Emotet Evolution: The Spreader Gets Integrated

Introduction

On July 19, 2017 we wrote about the incorporation of a spreader component into the popular Emotet downloader. Just a short while later, a volume spam campaign was initiated that delivered Emotet with further modifications from the samples that we had analyzed. This post documents the changes we have observed.

Share:

Share this page on Twitter

Share this page on Facebook

Share this page on LinkedIn

Key Findings

• Emotet now uses a modular framework to load the network spreader component, which was previously loaded as a separate package.
• This makes it both easier for it deploy the spreader component as well as more difficult to detect, since it’s running from the Emotet process space without necessarily touching disk.

Campaigns

After a short hiatus, Emotet has recently resurfaced with an updated version of its previously documented loader(1,11). On 24 July 2017, a massive spam campaign kicked off with a different version of Emotet being used than was previously seen. One interesting change observed in this campaign is that the network spreader malware was no longer delivered as a separate component, but was instead delivered as a DLL with encoded strings using the same string encoding as Emotet itself.

Emotet

This version of Emotet, like the previous one written about by Cert-PL(1), has very similar C2 structure with a few minor changes.

1. The first change being related to the botId that is generated, using a similar format as was explained previously (1) but with these exceptions:

Figure 1 BotId

2. For the C2 protocol itself, the bot still uses Google Protocol Buffers(6), but the protobuf definition has been slightly changed. There’s the addition of two fields into the registration request data sub-message:

syntax="proto2";

message regrequest {

        required int32 command = 1;

        required string botId = 2;

        required fixed32 osVersion = 3;

        required fixed32 crc32 = 4;

        required string procList = 5;

        required string mailClient = 6;

        required string unknown = 7;

}

3. There’s a CRC hash of the exe file on disk and a string field that was empty in the sample we analyzed. Also worth noting is the fact that the mailClient string was empty, which may indicate its use for other functionality. The CRC hash is interesting as the response if the hash is not correct, the delivery is a new Emotet binary. This could be an easy way for updates to spread more rapidly. The binaries appeared to be repacked/recrypted roughly every 2-4 hours.
4. The sub-messages themselves are also compressed, so before being put into their wrappers they are ZLIB compressed. This isn’t just the case for the registration request but also the case for the decoded responses from the C2 as can be seen by the ZLIB header in the decoded data after the first 4 bytes (0x78 0x9c).

Emotet Network Spreader

This new version of the spreader component has a number of changes compared to the SFX RAR package we previously blogged about(11).

• Now comes as a DLL
• Involves code reuse from Emotet
• Designed as a module

The first change is that the spreader code is no longer in a package format intended to be delivered, but instead is now a DLL. This transition is noteworthy because it indicates a move from a package delivery method to a module-based approach, where each module runs inside the same address space as Emotet.

Modularity

The first three modules are the same described in other reports(1) as being MailPassView, BrowserPassView and the module to interact with Outlook. The new DLL however is much smaller than the others, it uses the same code as Emotet to handle rebuilding its imports and also for kicking off its main code loop through a callback function in CreateTimerQueueTimer(7).

It also uses the same string encoding routine as Emotet.

These code similarities demonstrate the move to a modular mechanic. This is also proven later in the code when the bot gets the current process filename on disk, which will later be used to copy the file from the current system to the remote system when spreading. This works because the DLL is intended to be ran from the same process memory space as Emotet.

After this the module gets the currently logged in user with WTSGetActiveConsoleSessionId and QueryUserToken before calling ImpersonateLoggedOnUser in order to execute API calls as the currently logged in user before kicking off the recursive function that will enumerate network resources.

This network resource enumeration is done in the same manner that was previously discussed, but this time it first attempts to connect to the remote resource as the currently logged on user before jumping into the bruting portion of the code.

Password bruting

The bruting code is very like the previous package discussed as it enumerates available logons and uses an onboard password list. If all of these attempts fail, it moves into attempting to brute the Administrator account on the remote system. The biggest difference here is the more extensive password list, which when decoded is 1000 passwords in length. Choosing to include 1000 passwords seemed odd, but after a bit of searching it appears the list is the top 1000 off of a publicly available password list on github(8).

After successful login, the spreader code will attempt to copy a file onto the newly connected resource. As previously mentioned, this is different than the previous SFX package. This new modularized version will copy over the file associated with the process this module is running within onto the new system.

As with the previous version, a service is setup and kicked off on the remote system in order to execute the file.  But, instead of having a filename and service name hardcoded into the bot, it simply uses GetTickCount and an swprintf function to generate the name of both the exe and the service that will be created on the remote system.

Decompiling this and cleaning it up can create an overview of this creation that might help to make things clear.

Conclusion

Spreading appears to be the new in thing for 2017 with recent additions of a spreader module being added to TrickBot(9) along with even more additions being documented by other researchers(10) perhaps it’d be better to call this summer, the summer of coding for malware development.

I would like to thank researchers Joshua Platt and Brett Stone-Gross for their collaboration efforts on this research.

— Jason Reaves

IOCs

References:

1. https://www.cert.pl/en/news/single/analysis-of-emotet-v4/
2. https://blog.fortinet.com/2017/05/09/deep-analysis-of-new-emotet-variant-part-2
3. https://msdn.microsoft.com/en-us/library/windows/desktop/ms694363(v=vs.85).aspx
4. https://securelist.com/analysis/publications/69560/the-banking-trojan-emotet-detailed-analysis/
5. https://support.microsoft.com/en-us/help/3034016/ipc-share-and-null-session-behavior-in-windows
6. https://developers.google.com/protocol-buffers/
7. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682485(v=vs.85).aspx
8. https://raw.githubusercontent.com/danielmiessler/SecLists/master/Passwords/10_million_password_list_top_1000000.txt
9. https://www.flashpoint-intel.com/blog/new-version-trickbot-adds-worm-propagation-module/
10. https://blog.malwarebytes.com/threat-analysis/2017/08/trickbot-comes-with-new-tricks-attacking-outlook-and-browsing-data/
11. http://www.fidelissecurity.com/threatgeek/threat-intelligence/emotet-network-spreader-component/