Quantcast

Adaptive Penetration Testing 3: Prep for a Software Vendor Compromise

Moving on from theory to practice, Kevin Mitnick and Dave Kennedy share some experience on extensive preparation for an actual software company breach.

Company 1

Company 1

Dave: Our first demo is Company 1, which Kevin was doing assessment on in December 2010.

Kevin: It was a company that developed software for the financial market. Again, it was a full compromise. Our goal was to get access to the source code of their products. And what we like to do at our company is we like to actually do a lot of reconnaissance to get exactly an idea of their environment so that we could set up their environment in our lab. That way, once we know their environment we can go ahead and try exploiting our own environment, and then when we’re doing it live, especially with a spear phishing attack, you only usually get one shot, so it works. We are very meticulous at setting up the exact systems using VMware, so we have the exact environment.

And, for example, when you are targeting a company and you want to get around the AV, what you hear people typically do is they’ll use social engineering to call up the company, call employees to find out what AV they are running. I don’t do that. I do it more passively. There’s only a handful of AV companies, right? So I’ll call the AV company, pretending to be the client, saying “Hey, we want to purchase more licenses, let me talk to sales.” And then I’ll give my company name and they’ll look it up, they’ll be happy, they want to make a sale. That’s how I’ll determine who the AV company is that’s providing the software. So, now we have the AV environment, now we have what they are running. We will use stuff like FOCA, we will use social engineering – we want to get their environment.

In this particular test, what we had found was most of the users at the company were running Windows 7, which is surprising because at that time most people were running XP. And what we wanted to do was, basically, target an individual that was on the internal network to a spear phishing attack using Dave’s tool, but we wanted to get persistent access to the company. The problem was we had to get around the AV that the company was using at that point, Symantec Endpoint Security. So we created some encrypted Meterpreter shells so that it wouldn’t be detected by AV. As we were setting this up we realized – because it’s Windows 7 – that these people were likely running with the defaults, meaning that UAC was enabled.

The problem was we had to get around the AV that the company was using at that point.

So we started doing some research on bypassing UAC and found that an expert – I don’t remember the exact name – found that some guy had found a workaround to bypass UAC. And it was, like, exploiting two vulnerabilities. The first was simply injecting into Explorer – because it was running at a medium integrity – and from there because of the whitelist you could use the IFileOperation COM object to copy files. So you could pretty much place a DLL or anything in any directory, you could do a file copy operation, because certain programs also, when you execute them, would look in their current directory for the DLL. And at system32 you could simply use this IFileOperation COM object to create a fake DLL to drop it in the directory so that now, when you fire up the executable, it would check in its current directory first before it would check in system32, because it wasn’t in that known DLL list. And, basically, you can bypass UAC.

So, this guy created a proof of concept tool that was kind of GUI based, so I had one of my security engineers create a command line version. It worked flawlessly. Then I was talking to Dave and I said “Why don’t we incorporate this in Metasploit?” So Dave took it, and I think he had some people at Diebold working on the same thing, the command line version. So this was actually doing a lot of work prior to doing the attack: finding out the AV, finding out the operating system of most of the targets at the company, and actually working on bypassing UAC before the client was even hit. And then when we did the attack, it actually worked flawlessly the first time. So I put a lot of time into preparation, into information reconnaissance before doing the real attack.

Profiling the targeted organization

Profiling the targeted organization

Dave: Do you want to talk about the System Profiler?

Kevin: Oh yeah, forgot about that. Another tool we use is by using bugs in email and by getting people to click links by using FOCA. We created a JavaScript tool that actually would profile the user. It would find out the version of Java they’re running, the version of Adobe Acrobat products, the version of QuickTime and Windows Media Player.

Fingerprinting the user

Fingerprinting the user

So we basically had to lure the target to a site that ran the JavaScript code, and this is kind of an example (see right-hand image). And again, we would try to fingerprint the user prior to doing the attack so that we know what exploit would work.

A lot of times when we are doing attacks, it’s a one-time opportunity because we’ll target people that are network engineers or system administrators. How do find them? LinkedIn is very useful: you can put in the company name and put in “engineer” or put in “administrator”, and you could likely get a target list. That’s one of the tools. Besides LinkedIn, there’s Jigsaw, pretexting and so on and so forth. Then we combine that information with fingerprinting the targets, and then we know exactly where to hit them at usually a good 99.9% success rate.

Targeting fully patched OS

Targeting fully patched OS

Dave: At this point, Kevin had customized Meterpreter shells that were AV bypassed by using encryptor and was able to target Window 7 fully patched systems (see right-hand image), then from there tried to go from the targets to the system itself. At this point, you had a chance to either pivot or go further.

Pivot or go further

Pivot or go further

Kevin: Well, I got a chance and I could pivot on the user’s workstation and not bother bypassing the UAC to target stuff on the inside (see right-hand image). But instead, I wanted to have persistent access into at least one person’s desktop so that I could, you know, keep going back. I wanted to do something that was quick, because I had spent so much time on the prep part of it in the research and getting everything working in the lab – I just wanted to expedite it. I could have sent an email and waited for somebody to go for it with the email,
UAC successfully bypassed

UAC successfully bypassed

but instead I used SET, on this occasion with the Java applet attack. And then I simply called the target, pretending to be somebody on the inside of the company that needed to test on the staging server, and basically just gave the URL where SET was running, Java applet pops up and they say “I got this popup.” And I go “Oh, just click OK, don’t worry about it, it’s all in staging, it’s all in testing.” And then I exploited them immediately rather than waiting.

So, again, this was a social engineering exploit, calling them up on the phone, having them click the Java applet – that way it was done. And we created an automated script which, once they clicked the applet, uploaded the Meterpreter shell, set something up in scheduled tasks that ran the encrypted Meterpreter shell every 30 minutes, and that way it was a persistent connection into the target.
 

Read previous: Adaptive Penetration Testing 2: Real vs Simulated Breach

Read next: Adaptive Penetration Testing 4: Windows UAC Bypass

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: