 Last week we analyzed a downloader that was delivered via a ZPAC archive. We decrypted the downloaded file and afterwards we unpacked the payload. This payload is a topic for today. We are going to extract the configuration and to do that we are going to de-opfuscate payload. Let's continue with our analysis of the injected payload. I've cleaned up the desktop a little bit. All of our files that we previously had and looked at are now in the analysis folder. And I added another tool called shed which I'm going to try on this sample here. Let's actually rename this because we know it's the injected payload. Let's name it payload. And let's iterate a little bit more about the strings that we see here because when checking this file first we see it has a lot of encrypted strings and a lot of strings that indicate some kind of obfuscation. So we will have to de-opfuscate this. And if you open it in the N-Spy you will also see that the code is barely readable. But there are some strings that are still not obfuscated like this. And since here we have username, password, host. The other thing I see are these. These are very typical of NetReactor. So I'm going to assume that this is NetReactor obfuscated. And we also have strings here that seem to belong to some kind of config. So we can check these and see what they contain. So what they point to in the code. This is quite interesting. So here in the N-Spy you see the obfuscation mess. So it's pretty ugly trying to find something in this code here. We could already look at the plaintext strings that we found. Something like keylogger we see here. Enable keylogger that is here. I want to know where this is set. So I go to analyze assigned by. And it's set in the cctor method of jre class. And here is some mess of functions to which determine the value of the keylogger. Plus we have a switch case statement here. It's some control flow obfuscation. And I would really love to know what the values of all of these are. For instance also the telegram API. Let's see if we find any of those. It seems to be the config. Firstly I would like to try shed. What is shed? That's a way to dump and trace objects from .NET modules or .NET assemblies. And we see here what we should probably try is a minus minus exe option to check our file. Take our payload and we also set a timeout. Something like 30,000 probably alright. 3,000. I'm not so sure. Let's make it 30,000. And see what happens. I'm also checking it here. What we see now shed is running the payload exe. We just got to wait until it's done. So that was a whole hell lot of output here. And we actually could try shed on the injectors and see if it just dumps our module that we had there. When you scroll up you see quite some interesting strings. We see some references to the Thunderbird, Mozilla profiles and other interesting data. So it looks pretty much like a stealer. Also here data of various browsers. Here is a file that let's see if it's still running. I guess it's fine but we could check if this was being created on our system. Doesn't look like it. Here's some email clients, more browser data string. And here we have Telegram API and a user agent. So this is very likely part of the config that we just saw. You can check the result. It will create a folder named results with a number here. I think that's a PID. And here you also see the output log again. In case you want to find things, also a little bit more detailed I guess. Let's find the Telegram API it is. So these seem to be the resolved strings from the config because we see stuff like false, 23, these look like they belong to the config. But actually if I want to know the exact config it would be better to be able to assign those to the variables here. So I want to know what kind of string is assigned to let's say startup directory path. Okay it says one. But to all of these screen intervals, the 20 maybe that we saw there we don't know yet. So how do we do that? Now I said this looks pretty much like netreactor to me. And because of that we are using a tool named netreactor slayer. That's this one here. So we execute the help for that. We can simply execute this with our assembly file. So let's do that. Let's just take all of the options you see here. The standard options and how you can change them. So in brackets the default option is stated. So all of these are generally set to true unless you specify it otherwise. So let's add payload and see what it does. So payload underscore slayed. That's the new one. And in terms of the application flow this looks already better. So here we already see some of those options. Let's see where they are set. But this didn't work. So this file is the de-opposicada mess something up here. Because this was there before this method. See it said it couldn't find any encrypted methods so it didn't decrypt methods. So I don't think it has to do with that. But let's try to actually use some of those options to fix this. The thing is if we execute this it will probably crash. So let's see. And you could see briefly that it's calling the Windows error reporting. So this one crashed. So we have to tweak this a little bit. Let's see how we can tweak this. I think I will need the window alongside of the other. So what I would like to do is let's try to keep the obfuscator types and the metadata tokens and the old stack value. Because then we should still have all of the de-opposcation happening but not delete as much as we would delete before. So same thing. Let's try to find those again. It looks better. That looks way better. We recognize that this is set statically and replaced this with a call to this method here. So just like before, that's interesting because it obviously gets the string from an encrypted resource. Is it encrypted? Is it this one? Show in hex editor. Yeah, this is encrypted. That is also encrypted. Anyways, this is helping us. We could now manually decode this but it's also still a little bit of a hazard. So I figured let's try if we run another pass of netreactor if it can solve this now because it looks like a basic obfuscation. And let's just try this and I'm going to rename this. I'm not sure if it's causing problems if there's already a slate in the end. payload underscore two. And I didn't specify any options here because I figured now it looked quite clean. All of these cctorn methods were gone and it throws an unexpected error while decrypting resources. So maybe that's not a problem. And that is interesting because it decrypted additional strings where before we had just one or two strings here. There are now a lot more so it was able to do some more decoding. I wonder if it runs now by the way. Let's see. Let's see if this messes something up or if it works. It doesn't seem to crash. That's for sure a good sign and it's just running now. Okay, let's kill it because it seems to work well. And let's see if this did the trick. There's some control for obfuscation. It's not too bad though. And that did the trick. That's awesome. Now we got it. We have the whole config here in plain text and know what each of these values do because conveniently the names are still intact so we know what this is supposed to mean. So this is it already. I hope you learned something. If you have any questions let me know and see you next time. And as usual I put a link to those binaries in the description of the video below so check it out. 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 the 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.