 Have you ever heard of Melvier that abuses Z-Pack archives? Well, I haven't until I read an article by Xavier Mertens, they had this kind of Melvier in their honey pot, so it seems to be in the wild right now. And that got me interested. I analyzed this file and I decided to do a two-part series because analyzing it is like, it would take some time to get to the config. For part one of the series, we are going to unpack the Z-Pack archive, de-bloat the sample, we will decode the downloaded payload, perform some string decryption on the downloaded file, and then perform injection unpacking to get to the actual file that is being injected. The next second part of the series probably going to be online in one week from now. This will then finally cover obfuscator identification and de-obfuscation and then seeing what the config looks like. So that's basically it. Let's get to work. If you want to follow along, please check the video description below to download the sample so you can also do the same in your app. So this is the original article where I got this sample from Melvier dropped through a Z-PAQ archive. And this is quite unusual because I can imagine that many people will not be able to open this archive in the first place. So I really do wonder if there are any people who got infected this way. Anyway, when you check this sample, we have now the 4th of November and you can see here it's still at zero detections and that's because most of the Antivirus products cannot unpack this unusual archiving format. So when you unpack this, I do expect to see a rise in the detection rate. Now the person who found this Melvier said they had a quick look and that they couldn't figure out how to run the Melvier file and that it doesn't seem to work in their lab. So let's see if we can get it to work. Here I have our Melvier file and to unpack this archive I downloaded zpac.exe. This is a command line tool that's also available for Linux and I downloaded obviously the Windows version. So we check the help. We see it's using x to extract files. So we are doing this too, wait, without the minus and this extracted this exe file. So this file is almost one gigabyte in size and we do not really want that. So there are several ways you can deal with that. Firstly you can just have a look with a hex editor and when you scroll you should see oh wow this is all zero bytes here. So the quick and dirty method for me is to just select the blog up until the end and then cut this off. So as soon as you see okay let's put the cursor here select blog and then add a bunch of zeros and then press delete yes. So now we obviously still got way too much here. Let's see if we can delete a little bit more. It doesn't have to be exact as long as the program is not way too big. So this should do it. We select it from here and just save this one and now tools or sandbox systems shouldn't have a problem with this file anymore. So we can check here there's still a bunch of zeros in the overlay and if you really want to get rid of them you can check where the overlay starts and cut from this offset here or another alternative is a new command in binary refinery that's able to automatically de-blow samples. So this would work as well. It's not certainly necessary though to analyze this file. Let's check now how it behaves if we just execute it. I'm going to see in system informer if it's creating some child processes and whether it runs at all and we see it starts a child process and then it crashes with the Windows error reporting files at least started. That doesn't have to mean anything though. The article mentioned that this is a downloader. I don't have an internet connection on this machine so let's actually look into the strings. So this one doesn't seem to be too strongly obfuscated. We have some clear text strings one hinting to a media fire download dot wab file which is usually an audio file and this seems to be quite small this application. So let's look into it with the end spy. So this is the main and that's where it starts. This is looking a little bit weird. I'm going to check on is by also it's I'm not sure if this is all correct. So we go to main we go to this function. This is looking way better and here yeah that makes more sense and here we can actually see what it is doing. So it's loading this assembly that's coming from this function right here and then it gets this class from this function. So it's in the namespace wz yys that is the class name and this is the method name that it is calling on this assembly that is loaded right here. So we want to know how this assembly is loaded. We look into we look into this method and we can see here a triple d s decryption on what data that's the question where does the data come from. So this should be fairly easy. Here is the two base 64 strings that we saw are just the key and the IV. So you hover over that we see the first one is the key. This one this is the IV and the data comes from here. It's coming from this stream and the stream is loading the data from this function and this is the function that will load this audio file. So in this case good idea to check in is by because the code looked very weird and this is the actual download location. Now I checked the download location and it's not available anymore but I could find this file on VarusTotal. So the encrypted .var file. If you want to learn Java analysis from the ground up then check the link in the description below. There's a link to my Udemy course for beginners. It contains 11 hours of video content and the link is a coupon link that's a little bit cheaper for you than buying it from Udemy itself. So check it out and maybe I see you there. So I got the audio file. Let's first see. I mean we know it's encrypted. There's probably not much in turn when it comes to seeing any strings in here and indeed it's not. It's not useful in but it's still interesting to check just in case you find anything that's in plain text. Same thing we should check with a hex editor if there's anything that looks like a structure but this just looks like encrypted data if you scroll through. So it doesn't seem to be any additional data on that file. And now we can use our knowledge not from this one. This was useless but this knowledge to decode it. So you can use Cybershift. In this case I will be using binary refinery. So I'm telling binary refinery to use a base 64 string as the IV and as we know the IV is this part and then it expects the key so we take this part and we can verify now with peak that indeed this decoded some executable. And here we have our file. Same thing as before. Let's check with the strings. So that seems to be the name of this module and it's a DLL file. It's also .NET file and here we have some interesting strings that might contain some data references to several cryptographic algorithms and some resources the .NET resource here. So that's basically everything that's interesting. The strings seem to be encrypted at least I do not see much in terms of strings apart from general data, metadata. So I'm gonna rename it. So this isn't looking too well in terms of trying to understand this because the methods are barely readable. It's a smart assembly obfuscated file. Let's just run the for dot to clean up the methods a little bit. And this is a little bit better. I mean now we do not have an entry point in the DLL but we know what kind of method is called from this file. We saw that here in our let's see here. So the member that is being called or the method that's being called is this one gwjgucx in this class and that's where we find it. Now in terms of determining what this does if you go inside of those you will see it's kind of hard to determine. So for instance here we have a process start and the file name is being called with this s method 11. And if you check this one you will see it's calling some hash table and looking up the string. Now my go to method would be to use d for dot with a token to the string decoding method but in this case it didn't really work. So I'm gonna try something else and that is using PowerShell but not only that let's first actually try to see how the file behaves if we run it. So it's a DLL. So let's again observe the behavior right here in system informer. First we need to load the DLL and to do that we use a reflection assembly load file and you can do it like that drag and drop this inside note that this also runs the file so initialization code like code that's in cc-toro is already executed here. Now we are going to call the method that is also being called by the downloader that should be about correct. So and now let's hit run and the PowerShell EXE is gone. So there are two things that are possible. The first one is that this method exits on purpose and maybe it has some anti debugging things. Maybe it doesn't like that we don't have an internet connection or maybe something else is going on. Who knows and could have copied itself somewhere in the background. We didn't check that but let's see what we find in the code and if there's a way like to actually see what the code is doing by decoding those strings. Now the same way we ran this DLL method we can also run other methods. So that's a good thing and that means we can find out for instance what kind of process is supposed to be started here. So and why it doesn't do that or maybe it does that and we just didn't see it because of the refresh rate in system informer. Let's just load the file again and this time we will try to call this method instead. So it's class 3 as method 11 and put in the number that was used here that is 8510 and it can't find this type so I did something wrong. I know why that's the case so this is not public so we need to edit this actually. Edit the method and we say public scope. Okay now it has the public modifier and to do that we need to close this and then save the module. Right now we just run PowerShell again and it's still complaining that it couldn't find the type. The class is said also not public. You can actually check the available types so this is basically everything that we see so there are all of the other classes are not available and that's why it didn't work and the very reason for that is that this class here is internal so same thing we need to edit this class. Let me say right click on the name you say edit type and then we will say visibility public say okay so and now again we need to save the module and close this otherwise it won't do that. Okay and now let's try again and we say now get exported types it's still not working. I didn't load the cleaned one that's the reason. All right cleaned and now we see class three here and the powered by attribute is gone because we added because of d4.it removed this one and now we can also execute our method so all right it works so we have now a string decoder for this and that way we can slowly get to the bottom of what this all means so obviously this here meant cmd so if you really want to analyze what this file is doing you can go through all of these methods and while you have two choices basically you can decode this by hand now so you could just let's do it for this method here so we right click we say edit method so in this way you could slowly de-opposite all of the code the other way you could do it is if you write some sort of de-opposicator with the nlip that does this automatically but keeping in mind that we actually want to find the payload of this method let's take a step back and let's run this again and see at which of these methods it actually stops executing so we can find the culprit so we load the cleaned one it should be the right one we attach the process and we set the break point here so so let's now step through until this program exits so that we know where it stops so either if it's an entire debug method we will find the location where the debugging debugging check is taking place or if something else is going wrong we will also see where it ends up and so let's do this and just step at this point it executes a sweep so we have to wait until it's done so now it's done we step over again another sweep and we are already at the last method so all that comes before this one works and we should step into this one because um we can exclude these as being the culprit so here's a switch case statement it ends up in this method now we are here so this is interesting why that because we obtain a byte array and bytes arrays are generally interesting for process injection they might be used for that so if we step into that we are in this function that's the reverse function and we already get oh yeah we get an array full of data here but this can dump this save it it doesn't look like an image though we can still dump it just a quick look into the dump it's definitely just some encrypted data so let's continue with that it says it cannot obtain the value of this variable that's too bad and for some reason we exit now I'm not sure why this is happening like why it didn't continue like to one of the next steps like this one or this one um but anyways I would like to try and simply add some more breakpoints and see if that works so it will either lend in this function or in this one so let's put a break point here also very interesting because it really looks like it's dealing with some binary data so um looking at the parameters for these delegates here these are likely some api calls and they could have to do with some process injection because we have here process ID so that's the first one that's the second one let's just add a break point here as well and since this was executed this explains why the power shell window is gone after the maverick's finished because it just exits the whole environment so running this again we do not need this break point anymore actually because we set some other ones and we continue execution and again we need to wait because there are some sleeps in between and indeed we are in this method here so that's class 18 method zero we see it's attempting something 10 times and we have here a byte array so checking the byte array yes it starts with 4d5a so we have an executable image here which is likely the payload I uploaded the payload to varus total and this is what we get so it has a high detection rate which doesn't surprise because this file is not actually placed on the disk so all of the scanners that find this file right now it doesn't mean that they will find it when it is executed only in memory so a popular thread label here is agent slar which is agent tesla and we also see here esad says it's agent tesla pro tip esad is most of the time correct when it comes to the malware that is underneath um rising things that's red line well we will see so that's all for today we see each other next time with the payload deobfuscation and configuration extraction see ya and please post below if you have any questions