Enemy of the state

A case study in Penetration Testing
We haven’t been blogging as much as usual largely because we’ve been busy hacking things.   So, we figured that we’d make it up to our readers by posting an article about one of our recent engagements. This is a story about how we covertly breached a highly sensitive network during the delivery of a Platinum level Penetration Test.

First, we should make clear that while this story is technically accurate certain aspects have been altered to protect our customer’s identity and security. In this case we can’t even tell you if this was for a private or public sector customer. At no point will ever write an article that would put any of our customers at risk. For the sake of intrigue lets call this customer Group X.

The engagement was designed to produce a level of threat that would exceeded that which Group X was likely to face in reality. In this case Group X was worried about specific foreign countries breaching their networks. Their concern was not based on any particular threat but instead based on trends and what we agreed was reasonable threat intelligence.   They were concerned with issues such as watering holes, spear phishing, 0-day malware, etc. They had reason for concern given that their data was and still is critically sensitive.

We began work like any experienced hacker would, by performing social reconnaissance. Social reconnaissance should always be used before technical reconnaissance because it’s passive by design. Social reconnaissance when done right will provide solid intelligence that can be used to help facilitate a breach. In many cases social reconnaissance can eliminate the need for active technical reconnaissance.

Just for the sake of explanation, technical reconnaissance includes active tasks like port scanning, web server scanning, DNS enumeration, etc. Technical reconnaissance is easier to detect because of its active methods. Social reconnaissance, when done right, is almost impossible to detect because it is almost entirely passive. It leverages tools like Google, Maltego, Censys, etc. to gather actionable intelligence about a target prior to attack.

Our social reconnaissance efforts identified Group X’s entire network range, a misconfigured public facing document repository (that did not belong to Group X but was used by them and their partners/vendors), and a series of news articles that were ironically focused on how secure Group X was. One of the articles went so far as to call Group X the “poster child of good security”.

We began by exploring the contents of the aforementioned document repository. The repository appeared to be a central dumping ground for materials Group X wanted to share with third parties, including vendors. While digging through the information all of it appeared to be non-sensitive and mostly intended for public consumption. As we dug further we uncovered a folder called WebServerSupport and contained within that folder was a file called “encyrypted.zip”. Needless to say we downloaded the file.

We were able to use a dictionary attack to guess the password for the zip file and extract its contents. The extracted files included a series of web server administration guides complete with usernames, passwords, and URL’s. One of the username, password and URL combinations was for Group X’s main website (https://www.xyxyxyxyxy.com/wp-admin,username,password). When we browsed to https://www.xyxyxyxyxy.com/wp-admin we were able to login using the credentials. With this level of access we knew that it was time to poison the watering hole. (https://en.wikipedia.org/wiki/Watering_Hole)

To accomplish this we deployed our malware framework into the webserver (www.xyxyxyxyxy.com). Our framework is specifically designed to allow us to control who is infected. We are able to select targets based on their source IP address and other information identifying information. When a desired target connects to the watering hole (infected website) our framework deploys our 0-day pseudo-malware (RADON) into the victim’s computer system.   RADON then establishes persistence and connects back to our command and control server. From there we are able take complete control of the newly infected computer.
Netragard RADON v2.0 Strand Generator
radon_gen
RADON is not the same RADON used by the National Security Agency (NSA) as was speculated by the InfoSec institute. RADON does appear similar in some respects. It relies on side channel communications that cannot be disrupted without breaking core network protocols. It was designed to be far safer than other tools that tend to leave files behind (like Metasploit’s meterpreter). All strands of RADON are built with an expiration date that when reached trigger a clean uninstall and render the original source inert. We designed RADON specifically because we needed a save, clean and reliable method to test our customers at high levels of threat.

After the malware framework was deployed and tested, we scheduled it to activate the next business day. The framework was designed to infect one target then sleep until we instructed it to infect the next. This controlled infection methodology helps to maintain stealth. By 9:30 AM EST our first RADON strand called home. When we reviewed the connection we learned that we had successfully infected a desktop belonging Group X’s CIO’s assistant. We confirmed control and were ready to begin taking the domain (which as it turns out was ridiculously easy).

One of the first things we do after infecting a host is to explore network shares. During this test we quickly located the “scripts” share, which contained all of the login scripts for domain users. What we didn’t expect was that we’d be able to read, write, and otherwise modify every single one of those startup scripts. We were also able to create new scripts, new files and directories within the scripts directory. So uploaded RADON to the share and added a line to every login script that would run RADON every time a user logged into a computer. We quickly infected everything on the network.

After parsing through the onslaught of new inbound RADON connections we were able to identify personal user accounts belonging to network administrators. As it turned out most of the administrators personal accounts also had domain admin privileges. We leveraged those accounts to download the username and password database (ntds.dit) from the domain controller. Then we used RADON to exfiltrate the password database and dump it on one of our GPU password-cracking machines. We were able to crack all of the current and historical passwords in less than 2 hours time. What really surprised us was that 90% of the passwords were exactly identical.

Initially we thought that this was due to an error.   But after further investigation we realized that this common password could be used to login using all of the different domain accounts. It became even more interesting when we began to explore the last password change dates. We found that nearly 100% of the passwords had never been changed and that some of the accounts were over a decade old, still active, but no longer being used by anyone. We later found out that employees that had been terminated never had their accounts deactivated. When we confronted the customer with this they told us that it was their policy to not change passwords. When we asked them why they pointed to an article written by Bruce Schneier. (Sorry Bruce, but this isn’t the first time you’ve made us question you.)

At this point in the engagement we had more control over our customer’s infrastructure than they did. We were able to control all of their critical devices including but not limited to antivirus solutions, firewalls, intrusion detection and prevention systems, log correlation systems, switches, routers and of-course their domain. We accomplished this without triggering a single event and without any suspicion.

The last two tasks that remained were trophy gathering and vulnerability scanning. Trophy gathering was easy given the level of access that we had. We simply searched the network for .pdf, .doc,.docx,.xlsx, etc. and harvested files that looked interesting. We did find about a dozen reports from other penetration testing vendors as well. When we looked at those reports they presented Group X’s network as well managed and well protected. The only vulnerabilities that were identified were low and medium level vulnerabilities, none of which were exploitable.

When we completed our final task which was vulnerability scanning and vetting, our scanners produced results that were nearly identical to the other penetration testing vendor reports that we exfiltrated. Things like deprecated SSL, open ports, etc. were reported but nothing that could realistically lead to a network compromise. When we scanned Group X’s network from the perspective of an Internet based threat no vulnerabilities were reported. Our scans resulted in their security team becoming excited and proud because they “caught” and “prevented our intrusion attempt. When we told them to check their domain for a Netragard domain admin account, their excitement was over.

Custom Security Projects

What you don’t know about compliance…

People are always mystified by how hackers break into major networks like Target, Hannaford, Sony, (government networks included), etc.  They always seem to be under the impression that hackers have some elite level of skill.  The truth is that it doesn’t take any skill to break into most networks because they aren’t actually protected. Most network owners don’t care about security because they don’t perceive the threat as real.  They suffer from the “it won’t ever happen to me” syndrome.
As a genuine penetration testing company we take on dozens of new opportunities per month.  Amazingly, roughly 80% of businesses that request services don’t want quality security testing, they want a simple check in the compliance box. They perceive quality security testing as an unnecessary and costly annoyance that stands in the way of new revenue.  These businesses test because they are required to, not because they want to.  These requirements stem from partners, customers, and regulations that include but are not limited to PCI-DSS, HIPAA, etc.
Unfortunately these requirements make the problem worse rather than better.  For example, while PCI requires merchants to receive penetration tests it completely fails to provide any effective or realistic baseline against which to measure the test results.  This is also true of HIPAA and other third party testing requirements.  To put this into perspective, if the National Institute of Justice set their V50 or V0 standards in the same manner then it would be adequate and acceptable to test bulletproof vests with  squirt guns.  Some might argue that poor testing is better than nothing but we’d disagree.  Testing at less than realistic levels of threat does nothing to prevent the real threat from penetrating.
Shoddy testing requirements and a general false sense of security have combined to create a market where check in the box needs take priority over genuine security.  Vendors that sell into this market compete based on cost, free service add-ons and free software licenses rather than quality of service and team capability, and price illogically based on IP count. Most testing vendors exacerbate the problem because they falsely advertise compliance testing (check in the box) services as best quality.  This creates and perpetuates a false sense of security among non-security expert customers and also lures in customers who have a genuine security need.
The dangers associated with this are evidenced by the many businesses that have suffered damaging compromises despite the fact that they are in compliance with various regulations.  The recent Target breach (certified as PCI compliant by Trustwave) is just one high-profile example.  Target’s former CEO, Gregg Steinhafel was quoted saying “Target was certified as meeting the standard for the payment card industry (PCI) in September 2013. Nonetheless, we suffered a data breach”.  Another high-profile example is the Hannaford breach (Rapid7’s customer at the time) back in 2008.  Hannaford, like Target, claims that they too were PCI compliant.
It’s our responsibility as security experts to deliver truth to our customers rather than to bank on their lack of expertise.  Sure we’re in this to make money but we also have an ethical responsibility.  If we take the time to educate our customers about the differences between compliance testing and genuine penetration testing and they still select compliance testing then that’s fine (its their risk).  But if we lie to our customers and sell them compliance testing while we assert that it’s best in class then we should be held responsible.  After all, it’s our job to protect people isn’t it?
The irony is that Compliance testing typically cost more than genuine penetration testing because it uses an arbitrary count based pricing methodology.  Specifically, if customer has 10 IP addresses but only 1 of those IP addresses is live the customer will still be billed for testing all 10 IP addresses.  Genuine penetration testing costs less because it uses an Attack Surface Pricing (ASP) methodology.  If a customer has 10 IP addresses and only one is live then ASP will identify that and the customer will only be charged for that 1 IP.  Moreover, the customer will be charged based on the complexity of the services provided by that one IP.
If the Return on Investment (RoI) of good security is equal to the cost in damages of a single successful compromise and if quality penetration testing services cost less (on average) than compliance testing services, doesn’t it make sense to purchase quality penetration testing services?