Advanced persistent threats have garnered a lot of attention of late, deservedly so. APTs are arguably the most dangerous security concern for business organizations today, given their targeted nature.
An APT attack is typically launched by a professional organization based in a different country than the victim organization, thereby complicating law enforcement. These hacking organizations are often broken into specialized teams that work together to infiltrate corporate networks and systems and extract as much valuable information as possible. Illegally hacking other companies is their day job. And most are very good at it.
[ Find out how to greatly reduce the threat of malicious attacks with InfoWorld's Insider Threat Deep Dive PDF special report. | It's time to rethink security. Two former CIOs show you how to rething your security strategy for today's world. Bonus: Available in PDF and e-book versions. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
By all expert opinion, APTs have compromised the information infrastructure of any relevant company. The question isn't whether you've been compromised by an APT, but whether you've noticed it.
I've been helping companies fight and prevent APTs for nearly a decade. In that time I've amassed my share of war stories from the IT security trenches. Here are some of the better real-life tales, not just for the chase, but for the lessons learned.
APT war story No. 1: APT eyes are watching you
I once spent more than a year responding to an APT attack at a multinational company that was involved in everything from high-tech satellites and guns to refrigerators and education. When I got the call, the client had already been hit by two other APT attacks, which isn't unusual. Most companies that discover an APT usually figure out it's been there for years. One client I worked with has been compromised by three different APT teams over the past eight years -- not surprising in the least.
The multinational was finally serious about combatting the attack. The entire IT team was called together to respond; a large, single-purpose task force was created; all the relevant experts were brought in. It was decided that many months in the future all passwords would be reset.
You may wonder why the delay in resetting passwords. Password resets should always be pushed out far into the future in these situations because there's no use changing all the passwords to kick out an APT if you can't guarantee you can prevent the baddies from breaking right back in. Identify the most relevant weaknesses, fix them, then change the passwords. That's the best defense.
As in most companies I work with, everyone involved was sworn to secrecy. Code words were established, so the team could discuss various aspects of the project in (possibly monitored) emails without alerting intruders or employees not yet engaged.
In this instance, the big password reset day was scheduled to coincide with the company's annual baseball game, which had been instituted to increase employee morale. Because of this, the project was dubbed "company baseball game," with the name of the company changed here to protect its identity. From that point forward, no one mentioned APT or password reset. Everything was about the baseball game.
The company's systems were completely compromised, so new laptops and wireless routers were purchased. All project-related work was to be performed on these laptops over a secured wireless network to prevent any accidental leakage of information about the project, regardless of code-word use.
One facet of the project was to tackle the overabundance of domain administrators at the company. There were far too many -- all told, more than 1,000. We set up camp in one of the many executive conference rooms we used over the course of the project and began discussing what to do.
We couldn't decide which domain administrators were truly needed and which we could disable, so we decided to disable them all on "company baseball game" day, and force those who really needed domain admin access to reaffirm their need. We drafted a domain admin access request form on one of the project laptops and called it a day. We would send out the forms just before "company baseball game" day so that each person who needed a domain admin account could get one in time to be prepared.
The next morning around 7:30 a.m., I entered that same executive conference room. The project manager was already there. He looked up at me, his eyes a bit wider than usual for the early hour, and said, "Here's our first two domain admin requests," as he flipped them to me.
What did he mean domain admin requests? The form wasn't out of draft stage and wasn't scheduled to go out for months. But there they were, two filled-out "domain admin access request" forms. They had some small, but very noticeable mistakes, so it was obvious they were not from our original draft. Each was filled in by team members belonging to a foreign subsidiary, who currently had domain admin access. The reason they were requesting the reinstated domain admin access? Because the current access was to be cut on baseball game day.
To this day, I still can't believe it. I was holding two forms that shouldn't have existed. The only draft was on a laptop on an air-gapped network. Our precious secret project code was blown. Astonishment passed from team member to team member along with the forms as we gave them the news.
After much investigation, we figured out that the APT, led by insiders, had infiltrated all the conference rooms using the data display projectors and executive videoconference systems. They were watching and digesting all our supposedly secret meetings. Their only mistake was in not understanding that the form didn't really exist yet and was not due to be sent out for months. Thank goodness for language barriers.
Lesson: If your conference equipment is networked and has the ability to record voice or video, make sure you disable them before conducting meetings.
APT war story No. 2: Not all APTs are as advanced as experts think
This is the story of an APT team that had taken total control of a company's network. They were actively creating connections all around the network, day or night, by the time I got called in. They were beyond caring whether they had been discovered.
APTs are almost certain to dump all password hashes and use pass the hash (PtH) tools to take over the rest of an organization's network. In this instance, the customer decided it was time to disable those weak LAN Manager (LM) password hashes that Microsoft had been recommending to disable for at least 10 years, and trying to disable by default at least since 2008. This particular APT was using the captured LM password hashes to do the dirty work.
I told the customer the proposal would not work because, by default, at least two types of Windows password hashes exist in Microsoft authentication databases: LM and NT hashes. The attackers had downloaded both types, and the PtH tool they were working with could use either. I even showed the client how the attacker's tool had the syntax built in to switch between LM and NT hashes, a very common feature of PtH attack tools. Worse, even if you disable the storing of LM hashes, they are still created in memory when someone logs on. It sounds crazy, but that's how Windows works.
The customer would not be dissuaded. Despite my protestations of wasted effort, it disabled the LM hashes and reset the passwords. Now the local and Active Directory databases contained no usable LM password hashes. You know how well that worked?
Well, it worked -- because the APT team never used another password hash to perform its attack. Truth be told, they just moved on to other methods (see below), but the PtH attacks stopped. It turned out that the APT team didn't even know its own tools. You could imagine the discussion they must have had internally when all the LM hashes disappeared, including shrugged shoulders and a brainstorm of new strategies.
Lesson: "Advanced" may be included in the name of APT, but not all APT attackers are all that advanced. Plus, sometimes the expert is wrong. I wasn't wrong technically, but that didn't prevent the outcome the client was looking for to be the same. It humbled me.
APT war story No. 3: The medicine may be the poison
As a full-time Microsoft security consultant, I'm frequently asked to work on APT engagements led by other companies; I'm a resource, not the project leader. There's one security consulting company I've worked with enough to know many of its staff members and consultants informally, if not personally. We understand what our roles are -- depending on who gets there first, makes friends with the CIO, and assumes leadership. Our partnerships have always been friendly, though competitive. After all, it's better to be a leader than a follower.
This security consulting firm is well known for fighting APTs and even sells detection software to help. Frequently, on engagements, it succeeds in selling its software and getting it installed on every computer in the environment. I was very used to seeing its service running in Windows Task Manager.
In this particular story, the security consulting firm arrived first, saved the day, and moved on. It also succeeded in installing its software throughout the organization and hadn't been onsite in nearly a year. As far as anyone knew, the customer had been APT-free since the initial remedy. At least no one had detected any signs.
I'm a big fan of honeypots. A honeypot is software or a device that exists simply to be attacked. It can be an unused computer, router, or server. Honeypots can mimic anything, and they are great for detecting previously undetectable adversaries, so I recommend them often. This can be a decommissioned computer to which no person or service should be connecting. When a hacker or malware does connect, the honeypot sends an alert that can trigger an immediate incident response.
In this instance, I spent a few days helping the client deploy some honeypots. Most customers ask me how we are going attract hackers to the honeypots. I always laugh and answer the same way: "Don't worry, they will come." Indeed, every honeypot I've ever set up has detected nefarious activity within a day or two. These new honeypots were no different.
We detected network logon attempts coming from multiple workstations, none of which had a legitimate reason to be logging on. We pulled a few of these workstations and forensically examined their hard drives. We found that the APT had placed a remote-access Trojan on each of them. The Trojan's name? The same as the anti-APT detection software. The bad guys had someone replace the legitimate anti-APT software with a Trojan, and it turns out they did it on nearly every computer.
This explained a few things, like why no APT had been detected. But the bigger question was how did it get installed in the first place. It turned out the customer's "gold build" had been compromised in its build environment, and this Trojan was part of the build.
Lessons: First, verify the integrity of your builds; prevent unauthorized modification or invent some way to detect it. Second, honeypots are a great way to detect malicious activity. Third, always look for and investigate strange network connections from unexpected places.
APT war story No. 4: All your PKI base belong to us
APT attacks on Public Key Infrastructure (PKI) servers used to be somewhat rare. In fact, until two years ago, I never personally ran across an APT where PKI servers had been involved. Now, it's fairly common. But the most relevant story is the one where the PKI turned into physical access in a sensitive area.
This particular customer used its internal PKI servers to create employee smartcards. These smartcards were used to not only log on to computers but to physically access company buildings and other infrastructure.
The customer's root CA (certification authority) server was a virtual instance sitting, disabled, on a VMware host server. The bad guys had found it, copied it offsite, cracked the local (weak) administrator password, and generated their own trusted subordinate CA. They used this CA to issue themselves PKI access to everything they could.
What surprised me most was the video my client showed me of two unknown men posing as employees. Using the fake smartcards they created, they had parked their cars inside the secured company parking lot, walked into the building through the employee entrance, and onto a floor that stored highly sensitive data.
My customer couldn't tell me what happened after that or what was taken, but I knew they were not happy. There was a very serious mood in the room. I was invited to help them create a new PKI and to migrate the company into the better-secured PKI environment.
Lesson: Protect your PKI CA servers. Offline CAs should be just that: offline! They should not be disabled or sitting on the network with their network cards disabled, but off the network, stored in a safe, and not so easy to compromise. CA private keys should be protected by a Hardware Storage Module appliance, and all related passwords should be very long (15 characters or more) and complex. Plus, it can't hurt to look for and monitor if other unauthorized CAs get added as trusted CAs.
APT war story No. 5: Don't forget the accounts you're not supposed to touch