BadAudio and APT24: “good enough” OPSEC powering a multi-vector espionage chain

Reverse engineering shows pragmatic obfuscation, hardcoded crypto, and cloud-native infrastructure supporting scalable intrusion delivery.

APT24 · BADAUDIO · supply-chain compromise · watering holes · Cloudflare Workers · Taiwan

Metadata

• Affected vendor / product: Windows endpoints; websites consuming compromised third-party JavaScript
• Primary issue: PRC-linked cyber-espionage delivery chain (watering hole + supply chain + phishing) using BADAUDIO
• Exploitation status: Observed in the wild
• Confidence level: High (delivery chain and BADAUDIO behaviour); Medium (cross-vendor naming alignment for “APT24”)
• Severity: High (supply-chain blast radius reported at 1,000+ domains)
• Patch / mitigation status: No single patch; remediation depends on web-supply-chain hygiene, endpoint controls, and network blocking
• Sectors at risk: Organisations with Taiwan exposure; web properties relying on third-party marketing / analytics scripts
• Regions at risk: Taiwan (primary in current reporting); East Asia and US appear in historical reporting for overlapping clusters

Executive Summary

Google’s Threat Intelligence Group (GTIG) attributes a nearly three-year espionage campaign to a PRC-nexus actor it tracks as APT24, centred on a custom first-stage downloader called BADAUDIO and delivered via watering holes, supply-chain compromise, and targeted phishing. (Google Cloud)
A follow-on reverse engineering write-up by Securite360 dissects a publicly available BADAUDIO sample, highlighting low-cost but effective obfuscation, HTTP cookie-based beaconing, and AES-CTR encryption implemented with a hardcoded key. (securite360.net)
The most operationally significant shift is GTIG’s reporting that APT24 repeatedly compromised a Taiwanese regional digital marketing firm, impacting more than 1,000 domains and enabling scalable, selective malware delivery. (Google Cloud)
Defenders should treat this as both an endpoint problem and a web-supply-chain problem: compromise can begin on a legitimate site, then pivot into enterprise endpoints via social engineering and DLL sideloading chains. (Google Cloud)

Context

GTIG describes APT24’s activity as evolving “beyond the watering hole”, moving from broad strategic web compromises to supply-chain compromise and targeted phishing with an emphasis on Taiwan-based victimology. (Google Cloud)
BADAUDIO is characterised as a heavily obfuscated C++ downloader that fingerprints the victim, communicates over HTTP(S) with encrypted metadata in cookies, and retrieves an AES-encrypted second stage that is decrypted and executed (in at least one observed case, Cobalt Strike Beacon). (Google Cloud)
Securite360’s reverse engineering adds implementation-level clarity (string deobfuscation approach, specific WinINet API usage, AES mode selection), which is useful given GTIG’s broader focus on campaign evolution. (securite360.net)

APT24: what is known (and why naming is messy)

“APT24” is not a universally consistent label. Securite360 explicitly notes that open-source reporting on APT24 is limited and sometimes inconsistent, which complicates definitive assessments. (securite360.net)
Microsoft’s threat actor naming crosswalk lists “APT24” as an alias associated with Canary Typhoon and BlackTech, alongside other vendor names such as Circuit Panda and Palmerworm. (Microsoft Learn)
MITRE ATT&CK’s BlackTech entry describes a suspected Chinese cyber-espionage group targeting East Asia (particularly Taiwan, Japan, and Hong Kong) and the US since at least 2013, using a blend of custom malware and living-off-the-land techniques. (MITRE ATT&CK)
In 2023, US and Japanese agencies published a joint advisory on BlackTech tradecraft, describing router firmware-level concealment and pivoting via trusted relationships, reinforcing the broader theme that PRC-linked operators optimise for stealth and persistence over showy tooling. (CISA)

Analyst takeaway: for the BadAudio campaign, treat GTIG’s APT24 as the authoritative tracking label for the activity described, and use crosswalks (Microsoft, MITRE, government advisories) as context rather than proof of perfect one-to-one equivalence between all vendor clusters. (Google Cloud)

Technical Analysis

Delivery: from watering holes to supply chain at scale

GTIG observed an initial phase (from November 2022) involving strategic web compromises of legitimate sites, where injected JavaScript performed visitor filtering and fingerprinting (including use of FingerprintJS) to selectively present a fake browser update prompt that dropped BADAUDIO. (Google Cloud)
The campaign escalated in July 2024 when APT24 compromised a regional digital marketing firm in Taiwan, impacting more than 1,000 domains that consumed the firm’s scripts, with repeated re-compromise attempts over the following year. (Google Cloud)
GTIG also reports targeted phishing that distributed encrypted archives (including via legitimate cloud storage services) and used tracking elements, suggesting the actor runs parallel access pipelines and is willing to invest in audience selection before deployment. (Google Cloud)

Relevant ATT&CK alignment here includes T1189 for drive-by compromise and T1195.001 for compromised dependencies and development tools when third-party scripts become the delivery mechanism. (MITRE ATT&CK)

BADAUDIO: “highly obfuscated”, but built for throughput

GTIG reports BADAUDIO commonly appears as a malicious DLL executed via DLL search order hijacking (T1574.001), with newer variants using archives containing supporting VBS, BAT, and LNK components to automate placement and trigger sideloading and persistence. (Google Cloud)
On execution, the malware collects host identifiers (hostname, username, architecture), encrypts them with a hardcoded AES key, and transmits the result as a cookie value within an HTTP GET request to retrieve a second stage. (Google Cloud)
GTIG confirmed at least one downstream payload as Cobalt Strike Beacon, but explicitly cautions this is not confirmed in every instance. (Google Cloud)

“OPSEC on a budget”: what Securite360’s reverse engineering adds

Securite360’s sample-level analysis describes string obfuscation implemented via stack-based reconstruction and SSE XOR unmasking, designed to frustrate static tooling and accelerate operator iteration without the cost of more exotic protections. (securite360.net)
The write-up also details the network implementation: WinINet APIs construct a GET request (including a hardcoded path in the analysed sample) and inject an encrypted blob into a Cookie header field, consistent with GTIG’s cookie-beaconing description. (securite360.net)
Securite360 highlights a key weakness from an OPSEC perspective: AES-256 in CTR mode is used, but the key is hardcoded in the binary, meaning defenders who extract it can potentially decrypt captured traffic retroactively. (securite360.net)
Both GTIG and Securite360 note abuse of legitimate cloud infrastructure (notably Cloudflare Workers) as a blend-in mechanism that can erode the value of simple reputation-based blocking. (Google Cloud)

Indicators of Compromise

The following indicators are drawn directly from public reporting. Treat them as campaign-scoped rather than universal, as GTIG observed multiple delivery mechanisms and infrastructure rotation. (Google Cloud)

Detection and hunting guidance (source-led)

GTIG published YARA content for BADAUDIO and points readers to a VirusTotal collection of related IOCs for registered users, which is the safest way to consume a fuller indicator set without relying on third-party reposts. (Google Cloud)
At the network layer, both reports support hunting for unusual HTTP GETs where long, high-entropy cookie values appear to carry encrypted host metadata, especially to workers.dev subdomains not normally used in your environment. (Google Cloud)
On endpoints, prioritise telemetry for DLL sideloading behaviour aligned to T1574.001, and for persistence mechanisms involving startup entries (GTIG describes “startup entries” rather than a single specific artefact, so validate locally before scoping). (Google Cloud)

Incident Response Guidance

1. Scope by web exposure first: identify corporate sites and subsidiaries consuming third-party marketing or analytics scripts, then validate integrity and change history. GTIG’s reporting makes clear the web layer can be the initial access vector. (Google Cloud)
2. Contain at both tiers: block known C2 domains and worker subdomains from GTIG’s list while simultaneously isolating affected endpoints showing DLL sideloading or suspicious archive execution chains. (Google Cloud)
3. Preserve browser and web artefacts: collect web server logs, CDN logs, and JavaScript artefacts (including third-party library versions) to reconstruct the injection timeline and determine whether selective targeting logic was present. (Google Cloud)
4. Validate persistence: inspect startup entries and recently dropped script shortcuts (VBS/BAT/LNK) described by GTIG in newer chains, but do not assume a single canonical filename or path. (Google Cloud)

Mitigation Recommendations

• Lock down third-party script execution: use Subresource Integrity (SRI), strict Content Security Policy (CSP), and vendor allow-listing for external scripts to reduce the supply-chain attack surface implied by GTIG’s “1,000+ domains” compromise scenario. (Google Cloud)
• Treat cloud-serverless domains as “conditionally trusted”: implement policy-based egress controls and alerting for unexpected access to Cloudflare Workers subdomains, especially where traffic patterns resemble encrypted beaconing in headers. (Google Cloud)
• Harden for sideloading: improve application control and monitor for unsigned DLLs loaded by trusted processes from user-writable directories, aligned to T1574.001. (Google Cloud)
• Assume reinfection pressure: GTIG’s repeated re-compromise observations suggest you should validate that remediation includes credential hygiene, CI/CD security, and monitoring, not just file replacement. (Google Cloud)

Threat Intelligence Context

This campaign is a clean example of a broader PRC-nexus pattern: selective targeting, operational persistence, and a preference for tradecraft that scales (web injection, third-party dependencies, commodity post-exploitation) rather than bespoke zero-days. (Google Cloud)
From an OPSEC perspective, Securite360’s conclusion is telling: the obfuscation is optimised to slow triage and static detection, but hardcoded cryptographic material and disposable infrastructure can create strong investigative leverage once samples are obtained. (securite360.net)

ATT&CK mapping (observed in reporting)

(Google Cloud)

Further Reading

• GTIG: Beyond the Watering Hole – APT24’s Pivot to Multi-Vector Attacks (Google Cloud)
• Securite360: OPSEC on a Budget – What BadAudio Reveals About APT24 (securite360.net)
• BleepingComputer coverage of GTIG’s APT24 / BadAudio reporting (BleepingComputer)
• CISA Joint Advisory AA23-270A on BlackTech tradecraft (CISA)
• MITRE ATT&CK group profile: BlackTech (G0098) (MITRE ATT&CK)