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
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.
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
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
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.
Useful and additional information can be extracted from the executable if we use
The only interesting strings that I found was
dfsds.exe which is exactly the executable name that it creates as we saw in the Any Run screenshot.
Some interesting library functions like
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.
I’ll jump straight to the interesting files like
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
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
cookie and many many things.
Since this is a .NET application, I started taking a look at it with
Upon opening the file,
dnSpy displayed the original name of this executable which is
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
We immediately spot a base64 string and this is the decoded string that we get:
MHost:http://domalo.online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn3b34w , BHost:http://domalo.online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/46kqbjvyklunp1z56txzkhen7gjci3cyx8ggkptx25i74mo6myqpx9klvv3/akcii239myzon0xwjlxqnn3b34w , MX:DCR_MUTEX-wLcs8o1NVEUtXxJ9n9yf , TAG:UNDEF
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
dotNET.lnk and another shortcut into the
SpecialFolder.Startup by the name of
Secondly, it adds
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
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
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.
|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>|
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