Blog
/
Network
/
November 8, 2022

How Raccoon Stealer v2 Infects Systems

Learn about Raccoon Stealer v2's infection process and its implications for cybersecurity. Discover effective strategies to protect your systems.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Sam Lister
Specialist Security Researcher
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
08
Nov 2022

Raccoon Stealer Malware

Since the release of version 2 of Raccoon Stealer in May 2022, Darktrace has observed huge volumes of Raccoon Stealer v2 infections across its client base. The info-stealer, which seeks to obtain and then exfiltrate sensitive data saved on users’ devices, displays a predictable pattern of network activity once it is executed. In this blog post, we will provide details of this pattern of activity, with the goal of helping security teams to recognize network-based signs of Raccoon Stealer v2 infection within their own networks. 

What is Raccoon Stealer?

Raccoon Stealer is a classic example of information-stealing malware, which cybercriminals typically use to gain possession of sensitive data saved in users’ browsers and cryptocurrency wallets. In the case of browsers, targeted data typically includes cookies, saved login details, and saved credit card details. In the case of cryptocurrency wallets (henceforth, ‘crypto-wallets’), targeted data typically includes public keys, private keys, and seed phrases [1]. Once sensitive browser and crypto-wallet data is in the hands of cybercriminals, it will likely be used to conduct harmful activities, such as identity theft, cryptocurrency theft, and credit card fraud.

How do you obtain Raccoon Stealer?

Like most info-stealers, Raccoon Stealer is purchasable. The operators of Raccoon Stealer sell Raccoon Stealer samples to their customers (called ‘affiliates’), who then use the info-stealer to gain possession of sensitive data saved on users’ devices. Raccoon Stealer affiliates typically distribute their samples via SEO-promoted websites providing free or cracked software. 

Is Raccoon Stealer Still Active?

On the 25th of March 2022, the operators of Raccoon Stealer announced that they would be suspending their operations because one of their core developers had been killed during the Russia-Ukraine conflict [2]. The presence of the hardcoded RC4 key ‘edinayarossiya’ (Russian for ‘United Russia’) within observed Raccoon Stealer v2 samples [3] provides potential evidence of the Raccoon Stealer operators’ allegiances.

Recent details shared by the US Department of Justice [4]/[5] indicate that it was in fact the arrest, rather than the death, of an operator which led the Raccoon Stealer team to suspend their operations [6]. As a result of the FBI, along with law enforcement partners in Italy and the Netherlands, dismantling Raccoon Stealer infrastructure in March 2022 [4], the Raccoon Stealer team was forced to build a new version of the info-stealer.  

On the 17th May 2022, the completion of v2 of the info-stealer was announced on the Raccoon Stealer Telegram channel [7].  Since its release in May 2022, Raccoon Stealer v2 has become extremely popular amongst cybercriminals. The prevalence of Raccoon Stealer v2 in the wider landscape has been reflected in Darktrace’s client base, with hundreds of infections being observed within client networks on a monthly basis.   

Since Darktrace’s SOC first saw a Raccoon Stealer v2 infection on the 22nd May 2022, the info-stealer has undergone several subtle changes. However, the info-stealer’s general pattern of network activity has remained essentially unchanged.  

How Does Raccoon Stealer v2 Infection Work?

A Raccoon Stealer v2 infection typically starts with a user attempting to download cracked or free software from an SEO-promoted website. Attempting to download software from one of these cracked/free software websites redirects the user’s browser (typically via several .xyz or .cfd endpoints) to a page providing download instructions. In May, June, and July, many of the patterns of download behavior observed by Darktrace’s SOC matched the pattern of behavior observed in a cracked software campaign reported by Avast in June [8].   

webpage whose download instructions led to a Raccoon Stealer v2
Figure 1: Above is a webpage whose download instructions led to a Raccoon Stealer v2 sample hosted on Discord CDN
example of a webpage whose download instructions led to a Raccoon Stealer v2
Figure 2: Above is an example of a webpage whose download instructions led to a Raccoon Stealer v2 sample hosted on Bitbucket
example of a webpage whose download instructions led to a Raccoon Stealer v2
Figure 3: Above is an example of a webpage whose download instructions led to a Raccoon Stealer v2 sample hosted on MediaFire

Following the instructions on the download instruction page causes the user’s device to download a password-protected RAR file from a file storage service such as ‘cdn.discordapp[.]com’, ‘mediafire[.]com’, ‘mega[.]nz’, or ‘bitbucket[.]org’. Opening the downloaded file causes the user’s device to execute Raccoon Stealer v2. 

The Event Log for an infected device,
Figure 4: The Event Log for an infected device, taken from Darktrace’s Threat Visualiser interface, shows a device contacting two cracked software websites (‘crackedkey[.]org’ and ‘crackedpc[.]co’) before contacting a webpage (‘premiumdownload[.]org) providing instructions to download Raccoon Stealer v2 from Bitbucket

Once Raccoon Stealer v2 is running on a device, it will make an HTTP POST request with the target URI ‘/’ and an unusual user-agent string (such as ‘record’, ‘mozzzzzzzzzzz’, or ‘TakeMyPainBack’) to a C2 server. This POST request consists of three strings: a machine GUID, a username, and a 128-bit RC4 key [9]. The posted data has the following form:

machineId=X | Y & configId=Z (where X is a machine GUID, Y is a username and Z is a 128-bit RC4 key) 

PCAP showing a device making an HTTP POST request with the User Agent header ‘record’ 
Figure 5:PCAP showing a device making an HTTP POST request with the User Agent header ‘record’ 
PCAP showing a device making an HTTP POST request with the User Agent header ‘mozzzzzzzzzzz’
Figure 6: PCAP showing a device making an HTTP POST request with the User Agent header ‘mozzzzzzzzzzz’
PCAP showing a device making an HTTP POST request with the User Agent header ‘TakeMyPainBack’
Figure 7: PCAP showing a device making an HTTP POST request with the User Agent header ‘TakeMyPainBack’

The C2 server responds to the info-stealer’s HTTP POST request with custom-formatted configuration details. These configuration details consist of fields which tell the info-stealer what files to download, what data to steal, and what target URI to use in its subsequent exfiltration POST requests. Below is a list of the fields Darktrace has observed in the configuration details retrieved by Raccoon Stealer v2 samples:

  • a ‘libs_mozglue’ field, which specifies a download address for a Firefox library named ‘mozglue.dll’
  • a ‘libs_nss3’ field, which specifies a download address for a Network System Services (NSS) library named ‘nss3.dll’ 
  • a ‘libs_freebl3’ field, which specifies a download address for a Network System Services (NSS) library named ‘freebl3.dll’
  • a ‘libs_softokn3’ field, which specifies a download address for a Network System Services (NSS) library named ‘softokn3.dll’
  • a ‘libs_nssdbm3’ field, which specifies a download address for a Network System Services (NSS) library named ‘nssdbm3.dll’
  • a ‘libs_sqlite3’ field, which specifies a download address for a SQLite command-line program named ‘sqlite3.dll’
  • a ‘libs_ msvcp140’ field, which specifies a download address for a Visual C++ runtime library named ‘msvcp140.dll’
  • a ‘libs_vcruntime140’ field, which specifies a download address for a Visual C++ runtime library named ‘vcruntime140.dll’
  • a ‘ldr_1’ field, which specifies the download address for a follow-up payload for the sample to download 
  • ‘wlts_X’ fields (where X is the name of a crypto-wallet application), which specify data for the sample to obtain from the specified crypto-wallet application
  • ‘ews_X’ fields (where X is the name of a crypto-wallet browser extension), which specify data for the sample to obtain from the specified browser extension
  • ‘xtntns_X’ fields (where X is the name of a password manager browser extension), which specify data for the sample to obtain from the specified browser extension
  • a ‘tlgrm_Telegram’ field, which specifies data for the sample to obtain from the Telegram Desktop application 
  • a ‘grbr_Desktop’ field, which specifies data within a local ‘Desktop’ folder for the sample to obtain 
  • a ‘grbr_Documents’ field, which specifies data within a local ‘Documents’ folder for the sample to obtain
  • a ‘grbr_Recent’ field, which specifies data within a local ‘Recent’ folder for the sample to obtain
  • a ‘grbr_Downloads’ field, which specifies data within a local ‘Downloads’ folder for the sample to obtain
  • a ‘sstmnfo_System Info.txt’ field, which specifies whether the sample should gather and exfiltrate a profile of the infected host 
  • a ‘scrnsht_Screenshot.jpeg’ field, which specifies whether the sample should take and exfiltrate screenshots of the infected host
  • a ‘token’ field, which specifies a 32-length string of hexadecimal digits for the sample to use as the target URI of its HTTP POST requests containing stolen data 

After retrieving its configuration data, Raccoon Stealer v2 downloads the library files specified in the ‘libs_’ fields. Unusual user-agent strings (such as ‘record’, ‘qwrqrwrqwrqwr’, and ‘TakeMyPainBack’) are used in the HTTP GET requests for these library files. In all Raccoon Stealer v2 infections seen by Darktrace, the paths of the URLs specified in the ‘libs_’ fields have the following form:

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/X (where X is the name of the targeted DLL file) 

Advanced Search logs for an infected host
Figure 8: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device making an HTTP POST request to retrieve configuration details, and then making HTTP GET requests with the User Agent header ‘record’ for DLL files
Advanced Search logs for an infected host
Figure 9: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device making an HTTP POST request to retrieve configuration details, and then making HTTP GET requests with the User Agent header ‘qwrqrwrqwrqwr’ for DLL files
Advanced Search logs for an infected host
Figure 10: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device making an HTTP POST request to retrieve configuration details, and then making HTTP GET requests with the User Agent header ‘TakeMyPainBack’ for DLL files

Raccoon Stealer v2 uses the DLLs which it downloads to gain access to sensitive data (such as cookies, credit card details, and login details) saved in browsers running on the infected host.  

Depending on the data provided in the configuration details, Raccoon Stealer v2 will typically seek to obtain, in addition to sensitive data saved in browsers, the following information:

  • Information about the Operating System and applications installed on the infected host
  • Data from specified crypto-wallet software
  • Data from specified crypto-wallet browser extensions
  • Data from specified local folders
  • Data from Telegram Desktop
  • Data from specified password manager browser extensions
  • Screenshots of the infected host 

Raccoon Stealer v2 exfiltrates the data which it obtains to its C2 server by making HTTP POST requests with unusual user-agent strings (such as ‘record’, ‘rc2.0/client’, ‘rqwrwqrqwrqw’, and ‘TakeMyPainBack’) and target URIs matching the 32-length string of hexadecimal digits specified in the ‘token’ field of the configuration details. The stolen data exfiltrated by Raccoon Stealer typically includes files named ‘System Info.txt’, ‘---Screenshot.jpeg’, ‘\cookies.txt’, and ‘\passwords.txt’. 

Advanced Search logs for an infected host
Figure 11: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device retrieving configuration details via a POST request, downloading several DLLs, and then exfiltrating files named ‘System Info.txt’ and ‘---Screenshot.jpeg’
Advanced Search logs for an infected host
Figure 12: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device retrieving configuration details via a POST request, downloading several DLLs, and then exfiltrating a file named ‘System Info.txt’ 
Advanced Search logs for an infected host
Figure 13: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device retrieving configuration details via a POST request, downloading several DLLs, and then exfiltrating files named ‘System Info.txt’, ‘\cookies.txt’ and ‘\passwords.txt’
Advanced Search logs for an infected host
Figure 14: Advanced Search logs for an infected host, found on Darktrace’s Advanced Search interface, show a device retrieving configuration details via a POST request, downloading several DLLs, and then exfiltrating a file named ‘System Info.txt’

If a ‘ldr_1’ field is present in the retrieved configuration details, then Raccoon Stealer will complete its operation by downloading the binary file specified in the ‘ldr_1’ field. In all observed cases, the paths of the URLs specified in the ‘ldr_1’ field end in a sequence of digits, followed by ‘.bin’. The follow-up payload seems to vary between infections, likely due to this additional-payload feature being customizable by Raccoon Stealer affiliates. In many cases, the info-stealer, CryptBot, was delivered as the follow-up payload. 

Darktrace Coverage of Raccoon Stealer

Once a user’s device becomes infected with Raccoon Stealer v2, it will immediately start to communicate over HTTP with a C2 server. The HTTP requests made by the info-stealer have an empty Host header (although Host headers were used by early v2 samples) and highly unusual User Agent headers. When Raccoon Stealer v2 was first observed in May 2022, the user-agent string ‘record’ was used in its HTTP requests. Since then, it appears that the operators of Raccoon Stealer have made several changes to the user-agent strings used by the info-stealer,  likely in an attempt to evade signature-based detections. Below is a timeline of the changes to the info-stealer’s user-agent strings, as observed by Darktrace’s SOC:

  • 22nd May 2022: Samples seen using the user-agent string ‘record’
  • 2nd July 2022: Samples seen using the user-agent string ‘mozzzzzzzzzzz’
  • 29th July 2022: Samples seen using the user-agent string ‘rc2.0/client’
  • 10th August 2022: Samples seen using the user-agent strings ‘qwrqrwrqwrqwr’ and ‘rqwrwqrqwrqw’
  • 16th Sep 2022: Samples seen using the user-agent string ‘TakeMyPainBack’

The presence of these highly unusual user-agent strings within infected devices’ HTTP requests causes the following Darktrace DETECT/Network models to breach:

  • Device / New User Agent
  • Device / New User Agent and New IP
  • Anomalous Connection / New User Agent to IP Without Hostname
  • Device / Three or More New User Agents

These DETECT models look for devices making HTTP requests with unusual user-agent strings, rather than specific user-agent strings which are known to be malicious. This method of detection enables the models to continually identify Raccoon Stealer v2 HTTP traffic, despite the changes made to the info-stealer’s user-agent strings.   

After retrieving configuration details from a C2 server, Raccoon Stealer v2 samples make HTTP GET requests for several DLL libraries. Since these GET requests are directed towards highly unusual IP addresses, the downloads of the DLLs cause the following DETECT models to breach:

  • Anomalous File / EXE from Rare External Location
  • Anomalous File / Script from Rare External Location
  • Anomalous File / Multiple EXE from Rare External Locations

Raccoon Stealer v2 samples send data to their C2 server via HTTP POST requests with an absent Host header. Since these POST requests lack a Host header and have a highly unusual destination IP, their occurrence causes the following DETECT model to breach:

  • Anomalous Connection / Posting HTTP to IP Without Hostname

Certain Raccoon Stealer v2 samples download (over HTTP) a follow-up payload once they have exfiltrated data. Since the target URIs of the HTTP GET requests made by v2 samples end in a sequence of digits followed by ‘.bin’, the samples’ downloads of follow-up payloads cause the following DETECT model to breach:

  • Anomalous File / Numeric File Download

If Darktrace RESPOND/Network is configured within a customer’s environment, then Raccoon Stealer v2 activity should cause the following inhibitive actions to be autonomously taken on infected systems: 

  • Enforce pattern of life — This action results in a device only being able to make connections which are normal for it to make
  • Enforce group pattern of life — This action results in a device only being able to make connections which are normal for it or any of its peers to make
  • Block matching connections — This action results in a device being unable to make connections to particular IP/Port pairs
  • Block all outgoing traffic — This action results in a device being unable to make any connections 
The Event Log for an infected device
Figure 15: The Event Log for an infected device, taken from Darktrace’s Threat Visualiser interface, shows Darktrace RESPOND taking inhibitive actions in response to the HTTP activities of a Raccoon Stealer v2 sample downloaded from MediaFire

Given that Raccoon Stealer v2 infections move extremely fast, with the time between initial infection and data exfiltration sometimes less than a minute, the availability of Autonomous Response technology such as Darktrace RESPOND is vital for the containment of Raccoon Stealer v2 infections.  

Timeline of Darktrace stopping raccoon stealer.
Figure 16: Figure displaying the steps of a Raccoon Stealer v2 infection, along with the corresponding Darktrace detections

Conclusion

Since the release of Raccoon Stealer v2 back in 2022, the info-stealer has relentlessly infected the devices of unsuspecting users. Once the info-stealer infects a user’s device, it retrieves and then exfiltrates sensitive information within a matter of minutes. The distinctive pattern of network behavior displayed by Raccoon Stealer v2 makes the info-stealer easy to spot. However, the changes which the Raccoon Stealer operators make to the User Agent headers of the info-stealer’s HTTP requests make anomaly-based methods key for the detection of the info-stealer’s HTTP traffic. The operators of Raccoon Stealer can easily change the superficial features of their malware’s C2 traffic, however, they cannot easily change the fact that their malware causes highly unusual network behavior. Spotting this behavior, and then autonomously responding to it, is likely the best bet which organizations have at stopping a Raccoon once it gets inside their networks.  

Thanks to the Threat Research Team for its contributions to this blog.

References

[1] https://www.microsoft.com/security/blog/2022/05/17/in-hot-pursuit-of-cryware-defending-hot-wallets-from-attacks/

[2] https://twitter.com/3xp0rtblog/status/1507312171914461188

[3] https://www.esentire.com/blog/esentire-threat-intelligence-malware-analysis-raccoon-stealer-v2-0

[4] https://www.justice.gov/usao-wdtx/pr/newly-unsealed-indictment-charges-ukrainian-national-international-cybercrime-operation

[5] https://www.youtube.com/watch?v=Fsz6acw-ZJ

[6] https://riskybiznews.substack.com/p/raccoon-stealer-dev-didnt-die-in

[7] https://medium.com/s2wblog/raccoon-stealer-is-back-with-a-new-version-5f436e04b20d

[8] https://blog.avast.com/fakecrack-campaign

[9] https://blog.sekoia.io/raccoon-stealer-v2-part-2-in-depth-analysis/

Appendices

MITRE ATT&CK Mapping

Resource Development

• T1588.001 — Obtain Capabilities: Malware

• T1608.001 — Stage Capabilities: Upload Malware

• T1608.005 — Stage Capabilities: Link Target

• T1608.006 — Stage Capabilities: SEO Poisoning

Execution

•  T1204.002 — User Execution: Malicious File

Credential Access

• T1555.003 — Credentials from Password Stores:  Credentials from Web Browsers

• T1555.005 — Credentials from Password Stores:  Password Managers

• T1552.001 — Unsecured Credentials: Credentials  In Files

Command and Control

•  T1071.001 — Application Layer Protocol: Web Protocols

•  T1105 — Ingress Tool Transfer

IOCS

Type

IOC

Description

User-Agent String

record

String used in User Agent header of  Raccoon Stealer v2’s HTTP requests

User-Agent  String

mozzzzzzzzzzz

String used inUser Agent header of Raccoon Stealer v2’s HTTP requests

User-Agent String

rc2.0/client

String used in User Agent header of  Raccoon Stealer v2’s HTTP requests

User-Agent  String

qwrqrwrqwrqwr

String used in  User Agent header of Raccoon Stealer v2’s HTTP requests

User-Agent String

rqwrwqrqwrqw

String used in User Agent header of  Raccoon Stealer v2’s HTTP requests

User-Agent  String

TakeMyPainBack

String used in  User Agent header of Raccoon Stealer v2’s HTTP requests

Domain Name

brain-lover[.]xyz  

Raccoon Stealer v2 C2 infrastructure

Domain  Name

polar-gift[.]xyz

Raccoon Stealer  v2 C2 infrastructure

Domain Name

cool-story[.]xyz

Raccoon Stealer v2 C2 infrastructure

Domain  Name

fall2sleep[.]xyz

Raccoon Stealer  v2 C2 infrastructure

Domain Name

broke-bridge[.]xyz

Raccoon Stealer v2 C2 infrastructure

Domain  Name

use-freedom[.]xyz

Raccoon Stealer  v2 C2 infrastructure

Domain Name

just-trust[.]xyz

Raccoon Stealer v2 C2 infrastructure

Domain  Name

soft-viper[.]site

Raccoon Stealer  v2 C2 infrastructure

Domain Name

tech-lover[.]xyz

Raccoon Stealer v2 C2 infrastructure

Domain  Name

heal-brain[.]xyz

Raccoon Stealer  v2 C2 infrastructure

Domain Name

love-light[.]xyz

Raccoon Stealer v2 C2 infrastructure

IP  Address

104.21.80[.]14

Raccoon Stealer  v2 C2 infrastructure

IP Address

107.152.46[.]84

Raccoon Stealer v2 C2 infrastructure

IP  Address

135.181.147[.]255

Raccoon Stealer  v2 C2 infrastructure

IP Address

135.181.168[.]157

Raccoon Stealer v2 C2 infrastructure

IP  Address

138.197.179[.]146

Raccoon Stealer  v2 C2 infrastructure

IP Address

141.98.169[.]33

Raccoon Stealer v2 C2 infrastructure

IP  Address

146.19.170[.]100

Raccoon Stealer  v2 C2 infrastructure

IP Address

146.19.170[.]175

Raccoon Stealer v2 C2 infrastructure

IP  Address

146.19.170[.]98

Raccoon Stealer  v2 C2 infrastructure

IP Address

146.19.173[.]33

Raccoon Stealer v2 C2 infrastructure

IP  Address

146.19.173[.]72

Raccoon Stealer  v2 C2 infrastructure

IP Address

146.19.247[.]175

Raccoon Stealer v2 C2 infrastructure

IP  Address

146.19.247[.]177

Raccoon Stealer  v2 C2 infrastructure

IP Address

146.70.125[.]95

Raccoon Stealer v2 C2 infrastructure

IP  Address

152.89.196[.]234

Raccoon Stealer  v2 C2 infrastructure

IP Address

165.225.120[.]25

Raccoon Stealer v2 C2 infrastructure

IP  Address

168.100.10[.]238

Raccoon Stealer  v2 C2 infrastructure

IP Address

168.100.11[.]23

Raccoon Stealer v2 C2 infrastructure

IP  Address

168.100.9[.]234

Raccoon Stealer  v2 C2 infrastructure

IP Address

170.75.168[.]118

Raccoon Stealer v2 C2 infrastructure

IP  Address

172.67.173[.]14

Raccoon Stealer  v2 C2 infrastructure

IP Address

172.86.75[.]189

Raccoon Stealer v2 C2 infrastructure

IP  Address

172.86.75[.]33

Raccoon Stealer  v2 C2 infrastructure

IP Address

174.138.15[.]216

Raccoon Stealer v2 C2 infrastructure

IP  Address

176.124.216[.]15

Raccoon Stealer  v2 C2 infrastructure

IP Address

185.106.92[.]14

Raccoon Stealer v2 C2 infrastructure

IP  Address

185.173.34[.]161

Raccoon Stealer  v2 C2 infrastructure

IP Address

185.173.34[.]161  

Raccoon Stealer v2 C2 infrastructure

IP  Address

185.225.17[.]198

Raccoon Stealer  v2 C2 infrastructure

IP Address

185.225.19[.]190

Raccoon Stealer v2 C2 infrastructure

IP  Address

185.225.19[.]229

Raccoon Stealer  v2 C2 infrastructure

IP Address

185.53.46[.]103

Raccoon Stealer v2 C2 infrastructure

IP  Address

185.53.46[.]76

Raccoon Stealer  v2 C2 infrastructure

IP Address

185.53.46[.]77

Raccoon Stealer v2 C2 infrastructure

IP  Address

188.119.112[.]230

Raccoon Stealer  v2 C2 infrastructure

IP Address

190.117.75[.]91

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.106.191[.]182

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.149.129[.]135

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.149.129[.]144

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.149.180[.]210

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.149.185[.]192

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.233.193[.]50

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.43.146[.]138

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.43.146[.]17

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.43.146[.]192

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.43.146[.]213

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.43.146[.]214

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.43.146[.]215

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.43.146[.]26

Raccoon Stealer  v2 C2 infrastructure

IP Address

193.43.146[.]45

Raccoon Stealer v2 C2 infrastructure

IP  Address

193.56.146[.]177

Raccoon Stealer  v2 C2 infrastructure

IP Address

194.180.174[.]180

Raccoon Stealer v2 C2 infrastructure

IP  Address

195.201.148[.]250

Raccoon Stealer  v2 C2 infrastructure

IP Address

206.166.251[.]156

Raccoon Stealer v2 C2 infrastructure

IP  Address

206.188.196[.]200

Raccoon Stealer  v2 C2 infrastructure

IP Address

206.53.53[.]18

Raccoon Stealer v2 C2 infrastructure

IP  Address

207.154.195[.]173

Raccoon Stealer  v2 C2 infrastructure

IP Address

213.252.244[.]2

Raccoon Stealer v2 C2 infrastructure

IP  Address

38.135.122[.]210

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.10.20[.]248

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.11.19[.]99

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.133.216[.]110

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.133.216[.]145

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.133.216[.]148

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.133.216[.]249

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.133.216[.]71

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.140.146[.]169

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.140.147[.]245

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.142.212[.]100

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.142.213[.]24

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.142.215[.]91

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.142.215[.]91  

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.142.215[.]92

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.144.29[.]18

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.144.29[.]243

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.15.156[.]11

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.15.156[.]2

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.15.156[.]31

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.15.156[.]31

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.150.67[.]156

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.153.230[.]183

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.153.230[.]228

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.159.251[.]163

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.159.251[.]164

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.61.136[.]67

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.61.138[.]162

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.67.228[.]8

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.67.231[.]202

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.67.34[.]152

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.67.34[.]234

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.8.144[.]187

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.8.144[.]54

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.8.144[.]55

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.8.145[.]174

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.8.145[.]83

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.8.147[.]39

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.8.147[.]79

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.84.0.152

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.86.86[.]78

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.89.54[.]110

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.89.54[.]110

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.89.54[.]95

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.89.55[.]115

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.89.55[.]117

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.89.55[.]193

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.89.55[.]198

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.89.55[.]20

Raccoon Stealer  v2 C2 infrastructure

IP Address

45.89.55[.]84

Raccoon Stealer v2 C2 infrastructure

IP  Address

45.92.156[.]150

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.182.36[.]154

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.182.36[.]230

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.182.36[.]231

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.182.36[.]232

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.182.36[.]233

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.182.39[.]34

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.182.39[.]74

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.182.39[.]75

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.182.39[.]77

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.252.118[.]33

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.252.176[.]62

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.252.177[.]217

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.252.177[.]234

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.252.177[.]43

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.252.177[.]47

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.252.177[.]92

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.252.177[.]98

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.252.22[.]142

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.252.23[.]100

Raccoon Stealer v2 C2 infrastructure

IP  Address

5.252.23[.]25

Raccoon Stealer  v2 C2 infrastructure

IP Address

5.252.23[.]76

Raccoon Stealer v2 C2 infrastructure

IP  Address

51.195.166[.]175

Raccoon Stealer  v2 C2 infrastructure

IP Address

51.195.166[.]176

Raccoon Stealer v2 C2 infrastructure

IP  Address

51.195.166[.]194

Raccoon Stealer  v2 C2 infrastructure

IP Address

51.81.143[.]169

Raccoon Stealer v2 C2 infrastructure

IP  Address

62.113.255[.]110

Raccoon Stealer  v2 C2 infrastructure

IP Address

65.109.3[.]107

Raccoon Stealer v2 C2 infrastructure

IP  Address

74.119.192[.]56

Raccoon Stealer  v2 C2 infrastructure

IP Address

74.119.192[.]73

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.232.39[.]101

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.73.133[.]0

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.73.133[.]4

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.73.134[.]45

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.75.230[.]25

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.75.230[.]39

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.75.230[.]70

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.75.230[.]93

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.91.100[.]101

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.91.102[.]12

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.91.102[.]230

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.91.102[.]44

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.91.102[.]57

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.91.102[.]84

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.91.103[.]31

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.91.73[.]154

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.91.73[.]213

Raccoon Stealer  v2 C2 infrastructure

IP Address

77.91.73[.]32

Raccoon Stealer v2 C2 infrastructure

IP  Address

77.91.74[.]67

Raccoon Stealer  v2 C2 infrastructure

IP Address

78.159.103[.]195

Raccoon Stealer v2 C2 infrastructure

IP  Address

78.159.103[.]196

Raccoon Stealer  v2 C2 infrastructure

IP Address

80.66.87[.]23

Raccoon Stealer v2 C2 infrastructure

IP  Address

80.66.87[.]28

Raccoon Stealer  v2 C2 infrastructure

IP Address

80.71.157[.]112

Raccoon Stealer v2 C2 infrastructure

IP  Address

80.71.157[.]138

Raccoon Stealer  v2 C2 infrastructure

IP Address

80.92.204[.]202

Raccoon Stealer v2 C2 infrastructure

IP  Address

87.121.52[.]10

Raccoon Stealer  v2 C2 infrastructure

IP Address

88.119.175[.]187

Raccoon Stealer v2 C2 infrastructure

IP  Address

89.185.85[.]53

Raccoon Stealer  v2 C2 infrastructure

IP Address

89.208.107[.]42

Raccoon Stealer v2 C2 infrastructure

IP  Address

89.39.106[.]78

Raccoon Stealer  v2 C2 infrastructure

IP Address

91.234.254[.]126

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.104[.]16

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.131.104[.]17

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.104[.]18

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.131.106[.]116

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.106[.]224

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.131.107[.]132

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.107[.]138

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.131.96[.]109

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.97[.]129

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.131.97[.]53

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.97[.]56

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.131.97[.]57

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.131.98[.]5

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.158.244[.]114

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.158.244[.]119

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.158.244[.]21

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.158.247[.]24

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.158.247[.]26

Raccoon Stealer v2 C2 infrastructure

IP  Address

94.158.247[.]30

Raccoon Stealer  v2 C2 infrastructure

IP Address

94.158.247[.]44

Raccoon Stealer v2 C2 infrastructure

IP  Address

95.216.109[.]16

Raccoon Stealer  v2 C2 infrastructure

IP Address

95.217.124[.]179

Raccoon Stealer v2 C2 infrastructure

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/mozglue.dll

URI used in  download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/nss3.dll

URI used in download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/freebl3.dll

URI used in  download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/softokn3.dll

URI used in download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/nssdbm3.dll

URI used in  download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/sqlite3.dll

URI used in download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/msvcp140.dll

URI used in  download of library file

URI

/aN7jD0qO6kT5bK5bQ4eR8fE1xP7hL2vK/vcruntime140.dll

URI used in download of library file

URI

/C9S2G1K6I3G8T3X7/56296373798691245143.bin

URI used in  download of follow-up payload

URI

/O6K3E4G6N9S8S1/91787438215733789009.bin

URI used in download of follow-up  payload

URI

/Z2J8J3N2S2Z6X2V3S0B5/45637662345462341.bin

URI used in  download of follow-up payload

URI

/rgd4rgrtrje62iuty/19658963328526236.bin

URI used in download of follow-up  payload

URI

/sd325dt25ddgd523/81852849956384.bin

URI used in  download of follow-up payload

URI

/B0L1N2H4R1N5I5S6/40055385413647326168.bin

URI used in download of follow-up  payload

URI

/F5Q8W3O3O8I2A4A4B8S8/31427748106757922101.bin

URI used in  download of follow-up payload

URI

/36141266339446703039.bin

URI used in download of follow-up  payload

URI

/wH0nP0qH9eJ6aA9zH1mN/1.bin

URI used in  download of follow-up payload

URI

/K2X2R1K4C6Z3G8L0R1H0/68515718711529966786.bin

URI used in download of follow-up  payload

URI

/C3J7N6F6X3P8I0I0M/17819203282122080878.bin

URI used in  download of follow-up payload

URI

/W9H1B8P3F2J2H2K7U1Y7G5N4C0Z4B/18027641.bin

URI used in download of follow-up  payload

URI

/P2T9T1Q6P7Y5J3D2T0N0O8V/73239348388512240560937.bin

URI used in  download of follow-up payload

URI

/W5H6O5P0E4Y6P8O1B9D9G0P9Y9G4/671837571800893555497.bin

URI used in download of follow-up  payload

URI

/U8P2N0T5R0F7G2J0/898040207002934180145349.bin

URI used in  download of follow-up payload

URI

/AXEXNKPSBCKSLMPNOMNRLUEPR/3145102300913020.bin

URI used in download of follow-up  payload

URI

/wK6nO2iM9lE7pN7e/7788926473349244.bin

URI used in  download of follow-up payload

URI

/U4N9B5X5F5K2A0L4L4T5/84897964387342609301.bin

URI used in download of follow-up  payload

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Sam Lister
Specialist Security Researcher

More in this series

No items found.

Blog

/

Network

/

February 6, 2026

AppleScript Abuse: Unpacking a macOS Phishing Campaign

AppleScript Abuse: Unpacking a macOS Phishing CampaignDefault blog imageDefault blog image

Introduction

Darktrace security researchers have identified a campaign targeting macOS users through a multistage malware campaign that leverages social engineering and attempted abuse of the macOS Transparency, Consent and Control (TCC) privacy feature.

The malware establishes persistence via LaunchAgents and deploys a modular Node.js loader capable of executing binaries delivered from a remote command-and-control (C2) server.

Due to increased built-in security mechanisms in macOS such as System Integrity Protection (SIP) and Gatekeeper, threat actors increasingly rely on alternative techniques, including fake software and ClickFix attacks [1] [2]. As a result, macOS threats r[NJ1] ely more heavily on social engineering instead of vulnerability exploitation to deliver payloads, a trend Darktrace has observed across the threat landscape [3].

Technical analysis

The infection chain starts with a phishing email that prompts the user to download an AppleScript file named “Confirmation_Token_Vesting.docx.scpt”, which attemps to masquerade as a legitimate Microsoft document.

The AppleScript header prompting execution of the script.
Figure 1: The AppleScript header prompting execution of the script.

Once the user opens the AppleScript file, they are presented with a prompt instructing them to run the script, supposedly due to “compatibility issues”. This prompt is necessary as AppleScript requires user interaction to execute the script, preventing it from running automatically. To further conceal its intent, the malicious part of the script is buried below many empty lines, assuming a user likely will not to the end of the file where the malicious code is placed.

Curl request to receive the next stage.
Figure 2: Curl request to receive the next stage.

This part of the script builds a silent curl request to “sevrrhst[.]com”, sending the user’s macOS operating system, CPU type and language. This request retrieves another script, which is saved as a hidden file at in ~/.ex.scpt, executed, and then deleted.

The retrieved payload is another AppleScript designed to steal credentials and retrieve additional payloads. It begins by loading the AppKit framework, which enables the script to create a fake dialog box prompting the user to enter their system username and password [4].

 Fake dialog prompt for system password.
Figure 3: Fake dialog prompt for system password.

The script then validates the username and password using the command "dscl /Search -authonly <username> <password>", all while displaying a fake progress bar to the user. If validation fails, the dialog window shakes suggesting an incorrect password and prompting the user to try again. The username and password are then encoded in Base64 and sent to: https://sevrrhst[.]com/css/controller.php?req=contact&ac=<user>&qd=<pass>.

Figure 4: Requirements gathered on trusted binary.

Within the getCSReq() function, the script chooses from trusted Mac applications: Finder, Terminal, Script Editor, osascript, and bash. Using the codesign command codesign -d --requirements, it extracts the designated code-signing requirement from the target application. If a valid requirement cannot be retrieved, that binary is skipped. Once a designated requirement is gathered, it is then compiled into a binary trust object using the Code Signing Requirement command (csreq). This trust object is then converted into hex so it can later be injected into the TCC SQLite database.[NB2]

To bypass integrity checks, the TCC directory is renamed to com.appled.tcc using Finder. TCC is a macOS privacy framework designed to restrict application access to sensitive data, requiring users to explicitly grant permissions before apps can access items such as files, contacts, and system resources [1].

Example of how users interact with TCC.
Figure 5: TCC directory renamed to com.appled.TCC.
Figure 6: Example of how users interact with TCC.

After the database directory rename is attempted, the killall command is used on the tccd daemon to force macOS to release the lock on the database. The database is then injected with the forged access records, including the service, trusted binary path, auth_value, and the forged csreq binary. The directory is renamed back to com.apple.TCC, allowing the injected entries to be read and the permissions to be accepted. This enables persistence authorization for:

  • Full disk access
  • Screen recording
  • Accessibility
  • Camera
  • Apple Events 
  • Input monitoring

The malware does not grant permissions to itself; instead, it forges TCC authorizations for trusted Apple-signed binaries (Terminal, osascript, Script Editor, and bash) and then executes malicious actions through these binaries to inherit their permissions.

Although the malware is attempting to manipulate TCC state via Finder, a trusted system component, Apple has introduced updates in recent macOS versions that move much of the authorization enforcement into the tccd daemon. These updates prevent unauthorized permission modifications through directory or database manipulation. As a result, the script may still succeed on some older operating systems, but it is likely to fail on newer installations, as tcc.db reloads now have more integrity checks and will fail on Mobile Device Management (MDM) [NB5] systems as their profiles override TCC.

 Snippet of decoded Base64 response.
Figure 7: Snippet of decoded Base64 response.

A request is made to the C2, which retrieves and executes a Base64-encoded script. This script retrieves additional payloads based on the system architecture and stores them inside a directory it creates named ~/.nodes. A series of requests are then made to sevrrhst[.]com for:

/controller.php?req=instd

/controller.php?req=tell

/controller.php?req=skip

These return a node archive, bundled Node.js binary, and a JavaScript payload. The JavaScript file, index.js, is a loader that profiles the system and sends the data to the C2. The script identified the system platform, whether macOS, Linux or Windows, and then gathers OS version, CPU details, memory usage, disk layout, network interfaces, and running process. This is sent to https://sevrrhst[.]com/inc/register.php?req=init as a JSON object. The victim system is then registered with the C2 and will receive a Base64-encoded response.

LaunchAgent patterns to be replaced with victim information.
Figure 8: LaunchAgent patterns to be replaced with victim information.

The Base64-encoded response decodes to an additional Javacript that is used to set up persistence. The script creates a folder named com.apple.commonjs in ~/Library and copies the Node dependencies into this directory. From the C2, the files package.json and default.js are retrieved and placed into the com.apple.commonjs folder. A LaunchAgent .plist is also downloaded into the LaunchAgents directory to ensure the malware automatically starts. The .plist launches node and default.js on load, and uses output logging to log errors and outputs.

Default.js is Base64 encoded JavaScript that functions as a command loop, periodically sending logs to the C2, and checking for new payloads to execute. This gives threat actors ongoing and the ability to dynamically modify behavior without having to redeploy the malware. A further Base64-encoded JavaScript file is downloaded as addon.js.

Addon.js is used as the final payload loader, retrieving a Base64-encoded binary from https://sevrrhst[.]com/inc/register.php?req=next. The binary is decoded from Base64 and written to disk as “node_addon”, and executed silently in the background. At the time of analysis, the C2 did not return a binary, possibly because certain conditions were not met.  However, this mechanism enables the delivery and execution of payloads. If the initial TCC abuse were successful, this payload could access protected resources such as Screen Capture and Camera without triggering a consent prompt, due to the previously established trust.

Conclusion

This campaign shows how a malicious threat actor can use an AppleScript loader to exploit user trust and manipulate TCC authorization mechanisms, achieving persistent access to a target network without exploiting vulnerabilities.

Although recent macOS versions include safeguards against this type of TCC abuse, users should keep their systems fully updated to ensure the most up to date protections.  These findings also highlight the intentions of threat actors when developing malware, even when their implementation is imperfect.

Credit to Tara Gould (Malware Research Lead)
Edited by Ryan Traill (Analyst Content Lead)

Indicators of Compromise (IoCs)

88.119.171[.]59

sevrrhst[.]com

https://sevrrhst[.]com/inc/register.php?req=next

https://stomcs[.]com/inc/register.php?req=next
https://techcross-es[.]com

Confirmation_Token_Vesting.docx.scpt - d3539d71a12fe640f3af8d6fb4c680fd

EDD_Questionnaire_Individual_Blank_Form.docx.scpt - 94b7392133935d2034b8169b9ce50764

Investor Profile (Japan-based) - Shiro Arai.pdf.scpt - 319d905b83bf9856b84340493c828a0c

MITRE ATTACK

T1566 - Phishing

T1059.002 - Command and Scripting Interpreter: Applescript

T1059.004 – Command and Scripting Interpreter: Unix Shell

T1059.007 – Command and Scripting Interpreter: JavaScript

T1222.002 – File and Directory Permissions Modification

T1036.005 – Masquerading: Match Legitimate Name or Location

T1140 – Deobfuscate/Decode Files or Information

T1547.001 – Boot or Logon Autostart Execution: Launch Agent

T1553.006 – Subvert Trust Controls: Code Signing Policy Modification

T1082 – System Information Discovery

T1057 – Process Discovery

T1105 – Ingress Tool Transfer

References

[1] https://www.darktrace.com/blog/from-the-depths-analyzing-the-cthulhu-stealer-malware-for-macos

[2] https://www.darktrace.com/blog/unpacking-clickfix-darktraces-detection-of-a-prolific-social-engineering-tactic

[3] https://www.darktrace.com/blog/crypto-wallets-continue-to-be-drained-in-elaborate-social-media-scam

[4] https://developer.apple.com/documentation/appkit

[5] https://www.huntress.com/blog/full-transparency-controlling-apples-tcc

Continue reading
About the author
Tara Gould
Malware Research Lead

Blog

/

Network

/

February 5, 2026

Darktrace Malware Analysis: Unpacking SnappyBee

darktace malware analysis snappybeeDefault blog imageDefault blog image

Introduction

The aim of this blog is to be an educational resource, documenting how an analyst can perform malware analysis techniques such as unpacking. This blog will demonstrate the malware analysis process against well-known malware, in this case SnappyBee.

SnappyBee (also known as Deed RAT) is a modular backdoor that has been previously attributed to China-linked cyber espionage group Salt Typhoon, also known as Earth Estries [1] [2]. The malware was first publicly documented by TrendMicro in November 2024 as part of their investigation into long running campaigns targeting various industries and governments by China-linked threat groups.

In these campaigns, SnappyBee is deployed post-compromise, after the attacker has already obtained access to a customer's system, and is used to establish long-term persistence as well as deploying further malware such as Cobalt Strike and the Demodex rootkit.

To decrease the chance of detection, SnappyBee uses a custom packing routine. Packing is a common technique used by malware to obscure its true payload by hiding it and then stealthily loading and executing it at runtime. This hinders analysis and helps the malware evade detection, especially during static analysis by both human analysts and anti-malware services.

This blog is a practical guide on how an analyst can unpack and analyze SnappyBee, while also learning the necessary skills to triage other malware samples from advanced threat groups.

First principles

Packing is not a new technique, and threat actors have generally converged on a standard approach. Packed binaries typically feature two main components: the packed data and an unpacking stub, also called a loader, to unpack and run the data.

Typically, malware developers insert a large blob of unreadable data inside an executable, such as in the .rodata section. This data blob is the true payload of the malware, but it has been put through a process such as encryption, compression, or another form of manipulation to render it unreadable. Sometimes, this data blob is instead shipped in a different file, such as a .dat file, or a fake image. When this happens, the main loader has to read this using a syscall, which can be useful for analysis as syscalls can be easily identified, even in heavily obfuscated binaries.

In the main executable, malware developers will typically include an unpacking stub that takes the data blob, performs one or more operations on it, and then triggers its execution. In most samples, the decoded payload data is loaded into a newly allocated memory region, which will then be marked as executable and executed. In other cases, the decoded data is instead dropped into a new executable on disk and run, but this is less common as it increases the likelihood of detection.

Finding the unpacking routine

The first stage of analysis is uncovering the unpacking routine so it can be reverse engineered. There are several ways to approach this, but it is traditionally first triaged via static analysis on the initial stages available to the analyst.

SnappyBee consists of two components that can be analyzed:

  • A Dynamic-link Library (DLL) that acts as a loader, responsible for unpacking the malicious code
  • A data file shipped alongside the DLL, which contains the encrypted malicious code

Additionally, SnappyBee includes a legitimate signed executable that is vulnerable to DLL side-loading. This means that when the executable is run, it will inadvertently load SnappyBee’s DLL instead of the legitimate one it expects. This allows SnappyBee to appear more legitimate to antivirus solutions.

The first stage of analysis is performing static analysis of the DLL. This can be done by opening the DLL within a disassembler such as IDA Pro. Upon opening the DLL, IDA will display the DllMain function, which is the malware’s initial entry point and the first code executed when the DLL is loaded.

The DllMain function
Figure 1: The DllMain function

First, the function checks if the variable fdwReason is set to 1, and exits if it is not. This variable is set by Windows to indicate why the DLL was loaded. According to Microsoft Developer Network (MSDN), a value of 1 corresponds to DLL_PROCESS_ATTACH, meaning “The DLL is being loaded into the virtual address space of the current process as a result of the process starting up or as a result of a call to LoadLibrary” [3]. Since SnappyBee is known to use DLL sideloading for execution, DLL_PROCESS_ATTACH is the expected value when the legitimate executable loads the malicious DLL.

SnappyBee then uses the GetModule and GetProcAddress to dynamically resolve the address of the VirtualProtect in kernel32 and StartServiceCtrlDispatcherW in advapi32. Resolving these dynamically at runtime prevents them from showing up as a static import for the module, which can help evade detection by anti-malware solutions. Different regions of memory have different permissions to control what they can be used for, with the main ones being read, write, and execute. VirtualProtect is a function that changes the permissions of a given memory region.

SnappyBee then uses VirtualProtect to set the memory region containing the code for the StartServiceCtrlDispatcherW function as writable. It then inserts a jump instruction at the start of this function, redirecting the control flow to one of the SnappyBee DLL’s other functions, and then restores the old permissions.

In practice, this means when the legitimate executable calls StartServiceCtrlDispatcherW, it will immediately hand execution back to SnappyBee. Meanwhile, the call stack now appears more legitimate to outside observers such as antimalware solutions.

The hooked-in function then reads the data file that is shipped with SnappyBee and loads it into a new memory allocation. This pattern of loading the file into memory likely means it is responsible for unpacking the next stage.

The start of the unpacking routine that reads in dbindex.dat.
Figure 2: The start of the unpacking routine that reads in dbindex.dat.

SnappyBee then proceeds to decrypt the memory allocation and execute the code.

The memory decryption routine.
Figure 3: The memory decryption routine.

This section may look complex, however it is fairly straight forward. Firstly, it uses memset to zero out a stack variable, which will be used to store the decryption key. It then uses the first 16 bytes of the data file as a decryption key to initialize the context from.

SnappyBee then calls the mbed_tls_arc4_crypt function, which is a function from the mbedtls library. Documentation for this function can be found online and can be referenced to better understand what each of the arguments mean [4].

The documentation for mbedtls_arc4_crypt.
Figure 4: The documentation for mbedtls_arc4_ crypt.

Comparing the decompilation with the documentation, the arguments SnappyBee passes to the function can be decoded as:

  • The context derived from 16-byte key at the start of the data is passed in as the context in the first parameter
  • The file size minus 16 bytes (to account for the key at the start of the file) is the length of the data to be decrypted
  • A pointer to the file contents in memory, plus 16 bytes to skip the key, is used as the input
  • A pointer to a new memory allocation obtained from VirtualAlloc is used as the output

So, putting it all together, it can be concluded that SnappyBee uses the first 16 bytes as the key to decrypt the data that follows , writing the output into the allocated memory region.

SnappyBee then calls VirtualProtect to set the decrypted memory region as Read + Execute, and subsequently executes the code at the memory pointer. This is clearly where the unpacked code containing the next stage will be placed.

Unpacking the malware

Understanding how the unpacking routine works is the first step. The next step is obtaining the actual code, which cannot be achieved through static analysis alone.

There are two viable methods to retrieve the next stage. The first method is implementing the unpacking routine from scratch in a language like Python and running it against the data file.

This is straightforward in this case, as the unpacking routine in relatively simple and would not require much effort to re-implement. However, many unpacking routines are far more complex, which leads to the second method: allowing the malware to unpack itself by debugging it and then capturing the result. This is the approach many analysts take to unpacking, and the following will document this method to unpack SnappyBee.

As SnappyBee is 32-bit Windows malware, debugging can be performed using x86dbg in a Windows sandbox environment to debug SnappyBee. It is essential this sandbox is configured correctly, because any mistake during debugging could result in executing malicious code, which could have serious consequences.

Before debugging, it is necessary to disable the DYNAMIC_BASE flag on the DLL using a tool such as setdllcharacteristics. This will stop ASLR from randomizing the memory addresses each time the malware runs and ensures that it matches the addresses observed during static analysis.

The first place to set a breakpoint is DllMain, as this is the start of the malicious code and the logical place to pause before proceeding. Using IDA, the functions address can be determined; in this case, it is at offset 10002DB0. This can be used in the Goto (CTRL+G) dialog to jump to the offset and place a breakpoint. Note that the “Run to user code” button may need to be pressed if the DLL has not yet been loaded by x32dbg, as it spawns a small process to load the DLL as DLLs cannot be executed directly.

The program can then run until the breakpoint, at which point the program will pause and code recognizable from static analysis can be observed.

Figure 5: The x32dbg dissassembly listing forDllMain.

In the previous section, this function was noted as responsible for setting up a hook, and in the disassembly listing the hook address can be seen being loaded at offset 10002E1C. It is not necessary to go through the whole hooking process, because only the function that gets hooked in needs to be run. This function will not be naturally invoked as the DLL is being loaded directly rather than via sideloading as it expects. To work around this, the Extended Instruction Pointer (EIP) register can be manipulated to point to the start of the hook function instead, which will cause it to run instead of the DllMain function.

To update EIP, the CRTL+G dialog can again be used to jump to the hook function address (10002B50), and then the EIP register can be set to this address by right clicking the first instruction and selecting “Set EIP here”. This will make the hook function code run next.

Figure 6: The start of the hookedin-in function

Once in this function, there are a few addresses where breakpoints should be set in order to inspect the state of the program at critical points in the unpacking process. These are:

-              10002C93, which allocates the memory for the data file and final code

-              10002D2D, which decrypts the memory

-              10002D81, which runs the unpacked code

Setting these can be done by pressing the dot next to the instruction listing, or via the CTRL+G Goto menu.

At the first breakpoint, the call to VirtualAlloc will be executed. The function returns the memory address of the created memory region, which is stored in the EAX register. In this case, the region was allocated at address 00700000.

Figure 7: The result of the VirtualAlloc call.

It is possible to right click the address and press “Follow in dump” to pin the contents of the memory to the lower pane, which makes it easy to monitor the region as the unpacking process continues.

Figure 8: The allocated memory region shown in x32dbg’s dump.

Single-stepping through the application from this point eventually reaches the call to ReadFile, which loads the file into the memory region.

Figure 9: The allocated memory region after the file is read into it, showing high entropy data.

The program can then be allowed to run until the next breakpoint, which after single-stepping will execute the call to mbedtls_arc4_crypt to decrypt the memory. At this point, the data in the dump will have changed.

Figure 10: The same memory region after the decryption is run, showing lower entropy data.

Right-clicking in the dump and selecting "Disassembly” will disassemble the data. This yields valid shell code, indicating that the unpacking succeeded, whereas corrupt or random data would be expected if the unpacking had failed.

Figure 11: The disassembly view of the allocated memory.

Right-clicking and selecting “Follow in memory map” will show the memory allocation under the memory map view. Right-clicking this then provides an option to dump the entire memory block to file.

Figure 12: Saving the allocated memory region.

This dump can then be opened in IDA, enabling further static analysis of the shellcode. Reviewing the shellcode, it becomes clear that it performs another layer of unpacking.

As the debugger is already running, the sample can be allowed to execute up to the final breakpoint that was set on the call to the unpacked shellcode. Stepping into this call will then allow debugging of the new shellcode.

The simplest way to proceed is to single-step through the code, pausing on each call instruction to consider its purpose. Eventually, a call instruction that points to one of the memory regions that were assigned will be reached, which will contain the next layer of unpacked code. Using the same disassembly technique as before, it can be confirmed that this is more unpacked shellcode.

Figure 13: The unpacked shellcode’s call to RDI, which points to more unpacked shellcode. Note this screenshot depicts the 64-bit variant of SnappyBee instead of 32-bit, however the theory is the same.

Once again, this can be dumped out and analyzed further in IDA. In this case, it is the final payload used by the SnappyBee malware.

Conclusion

Unpacking remains one of the most common anti-analysis techniques and is a feature of most sophisticated malware from threat groups. This technique of in-memory decryption reduces the forensic “surface area” of the malware, helping it to evade detection from anti-malware solutions. This blog walks through one such example and provides practical knowledge on how to unpack malware for deeper analysis.

In addition, this blog has detailed several other techniques used by threat actors to evade analysis, such as DLL sideloading to execute code without arising suspicion, dynamic API resolving to bypass static heuristics, and multiple nested stages to make analysis challenging.

Malware such as SnappyBee demonstrates a continued shift towards highly modular and low-friction malware toolkits that can be reused across many intrusions and campaigns. It remains vital for security teams  to maintain the ability to combat the techniques seen in these toolkits when responding to infections.

While the technical details of these techniques are primarily important to analysts, the outcomes of this work directly affect how a Security Operations Centre (SOC) operates at scale. Without the technical capability to reliably unpack and observe these samples, organizations are forced to respond without the full picture.

The techniques demonstrated here help close that gap. This enables security teams to reduce dwell time by understanding the exact mechanisms of a sample earlier, improve detection quality with behavior-based indicators rather than relying on hash-based detections, and increase confidence in response decisions when determining impact.

Credit to Nathaniel Bill (Malware Research Engineer)
Edited by Ryan Traill (Analyst Content Lead)

Indicators of Compromise (IoCs)

SnappyBee Loader 1 - 25b9fdef3061c7dfea744830774ca0e289dba7c14be85f0d4695d382763b409b

SnappyBee Loader 2 - b2b617e62353a672626c13cc7ad81b27f23f91282aad7a3a0db471d84852a9ac          

SnappyBee Payload - 1a38303fb392ccc5a88d236b4f97ed404a89c1617f34b96ed826e7bb7257e296

References

[1] https://www.trendmicro.com/en_gb/research/24/k/earth-estries.html

[2] https://www.darktrace.com/blog/salty-much-darktraces-view-on-a-recent-salt-typhoon-intrusion

[3] https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain#parameters

[4] https://mbed-tls.readthedocs.io/projects/api/en/v2.28.4/api/file/arc4_8h/#_CPPv418mbedtls_arc4_cryptP20mbedtls_arc4_context6size_tPKhPh

Continue reading
About the author
Nathaniel Bill
Malware Research Engineer
Your data. Our AI.
Elevate your network security with Darktrace AI