 So, I'm Val Smith. I run attack research. I do a lot of stuff with the metasploit guys. Woo, metasploit. Spent a lot of time researching attack techniques, what real attackers are actually doing, do some break-in into computers and developing exploits and all that kind of stuff. You might have seen a few of my talks before. I pretty much talk about a completely different topic every single time, and this is going to be no different. Is this on? Oh, my gosh, it is. I'm Colin Ames. I work with this character. Do security research, hopefully metasploit development a little more, and general nonsense. Closer to the mic. Hi, I'm Dave. So I've done security research for the past 10 years on various things, bouncing around everything from writing installation for drivers to doing malware reversing. Yeah. All right, so we're going to talk about spearfishing and a few tools that we developed to do that for pen testing, basically. Working on some standardized tools to run on top of or in conjunction with metasploit to do this sort of thing. So we're going to start off with some file fishing stuff, talk about some web things that we were working on, Tor, that's going to be crazy. All right. So why spearfishing? Well, this is the way that people are actually getting in now. Back in the day, people got in with buffer or flows, remote exploits. They find some port. They send their payload at you. And really, with firewalls and everything else that people have implemented, that's not as prevalent. People are sending emails or they're directing you to websites, all client-side type attacks. And they're blending a whole bunch of different types of attacks together. Like, they'll have a malicious website combined with a malicious document, which then sends you off to some malware and the social engineering component to trick you into doing these things. So they're blending these attacks together. So those of you in the audience that are pen testers, how often do you get to do fishing attacks against your customers? Anybody who does it frequently? A couple. All right. All right. That's better than none. If you're not doing this, you're really missing a major vector. Like, one of the big threats to your customers is that they're going to get hit by spearfishing. And so if they're not letting you do this, then you're missing out. So it's because of this kind of thing that I think that the security industry as a whole is sort of failing right now because we're not actually testing what real attackers are doing. We're sitting there in the boardroom. We're doing our little pen tests and our scans, and the attackers are like hitting it up. We're going to hand them a checklist of here's your highs and your lows and your mediums, and this is what you should do once you got a patch, and the attackers are blowing them up. Now, Val is a very calm person, but we really want to hit this home. This is what you should be doing. This is how bad guys get in. This is how you hack things. All right, so one of the things that we've been seeing that's pretty prevalent out there is that there's a lot of these web kits that are designed to do this sort of attack. Russians are doing it. A bunch of people are doing it. M-PAC, Tornado, LuckySpoit, these are really sort of common web kits that deploy exploits to the clients and the browsers. Now, if you're a pen tester, you will try to find these or download these, but who knows what's in them? It could be anything. It's an uncontrolled environment. A lot of these are backdoor, meaning that you get a shell. Somebody in Russia gets a shell, too. So you don't want to be introducing that into the networks that you're trying to test on the up and up. The other thing is that there's a lot of file format exploits coming out, especially PDF exploits. And these are sometimes getting built into the frameworks that already exist in the Metasploit or Core Impact or whatever. But a lot of them sort of have the same problems that web kits have in the sense that it's not really well understood what's in them. A lot of times, they just pop up a blank PDF that crashes. It's hard to target those. And there's not a lot of knowledge out there about reverse engineering file formats. And so our solution to this was, we're going to go out and we're going to figure out what bad guys are really doing when a reverse engineer or take those techniques and put them together in a sort of standardized, modular way that people can use and trust and know what's in it, open source. So the sort of workflow that we've come up with to do this kind of work is that we thoroughly recon the target first. We figure out everything we can about who they are, what they do, what their business is, how they communicate, and then build a legend for our tech, meaning what are we going to pretend to be? Are we going to pretend to be a vendor sending them a spec sheets for whatever they're trying to buy? Are we going to pretend to be their editor for their newsletter? So we want to look for documents that are plausible from them. We're going to build our vector, meaning is it going to be a PDF we're going to send them? We're going to redirect them to a malicious website, email, whatever the vector we're going to choose for this attack. And then we're going to send it off and see who we get. So that's on the attack side. On the back end side, we've got to have sort of our own infrastructure to handle this stuff where I need a server side exploitation system, something that can handle all these clients coming in. Because when you send out a fish or you send 10,000 people to a website and you're going to get a bunch of shells and how do you handle all that? You can't just manually do one at a time. And also, one of the things that attackers have to worry about is if they have a firewall, how are we going to bypass it? Are they doing egress filtering? What ports are they allowed to send out? And so there's some upfront work to do there. For example, inject your payloads until browsers are already authorized to get out through the firewall or get out through the proxy. And then you're going to want to automate stuff because when you're dealing with hundreds or thousands of shells, you don't want to have to, OK, this shell, I'm going to type my commands. This shell, I'm going to type my commands and dump my passwords. You'll never get done. A lot of times on pentesting engagements, you've got two days or a week or two weeks. So all this stuff is kind of complex and needs sort of a framework to work in. So I talked a little bit that client side is sort of the new paradigm. You're hearing a lot about frameworks these days. This is sort of the direction people are going. And phishing is really the client side attack facilitator. That's the way you get drive people. If you're doing targeted stuff to whatever your exploit is. There's a lot of tools out there, but a lot of them are manual or standalone, with the exception like browser auto-pwn. You could go get Core Impact, which has some of this stuff in it, but that's a lot of money. Not everybody can afford that. But pentesters really need something that's standardized, that they can control and understand and prove to their customers that it's safe, that they can automate and customize their attacks. And really, one thing that's left out in a lot of these tools is the concept of targeting. How do you target who you're going after and make it look plausible? All right. So targeting specifically, you have to break it down to a lot of different pieces. And most of this is heavily influenced on the talk that Val and HD gave while back tactical exploitation. And it sort of goes back and forth to that. And it's very, very focused on social engineering. It's driven by social engineering. How do we socially engineer that user, that weak link on that network to get us in? And that's really where we're going to push it to. And it requires a lot of steps. And you have recon. You have to take that recon and derive it down. And it is still it into something that's useful that you can then re-implement and use to actually get in. So the first thing that's really, really useful that we're going to talk about in getting more depth here is file harvesting, file hunting, that sort of thing. And this is really as simple as googling, creative googling of companies' website and finding out, well, what PDFs you got? What docs you got? Let's see what you're putting out there. Or is your quarterly statement there? Is your bi-weekly newsletter there? Something that'll give me insight into your network, into the way that you do things there available. And so, of course, the first thing is to find all these documents the best way you know how. So googling is always a good bet. There are other search engines we like to use as well, so that's useful. And then you have to step it down. First part of file harvesting as well, hey, why don't you read the document? There's amazing things you can find on documents. There's scans every once in a while that we get, usernames and passwords, I believe. But more importantly, you get a feel for the social engineering aspect behind it. What are these users expecting? Do you see a lot of newsletters coming out? Do you see a lot of product discussion? Do you see forum posts, this sort of thing? And so, the documents that you can grab from their network openly from the internet gives you great insight into all of this. And then, of course, you can dig a little deeper and start scraping metadata. Word documents are great at this stuff. They store everything under the sun. And even PDFs are pretty good at this as well. So you can get names, email addresses, numbers. In fact, even operational details, such as what OS are they running, what software, what patch level. And so that's how you kind of dig deeper and deeper. So as tactical exploitation talks about specifically, you need to understand the infrastructure that you're attacking. You need to understand what your scope is, what the paradigm that you're shifting towards. And really, how you do this is enumeration first once you're out there on the internet and you're pushing forward and you wanna see everything that you can find. And there's a couple of different ways in vowel cover, I think, a bunch of it here. And fairly good light, I hope. And you just sort of step through it, step through it. Now, the good stuff that vowel will get into here shortly is bots versus browsers and other proxy logs and that sort of stuff. And it's just great information. All right, so one of the things when you're going after your clients is how do you know what their internal addresses are? How do you know where their web traffic is coming out of if you're gonna target it? You know, you need to gather as much information about the target as you can. A lot of times you wanna do this in a passive way so they don't know you're coming, they don't see you. One of the things that we've been looking at is the fact that a lot of sites out there have proxy analysis logs, which are sort of the reverse of web server logs. These track all the stuff that clients are doing as they come out of a network and provide a web interface so you can look at that data. And, you know, for example, up here, it's hard to see, but essentially this gives us a list of internal behind the NAT IP addresses and a couple of hosts. This is another example of a proxy analysis logging tool. This is some Russian site and it gives you the user IDs of the users and the traffic from when they're surfing the web. So now we've got some users to target. We know their internal IP address range. We haven't done any scans on their network or sent them anything. You can find cool stuff like this. I think this is in the Ukraine. This basically tells us what antivirus they're using and the fact that they update it and how often they update it and the dates of when they update it. So we know, okay, well, if we're gonna target these guys with a fish, we better be able to bypass Kaspersky because they're running it and it's up to date. So some of the cool things that you can also look for in these logs is crutches of individuals who are on a network. So it's been once or twice that we've seen there and seen them going to porn sites. Gives you an idea of what they're looking for. Every once in a while you can find them clicking on spam so you can go find the spam and these guys are nice guys to go fishing after. Yeah, if you see a guy that goes to Suicide Girls every day, then you know, okay, I'm gonna send him a Suicide Girls update email with, hey, here's some new pictures or whatever. And then you see stuff like this in these logs that tells you, oh, they're running Windows because they're going to Windows Update and they update rather frequently. The next thing is like, okay, well, if we're gonna target people, we need to know what IP ranges that we're dealing with and which ones are their web-hosted company IPs and which are their internal network IPs for their company. And one of the ways to do this is, well, you start off and you look at the domain name, we pick some random Chinese domain to play with, you get one IP address. So if you go searching through news groups and mailing lists for people posting from that domain, you'll actually find other IP addresses in the headers which are often their corporate internal network. It's where their network is. So attacking their web host may not get too far but attacking their actual network may be what you wanna do. So this helps you target that a little bit better and you look it up and it's owned by the same people, it's in the same country and all that stuff. It's just an IP that you may not have known about. Bots versus browsers is awesome for this too. Once you get these kind of IP ranges from proxy logs or from mailing lists or whatever, go look them up and you can see the user agents without ever having to get them to your site. You just go and see, okay, well, they're running Firefox on Windows XP or whatever. So the next piece, we briefly spoke on it earlier and then we've covered a lot of this targeting for network information and that sort of gathering. Now we're gonna dig a little deeper into the network and find specifically for files that we're looking for, files that'll get us access, things that are useful. So here's a newsletter for a phishing site that talks about phishing, we like this. But in general, when you're looking at these or targeting these networks in general, there's a lot of information to be gleamed and the useful stuff that you see oftentimes is, oh, well, we just went to this conference or we published at this conference or you have speakers or you're hosting this conference. So updated slides, always good, you know, newsletters. Hearing vibrations. And I mean, and so when you dig through these things, that's what you're looking for. I mean, and then it's, you know, you dig, dig, dig and now we get to the good stuff. So what we really wanna do is we wanna find a PDF in our particular case here. We picked PDFs for specific reasons that we'll get into here shortly and we wanna infect it. We wanna create it as our payload to get into their network. And then there's lots of reasons for this. PDFs are probably the most prolific document format there is out there right now. And I think you can take all the others and add them together and they still don't equal up to how many PDFs you can find just by doing a simplistic file type search on Google. It was, you know, I'm not really, really big into that sort of number, but that's how I've based a lot of this. And people generally seem to trust them. They also have lots and lots of features. So first, you know, we have to find a PDF. So here's some general stuff. Now, there's an interesting thing in, you know, a little Easter egg in the corner here. Can we see something that's wrong? Val's a good guy and all, but sometimes he forgets to log himself out of Gmail when he's, you know, searching for things. Now, this doesn't necessarily tip them off that you're looking, but, you know, that's leakage. That's information leakage that you didn't need to do. So be careful when doing this sort of thing. Yeah, you might hit some site that's already been hacked by somebody else and then screw your Gmail account. So here we are. We're kind of going through, and you know, we come across this PDF. This one looks fairly interesting. You know, it's a newsletter and it's about a conference that's ongoing and so forth. And here's another thing that we want to point out here specifically is again, Val has done something wonderful that I always love to see is people opening PDFs in their web browsers. This is great. I love it when you do this because it elevates my PDF to run with full access. I don't have to ask you permission anymore to, you know, launch cmd.exe or, you know, do all those other fun things that I really like to do that we'll talk about a little later. So as we keep going down, we go down to, you know, you're reading. Here we are. We're just reading now. And you know, we can see here that we have the person that writes this newsletter and distributes it. And you know, we can follow it up here and you can see in the corner we have another follow-up Google search that shows you who it is, who the editor is. So now we're getting a good target list. And now we want to find, you know, cross-correlation. We want to see sites that trust this, leveraging, you know, what do we, who reads this? Who's interested in this? Who are they partnering with? And you know, because this could give us more attack structure, more vectors to enter from. And so, you know, continuing on and just digging a little deeper, looking for email addresses. These are good targets, good targets. Keep going. And you know, you continue and look for those relationships that can maybe be leveraged at a higher level than ones you've already found. And so you just sort of keep structuring it further and further. Yeah, so this helps you decide, okay, well, I want to send this newsletter from Organization 8 or Organization B because I know they have a relationship and they're using the same content and something you might expect or trust. So the actual, you know, specifics of PDF infection. Now so, I mean, I'm talking about infection. I'm gonna take ready-made PDFs that are valid information, your information, information, you read information, you provide it to us and I'm gonna infect it with a payload. It doesn't destroy the information. In fact, the information is still there and there's some wonderful features about PDF that makes this amazingly easy. So, as you've heard, I'm sure in the news and other things, you know, PDF has got tons of features. Adobe, I love them for this. They love features. Gosh, everyone wants to have flash in their documents. Everyone wants to be able to view a web in their documents. Hey, why not have a document launch commands? That's wonderful. So, you know, we have just tons of vectors in PDFs that we can leverage and these are allowed, this is a feature of the document format itself, not even a vulnerability or an exploit. This is just what's built there given to us, say, hey, go ahead and use this. Functionality is great. You know, and again, PDFs work all over. They, you know, they work on Linux, they work on OSX, they work on Windows. So you have a wide range of targets that you can use with just one file format. And again, we like to believe that they're trusted. We'll see how much people continue to trust them as we go on, as things we keep picking on PDFs quite a bit. So, there's been a lot of good research out there. I want to throw up some of these names. These are good people to go looking for if you want to learn more about PDFs, about the structure of them, about attacks on them. You know, and so these are good places to go and there's some great code out there that does a lot of what we're going to be talking about, but then they're, and most of the stuff is structured at how do we analyze PDFs from malware and that sort of thing, and that's kind of where we're going to try and set ourselves apart is we're interested in attacking with PDFs, although a byproduct of this, of course, is that yes, I can take apart a malicious PDF and tell you, you know, what shell code is it using, where is it beaconing to, so on and so forth. But that's not really our primary goal. So the attack basics specifically for PDFs, you know, we have vulnerabilities and we want to turn those vulnerabilities into exploits. You know, you've got JavaScript. Those are prolific. There's, I think, six or seven, at least, you know, overflows in the actual JavaScript interpreter for Adobe and specifically in Adobe Reader. And, you know, you've got Flash. I mean, it's just fully-featured things. I mean, if you fuzz this, you can get information and you can get, you know, good results. And, you know, of course J-Big, these are filters. A filter, you know, in a PDF is just a way of displaying information or translating it from one medium to another. I think Puscat was telling me that she fuzzed for about 10 minutes to find the J-Big exploit. And so then you start leveraging design features on tops of, you know, vulnerabilities for your attack and that's what we're gonna actually do specifically for, you know, our infector. So, you know, the deep mechanics of this is when a PDF is opened, it parses through lots of objects. And of these objects, you can get, you know, varying results of what you can and cannot do. Useful ones are open actions. Open actions take you to other object groups that can do things. Open actions are always associated, or not always, but mostly associated with malicious PDFs and so forth. But they're actually also legitimate uses. If you have an index of, you know, 40 pages and actually page number one is number 41, you have to use an open action to hop to page 41. If you wanna open page one when you view your PDF. So this is controlling content, the way the content is driven and viewed by the actual PDF reader. And so we wanna use this, we're gonna leverage this to kind of point it to where we have bad things to go. The next is you have additional actions which is AA here and these are all object types in PDF, which can then go further on. And the open action that we're using, you know, we're gonna use something that calls CMD and it's very, it's interesting. So you go through and you have all of these features that you take, you basically overload and use to base your attack. And so the most important feature here is PDFs have a wonderful thing called incremental updating. Incremental updating is that you leave all content in the PDF in place and anything that you want to change, you just add to the end of the file, you just append it. You just put it at the end. At the end of, you know, a PDF file, you have end of file as we see here and then you just start adding new objects or overwriting objects. I don't have to change anything on the PDF to infect it. This is wonderful. So this leads us to our, you know, our actual Metasploit module and so what our Metasploit module does is you pass it a PDF that you found that you want to infect. It then will infect it with a Metasploit payload and it'll launch it. So let's see how the demo gods like us today. All right, so what he's doing is loading up two console, Metasploit consoles with resource files that do the multi-handler, which is going to catch the cells coming in and then his PDF stuff. So if we could show it here, set up. So, you know, we were showing the PDF that we saw earlier, this SDIAP v2 and 4. Now an important feature of the actual module in this particular case is that we want the file name that we're going to create here to be very, very similar, but not the same and I'll explain this in a second. And this is more or less, you know, we could make it a random file but random files are strange looking. Normal users don't open random files. So, well, that's not true, but we're really trying to, you know, play to their side of the coin here, so. So make sure you name it exploit.pdf, so they open it. Oh, they love exploit.pdf. And another thing that I want to point out here is this is not a vulnerability. This will work on every single version of Adobe till the end of time, unless they change functionality of PDF, which I don't actually see them doing, to be honest. Don't have it in temp? So Val told me he had set this all up, but he lied to me. He did not move it to temp to make our life easier. It's okay, it's okay. I wished hab complete worked on Val's VM. All right, maybe now it'll work. If you spell re-exploit, correct. Ha, ha-zah. So as it goes through here, we just see it, you know, we picked a payload, we used a mature to reverse GCP, nothing fancy. And then just, it spit out a new one in temp, which is our other one. And then that load it up into a, we have a web directory for that. Let Val log in here so I can own him. Do you wanna own yourself? Do you wanna click through it all? Sure. I'll own myself. Hopefully. It'll eventually log in, I promise. You know what, this is wrong. Let's own Root, Valsmiss or Wuss. Because Valsmiss is a good guy, he uses a, you know, user privilege separation, he never runs as administrator. All right, so what we're gonna do is we're gonna connect to our, you know, we're gonna assume that you're connecting to a web server that's hosting up this PDF and we're gonna hopefully launch it. And you can, of course, attach this to an email that you're sending in, which is the more traditional vector that we use. So here we see it opens the PDF and it immediately asks him to save the same PDF he just opened. That seems a little odd. So actually what it's asking him to save is our actual payload. And then the next thing he kicks up, that's CMD, it asked him to call CMD. So let's go check other VM and see what happened. Hopefully something. We got a session. All right, so basically what happened when we opened that PDF is that we got owned. Do a hash dump. Say what? Actually. It's all the same. The newer versions of Acre Read on Linux, I haven't checked it recently on OSX, but Linux will not call commands directly anymore since version, after I think seven, the eight version will only call the default web browser, which is generally Firefox. So of course you can do other interesting things like call Firefox exploits through Adobe, but we'll get to that later, maybe. All right, we're gonna crank because we wanna make sure that there's time for all the other most weight track people. So we're gonna jump into the next piece, which is web phishing. Now the idea behind this is that you wanna direct your targets to your website with some means, whether it's an email or you hack their website and put your stuff on it. And then Egypt give a great talk about target enumeration and we're gonna talk a little bit about that from a more basic point of view. This is stuff you can take home and play with and figure out how to do yourself. And then the next thing you wanna do is social engineer is targeting and believing that everything's okay, nothing bad's happening to them, and then execute code on them using some social engineering techniques we're gonna talk about. Then you gotta handle your access just like we did with the PDF and then automate your post exploitation activities. All right, so I sort of have some really general stuff and a lot of this is taken straight from how real attackers do their web kits. But I did it in such a way that at least you can understand the code, it's fairly simple and you can use it without thinking I'm gonna backdoor it. So we wanna do OS detection and IP detection, figure out what browsers they're running and then make a decision on okay, well if they're running this OS and this browser we're gonna send them over here. Similar or long same lines is a browser auto pump. We got some decloking stuff and then some sign job applets. So in general what we do is we sort of built some little modules to do client side enumeration and you can extend these to do all kinds of crazy stuff and I'm not gonna read all the code but I'll just sort of show you a little overview of each thing. So the first thing we wanna do is generate the header for our page, whatever it's gonna be. In this case we're gonna check and see if they have JavaScript enabled and if not we wanna bounce them out to some safe URL, maybe their company site or whatever we're trying to iframe in. The next thing we wanna do that's sort of important especially to pen testers is we wanna verify that the target IP is in scope. We've been on pen test where we've done phishing and accidentally owned random people's home boxes so you don't want that to happen. You wanna make sure that the only IPs that you're hitting are in the scope of whatever your engagement is and if they're not bounce them off to some innocuous site that's not gonna hurt them. So we just have some code to help you do that. We wanna verify that they have Java installed because this particular attack requires Java. So we just have a really simple, this is like simple easy stuff but we have them in a modular way that you can just go grab these things for your own attacks if you're trying to build a phishing thing for client-side engagements. Then we wanna know what OS they're reading. This particular function is really based on user agent stuff. Egypt's got some really targeted, reliable ways of finding about OS and patch level and service pack level which you should definitely check out. And then gathering information about the browser, you know, are they running Opera or Internet Explorer, Safari or Firefox or what have you? All right, another thing that can be useful while you're, I mean, if you've got them as a captive audience and they're hitting your webpage, you might as well gather information about their internal IP. And so there's a couple of ways to do this. We have a JavaScript method which allows us to get their internal behind the NAT IP address. We also have a Java applet. There's a guy out there, Regulus.de who released an applet to do this and we sort of maybe reverse engineered a little bit and added some bling to it. You can go to his site and get more info about what this class exactly does but it'll essentially do some stuff to get you their internal IP address. And if you're really interested in decloking internal IPs or finding out if someone's coming through a proxy or tour, check out hdeclok.net. It's got all kinds, you know, just a hundred different ways of doing the same kind of thing that go way beyond what we have here. And then you might want to log all this stuff. You want to know, okay, this IP hit me at this date and time and they're running this stuff in case, you know, your customer says, hey, you guys didn't really own me or you did own me and something bad happened. You want to know if that was you or somebody else. It's very helpful to log this stuff. So we just have an example of what this sort of little front end will do. Normally, you wouldn't output this to the user because obviously it looks weird but send it to a database. Okay, so, you know, the social engineering aspect of all this is having a Java applet that you can distribute your payloads in a similar way to the PDF stuff that Colin was talking about earlier. You know, we love a interpreter. That's sort of our favorite thing. So we're going to distribute that in this case. The idea behind this is the client's going to hit a page. They're going to get a Java applet window pop up that, you know, asks them to run an applet. They're going to hit run and it's going to cause the client to in the background download a interpreter and execute it and then send you a show. So I've got some really, really simple applet code for doing this. This basically just goes and gets them a interpreter and executes it. You can play with this and make it better. You know, it's just some example code. Now, how to make this really deadly is if you cryptographically sign the Java applet as your target, most users are going to go, oh look, my website has a little signature thing asking me to run something. They're going to trust that because it's from their site, signed as their company. You know, why would they question it? They're going to hit run and they're going to get owned. So, you know, we usually change up these file names to reflect the target's infrastructure. If they're running WordPress or some other content management system, we want to make sure our stuff matches that. So it's not just some random, you know, Java applet file that they never heard of before. We've got the commands for doing this here. If you want to do it by hand to show you how to sign, cryptographically sign these Java applets. By the end, you know, once you run through all those commands, you'll end up with a series of files, including the class file and a certificate and a key store. And then you're going to need a webpage to launch this. And I've got an example. Typically, you would throw this into an iframe or something like that. And also display the target's real website so they think nothing bad is going on. And they're going to get a little pop-up that looks like this. In this case, we signed it as MetaFish. We could sign that as anybody, you know, Microsoft or Target, ABC or whatever it is. It's literally a text string. Whatever text string you want. Okay, so some of the automation sites, MetaSpy has the capability to handle end incoming sessions, essentially. So you want to be able to automate functions like all your post-exploitation stuff that you don't want to do by hand if you're getting hundreds of shells coming in. Like getting your passwords, adding users, updating or uploading other types of backdoors that go beyond what a interpreter might be doing. And, you know, keep cognizant of what egress ports are allowed. So I've got just some basic examples on how to create your interpreter binary. So it'll work. I'm not going to go into that. You can read on the slides later. And then your basic commands for setting up the multi-handler session. And then on the automation script. You can use any script you want. We've got an example, but, you know, there are a whole bunch out there. So you want to deploy and interpret your target using whatever means you can't, whether it's an effective PDF, let's just website with a Java app like we're going to show in a minute or whatever exploits or just email it to them. A lot of people will just click on an interpreter executable. And then watching, you know, for your session coming back and success. So in this case, the demo we're going to do, there'll be an automated scraper that'll go and grab all this kind of information, generate a directory with time stamps and IP and all that. Then you'll end up with a bunch of files that have hashes and network neighborhood and whatever. Darker operators got some scripts out there. HD's making. Oh, he's going to talk right after this on the types of scripts he's doing. So check that out. All right, so briefly, before we get to the demo of this, I'm going to talk about obfuscation. One thing a lot of attackers are doing are obfuscating their iframes or the ways that they're getting these payloads to you because people are having host-based intrusion detection systems or AV or whatever detect these things and block them. And this is an example of iframe obfuscation where they essentially write a JavaScript that breaks up the word iframe into different variables and then reassembles it later. And a lot of your tools that would look for iframes in the HTTP request won't see this kind of thing. There's other stuff you can do. We see this all over on Chinese and Russian web kit sites where they encode their URLs and commands and whatever they're loading with just like character encoding. We have a few different examples here. These are just different ways to evade detection from getting stopped because it sucks when you hack the machine and they've run the commands and the shell gets stopped because they're running AV. There's a website out here, Script Asylum, which has a bunch of examples of encoding decoding for your JavaScript or whatever. I advise you check it out. Looks cool. And then Egypt's talk for Ajax obfuscation. He mentions this a little bit briefly and I don't know if he'll talk about it more. But it's cool stuff. All right, so we're gonna attempt to demo. And this time you'll get your hashes off that same box. For those that wanted those last time. Hopefully. All right, so we're gonna load up a couple of Metasploit sessions with some resource files that preset them up since I can't type for crap. And the settings for the actual web app applet is this is using HTTP server for Metasploit and it just basically defines what class name you wanna use, this sort of thing. It builds what payload you want. We've picked reverse TCP interpreter and it just sort of sets through all these things. So there's a few things you're gonna wanna set in here like who you wanna assign the applet as, you can put whoever you want, what ports and all the typical stuff. And also the URI path meaning what directory do you want this to come out of? And we picked cn underscore gov. So I'm gonna get it set up here. You wanna explain what's going on? So this is actually calling out to Java which is a bad thing. HD assures me that he can just sort of throw out Java byte code so we'll be moving to something a little cooler and sexier later. But this is basically just compiling the Java applet. It renames a bunch of the functions, puts the calls into the right IP addresses and so forth and builds and signs it and then hosts it up on our website. All right, so I think we're all set up and running. I'm gonna switch to our other VM. Windows is so much slower than Linux. Interesting side note, I was waiting for him. The actual command in the CMD call that called the payload is due to the opening of page one. So if you went to page two and then back to page one it would in fact launch the command over again and you'd get two shells. Okay, so I'm gonna go to our little client-side enumeration webpage that we have built and what it's gonna do is determine is this a viable target, is they're in scope, is it what we wanna hack? Yes, and it's gonna bounce us off to the Java applet. Hopefully. So if you can see up there it decided that we were a good target and it shipped us off to this other URL which is say my p-address but a different directory and it's running really slow but I promise it's just because it's in a VM. So what we've done is we've iframed in something that would look normal to our target so that they don't think that they've been hacked. All right, eventually here we should get a window or something. All right, we're gonna try that again. Everyone pray to the demo gods. Kill the chicken, someone. It's really slow. All right, while we're waiting for that to work we'll show it to you real quick in a video. I think my VM is hosed or something that's running really, really slow and I think that's what the problem is but never fear, we have backup. All right, so you can see this is sort of a video what you're just looking at. You gotta pay real close attention because Val clicks yes real fast. You gotta find the spot where it actually happens. All right, so like you said I clicked that really fast but he's such a trusting fella. So what they get is a pop up that says hey, this is signed by whoever and we could assign that as Chinese government if we wanted to, they're gonna click run and then it's gonna complete. Let's check our thing over here, see if it worked yet. Oh look, it's sending. I don't know why it's so slow. It's not like we're hacking or anything. All right, so we got another video of the attacker side so you can see what happens. I think our actual demo is gonna work. I think it's just gonna work in like super slow motion. Because everything goes perfectly when you're hacking boxes. Always perfectly goes as planned. All right, so essentially what happens is it ships off the Meturpreter EXE once they hit run on the cryptographically signed Java applet and then just opens a session on the other side and runs the auto scraper to gather basic information. So you see a Meturpreter session opens up can interact with it. You can execute a shell, typical stuff like you can with Meturpreter. And then sort of what the auto scrape stuff will look like is you'll have a director with the IP timestamp and things like that and you have all these different files like you can have hashes. And these hashes are meaningless so crack them if you want, I don't care. You know, what the network neighborhood is. Repeat your question, or you're heckling. I think it was a different room. All right, so anyways, I don't know what's up with this. Like it actually sent the applet but it never sent the Meturpreter. All right, demo fail. Regardless, we'll move on to the next piece. Okay, so we were on a pen test one time and we were supposed to go offsite because it turned out that the people we were pen testing were monitoring our traffic. Sometimes the people who hire you and the security teams are not in sync. But so what I started playing with was some of the TOR stuff and everybody knows about TOR for using it for autonomously browsing the web but we started thinking, well what if we can go ahead and do more with it? And so a lot of this is already published but it takes a lot of time to figure out exactly how to do it so that we kind of put it together and these guys didn't have any clue that we could go as far as we could. So the first thing that we looked at was who do we want to be? So who do we want to come out as? Did we want to come out in China? Did we want to come out in a city where the place is located? One of the things that we're seeing as a trend is people are starting to get real reactive to being penetrated. So you'll see, oh they all of a sudden block off all access to China or they all of a sudden try and block off everybody except for their local neighborhoods for their VPN. So instead of having to drive somewhere and try and figure out what the site will look like from China and having to fly to China, we just use Tor, an easy way. You can go ahead and buy a virtual server somewhere. That's kind of expensive. It's another way to cover your tracks, kind of keep the defense off guard. So if you're actually trying to test the security teams and they're expecting you to come out of your home base in San Francisco or wherever, they might be looking at that city a little bit more. If you're coming at them from Mexico, well then they're not expecting it. So a little bit just on how to set it up and a couple of notes that we found. So in a lot of the documentation it mentions that you can just specify a country in an RC file for Tor. Turns out that's a little bit harder to do. It doesn't seem to work correctly except in some of the betas. So and one of the other things that we started to find is, and actually we found this one from the defensive side too, is if you're seeing a scan and it starts hopping IPs mid scan, all of a sudden you start thinking something's up and it's a little bit more suspicious. So it's kind of nice to define your exit note to one particular place and just pop out of that one place when you're doing a scan and then go to another place for another scan or for an attack. So of course the easiest way to figure out where you want to pop out of is through Adalia. You can go, you can see the little country flag, get an idea of what city it is, what the location is. The only big problem there is you have to have unique names in your torrc file or else you could potentially pop out of an exit note that you're not expecting to. So the unnamed is a really bad choice if you're gonna use Adalia. So you go ahead, you choose your exit note, put it in your torrc file, make sure that you're strictly exiting out of that node with the strict exit node equals one and just put a comma list if you want more than one node, put a comma separated list of the exit nodes you want to pop out of. Of course if you want to get some of those other like unnamed or not unique named exit nodes, you can do this through a couple of websites that track it. So they'll give you a unique key that you can go ahead and put it into the torrc file and then you can pop out right at that node. And here's an example from one of the torrcites. So this isn't real important unless you're coming back later, this is just how to get to the where to set the torrc. Now one of the things I discovered when I was talking with people about this is they don't really understand what they have on their box when they're looking at Tor. So you see people running proxy where tools through the 8118 port, PrivOxy. Problem is that will fuck with a lot of your tools, especially if it has Java on the other end or Flash. So you'll get real weird false positives. So that's, you can do it but it's not what I would recommend. Tor also has a full SOX 5 proxy on 9050. And there are a lot of people who think the Dali is Tor, which it's not, it's just the GUI. You don't need it at all. So there are a couple of standard tools that you can use if you wanna get any TCP connection to go over Tor or basically any. There's proxy chains, Tor SOX and TSOX. They each have their own pluses and minuses and we'll go over a couple of them. Depending on what I'm doing, I use different ones. A lot of the scans I tend to like proxy chains because it gives you a little bit more feedback. The way these work though is they hook the socket call directly and send that over the proxy. The reason this is important is so if you try and use the end map as root, it opens a raw socket so you really don't wanna do that. It's doing it for efficiency but then it ends up bypassing the proxy chains or the Tor SOX. You also need to be careful about DNS leakage, IP leakage. One of the things that I always recommend and that I do just now is standard practice because if nothing else, I've sometimes fact finger it and forget to put Tor SOX at the beginning of the command is IP chains off wherever you're going. Make sure none of your stuff leaks. If you wanna know that you accidentally did it, put it in your logs. Always try not to run as root also just in case that nice raw socket is opened. Yeah, we've seen Tor nodes that inject malicious code into every web page that you visit so running as root can expose you to that. Yeah, that's true too. So I kinda went into a quick config here. The important parts, so we wanna come back to this later, that's great, but the important parts are actually the timeouts. So if you're gonna try and do something like end map over Tor, you need to play with these timeouts a lot because you'll get a lot of false negatives or false positives. TSOX, even a simpler config, you just point it to the local host at the Tor port and Tor SOX basically works right out of the box. So we can go ahead and we can end map over Tor. It's actually not too bad. It can be problematic with the timeouts as I mentioned before and you have to be careful about your exit nodes. Some exit nodes won't allow 135 out or other exit nodes won't allow some port out. So sometimes you'll fail and you think that you shouldn't. Just try another exit node and see if you're successful. Now the results are not exactly foolproof and it takes a lot of time but if you run it overnight and then come back in the morning you have something you can play with and so it's better than having to wait. A lot of the reason this came up is I just didn't wanna wait for a pen test that we were supposed to go off site for. I got anxious and wanted to get to hacking. Of course you can't do any UDP so be careful there. So here's an example of proxy chains with end map over Tor. Now the important part here to note is that first access denied. Let me see if I can. So this access denied here is showing you that the 443 is being denied. Now if you just let this scan go it'll take forever to actually time out because basically it's still trying to get that connection going. The basically all of the Torsox proxy chains they try and assume that the ports are really supposed to be open and they're timing out for a different reason or getting rejected for a different reason. So they keep retrying. So you can go and you can tweak what your scan is and if you're using the minus A option on end map you can end up finding a lot about the end host and you just kinda sit there and play with the port ranges that you wanna see and what ports are being scanned for. You can find out, yeah this is an open SSAH running a boon to and there's no OS detection. It's really nice. So here's an example of the scan that I was actually running against blog.attackresearch.com So we were popping out right in China except I lost the cursor again. Well, we're popping out here in China going over 22 and 80 straight to blog. So in blog all that was seen was China traffic from this random exit node. But let's go a little bit further. So end map's nice but you can do a lot of more interesting things. So we went Nick to over Tor. We tried it a couple of times with the privoxy but that's one of the reasons I mentioned before. We switched over to using Torsox and what was nice about this is we were actually able to root a couple boxes all remote that coming straight from some other IP somewhere else in the world and it just took overnight and all of a sudden we were able to find a directory on some random website that they didn't know about or didn't think about that had the complete build documents including the user names and passwords to their entire website, database, everything else. So it's a nice thing to think about. We just showed it up here again scanning our attack research box and you can see the, I use proxy chains because it gives us a little bit of output so we can see what's happening and you can see each chain being created as it's going over the Tor network and hitting attack research. The minus host here just as a side I know I mentioned that you should try and use IPs whenever available. The host is to get to the virtual host on the IP that you're going after. So it's not actually doing a DNS lookup. It is a necessary thing with NIC2. But you can go further. And this was one of the fun ones that I was playing with one day and we did a full VPN over Tor. It's painful, it's slow, it dropped a lot but we were able to connect up eventually to the remote end and to a VPN site that we were after. So it was popping out wherever we wanted it to. Now it took two boxes to do this so it's a little bit of a strange setup but the nice thing about Tsox, Torsox, ProxyChains, all of them is they only end up hooking your outbound stuff. So you can still listen. So if you use something like TCP XD or any of the port redirectors it'll go ahead and listen on one port and then inject it straight over the Tor network to wherever you want. So all we had to do was take our second box, have it VPN in to our first box and that realistically piped it all over the Tor network. So these guys asked me of course what about Metasploit? For a while there I was doing Torsox with Metasploits until I read a post from HD and found out it's much easier than that. So all you have to do is set the global proxy to a SOX4 proxy on local host pointing to your Tor support. There you go. Of course you're restricted to connect shells. If you do a reverse shell you're gonna have a bad day because it points right back to you. So there's still some limitations and we went ahead and decided to show that though. Okay I guess we're skipping this so that we can give more time to the Metasploit. Hold on a second. I actually wanna see if our script ever came back up. I'm gonna have Dave do the demo of his tool and we're gonna skip Metasploit over Tor because basically yes you can Metasploit over Tor. I'm gonna bounce this box. Okay so of course once you get onto a box you wanna be able to get your command shell back and you want it to be persistent. So you want to have this anonymous server out somewhere. Well you can use Tor to do that. They're the dot onion sites. Normally this requires Tor on both sides. So if you want you can get onto your attackers box, install Tor, install Tsox or PrivOxy and sure no problem you can have a back door going over Tor in no time. It's actually fairly easy with Bash so you can get Bash over Tor by setting up a hidden service on one of the Tor servers and just doing a net cap. You can also do it with the built in TCP and Bash. And but in the interest of time what we did is we didn't want to do that. We didn't want to have to install Tor on the remote end. So we wrote a tool. This back door goes through a website called torproxy.net. It's not the only one out there but it's an easy way to bounce through. So we can do HTTPS straight to this place in Germany and then it'll go anonymously to the Tor network. So in the end no one really knows where we are and forensics from the place that has this back door on it is really nasty because everything's going HTTPS out their site. So it's not like it's the Tor network that's going over the wire. So any IPSs that block Tor, no good. So there's some really nice benefits on this. Of course, no need for any special clients, just the actual back door. Oh, apparently I'm not close enough to the mic. So can't tell who the server belongs to, of course. Don't know who's the onion belongs to and it's all going over HTTPS out the front door. It's not what I would call an interactive at all. It's, or it's not interactive. It's just a simple sin commands and it's also very asynchronous. So it's not a fast back door. But it's extremely useful if you're trying to hide where you're coming from or any tracks and make it very hard on the defense. So just a quick kind of visual because apparently a lot of people have trouble visualizing this. Yeah, the victim's going over HTTPS to the Torproxy.net. So Torproxy.net at that point can see your traffic entering the Tor cloud. But really all they can see is something going to a dot onion site and some random traffic that looks like HTTP over the actual connection. So we're going to run this on a demo. Oh, that is true. One of the things I did forget to mention. So I ended up actually writing this back door twice. Once in Ruby. And then after I, my machine crashed and I lost my backups. Important to know where your backups are. Colin even saw me make them but I can't find them. I wrote it again in mono. So it's using C sharp and mono. One of the benefits being that since now Boon 2 and Debian and a whole bunch of distributions are starting to come with mono. I can actually use the same executable on Linux and Windows. And the back door will work. No problem. So what we got is a basically a back door that communicates all over SSL through the Tor network anonymously and is cross platform. So let's see if we can get it up here. Now I admit I'm doing this all over video because as we've seen. I know you can get it up Dave. Oh yeah. So as we've seen the network here is kind of iffy and I'm not going to try and tempt Tor with the network here. All we'll do is waste everybody's time and I can't grab it. So here I am on my Linux box. I'm setting up a server for the Windows and I'm going to set up the server for the Linux side here. And there we go. He's doing two demos at once. Yeah. Linux and Windows. So since this takes a while to actually run I figured I would get everything out. So here's the actual command that's going out. This is just debug output coming out from the back door right now. So I could show it. You can see it going to the Torperoxy.net and at the end of the URL here there's a dot onion and that's the actual onion server that it's sending everything to. Very similar on the Linux side. All HTTPS leaving the network. So on the Linux one we want to go ahead and run a command. So we'll go ahead and do an LS minus LA on slash. So that's going to take a while to come back. I mean it is over Tor. It's going to be a bit. If we go over to the Linux client we can actually see this stuff being transmitted. So it's being transmitted in 200 byte modified base 64 encoding. So it's just in the get request is the actual data coming back. So now here on the window side we'll go ahead and do something else. IP config is all is what I chose just so we can see it. Now if we go back over to the actual Linux place where the back door is or the windows place where the back door is we can see it going by same thing. 200 bytes at a time modified base 64. And if we go back to the Linux client there's the output or the Linux server. Client server gets confusing in Tor. But we succeeded in sending our complete command over Tor SSL out from the victim. So just to show kind of the speed we're going to go ahead and do a uname minus A and this time I'm not going to switch out. So uname minus A isn't exactly big. It's only one or two packets that need or yeah packets that need to be sent. There it is all over Tor. And on windows there's our IP config coming back all the data. So and that's pretty much it for the Tor back door. Oh yeah talk about this real quick. Oh yeah. So one of the things we were throwing around in the office was we were going to do a Gmail back door and we never got to it we just got busy and we were our thought was we were going to use Dyn DNS to trigger when to go check Gmail. Well then all of a sudden we see this maybe a month ago the tweet my PC came out or at least a newer version it's more functional and where you can control it over Twitter and Gmail your PC remotely. So if you trust Twitter and Gmail that way you don't have to deal with Tor which is kind of nice. If you still don't trust Twitter and Gmail you can go ahead and use Tor. It's just another way to go ahead and hide the traffic especially since how many corporations are still trusting Twitter and Gmail. A lot of corporations are using Gmail as their primary means of communication. So it's just another way to deal with it's customizable something to play with can't take credit for it. All right so so far what we've talked about is we're going to give you a Minnesota module that'll infect target targeted PDFs for you. We're going to give you a Minnesota module that does cryptographically signed Java applets and client side enumeration and we're going to give you a back door that's SSL cross platform anonymous over Tor. That's it so far. So of course there's a lot of other people out there doing similar things a lot of us in the Minnesota community in this and one of our good friends Dean DeBeer actually has created a front end that'll actually wrap around all this. It gives us a nice fishing framework and so we're talking about MetaFish. This is really MetaFish it's called Asagai and so here's some generic things here. We got some nice statistics and pretty pieces. You log in, you run all of your fishes this way it generates templating and you can mimic websites. So here's the users you sent your fish to. Did they click? Did you get a user password out of it? That sort of thing. And it keeps track of all of the specific statistics when they clicked what they were on so forth. If it can load an active X control it'll do that and try and get more information from you. If it can load other things it just continues and this is all leveraging MetaSploit under the hood. And so here this is just you load in a CSV of your email addresses you wanna send it to. Here's a nice SSL webpage that you wanna send them to to say hey log in to we now have upgraded SSL log in. And so here's the setup here. We have a nice screenshot showing if you wanna attach a pre-made format here kind of the two froms and then in this case we're showing the email collab vulnerability that MC here wrote that we just wanna attach it and it'll automatically create it using MetaSploit under the hood and attach it to your emails to send out. And that's it. Everyone we wanna thank, thank you for coming. Thanks. All right really quickly any questions? Like if not catch us after the talk. There's a whole track still going on in MetaSploit talks a bunch of people are gonna come up and do their thing. So please stay and hang out and watch that.