 Welcome to Mavic Analysis for Head Shocks. Today's topic is rabbit holes and how to avoid them. Because you know, head shocks don't really belong into rabbit holes and we can spend our time more wisely. So I think that's a problem every Mavic analyst and every reverse engineer knows, especially from the time when you just started out. It's, you know, a time waster that you dive into the code and you don't get out of it. Like you're cluelessly searching for the things that might be interesting and you don't find them, say. There are some habits that can help you to avoid it. If you're a beginner, check this out. All right, the sample we will be looking at is a card game. Maybe. If you're a beginner in Mavic analysis, what you might do first is checking this file. Let's say in detected easy or something similar. It tells you it's a .NET file and then you go straight to the endspire because you know the endspire is a .NET decompiler and let's load the file there. You check the entry point and you see, oh, wow, this is initializing some kind of, well, graphic user interface probably. And well, if you check the strings here and the method names and the class names, it really looks much like a card game. It says something like other player cards received. There are some, well, game states, the game server is, you know, it really looks like an innocent game. Now, I got the sample because someone on MavicTips.com asked me, asked in a thread for help analyzing the sample because they knew it was Mavic but could not find the malicious code inside of this supposedly card game and didn't know where to look for the malicious code. Now, what can you do to avoid rabbit holes like this one? That's actually a rabbit hole. If you now start looking for the malicious code by just, you know, clicking all of the classes and methods, you will get lost in one very soon. The first thing, and that's like the person who asked about this file, they did this correctly. They have uploaded it to any run or you can use any other automatic analysis system that dynamically analyzes the samples. And any run will provide an overview to you what the sample does on the system. So these are the first things you can use to get a starting point for your analysis. The first thing you do is you get some kind of overview and several starting points to look for more. Now, any run will already tell you very valuable things. For instance, it seems like the process will start, will persist using a task, the task scheduler, and it seems that it injects into a legitimate file called recservices.exe. So that's very common for .NET malware to start a legitimate .NET file and then inject into it. And this one, if you check on the, let's see where I find it, the threads tab, you see it says the network Trojan was detected and that there's agent Tesla X filtration in the recservices.exe. So we can already assume it somehow unpacks an agent Tesla executable and injects it into recservices.exe. If we click on the process for it, you see also agent Tesla was detected, you can click on that to get more information. And action looks like stealing of personal data. So here's some folder that has was touched by the file call. Yeah, it seems like some kind of user data for sheet out. And it changes the order on value on the registry for some arbitrarily named .exe file in the app data folder. So yeah, that's pretty obviously malware. And now we need to find out what else is happening. The next thing I also like to look at at the very beginning is virus total. Not only the detection rate is interesting, of course, with the detection rate like this, it's pretty sure that this is malware. And it looks to be consistent with agent Tesla. Since there's some kind of password stealer indicated here, we have some agent Tesla named detections as well. And some say it's like cryptic. So it's packed. Cryptic cryptic means packed. Furthermore, the comments in the community tab, they will say some more automatic analysis systems. One of them is in teaser, which also creates a report and interesting part is that it will try to tell you what kind of malware family it is based on the codes it found in there. So codes and strings. The in teaser report looks like this. That's the original file. And here it just didn't find anything special. But the dynamic execution found the memory module that it detected as agent Tesla. You see it here. Click on that. It has almost 2000 genes that are supposedly an agent Tesla. And also in this rec services.exe. So take note of that, write that down rec service.exe our interesting service to get the payload. Now, we already know quite a lot of things here. But how do we find the interesting part to continue with our analysis, right? It's what I suggest is first use a hex editor, and just scroll through the file. If it's not too big, if it's too big, you may want to check it out with something like protects analyzer first to see interesting areas of the file that you can read. Let's see what products analyzer finds. All right. So this is the visualization of the file. Firstly, this is a net file that it has two kinds of resources. products analyzer is a PE viewer and parser. It will show the this part of the image shows structures related to the PE file. So the resources mark green here, they belong to the PE format. And you can already see in the bipolar that this looks like an icon. And indeed, if you check the resources here, in resource hacker, you see that this is indeed the icon that Windows would display if you append a .exe extension to the file. Now, that's not that interesting for us. What is interesting is this blue area here, because blue in the bytecode means visible asky. So it's actually two blue areas, but this is a larger one. And we should check those for strings that are interesting. A lot of times Malware may pack the payload into a big string. Or in this case, the second thing that's interesting is this area here, because that's high in entropy. So it has some probably some thing packed into this area. How do we check those? And we can use the hex editor. And we can also use strings exe from this internets, right? Okay, let's check it in the hex editor, we could go approximately to the area where we found the blue stuff. That's here. Well, that looks like these are method and class names for the internets assembly. And strings can be quite a bit hard to read in the hex editor. Oh, what's that? Well, it looks weird. Pretty weird. It says quotes on life and repeats that all over. Well, definitely something I would take note of because why would it do that? Let's scroll to the beginning. This seems to be a net resource. You see here the header of the resource and advantage of using hex editors, you see like the structure around those strings. So we can check the net resources with the inspire, for instance. And if you do, which is also what I recommend doing before diving into code, run strings that easy from this internets on your file, pipe that into txt file, then check them just scroll through. And here you can read the interesting fun. So see if there's anything you might want to take a look in the code later. That things you want to look out for if you check on dotnet files, which do process injection is something like invoke entry point, get method, and so on. And we can see something like that here. Also, here's an invoke just reverse. So it seems like these are interesting starting points for us to search for the code that does the injection or unpacking of the payload. And yeah, that's what we're gonna do now. Now it's time to check the code. Firstly, the section of the resources. We saw a reverse invoke, right? I think I would just show you several ways to find this particular code of interest here, the three ways for it. Firstly, the resources, check the resources. And what you can see is this is big quotes on live string. First, note the name, write it down as AS that's the resource with that string. Secondly, we have this image, which is not really a useful image. If you see an image like that anywhere in the fall, most of the time this is packed code, or a packed assembly disguised as kind of a disguise. It's not really a disguise because it's pretty obvious if you see it. And if you saw it once, you will recognize it again. So this is how an image looks if you just put some random crap into it. So both of these are quite interesting because there's always a reason behind those things. Why would you put someone with this quotes on live here? Now, what you can do, you need to find the location, the code that uses these resources, right? So you go into the properties, resources, there's the resource manager for the .NET file. And then you find gathers and setters for the resources. So that's the first way to find the code here. There that's the image. And as AS, that's the quotes on live string. And then you right click analyze, you will find just by and then you see a method named rate that calls this resource and does something to it. Second way to find this, that was the first using resources. Second way you could have found this is using the search function. We already know this reverse invoke way was kind of weird. So what we search for is that, is that, right? You say, I want to search for number of string is like this reverse invoke. And now you also get the rate function. So using that, you could have found the interesting method here. The last thing you could have done, we know from the community comments that there's a Yara signature match on reverse base 64 encode exe. Well, that's quite interesting. So what you can do is the rule link, you can download the rule, right? You click on raw and save that onto your desktop, save it. And then you'll run Yara on that file. So Yara, we tell it our rule set. And we say this game. So let's put the minus s there. What it does, it shows the strings of match. And then it also shows where it matches location. And it's 24 C to E. So open this up and the hex editor, where is the game here? And go to that location, go to C to E. And that's where you land. Here. That's obviously some kind of, well, it says this is a reverse base 64 encoded exe string, this part here. So you know, okay, here's some kind of base 64 string that this liven quotes is in between. It's quite weird. So you could have seen that this is an interesting area for you this way. And then later on got to that method here. So now the interesting part, what does it actually do? It will get this resource and replace the quotes on live with a. Let's save the resource first. That's the resource we can right click save. We save it as txt because it's big string. And then we open it up in, yeah, in notepad plus pass and do the same just replaces with a place all. And that's our string basic C for strain. Now we know it's reversed. So where is it? What does it do? It gives the reversal. This method actually reverses the basic C for string. And then it does a conversion from base 64. We can easily do the same. I prefer to do this with Python. So then we will open our file for reading and say, this is relives first line. Let's print the first 100 characters. And I want the first three strings to disappear. Because it seems to start with non character stuff. And then we have that that looks better. And I want to reverse this as well. And we get a reversed string. That looks good. And now we just decode that and print that to file base 64. We can say B64 decode and then our reverse string. And we save that to decode it. So and then I open this file, new file called dump for writing and needs to be binary file because that's what we have right now. Let's check it decoded looks like that. And yeah, that that's about right. This is the m that mz and here's the dot sub message. So it looks correctly. And we write this decoded to the output file name dump and exit. Now we don't need to do closing on the streams. In case you have Python, Python program and we don't need to close it because when I exit Python, it will also close the streams here. Okay, here's the dump file. And as well as with the original file, this code game file, we will do the same thing and just put it into products analyzer for visualization and strings.exe to check where the interesting parts of the file are. But also we know without that, what's interesting from what is being called, which method is being called, you can see that here. So check that and if you already find the stuff that's interesting, then it's good. But otherwise, I recommend the same thing that check it out and hex it or check the strings and so on. So we know it calls a method named like that. So already knows quite obfuscated. And it's in this class and in this namespace. Let's drag and drop it in here that I'm found. Maybe it's our agent Tesla code. It's a DLR. This looks quite awful to that. The method, the relevant method is this. So we find it here. That looks obviously awful. So we need to deobfuscate it. But take note of how it looks like, because this seems to be the only method with three strings as parameter and void. So you can kind of find it later when you use D for that. With this pattern, where it's a dump. So now we have a clean dump. That's a bit confusing. This is called sparta. And this one is the method we are looking for, because as I said, it's string, string, string wide. So that's the method. And that looks about right. So we need to know what it does here. If you check out this, it seems to get something from the resources. And then it extracts some kind of pixel data from it. And then it does some form of XOR decryption using this array. And this string is a kind of password. So you could copy all of this code and put in the strings from the caller. But it's far easier if you let them ever do this dynamically, the unpacking of the payload. It takes less time at least. And we already know, this should be interesting for you, because here's a sleep. So this sample waits 38 seconds before does it. So just running it and running some kind of like mega dumper will not get you the payload you need to wait. So let's do this. We will start process Explorer. Furthermore, you know where the payload is located in this rec services.exe. So that's what we will wait for. We will append.exe extension, run it. And right now it doesn't do anything at all. The CPU is not spiking here. It should have some some CPU usage. That's now it's not sleeping. So let's check out mega dumper. We run it with administrator privileges. And once it has started executing the payload, we should be able to get it. If you run mega dumper now on this, I know it starts, there's rec services.exe. That's what we want. And we run the dump by mega dumper. So note the directory that the files are located. Since it just ran some net executable from the dot net framework, it also put the dumps in there. An easy way to get there is to right click and go to location. And now I think we should kill the malware process. So we should find the dump in there. There they are. Continue. So and here we are. That's the payload. That's it. Everything for today. You can also put this into the inspire for analysis. It seems to be packed with Confuser X. I didn't verify it. But in teaser says it is. Yeah. So you might want to use some kind of deal for skater like the Confuser X. No, I think it's unconfused x or no conf no fuse x. Anyways, you will find the operators for this type of obfuscation. And then you can analyze the payload if you want to but agent has analyzed already. So yeah, that's it. Alright, so to summarize, what can we do to avoid rabbit holes? What are good habits? Well, you should check every file that you get first for strings. And secondly, check out an hex editor for interesting parts. If the file is very large, use visualization to find interesting areas. And if you, well, the advantage of these is they are not dependent on any file type. So usually, because if you use, for instance, either to check the reference strings view, that's not a replacement of this internal strings, because the strings view will show strings that are referenced in the file. So it's dependent on the file format and what the file actually does with these strings. Whereas strings.exe, you can apply to any file of any type. And strings that are never referenced will also appear. Same for the hex editor. Of course, there are some hex editors that read file types and so on. But generally, you have just some hex data and some kind of ASCII string view, which cannot be fooled if the file type is somewhat awkward, corrupt or whatever. And when you do this, take note of all the interesting areas that you find the interesting strings that you want to check out later. And when you get stuck, you should, you know, stop, take a break, take a break, maybe discuss with some colleagues or friends, your problem, or talk to a rubber duck. But this will also, you know, free your mind a bit. And then you might get back to checking more like the overview of the file, the surface of the file where you might go dive deeper into. Also, automated analysis sandboxes, they are great if you, if the file has sandbox detection that detects our sandboxes. Because you can see already if the file does, like sandbox injection or similar process injection, so where to know where to look for the payload eventually. And yeah, last but not least, I would also check out, like file format viewers before diving into the code. For instance, if you have an MS-DOS file, use some kind of MS-Office file, use some kind of format viewer for that file format. Or for PE files, you have PE viewers and so on, to check out the resources there, for instance. So, yeah, that's it from me. And if you have any other tips to avoid rabbit holes, please put them in the comments below. And let's see you next time.