Tracking Emotet payload: IcedID

In June 2017, Fidelis Cybersecurity was alerted to a new banking trojan that appeared to be doing very small delivery campaigns for testing purposes. This malware has since been named IcedID by IBM(1), and remains alive in an ongoing development cycle. IBM’s own report provides a good overview of the malware, and as such our report is meant to provide supplementary research to the community.

Share:

Share this page on Twitter

Share this page on Facebook

Share this page on LinkedIn

Key Findings

• IcedID, active since at least June 2017, continues to be an active threat today.
• In July 2017, IceID was updated to include spreader functionality.
• We include the target list, bot history, and encoding mechanism details to extend community knowledge.

That early instance of IcedID was using a crypter not seen before, and as such we wrote a detection in order to find additional samples or a potential delivery mechanism. That effort resulted in roughly 30 additional samples using the same crypter spread out across a few malware families. Tracking the crypter led to a number of Emotet samples, which after pulling payloads for a few weeks we managed to get a IcedID delivery from Emotet confirming suspicions of Emotet delivery based on crypter reuse, along with IBMs reporting of Emotet deliveries.

Early instances of IceID:

The bot is setup to either accept no parameters or a switch parameter of /w or /s. The parameter ‘/s’ causes the bot to skip establishing persistence, while the parameter ‘/w’ is used by the unhandled exception filter setup by the bot to restart itself.

Figure 1 Command Line Parameters

Strings in the malware are encoded with a custom XOR routine with a DWORD xor key that gets permutated for each byte iteration on the encoded string. Below is IDA python code to decode the string:

Figure 2 String decoding

The decoded string output is shown below:

SOFTWAREMicrosoftWindowsCurrentVersionUninstall
SoftwareMicrosoftWindowsCurrentVersionRun
C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=(c) 2006 VeriSign, Inc. - For authorized use only; CN=VeriSign Class 3 Public Primary Certification Authority  - G5
CN=.com
%0.8X.tmp
HTTP/1.1 200 OK
Content-Length: %i
Connection: close
%u           %u           %s
%s /test.php?%c=%u&%c=%0.8X%0.8X%0.2X&%c=%u&%c=%u
&%c=%u&%c=%u&%c=%u&%c=%u&%c=%u
application/x-www-form-urlencoded
 HTTP/1.1
Connection: close
Content-Type: %s
Content-Length: %u
Host: %s
%u.%u.%u.%u.%u.%u
%0.8X%s
D:(A;;GA;;;WD)(A;;GA;;;AN)S:(ML;;NW;;;S-1-16-0)
RuntimeBroker.exe
GET /data.php?
 HTTP/1.1
Host: 127.0.0.1
Upgrade: websocket
Connection: Upgrade
tmp%0.8X01.dat
SoftwareClassesCLSID

The onboard config, C2 list, and needed RSA public keys are also stored in an encoded form. These are decoded with a different routine shown here:

Figure 3 Other data decoding

Initial C2 communications contains the parameters k=&l=, along with OS information. The return data will be a list of numbers, each one corresponding to a unique command to run. The malware performs a lookup by taking the number and using it as an index into a jump table.

Figure 4 Jump table for C2 commands

Some available commands include:

• Pull target list
• Update C2 list
• Update
• Winexec
• Pull down process information
• Initiate VNC
• Read registry data
• Start deleting files from current directory

The remaining C2 communications are encoded by having an 8 byte RC4 key prepended to an RC4 encrypted blob. Once decrypted, the blob of data has a 4 byte marker (‘zeus’) followed by a 4 byte length value. The rest of the data is then decompressed depending on the header, either GZIP or DEFLATE is used skipping the GZIP section if no GZIP header is found. This decompressed data will then have an RSA signature hash on top of it when the returned data is an updated list of C2s.

Figure 5 Decode RSA Public key and Check Signature

C2 data is stored locally in then registry using a technique reminiscent of Vawtrak, where it takes some hardcoded strings and mutates these strings along with a DWORD based on computer data. Instead of creating a pseudo random string like in Vawtrak, this malware instead MD5 hashes the string, and then updates the hash with the computer DWORD value,and then finally produces a unique hash which is turned into a QUID for data storage in ‘SoftwareClassesCLSID’. This data is encoded just like the blobs of data from inside the malware itself, except the DWORD key is the computer based DWORD.

Spreader Update:

In early July another version of this malware was seen with two immediately noticeable additions. For one, the data section of the binary was now encoded to completely hide any and all strings. After decoding this section, the strings previously seen were still encoded in the same manner as the earlier version.

In addition to encoding its data section, there was also a new command present, a spreading command. There are additional encoded strings related to the report it builds as it attempts to brute accounts and spread.

[WORM] Start
[WORM] InDomain
[WORM] InDomain = %u
[WORM] InLan
[WORM] End
[WORM] AD Admin List %p
[WORM] AD Admin Brut Fail
[WORM] AD Admin Brut U:%ws P:%ws
​[WORM] I'm Dom Admin
[WORM] AD PC List %p

Password list for bruting:

Figure 6 Bruting Password List

The spreading component to this banker was added very closely to the same time period as Emotet added their first version, however code comparison showed that it was quite a bit different.

At this point we began closely monitoring the infrastructure and webinject target lists, such as their addition of lik0sa1.com to the webinjects on 13 Oct. This information is parsed and detailed in the tables that follow.

IOCs:

1cd6f992fbeee0a66e1c329e15db71fe891ae0e845867d6d30df867babe5bed6

f3c98c0dce4e114ba1756da299c48a9430b9df93f2c3d030d21096b5d2418c7b

mytimearena.com
myzonearena.com
myareantime.com

IP used and date noted:

Jason Reaves,
Principal Threat Researcher

References:

1. https://securityintelligence.com/new-banking-trojan-icedid-discovered-by-ibm-x-force-research/