A state-sponsored APT has deployed HazyBeacon, a sophisticated Windows backdoor, targeting high-value corporate environments through WordPress exploitation. The campaign leverages a "living-off-the-cloud" strategy, utilizing Amazon Web Services (AWS) Lambda functions to host serverless Command and Control (C2) infrastructure. By mimicking legitimate AWS API traffic and employing Steam Community profiles as secondary covert communication and data staging channels, the threat actor bypasses traditional network security perimeters, DNS filtering, and IP reputation-based detection. This architecture ensures long-term persistence and enables undetected data exfiltration within enterprise networks by masking malicious traffic within high-reputation cloud service streams.

• Incident Overview: HazyBeacon Deployment
  • Deployment of a custom Windows-based backdoor designed for long-term espionage.
  • Utilization of high-reputation cloud services to mask malicious activities.
  • Focus on maintaining persistence within high-value corporate networks.
• Attack Vector: WordPress to Windows Transition
  • Initial access achieved via exploitation of vulnerabilities in WordPress sites and plugins.
  • Payload delivery facilitates the installation of the HazyBeacon backdoor on Windows endpoints.
  • Moves from web-layer compromise to deep internal network presence.
• Threat Group Profile: State-Backed Espionage
  • Attributed to a sophisticated, state-sponsored Advanced Persistent Threat (APT).
  • Targeted intelligence gathering against "Big corporate ships" and enterprise entities.
  • Highly disciplined operational security (OPSEC) to avoid traditional detection.
• C2 Architecture: Living-off-the-Cloud
  • Employs AWS Lambda for serverless C2, bypassing IP-based blacklisting.
  • Uses customized communication protocols that mimic legitimate AWS API traffic.
  • Utilizes Steam Community profiles for covert signaling and secondary data staging.
• Detection Challenges: Bypassing Perimeter Security
  • Bypasses DNS and IP reputation filtering by leveraging trusted cloud subdomains.
  • Negates standard egress filtering as AWS traffic is frequently whitelisted.
  • Extremely difficult to distinguish from legitimate cloud-native application behavior.