Unpacking Emotet / Geodo (Stage 1) Using x64dbg - Subscriber Request

[Music] hi folks and welcome to open analysis live so apologies for the delay in the video it was Valentine's Day last week so we took a day off and also we had some technical difficulties there's something that happens just with like with the VMS going and the recording software it just it really slows everything down so there are some issues I'd to overcome anyway so today we're gonna take a look at a sample that subscriber endurance tea send in to us and endurance tea it's actually been a subscriber since the beginning of our channel so thanks a lot for the support and the sample that he sent in is actually quite interesting so he'd mentioned that it's doing some funny stuff and it looks like it's packed but when he opened it in some Packer detector is it nothing's really detected so what we're gonna do is we're going to take a look at it find out is it packed if it is we're gonna unpack it and it's probably packed and well show you guys the technique that we use - okay so we're gonna be using to take a look at the sample is our Windows 7 VM here I've just copied it over to the desktop and called it bad and there's a couple tools installed in the VM that you'll see me using which I will link in the description below of the video if you guys want to install them so the first thing I want to do is take a look at the sample with detected easy and just see if it detects a packer so I'll drag the file over here and it doesn't detect a packer which isn't really surprised it does detect that it's C++ compiled here but doesn't detect a Packer now this is actually really common for like custom Packers especially with malware because all the time these Packers are sort of like one-off custom things that the malware developer has actually developed themselves so there just aren't common signatures for them so tools like detected easy and PD ID and stuff like that are good for detecting like calming commercial Packers or like really popular Packers but of course they can't have signatures for every type of Packer so sometimes they won't be able to tell you that a sample is packed but I'll show you guys in a minute when you run the sample you'll be able to see oh yeah it's probably packed and another way to take a look at that is just you could also just look at the sample look at the strings and see if there's any plain text strings or how many imports the sample has it's also a good way to tell whether a sample is packed or not so let's do it like the easy way we'll just open process explorer which i've renamed a fun fun which is a trick that i do just in case the malware is looking for the string name process explorer and the running process tree because i'm reading him to fun fun a lot of times that bypasses and he like process Explorer detection stuff so I'm gonna run that as administrator here okay and then what I'm gonna do is I'm gonna make a copy of this file here and paste on the desktop and I'm gonna run the copy just in case it deletes itself a lot of malware will like delete itself after it's run to sort of hide the fact that it's running and this is the only copy I have I don't I don't have to like recopy it over again so I just make a copy of it here so let's run it and we see it's running here and process Explorer and it starts another coffee it kills itself it starts a child and then there's like another copy started here under a different name so it's spawned something else under a different name which I've just suspended just to make sure that it doesn't do anything crazy so I'm gonna actually kill it here so what we've learned from running it is it creates a couple child processes and so if we want to look at unpacking halt state so this is like how do you know when it's unpacked if you're running it one of the things we could look for is a hook on create process internal which is one of the lowest level API calls you can have in user land to create a process so a lot of create process calls all sort of filter down into create process internal W so we can hook that and then once that API is hit we'll know that probably the code is unpacked and then we can start taking a look and see what's going on so why don't we do that and you can also see that that coffee that I made has actually deleted itself so it was a good idea that I made a coffee okay so now let's open the sample in x32 debug the 32-bit version of x64 debug and we're going to have to set a breakpoint on create process internal because that's what we saw you saw it was creating a child process so we expect that that's probably the whole state for this PE file so that's when it's actually going to be unpacked in memory so we'll pop over to symbols kernel32 and look for a Kree process create process internal W and I'll just right-click and toggle breakpoint so now I'm just going to run until we hit that break point so we're gonna run we're gonna hit the entry point here I'm gonna run and we hit the create process internal breakpoint so now we know that somewhere in memory is probably an unpacked version of this PE file so then we pop over to our memory map here and we start looking for protected sections that are marked as execute so you can see like ER w so E for execute our for readable and W for writable so if it's going to be executed in memory it needs to be marked as executable so you can see for example here is the PD file that we loaded bad Exe and you can see that the text section that contains the executable code is marked as executable but there's other sections in memory like right here which is also marked as executable but it's not within a PE file so it's it's just an allocated memory segment so anytime you see that it's definitely worth investigating taking a look at and seeing what's going on because you know it shouldn't be executable it should just be a memory segment that you're reading and writing from so the way we can take a look at it is we could just like right-click and following dump and take a look at it here so it looks like there's no indication that's a PE file it looks more like it's some code that's maybe being executed and what we're looking for because we're lazy is we're looking for a PE header because we're hoping that the entire PE file has been injected into memory this is the first thing we look for it's not always gonna be there it's not always going to be as easy as just dumping a PE file out of memory but it's the first thing we check for so we want to go back and see are there any other memory segments that are executable as well so it looks like up here there's another section that's executable as well so let's follow that in the dump and we'll see hey there we go there's a video editor so this means that there is a PE file injected to memory where there's no defined file so it wasn't loaded by the operating system it was just injected in there we can see it has a PE header and it's marked as executable so when we see something like that we want to dump it out and take a closer look at it so the way we do that is we just like right click and write the dump to a file and we'll write into our desktop here and we'll just save it with the default file name here it said to turn on the light there for a minute it's kind of getting dark in here okay so we have dumped out this file to the desktop so let's use PE bear take a look at it which is just a PE file parser so we'll just drop it over and the first thing I want to do is I want to look at these sections here so let's go to the section headers and so we can see there's four sections here two data a relocation table and the text section which contains the code and so the text section I want to look and see what the actual file looks like so we'll click on the text section here and we can see that it's actually all zeros so this is like my way of checking to see whether the file is mapped or unmapped what I mean by that is there's this kind of two formats that a PE file can be in so the first format is the format that you would find it on disk as a file so this is just the standard format of a PE file and all the headers will match the raw offset so the raw offsets mean like we're in the actual file the section headers are located and then the second state of the PE file is when it's mapped into memory so this is when the file on disk is then mapped into memory and ready to be run and when that happens all of the sections are transferred from the raw address to a virtual address it's kind of like they split the PE apart and then inject it into memory so a lot of the times what will happen is if you dump a file and it's in the mapped format and then you go and click on the section here to see what it looks like in the raw format and you see zeros it usually means that the file is maps because the raw pointer is pointing to some address in memory where there is no PE section it's just a bunch of blank space so what we would expect to see here is a bunch of hex codes or the code that's going to be executed so there's a couple different ways that you can unmask a file that's been dumped that's mapped in memory and I've showed in some of our other videos ways to unmapped files using like the PE on macro tool from hash or Zaid so if you guys interested I'll actually link that video below but in this video I'm gonna show you an easier way to do it and and this method is actually quite straightforward so all we do is we actually adjust the raw assets of the P header to match the virtual offsets and that basically just tells the P file to address those sections as they exist now because they're in their map state so by doing that you kind of force the P file to look the same in its map version and unmapped version so you basically say like the sections are always going to be aligned in the same area now when you do this you have to actually turn off relocations because of course the relocation table is not no longer gonna be applicable so that's one of the drawbacks of doing this and it also means that your PE file is gonna be way bigger of course because you're now using the virtual expanded version of the PE instead of the standard raw version but it's not a big deal and especially we just want to open into Ida just start reverse engineering it and we're not going to be try and like running this P file or anything like that this is a quick way to do it so all we do is just copy these virtual addresses over to raw so one one two three four one two three seven one two three eight okay and the other thing we have to do after we've realign these sections is we need to change the base address in the optional header so this is where the actual PE file is loaded in memory to match the base address where we pulled it from memory so that everything aligns properly so that's gonna be six one two three four okay and we'll dump that file out to the desktop and now I like to call it outlined just as just because I kind of think of it as like realigning the PE file from map to unmapped now that we have that let's take a look at the imports here and they haven't actually been fixed by that on mapping and that sometimes happens so sometimes when you on that profile using that technique it'll actually realign it in such a way that the import address table is now addressable and sometimes it doesn't so in this case it hasn't now this is kind of a special case we're using in frac or sila it doesn't really work very well to try and rebuild the import address table and that's because this file is actually existing in a memory segment that's completely outside of where the PE file is and so when you try and use like sila or impractical the import address table for this file what is those tools tend to want to change the base address that we just altered here they try and change the image base to align with the P file even if you say like don't use the P file header from disk and stuff like that there's there's something in there that I haven't figured out how to tell it like hey just build the import table don't mess around with anything else so I wasn't able to get those tools to work and this is a pretty common case anytime that you're trying to build an import table for a P file that's completely out of the memory region of the process that you're actually attaching to so there's a script that Sean and I wrote that's on our github which I will link in the description of the video below and all that script does is it actually tries to rebuild the imports based on brute forcing them so it'll find any references that might be an import and then it'll build a new import address table based on those imports that it finds and I think that's what I'm going to use to rebuild these imports because it's actually gonna work in this case so I have that saved on the desktop and we'll just pop over to it now and let's do the help file for it okay so it expects an input file which is the file that we just realigned here with the broken import address table and then there's an output file where it outputs the file with the fixed import address table and then we have a PID that for the process that it attaches to the base address and the original entry point and the original entry point is the virtual address for it not the r-va and I'll explain that when we get to it it's it's one of the important parts of why this tool works and other tools don't input file and the output file I'm just going to call the output file fixed here and then we have the PID to attach to which is two nine eight zero and then we have the base address and the base address in this case these are all specified in decimal not hex which we should definitely fix at some point so I have to calculate from six and four zeroes in to decimal and I'll use a calculator to do that X six one two three four the decimal three nine three nine three two one six okay and then we have to do the same thing for the OE P now here's the thing about the original entry point if we look in PE bear here and we look at the entry point it's three 902 hex and that's actually the offset from the base address so we call that the relative virtual address so the r-va and the way the tool works is that actually takes the virtual address so the address actually in the process memory where the entry point is now because we have the r-va we have to turn it into a virtual address so to do that we just basically add the entry point to the base address and then that's that's actually the virtual address so in the calculator if we go back to hex that's the base address and we're just gonna add to it the r-va of the entry point so 3 902 okay so a 6-3 902 is the virtual address and if we convert that into decimal we can plug that into our script here ok and then we run it and it found all these imports here and it's rebuilt the import table and then if we refresh here it's created that file fixed file on our desktop here so now what I want to do is want to pop over to our other VM and I want to show you this newly fixed file in Ida to show you that it works and all the imports have been populated for it ok so we've opened up the file that we just fixed in our other VM we've opened it up in Ida here and let's take a look at it so here's the start function I'm just gonna ctrl f5 turn it into the hex raise view so it's easier to parse through it here so let's take a look at some of the functions here it looks like everything's kind of aligned properly our strings are referenced and you can see here all the imports are reference to so if we look at our imports table that's all correctly set up here and like I said all the strings here are also referenced which is always a good indication that you've realigned everything correctly so here is our first step in unpacking this sample now if you look at some of these strings you can google for them which might give you a hint about what the next video is gonna be in the series here this is actually an mo tat sample and this is the loader for the ma tête loader so this is the very first stage of mo tat that we've unpacked here and so there's gonna be a few more stages and hematite is quite an interesting sample to take a look at so stay tuned so just to do the recap we ran it using process Explorer to identify what the halt state would be so what API is we can hook to indicate that it would be unpacked in memory so we found that it creates a child process so we hooked create process internal and that would be our halt state we ran until we hit create process internal and then we looked for read/write beautiful memory sections in the memory of the process once we found one that had a PE file in it we dumped that out then we unmapped the PE file and we used our import rebuilder to rebuild the imports for it and now we've loaded up an item we can take a closer look so hopefully this is gonna be useful for you guys dealing with other similar malware that's packed in the same way thanks again to Durance T for sending the sample in it's a really good one and certainly fun to take a look at and thanks to everyone else who's sending great comments and samples for us to analyze we now have a nice queue of stuff that we to look at and some good video ideas so thank you so much remember if you guys aren't subscribed to subscribe down below one video every week we'll try and keep this up even if it's a bit delayed we'll still try and give it up and until next week keep exposing the mechanics behind them our and stay curious

Channel: OALabs

Views: 17,905

Rating: 4.9326925 out of 5

Keywords: emotet, geodo, malware, unpacking, debugger, x64dbg, pe-bear, IAT rebuild, open analysis live, openanalysis.net

Id: 4VBVMKdY-yg

Length: 15min 35sec (935 seconds)

Published: Sun Feb 18 2018

Reddit Comments

[u/Neruomute]

looks like another channel to binge.

[u/port443]

I liked the video, really engaging. At 9:21 in the video you got a typo though, and put in 0x600000 (one extra 0) which might be why your imports failed?

I feel a little pedantic mentioning this, but this seemed like an example of reflective loading rather than traditional packing. I've seen samples that just throw the real executable in the resource section then load them up like yours did, so sometimes you can skip the whole fixing-up if you catch it before its loaded.

[u/iCkerous]

u/herrcore - Lovin the channel man. I've tried to follow this thread to analyze a recent emotet sample but not having luck rebuilding the import table (the script gives 0 output). Able to take a look?

https://www.virustotal.com/#/file/10c5df8ad6bb3bff3174f300e558be862aa0274cd84a9bc130120aeec8b858d2/detection

Keep up the great work and content!