 Welcome to Memanalysis for Hedgeshrocks. Today we are looking at a sample that has a native unpacking style that is .NET file size. We are going to formulate a plan to unpack this file using Tiny Tracer to log the APIs and then see where we can break on to unpack it with x64dbg. After unpacking it, we are going to de-opfuscate the style. Let's look into it. I would like to show you how to unpack this sample and how to analyze it. When you take a look at it, this is a Visual CC++ application probably made for Visual Studio 2008 to 2010. We are also going to check on Potex Analyzer and on the strings. I'm going to quickly create a strings view. Firstly, when checking the strings, you will see that there isn't much. This is just the standard stuff that you also find and probably find the execution environment in the library or whatever and then you have the imports. That's basically it. The version info, well, that one looks pretty weird. It's just like someone opened a dictionary and randomly picked some words and put them into the version info. The good thing about that is that it's very suspicious if you find that on your system with random words and version info. You know it's never. The strings below the version info, they look encrypted. This is what encrypted strings look like. There isn't much else. The rest just looks the same as these strings. Again, version info pretty weird. Visualization shows there isn't high entropy there but still we suspect it's encrypted simply because of the lack of strings and the lack of stuff you can see there. Plus, when you check the imports, the anomalies section will also tell you that there are some functions that are typical for code injection and these are functions we can use to break on to unpack this file. There's nothing else special here, I guess. Let's analyze the behavior of this sample now using Tiny Tracer. This will take a while. First, I'm going to rename it and I'm going to use Tiny Tracer by Hashi Risade and then run it as administrator. It will run for some time and now we are going to wait until it's finished. Tiny Tracer has finished finally and we can check the result. It's in sample exa.tag and here it is. Let's scroll through a bit. Let's actually search for the functions that we found like virtual protect. We definitely will break on this function. Furthermore, we will also break on load library because this seems to be an interesting marker. We see here that mscoree.el is loaded with core ex main and that means the file that is unpacked is a .NET executor and here the execution of core ex main starts. I want to know when we are almost there so we will put a break point on create thread as well. We got this maybe also virtual alloc. That looks like a good outline for me. This is my plan. Let's open up the sample in x32dbg. Now that we made our plan, let's place the break points on these functions that we marked here. Load library A, virtual protect and create thread. Now we can press run and we add the address of entry point, run again and that's the first call to virtual protect. First argument is the address of the area where virtual protect is called and also if this is 40, it means that this is going to be made executable and we can follow this in DOM, so nothing special so far. If you look at the memory map, this area is the data section of our sample which is already quite interesting but we have a few more calls to go. We are probably going to dump it here or here. So let's continue with run. That's the load library call. I'm going to press on run to user code because then we can see here, okay, this is MsCurry. That's correct. We are actually here at this point of the execution. Let's run again and use the next virtual protect call that should be this one and the address is this one. So let's follow in DOM that is somewhat here. What area is this? It was that one, I think. It's five, two, two. So that should be the correct area. Let's look in the memory following DOM and you see here is a polybex executable file inside that area. So that is very good. We are on the right track but let's check the other ones as well. Next virtual protect call and it's five, four, six thousand. So that seems to belong to this area as well. So it's still in this area. And again, and now we are at the third virtual protect call and it's also still in this area. See here if you scroll a bit here. It says agnian.pdb. So this seems to be the .NET file that we want. And since we are here now, let's dump this. So we know it's this area. We just say dumb memory to file, put it on a desktop, save it. So here is our sample. Of course, first thing we know it's .NET. That's attempt to open it in the inspire. And of course, it doesn't work. Let's investigate why. Now the obvious ones when you just dump the file from memory is you need to unmap the file and need to fix the imports or anything like that. And indeed in this case, I don't see any imports. So there is a data directory. There's an import table, but it seems that the imports cannot be read or are not valid or whatever most of the time. And this is because the file still needs to be unmapped. So I'm using PE unmapper by Hashirisada. And we want to unmap this dump. Conveniently, the dump contains the base. So we just need to retype it. So now we have created an unmapped version. And we can check if it's now recognizing the imports. And indeed now we have the standard import for .NET executable. Let's open this file in the inspire. So that was the first one we couldn't read. And here it can read the code. Agniana, I'm not sure how to pronounce it. But this is obfuscated. So first thing I'm always trying when it looks like that is d4. Where is d4. I think I have it in my tools section. So I'm just drag and drop it into d4. Now we get a cleaned version of this dump. That looks a little bit better, but not actually because we have still no readable reference strings. So if you check that funnily enough, I immediately recognize this function as being the XOR obfuscation by draconia. So let's decode this. This is actually easy because such a string decryption function, you can just provide the token to d4. To create a version with the decoded strings. So that is relatively easy and we can do that. So you need to provide a sample. Then we say the string type is delegate. And let's provide this token. The token is the one from the string encoding function. So it's 60000DB. Let me remove the clean dump because sometimes it makes some issues. And now we created a dump where the strings might be decrypted. And indeed the strings are decrypted now and we can read. See here we can read what's going on a little bit better. Still we need to identify what these functions actually do. But that shouldn't be a problem anymore. I mean the unpacking worked now. This seems to be called AgaNiana. And let's see if we find the configuration actually. It says something like get config. If you click on that you see it contacts the C2 to get the current config. So we can actually rename that. Because where does it take this string from when you check that? That seems to be some code. And that is this ID here. So it says ID is. But here we have the version. Alright so what I want to know is where is this request for the configuration sent to. So we can maybe also get our own config. And the easiest way to do that is just set a break point here. Because yeah. At a break point we say start okay. And it's warning us because the fire doesn't have a valid extension I don't care. Alright. And what do we see here? Let's step over. And now we have the first part of this. Of this here. If you want the full config string I guess we can just break point here. Continue. And here it is. This would be the full request string that is sent to the C2. I have entered this request string to virus total. And that is what I get. So here's the content of the file and that's what it looks like. So we have txt.dog.x wallet seed. And that's it. So now we know what we get from here. Let's stop debugging. And I'm gonna go back to the start of that. So we know this is this URL string. And there's one thing I should have done first actually after cleaning the dump. And that is look at the strings. Oh wait. So again we see here still the encrypted strings. And if you scroll to the US stream of the .NET executable we have the decoded versions because we decoded them with the before dot. And that is where you see or get an idea what this file is actually doing. Let's scroll a little bit make this bigger. So this we have seen this right. And here you see it's containing typical stealer strings to steal a lot of credentials. And there's the log file header agony on a stealer. And you see also some info threads where you can find more information because this helps you to get like a good overview to everything. And yeah. Let's see what it does. And main here. So it splits this config right. And this is the config we know that by now. Config. This config is split here and then it checks this for one. The presence of one. And in this class here there are a lot of methods related to anti debugging stuff. So anti debug this checks the IP. Some sleeping methods some check for the presence of process names related to reversing. And here we have signs from the management object searcher that this is in a sandbox. So some anti sandbox stuff. So did I forget something? I forgot this one. Now if you go back to main the code will make more sense. Since now you know okay it splits this config and then checks the values and checks if any of these are true and then it executes those anties. And then more is going on. I will stop here because this will otherwise make a very long video. But I think you get the idea. So we just unpacked a file that seemed to be a native file. I mean it was a native file but it's a picker that allows loading dot net files without being a dot net stuff itself. And that was quite interesting. You can unpack those just as any other native picker though. And using DE for dot we were able to decrypt most of the strings. That's it if you have any questions please leave them below and see you next time.