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.

Netragard’s Hacker Interface Device (HID). You can get hacked by your mouse.

We (Netragard) recently completed an engagement for a client with a rather restricted scope. The scope included a single IP address bound to a firewall that offered no services what so ever. It also excluded the use of social attack vectors based on social networks, telephone, or email and disallowed any physical access to the campus and surrounding areas. With all of these limitations in place, we were tasked with penetrating into the network from the perspective of a remote threat, and succeeded. The first method of attack that people might think of when faced with a challenge like this is the use of the traditional autorun malware on a USB stick. Just mail a bunch of sticks to different people within the target company and wait for someone to plug it in; when they do its game over, they’re infected. That trick worked great back in the day but not so much any more. The first issue is that most people are well aware of the USB stick threat due to the many published articles about the subject. The second is that more and more companies are pushing out group policies that disable the autorun feature in Windows systems. Those two things don’t eliminate the USB stick threat, but they certainly have a significant impact on its level of success and we wanted something more reliable.

Enter PRION, the evil HID. mouse_guts

A prion is an infectious agent composed of a protein in a misfolded form. In our case the prion isn’t composed of proteins but instead is composed of electronics which include a teensy microcontroller, a micro USB hub (small one from RadioShack), a mini USB cable (we needed the ends) a micro flash drive (made from one of our Netragard USB Streamers), some home-grown malware (certainly not designed to be destructive), and a USB device like a mouse, missile turret, dancing stripper, chameleon, or whatever else someone might be tempted to plug in. When they do plug it in, they will be infected by our custom malware and we will use that point of infection to compromise the rest of the network. For the purposes of this engagement we choose to use a fancy USB logitech mouse as our Hacker Interface Device / Attack Platform. To turn our logitech Human Interface Device into a Hacker Interface Device, we had to make some modifications. The first step of course was to remove the screw from the bottom of the mouse and pop it open. Once we did that we disconnected the USB cable from the circuit board in the mouse and put that to the side. Then we proceed to use a drummel tool to shave away the extra plastic on the inside cover of the mouse. (There were all sorts of tabs that we could sacrifice). The removal of the plastic tabs was to make room for the new hardware. Once the top of the mouse was gutted and all the unnecessary parts removed we began to focus on the USB hub. The first thing we had to do was to extract the board from the hub. Doing that is a lot harder than it sounds because the hub that we chose was glued together and we didn’t want to risk breaking the internals by being too rough. After about 15 minutes of prying with a small screwdriver (and repeated accidental hand stabbing) we were able to pull the board out from the plastic housing. We then proceeded to strip the female USB connectors off of the board by heating their respective pins to melt the solder (careful not to burn the board). Once those were extracted we were left with a naked USB hub circuit board that measured about half an inch long and was no wider than a small bic lighter. With the mouse and the USB board prepared we began the process of soldering. The first thing that we did was to take the mini USB cable, cut one of the ends off leaving about 1 inch of wire near the connector. Then we stripped all plastic off of the connector and stripped a small amount of wire from the 4 internal wires. We soldered those four wires to the USB board making sure to follow theright pinout pattern. This is the cable that will plug into the teensy mini USB port when we insert the teensy microcontroller. Once that was finished we took the USB cable that came with the mouse and cut the circuit board connector off of the end leaving 2 inchs of wire attached. We stripped the tips of the 4 wires still attached to the connector and soldered those to the USB hub making sure to follow the right pinout patterns mentioned above. This is an important cable as its the one that connects the USB hub to the mouse. If this cable is not soldered properly and the connections fail, then the mouse will not work. We then took the other piece of the mouse cable (the longer part) and soldered that to the USB board. This is the cable that will connect the mouse to the USB port on the computer. At this point we have three cables soldered to the USB hub. Just to recap those cables are the mouse connector cable, the cable that goes from the mouse to the computer, and the mini USB adapter cable for the teensy device. The next and most challenging part of this is to solder the USB flash drive to the USB hub. This is important because the USB flash drive is where we store our malware. If the drive isn’t soldered on properly then we won’t be able to store our malware on the drive and the the attack would be mostly moot. ( We say mostly because we could still instruct the mouse to fetch the malware from a website, but that’s not covert.) To solder the flash drive to the USB hub we cut about 2 inches of cable from the mini USB connector that we stole the end from previously. We stripped the ends of the wires in the cable and carefully soldered the ends to the correct points on the flash drive. Once that was done we soldered the other ends of the cable to the USB hub. At that point we had everything soldered together and had to fit it all back into the mouse. Assembly was pretty easy because we were careful to use as little material as possible while still giving us the flexibility that we needed. We wrapped the boards and wires in single layers of electrical tape as to avoid any shorts. Once everything was we plugged in we tested the devices. The USB drive mounted, the teensy card was programmable, and the mouse worked. Time to give prion the ability to infect… We learned that the client was using Mcafee as their antivirus solution because one of their employees was complaining about it on Facebook. Remember, we weren’t allowed to use social networks for social engineering but we certainly were allowed to do reconnaissance against social networks. With Mcafee in our sights we set out to create custom malware for the client (as we do for any client and their respective antivirus solution when needed). We wanted our malware to be able to connect back to Metasploit because we love the functionality, we also wanted the capabilities provided by meterpreter, but we needed more than that. We needed our malware to be fully undetectable and to subvert the “Do you want to allow this connection” dialogue box entirely. You can’t do that with encoding… Update: As of 06/29/2011 9AM EST: this variant of our pseudomalware is being detected by Mcafee. Update: As of 06/29/2011 10:47AM EST: we’ve created a new variant that seems to bypass any AV. To make this happen we created a meterpreter C array with the windows/meterpreter/reverse_tcp_dns payload. We then took that C array, chopped it up and injected it into our own wrapper of sorts. The wrapper used an undocumented (0-day) technique to completely subvert the dialogue box and to evade detection by Mcafee. When we ran our tests on a machine running Mcafee, the malware ran without a hitch. We should point out that our ability to evade Mcafee isn’t any indication of quality and that we can evade any Antivirus solution using similar custom attack methodologies. After all, its impossible to detect something if you don’t know what it is that you are looking for (It also helps to have a team of researchers at our disposal). Once we had our malware built we loaded it onto the flash drive that we soldered into our mouse. Then we wrote some code for the teensy microcontroller to launch the malware 60 seconds after the start of user activity. Much of the code was taken from Adrian Crenshaw’s website who deserves credit for giving us this idea in the first place. After a little bit of debugging, our evil mouse named prion was working flawlessly. Usage: Plug mouse into computer, get pwned. The last and final step here was to ship the mouse to our customer. One of the most important aspects of this was to repack the mouse in its original package so that it appeared unopened. Then we used Jigsaw to purchase a list of our client’s employes. We did a bit of reconnaissance on each employee and found a target that looked ideal. We packaged the mouse and made it look like a promotional gadget, added fake marketing flyers, etc. then shipped the mouse. Sure enough, three days later the mouse called home.

The Human Vulnerability

It seems to us that one of the biggest threats that businesses face today is socially augmented malware attacks. These attacks have an extremely high degree of success because they target and exploit the human element. Specifically, it doesn’t matter how many protective technology layers you have in place if the people that you’ve hired are putting you at risk, and they are.

Case in point, the “here you have” worm that propagates predominantly via e-mail and promises the recipient access to PDF documents or even pornographic material. This specific worm compromised major organizations such as NASA, ABC/Disney, Comcast, Google Coca-Cola, etc. How much money do you think that those companies spend on security technology over a one-year period? How much good did it do at protecting them from the risks introduced by the human element? (Hint: none)

Here at Netragard we have a unique perspective on the issue of malware attacks because we offer pseudo-malware testing services. Our pseudo-malware module, when activated, authorizes us to test our clients with highly customized, safe, controlled, and homegrown pseudo-malware variants. To the best of our knowledge we are the only penetration testing company to offer such a service (and no, we’re not talking about the meterpreter).

Attack delivery usually involves attaching our pseudo-malware to emails or binding the pseudo-malware to PDF documents or other similar file types. In all cases we make it a point to pack (or crypt) our pseudo-malware so that it doesn’t get detected by antivirus technology (see this blog entry on bypassing antivirus). Once the malware is activated, it establishes an encrypted connection back to our offices and provides us with full control over the victim computer. Full control means access to the software and hardware including but not limited to keyboard, mouse, microphone and even the camera. (Sometimes we even deliver our attacks via websites like this one by embedding attacks into links).

So how easy is it to penetrate a business using pseudo-malware? Well in truth its really easy. Just last month we finished delivering an advanced external penetration test for one of our more secure customers. We began crafting an email that contained our pseudo-malware attachment and accidentally hit the send button without any message content. Within 45 seconds of clicking the send button and sending our otherwise blank email, we had 15 inbound connections from 15 newly infected client computer systems. That means that at least 15 employees tried to open our pseudo-malware attachment despite the fact that the email was blank! Imagine the degree of success that is possible with a well-crafted email?

One of the computer systems that we were able to compromise was running a service with domain admin privileges. We were able to use that computer system (impersonation attack involved) to create an account for ourselves on the domain (which happened to be the root domain). From there we were able to compromise the client’s core infrastructure (switches, firewalls, etc) due to a password file that we found sitting on someone’s desktop (thank you for that). Once that was done, there really wasn’t much more that we had left to do, it was game over.

The fact of the matter is that there’s nothing new about taking advantage of people that are willing to do stupid things. But is it really stupidity or is it just that employees don’t have a sense of accountability? Our experience tells us that in most cases its a lack of accountability that’s the culprit.

When we compromise a customer using pseudo-malware, one of the recommendations that we make to them is that they enforce policies by holding employees accountable for violations. We think that the best way to do that is to require employees to read a well-crafted policy and then to take a quiz based on that policy. When they pass the quiz they should be required to sign a simple agreement that states that they have read the policy, understood the policy, and agree to be held accountable for any violations that they make against the policy.

In our experience there is no better security technology than a paranoid human that is afraid of being held accountable for doing anything irresponsible (aka: violating the policy). When people are held accountable for something like security they tend to change their overall attitude towards anything that might negatively affect it. The result is a significantly reduced attack surface. If all organizations took this strict approach to policy enforcement then worms like the “here you have” worm wouldn’t be such a big success.

Compare the cost and benefit of enforcing a strict and carefully designed security policy to the cost and benefit of expensive (and largely ineffective) security technologies. Which do you think will do a better job at protecting your business from real threats? Its much more difficult to hack a network when that network is managed by people that are held accountable for its security than it is to hack a network that is protected technology alone.

So in the end there’s really nothing special about the “here you have” worm. It’s just another example of how malicious hackers are exploiting the same human vulnerability using an ever so slightly different malware variant. Antivirus technology certainly won’t save you and neither will other expensive technology solutions, but a well-crafted, cost-effective security policy just might do the trick.

It’s important to remember that well written security policies don’t only impact human behavior, but generally result in better management of systems, which translates to better technological security. The benefits are significant and the overall cost isn’t in comparison.