Computer security gurus Kevin Mitnick and Dave Kennedy taking the floor at DerbyCon to explain the concept of adaptive pentesting and cover its advantages.
Dave Kennedy: Thanks everybody for coming for the talk! Obviously, Kevin Mitnick and myself wanted to get together and get a talk around adaptive penetration testing, which will be explained a little bit here.
Kevin Mitnick: My book “Ghost in the Wires” is about kind of adaptive pentesting, a lot of that in the book. So, taking those concepts and using kind of the same stuff today – some of the same stuff still works but we’ll get into that later. We have a company and we do security assessments, but we usually take security assessments that are full compromise. We pick and choose, so it’s kind of fun. The only boring part of the work involved for pentesting is actually writing the report. But the actual work of pentesting is the awesome part. Dave is teaching me a little bit about social engineering, he wrote kind of a little toolkit. Dave it taking me under his wing.
Dave: I have to say Kevin is the number one bug contributor to the Social-Engineer Toolkit. He constantly uses it and gets to fix all the bugs that I do on my horrible coding. About myself – I’m the creator of the Social-Engineer Toolkit, one of the founders of DerbyCon (see right-hand image). I have a book from NoStarch Press. I’m on the BackTrack Development Team and Exploit-DB Team, although I’ve been kind of inactive on the Exploit-DB Team lately. I’m also an exploit writer. And I’m Chief Information Security Officer and Diebold. And I give hugs.
So, a brief introduction about what we wanted to cover here, adaptive penetration testing. When we look at penetration testing as a whole, it’s becoming kind of a convoluted system that we are leveraging, because there is no standardization around penetration testing. And for us, what we wanted to do is show different scenarios that we leverage in real-world penetration tests that are outside the norm: things that you don’t think of unless you are a hacker, things that you try to do that haven’t been done before that actually have a large impact on the organization.
Kevin: In a lot of penetration testing, what my clients talk to me about is they hire a company, they do scans with the common scanning tools, and then they package up something like a 400-page report with their logo and send it over to the CSO for review. In other words, they are not actually looking for the holistic vulnerabilities across the whole enterprise, where they could take several vulnerabilities that they have identified and put it together into something that’s really useful. They kind of stop at identifying the single vulnerabilities, put them in the report, send it over to the client, and it’s not of much use. That’s not every pentesting company that does it out there, but it’s a lot of them that I have encountered.
Dave: We are trying to come to a point in the security community where we can all come together and agree on the formal methodology around penetration testing that meets all of our needs. It requires actually having some skill to do penetration testing. That doesn’t mean you can’t grow through penetration testing; at the same time, we have to set some standards around actually performing penetration tests. That’s where the Penetration Testing Execution Standard was developed. Essentially, that standard defines what a penetration test should be. And basically, everybody in the community came together all over the world, people from god knows where, and said: “Listen, we’ve had enough, we want to define what this is, and this is what it’s going to be moving forward.”
And so, I look at the industry and I say: “Have we forgotten what we’re trying to do during a penetration test?” A whole goal of a penetration test is to attack the organization and try to impact their ability to generate revenue, or try to hit them where it actually hurts (see right-hand image). And that’s what an actual attacker is going to do: they are going to target the infrastructure, they are going to steal intellectual property, ransoms, try to go after financial system – whatever their motives are. And really, that’s where we kind of need to go when it comes penetration testing. That’s not really where we are at right now.
Kevin: I encourage people that are doing penetration testing to kind of think out of the box. Again, as I mentioned before, a lot of it is canned, or they follow a simple checklist. They do some good work, but I like to think about thinking out of the box, looking at the enterprise, looking at the target and figuring any way you can compromise that target through compromising physical, technical or human factor vulnerabilities. So when we are doing our pentesting we look at everything holistically and then we look how to attack the target. With my company, I hire pentesting contractors, and depending on the scope of the job they may hire a team, kind of like a mission impossible team, where the people involved are especially skilled at attacking what that client particularly has exposed. That’s how we set it up, and it’s been very successful.
Dave: And, obviously, there is something wrong. We are seeing an elevated number of breaches that are occurring. These statistics (see right-hand image) are taken from privacyrights.org. If you look at 2008 and 2011, there’s an exponential growth on companies actually receiving breaches. Somebody may say, hey, we might be getting better at detection elements. Well, generally speaking, around 70% of the companies had been in breach for several months or years without actually knowing that they were compromised. And so you think, with the industry growing larger and larger, we would actually start to be able to stop some of these exposures and actually start to stop some of these attacks. However, what we’re seeing is it’s not really happening.
Kevin: In fact, some old colleagues I used to work with, when they would compromise a target, the target would not get them out for years. I mean, once you get in, it’s extremely difficult to get the attackers out of the network, depending on their sophistication. But I have known guys who have been in for, like, a decade.
Dave: …Ouch! And so we look at our spend, as far as Gartner goes, and year after year we continue to increase out spend when it comes to security. We buy those shiny products, right? While those products are great and they actually can assist in building your security program, you have to look at your foundation first and what that really is. So we spend more money on protecting our infrastructure and we buy the latest technologies protecting us from zero-days.
And yet, we still see these guys (see right-hand image) running a muck.
Kevin: Yeah, these guys didn’t use super-sophisticated exploits. The LulzSec team used basic SQL injection and DDoS tools, not super-sophisticated. Anonymous – I think they recently compromised BART website, again, through simple SQL injection. It’s not rocket science. Why were they effective? Because there’s a lot of low-hanging fruit out there.
Dave: How long has SQL injection been around for? Thirteen years?
Kevin: Yes, years. And there are some in the industry that actually argue that pentesting is not valuable, like Marcus Ranum for instance. He argues that pentesting isn’t valuable, and I don’t agree with that. I think if these entities actually had tested their security ahead of time, probably the LulzSec or Anonymous crew wouldn’t have got in.
Dave: I guess it all goes into what they actually do to protect themselves. If they get a report that actually shows systemic weaknesses in their infrastructure that might be used to take down the company and compromise them, and they don’t fix it – well, that’s on them. But at the same time, it’s better for them to have that knowledge and actually fix them than not know at all.
Kevin: It’s interesting, because several companies have hired us to do security assessments; we package up the report, we find their vulnerabilities, and then what happens is they hire us next year to do the same thing. So what we do is we pull the old report, and you know what? 90% of the stuff isn’t fixed, because the only reason they are doing the security assessment is for compliance. They have to comply, whether it’s SOX, GLBA, HIPAA, whatever, and so it’s interesting because some companies don’t seem to really care much about security, they would just really care about complying.
Dave: And so, this is how we build our security programs (see right-hand image). It’s true, right? We don’t want to know, because we’re scared. We tuck our heads in the sand and we hide from them. We fear guys like Anonymous and LulzSec.
Kevin: Those guys actually were kind of cool – because of their activities, I have three new clients. So thank you LulzSec! Thank you Anonymous!
Dave Kennedy: We are the only industry that I know of who keep increasing their budget, keep increasing their capital expenditures, and continue to get worse. Oh wait, it’s been proven that it’s not actually accurate – weathermen are the first, and we are second. So I guess we are the second industry that I know of that continues to get worse.
This brings us to our point: we believe that penetration testing is partially the answer to fix the problems that we see in the security industry. Without knowing where your exposures or your risks are at, you aren’t going to be able to protect or defend against them. That’s why we came up with adaptive penetration testing. For us, security breaches are the best thing that can ever happen to a company. Take a look at Diebold – you sold these things off eight years ago or something like that, and they continue to be in the news. What that did for us, though, is it really put security into our entire company. I mean, our CEO loves security, he looks at it as an enhancement. I get budget, I get people, and I’m able to actually protect the organization. I’m able to do what I need to do in order to actually protect the organization. If we suffer a breach we experience significant pain as a company, and a company is generally not going to move on security unless they experience pain.
Kevin Mitnick: In fact, we get some clients because there’s fear in the media because of recent attacks, and also we get clients because they’ve been in compromise, so they go: “Oh shit, we got to do something about it,” and then they hire us to do security assessments or code reviews.
Dave: Fear is not always the best thing, but at the same time if you can represent how to actually systematically take down their company, it could be good.
So let’s investigate a real breach. Company A experiences a breach. Security up until that point was extremely difficult to implement. They leverage that breach, you actually communicate it, you can use that to your best advantage. Now, in stating that, obviously, you don’t want a breach to occur. But at the same time, that’s not the doom and gloom that everybody makes it to be. I mean, if you experience a breach, what company has gone out of business? I think in the history of breaches, some guy at ShmooCon did a presentation and did studies on this, and two people have gone out of business because of a breach, and one CEO lost his job.
And so, if you look at that, systematically we are not going to go out of business. You should leverage it to your benefit if you experience a breach. I mean, most of our first reactions are “Tuck it away”, “Make sure nobody knows about it”, “Hide it because I don’t want to get fired”. If you are doing your security job right and you’ve been preaching that your security sucks for the past five years, you should have a pretty good backing to say: “Listen, I’ve been telling you guys for five years this is what we need to do. Let’s make this work now, because we’re screwed, you guys feel pain, and I can fix it.”
And option two is a simulated breach, penetration testing. For us, maybe it’s not as effective as a real breach can be, maybe it’s not as good as a real breach can be, because they are actually experiencing pain when you do it. But the ability to simulate an attacker, the ability to actually go into a company and exploit them is going to be leaps and bounds beneficial to, obviously, happening in the news.
Kevin: And that’s one of the things we actually enjoy doing: when we take penetration testing jobs we actually only take the ones that allow us to do full compromise. So the client will give us, you know, what’s the target asset. If it’s a software development company, that’s source code; we’ve done ecommerce companies where it’s been their credit cards. And that’s the only ones we take because those are the only ones that are interesting. And then, one of the other rules that we set for clients is they can’t change anything as the pentest is going on. So if we find some sort of vulnerability that we have to report as part of our contract, we ask that they don’t share that with the IT team so they fix it, because it affects the pentest. But we like to simulate real-world type of stuff, we don’t like to stop at a particular point. So we are very picky on what ones we actually do.
Dave: Penetration testing isn’t the smash and grab that we are used to; it’s not firing off the scanners; it’s not running a bunch of exploits trying to barrage the infrastructure. I mean, it’s not the techniques that we are leveraging right now. It’s more than finding exploits, it’s more than actually going after a system and saying “I got domain admin.” It really has to hit the company where it hurts, and that’s the most important part about it.
Again, the reason why we wanted to go into this and give you a little bit of history behind it is because we truly believe that penetration testing is absolutely one of the founding things that can help a security program grow. And what we wanted to do is give you a perspective of how you need to look as you’re doing these penetration tests and what you need to think of. Think outside of the box, think of something that hasn’t been done. I mean, yeah, if you’re having a low-hanging fruit with SQL injection, that’s great, but leverage that for something else.
And so, the rest of this talk is story time. We are going to go through real-world scenarios that we’ve done in penetration testing that’s unique, something that hasn’t been done before, something that is unique in nature, something that might not be as crazy sophisticated or might be, but something that was unique that actually provided the value to the customer.
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.
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.
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.
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.
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.
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,
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.
Dave: What I’m going to show you here is a demonstration of that actual bypass using the Social-Engineer Toolkit and the Java applet. What I’m going to show you is the new version, version 2.1, which has been in development now for probably the past three months. I’ll talk a little bit about the new features later on, but there’s some wicked stuff coming out. I’m also going to be talking about something that I did which is currently being reviewed by the EFF, because I don’t want to get sued. So, once that’s actually okay and clear and I got the backing, I’ll talk to you about what that is.
Bypassing User Account Control using SET
So we have SET here (watch video above), and in the new version of SET I’ve incorporated Fast-Track, which is a tool that I came up with a few years ago that was meant for the automating of penetration testing. I have recoded Fast-Track from scratch. Fast-Track was my first Python program. Since I’ve actually matured at my age in programming, I wrote things that are actually multi-threaded and used the functions, reused code and stuff like that, which was relatively unique for me. So, that’s now incorporated in the new version of SET.
We select the Social-Engineering Attacks menu and we are going to go to the Website Attack Vectors. Then we are going to select the Java Applet Attack Method. And for me personally, the Java applet attack vector is by far the number one most popular attack that I leverage during an attack. The reason is I no longer really have to attack a browser bug or an Adobe bug or a Flash bug – when I’m going and exploiting those, you have maybe a small percentage of that actually being successful, unless you did a ton of reconnaissance ahead of time. The Java applet attack leverages trust. It’s not an exploit, it’s not a bug – it’s something that leverages trust of how Java is actually designed.
And so we are going to go ahead and clone a website, and we’ll do gmail.com. It could be any website you want to. What SET is going to do is it’s going to go pull that website down, rewrite the web page, set up a fake web server, do a Java applet and so on and so forth. In one of the earlier versions that I released – I think it was 1.7 – I incorporated what’s now called the SET Interactive Shell, which is a completely custom interactive shell that’s similar to what you would expect from Metasploit or Meterpreter but specifically customized and designed for SET. It does randomized cipher key exchange of AES-256, so you have AES-256 communications going back and forth each time. It randomly compiles and obfuscates each one in order to get around signature-based detection, and it has a bunch of tools built into it. And so we are going to select that, we are going to listen to Port 443, and it’s going to do everything for us. So now we have everything listening here.
I have UAC on here, you can see it’s set to its default value. This is a relatively recently patched Windows machine, the patch comes out every two days. So we go to IP address 192.168.235.129, and it’s going to load the Java website for us. It looks just like Gmail. Funny enough, if someone’s like “No, I don’t want to click on this” and they hit Cancel, then they go to type it in and can’t type it in, hit Cancel again, and it goes back until they hit Run. Then it actually executes it. It’s what we call the Java repeater: if you hit Cancel each time, it keeps re-popping up, so they can’t type in their email and they can’t even close the browser unless they kill it through Task Manager, so it’s really annoying as hell. So they are just going to click Run regardless, because they want to get the thing off of the screen.
As soon as they hit run, it redirects the victim back to the legitimate website and everything looks like it’s normal. Now, one thing that’s kind of cool – and this is what I’m working with the EFF about – is as follows: what happened a long a time ago when I released SET is you could do what’s called self-signing of the Java applet, so you could sign it as Microsoft or Google or whatever you wanted to. So the Java applet would pop up as “This is published by Microsoft”. They have since changed it to show just a big “Unknown” as the publisher if it’s self-signed. So you, basically, have a publisher with a self-signed certificate of big “Unknown”. Now, we saw from statistics it literally impacted SET zero – we still have a 99% success rate when sending this. But at the same time, it wasn’t good enough for me.
And so, what I did was I looked at how you actually get a valid certificate from the different variety of code signers, so I registered a company in the State of Ohio and then I bought a code signing certificate. And the name of that is “Verified Publisher”.
Kevin: My Company is called “Oracle Java Applet”.
Dave: You know, Kevin was worried about calling it “GoDaddy”.
Kevin: Yeah. I remember I was going to participate in the Social Engineering CTF at Defcon two years ago and they wanted me to target Microsoft. So I registered microsoft-test.com, microsoft-this.com, and then I got a call from GoDaddy: “Mr. Mitnick, we just found out you registered these Microsoft domains. Is there anything we can do to help you?” I said “No, no, no, everything is fine, thank you!” But they actually took it upon themselves to call and check, you know, because maybe I’m on their list: what’s he gonna register today?
Dave: And so, the proof of this, the reason why we wanted to do this, the way we do these type of attacks – it cost me $30 to register an LLC in the State of Ohio. It cost an additional $200 for a code signing certificate. Do you think an attacker is going to do that if they really want to target an infrastructure of a company? I mean, the process that you have to do it takes literally about five days. And it’s not hard work, you just submit the paperwork, which kind of sucks. You submit it and it comes back after the governor gets the chance to sign it, and then you go to a website, you fill out some automated; you have to put a fake website, so I got a fake website out there.
Kevin: So, even if you are spending a grand, it’s worth it if you are doing a real attack.
Dave: Yeah, it’s obviously beneficial if you want to actually go and target a company, so it makes it absolutely more believable. And that’s the whole point of a pretext or an attack against an organization – you want to make them feel confident in what they are doing. And so the Java repeater that just annoys the hell out of people and the actually trusted applet – people are definitely going to click on it.
Completion of the UAC bypass attack
So we went ahead and we clicked on Run, and over here on our attacker machine we have a new shell (watch video above). The SET Interactive Shell is multi-threaded, so you can get 50 shells coming at the same time, it holds as many as you want to. And here we are going to interact with it by hitting “1”. Now we are in the SET Interactive Console, which basically gives you access to whatever you need. So you are going to enter “?” (question mark), it tells you all the different types of things you can do, so I can drop a new shell and type in “net user bob ihugalot /ADD”. If you noticed, I get “Access is denied” message. And why is that? Because UAC stopped us, User Access Control prevented us from actually being able to add a local user account onto this.
And so, what we incorporated in the SET was “bypassuac”, where you just type “bypassuac {IP address}. So it’s going to do its thing. This took me so long to code.
Kevin: What’s scary is there’s only, I think, three whitelisted executables that are outside the system32, so Microsoft could easily fix it.
Dave: Yep. So if you see here, we get “Connection received from {victim machine’s IP address}”, we drop back out to this, and now we see an option 2 – we see Windows calling UAC-SAFE. Now we can drop into that, and we completely successfully bypassed Windows UAC.
Kevin: What’s interesting with your tool is, in a speaking engagement I’ll demonstrate Java applet, I’ll leave it run and then I get busy and I’ll fly home, and then I’ll go there and I realize, like, six or seven people (not at the conference) connected to the site and actually executed the Java applet, just random people on the Internet. It’s amazing! I should let it run for, like, a year and see what happens. I don’t want the feds knocking on my door, so never mind.
Dave: The tool here has a lot of things like list running processes, execute things; you can do SSH reverse tunneling so you can tunnel a port based on the internal port, reverse it back so you can connect to it locally. It can also be used to kill processes, reboot. It’s got localadmin, domainadmin, grabsystem so you can get privileges on the system, keystroke logging, keystroke dumping.
It also does lockworkstation, so you can lock the workstation while you’re logging the keystrokes and intercept their user credentials, which is one of my favorite ones. But the whole point isn’t to go through the SET Interactive Shell but just to show you how to bypass UAC. So, lessons learned from this – what have you learned from this attack?
Kevin: If you put your mind to it and actually prepare and you are meticulous about it, you are usually going to get in.
Dave Kennedy: Kevin, by far, is one of the most meticulous people I’ve met. I mean, for me it’s kind of a hack job, I’m like “Oh, this is cool, this will work,” I figure out things and I go ahead and do it. Kevin is like “100% this has to work or else I fail,” which is obviously a pro. I have ADD, so I try to do different things at times…
Kevin Mitnick: I think with enough of upfront preparation it’s really critical to be successful in this stuff. Or you can just throw stuff at it and hope it works, and get detected. And I don’t like to be detected.
Dave: Didn’t you do a physical part of this as well?
Kevin: Yeah, that was also a cool one. The client also wanted to see if there were other ways to get in besides social-engineering somebody over the telephone, so my next step was look up one of the facilities they had in Google Maps. I saw it was a pretty big building for this company, and I did a little bit more research and found out they just rented an office suite. Then I tracked down the realty company and I set up an appointment under the pretext I wanted to rent office space. So I had some business cards printed with the name “Pinkerton Investigations”.
I had a colleague of mine – actually, a friend of mine that’s in the “Ghost in the Wires”, my friend Alex – he used to do all this physical stuff with me back years ago. I said “Let’s go down south to where the company was.” We show up, we’re wearing suits, we have out Pinkerton business cards and we ask for the tour of the office space. And then I said “Listen, do you know we are a security company?” He goes “Yeah, I’ve worked with Pinkerton before on getting them office space when I was in New York.” And he asked me if I knew these people – of course I did, when I’d never even heard of them before. So I had the credibility and then I said “As a security company, we are really concerned about security controls of this physical building, so I need to know how everything works.”
So the realty guy told me all the security controls that were in place. Was there live surveillance? No. When the cameras were turned on, how would the alarm work? Basically, all the security controls that the building had, the perimeter patrol – how often did the security guard go around the perimeter? The doors were unlocked in business hours. They used HID cards to get in. And when we were walking around I saw they were using Schlage Everest locks. My goal was to find out the janitorial company – because a lot of these office suites combine janitorial services – that served as the client, because I thought the janitorial crew would be the easiest to convince to let me into the facility so I wouldn’t need a key.
So I ended up calling the janitorial service, trying to work out who the actual people are that clean the building. I wanted to talk to them because they are the lowest level. And if I could use caller ID spoofing, call from the office, maybe I could convince them “If these people show up, go ahead and let them in.” So I found out who the supervisor was and then I decided to change tack – I wanted to get home and I wanted to do this quickly. So I called the supervisor of the janitorial crew and I said we had a system crash in our building, and the access cards wouldn’t work for their janitorial crew to come in Sunday morning to clean. But we have a solution: I have a new card. So the whole idea was to drive out to the janitorial crew employee, to this one lady’s house, give her a new HID card that, obviously, didn’t have any credentials on there, and get her old one so that we could get into the building.
So, as we were setting this up, the supervisor calls me and says “We don’t use access cards to get into the suite, only into the building.” And he went on to tell me that on the janitorial door they had a little lock box, and in that lock box were all the master keys to everything in the building. So I go look and, lo and behold, there’s this lock box, I jiggle it and I hear the keys, but it’s an Ace II lock, and those are the hardest to pick. I called my friend from Amsterdam and I said “Hey, I got this Ace II lock, what tool do you suggest?” It was a tool sold by Peterson International. I found these great guys that actually do some work at Defcon in the Lockpicking Village, and I said “Hey guys, I need you to come out and help pick an Ace II lock.”
I set one team on the lock, and the other team to actually pick the suite door, because it was kind of a trap door and, again, it was a Schlage Everest lock, so it has a security pin in the back. And they were actually able to breach the suite door before they were able to breach the Ace II lock. We got into the suite of the client and we realized all the administrators had secondary “locks” on the doors – they put their trash cans outside their doors, so even if I got in with the janitorial crew I would have been stopped at that point. So it was good luck that I decided to go the lockpicking route. It didn’t take long, they picked those locks as well and we got all the way into the server room.
In the server room they had a nice post-it note with the administrator password, which was helpful. I took a picture of it and sent to the CSO. I said “This is a bad idea.” But they felt secure because there were so many doors to go through. We actually found the machine that made the access cards and made our own, so we had full access to the building. And then I found out who the administrators were and rebooted their boxes to a USB tool so that we could, basically, set administrator level password and install encrypted Meterpreter shells. We used task scheduler to connect every 30 minutes.
What was cool about this attack is, because the building management was being so helpful and letting us know about the security controls and especially letting us know that the clients did not have alarms (there was just alarm on the main structure), we were actually able to duct tape the lock. So after we left we were actually able to walk back into the building to do more reconnaissance before the real attack. So this was kind of a cool attack, because it was going in, physically doing it, doing some lockpicking and owning their entire infrastructure that way.
It was extremely successful, and they never detected it. I think about four weeks later I asked them “Did anyone report anything suspicious or anything going on?” And they go “No.” Then I said “Well, do me a favor, the Linksys access point in this office – go ahead and unplug it from the network.” Then the realized they were hit, because I wanted to wait a while to see if the attack would be detected, and it never was. I think that’s important, too. It’s not only “Did you get in?” It’s whether or not the IT staff or the security staff realize there has been a compromise once you get in.
Dave: The next one is Company 2, which is malicious media. This actually happened this month. It was an engagement that I was working on. It’s a Fortune 1000 company. The customer requested to deploy malicious items through parking lot (see right-hand image). We’ve gotten those assessments before, where the customer wants us to drop a malicious USB or DVD in the parking lot and see how many people pick it up.
Well, we wanted to do something different because those were getting a little boring for us. How many times have you seen an RFP that says “You must do it this way”? So, we were bored with the standard deployment and we decided to do something a little bit different. I went and scoured the Internet for the most expensive, fancy keyboard that I could find (see right-hand image below).
And who wouldn’t want this thing? This thing is awesome! It’s got lights and stuff, and it’s an IT person’s wet dream. I mean, they can do some major gaming at lunch time on this thing, right?
And what we did is we sent this keyboard – modified, obviously – to five IT folks in the actual company itself. And this is where we talk about “The Teensy Attack”. A Teensy is this little device right here (see left-hand image), it’s a computer chip. Here’s a couple of different ones out there (see image below).
And I have to give a special shout-out to Josh Kelley, because his research has been instrumental in a lot of the stuff that we’re doing here. He’s also got a talk on Sunday, where he’s going to be releasing some extremely cool stuff that will literally blow your mind because of what you can do with it. So, Josh, no pressure.
What we did with this is we coded the keyboard itself to do an in-line attack (see left-hand image). Essentially, when you hit a key on the keyboard, the Teensy detects it and then propagates that key out. So we can actually start to detect when someone is actually there, right? What happens is, when it doesn’t detect somebody there it moves the pixel of the mouse up one into the left. You don’t notice it on the screen, but it keeps the screensaver active. So, after about two hours of inactivity you know that person is not there and you can drop your malicious payload onto it.
And why that’s important is, this thing is recognized as a keyboard. You can change the vendor ID and product ID to whatever you want to and see if you can make it that manufacturer that we bought the keyboard off of, and put it in there. And why is that important? Because it disables autorun, there’s no autorun capability. If you have autorun disabled, it’s still going to execute because it’s recognized as a keyboard. The Teensy devices have on-board memory storage that can emulate keyboard typing, and I’ll show you that in a second.
And so, during off-hours we deployed it. This is actually really funny, because we got nine shells (see right-hand image). We only sent it to five people. My only guess is that the IT guys got jealous and ganked it from the other person, which is what we normally do in IT, right? I mean, if it’s out there and it’s cool, we take it. And we got nine shells, so jokes really on them. From there we further penetrated the network and got further access, and I’m going to show you a demo of this (watch video below). This is all available in the Social-Engineer Toolkit.
The Teensy attack deployment
Essentially, you just go to SET, then you go to Social-Engineering Attacks, you go to the Arduino-Based Attack Vector, and you select what attack vector you want to do. It has some of the X10 stuff that we’ve been doing with jamming, which I’ll talk a little bit about. And my favorite one is deploying a binary via the Teensy attack. What’s cool about this is you can actually drop a binary onto the system and have it convert back and run a binary. So, if my demo works, we should see some magic typing happening here, no hands. What’s happening here is it’s deploying a payload onto the system using a hexadecimal representation. So what we are going to leverage is PowerShell to reconvert our hexadecimal representation of our binary back to a binary again. What’s cool about his one is I leveraged a tool called Shellcodeexec. If you’re unfamiliar with Shellcodeexec, it’s just an executable, where you can give it a second argument parameter that’s alphanumeric shellcode, and it shoots Meterpreter string into memory. So it never touches disk.
In this case – you are going to see it convert here in a second – we are going to do our conversion, here it goes. This took a long time to code, by the way. My wife hated me on this one. So we execute and, lo and behold, now it’s generating the alphanumeric shellcode, it’s going to stage everything into hexadecimal representation of it. It’s going to create the PD file through Arduino. You can see the Arduino stuff right here, this is all the code.
Kevin: I remember when we were testing this, and I was testing this on an Acer One. The timing on this thing was crazy. Dave and I had to spend, like, a few days with the timing on it. It was just funky.
Dave: Yeah, it was typing way too fast for the actual computer to handle. Usually I have that problem whenever I’m typing, it can’t handle me. What’s cool is we did a modification to the Teensy device, which I don’t have one with me right now, but Josh ended up soldering an SD card onto the Teensy device, and now you can do native SD storage on the device. Why that’s important is, when you plug it in, it doesn’t recognize as a storage device, because the Teensy actually natively reads an SD card, so you can store as large of a binary as you want to on it and then copy it up.
So you’re not restricted with the characteristics you would have when leveraging the Teensy device. So we go back to our attacker machine here, there’s the Meterpreter shell.
Lessons learned from this: we decided to do something a little different, and we had a lot of fun doing it.
Dave: We have a little bit time left, so Kevin do you want to fly through this one? This is the external and wireless penetration test (see right-hand image).
Kevin: Oh, yeah, a company had us do a wireless security assessment, but also it was a web app assessment.
And through SQL injection we were able to breach the external web servers. And so, using a tool – Jason Geffner wrote the whitepaper on the tool – we were able to export the private RSA keys (see left-hand image). Based on this whitepaper, actually, he had some code that he released that lets you export the private keys to the certs, so, basically, steal the web server cert. And because this company is running one of Cisco’s wireless products. What we realized is, since they had their own CA, they loaded their own cert onto the Cisco device, or actually onto the box that was doing the authentication. And we realized that this cert was signed by the same root CA as the web server cert.
So we stole the web server cert and were able to leverage that to create a rogue AP to get clients that would connect to the network through certs (see right-hand image). We were able to leverage that to get them to connect to our rogue AP and then exploit them through our client-side exploit. So it’s kind of cool: you steal something from one location and you leverage it somewhere else, and there are no scanning tools on the market that are going to do something like that. It just takes human knowledge.
Dave: If you remember correctly, when you penetrated that server you ran into a lot of dead ends. I mean, that was really a locked down DMZ
Kevin: Yeah, we were like “Okay, we’re sitting on the DMZ and we’re trying to get to the internal network.” Basically, everything was blocked (see left-hand image). It was taking too much time. So then we had to figure out how else we could get to the internal network and we thought “Well, let’s just steal the cert and the private keys, create a rogue and then have clients associate to it.” And it worked. It was very simple. A little bit of debugging, but it was easy.
Dave: Company 4 – this is for powerlines (see right-hand image). At DefCon, we released a talk called “Pentesting over Powerlines”, which leveraged an attack against home automation systems and controllers-run X10 devices. And so, we were doing a physical penetration test against an armed guard facility. When we started doing reconnaissance of the systems we took pictures of the camera system, the people entering the system itself, and looked at the brand names and the X10-based controllers that they were leveraging for the systems. They were using powerlines to communicate those devices and transfer data over in those different routes. We decided to be kind of unique on this.
After researching the brand names, we decided to attack X10-based controllers and see what we could get with it (see left-hand image). So we started doing some work, and I have to give a shout-out to Rob Simon because he, really, was instrumental in creating all of this.
Here’s the X10 Kit that we were leveraging (see right-hand image), and Rob was testing this device right here – some lights and the actual device itself, you can turn it on and off with different things – you know, it’s home automation. It’s the same thing that these security systems were leveraging.
So we decided to create a jammer (see left-hand image) to jam the devices so that, if we were to go into the facility and start attacking it, there wouldn’t be any type of alarms going off and everything would be, basically, blacked out.
We started with an Arduino-based device (see right-hand image), and we started to go a little bit smaller.
Rob started modifying the TW523 (see left-hand image), so we started soldering it into the home automation device. We are not any type of electrical engineers whatsoever,
so we fried that one Teensy and many more until we figured out what we were doing (see right-hand image).
All in all, we had a product that we ended up fixing, which was this guy right here (see left-hand image). Essentially, this device right here is what we call the “blackout jammer” for X10. It is a modified Teensy-based device. What you should see is, if you were able to go to external plug on the outside and plug this, you could jam the X10s so that they wouldn’t be able to communicate. Now the X10 is inoperable, and if I try to turn it on and see what’s going on – nothing, it’s dead. Once I take it off, the device pops back on.
So, what we were able to do is we did a night-operation, we disabled the security systems, we lockpicked the back entrance door, no security alarm ever triggered, and we had full access to the infrastructure, so from there we were able to go on and do everything we wanted to (see left-hand image).
Again, what we wanted to get out of this was to be creative, do something that hadn’t been done before, do something unexpected; to be a hacker, right? So, instead of giving the customer a 400-page report, we decided to do something unique and had some fun with it (see right-hand image).
Dave: Now I want to go into the Social-Engineer Toolkit 2.1, which is getting released today. I’ll upload it, probably, tonight when I maybe don’t sleep or whatever. It’s 27 new features, 22 bug fixes, 18 enhancements. And usually the bug fixes actually outweigh the features, so I’m actually getting better with coding this time around. I just have to say I’m proud of myself on this one. Fast-Track is now a part of it.
Useful features of The Social-Engineer Toolkit demo
Just a couple of cool things I want to show you real quick (watch video above). Oh God, that is not a bug. And I just got to give a shout-out to the SET development team. It started off with me, and Jerry Dupree and Joey Furr joined the development team, as well as Thomas Werth. So we actually have a development team working on SET quite a bit. Poor Joey, man – I go through and I just stream through code and I do a bunch of stuff, and he goes through and fixes it, so I got to thank him for all of my “good” coding techniques that he doesn’t like.
And so, in the Social-Engineer Toolkit one of the coolest options is we’ll go ahead and we’ll do the Website Attack Vectors, and then we’ll do the Java Applet Attack Method; we’ll go and clone a site, just like we did last time, and a new option now is option 13, which is ShellCodeExec Alphanum Shellcode. Why that’s important is I rewrote the Java applet to now drop a Meterpreter stage that shoots directly into memory through alphanumeric shellcode and never touches disk, so we no longer have to worry about antivirus.
The options you have is you have reverse Meterpreter, reverse TCP, you have reflective injection, reverse HTTPS stager, and you also have the standard reverse HTTP stager as well. So you can use either one of those, all of them work now.
And so, it’s going to go and generate it for us; we are not going to create another payload. And, by the way, the Java applet targets Linux, OS X and Windows, so no one is safe. So we go ahead and do the Java applet thing again, it loads Gmail, we don’t want to hit Cancel on the popup because we already know it jacks us up, so we hit Run, it redirects back, and now we got the Meterpreter shell. No need to worry about AV. So, that’s one of the features.
One of the ones that I did a long time ago was the MS SQL thing, which is one of my favorites. Obviously, when you install SQL you have the capability of having SA password, if you use mixed mode or just SQL authentication. And one of Fast-Track’s attacks was this type of attack, where we go after an actual SQL Server. This supports CIDR notation and this supports single IPs. But I guarantee, if you’re going through a large customer, you’ll always find a black SA password. So just scan, look for it.
What SET is going to do is look for 1433; we are going to use the default wordlist, we are going to use “sa”, it found a port open and it automatically brute-forced it. I spent a lot of time on tuning performance on multi-threading and brute-forcing, was able to get that through. And you can see on number 1 we have 192.168.235.131 was using username “sa” and password “password123”. We drop into that, and we can either leverage Windows PowerShell or use Windows Debug Conversion, which will, basically, take our binary out. It looks really cool.
And so, I’m going to go ahead and do Meterpreter, it’s going to code and do odd stuff, and now it’s going to deploy our initial stager, which is all going through MS SQL at this point. This is hexadecimal representation of our initial stager payload. And why this is important is, with Windows Debug you have a 64K restriction, and Meterpreter shell is going to be a lot larger than that. It will actually take a stager payload that, essentially, just reads in raw hex and writes out binary. And so, we can, essentially, bypass the 64K restriction on Windows. Now I’m going to go ahead and trigger the payload – and I got Meterpreter shell.
This is just one of the many features in the new version of Social-Engineer Toolkit that will be released today. Again, I’m not releasing the Java code signing one as of yet. It is definitely there, it’s ready to go. I just want to make sure that I’m doing everything legally to it.
So, what we really wanted to get out of this talk was, again, just to make yourself think creative. You know, think outside of the box when you are doing these penetration tests, do something unique, do something that hasn’t been done before, do something fun. I mean, the traditional scan and exploit type of penetration tests are not doing any type of value; it’s not we are designed to do as a field. Kevin, do you have anything that you want to say?
Kevin: I really enjoy doing it. I encourage people to think creatively and be innovative. We do use scanning tools, but that’s kind of initial footprint type of stuff. I could run Nmap and look for any low-hanging fruit, but that’s kind of the very initial stages of a security assessment, very initial stages. And then we go on from there. I wouldn’t stop there. And I’m sure a lot of you don’t stop at just simple scanning, I’m sure you guys do a lot of more in-depth pentesting. But you never know, because, again, I’ve dealt with clients that showed me passed reports, and it’s like a 400-page report that doesn’t have much value, that just repackaged information from an automated scanning tool. So, that’s pretty much it.
Question: Kevin, would you demonstrate your famous whistle?
Kevin: I actually recorded my famous whistle. Do you mean the one that launched the nukes? Today I’m not really good at whistling, but hold on… Let’s see if I have it, it’s funny as hell. Here we go (watch video below). That’s my famous whistle.
Kevin Mitnick’s famous whistle
Dave: Thanks everybody for coming! We appreciate it!
