Loading story…
Palo Alto Networks Unit 42 detailed active probing and network fingerprinting methods that can identify Cobalt Strike Team Servers before a victim Beacon establishes command-and-control communications. The research found that Team Servers exhibit distinctive responses to specific HTTP methods, URI requests, and DNS queries, including recognizable behavior for OPTIONS requests, stager and stager64 paths, beacon.http-get and beacon.http-post paths, random URIs, and checksum-based URI handling. Although Malleable C2 profiles can modify some traffic characteristics, the underlying server behavior still leaves detectable patterns defenders can use.
Using those fingerprints with internet-wide scanning and open-source intelligence platforms such as Shodan, Censys, and ZoomEye, the researchers identified multiple live Team Server instances in the wild and published supporting indicators including IP addresses, URI paths, and sample hashes tied to Cobalt Strike infrastructure and Beacon payloads. The findings give defenders a way to hunt for adversary-controlled C2 infrastructure earlier in the intrusion lifecycle and improve blocking, monitoring, and threat intelligence enrichment around Cobalt Strike activity.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
Using active probing, network fingerprinting, and open-source intelligence sources including Shodan, Censys, and ZoomEye, researchers identified multiple live Cobalt Strike Team Server instances on the internet. The article states these instances were discovered in September 2022 and provides associated IPs, ports, URIs, and sample hashes.
Fox-IT disclosed a technique to identify publicly reachable Cobalt Strike team servers by detecting an anomalous extra space in HTTP responses generated by the NanoHTTPD-based web server. The blog also shared historical scan findings, a server list, and a Snort rule to help defenders investigate possible Cobalt Strike activity.
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 12 in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
3 references tracked. Mallory keeps watching after this page renders.
unit42.paloaltonetworks.com
Open sourceblog.fox-it.com
Open sourcejsac.jpcert.or.jp
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
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.
Aug 15, 2026