AdFection Technical Architecture: A Defensive TTP Breakdown

Conditional ad-markup cloaking

What the attacker does

Public reporting describes request-conditioned delivery: selected requests receive additional code, while other requests can receive benign or empty responses. This can cause scanners without the selected target context to miss the additional code[1,7].

Illustrative implementation: cloaking.py

In the proposed example, the process_bid function in cloaking.py dynamically constructs the adm (ad markup) string. A target match would produce markup containing a base64-encoded JSON configuration and a script tag referencing adint.js. A non-matching request, such as a scanner without the selected target MAID, would instead receive a clean HTML div with a low bid.

Evidence note: these filenames, the function name, the configuration format, and the bidding behavior are illustrative details supplied for this example, not verified recovered AdFection source code. A clean scanner response alone does not establish that a creative is safe.

Why it defeats analysis

Automated ad-review crawlers, sandbox detonations, and security scanners do not carry the target's MAID or reproduce the target's request context. They therefore walk the benign branch and see an ordinary div. Static scanning of the creative URL is insufficient because the malicious path is conditional on identifiers the scanner does not present.

Detection surfaces

• Correlate a single creative URL serving structurally divergent adm payloads across requests with different MAID/IP fingerprints — payload divergence is the cloaking signature.
• Flag bid responses whose adm contains base64-JSON config blobs plus a remote script tag, especially when the same creative returns bare divs to other request profiles.
• Instrument the bid server, not just the creative: the branching decision is the indicator, and it lives in the response-generation logic.
• Cross-reference with the downstream validator/C2 infrastructure in the IOC database — a cloaked creative that later contacts a known Candiru validator is high-confidence.

Ephemeral ECDH C2 key derivation

What the attacker does

Public reporting describes encrypted channels associated with the pipeline, including ECDH/AES and DNS-over-HTTPS, which complicate passive network analysis[7].

Illustrative implementation: adint.js & ecdh.py

In the proposed example, rather than hardcoded AES keys, the adint.js client uses the browser's native crypto.subtle API to generate an ephemeral ECDH keypair, with ecdh.py handling the server-side counterpart and shared-key derivation. This matches Confiant's finding that Candiru uses dynamic key derivation to encrypt C2 traffic, making passive network analysis incredibly difficult.

Evidence note: the filenames adint.js and ecdh.py and the specific client/server split are illustrative details supplied for this example, not verified recovered AdFection source code. The dynamic key-derivation behavior, by contrast, is reported by Confiant.

Why it defeats analysis

Passive network capture yields only the ephemeral public key and ciphertext. Without the server's private half — which is generated per-session and never persisted in the client — the traffic cannot be decrypted after the fact. This matches Confiant's finding that Candiru uses dynamic key derivation, making retroactive traffic analysis infeasible even where full PCAPs exist.

Detection surfaces

• Detect the use of crypto.subtle generateKey with an ECDH curve inside ad-served JavaScript — legitimate ad creatives rarely perform key generation.
• Flag ad scripts that immediately establish a long-lived encrypted websocket/fetch channel to a non-ad-domain endpoint.
• Pin and monitor the C2 endpoint domains and certificates (see the IOC database) — the encryption hides content, not the existence of the channel.
• Endpoint-side (browser telemetry / EDR) instrumentation can observe the key generation call and the outbound channel before encryption hides the payload.

WebAssembly exploit trigger

What the attacker does

The final stage loads a WebAssembly module as the exploit trigger. WASM executes outside the JavaScript JIT's normal visibility and closer to the raw machine layer, which is the prerequisite for a JIT-boundary or memory-corruption primitive in a modern, heavily sandboxed mobile browser (iOS Safari, Android Chrome). The WASM module is the vehicle that attempts to cross the sandbox boundary and hand control to the Candiru validator[1,7].

Why it defeats analysis

Standard JS-based sandboxing and JS-aware security tooling have poor visibility into WASM execution. The module's bytes are compact, binary, and can be obfuscated or split across fetches, so static string/signature scanning of the creative misses it. Mobile browsers' JS sandboxes are precisely the boundary WASM is chosen to pressure.

Detection surfaces

• Flag ad-served WebAssembly modules — a creative that fetches and instantiates a .wasm blob is rare in legitimate programmatic advertising and warrants review.
• Monitor for WASM modules that request capabilities (memory, threads, SIMD) disproportionate to a display ad's needs.
• Sandbox detonations that execute WASM and observe post-execution process/thread anomalies catch the boundary-crossing attempt that static scanning misses.
• Pair with the CVE database — a WASM trigger paired with a known Candiru-linked browser CVE is a high-confidence campaign indicator.