How To Defeat Anti-VM and Anti-Debug Packers With IDA Pro

[Music] hi folks and welcome to another episode of open Asus live so today what we're gonna do is we're going to look at a malware sample that is packed with a packer that has a whole bunch of an e debug and anti VM any analysis tricks in it this is something that you guys have asked for I saw in the comments and actually had a DM about this as well as something that you guys want us to cover so today we're digging in I found a good sample for you guys that has all kinds of stuff just the kitchen sink of anti analysis tricks in it and we'll just walk through that and show you guys how to circumvent these things so before we get into this I just want to say that this tutorial is a little bit more advanced than some of the other ones that we've done because of the nature of obfuscated code and anti debugging checks you just you basically have to know a little bit about assembly before you can start tackling that sort of stuff I've tried to slow this down and I've tried to go a step by step as possible but it wasn't always possible so if there are any steps in the video that you guys think I've skipped over or you miss what was going on by all means leave a comment and I'll definitely reply to you guys below I'll try and explain anything that you might have missed so here's our sample I actually grabbed this off of RAD site malware traffic analysis dotnet I plugged that every video it's a great site if you want to grab malware samples to practice with I'll actually link it in the description below and also for all the samples that we work with today I'll put the links in the description of the video below I know you guys were asking about that so here we go we have our sample and as you can see in hybrid analysis if we go down to the actual process list here the sample was run but nothing else really happened there's no network traffic there's no other processes spawned there's no files drop so this might be a good indication that this sample detected that it was in a sandbox and it didn't run so that's why I selected this I thought it would be a good one because it didn't even run in higher analysis which is pretty decent sandbox in terms of hiding itself it usually bypasses most sandbox detection but in this case it did not so what we'll do is we'll copy the sample down and then load it up in Ida and we'll load it up in a VM and just kind of run it and take a look so today I'm going to be using two VMs like I usually do we have one that's the victim and that's what we're looking at here it's just a Windows XP VM and then the other one is my analysis box so this is where I have Ida installed and all my tools and so the way it's going to work is I'm gonna have Ida here on this VM and I'll be debugging on the other VM so that if anything goes wrong it's not going to affect my Ida license and I can just take a snapshot of the other VM and revert it if I need to so let's take a look at that victim VM here here's the sample that I grabbed I called it anti debug sample just you know so we can keep it clear of what it is and the first thing I need to do is just kind of load it up in P studio and see what it is so the reason why I did this is sometimes you can get lucky maybe it's a common known Packer that we have an unpacker script for or something like that so in this case it's kind of interesting if we go down and kind of look at the the properties of the file here you can see this signature Bob Huff mini Delfy which kind of looks familiar to me I think I've seen that before and I'm not quite sure where let's see if we can get any other information about it okay so it looks like this is actually Auto IT which is like a Installer where you can have a bunch of scripts and then you can package your binary and the scripts and everything into one exe and then it's kind of like a one-click installer I've definitely seen malware packed with this stuff before and up until actually yeah so if we look at the version here so up until like version 3.2 I think 3.2 something there was a tool that would actually automatically extract the Installer script in the binary for you it was pretty awesome unfortunately it looks like these developers knew that so they're using a newer version 3.31 for I don't think there's a tool for it so we're gonna have to actually do it with a debugger but always worthwhile to just kind of check this stuff out just to see if maybe we could a shortcut this so it looks like we're not gonna be able to do that what I like to do as well just in case we get lucky from process Explorer take a look at what's going on and actually just run the sample so here we can see it's running at the bottom down here and so it looks like it's actually maybe doing some unpacking it has there's some activity going on here I'm not hopeful because if hybrid analysis wasn't able to trick it I really doubt that my VMware VM that I haven't heard that all is going to be able to check it but it's always worth trying always worth giving it a shot so it's running and magic of time-lapse it just exited nothing else happened nothing interesting so it looks like we're probably gonna have to open this thing in a debugger so here I've already loaded the file in Ida and so now we just have to set up the remote debugger so we're gonna do windows remote debugger on the other VM we have to start our remote debugger so I just started the remote debugger it's running on IP 131 just remember that let's go to our debugger process options and hostname 131 131 okay cool and like I always do I like to put a breakpoint on the start and then just start running it basically okay so now that we've started our debugging session we can put some breakpoints on a few api's that might be used to detect whether there it's being debugged or whether there's a vm present what I'm gonna do is we'll take a second here to look at some of those interesting api's that we might want to hook I realize I say hook API is a lot I talked about hooking API is in a debugging session and I just want to clarify for anyone who's wondering when I use the word hooking really what I mean is I just put a breakpoint on the API on the entry point of the API and then I take a look at the data that's passed to it so I use the term hooking because it's kind of the same concept but it's not exactly hooking so just keep that in mind I think I'd have comment about that so I just want to clarify alright let's talk about AP is that we can hook that might tell us what's going on what what is happening with this binary what I'd like to do is I like to pull up a few documents on anti debug in techniques and I'll link these in the description below so you can take a closer look at them and I'll also sort of walk through this quickly with you guys so here I have open the ultimate anti debugging reference it's fantastic and like I said I'll link it in the description below the video and I also have the art of unpacking from a black hat talk both of these are they have a lot of overlapping stuff but they're both excellent excellent references if you want to find out what all the tricks are for any debugging basically if you're trying to unpack something that has a lot of anti debugging the methodology is it's very simple there's no real tricks I mean I can show you I am gonna show you a few shortcuts but in terms of getting started there's there's no real trick to it really what you do is you set breakpoints on all of the api's that you think might be being used to detect a debug session and then you run the binary in the debugger and you see if any of those api's are hit and if they are then you check out where they're being used in the code and maybe you can see what sort of tricks are being used so it really is not a fast process really if you want to do this stuff fast if you're doing this professionally there's two tricks to it one is have a virtual environment that is scrubbed completely clean so I can talk about this in another video about how to harden a VM but that's step number one and step number two is don't use a debugger use a hook engine that is hard to detect so basically what we're talking about is build a good sandbox that's what you know that's how you unpack quickly if you have to do this in a professional environment but today we want to talk about the basics you know we want to talk about the foundation of how you do this so so that you have the concepts behind it when you go to implement this at a larger scale so we're gonna do it all manually and we'll talk about what these different andi debugging ante analysis tricks are so let's start with the ultimate debugging reference and what we'll do is we'll scroll down there's this nice there's a nice section called API so these are a bunch of api's that we won't want a hook and what I'm gonna do is I'm just going to start adding breakpoints to them in our debug session so we have a Czech remote debugger present great to help snapshot there's is Department debugger present ante query information process there's tons and tons of these api's so if you had to do this from scratch and you were really lost you would just basically add breakpoints on all of those api's and you would run the binary and check and see what's going on so that's what we're gonna do today we're gonna we're gonna try this method out here so let's look for check remote debugger present here's how we set our breakpoints we go over to kernel32 which will have a check remote debugger president and we add a breakpoint here I'm going to do control F is the bugger present so I'm gonna add a breakpoint here what were some of the other ones that they listed create tool will help 32 snapshot so the debugger ones are pretty self-explanatory but let's talk about create too will help snapshot tool help 32 snapshot so basically what that does is it returns a pointer that you can use to list all the processes that are running so anytime you see create tool hell 32 snapshot really what you have to think about is get processed lists that's kind of it's it's analogous to that basically so we definitely want to put a breakpoint on that because if they want to do any searching to see if any processes are running that are related to a VM they're definitely going to probably use that API so create two will help 32 snapshot at a breakpoint at a breakpoint and let's see what else they have so also anti query information process so the way empty query information process works is you have a call that can be used to get information about a process depending on the information class that you send it so there's a whole list of process information classes that you could check for and have this open over here these aren't formally documented a lot of them but the ones that we're pretty much interested in is if we look for debug so there's you can check for debug port you can check for debug handle and you can check for debug flags I think there's a bunch other stuff so basically the way this works is if you call aunty query information process and you pass it like 0 7 or 1 or 1 F then the result can be used to determine whether there's a debugger present so we definitely want to hook that thing and that's in NT dll DLL antiquarian formation process so let's add a breakpoint here ok so that's probably enough to get started at least I'll jump back to our instruction pointer here at the beginning and let's set up our our IDE instance so that it looks a little bit nicer let's give ourselves an advanced toolbar and that just gives us the extra buttons up there that I like to click on and we'll show a bit more of our stack here I want to see more of the registers ok so now what we wanna do is actually just run this and see if we hit any of the breakpoints that we started so now we're running and what I'm gonna do is I'm gonna pop over to our VM here just to see how we're doing so it's running looks like it's doing its thing here probably unpacking something as we can see a little bit of CPU usage so let's pop back over to our debugger and see how we're doing and it's still running it might take a minute with the debugger attached and stuff I feel sick see if we'll hit one of these hooks that we said or one of these breakpoints w site so I'm pretty sure that we will I have confidence seeing as I take this sample so I'm pretty sure we'll hit one of those breakpoints no use taking up your time let's just use a magic timeout okay actually that was amazing as soon as I snap my fingers it it actually hit on create to help snapshot it looks like we've that they're using this API so what we can do is our old trick which is run until we return so we'll return back into the code here we go here's our actual code that was running so this looks like a little segment of code it doesn't look super well-defined because maybe it's a maybe there's some obfuscation hinton yeah there's definitely a lot of obfuscation in this so let's take a look in this code here and see if we can see the call that was used to call into that API create 2 will help just to see how that how that's working I really want to want to look for is to see whether the API was dynamically resolved or whether it's one of the imports I don't think it's one of the imports I didn't show you guys that but I did check them off camera so the way to do this is here's our instruction pointer here and that's where we return to so probably the code above it is where they called the function so let's just move over there a seat turn into code so here we can see a call out to es I was here with an offset let's jump in there and let's see if we can do a DDD to turn this into a D word yeah and indeed this is a pointer to create so we'll help snapshot it so it looks like what they've done is they've dynamically resolved some API SEO so you can see this in the About section and if we go back they're calling it by reference basically so that's a good indication that this is a dynamically resolved API and what I like to do this is a little trick is let's open this in a new window so you can play around with it a little bit is anytime you see a dynamically resolved API like this there's a good chance that there's probably other dynamically result api's around it so I'll just go down here and I'll press DDD again to turn this into a D word and yeah so we have some other dynamically resolved api's as well oh it looks like the section starts here so let's let's see if we can turn these all into yeah they're all ad eyes so what we found here just by hooking that possible anti debugging API and API that could be used to list the processes we've been able to hop back into the unpacked or some unpacked section of code with a bunch of dynamically resolved API is so this is like a first good step because with these api's we might be able to get an idea of what other anti debug tricks there are and then we'll do is I'll walk you through how to determine what these anti debug tricks are and how to circumvent them but first things first let's just take a look at the api's that they've dynamically resolved [Music] hmm okay so now we have all of our api's labels here so we can see what API is they want to use in this little bit of code that they have unpacked so we can see our create to will help snapshot some read process memory stuff right process memory so maybe they're going to do some process injection and I think I saw a create process in here yeah create process so probably pretty likely that they're doing some injections so I can tell that by the fact that they're creating process they have a get thread contacts which usually means they're trying to figure out how the process is laid out after they've created it they have a write process memory which is you know all of these api's can be used for process injection so I'm thinking that's probably what we're going to look at that's probably gonna be the final stage here we can also see some other anti analysis stuff here so we have that anti query information process we know that they're definitely going to use that at some point those look like too good a few guys to look at to see if there's any anti analysis stuff related to them going back to the code that we were just hopped into here we can see that we've just returned from create tool help snapshot so we actually have in one of our arguments that we passed we'll have a pointer to that list of processes and so why don't we do a couple steps here to see if if we can tell what they're actually doing with the with the results of that process list so what I'm going to do is I'm going to step through some assembly here so it looks like the movie acts and EBX and then they're checking it for negative one so they're just checking the return value to make sure that it returned properly and I guess if it didn't return properly they're gonna jump somewhere else but it did okay so we're just gonna continue on here keep stepping through I don't see anything super interesting just yet we can see there's a call out here to process 32 first W which gets the first process in the create tool help list pointer of processes so it looks like they are going to actually get processed names probably most likely that's what they're going to do so let's skip over this we don't really need to jump into the API cuz we know what it does and actually we will should probably just 32 first fist first I should probably just put a label on there just so we remember what it is and then we'll keep going here so this is as you can as you guys can see here this is pretty obfuscated it looks like what they've done is they they've taken functions and they've split them apart and use jump statements to connect different sections in the function together and if we look up here it looks like they're using this efore as like a separator in between the function so you can see this like ephors here and and so you 4044 and then there's a bunch of what looks like maybe code and then efore so I think if we like go to here and we just press code yeah we can turn these into blocks of code so here's a bunch of ephors here so let's turn that into code so you guys can kind of see the the set up now so they basically have taken functions they've split them apart they've used jump statements to connect the different blocks and then in between the blocks there's these like efore obfuscated garbage that we're not going to care about so what I think I'm going to do is I think I'm going to through the magic of a video I'm going to turn all of these sections here in between the in between the ephors I'm going to turn them all into code sections and I'm gonna add a few labels to them and then I'll come back and with it all labeled up nice and we'll see if we can't if we can't take a look at this so that it makes a little bit more sense okay so you can see I've been busy labeling here through the magic of video after that snap I went through and I walked through and added labels to a bunch of of these functions or I guess they're not functions really they're sections that are being called into because the functions have been kind of destroyed by this obfuscation like I was describing before so I've added a couple labels just to try and make this a little bit faster in order to do that I have to step through the code and it takes quite a bit of time and I don't think there's a lot of value in showing that and just having a giant video where I'm definite three code and then labeling stuff so what I'm going to do is I'm going to go over a little bit more of what the an debug tricks actually are now that's one of the stuff is label a little bit easier to see so here in this variable here we have what looks like a process name called system process that we probably got from that create - will help list process list and it's a system process but if you if you use the create tool help a function order to get what is basically a list of processes or a pointer that you can walk and thus get the list of processes the assistant process has this silly designation here so that's just a name you'll see some of the other names are are going to be called other stuff like you know like Alsace and whatever so like I'm saying I put a label here this is actually getting the string length of this variable that's passed in and it's going to store it in EAX so let's skip over this we can say e ax has hex 10 so 16 bytes so that's that matches rate system process with the two brackets in the space 16 bytes so it's comparing the length of the string and eix to 40 Hanks which is 64 and so it's seeing if the process name length is 64 bytes long and if it is it skips this jump and we go down here and we call into exit process so why would they be doing that what are they what are they looking for there well this is actually kind of a silly mistake I think on the part of the developer so what they're doing is they're checking for any process where the name of the process is exactly 64 characters long and if any of those exist in the process list it actually kills the unpacker so it doesn't unpack now I think what they're trying to do there is they're trying to see if any of the process names have a sha-256 sum as their name so a lot of times if you like download a sample from virustotal the sample name will be 64 characters long and that'll be the sha-256 sum of the file so I think what they're doing is they're checking to see are there any processes that are being run with sha-256 filenames now that's that's like a good that's a good trick I've seen this before a lot of sand boxes will run a sample will rename it with the sha-256 sum as its file name just to track it properly so this is kind of a clever trick but one thing I think that's kind of weird about it is they're not there checking for 64 bytes exactly and they're not accounting for dot exe and write the appended file type on the end of it so I guess maybe some sandbox is Rhon files they have a way to run the files without the without the font handler on the end of it you know that's that you can definitely do that if you're starting stuff via like shell execute and commands like that you don't need that file handle around the out of it so I think to make this a little bit better they should be checking for either 64 bytes or 68 by it's right so either just the filename as a sha-256 sum as the file name or a sha-256 some dot exe on the end of it right for extra bytes so I think that would make this a better check I think this might have been a bit of an oversight on the developers part so obviously none of our processes are we're not using sha-256 as the file name so we don't really have to care about this check so let's continue on here we'll keep jumping through the code so now what they do is they turn the process name into lowercase oops let's let's go back here and setter I set a breakpoint here and a great point I will just run until we get there because again we don't have to step through all the code to turn into lowercase we know that we're turning into lowercase because I already walked through and labeled that code so and now that they have a lowercase what are they going to do with it I don't know we have a bunch of more jump statements some more garbage and it looks like they're copying it into a buffer okay great so they turn into lowercase and then they store it into a buffer so I think what they're probably doing is they're probably going to do this yeah here we go so the next API call we have is process 32 next which means get the next process in the process list so I think it's safe to say that pretty much all this function is doing is checking if the process name is 64 bytes long if it is it terminates the unpacker if it's not it stores it it turns it into lowercase and then stores it in a process list I mean okay cool that's they're probably gonna use that process list later on and another function so why don't we run until we return from this and what that's going to do is that's going to give us a that's gonna sorry let me turn this into code here so what that's going to do is that's going to give us a run back until this process was called so you can see I've added a label here get process list check safety for length because I've already walked through this so we can see that's that's one of the checks that they've done and you can see what they're doing here is they're actually testing the returned value which is in EAX so this could be a flag maybe that they're testing kind of interesting that they would be doing it that way to see whether any of these any of this stuff failed so I mean it didn't we don't really care and then the next check is they check the name of the malware sample so let's look at that check will step into that and we'll talk a little bit about how how that check works all right so let's jump into this function here and see how they're checking the sample name so we can see that there's a bunch of setup stuff here that we don't really care about and then we started to see this weird stuff where I've actually just turned these into letters so you can see but normally they they look like this so they just look like hex characters and we can see there's like a push pop into e.x push and then e x and e are sort ECX into e x so let's see what they what's going on here and then it looks like they're moving a X so the the character so only one plate into this variable here so let's just get past that and I'll just show you so in the variable they've put an S and it looks like they do this a bunch of times so let's skip through a few of them and now let's look at it so it looks like s a.m. so I think what they're doing here it looks like it's a little bit hard to see because it's split up with a bunch of jumps but it looks like this is just a standard stack string build so if you're not familiar with what stack strings are it's basically a way to obfuscate it's a simple way to obfuscate strings so instead of having a constant string in your file so a constant set of bytes what you do is you have a bunch of code like this which pushes one byte at a time onto the stack and then you use the reference to the beginning of that string and the stack as the string so it's a way that you basically dynamically build strings so that they don't exist if somebody runs strings on your binary and what this means is that if we want to see what these stack strings are we're gonna have to click through a whole bunch of code where they build the stack strings and it just yeah it takes forever right because they're building the strings one byte at a time it's super frustrating so and then once they've built them you can see like well we'll move over sorry I'll jump it to this in a new window so we can see here's our that's our stack right so we can see there's like sand Bo maybe that's gonna say sandbox what else they have on here their sample do they have anything else no nothing else I don't think so these are these are basically stack strings so so this stack string would be saying I think this is gonna be sandbox of this one would be sample so given that and the fact that I already know what this function is doing which is it's comparing the process names against these strings so why don't we let it run until it exits and then or till it returns sorry and then we'll see what the and we'll get to see what the stack strings all are because we can just of course look at the stack so I'm gonna keep this window open as a reference cuz we know that the stack stack strings will be built here and what I'm gonna do is I'm going to run until we return from this function now you might be saying well you know you don't really know what it's doing you don't know how it's all working but remember that when they return from these checks they return a flag in EAX and then that that flag is actually being used to determine whether the unpacking should continue so what we can do is we can do this pretty safe right we can just run until we return and and we just checked the flag to see whether whether we've been caught or not and then we can also check the stack spring flags or sorry the stack strings just to see whether any of our processes match up with the static strings so let's do that we'll just run until we were so now that we've returned we can see that there actually is one of the flags is set here it's actually purple because as I was waiting for it to return I just automatically set it to zero so they wouldn't trigger the unpacker to stop unpacking but I put it back to ones that you guys can see that the flag was actually set so one of the strings was detected so why don't we take a look at those strings and see what they were and why something was detected so remember this window here is where I have a pointer to the stack and this is where the stack strings were so if I just come over here and I press a to turn these into strings we can see what the strings actually are virus self dot something and sandbox I think that's it so what they were doing was looping through all the process names that they collected and checking to see whether any of these strings existed in the process names so they're looking for not just our not just our sample but also some other processes that might be running so I remember we called our sample up here we called it anti underscore debug underscore sample so this actually was this actually caught our sample and this is one of the reasons why our sample wasn't unpacked so we're gonna have to change the name of our sample where we're gonna have to change this any debug trick return value so we can change the X to zero to make it look like this string wasn't found so they also checked for a virus self dot something I'm not sure what that's for sandbox and malware so let's come back over here like I said I just changed the flag to zero so that it looks like none of the strings are found but I'm also going to change the sample name after this debug session so it actually runs so here we go we it looks like we're testing EXO we test that flag and because I changed it we're doing the jump so the next thing they're going to do is check for some AV strings so they're going to check the process list for sound avy strings I guess for a vast and that I'm actually not going to show you guys because it's kind of boring and doesn't really relate to us because we don't have a vast running that's not really so this is like an anti AV check not an anti debugging trap check I would assume that in your VMs that you're running malware you don't have a V so you have to worry about this so I'm just gonna skip over it and we'll keep going here so there's another I have to keep going okay so now they're going to check they're going to check more strings and these are they're gonna check for debug stuff so why don't we take a look at how they do that so we'll hop into this into this check here so again there's a whole bunch of it's hard to read this code which is why I had to add these add these labels because everything has really split apart so it's it's difficult to sort of to see the whole picture but what I like to do is I like to kind of go until we have until we either see them building some stack strings or until we see them doing some calling some api's so here again remember see these single byte pushes let's see if we can use the our to turn these into characters yeah it looks like again they're building stack strings once again so snack strings yeah I think so so why don't we again step through this stuff pretty quickly I think they're probably building a lot of stack strings if I remember correctly so why don't we use that trick again where we run until we return from this debug check again we're not too worried about it exiting the unpacking just yet because they always check that return flag from the debug check first before they do anything so we always have it we have a chance to change that if we need to and also when they return from this function because we have our window open to the the stack here we can check and see what stack strings were actually built so again this is a quick trick if you want to see what's being done now if you're doing this you might find a situation where you run until a return and then the process exits right because some were inside that function they were actually checking something that caused the program to exit and if that's the case it's not a big deal all you know is that next time you can't skip over that function you have to run through it and find out where they're exiting yeah again it's like kind of a trial and error thing here and and it's a little bit slow going and I don't want to make a you know four hour long video so I've kind of kind of skipping over a few of these things but again there's no magic I'm not skipping over any tricks all you're doing is basically reading the assembly to find out you know what the function is doing and then labeling it that's basically it so let's run until we return here Oh what happened here Oh interesting so actually as I was describing what I was just saying actually happened so there was actually a check in that function which determined if they found one of those strings maybe they called in to exit process I'd actually previously put a breakpoint on exit process which I didn't show you guys but that's just one of the tricks that I guess I should have mentioned where you should you definitely want to break on exit process so that you can see what went wrong if something went wrong and in this case what I'd like to do is I'd like to take a look at the stack strings and see oh yeah okay I think I think I see what's going on here so so we were so we were checking process so we're checking the process names against some more strings which I called debug strings I guess when I was labeling that function but it looks like it was probably more than debug strings so let's go over to our stack here and let's turn these into strings yeah you can see you can you guys see what's going on here let's just turn them all in so we can see oh yeah there's more up here is there any other ones no that's it so it's checking for these processes I process Explorer 64 proc Mon 64 proc Mon Ally debug process Explorer and win debug so let's pop over to our VM here and we can see we're actually running process Explorer so yes that's probably the issue here and here's a trick that you guys can do I like to do I actually knew that this was going to happen so I so I called this process Explorer but I actually always rename process Explorer for this exact reason so let's call this god mode god mode dot exe so I like to just rename it so that if this if malware is actually checking for it it won't it won't be found so now that it's called god mode not process Explorer let's go back and start a debugging again and see if see if we bypass that check come back here we're going to stop actually sorry let's let's go back to check debug process names and we'll add a breakpoint here so we can find that easily next time when we run this sample so let's stop our debugging session oh it started again we're gonna run into starts we'll just run just double check that this is running here so god mode is running Auto is running oh that's right I renamed the sample to Auto dot exe instead of instead of what was a debug example or something because I yet anti debug sample because I wanted to bypass that sample check where they're checking the process name for the word sample so let's pop back over to win a hacker here yeah so we've stopped on create tool a help 33 snapshot but remember we set a breakpoint on that function that we failed on so let's just run until we hit that function there we go so here's the magic of this is when you can really see that having VMs and a bunch of you know being able to add breakpoints and revert to where you were before if you make a mistake it's super helpful so let's run this and see if and see if our changing process Explorer the name of precipice Explorer to God Mode to see if that changed the result of this debug check so let's jump over it and there we go so we didn't end up exiting it looks like that name change helped let's delete the breakpoint and we'll continue on here let's go down so our next one is a debug track with create query info process remember I showed you guys at the beginning of the tutorial this is a way to query information about the process and based on the process info key that's pet that it's passed into the function you will be able to query different types of information and if we just pull up that browser for a minute that I had open we can see that the information that you might want to query would be about like the debug port is zero seven the debug object handle is 1 e debug Flags is 1 F so if any of these keys are passed into query information process then we can be reasonably assured that they're actually checking to see whether one of these debugger tells is present on the on the host so we'll actually step into this and show you guys how it works I'll come down here just again the setup with the jumps kind of hard to follow but trust me we're not doing anything interesting yet we're just doing the setup and then we'll come down to here which is a call so we'll just hover over here that's our ante query information process so let's label that ok and then let's see what's being passed into this API so the arguments from the stack here the first one is actually let's pull it up in the browser just so you guys to refresh your memory here so the first argument is the process handle and then the second one is the information class so let's take a look here so the first thing on the stack is a process handle and all Apps means is negative one and a process handle of negative negative one means your own process so we're saying query this process and we're passing it we're passing the key 1f which i think was one of the debug Mattel's so what is one F 1 F is process debug flags so we're checking if there's any process debug flags present and so let's go back to our to our assembly here so let's call that API and see oh shoot I jumped into it let's just run till you return for okay so to understand how this debug trick works we have to actually look at the documentation for it a little bit it's a little bit less intuitive than you might think so let's hop over to our browser here and I've actually pulled this up so the way that this works is the process debug flags class returns the inverse value of the debug Flags so if the return is zero it means that there's a debugger pleasant present and if it's an another number it's not zero then it means that there's no debugger so it's a little bit counterintuitive intuitive it's the opposite of what you might think so if we come back here that's why they're actually checking so EDI is is zero here that's why they're checking to see if that return value is zero and if it is then then they jump so what we'd like to do is we'd like to just tell it not to jump basically so here is there's the jump zero so we're going to tell I don't don't jump zero so just set our IP here so what I've done there is I've just told it like don't take that jump so it would have it would have taken the jump because the return flags were zero which is the universal what they really are me that there is a debugger there so it was trying to take that jump and I just told it not to so let's continue on and see what else they have in store for us again there's more setup stuff and then there's another call and it's again to anti query information process so it looks like there's check they're checking more than one thing through anti query information process again that's empty very information process process I'm just label it so that we know what's going on so let's take a look at our stack here the top of our stack again is negative one or all FS which means this process so we're querying the process that's actually running and we're sending it one e so remember if we go back to our diagrams here one e is right here is process debug object handle so we're checking for the debug object handle and let's take a look here we'll come back over to our auntie debugging tricks and we'll see if they can tell us a little bit about what that's doing so what they're doing here is they can they're actually checking to see whether that returns a value so if it's returning something that it's not zero basically so the way that they're doing it is they call out to Auntie query information process they take the passed argument off the stack into EAX they test it they jump if there's a value in EAX basically they jump if it's not zero so we'll have to keep that in mind when we see the when we see the return here so let's jump over this API call they're testing EAX so they're just testing the return to see whether it actually worked so we remember EAX doesn't actually have this debug object in it yeah X is the return code from the API call so it just tells you whether the API call returns successfully or not we can see here that it did you know return successfully so here whoops oh I see what they're doing okay so they're actually just checking to see you returned at all and then they're telling us that yeah there's the the return it tells us that there's a debugger present I I miss that I guess so in the first pass but that's that's what they're doing so let's return back and we can see that our flight here is set to 1 so remember we've returned from our call here and the flag is set to 1 which means that there is a debugger present so let's change that to zero and and make this okay so now at this point there's there's tons there's other debugger lots of other any debug tricks but I think that this is enough for you guys to get an idea of how to do this you basically how to use those documents that I'm linking in the description below that have all the different api's that can be used to detect whether there's a debugger present you load it up in your debugger you add you load the malware in your debugger you add breakpoints on all those api's you run the malware anytime you hit the API you hop back into the malware code and you check and see how that API was being used so in this case they're they're checking return values from the api's and using that to determine whether there's a debugger president whether there's process Explorer present or whether there's any processing with the 64 bytes long either checking whether versus explorer and sample and sandbox is our strings that exist in any of the process names so these are all I'm just going through high-level what we've what we've already determined about this program so this is basically this is how you do it you can see here that's very slow and I think what I'd like to do is I'd like to leave some of these other debug tricks up to you guys to test out yourselves so I will provide links to the samples and everything below so that you guys can take a look at this yourself you can use the exact same process that I'm using here and what I'd like to do is I'd like to show you guys a trick to basically circumvent all this stuff so let's stop our debugging session here and we'll hop over to our our victim VM here you don't need this remote debugging anymore and let's change this name to Auto dot exe and we've already changed the process Explorer name so what we're going to do is we're gonna go back we're gonna get old school here so we know that this Packer here is checking all the running processes for a bunch of strings that it has and so we can see here in process Explorer that none of the strings that they were checking for exists now in the process names because we've changed them all so what we can do is we can run it without a debugger go super old-school and see whether it'll work now so let's double click to run it we can see it's running here it's doing its thing and we'll see whether whether we we've already bypassed all the anti debugging checks by just simply running it oh yeah look at that so it started I'm going to pause this so it started a if you guys caught that really quickly it started a version of itself so remember I said earlier when I was looking at those API calls it looks like it was going to do some processing jek ssin so what we saw here was it started itself again it ran itself and then the original program exited and the version that it started is still running so I'm gonna show you guys a trick here I'm pretty sure that this is processing ejection it looks like we've bypassed all the anti debugging checks so all we have to do now is dump this process I'm going to show you just for fun super old-school way to do this those of you guys who've been around for a while remember this 'lord PE I'll put a link to the to this tool in the description below again I don't think anyone uses this anymore but I think it's hilarious just to let you guys know a little bit of history reverse engineering history so Lord Pei well ago a long time ago was like the process dumping tool and you'll see why in a second here so we can just select the process here and then we can just do a full dump basically yeah I can't find the original PD header that's fine let's save it here is dump dot exe on the desktop let's save it done thing is done and what we'll do is we'll copy that file over to our to our Ida instant our VM with the idea instance running and we'll take a look at it and see whether it's actually unpacked so we opened up dump exe and Ida on our virtual machine that we're running on I know on and let's take a look at the strings first to see if we got what we needed oh yeah so it looks like yeah here's a bunch of low key strings so I knew that the sample was going to be low key because when I found it on Mallard traffic analysis Brad had already identified it as low key based on the network traffic so the fact that I see the low key strings here you can see here's all their credential stealing paths and stuff like that so we can see that we've actually successfully unpacked it so this is kind of like the the funny conclusion to this to this tutorial so I hope that by showing you guys manually how to go through and circumvent anti debugger and an EVM tracks you can see the process that you would need to use if you need to do this but the the conclusion hopefully points you guys in the right direction which is that usually just buy a couple tweaks just changing the filename so that they're not something common make sure any of the analysis tools that you're using don't use common names make sure your VM is relatively clean you can probably just run it and dump it out with it you know you can probably circumvent all these debugger checks and all of these ant analysis checks so hopefully you guys found that interesting if if you have any feedback questions comments you want to see us explain something a little bit further please make sure to leave your comments below we'd definitely pay attention or you could DM your Sean on Twitter our links are in the description below as well and also I would totally encourage you guys to make sure to subscribe and turn on the little notification button we're doing one tutorial week so you won't miss one if you subscribe and spread the word so until next time I keep exposing the mechanics behind the Malheur and stay curious

Channel: OALabs

Views: 58,879

Rating: 4.9674268 out of 5

Keywords: malware, malware analysis, debugging, ida pro, reverse engineering, anti-debugging, anti-analysis, anti-vm, packer, unpacking, LordPE, process injection, open analysis, open analysis live, openanalysis

Id: WlE8abc8V-4

Length: 48min 36sec (2916 seconds)

Published: Tue Nov 28 2017