Loading story…
Multiple security researchers published detailed analyses of Cobalt Strike loaders, shellcode, and beacon traffic, showing how attackers continue to wrap the framework in diverse delivery chains including malicious DLLs, .hta files, .vbs scripts, CACTUSTORCH payloads, and Nim-based stagers. Across the samples, the loaders commonly used VirtualAlloc, VirtualProtect, CreateThread, WriteProcessMemory, and WinINet APIs, while shellcode was frequently hidden with XOR, Base64, 3DES, or custom obfuscation and then resolved APIs dynamically through PEB traversal and ROR13-style API hashing. Reported command-and-control indicators included 116.62[.]138.47, 195.211.98[.]91, 51.79.49[.]174:443, and 42.193.229.33:12342, with several samples using legacy Internet Explorer-style user agents and HTTP downloader or reverse-beacon behavior.
The reporting also highlighted defender opportunities in memory and configuration analysis rather than static signatures alone. Analysts demonstrated extracting decrypted shellcode with hardware breakpoints, entropy-guided reverse engineering in Ghidra, and emulation in SpeakEasy, while other work showed how to recover or decrypt Beacon metadata and task traffic from leaked RSA keys or process memory. Additional hunting indicators included the named pipe pattern \\.\pipe\MSSE-%d-server, suspicious execution chains such as mshta.exe spawning child processes, and memory artifacts such as decoded payload stages, page-permission changes, and writable-memory key material. Together, the research shows that although Cobalt Strike payloads are heavily obfuscated and delivered through varied loaders, their in-memory behavior, decryption routines, and beacon communications remain practical points for detection and investigation.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
19 events from the most recent confirmed update back to the earliest known activity.
Jason Reaves published analysis of a Cobalt Strike stager variant that stores shellcode as UUID strings rather than conventional hex blobs. The write-up detailed decoding methods for standard, Go-based, and reversed-order UUID layouts and shared recovered IOCs, user agents, hashes, and a YARA rule for tracking the cluster.
Michael Koczwara published an analysis of a Cobalt Strike PowerShell payload, showing that an embedded Base64 block was XOR-encrypted with key 35. The write-up described extracting the encoded payload from the script and decrypting it with CyberChef.
A 64-bit DLL loader later analyzed as a Cobalt Strike shellcode loader was submitted to VirusTotal, where 37 security vendors detected it as malicious.
Michael Koczwara analyzed a Cobalt Strike Beacon payload configured for HTTP command-and-control to remote.claycityhealthcare.com over port 80, using distinct GET and POST URIs and a 30-second sleep with 20% jitter. The analysis also identified rundll32.exe spawn targets for x86 and x64, multiple process-injection methods, and customer watermark 2005485734.
Avast published a technical analysis of Cobalt Strike raw payloads and stagers, detailing identifying traits across DNS, SMB, TCP bind/reverse, HTTP, and HTTPS variants for x86 and x64. The write-up described API-hash patterns, checksum8 request-query behavior, watermark placement from version 3.9 onward, and XOR/encoding schemes to support detection and forensic analysis.
Jason Reaves published analysis of Cobalt Strike stagers that decode embedded shellcode using floating-point math and use a raw-socket request to google.com to perform an anti-sandbox sleep-tampering check. The write-up also shared file hashes, domains, IPs, and two Suricata-style signatures for detecting the stagers' outbound port-80 timing-check traffic.
GuidePoint Security analyzed a malicious DLL named 3z5pjb0l.ab4, executed via regsvr32 and DllInstall, and showed it reconstructed shellcode from GUID-like strings to download and run a Cobalt Strike beacon in memory. The researchers then retrieved and parsed the beacon configuration, identifying its network parameters and planned spawn target of svchost.exe -k netsvcs.
Didier Stevens analyzed a packet capture containing suspicious HTTP traffic, identified short URI patterns associated with Cobalt Strike shellcode, and exported the stream for offline review. Using the 1768.py tool, he confirmed the extracted data contained a Cobalt Strike beacon configuration.
A manual shellcode analysis in Ghidra and x32dbg resolved API hashes including LoadLibraryA, InternetOpenA, and InternetConnectA, and identified a C2 reference to 195.211.98[.]91.
An analyst used x64dbg hardware breakpoints to catch a Windows executable writing decoded shellcode into a VirtualAlloc buffer, dumped the payload, and emulated it to reveal C2 116.62[.]138.47 and path /8yHd.
A heavily obfuscated .vbs loader was deobfuscated to recover shellcode, revealing process-injection APIs, an EICAR marker, and a possible C2 address of 47.98.51[.]47; SpeakEasy emulation confirmed HTTP-based downloader behavior.
Analysis of a malicious .hta loader extracted and emulated embedded shellcode, showing downloader behavior attempting to retrieve content from 51.79.49[.]174:443.
A Ghidra-based analysis of a suspected Cobalt Strike DLL located a high-entropy blob at DAT_1800373a0 and identified FUN_180027a80 as the likely decryption function based on repeated references and XOR/SHR operations.
Unit 42 analyzed and named KoboldLoader, MagnetLoader, and LithiumLoader, describing their use of mapping injection, DLL masquerading, side-loading, and callback-based execution to deploy SMB, HTTPS, and stager beacons.
Unit 42 explained how Cobalt Strike Beacon encrypts metadata with RSA, derives AES and HMAC keys from decrypted metadata, and how leaked private keys can be used to decrypt captured Beacon metadata and task traffic.
Analysis of a malicious HTA built with CACTUSTORCH extracted a PE32 DLL beacon configured to contact 42.193.229.33:12342 using /j.ad and /submit.php, and identified watermark 305419896 associated with leaked Cobalt Strike builds.
NVISO described methods to recover AES and HMAC keys for decrypting Cobalt Strike traffic from process memory dumps, including 0x0000BEEF metadata extraction for version 3 beacons and a dictionary-style attack for version 4 beacons.
Jason Reaves published a follow-up investigation into Nim malware, including NimGrabber, NimRev, ransomware samples, and multiple Nim-based Cobalt Strike stagers using 3DES or modified Base64 decoding.
NVISO analyzed an early-detected phishing attempt against a financial-sector customer in which a malicious job-application document was used to deliver a DLL-based Cobalt Strike stager designed for COM hijacking persistence.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. View all 133 in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
19 references tracked. Mallory keeps watching after this page renders.
embeeresearch.io
Open sourceembeeresearch.io
Open sourceembee-research.ghost.io
Open sourceembee-research.ghost.io
Open sourceblog.nviso.eu
Open sourcemedium.com
Open sourceguidepointsecurity.com
Open sourceisc.sans.edu
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Multiple security researchers published new technical details on how **Cobalt Strike Beacon** can be modified and concealed during post-exploitation, while also outlining ways defenders can decode and detect its traffic. TrustedSec showed that Beacon’s XOR-obfuscated configuration blob can be altered in memory at runtime to change settings such as the **user-agent**, sleep and jitter values, HTTP verbs, spawn-to paths, ports, and even the active C2 destination after egress testing. Other reverse-engineering work described how Beacon resolves Windows syscalls for direct or indirect execution to evade monitoring, and how operators use **Malleable C2** profiles to shape network traffic and metadata encoding. Separate analyses highlighted how attackers increasingly hide Beacon communications behind trusted infrastructure, including **CDN services**, **domain fronting**, and **serverless reverse proxies** such as Cloudflare Workers, making attribution and blocking harder because traffic appears to target legitimate platforms. Defensive research from Unit 42, Splunk, and open-source tooling including **CobaltStrikeParser** focused on parsing Beacon configurations, decoding metadata formats such as `Base64`, `Base64URL`, `NetBIOS`, `NetBIOSU`, and `Mask`, and detecting suspicious profile settings like `spawnto_x86` and `spawnto_x64`. Together, the reports show that Cobalt Strike remains highly adaptable for adversaries and requires layered detection beyond simple perimeter filtering.
Aug 15, 2026
Security researchers detailed multiple ways to identify and decrypt **Cobalt Strike** command-and-control traffic, including the use of known private RSA keys recovered from cracked or rogue distributions. NVISO reported finding six unique RSA key pairs inside leaked Cobalt Strike ZIP packages and said more than 25% of over 1,500 fingerprinted Internet-facing servers used one of two widely reused key pairs, allowing analysts to identify rogue beacons and in some cases decrypt beacon metadata and full C2 communications with tools such as **1768.py**. The research also showed how defenders can recover and decode traffic protected by **malleable C2** transformations and sleep-masked beacon memory. Analysts can reverse custom transforms such as dropped bytes, Base64 URL decoding, and XOR decoding to recover encrypted payloads, then extract AES and HMAC keys from process memory—even when beacon memory is obfuscated during sleep—using tools including **cs-analyze-processdump.py**, **cs-extract-key.py**, and **cs-parse-traffic.py** to decrypt HTTP(S) and DNS beacon traffic.
Aug 15, 2026
A malware loader linked to a **TrickBot-associated intrusion crew** was observed fetching an encoded payload from GitHub files disguised as images, decoding the data into shellcode, and launching a 64-bit **Cobalt Strike** beacon directly in memory. The sample used obfuscated strings, manually resolved APIs from `ntdll.dll` and `kernel32.dll`, and loaded `wininet.dll` to handle network communications, reflecting a stealth-focused delivery chain commonly associated with post-compromise ransomware activity. Analysis of the beacon configuration tied command-and-control traffic to `rainbowmango.info` subdomains over **HTTPS/443**, with `gpupdate.exe` configured as the **spawn-to** process for execution. One GitHub account previously used to host the payload was later deleted, indicating likely operational cleanup by the actor as defenders and researchers tracked the infrastructure and tooling behind the campaign.
Aug 15, 2026