Security researchers have discovered an updated version of the Wi-Fi spreader used by the Emotet malware being delivered to multiple bots. This updated version changed the spreader from a stand-alone program into a full-fledged module of Emotet with some other functionality improvements, said a blog post by Binary Defense. Instead of bundling the Emotet loader with the spreader, it now downloads the loader from a server.
Security researchers have discovered an updated version of the Wi-Fi spreader used by the Emotet malware being delivered to multiple bots.
This updated version changed the spreader from a stand-alone program into a full-fledged module of Emotet with some other functionality improvements, said a blog post by Binary Defense. Instead of bundling the Emotet loader with the spreader, it now downloads the loader from a server.
They said that these changes do not affect the key functionality of the malware, but do increase the logging capability of the spreader, allowing Emotet’s authors to get step-by-step debugging logs from infected machines through the use of a new communication protocol.
During an attack, if the spreader fails to brute-force the C$ share, the spreader will then attempt to brute-force the ADMIN$ share. Before then it attempts to download, from a hardcoded IP, the service binary that it installs remotely. If this download fails, it sends the debug string “error downloading file” before quitting.
There are also changes to service.exe. This is the executable used to install Emotet onto infected machines. The new service.exe downloads an Emotet binary from the C2 instead of containing a binary packaged inside of it.
“Upon startup of Service.exe, the malware connects out to the same gate.php used by the spreader and sends the debug string “remote service runned Downloading payload…”. Next, it attempts to connect to a hardcoded C2 where it pulls down the Emotet binary, saving the downloaded file as “firefox.exe.’,” said researchers.
When the motet malware has downloaded from the C2 server, Service.exe sends an acknowledgment “payload downloaded ok” to the C2 before executing the dropped file. This also ensures that it has the most recent loader, without needing to package it inside itself. Researchers said that this method helps to avoid detections that may flag off of the Emotet loader, but not the service executable.
Researchers also found some clues about the development process for the spreader. While looking at strings for the spreader executable, researchers noticed that the hardcoded URL used by Service.exe to pull down the Emotet loader was also present in the spreader executable.
“Additionally, the drop name for the Emotet loader (firefox.exe) was also present. However, both were unused. This hints that it is possible that the spreader and service combo were once a single file,” added researchers.
Given that "worming" attacks rely on guessing passwords using hard-coded lists of possible passwords stored within the malware itself, a big chunk of the mitigation strategy must be strong and unique passwords updated fairly frequently, said Alex Hinchliffe, threat intelligence analyst at Unit 42, Palo Alto Networks.
“Brute force attacks like this rely on commonly used, weak passwords like basic dictionary words perhaps with a few numbers tagged on the end. Such passwords are easy to crack programmatically by simply trying 100s of possible options in a very small time-frame. Using a password manager to create long, unique, and complex passwords can thwart such activity whilst maintaining access to your own services,” he told SC Media UK.
Wireless networks that are managed by organisations should have egress controls in place to block malicious URLs, said Matt Aldridge, principal solutions architect at Webroot.
“This should be done at the firewall, gateway or DNS level or a combination of these. They should also where possible, isolate wireless clients from one another to prevent cross-infection between connected devices,” he told SC Media UK.