Emotet Update: New C2 Communication Followed by New Infection Chain
On March 15, CofenseTM Research reported that the Emotet botnet is changing the way it communicates, in a likely attempt to evade malware detection. Since then, Cofense IntelligenceTM has seen the same trend: Geodo-Emotet isn’t relying on cookies to make certain requests, instead performing HTTP POSTs to what seems to be the C2. Baking requests into cookies is a time-honored and easily detected pattern of behavior. Switching this up makes it harder to see when the malware is calling home.
Historically, Geodo has passed data to its C2 using the Cookie field of the HTTP header. Information about the system, as well as identifiers, would be encrypted, wrapped in Base64 and added to the HTTP header before transport. This was a consistent and easily identifiable pattern of behavior, which led to near universal enterprise detection. Figure 1 shows an example of this exfiltration method.
Figure 1: An example of classic Geodo C2 comms using the Cookie field. Source: app.any.run
Despite being a valid and oft-used header field, there are several other tells – such as direct communication with an IP address for which no DNS resolution was performed. This, when combined with the cookie, is an easy way to identify a Geodo infection calling home.
The latest iteration of Geodo, however, has transitioned away from this legacy method to submitting data to its C2 via HTTP POST as a form. Figure 2 shows an example of this updated communication method.
Figure 2: The new method of C2 comms
Figure 3: The obfuscated payload showcasing cleartext strings
After deobfuscation, the flow of the code is somewhat easier to interpret. The code is broken out into 5 distinct functions, with two anonymous functions—one at the head and one at the tail—responsible for execution. Figure 4 shows the first two functions and an array.
Figure 4: Two functions responsible for shuffling an array and retrieving an element by index, respectively.
The shuffling function is likely there to slow down manual analysis of the file. It could also be used to defeat unsophisticated emulation techniques. The second function simply returns an item from an array by its index.
The next two functions, seen in figures 5 and 6, are responsible for downloading and response code verification, and looping through available URLs, respectively.
Figure 5: The code responsible for downloading payloads and verifying the response code
Figure 6: Looping through five URLs, and attempting to execute the retrieved payload
Although the dataset is entirely too small to accept as correlation, the use of 5 payload locations is in line with the standard Geodo modus operandi. During analysis, it was noticed that one of the payloads was not like the others, however. Figure 7 shows the rather interesting subject matter returned during analysis of the payload locations.
Figure 7: A blog page returned in lieu of a binary payload.
Figure 8 shows the code responsible for finding the path of, and writing files to, the %temp% directory.
Figure 8: The dropper generates a pseudo-random filename as which to write the file
Figure 9 is the code responsible for kicking off the main functions of the script.
Figure 9: The code responsible for starting the download and execute operations. Comments added for clarity
With routine changes in behavior and delivery methods, Geodo’s operators consistently find ways to evolve how the botnet behaves—always attempting to stay ahead of the cat-and-mouse game they play with network defenders. The change in how form data is passed will almost certainly allow Geodo to overcome certain detection technologies, requiring immediate retooling. Identifying a highly dynamic family, such as Geodo, requires highly agile security infrastructure coupled with responsive threat intelligence.
To stay ahead of emerging phishing and malware trends, sign up for free Cofense Threat Alerts.
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.