Unpacking GlobeImposter Ransomware With x32dbg

[Music] hi folks and welcome to another episode of open NASA's life so it's 10 o'clock on a Saturday night do you know where your reverse engineering friends are right here behind the debugger so I had some free time tonight and I thought I would play around with a new debugger I'm always getting true using AI debug from my friends and my colleagues and I use all the most the time if I need to use like a good debugger but always kind of old and I've been hearing a lot about these new debugger set x64 debug and x32 debug everybody seems to think that this is the future so I figured I'd give him a try and see what they're like so what I wanted to do was just kind of see if I could unpack something kind of quick with it see how it compares with all each I'm most familiar with in terms of a non idead debugger and how it compares to Ida obviously nothing's quite as good as I did in my opinion but I'm sure I'm gonna get so much hate for that in the comments but yeah anyway so I figured I'd give it a try so what I wanted to do was take a look at the globe impostor ransomware recently Brad had a quick note about this on his blog we took a look at a recent global impostor sample and if we scroll down here he's actually got the sample listed here so we can use our nice Oh a pivot plugin and see if there's actually any analysis of this actually already been submitted and there has so there's already analysis of this submitted to hybrid analysis so we can just take a look at it here and scroll down and see what the process tree looks like for this guy so looks like it runs itself a couple times so it might be some process injection or something like that and if we take a look at the screenshot here and we can see it looks like some of these files like minesweeper have been replaced with a document and there's a readme file here and I did take a look at a blog where somebody had looked at globe imposter before and it looks like it drops I mean it's ransomware and it you know encrypts files and then it drops a readme in each directory where they tell you how to you know get your files back pay them some Bitcoin or whatever what I want to do is I grabbed that sample and then load it up in a VM here and so here we go I have a sample copied over already and what I've done because I know this is ransomware is I have turned off network connections and I've turned off shared folders so the VM is completely isolated and that's the way that we're gonna be working with it today so I think I'm just gonna load it up and see what this thing looks like now I was doing a little bit of practicing earlier just so that yeah I wouldn't be stumbling too much I do actually kind of like the debugger it's it's nice it has some features that are nice and similar to ollie so it doesn't seem too crazy to jump into it and there's a few other extra things like the show graph stuff that I'll show you guys in a minute that I think is pretty nice okay so let's open up our sample here it's on the desktop Globemaster exe well open it up and the way that it works is x32 debug will automatically set a breakpoint on the entry point so if we go and look at our breakpoints here you can see they have already set a breakpoint on the entry point so if we want to just jump to where the breakpoint is we just double click on it and we're brought in here now with this program they're using a bit of setup before they get into win main so what we're gonna do is we're gonna have to actually because this isn't actually where the code starts the user code this is all just setup stuff what we're gonna do is we're just gonna actually jump over into graph mode and this is one of the cool things so you can kind of see it's almost like an idle like graph layout it's much easier to see the code flow here and we'll kind of go down to near the bottom of the graph here before they return so before they get into the return one of these calls is going to be to win main and I know that it's this one right here because we can see being pushed on to the stack here is the base address of the module module is loaded at or and five zeros so I just know that if you were unsure about this you could look up the definition for one main this is actually an instance handle which really just means like the address of the base of the module so the best way to find when main is just to look near the bottom of the function before they return look at the calls and then see which call has the base address of the module being pushed to it so we can see it's right here so you just double click to go to it and the cool thing here is like they show it to you in graph mode but you can actually right click and then do follow into this assembly and you can pop over here so this is actually win main right here and there's a neat function here you can do analysis and you can do add function so that actually adds a function definition here and this is actually our wind main so why don't we put a breakpoint on here there we go and so now we can just run so let's hit the entry point and let's run again until we get into wind main ok I did that kind of quick but really all you're doing here is if you're used to using the ID debugger or if you're using a ladybug this is just the entry point to win main so we're sitting in win win right now so let's pop back over to the graph view and we'll take a little bit of a look at this actual function here so we can see something interesting one of the cool things about x64 debug I'm gonna mess this up all the way through the video so there's two debuggers one for 64-bit and one for 32-bit I'm just gonna call it x64 to hug because that's what everyone calls it this is actually x32 debug the 32-bit version of it but you know don't mind me if I mess it up you guys know what I mean so here we go one of the cool things that they do is they'll actually resolve the API call name so these are all like win32 api s and so you can actually see what's being called here now we can see that this is junk code cuz it looks like they're just pushing a bunch of null values on and then calling things like when HTTP open and I know that like when HTTP open actually takes a bunch of arguments that you need to pass it so passing junk values like the 0 0 0 isn't gonna make any of these api's do anything so let's scroll past those and see if we can see something that's a little bit more value again there's more null bytes here so one of the tricks here when you're looking at a packed sample is go down to the bottom of the function and see what they do before they return or before they exit because a lot of the times if it's some sort of injection or some sort of especially if it's some sort of self injection a lot of the times near the end of the function will actually be a jump to a register or a jump to a code segment and that'll be you know that's where you want to put your breakpoint and it's usually near the bottom of the function so with this graph view it's really easy we can kind of like scroll down here's a loop oh there's something interesting here here's the end of the function so here's their return and that's where they end and we can see just a little bit above here they have pushed a bunch of values onto the stack here and then there looks like they're calling a virtual protect right so they're pushing virtual protect you guys can see that written down here onto the stack and I can see a call-out to get process address so probably what they're doing is they're dynamically resolving virtual protect now for those you who aren't too familiar with different packing techniques or unpacking techniques usually if you are going to write code into a memory segment and then execute it you could either create the memory segments with read write execute privileges or you could create the memory segment you can do an a lock you can write the code there and then you can change the protection of the memory segment using virtual protect so here I think that's probably what they're doing so I'm very interested in that memory segment I'm very interested to see what's happening with it and I can see down here there's a call to a memory segment and down here there's a call to EBP +14 so what I am do is I'm gonna add a breakpoint here and I got another breakpoint here don't need to add the second one but I'm just doing it to demonstrate to you guys that I'm interested in both of these addresses here and then I'm gonna run so we ran and we got to this breakpoint here you can see the little black mark beside the breakpoint but if we go back into our CPU view that's where we can actually see where IP is at any time if you ever get lost here it's kind of cool you can just double click on e IP and it brings you right back to the IP so we can see here now one thing that's important here is you didn't see in the graph view you didn't see that this memory segment was not repopulated based on what appeared in it currently but if you go to the disassembly view you can see that it's been repopulated or renamed to be virtual protect so you should always just be following it in the disassembly view here so we can see here it's been renamed so this is actually a call to virtual protect so they must have used the stack string here where they push virtual protect string onto the stack and then they called get process address and then you can see the return from get process address would be an EI X they move that into this memory segment and then of course this memory segment is being called here so let's take a look at the stack and see what arguments they're passing to virtual protect I have a feeling it's probably something related to this EVP here so I'm thinking probably what they're doing is their changes the protection level on code segment so you can execute it and then they're going to use this call EBP -14 to jump into that executable code segment so let's just take a look at that so if you guys remember first argument is pushed last on the stack so here is the actual address on the stack so if you guys are wondering how do I know that well this is actually the stack view down here and we can see the stack addresses here and then ESP is pointing to the stack address so 70 u 70 so that's our stack so here's the address that we're actually saying in the protections for here's the size and then here's the protection value and if you guys want to double check that we can just open it up in a web browser here here's virtual protect on MSDN so first argument is the address then the size of the dress and then the new protection value so let's go down and look at the new protection values so let's look at the protection constants so here we go depending on the value that you send in the protection constant it's going to do a different protection for the memory segment so what we're interested in here is execution page execute read write so this is full execution and read write is as your ex 40 so if we go back to our stack here you can see here is 40 so indeed they are turning this memory segment into executable code let's jump over that and we'll come down to the next point here so now we're gonna jump into EBP minus 14 and here we go we've jumped into a bunch of code and there's a second jump here so let's just follow that jump it looks like it's just jumping down a little bit to the next part of the code here so we'll just jump down here now the interesting thing here is this is a bunch of code that's been injected into memory and we can see here the memory segment address on the side so we're probably gonna have to redefine this as a new function so we're gonna add function because we can see here push EBP move ESPE BP and then sub to make actually your stack space so this is a standard function set up a standard beginning of a function so we can just rename that as a function and then we could also want to take a look at it in the graph here so here we have something interesting because this is going to be probably shellcode or position independent code and it doesn't look like the unpacked version of a PE because it has all this kind of weird stuff in it this looks more like sort of a stub that's setting stuff up so let's kind of take a look at what they might be doing we can see there's a couple strings here it looks like a fairly big function so let's kind of do a little bit of a walk with the debugger and see what they're trying to do here now I'm pretty fearless because I'm in a VM and I'm running this VM completely isolated there's a snapshot of it so if I mess up I can just revert it so I find a lot of times if you're kind of unsure about what's happening it's pretty easy to just take a snapshot and then keep walking through the debugger if you mess something up you can always just go back and revert it so I'm just gonna do a couple step overs here I see I'm what I'm really interested in here is the is this call these call functions here so I'm gonna just step over until we get to one the first one here so if we look here we can see a bunch of moves here and that kind of looked like what we saw before in the rest of the function there's these blocks where they're moving a bunch of D words over so why don't we kind of jump down until we get to the beginning of it now I know what this is because this is really common in malware we call these stack strings so basically this is where you instead of having a constant string in your malware you push parts of the string onto the stack in order to create the whole thing and then that way if somebody runs strings on it or whatever it's just an obfuscation technique that's basically I'm gonna show you guys something kind of cool about x64 debug where what we can do is we can sort of actually watch the string being built so if we grab this right here we can right click on it and do following dump and we'll follow the address here in the dump and that's gonna actually show the address contents here so watch as we as we execute down here we have to get down to it okay so down here we can see they've actually moved something in here it looks like kay no bite e null byte so that's the D word that they moved in so let's let's jump through a few more of these moves we'll get down to the bottom here do you see something happening so it looks like it's they're moving kernel32 in wide strings and remember I've talked about this in a few other videos but a wide string is really just an ASCII string that's been moved apart and in between each character they've put a null by it so because it's a 2 byte wide character string that's what a wide string is basically so here we have K null byte Anila byte arnelle by etc etc and so we can it's kind of cool because you actually watch that string being built on the stack here I think what they're doing here is they're probably trying to resolve some api's dynamically and because you would generally need to resolve your api's before you do any anti debugging tricks I'm pretty confident that we can actually just run through this hole through this hole function without worrying too much about what it's doing because it's probably just resolving API is and by doing that we can check and see what API is it's resolved at the end so let's just do a run until return and so here I'll just show you I'll scroll up a little bit so here's a return we'll just jump into it and here we've just returned from this function so one of the neat things that you might notice something's a little bit different one of the neat things that x64 debug does is they'll actually add the labels to these addresses as you go so you can see here these two memory addresses that were actually pushed onto the stack before we called that function now contain the two API is load library a and get process address now here's the cool part you can kind of scroll down here see these stack strings remember that's that looks very much like what we just showed you with the stack string look at what happens after the stack string there's a call to load library which we just resolved up here and then there's more stack strings and a call to get process address so probably what's happening here most likely is this is all API resolving stuff so what's really cool is if we scroll down here we can see these labels have been applied anywhere the memory dress is called and if we look at these they look like stack strings like what we just described so probably what they're doing is they're building strings and they're calling load library that looks like they're probably trying to load a DLL and then there's more stack strings than they're loading they're sorry they're calling get proc address so they're probably loading an API so this looks a lot like dynamic API loading so what we can do is kind of come down till we see the last get proc address and let's add a breakpoint here and we'll just run until we get there and see what the labels give us so see this is really cool right so exclusively for debug has now relabeled all of these memory addresses with the api's so now that we have the API that they've dynamically resolved we can take a look through them and see what they're actually doing right like what sort of so there's a you know what is a shellcode doing so virtual outlook which will protect get version lots of terminate process stuff get procedure dress which we already talked about output debug string that might be an anti debugging track we can see in a minute yeah so it looks like those are the the API is that they have resolved so in my case it looks like there's probably not really any anti debugging stuff in here except maybe that output debug string and I can actually link to below I'll link to the cheat sheet that I have for anti debugging techniques I describe it in a previous video and so actually I'll link to that video as well in case you guys are curious about it but by looking at these api's I'm pretty confident that they're probably not doing a lot of anti debugging checks here so what I'm gonna do is I'm going to jump back to our graph view here and I'm going to scroll down having use the same trick I used in the previous stage where I look at the bottom of the function and I look to see do they change control by using a jump to EAX or jump to a register we're using a call to a register or using a call to a memory segment because that might tell me that this stub is unpacking to a new memory segment and then we're gonna jump to it so let me just take a look down here see you again using this graph you I really like it I think it's awesome I'm a super visual guy so I like to see the the control flow mapped out like that and it makes it easy to sort of navigate and find the end of the function so we're coming down here and it looks like right at the bottom here they have this jump EAX so again knowing these common yeah packing tricks I know that I probably want to put a breakpoint here most likely this is controlling execution and it's transferring it over to another section of unpacked code so I'm probably I'm gonna just see if I can run until I get there I do also want to mention something kind of cool that you guys might see here you might you might have noticed see how they're building another stack string here that says jump OAP now you know that sounds a lot like a jump original entry point and I've noticed there's also other stack strings up here like no p80 exit and there's a couple other ones like MSV CRT and I was like I was definitely when I was looking at this stuff I was wondering like what are they what are they actually doing with this like why why are they building these strings these aren't API strings what are they doing with these so why don't I show you that quick because it's kind of interesting and it also makes me question what they're doing at this Packer like it seems like maybe it's in development or something so why don't we do a right-click and follow in disassembly here and here we'll add another breakpoint and we'll just run until we until we get to it I think it's again this isn't important for unpacking but it's just something interesting that I noticed about those code so we'll just run until we get here now what are they actually doing here well they're pushing this string jump you ofE on to the stack and then they're calling this function so let's jump into that function and take a look at what it does so I step forward a little bit and you can see that x64 debug has repopulated this this call here to output debug string so and then what they're pushing onto the stack is that argument that we passed to it which is jump Oh a P so what they're actually doing here is they're outputting those strings as debug messages so I it's super crazy I'm not sure why they're doing this and so if we jump over it there they've just sent that out as a as a debug message and so if we look down here we can see the debug string is Jeff OPP I'm not sure like again this is this is meant to send this message to a debugger so it looks like this is maybe a debug build of the code again I'm really not sure why they're sending all these helpful debug strings out here but it's nice for us because we know that here let's just return from this so we know that now we're gonna jump to ofe isn't that weird I think it's weird so that probably means that this jump EAX is a jump to oep so let's let's just jump into it here and remember this this jump e^x is the same jump e^x that I put a breakpoint on at the end of this function here so it's the same one and I guess they're telling us that it's OAB so let's treat it as oep so we'll jump into it and and then we have this kind of interesting we have this interesting call into another section of the code here so we can jump into that and what's happening here what's what's kind of weird here is that was an immediate jump like that last instruction was an immediate jump so I'm thinking probably this is IEP I'm thinking there's probably just a one stage hop into oep so here's the cool thing now normally like when I did this the first time I didn't quite know what the debug strings were and I was kind of confused about you know what was going on so I did actually look at some of this code I kind of walk through a bit of it before I realize oh yeah this is actually the unpack code but because the debug string tells us that we're jumping to oep we can kind of just treat it as ofe so I'm going to show you something really cool about x64 debug x32 debug is now that we've jumped to our oep we can actually just dump and reconstruct the PE file directly from the debugger I think it's super cool so they have this plug-in here called Sai sylia which is kind of like imp rec if you guys remember in Freck I don't know why it's not working so kind of something kind of embarrassing when I went to run and show you that the plugin actually crashed but but I reset it everything so that's why my debugging time is reset now but anyway no no big deal we're back to where we started so now that I know that this is the original entry point I can actually use this sylia sylia plug-in Celia Cielo I don't know how to say that sila sila it's it's basically import Reconstructor like incorrect and Lourdes PE combined so it's like a dumper and an import Reconstructor all combined and it's super easy how you use it so you basically just give it a ap so we'll just grab right here we're gonna copy copy the address pop back to our plugin here paste the address in here and then we're going to do an auto import address table of search so it actually found the import address table automatically okay and then we're going to dump the file and we'll dump it to something yeah dump that exe sure save it so that's pretty much all you need to do and that should be a nice extracted dumped PE file so why don't we load that up in Ida and take a look so here we go we've loaded it up in Ida and it works like a charm here's our entry point right here and if we look at our imports we have all of the imports these are all the nice dynamic ones that have been built for the unpacked code and if we just do a quick string search and it will be a look at the strings here we can see a bunch of strings that are related to global posture now this is like a new version of global posture where a lot of the strings are actually encoded or obfuscated but we can at least see here where they're deleting the dvss shadow copies is that you can't restore from the shadow copies so there you go pretty quick tutorial hopefully it was interesting we thought it was kind of cool to get to play with a different debugger something I'm not really used to I think I'll probably be using it in the future I mean my heart is still with with Ida obviously I didn't Eve are forever but but yeah so whenever actually do you need a real debugger I think I'm probably gonna try and transition from Olie over to x64 debug I think it's pretty cool so what I'm gonna do is as always I'll put a link to the sample below in the description of the video I'll also put a link to the to the download page for X to c4 and x32 debugger they're both free open-source debuggers so definitely if you want to give them a try you can replicate what I showed you here today and I'll also put a link to all we've hibbett which is that chrome plugin that you guys saw me use earlier to do a quick search on an indicator so that might be of use to you guys as always keep sending us comments for what you guys want to see what types of videos you want to see we have a few queued up for from some of the comments you guys said earlier so we're definitely gonna try and get some of those videos out or stuff that you guys asked for also remember to like and subscribe new tutorial videos every week one a week hopefully we can keep this up and also make sure to spread the word if you like what you're seeing so I guess that wraps it up I keep exposing the mechanics behind the malware and stay curious

Channel: OALabs

Views: 10,828

Rating: 4.9159665 out of 5

Keywords: malware analysis, malware analysis tutorial, unpacking, unpacking tutorial, debugging, x64dbg, x32dbg, malware unpacking, ransomware, GlobeImposter, GlobeImposter ransomeware, malware, debugger, open analysis, openanalysis, open analysis live

Id: _rhQRwrH7yc

Length: 23min 26sec (1406 seconds)

Published: Mon Dec 11 2017