The main goal of this analysis is to test what I’ve learned during these weeks studying malware analysis by following Practical Malware Analysis and their labs. I won’t post every step I did but the most important and interesting findings.

For a professional report written on this malware, please check FireEye’s Report if you’re only interested in using the IOCs and understand what the final payload does to the victim’s machine.

First insight using automated solutions

I always start with a quick automated malware analysis that some websites offer like Any Run, Virus Total, Hybrid Analysis or Intezer Analyze to better understand what I might expect from it and to see if it’s suitable enough for a beginner like me.

Virus Total

I ran some scans using Virus Total to get an overview about the malware I’m trying to analyse and to guess its behaviours.

Without any doubts, the file we are analysing is malicious and also has been compiled by NSIS, a common open source system to create Windows installers.

We can see that there are some registry keys manipulation.

And last but not least, some network indicators including IPs, domains and potentially additional files that the malware creats like for example mnb.exe.

Any Run

I also threw the sample into Any Run for a quick evaluation to see if I can find anything else before getting my hands dirty.

This is the process tree and as expected, the malware creates additional executables and injects itself into explorer.exe process and creates a service called searchindexer.exe.

And finally some network activity with the sketchy domains involved, which in our case should be the C2 server. We need additional information to really understand what data has been transfered from the victim to the C2 or if the victim waits for any inputs from the C2.

Static Analysis

Useful and additional information can be extracted from the executable if we use PE Studio:

The only interesting strings that I found was fsdffc.exe and dfsds.exe which is exactly the executable name that it creates as we saw in the Any Run screenshot. Some interesting library functions like CreateThread and WriteFile can be observed during our string analysis sessions.

I’m not 100% sure about this but every string seems to be encrypted since they contain gibberish values.

Last but not least, there is some sort of digital certificate at the end of the string file which might indicate an attempt to digitally sign this malware in order to make it trusted (I’m not sure neither here, I’m just speculating).

Analysing the file with Ghidra

Without further ado, I started analysing the entry point and the functions called.

There’s this function getting called a lot by passing an integer. At first glance, it seems to load a module or a system function from PTR_s_KERNEL32_0040a240 array and providing an index to retrieve data from it. By taking a quick look at what’s PTR_s_KERNEL32_0040a240, we can see:

And exactly as expected, the function loads into the memory all the needed library functions. I wasn’t able to find anything else interesting besides some file creation, deletion and some queries to the registry.

Dropped files

I’ll jump straight to the interesting files like daaca.exe and dfsds.exe.


Runs injected code in another process is what Any Run says about this executable. I won’t waste my time so I’ll keep moving forward and comeback later if this executables is really needed or if I’m lost again.

I cheated a bit here to be honest, I searched on Google if someone else already analysed this executable and it appears that the whole purpose of this executable is to evade sandboxed environments (too complicated for me to understand it right now and I’ll simply call it magic). Here’s the report and in the future I’ll definitely make a post about this method and better analyse it by myself.


By analysing the strings, I immediately found interesting things like CreateDecryptor, CreateEncryptor, ToBase64String, cookie and many many things.

Since this is a .NET application, I started taking a look at it with dnSpy.

Upon opening the file, dnSpy displayed the original name of this executable which is DCRatBuild.exe.

This one got my attention since the InstantiateIndexer method gets called A LOT and, by taking a little peek at FireEyes report, I understood that it works like a big switch and this is what its implementation looks like:

To deal with the deobfuscation process, I used de4dot and opened the output executable with dnSpy.

We immediately spot a base64 string and this is the decoded string that we get:


Seems to be similar to a configuration file but I have no idea how can it be useful.


To secure persistency over a reboot, the malware has to modify the registry entries in order to execute itself upon boot.

Firstly, it creates a shortcut into the SpecialFolder.ApplicationData called dotNET.lnk and another shortcut into the SpecialFolder.Startup by the name of Sysdll32.lnk.

Secondly, it adds dotNET.lnk into Software\\Microsoft\\Windows\\CurrentVersion\Run\\ with scrss as the name and %APPDATA%\\dotNET.lnk as the value.

Same thing with Sysdll32.lnk but this time it’s going to be added under Software\\Microsoft\\Windows\\CurrentVersion\\Run\\ with Wininit as the name and C:\\Sysdll32.lnk as the value.

Checking if the C2 works

The configuration file that we first decoded are useful here because the malware tries to send a request to the C2 and expects to receive an ok response.

The AwakeCustomer functions simply encodes the given string into an SHA1 hash and appends it to the URL.

Remote Command Execution

Lastly, once the communication is established, the C2 and the infected machine can communicate over HTTP using the GET request we recently viewed, also appending a user identifier, the command that the attacker wants to execute and the data.

And there are a lot more commands that the attacker could excute on the infected machine.


Value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\scrss
Value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Wininit
Path C:\Sysdll32.lnk
Path %APPDATA%\dotNET.lnk
Path Start Menu\Programs\Startup\Sysdll32.lnk
Path Start Menu\Programs\Startup\dotNET.lnk
HTTP Request http://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/212bad81b4208a2b412dfca05f1d9fa7.php?data=active
HTTP Request http://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn3b34w212bad81b4208a2b412dfca05f1d9fa7.php?type=__ds_getdata&__ds_getdata_user=<user_hash>&__ds_getdata_ex t=<message_hash>&__ds_getdata_key=< key>
Domain domalo[.]online


Not gonna lie, this malware gave me a headache and I’m not 100% happy about the end result since a lot of things have been avoided or simply missed because of my inexperience.

Remember, this is not a professional analysis! This is an analysis made by a beginner in this field and WILL contain mistakes or inaccuracies.

If you want to see FireEye’s report, take a look here