Terms like China, APT and Zero-Day are synonymous with Fear, Uncertainty and Doubt (FUD). The trouble is that, in our opinion anyway, these terms and respective news articles detract from the actual problem. For example, in 2011 only 0.12% of compromises were attributed to zero-day exploitation and 99.88% were attributed to known vulnerabilities. Yet, despite this fact the media continued to write about the zero-day threat as if it was a matter of urgency. What they really should have been writing about is that the majority of people aren’t protecting their networks properly. After all, if 99.88% of all compromises were the result of the exploitation of known vulnerabilities then someone must not have been doing their job. Moreover, if people are unable to protect their networks from the known threat then how are they ever going to defend against the unknown?
All of the recent press about China and their Advanced Persistent Threat is the same, it detracts from the real problem. More clearly, the problem isn’t China, Anonymous, LulzSec, or any other FUD ridden buzzword. The problem is that networks are not being maintained properly from a security perspective and so threats are aligning with risks to successfully affect penetration. A large part of the reason why these networks are such soft targets is because their maintainers are sold a false sense of security from both the services and technology perspective.
In this article we’ll show you how easy it was for us to hack into a sensitive government network that was guarded by industry technologies and testing best practices. Our techniques deliberately mimicked those used by China. You’ll notice that the techniques aren’t particularly advanced (despite the fact that the press calls them Advanced) and in fact are based largely on common sense. You’ll also notice that we don’t exploit a single vulnerability other than those that exist in a single employee (the human vulnerability). Because this article is based on an actual engagement we’ve altered certain aspects of our story to protect our customer and their respective identity. We should also make mention that since the delivery of this engagement our customer has taken effective steps to defeat this style of attack.
Here’s the story…
We recently (relatively speaking anyway) delivered a nation state style attack against one of our public sector customers. In this particular case our testing was unrestricted and so we were authorized to perform Physical, Social and Electronic attacks. We were also allowed to use any techniques and technologies that were available should we feel the need.
Lets start off by explaining that our customers network houses databases of sensitive information that would be damaging if exposed. They also have significantly more political weight and authority than most of the other departments in their area. The reason why they were interested in receiving a nation-state style Penetration Test is because another department within the same area had come under attack by China.
We began our engagement with reconnaissance. During this process we learned that the target network was reasonably well locked down from a technical perspective. The external attack surface provided no services or application into which we could sink our teeth. We took a few steps back and found that the supporting networks were equally protected from a technical perspective. We also detected three points where Intrusion Prevention was taking place, one at the state level, one at the department level, and one functioning at the host level.
(It was because of these protections and minimalistic attack surface that our client was considered by many to be highly secure.)
When we evaluated our customer from a social perspective we identified a list of all employees published on a web server hosted by a yet another department. We were able to build micro-dossiers for each employee by comparing employee names and locations to various social media sites and studying their respective accounts. We quickly constructed a list of which employees were not active within specific social networking sites and lined them up as targets for impersonation just in case we might need to become someone else.
We also found a large document repository (not the first time we’ve found something like this) that was hosted by a different department. Contained within this repository was a treasure trove of Microsoft Office files with respective change logs and associated usernames. We quickly realized that this repository would be an easy way into our customers network. Not only did it provide a wealth of META data, but it also provided perfect pretexts for Social Engineering… and yes, it was open to the public.
(It became glaringly apparent to us that our customer had overlooked their social points of risk and exposure and were highly reliant on technology to protect their infrastructure and information. It was also apparent that our customer was unaware of their own security limitations with regards to technological protections. Based on what we read in social forums, they thought that IPS/IDS and Antivirus technologies provided ample protection.)
We downloaded a Microsoft Office document that had a change log that indicated that it was being passed back and fourth between one of our customers employees and another employee in different department. This was ideal because a trust relationship had already been established and was ripe for the taking. Specifically, it was “normal” for one party to email this document to the other as a trusted attachment. That normalcy provided the perfect pretext.
(Identifying a good pretext is critically important when planning on launching Social Engineering attacks. A pretext is a good excuse or reason to do something that is not accurate. Providing a good pretext to a victim often causes a victim to perform actions that they should not perform.)
Once our document was selected we had our research team build custom malware specifically for the purpose of embedding it into the Microsoft Office document. As is the case with all of our malware, we built in automatic self-destruct features and expiration dates that would result in clean deinstallation when triggered. We also built in covert communication capabilities as to help avoid detection.
(Building our own malware was not a requirement but it is something that we do. Building custom malware ensures that it will not be detected, and it ensures that it will have the right features and functions for a particular engagement.)
Once the malware was built and embedded into the document we tested it in our lab network. The malware functioned as designed and quickly established connectivity with its command and control servers. We should mention that we don’t build our malware with the ability to propagate for liability and control reasons. We like keeping our infections highly targeted and well within scope.
When we were ready to begin our attack we fired off a tool designed to generate a high-rate of false positives in Intrusion Detection / Prevention systems and Web Application Firewalls alike. We ran that tool against our customers network and through hundreds of different proxies to force the appearance of multiple attack sources. Our goal was to hide any real network activity behind a storm of false alarms.
(This demonstrates just how easily Intrusion Detection and Prevention systems can be defeated. These systems trust network data and generate alerts based on that network data. When an attacker forges network data then that attacker can also forge false alerts. Generate enough false alerts and you disable ones ability to effectively monitor the real threat.)
While that tool was running we forged an email to our customers employee from the aforementioned trusted source. That email contained our infected Microsoft Office document as an attachment. Within less than three minutes our target received the email and opened the infected attachment thus activating our malware. Once activated our malware connected back to its command and control server and we had successfully penetrated into our customer’s internal IT infrastructure. We’ll call this initial point of Penetration T+1. Shortly after T+1 we terminated our noise generation attack.
(The success of our infection demonstrates how ineffective antivirus technologies are at preventing infections from unknown types of malware. T+1 was using a current and well respected antivirus solution. That solution did not interfere with our activities. The success of our penetration at this point further demonstrates the risk introduced by the human factor. We did not exploit any technological vulnerability but instead exploited human trust.)
Now that we had access we needed to ensure that we kept it. One of the most important aspects of maintaining access is monitoring user activity. We began taking screenshots of T+1’s desktop every 10 seconds. One of those screenshots showed T+1 forwarding our email off to their IT department because they thought that the attachment looked suspicious. While we were expecting to see rapid incident response, the response never came. Instead, to our surprise, we received a secondary command and control connection from a newly infected host (T+2).
When we began exploring T+2 we quickly realized that it belonged to our customers head of IT Security. We later learned that he received the email from T+1 and scanned the email with two different antivirus tools. When the email came back as clean he opened the attachment and infected his own machine. Suspecting nothing he continued to work as normal… and so did we.
Next we began exploring the file system for T+1. When we looked at the directory containing users batch files we realized that their Discretionary Access Control Lists (DACL’s) granted full permissions to anyone (not just domain users). More clearly, we could read, write, modify and delete any of the batch files and so decided to exploit this condition to commit a mass compromise.
To make this a reality, our first task was to identify a share that would allow us to store our malware installer. This share had to be accessible in such a way that when a batch file was run it could read and execute the installer. As it turned out the domain controllers were configured with their entire C: drives shared and the same wide open DACL’s.
We located a path where other installation files were stored on one of the domain controllers. We placed a copy of our malware into that location and named it “infection.exe”. Then using a custom script we modified all user batch files to include one line that would run “infection.exe” whenever a user logged into a computer system. The stage was set…
In no time we started receiving connections back from desktop users including but not limited to the desktops belonging to each domain admin. We also received connections back from domain controllers, exchange servers, file repositories, etc. Each time someone accessed a system it became infected and fell under our control.
While exploring the desktops for the domain administrators we found that one admin kept a directory called “secret”. Within that directory were backups for all of the network devices including intrusion prevention systems, firewalls, switches, routers, antivirus, etc. From that same directory we also extracted viso diagrams complete with IP addresses, system types, departments, employee telephone lists, addresses, emergency contact information, etc.
At this point we decided that our next step would be to crack all passwords. We dumped passwords from the domain controller and extracted passwords from the backed up configuration files. We then fed our hashes to our trusted cracking machine and successfully cracked 100% of the passwords.
(We should note that during the engagement we found that most users had not changed their passwords since their accounts had been created. We later learned that this was a recommendation made by their IT staff. The recommendation was based on an article that was written by a well-respected security figure.)
With this done, we had achieved an irrecoverable and total infrastructure compromise. Had we been a true foe then there would be no effective way to remove our presence from the network. We achieved all of this without encountering any resistance, without exploiting a single technological vulnerability, without detection (other than the forwarded email of course) and without the help of China. China might be hostile but then again so are we.
