 Everybody in a good mood? Unlike a lie, this is Matt Richard. You can call him Matt or Richard because he has two first names, so it doesn't really matter. So our talk today is about making fun of your malware, and here's what we're going to try to do. So not all guys that write code are really good at it, and people make a lot of mistakes. Not all guys who use malicious code are actually good at operating it, so we've got a little bit of that in there, too. And then there are people who just completely fail at both. So sit back, relax. We may not be funny, so just in case we include the actual technical material, just in case you want to learn something, too. So if we're not funny, at least enjoy some of the little tidbits of tech talk. So the real quick disclaimer is these opinions are our opinions, and nothing in here is that of our employer's standard disclaimer. Don't hold us liable. All right, so this first one is called Honey. I shrunk the entropy, and it's the story of silent banker authors who developed this very complex encryption algorithm and then forgot to seed the random number generator. So this code over there is snippet from Zeus from September 2007, and you can see that it is seeding a random, seeding that global variable called DDTitCount. It first moves it into the EAX register the first time that this function is called, and then it checks that value to see if it's zero, and if it's not zero, it calls getTitCount to seed it. We weren't surprised when we saw a similar resemblance in a silent banker binary from February 2008. And you can see the resemblance here. It has a similarly named global variable called DDTitCount that gets checked if it's zero or not. If it's not zero, it gets seeded with the value of getTitCount. And at first, before I saw the MSVCRT version of RAND, I thought maybe there was a link between the Zeus authors and the silent banker authors just based on those few hex numbers that are hard coded into the binary. But really, they both just statically linked with MSVCRT. So now we get to the recipe for disaster. This snippet of code is from Silent Banker in July 2008, so just a few months after that last sample we saw in February. So they updated their code, sent out a new version of Silent Banker, and this one is significantly different from the ones that we saw previously because you don't see that global variable named current seed in this case being checked if it's ever zero and seeded. It's just used. So it's possible that somewhere else in the binary before we get here, Silent Banker seeds this global variable with some type of number. So I'm going to skip over here to the disassembly. Here's that same function. Let's just check if current seed is used anywhere else in the program before it gets used in this RAND function. You can see it initially starts out as zero, and we'll check the cross references to that variable. Based on this T column right here, the W means right. There's only one right operation to that global variable throughout the entire binary, and it is the RAND function itself. So I'm going to skip through this one just a bit fast. I talked about this briefly at DefCon last year. The recipe for disaster is to seed the random number generator that's fairly gray up on there because I wanted to indicate that they didn't do it. The next step is that they make 1,000 calls to that My RAND function and generate a 16-byte number, which is the primary encryption key. And then they take that 16-byte number and compute an 8-byte number using a particular formula. Then they generate another 8-byte number from the secondary key, and then they use some arbitrary precision math to explode that 8-byte tertiary key into a 32-byte number. Finally, they encrypt the stolen data, usernames, passwords, what have you, using the original 16-byte key. But they don't transmit that 16-byte key with the stolen data when they send it to the drop site because that would be kind of transmitting the key with the encrypted message. That would be a good idea. So instead, the silent banker author has transmitted that 32-byte number instead, and on their side, they've got a program that converts this 32-byte number back into the 16-byte primary key. But we don't have that program. So recipe to exploit the disaster. Number one, we start with seeding the random number generator to zero. Those next four steps, we can all automate with a Python script for immunity debugger because we have the formula that computes that 16-byte key, the 8-byte key, the next 8-byte key, and the 32-byte key. We have that formula. It's not in C code, but we have it because we have a copy of the silent banker binary that does it. So that Python script, I'm going to show you a demo of how it works in just a second. When we're done, we should have a good disaster recovery scenario. So here, I've got silent banker and immunity debugger. I'm attached to Internet Explorer, which is where silent banker runs. And I've marked the four functions that generate the encryption keys. And I plug in that Python script that I showed on the last slide. I invoke it by typing bang keegan. And you can see that the debugger will just play through those few functions that I want to execute about five times for this demo, but in real life, we did it about 5,000 times to get a larger set of keys. You can see on the log pane here that for each iteration of the loop, it outputs a 16-byte primary key here and then the associated 32-byte key. So at the same time that this script is printing information to the log data, it's also creating a file on disk that has the associated 16 and 32-byte keys here. So it's just a hex file. So we can go and use a Python script that we wrote that accepts that keys file and also a directory of logs that we recovered from the command and control site. So here we have a few encrypted private key certificates and a few .txt files which contain the encrypted data. And we can just run this program and it's searching through each of these text files extracting that 32-byte key, looking through the key file that I have and pairing that 32-bit number with its original 16-byte key. And then it goes ahead and decrypts the information once it finds the 16-byte key. So this is the original .txt file. You can tell it's obviously not readable. And then the output is a bunch of .tmp files which are in fact readable. And we can take that information and then go return it to the rightful owners. So all the complex work that Sonic Banker authors went through to keep their information protected is just completely ruined because they forgot to see the random number generator. Now the best part about this is this function here in the Sonic Banker binary. I've named it why not use this. So they've actually got a function in here that uses getCursorPosition to generate entropy and uses that to seed a random number generator. And we can check the cross references to this function here and see that it's used about 10 or 15 other places in the code. So it's not that the Sonic Banker authors forgot to write code that was capable of seeding a random number generator. They just simply forgot to call this function from their encryption routines. It's there. They just forgot to use it. So we thought that was pretty funny. And there's the one that got away. It's there. Why not use it? So the next one is called toDes or not toDes. And this is a story about a malware author who either doesn't know how to use the Windows API appropriately or doesn't know the maximum size of a deskey. So for the crypt-derived key API function, the DW flags parameter, the high-order, I'm sorry, the low-order two bytes of this specify the key size that you want for your encryption key. So here, if the low bytes are 0080, then the encryption key that we're asking is 128-bit RC4 key. Now, this is how to shoot yourself in the foot. And I'm going to go to the disassembly for this one as well. Here is a function called initializedCryptoSubsystem. And you can see the Trojan calling CryptoQuireContext. And then it's creating a container for an MD5 hash. And then it's creating an MD5 hash of a hard-coded password in the binary. And it's trying to use the output of that hashing function to generate a 128-bit deskey, which obviously will fail because there's no such thing as a 128-bit deskey. So if any of those API functions fail, it follows this jump to what I've labeled cannot-derive key. And that location is right here where it moves the value that is in EBP, which is zero at the time, into this Boolean value called BU's MSCrypto API. Now, to see what type of effect this has, at runtime, we have to follow this structure member and see where else it's used in the program. What different behavior does the Trojan exhibit if this is true or if it's false? So in the function that I've named in CryptData, we can see that Boolean value being checked. And if it's true, then it comes over here to this side where it uses DES encryption and the Crypt and Crypt Microsoft API. However, if that value is zero, which, as we know, will always be zero, it comes over here and defaults to XOR. So I was just a little curious. At what point in time did the malware author decide to make a backup of this? Was he getting pressure from people above that he needed to push some malware out the door? And then at the last minute, he realized that his DES wasn't working, so he threw in some XOR. I'm not sure, but it was pretty funny. So always make backups is the moral of that story. The next one is called You Did What With What. And I was trying to think of a term that described the way Core Flood's encryption worked, and I came up with location-dependent encryption. And I wondered, hmm, has somebody else already written a paper about this? Maybe I can Google for it. And I Googled for that, and I found a hit on the US patent website where someone has actually submitted a patent for something called location-dependent encryption. And this diagram is pretty meaningless. I wouldn't recommend staring at it too long. But basically the way that it works is I send you a message, an encrypted message, and in order to read it, you have to take your GPS device and travel to the exact longitude and latitude that I specified when I encrypted the data. So normally there's that security and convenience trade-off, and this one has neither. So it's definitely not secure, and in order to read a message you have to travel somewhere that I specify. So I was joking with Matt earlier, saying that if you find yourself in a flame war on an email thread and you really want to get rid of somebody, just encrypt a message to them and make it only readable from, like, Iraq. And then there will never be a problem. So the way that this fits into Core Flood is their patented method here. This says a snippet of the code where Core Flood, after it steals information from the user, it will encrypt it and write it to disk so that the Trojan can then retrieve it later and upload it to its command and control site. So it calls setFilePointer, and the return value of setFilePointer is a D word which specifies the offset in the file that the pointer was set to if it succeeded. So then it takes the number of bytes to encrypt and moves it into the ECX register. And it takes a pointer to the data to encrypt and moves it into the EDX register. And then it ensues with this XOR loop here where it exores every byte in the buffer with AL and AH, which are the high and low order bytes returned from setFilePointer. So the actual encryption key in this scheme is the offset in the file where the data exists. Brilliant. So how to dump core? This is a program that I wrote and just released fairly recently, and you can download it. It's got the entire source code there. And it's helpful if you encounter a machine that has been infected with core flood and for some reason it wasn't able to reach its command and control server in order to upload the data. So you can actually go and retrieve those files that it has on disk and use them using this tool to figure out what would have gotten stolen if you need to report it to a customer or anything. So the other interesting part about core flood is albeit it has that encryption algorithm kind of weak, but then it goes and transmits all its configuration information, what information to steal, all its target information, which banks, which credit unions to steal information from, transmits all that in the clear. So another method of dumping core flood traffic. So here the way that core flood works is it's a DLL that gets injected into Internet Explorer and Explorer. And there are various ways to inject a code or a DLL into a process. Here are several of them. And the important part for a stealthy malware author is, number one, does the method require a change to the registry? Number two, does it require me to reboot my computer before the change takes effect? And number three, does it require the application that I'm injecting code into to restart? So there are several options here available to malware authors. And which one does core flood choose? They chose one that requires modification to the registry. And they chose one that requires an application restart. And in this case, the application is Explorer, quietly, so no one hears. This is the code that we reverse engineered showing that core flood chooses to manually terminate Explorer so that the change takes effect immediately. Now you're probably familiar with what happens if Explorer crashes on your machine. Your task bar disappears, your open applications disappear, all your desktop icons disappear, and then slowly one by one they start to come back. So the core flood authors obviously knew that because they went in here and they made a call to set error mode right before calling open process and terminate process. So what set error mode does is it prevents particular crash notifications being sent to the system which would then create a small pop up box and it sends the error message to the terminating application instead. So all that they've done with this call to set error mode is prevented a small pop up box from being shown to the user before Explorer crashes. So you tell me which one is more suspicious to a user? A small pop up box followed by everything disappearing and then reappearing or everything disappearing and then reappearing. Both. So core flood when it loads as DLL it doesn't stay loaded in the loaded modules list it allocates some memory on the heap and copies itself to the location on the heap and then it deletes its PE header so if you encounter a machine that's loaded with core flood and you say okay the next step is to dump this executable then I can maybe load it in Ida and I can analyze it well it's pretty hard to dump an executable if there is no PE header. So on top of that core flood when it calls virtual alloc it specifies the mem top down flag which causes the system to return an address the highest available address rather than the lowest available address and it causes core flood to then be able to quote unquote hide in the higher regions of user mode memory around all the system DLLs. So this next demo is how to make all that hiding useless and when you encounter something like core flood that has a few hiding techniques and there aren't available tools to help you you have to create your own tools if you're familiar with unpacking what you might normally do is use a debugger if there isn't an automated unpacker for core flood there isn't because it's not a common algorithm but you might use a debugger and go to the original entry point and then maybe dump it with Lord PE or proc dump or another process dumping utility and then you might fix the imports with import reconstructor and then finally after all that work you might have a binary an IDB that you can open and examine so this next demo is a tool that I wrote recently it's not publicly released yet because I haven't published it but it's a plugin for the volatility platform and right now I'm connected to internet explorer and a debugger and since I know where to find core flood I'll show you where it is just for purposes of the beginning of this demo so here it is right here hiding in memory at 7FF8100 we can double click on that to see the actual hex data there and we can verify that it's core flood based on some strings that we see so the next step sorry it's a little hard to read but I'm going to make these demos available you can download them and play them on your own machine where you have better resolution behind the scenes I took a memory dump of that system infected with core flood and I'm analyzing it now with volatility and first I'm printing a process list so I can find out the PID of internet explorer and right here it's telling me that the PID is 1732 so what I'll do next is use the malfind plugin which searches the virtual address descriptors which contain similar information to what the memory map in the debugger contains all the allocated memory regions in the process and for each allocated memory region it checks the VAD tags and the permissions to see if there's executable code there and if it is it'll try to disassemble it so that you can instead of attaching to it with the debugger and searching through the memory map this is one step and you can see that malfind has located some executable code identified by the proper disassembly here at 7FF800 so naturally the next step is to use this new plugin it's called fixIAT and I give it a process context PID 1732 for internet explorer and I specify the start of that memory range where core flood is hiding and what the plugin does is it enumerates all the loaded DLLs in internet explorer's memory along with its base address and size and then it parses the export table to find the RVAs of the exported functions from those modules and it saves them and then it disassembles all of the information starting at that memory region at 7FF800 looking for calls that lead to any of those exported functions and that's how it rebuilds the import address table without even having a PE header and you can see that the output of this will be something similar to import reconstructor you have the modules the first thunk and each imported function from the modules and the output of this fixIAT script is an executable that you can open in a PE viewer and see that the import table is successfully reconstructed and you can further verify just taking that and loading it into IDA everything looks right in the import address table we can then go and file the cross references to set file pointer in this case and there we are exactly at that point of the location dependent encryption code so in just a few commands with volatility on the memory dump we located where core flood was hiding in memory we disassembled it extracted it, pasted a PE header to do it even though it didn't have one and then completely rebuilt the import address table and it only took about 20 seconds so the next one is called honey, sorry to bother you again I shrunk the internet and this is a story about konfiker.b's flawed IP generation algorithm so we're going back to the windows RAND function here and the important part about this function is the very last instruction where it performs an AND of whatever value is in EAX with 7FFF so if you're not familiar with assembly and what that instruction might do then here's a small demo we're moving the maximum value that EAX can hold into the register here and then executing that AND instruction and you can see it chops off that upper half of the value and then subtracts 1 7FFF is 32768 also known as RANDMAX Windows Source Code so apparently the konfiker authors weren't aware of this limitation that calling windows RAND doesn't return an integer of that size that they wanted it chops it down to be no greater than 7FFF so that one byte right there the 7F will never be greater than well, 7F it will never be 80 or anything like that so now we get to the code in konfiker on the left hand side where it shows one call to RAND initiates the first and second octets of the IP address that it's going to scan with what it gets back from RAND the next call to RAND initializes the third and fourth octets of the IP address but two of those octets are never going to be greater than 7F so there's a large portion of the internet that konfiker.b is not capable of scanning using this algorithm over here on the right hand side is some source code that shows exactly what the assembly is doing right here and yeah, it's hard to read but the code is online for you to see if you're interested, here's a link to the tool down there at the bottom so what's the big deal behind this a big thanks to Brandon Inright who made this awesome diagram it's called a Hilbert curve diagram and I'm going to jump out to the larger version of this so you can see it a little bit better but the blue color in this diagram shows IP address ranges that konfiker.b is simply not capable of scanning using that flawed algorithm the red code shows what you can scan and as you can see this color in the larger view of it right here it's red, it's purple you don't see the red until you zoom in a little closer to one of the particular net blocks and then you can start seeing a bit of red but even in that red for each slash 16 net block here, there's still a significant amount of blue that konfiker will not be able to scan so that's pretty interesting a lot of people think that there were some great minds behind konfiker and maybe there were some interesting that windows rand provided so going back to those guys who just really aren't that good an operator in the cybercrime world it's kind of like a dog eat dog world so no honor among thieves so we're going to talk a little bit about the neosploit crew they basically made this attack toolkit and their motto was really thanks for the cash now we're going to dash so neosploit is a web attack toolkit so basically cybercrime fellows would buy this toolkit and they'd set it up on a web server they have a whole bunch of exploits they would trigger download their code so basically this is kind of like a script kitty type you know roll your own exploit kit so the neosploit guys were probably one of the most advanced groups out there and they were definitely very good on the business side they wanted to protect their investments and their time so they wrote all the code in C so this wasn't like PHP or some other flaky web app they wrote it all in C as a CGI so they would give each of their customers a binary distribution and also in the underground world they were very worried about people going and ripping off the exploits like literally just copying and pasting the exploits and making a whole new kit out of it and that's kind of rampant in the underground there's 40, 50, 60 different web attack kits and they're all just ripped off from each other copying and pasting exploits so the neosploit guys were a little bit smarter they thought they were going to encrypt it inside the screenshot here shows that they actually have a key file so this is a fully licensed distribution they would actually distribute a key and do a bunch of IP checks on the server hosting it and so they had a lot of really good customers I don't doubt that they made tons of money they had customers, the tour pig group if anyone's ever heard of the master boot record root kit or tour pig they were one of their biggest customers they had tons and tons of other customers as well so they were really out protecting their investment they had a version 3 was really their big build and that was released sometime in 2008 and we'll go into more of that story later on but needless to say they were really really worried about piracy so there was definitely a lot of FUD along with neosploit neosploit was in the media quite a bit and there were people who said oh neosploit's just copied all over the place and neosploit's this so needless to say we'll go into some of the disassembly and show a little bit of how it works so the first funny thing they did is they had this kit around since April of 2008 and then in July 2008 they pretty much decided that we're really not interested in supporting this anymore it's kind of a lot of work to keep adding new exploits and we've already got your money so see ya so they just basically just dropped a note on their website and told all their customers that sorry, it's been fun but we're out of here then they were just kidding so then in August 2008 they came back and they actually released a whole new version and they started redistributing it to some of their better customers but not everybody so they still screwed a lot of people all those people who were originally paid for it still didn't get updates but they started getting a new revenue stream coming back in a lot of new work and then they decided yeah, no, we were really serious we're just going to keep that extra money you just gave us too so now you're all screwed so going into a little bit of NeoSploit it was kind of a cool attack kit so like I was mentioning before they were really worried about piracy and people were ripping off exploits and copying and pasting them into new kits so what they did is they took each exploit and within the CGI file they would basically encode each one so of course for those who were still thinking from the other slide from the media that these exploit kits are sometimes just copied and pasted binaries are not the same as PHP scripts they're a little bit different and there was a famous quote on NeoSploit that was in a blog that said anyone can introduce new exploits for this kit it's kind of hard so this is the whole reason for this part of the talk is I said I wonder how hard it really is so I went in and started disassembling the actual exploit kit and so what they do for each exploit there's a code segment that loads the blob of the encoded exploit that's a 3 byte key it decodes it, runs through the whole loop and then serves that up to the user every time so even if you were to go through memory it's still even kind of tricky to dump memory and get all the exploits because it's clearing out these buffers each time so luckily if you did want to just copy and paste these exploits there is an answer so IDA scripting is a very powerful feature with scripting so you can basically just write a little script that goes through, finds all these blobs looks for all calls to the decode function, grabs the blob decodes it with the XOR and then dumps it out so this would probably be one of the ways or you could write your own custom small application that did it but if you were going to add new exploits to NeoSploit this is probably the way you'd have to do it is something along these lines and of course once you dump it out then you've got the whole plain text and you could rip it off and resell and do other things and NeoSploit guys probably just gave it up because it was some good money and he really didn't care about their customers so for anyone who's ever heard the words of the great philosopher Biggie Smalls, he has a song called The Ten Crack Commandments very very strong wisdom for anyone's crack dealer, I highly recommend it so number four he's got out of the ten crack commands number four is never get high on your own supply, very important you really don't want to be a crack head selling crack very important so we came across this guy, I called him the peeper so he was distributing malicious code and we'll walk through that in a second but basically he didn't listen to this song so his attack went something like this he would send out these emails disguised as various government agencies official looking emails addressing people by name, dear so and so the FTC's logic complain against your company click here to download this document that describes the whole thing so when the user opens up that particular document they would get this, it's a real Word document and inside of it a very clever feature of Word which is basically OLE that allows you to just drag and drop executables inside a Word document and then rename them so that they say something like Microsoft Word's encounter and error please double click here to continue yeah completely brilliant so he was using this and people would still click through I mean it takes like six clicks to go from getting this message to actually being infected and he had tons of victims so people are really brilliant when it comes to that you know and I love his message too they tried to cheat me blah blah blah so the next thing we found as we were tracking this guy down is if you're going to have a drop site maybe he didn't have his own management tool so maybe he thought open directories were good but open directors are bad if you're storing a lot of information about people so he definitely had the whole every server that he would configure for his drop site had an open directory and he could just go through and browse all the listings of all of his victims and see each and every one of them and oddly enough in one sense he was a good developer so he liked to QA his code the downside was is he was QA'ing his code to the actual server using his real IP so you don't last long when you do things like that so he would actually had his DSL cable modem his DSL connection from the Ukraine he would test all of his code and the malware had a nice feature called watch me or watch him so basically the whole point of this guy is he was stealing banking credentials but sometimes he just wanted to watch his victims and just sort of see what they were doing hence the reason we call them the peeper so he wasn't satisfied just to have that kind of functionality he started to watch himself kind of odd so like I don't know if anyone's ever like opened up a VNC window on your own machine where it has VNC running and kind of like loops back and he starts these smaller and smaller images he actually did that to himself multiple times on multiple drop servers yeah really really odd so he would go through this when we'd be looking through the drop servers and oh there's a picture of him watching himself watching himself watching himself and then the one that really takes the cake my favorite of all that we found that he had done to himself so he's using this watch me feature on himself while he's developing the code so he's actually got his dev environment up he's actually writing code watching himself sending it all back to the command and control so there's nothing that helps the authorities when they bust down your door and kick it in come running in and grab your machine when you've got the source code there set up on a command and control server and see that they're exactly the same thing not too right so the last piece of malware we've got is an interesting one you might be familiar with it's called Internet Explorer 7 so don't worry it's all under control Microsoft's taking care of it let's not get too worked up so Microsoft had a big problem with IE6 and that was that it was way too easy to steal stored passwords so you're probably familiar with you go to a website and it says where they call it in teleforms and you say yes and it stores it in the registry well the problem with Internet Explorer 6 was any user logged in with if you were logged in the context of the user you only had to make one function call to decrypt those passwords there was literally no protection so for malware if it was running in the context of the user it could literally just read those passwords and send them back off so in IE7 they came up with a brilliant fix they encrypted it with 128 bit encryption unbreakable brilliant bottom you can see there's a hash of a website that I'll explain later on and then a binary blob that contains the username and password so it seemed to actually be a fairly reasonable solution so I want to quote from another great philosopher John Travolta from the movie Swordfish and my favorite part is when he's sitting there and he's explaining to the other guy and he says this encryption is so good even I can't break and I think he mentions like the 512 bit encryption is he's like the best cryptographer in the world that's why they hired him so he's like even I can't do this so here's what Microsoft did they to encrypt the password they would generate 128 bit key based off the MD5 of the site that they were storing the password for so that actually seems like a fairly reasonable thing so if you went to www.bank.com slash login.asp what they would do is they would take that string they would make it all lowercase then they would make it a wide string and then basically MD5 that and that was then the key that was used to encrypt the password and the registry and the username and then when you visited the site that it had a stored password for it would do the opposite it would take the site you just visited it would chop it down, normalize it, convert to a wide string and then look through the registry to see if it had any stored values for you and if it did it would pop them in so it seems fairly reasonable except when you think about it there's a little problem that's actually not very much entropy it's kind of easy it's really not that much harder than what the 6 password encryption was so in order to break it it's fairly straightforward if a user is storing a username and password chances are it's because it's a site they go to and if it's a site they go to chances are it's a site that you can easily find an index.dat or the typed URL's registry key so that part's pretty easy so another easy way to find them is if you're talking about US victims there's only 15,000 banks and credit unions in the US and each one of those only has a handful of login pages so it's fairly trivial to go out and scrape them all and to gather a collection of those so again not really much protection and of course if you're a bad guy you probably know a lot of the sites that you want passwords for whether it's Facebook or MySpace or Twitter whatever it happens to be and you know the login page so again you can just pre-compute those and then if you really get desperate Alexa keeps tabs of popular sites and you can just grab those so it's really easy to decrypt these you can do something like basically create a rainbow table out of all these common sources and then you've basically got all the keys to decrypt all the passwords so for the bad guys it's fairly straightforward so the moral of the story for IA7 is it's not looking good but maybe there's help or there's not so nobody really does a good job with this we actually Michael and I looked at a bunch of different applications AIM and Mozilla Firefox basically everything try to write password recovery tools for them and you can write a password recovery tool for pretty much everything there's really not much that will help protect you if you're storing passwords and any sort of application specific you know remember my password thing they're pretty much all recoverable in some more or less trivial way IA7 included Firefox is probably the strongest of those since you actually have to enter a password first but even then if you've already entered your password the bad guy can sort of steal that too so moral of the story don't get compromised kind of helps from getting your passwords stolen don't save passwords of value and I think that does have a login form there's some little tricks you can do to basically tell IE don't save these passwords so the last one we have a trojan called LACMA and what it does typical trojan where basically they steal login credentials and they steal all sorts of other pieces of data and one of the things they steal is cookies I love cookies so when they upload the cookies they do it in a kind of strange way they don't necessarily sanitize the data so the user gets infected the malware steals the cookie value and then it uploads the command and control site and when it does it just uploads it with whatever file name that happened to be and if you're emulating the trojan with your own code you can specify that to be anything you want like say another PHP file so you can just upload your own PHP script to the bad guy's site simply by using this it's literally just an arbitrary file upload vulnerability sorry this one isn't funny but watch anyway because I think it's cool so I was just trying to find a way to fit this demo into the presentation which is why it's kind of not funny but it's based on the LACMA root kit that it installs just imagine that you're an incident responder or you're a malware reverse engineer and you encounter a machine that is infected with LACMA or any type of root kit that places hooks into the system service dispatch table so first what you might want to find out is what functions exactly are hooked in the SSDT and then you might want to go and recover the kernel module that's running in order to inspect it with IDA or something so it's a really cool plugin that I wrote for volatility that automates all of those tasks so I've already behind the scenes taken a memory dump of a machine infected with LACMA and then I'm just using the SSDT plugin from Volatility it's by Brendan Dolan Gabbitt it's an awesome plugin and what it does by default is just prints all of the entries in the SSDT and the owning module and the address of where the SSDT function points and it does that for all four of the SSDTs the first one the entries should be legitimately pointing inside NTOS kernel for the second table they should all be pointing inside the Win32K and for the third and the fourth it's a little arbitrary because those are not set by default so I'm going to use Brendan Dolan Gabbitt's SSDT script and on the command line just set a filter with eGREP so that I ignore anything that points inside NTOS kernel and anything that points inside Win32K and what I end up with is four functions down here that point inside a module named landmandrv.sys NT enumerate value key for hiding registry entries NT open process for hiding processes NT query directory file for hiding files and then NT query system information so like I said that's the first step we wanted to know which SSDT functions that this root kit hooks the next step would be to dump the module and look through it with IDA to try and maybe figure out what processes it's hiding, what registry keys it's hiding, what files it's hiding so I automated that task a little bit plug-in called ssdtex and you can see that blue screen flash by really quickly and that was actually IDA's command line program that I automated to process the landman drv.sys after having dumped it from memory after having identified that the four hooked ssdt entries point inside that module so furthermore after automating the creation of an IDB it does a little bit more automation and goes as far as actually labeling the functions in the IDB according to which ssdt functions that it hooks so just in one easy step we found out which ssdt functions were hooked dumped the owning module created an IDB of it and then named the function so I know exactly where to look in the IDB when I start reverse engineering it so that's all, thank you, I hope you had fun