The Fidelis Threat Research team is comprised of expert security researchers whose sole focus is generating accurate and actionable intelligence to better secure customers. Together, they represent over... Read More
Earlier this year the Fidelis Threat Research team detailed an update with Emotet involving the use of NetPass and string obfuscation which you can read about here(1). Recently I began researching an Emotet sample that appeared to have been updated yet again. Together with researchers from Flashpoint we were able to map out a number of recent updates which I have outlined below.
Updated C2 Protocol
The protocol structure for Emotet is still using Google Protocol Buffers(6) but has changed slightly from the previous two iterations mapped out (5,7). The mail client string was removed and the osVersion data is also slightly different.
Figure 1 Registration data building
The new proto buff definition can be seen below for the bot registration.
Figure 2 Registration proto
Similar to the previous version this registration request is wrapped up into another structure after being ZLIB compressed. This registration data is then encrypted in the same manner previously described using AES and RSA.
The only other large protocol change that I identified was the response data from the C2 which was changed to specifically deal with the modules and payload which was packaged up together into one group.
Figure 3 Response and module proto
Emotet code flow obfuscation
Some of the flow of the binary has been obfuscated by adding jumps into other memory sections which basically just jump back into the previous memory section at the next instruction. You can see that large amounts of padding have been added to the code in order to account for this.
Figure 4 Code flow obfuscation
When the code is executed from its previous layer it is fixed up so that these are not broken.
Figure 5 Code flow obfuscation from debugger
This same piece of code from a debugger shows a jump opcode has replaced part of the block, below we can see that this jump is actually just jumping to the next block.
Figure 6 Code flow obfuscation from a debugger 2
Not too difficult to follow then if you’re proficient with static analysis but it’s enough of an obfuscation to throw off IDAs analysis of some of the blocks of code.
Emotet new module
Emotet also comes with a pretty interesting new module which has an onboard UPNP library miniupnp(4). The code appears to be used for creating port forwarding on a router and then has code for binding to a local port. It seems like a good way to turn your infected residential bots routers into proxy nodes for your C2 network. Or judging by the decoded strings perhaps just trying to bypass firewall rules? Seems overkill though unless you’re expecting something inbound.
Figure 7 Decoded strings
Figure 8 Miniupnp library strings
An interesting crossover here is that McAfee saw this same technique being used by Qbot(2), Emotet has previously been seen delivering Qbot as well as Dridex. What is immediately interesting is that these proxy like C2 nodes for residential IPs appear to have both an HTTP port open and an HTTPS port open, the certificate is generated and appears to match what is specified in the McAfee article. It’s interesting to see the same technique used by Qbot against home routers showing up as a module for Emotet and then seeing many of these nodes hosting what appear to be both.
The new module will post a request to /whoami.php to one of the module’s C2s such as 126.96.36.199:8080. However also on this same IP at port 443 is a certificate that appears very similar to what was described in the McAfee article for Qbot.
The next day a newly generated cert was available:
Checking another C2 from the modules shows another similar certificate:
This potential Emotet and Qbot crossover of techniques is curious but as we mentioned previously we have seen Emotet delivering Qbot. However, in this case the UPNP code was being used as a module of Emotet, as with the other modules it expects the main Emotet binary to pass over needed things such as the RSA public key and has some code reuse from Emotet such as functions used for counting its onboard table of IP and ports and stack based string obfuscation. This technique overlap coupled with frequent double ports found on these residential IPs makes for some interesting speculation on how close the actors are behind Emotet and Qbot respectively.
So with all that we are expecting a Qbot delivery right? Well for this run I received an IcedID sample, IcedID being delivered by Emotet is also not new(8) but then why does it appear that the Emotet module C2s (which are residential IPs) appear to be hosting a port for Emotet and a port for Qbot? Questions that will hopefully be answered in due time by the research and intelligence communities.
We’ve outlined a number of updates in this paper that will hopefully benefit other researchers and defenders in the field. This research was conducted with the help of other researchteams from Flashpoint as well as Bank of America and as such we would like to thank all parties involved; Vitali Kremez, Director of Research at Flashpoint, Ronnie Tokazowski, Senior Malware Analyst at Flashpoint and Joshua Platt with Bank of America.
|Emode Module C2|