 Well, welcome to the Hacking Malware talk that we're going to give here today. Oh, yeah. All right. I'm Val Smith. Some of you might know me. I'm a malware analyst. I do penetration testing, exploit development. I'm affiliated with Offensive Computing, which is part of what this talks about. I also do some work with the Metasploit team and Cult of the Dead Cow. And I'm Danny Quist, a security researcher, software developer, exploit developer and reverse engineer, and I'm affiliated with Offensive Computing. All right. Just real briefly, I want to, you know, give thanks to a couple other team members, Patrick Stock, H.D. Moore, Ty Bodele, Scott Miller, who's giving a talk here later, so if you get a chance, go see that, and, you know, tons of other people. So thanks to everybody. Okay. What we're going to talk about today, we're going to cover a few things. The first thing that we're going to talk about is malware and malware protections. We're going to lay some basic found work for you guys. Then we're going to talk about virtual machine detection. You may have heard of tools like Red Pill. We're going to expand upon that a little bit. Then we're going to go into exploiting some malware, and we use Metasploit to do that. Hopefully that will be interesting. And finally, we're going to finish up with explaining our Offensive Computing project and what that's all about. All right. So I'm going to jump right in. So basically, we look at malware like any other system, you know, an application operating system, it's got its own protections, its own security, and so its own vulnerabilities as well. You know, malware does lots of things to protect itself from analysis and from being removed. So we spent some time focusing on how to bypass these protections, and we're going to talk about that. Okay. So the main areas that we're going to cover in this talk, just to get the basics out of the way, are anti-virtual machine detection. Malware often, like if you've seen the Dasher worm, it'll detect that you're running in a virtual machine, destroy itself, and destroy the virtual machine at least temporarily. Malware also uses things like binary compression, make itself smaller, encoding to make it harder to disassemble, and anti-debugger technologies. We're going to touch on each of these areas to lay a groundwork. Okay. So we like evil things, so we're going to use evil to fight evil. All the same sorts of methods that you might use in exploit development, you know, software cracking, especially old school stuff, that's the kind of things that we use against malware. Disassemblers, packer detectors, debuggers, metasploit, of course, other cracking tools. So we're going to cover some of these areas. All right, Europe. Okay. So one of the first things that a piece of malware can do is look to see if it's in a virtual machine. This is actual disassembly from the Dasher variant. And those of you that don't speak assembly, the pseudo code is if you detect malware, destroy yourself, otherwise continue with the hilarity. And Dasher isn't all that wonderful. It does this elite net start and then grips for the VMware string. So all you have to do on this one, it's pretty easy to start. So it's just looking for the VMware services inside of here. All right. We've got a quick demo. So we have several movies to sort of demonstrate how this stuff works. So we're going to play them. Hopefully they don't look too bad on the big screen. So this first movie is going to demonstrate how this anti-virtual machine stuff works. And let me get that started for you. Okay. So we're going to open up the Dasher worm here in a tool called Bintax. It's just a string viewer. And we're going to look through here for strings that might help us figure out what this malware is doing. And basically, there's a little bit, but a lot of it's pretty much garbage. So that's not so good. We can't really tell what's going on. So the next thing to do, of course, is pop it up in Ida Pro, the reverse engineer's tool of choice, and see if there's any more information we can get from this malware. First thing's going to happen. We're going to get some errors in Ida Pro. This is a hint that has been protected in some way, packed, compressed, whatever. When it loads up, you'll see here, like in the names window up at the top right, typically there's functions and other stuff and down at the bottom of strings. There's pretty much nothing. So we're going to run this malware. We're in a VMware machine right now and see if we can tell what's going on. And you see the malware detected us and it's destroying itself. It'll just keep running command line windows until the virtual machine dies. So that's kind of rough for analysis. All right. So the more sophisticated methods for detecting virtual machine start using some of the proprietary protocols inside of the VMware driver interface. So from a user level program at ring three, you can actually set up the entire transaction as you would to do that. So in this assembly code here, we're setting up a VMXH operation, which is a special code to send to VMware on some other values. And we're actually using the get VMware version. We set it to the Vx port and then we do an in operation to read from that port. And basically, if something comes back there, then that's a VMware port. If something doesn't, then that triggers an exception. And so you'll see this a lot in samples of malware if you do analysis on them. Okay. Again, this is the virtual PC interface. This uses the emit series of calls, but it's basically the same thing. If these fail in any way, you're going to trigger an exception and go off to it. So virtual machines are important for the malware analysts because it's important to have some level of safety. You don't want to infect your root machine. Not that it doesn't happen. But there's a couple different or a few different types of virtual machines. The first one is a fully emulated instruction set. And this is where the instructions are translated dynamically on the fly from the host OS. These have a, you know, 100% it's being emulated. Things like box, it's really slow. That's because it's doing this one to one emulation. The next advance in virtual machines is somewhat emulated. And this is VMware's acceleration mode. So this is where some of the critical instructions are emulated by the VMware, but otherwise the entire operation of it is carried off on the raw hardware. The next set is hardware virtualization. Joanna Rutkowski gave a great talk about ideas about how malware could use that. And this is the Intel Vanderpool instruction set and AMD Pacific instruction set. And what these do is they actually have chip support inside of the CPU to handle the virtualization functions. Okay. So generic VM detection, there was an excellent paper outlining the problems implementing virtual machines on IA32 architectures by Robin and Irvine at USENIX 2000. And basically what they said is that there are some registers that have system-wide applicability. So you have the LDT, the local descriptor table, the GDT, global descriptor table, IDT, which is the interrupt descriptor table, and this is the technique used by Joanna's red pill, and also the machine status word. So any time a program is executing inside of VMware, these instructions and these register reads have to be emulated. And that's where we make our tool useful. So the thing about it is the Intel CPU was not originally designed for virtualization. It either must be emulated, these instructions, or it must be translated. And so this is all ring three or user-level code or signature generation. So to further on, to go to some of the techniques, see the evil theme in here? Cheap shot. Sorry. So the IDT technique, this is done by the red pill by Joanna Rakowska and the Scoopy Dew by Tobias Klein. This is just a simple signature match on the IDT register value. But the problem with the IDT is that being the interrupt descriptor table, each CPU has its own copy of the IDT. So if you're on a multiprocessor machine, the signature is not going to match. And so the question becomes, how does the ingenious malware developer come up with a way to understand all of the IDTs across all number of processors? And so the quick thing that you can discern from this is that if you are using the IDT method, you're going to fail one over in times for however many processors you have. The global descriptor table had similar results. It was effective in discovering this. The only thing that was useful was the LDT. You could see it across a parallel system, and it always had the same idea. And since it's used for accessing local data, it's all operating system dependent, but for our case in Windows, it worked quite nicely. So memory is addressed similarly on the context switch. The problem with the LDT method, as is pointed out when we made a rootkit.com post is that it fails on full emulation. So the trick to get around this, if you want to analyze a piece of malware that's only looking at the LDT is to disable emulation. But it turns out that there's another bug, and the machine status word is what we'll use to give the full idea. So here's our grand unified VMware fingering or VM fingering, our fingerprinting algorithm. So the first thing we do is we look at the easy LDT value and see if this matches our signature. If it does, and we say fine, we're in a virtual machine. The machine status word, or if we fail on that, we look at the machine status word. The high order bytes in the Intel specification says that this is undefined. And so inside of the Intel machine, it sets it, our actual Intel hardware, it sets it to a predefined value. But on VMware, there's a bug or at least an oversight that says that it or it doesn't clear that out, possibly for speed. So that's where we build up our signature detection. Okay, so we'll do a demo here. Make this bigger so people can see it. Okay, so I'm just going to run this VM detect tool. This looks at the LDT. It's set to all zeros, which is indicative of this. The machine status word, again, the higher bits are 8001, so we can mostly conclude that this is a native machine here. Over on a VMware system, we're in the VM detect tool. And we'll see that we're detecting a fully emulated virtual machine here. And so we're also running some of the other systems to look at it. So for the emulation method, if you're in VMware and you go to options and it's advanced here, this disable acceleration is the critical one, the critical flag to look at. And so again, this is a bit opposite from the actual demo, but if you run a VM detect on this too, we can see that the LDT has this 6040 value and the machine status word is set to the normal Intel thing. And that's because the root CPU is actually running that. So this is a virtual machine without emulation. Okay, so how do you defeat these VM techniques? The first one are in the case of the Dasher variant. It's just looking for that string in the list of running services, which says, I'm running the VMware tools. So all you have to do is net stop VMware tools and then you're done. The next method that you can use is to binary patch the malware basically just to knock over the VMware detection routines. So inside of here, we're actually finding the call and patching it over with the 0x90 or not. The other thing that you can do if you like to roll that way is that you can run natively or use some obscure VM. So as you can see, Danny is the brains behind the operation. I'm just the eye candy. We're a movie happy. So basically we're going to pop this thing open in Oli debug and look at it and try to get an idea of what's going on, how it's screwing over our VM. Then this is the Dasher worm that we were looking at earlier. So this isn't like an advanced Oli demo or anything. We basically consider Oli to be sort of like a machine Tivo. We like to be able to go forward and pause things and see what's going on. So what we did here is we opened Dasher. We advance it, we step through it a few times until we get to a point where we think something's going on and then we're searching down here in this window for potentially useful strings that could give us hints as to what to do about this. It's kind of hard to see in there. So I'm going to cut and paste it into Notepad. And then we'll search through there and you can see what's going on. Okay, basically there's tons of information in here. But we're looking for something that really triggers us off on the VMware self-destruct mechanism and how that works. So I'm going to fast forward just a little bit. Okay, you can see there's a batch file called virtual.bat. That's not needed to the system. That's something that's there since the malware started running. So we're going to go take a look at that and see what it does. Okay, so we found that file. It's indeed there. And you can look in here. It's just a batch file that says look at the net start services output, run find string and find VMware. This is a really lame way of doing this. That's why we're releasing the VMware detect that Danny was talking about. But you can see that's basically what malware people are doing. Most of the malware that's out there running around the wild uses these really simple techniques. Okay, so now that we know how it's detecting VMware, let's see if we can find what it does next. So we're going to do the same thing. We advance the stack a little bit. We're going to pop this open in Notepad and look for some more useful strings that can help us out. And more fast forwarding. You know, the other malware is more advanced. You might not be able to do this. Like we'll get into it a little bit more later. But it might detect all the debug and prevent you from doing this kind of thing. Almost there. All right, so you can see there's a really friendly batch file on the system now called f-off.bat. Definitely not something that we put there originally. So the malware had to create this. We're going to pop this open and see what this is going to do. Probably not something friendly. So it's basically just a go-to loop. Spawn a command shell over and over and over again. Till you fill up the memory, okay. So the next thing we got to do if we want to do some real analysis on this malware is get around its protection mechanism. The simplest way, I mean you can do some of the old school cracker stuff that Danny was talking about and knock it out or whatever. But if you don't really know what's going on, do the same thing it does. Look in the services strings for the VMware tool service and stop it. So we're going to stop that service. Now if you do a net start and look in the services list it's not going to be there anymore. So when the malware looks for it, it's not going to find it either. Then the next thing to do is to instrument your system with things like sysinternals, regmon, filemon, whatever. So you can see what the malware is doing to your system when you run it. You want to look at things like network ports, run a sniffer, all that sort of stuff. Fast forward just a little bit more. Okay, what we're doing here is filtering out known things in regmon. We're going to run it and you can see in the background all that stuff got populated. That's everything the worm does to our system now. So we're inside of VMware. We're able to analyze this malware that we weren't before and build up a model or a signature for what it's going to do and run a sniffer and take a look at that. Okay, so a couple of the other things besides VMware detection that malware does is binary compression. There's a lot of reasons for doing this. Smaller binaries takes less bandwidth. This is really important in worms so that they can propagate really quickly. Leave a smaller footprint on your system. Makes it harder to disassemble and analyze, figure out what's going on. There's tons of packers out there off the shelf that you can get. Lots of people write custom packers for their malware. The next thing is encryption, which is very much related. Basically, these things load a small decoder stub at the beginning of the binary or something like that and they either uncompressor or decrypt themselves before they execute. This doesn't give you a smaller footprint, but it makes it harder to reverse engineer or analyze what the binary is doing. There are some legitimate uses for this stuff like intellectual property protection, but I don't think anyone really takes that seriously because all of it can be broken. Okay, just gonna show a quick example of what that looks like. We love movies. All right, we're gonna take some botnet thing that we found out there and take a look at it. This one hasn't been protected with anything. So you can see here's a bunch of strings. It's got denial service stuff going on. It's got IRC commands. So it's pretty easy to tell what's happening here. If you pop it open in IDA Pro, you're gonna see quite a bit of information that you can fully reverse engineer this bot. You look up there, there's functions in the top right, there's strings in the bottom. The assembly looks pretty good. It's easy to figure out what this is doing. And if you look at a call graph, it makes a lot of sense, it's really clear. So we're gonna protect this as one of the common packers called UPEX. This is a compressor and we're gonna compress the bot and then we're gonna do all these same steps again to see what changed and how it looks different. So you can see in here, most of the strings have disappeared. There's still a few here, but it's actually improved the protection of this piece of malware. When you look at it in IDA, you're gonna see a bunch of changes. The first being you're probably gonna have some errors, like trying to find the import address table, for example. And you can see there, there's a lot less functions. The strings are pretty much mangled. The call graph looks really interesting. Little less clear than the previous one. There you go, that's for comparison. Okay, but still it's not too bad. You can glean some information from this. All right, we're gonna get all hardcore and use morphine. It's written by a guy named Holy Father and this is an encryptor. So we're encrypting on top of this. And now when we pop it open, take a look at it. You know, there's even less strings, pretty much none, except for get proc address and load library. Those are really common in malware. You'll see those all the time. And IDA is gonna look really bizarre once we open this one up. Okay, no strings, basically nothing in the names window and a really confusing call graph. So that loop right there is probably indicative of the stub that unpacks or decompresses this whole thing. Okay, so a little Faustian picture there. How are we gonna defeat this stuff? Well, there's a lot of different ways. There's some basic ways, like you scan it with a detector and if you can detect what it's packed or compressed with, go out there and search around for an unpacker or an encryptor if it's available. A lot of times that they're not, so you need to unpack it yourself. There's a great tool called x86EMU by Chris Eagle. Highly recommend for doing this kind of thing. Of course IDA, Olly Debug. The best way for getting around these malware protections is to actually partially execute the malware and dump the region of memory where this process resides. Some processes don't stay memory resident, so this could be a little bit harder. You need to run like a debugger so you can pause it right before it exits or whatever. Okay, there's another video here. We'll just take a quick look at this. All right, so you can see we have some professional tools developed for this. These are three of sort of the top packer detectors, PID and P-Scan and a protection ID. So we're gonna stick this thing in there and basically they're not gonna detect anything. They have no idea what this is protected with. These tools based on like opcode sequence signature matching, which is okay, but a lot of these new packers and encryptors coming out are polymorphic, so it's different all the time. A lot of these demos are with real live malware that we get through our site, so these aren't contrived. These are actually, we're reverse engineering realm malware. Okay, so what we're gonna do here is pop this open in Olly Debug and we're gonna advance it through. We're gonna step through several instructions to try to get it to a certain point. There's way more complex techniques than this, but we just wanna get the basics out of the way. There's a tool called LordPE, which I like a lot. It's good for editing binaries. It's also good for dumping them. You can dump them in Olly Debug with a plug-in. So what we're gonna do here is we load it up in Olly Debug, which pause the malware process for us. We found it in LordPE and then we're gonna dump it. And then LordPE has a little tool to help fix up the binary and hopefully get some more import table information. All right, so previously we had this thing, the packers couldn't detect it. We couldn't find any strings. Pretty much was hard to figure out what was going on. Now that we've dumped it from memory, we can open it up in IDA and hopefully you'll see here. Yeah, all the functions are available. Strings are available, so you can start to see here. You know, okay, there's some registry key access going on. We're gonna pop it up in the strings window because it's a little bit easier to see. I mean, the main point of reverse engineering malware is to find out what it is and what it's doing. And a lot of times you can figure that out. For example, these strings here, it's obviously a porn bot of some sort. If you want some anime, install this, it'll hook you up. Okay, so the final kind of protection that we're gonna go over here is anti-debugger technology. People are getting really crazy with this. They're like, check summing their binary image and memory. But this is one of the simple methods. Windows actually provides an API call, which is useful to developers to detect if a debugger is attached to their process. This is just some basic code to show how this works. There's a lot of different ways to get around this. We actually did some cracker stuff and found this in a binary and jumped over it. OliDebug has a really helpful isDebugger present hiding plugin now. So that's one of the best ways to get around this. I don't think I'm gonna go into this video because this is pretty simple. You basically run OliDebug if you have the plugin installed and quit and click hide from isDebugger present. Okay, one of the other things that we did here is we disassembled the binary. We found the isDebugger present call in there and basically changed the jump so that we could get past it. You can see in there, basically if the debugger's present, it sends you to a you die now call. So a lot of malware will do that. It'll delete itself or similar to the VMware protection stuff. Okay, now we're gonna get to the cool stuff, hopefully. Exploiting malware vulnerabilities. Often malware writers don't care about quality or stability. They just wanna get it out to get famous or if they're trying to make money from identity theft. So they don't really write great code all the time. Which means that often the malware has vulnerabilities. A classic example of this is this thing called the AV serve FTP server. It's used in a lot of worms. Like I think the Sasser worm probably used it. So we took a look at this thing. Somebody out there wrote an exploit for it which was kind of hard to use. So we decided to use the awesome Metasploit and make it better. We unpacked this binary using the unpack methods we mentioned earlier and we started analyzing the disassembly. Inside here is a real basic buffer overflow in the port command of the FTP server. If you look up there basically it takes the port command from the user and whatever port the user feeds it, it sends it right to a stir copy with no checking. So you can send a port command of 500 days. Okay, Metasploit's great because you can write like one line exploits because the whole framework's there to handle everything for you. So that's basically what we did. Sometimes writing a Nile service attack for a piece of malware could be really helpful. If you own your network, for example, if a network gets compromised by one of these worms and you can't make it to all the machines to go cleaning them up, you could do like a broadcast Nile service attack which will kill the worm on everybody's machine but leave the host intact so people can keep working. So that's kind of the idea behind this what we're doing here. At the bottom in red you can see we developed a really simple request through the Metasploit framework to send a port command of 295 As. Okay, well that's pretty cool but just for bling's sake, we're gonna kick it up a notch and see if we can get a shell on this piece of malware. We used a classic SEH overwrite to do this and Metasploit framework to develop it in one line. Metasploit has a cool tool called MSFP Scan which can find return addresses and DLLs and things like that so we use that. There'll be a movie for this in just a second but I wanna cover the exploit line real quickly cause it's a little bit complicated. Basically we're gonna send the FTP command, a bunch of padding, a jump to jump forward six bytes to our address which we found in kernel32.dll and then a jump back about 1000 bytes to our shell code. The reason for this is because on this particular one memory gets corrupted and two copies of our shell code get created. The bottom one is destroyed and the top one's actually good so that's why we're jumping back and then some padding. So let's show the fancy video. All right, so the two black windows are SSH into a system running Metasploit. We're gonna open up this piece of malware in Windabug so that we can watch what happens when we send our exploit. You can see up there it dumps what DLLs are being imported into this malware FTP server so we were able to look at that to decide which one to pick to find an address. So we hit G, the malware's running, we're gonna go ahead and write our exploit real quick. This is the first version, the Denial service, just to get a feel for what's going on. So just for the heck of it, we're gonna send it 500 As and see what happens. So we send our exploit, sends a port command and you can see in Windabug the worm crashed and we own EIP. All right, so looking through memory just to get an idea of what's going on we can see all our As are in there, the port command's in there and we've basically taken over this piece of malware. So if this guy's running on your network spewing a bunch of crap and you can't physically get to it for some reason you could send it down a service and turn it off and the system would still run. But we're gonna get a little more complex and write a real exploit for it. Okay, so like I said before, the port command, some padding, we're gonna do all that stuff. We actually just guessed completely on the first try and got it all right. Okay, we need to use the MSFP scan to find a suitable address to jump to and it's pretty easy. You just give it a dash F and the DLL you wanna look at and it'll give you a bunch of address to choose from. This is a little endian so we gotta flip all the bits around. Punchline's coming, I promise. Okay, so this is the part where we're gonna put our shell code, we're gonna jump back 1,005 bytes and some padding at the end. But this shows really some of the power of Metasploit. I mean, you can write a pretty complex exploit in one line. Okay, so we're gonna load up our exploit if I can type it correctly and then we need to go ahead and start up the worm so that it has something to attack, close our debugger and sometimes you wanna make sure the worm's actually fully gone from your task list because things can hang around and cause problems. Okay, so the worm's right in the background, we're gonna type exploit, it's gonna send the FTP command and we got a shell. Okay. So it's just a different kind of concept, you know, fighting evil with evil, using all the same techniques that exploit developers use against malware, worms, Trojans, whatever. Okay, so now we're gonna introduce our website. Guess two of us can't stand here at the same time. Okay, so we can hack the malware, now what? What do we do with this? Basically we want access to more malware, we wanna make it more open. Right now the antivirus companies use the previous methods and others to build commercial products, but there are well-known deficiencies. There's the signature performance, amount of processing required on the computer, and they're intrusive, not very effective, and the performance isn't all that great. So, you know, personally I don't run AV protection because it gets in the way of other stuff I wanna do. So how is the AV market doing? There was a recent article that came out from OSERT saying that there's a 20% detection rate and looking at our database we roughly confirmed this using very unscientific methods. But this is, profit is their primary goal, and that's fine, we're not against that. But what we would like to do is have a lot of the AV companies collaborate with each other. So this 20% detection rate wasn't 20% of all the malware that was detected, it was each AV company detected a different 20%. So if they combined, then they would get more, you know, 60, 80%. And again, the behavior-based models are the new hotness, but if you start doing that, then you get into more performance problems. So what we say is that open analysis of malware and open sharing can only help the situation. So what's wrong with the current situation again? The field is very elitist. There are lots of vetted private mailing lists. If Paul Vick sees in the audience, he can tell you all he's got some ideas for a private or exchange system. But generally these are hoarded, and the idea of these collections becomes a commodity for all the AV companies. And so what also happens is that AV companies come up with a situation like the Nixom worm, or LoveSan, or I think every single AV vendor had a different name for it. So how do you come up with this? And MITRE's done some work on naming that, but it hasn't been well adopted. The other problem is that there's casts of researchers. You have to prove yourself to get into the field, and it prevents outside analysis. So if you've got a, hey, I got an idea and I need four gigs of malware, that doesn't really fit here. Learn the current situation. So academic analysis is limited without effort, and it's not attractive. If you're sitting with something on your network, and you need to know something about it, the information provided by these outside vendors isn't always complete, and it's hard to validate these results. So you wanna ask the questions, what can I do to stop this, and what is this thing doing? If it's targeted specifically for my company, I need to know right away. So what's our solution? Everyone gets the same access to malware. We do not vet. The only vetting we do is we check to see if your email skills are there, and you can click a link. And so all the analysis is done in an open manner. Other than requiring you to log in, everything is shared and available to you. We've got an online web forum, bulletin board type environment, and soon we're gonna have an auto decompiling wiki-styled environment. So our end goal is IDA for the web, but we'll see how that works out. The other thing that we're doing is auto scanning with a set of AV products. We've got a pretty good sampling of the UNIX scanners that are available. And there's a lot of these available already, but in this case, and there's, the theme with those is that you upload your malware, but you can't get what other people have uploaded. So we'd like to change that. Next thing is unpacking and decryption. This is an ongoing method. Right now it's pretty manual, so if somebody unpacks a malware, then we can go ahead and include that. So we're working on some automated methods, and we'll of course be sharing those as they come available. So we've got a little bit of criticism from this. If any of you read FundSec, you were witness this firsthand. So the first comment we got was, lack of a vetting process helps the bad guys. Well, what we're saying is that it helps the well-intentioned analysis, or it hurts them much more. So writing effective malware is hard, thankfully, but defending against it is harder. It's a lot of work to get into the reverse engineering field and that sort of thing. And if we come to it, AV is failing. It detects the known stuff, but the unknown stuff is what we're worried about. But there's other people that say, I don't care if you distribute your samples, open analysis is a bad thing. But open analysis is already available from Symantec, McAfee, and the good guys at Fsecure. So we say that this doesn't matter too much. So what we're looking for is a synergy between the access to the malware and getting that. So the other thing we'd like to see more of is that peer-reviewed publications tend to focus on malware performance rather than mitigation. People are starting to work on some automated methods to discover this, but for the most part, it's not there yet. So malware is poorly written. It's difficult to make it reliable and it's difficult to make it portable. But as soon as whoever's writing all this figures out test-driven development and that sort of thing, then they're gonna go crazy. The field will go crazy. All right, so this is how we're ruining the inner tubes. Tubes. Okay, so we're gonna talk about our automated malware analyzer. Basically what we've done is we put online a searchable web database. We run a number of checks on the malware, like file typing, multiple check sums because as we all know, the SMD5 sum's been broken. Packer detection with MSFP scan. Actually, HDMor did a few modifications of this tool so that we can feed it a Packer database and then it can scan a file for those opcode sequences. So thanks to him. We do multiple antivirus scan like he talked about, kind of like virus total. We gather portable executable information like the sections and headers and all that kind of stuff with a tool called the Pelt Project. We have a rudimentary auto disassembler and actually we've been talking to some people about how we can improve that so there'll be some cool stuff there soon. And then we have this massive binary archive of malware. We get strings disassembly to a wiki. This is just sort of a screenshot of our site so you can get an idea of what it looks like. We've got uploads, you can go up there if you have an executable or a DLL, you can upload it to our site. It'll auto analyze it about 30 seconds to a minute and then it'll give you some results back. All those results get put into our database so if you find something on your system you can search our database and get not only analysis but a copy of it in case you're looking for some specific worm. And then we also have this blog system where we can post really in-depth analysis. We tend to get a lot of the new stuff really quick so check there frequently for in-depth analysis. This is what the database output looks like so if you search for an MD5 sum or a particular malware name you're gonna see something that looks a little bit like this. Basically you know your check sums are at the top, what type of file, what type of packer, if any of the antivirus detect it and you can see here they didn't do so well. More constantly adding new antivirus tools as we get licenses for them. And then over on the right you can actually download a sample, it's compressed and password protected but the password's right there. You can get a text report with some of the more executable information in it disassembly and some strings. Okay so this is sort of the proof of concept idea here where the automated analysis is gonna go through an attempt to disassemble this and if it's successful it's gonna put it into a wiki so multiple people can log into the site and work on a piece of malware, add comments, et cetera. Just another view of this you can see here. You know a little piece of disassembly there or someone went in and added a comment. This isn't that cool yet but I think eventually as we work on it it'll be pretty useful. All right so I think we're gonna have some time for questions and answers here in a second but just to wrap up real quick what you just saw was an improved method of virtual machine detection. Some of the typical things that malware does to protect itself. Some kind of nifty exploits against malware and then our offensive computing project which we hope we can get more participation in. All right anybody got any questions? Yes we have root kits, Trojans, viruses, worms. We have about 32,000 pieces of malware in our database currently and tens more thousands waiting to be put in. Hold on one more time. Well it's different in the sense that it's pretty well organized, it's easy to find. We're getting a lot of support from the community to add new tools. Pretty soon our auto analysis will be really in depth and intensive and the question was how is this different from other virus bulletins? You know and basically the thing is just a lot of those are just collections of malware not so much analysis and it's not vetted. Anybody can join. Can you hear me? A lot of these AV vendors are claiming they're not using signatures as much, they're using heuristics and stuff and they can detect zero a day. Have you analyzed any of these vendors and seen if it really works? We haven't seen much success with that. I'll let Danny talk about it a little bit. Well I mean you can take a look at the 20% detection rate that they're getting and make your own conclusions from that. Thank you. Sure. Yeah one second. Any other questions? It must die. Okay there you go. Thank you very much.