Last year Fidelis Cybersecurity posted an update to our previous research on the Emotet spreader module(7). Our analysts continue to monitor this threat however, due to ongoing Emotet activity recently, the Fidelis Threat Research Team recently dedicated some time to check out an updated sample.
We decided to do the full break down on the malware and its modules to verify whether the C2 protocols were the same and also release updated technical data to the community. While in the process of reversing the modules, we noticed the spreader module looked different and this blog will cover the modifications we uncovered during our analysis of the updated Emotet malware.
Emotet Network Spreader
For starters, the new sample was larger than it was when last analyzed. Change in size does typically indicate alteration. Once we dug in we realized the new version is identical to the previous version except for two key differences:
- Emotet now comes with NetPass.exe onboard
- Strings have been obfuscated instead of encoded
While the spreader still comes with an onboard password list (10), it also now comes with two embedded and XOR encoded EXE files. After decoding the files we can see that they are the 32bit and 64bit version of NetPass.exe(8) which will be executed with the argument ‘/stab’ in order to dump any stored network passwords onto the system. This is a crude addition similar to their usage of other NirSoft utilities as modules which allow additional passwords to be utilized as the malware spreads around the network. This technique also capitalizes on any potential password reuse across accounts.
Most of the strings for this spreader module are obfuscated instead of encoded as the other modules have encoded strings –similar to how Emotet encodes its strings. The exception being that the onboard password list is still stored encoded.
The above is an example where we can see the string ‘Administrator’ loaded in chunks.
Strings used to create file names and service names are similarly obfuscated.
Instead of manually typing this we can utilize a similar technique to deobfuscate H1N1 strings which use a similar method for hiding its strings. This involves using the unicorn emulator(10) in python.
from unicorn import *
from unicorn.x86_const import *
STACK = 0x90000
code_base = 0x10000000
mu = Uc(UC_ARCH_X86,UC_MODE_32)
complete = "c745e425007500c745b425007300c745b825007300c745bc5c002500c745c075002e00c745c465007800c745c865000000c78578ffffff22002500c7857cffffff73005c00c7458025007500c745842e006500c7458878006500c7458c22002000c745902d002500c7459463000000c745dc5c004300c745e024000000c745cc5c004100c745d044004d00c745d449004e00c745d824000000c745ec43003a00c7459825005300c7459c79007300c745a074006500c745a46d005200c745a86f006f00c745ac74002500"
mu.emu_start(code_base,code_base + len(binascii.unhexlify(complete)))
a = mu.mem_read(STACK,4096*2)
This gives us an output of the strings previously built which also lines up with strings we have previously seen in the Emotet spreader module.
The onboard password list is still stored encoded with the normal Emotet string encoding routine as seen below:
To find the NetPass executable we needed to investigate some of the large chunks of data that are being referenced.
This function is passing in the offset to a rather large chunk of data, investigating the routine shows it loading in a 128-bit value.
Shortly after it begins XOR decoding out the data that was passed in.
The key as we can see below is just a repeating DWORD value.
A quick investigation into this data by taking a sample of it shows that it is a XOR encoded PE file.
Python>key = GetManyBytes(0x10004000, 16)
Python>blah = GetManyBytes(0x10005000, 500)
Python>blah = bytearray(blah)
Python>key = bytearray(key)
Python>for i in range(len(blah)):
Python> blah[i] ^= key[i%len(key)]
A quick way to decode out every potential file embedded in this sample is to simply XOR encode the entire file and then dump out all the PE files from it, this works as the data is stored on an even offset within the file. Doing this provides us with two PE files, a 32bit and a 64bit version of NetPass from NirSoft.
Now that we’ve found this little addition we can take a look at its usage in the overall setup phase of the spreader module.
As can be seen in this overview of the setup phase of the spreader module, it is much the same as the previously documented version except for an addition involving the executing of NetPass. After this initial setup, the DLL moves into the actual spreading portion:
The spreading portion is similar to our last post. Upon a successful connection to the remote machine the Emotet sample on disk is copied using a random name based on the tick count and then a server is created to execute it which also uses a random name based on the tick count.
Network spreading appears to continue to be a development priority for malware authors, this trend isn’t looking to stop anytime soon. The research community appears to have answered this trend with researchers from many fields in cyber security adjusting their focus to lateral movement and pivoting in enterprise environments. Attacks such as the one being utilized by Emotet for spreading however are related to old problems in our field; password policies. There’s nothing like an ever-evolving current threat to help us remember why these old principals are still important to this day. Fidelis threat research team will continue to monitor threats such as these to help the community and our customers stay ahead of our adversaries.
|220.127.116.11:4143||Emode Module C2|
|18.104.22.168:4143||Emode Module C2|
|22.214.171.124:443||Emode Module C2|