Since I am still interested in how Emotet works underneath I wanted to introduce a way to intercept traffic which is exchanged by Emotet bot and its Command and Control servers. 

Thanks to @Cryptolaemus group I got my sample from Cape analysis sandbox and then I run it on my Windows VM.

Communication between Emotet bots and servers is encrypted using AES 128-bit length key and this key is encrypted using RSA public key. That is why intercepting traffic to and from C2 servers does not make any sense – you will not see anything interesting there and you will not be able to decode it.

Emotet uses CryptEncrypt() and CryptDecrypt() Windows API calls from CryptSP.dll library to encrypt and decrypt messages exchanged with C2 servers. Having this is mind, hooking those calls allows you to intercept messages that exchange bot with C2 server.

Hooking dll calls be done in many ways. I did it using pamei and pydbg module from OpenRCE repository. Then I prepared python script which attaches to a running instance of a Emotet client and reads process memory to retrieve packets exchanged with C2 server.

Just after CryptDecrypt() is being called I read the whole buffer which contains a decrypted message. This allows me to have a look into the decrypted message. Also if the content of the message is longer than 100 bytes then I write it into file – since it is easier to analyze afterward – this is helpful if the message contains, for example full PE files. Reading those files from terminal output would be a nightmare so I dump those into files for further investigation.

python.exe emotet_communication_hook.py icmp.exe

Running script which intercepts cryptographic API calls

The full source of this script can be found in my github.com repository. Then, a few days later my bot received something interesting. I have seen lots of bytes decrypted from the coming message. Then after the decryption you can see that this binary message contains PE file.

Running this script requires you to know the name of the process with the Emotet bot. So look for some new process started with a higher PID that other processes.

This is my way of intercepting Emotet communication protocol. You can of course script it so that you will be able to receive payloads and then present it in more readable or usable way – this is just an idea how it can be done.

Having such an interception mechanism allows you to know what Emotet is currently spreading.

The sample that I was analyzing used E2 Emotet servers. Not sure if this is the case in for all Emotet bots but I needed to wait some time until I got an interesting payload from C2 server.

There are plenty of other aspects that needs to be considered like a region from which you are trying to connect to C2 server(if your region is blocked because of some reason or not). If you bot id is blocked because of some reason. Then be patient and wait until something will be shown on your sniffing end.