CAV3RN picks its C2 channel by DNS lookup, and rotates the Google half on demand

Kaspersky's Securelist has published new analysis of Project CAV3RN, a modular espionage framework used against targets in Israel, centred on a communication module that decides per transaction whether to reach its operators over direct HTTPS or through a Google Apps Script relay ^[1][2]. The decision is made by a DNS A-record lookup, and the same DNS infrastructure can validate and replace the Apps Script deployment ID ^[2][3], which turns a Google-domain allowlist from a boundary into a lane the operator can steer traffic into at will.

The module is GoogleService.dll, a 64-bit DLL built with .NET 8 NativeAOT ^[4]. Before polling for commands or returning a result, it queries a name of the form `<nonce><error state>.<hex-encoded client ID>.m.studiotikva.com` ^[5]. The first label pairs a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, 3 for DirectFailed, with each new transaction starting at 0 ^[6]. The exact answer 12.19.29.30 is a rejection; anything else is read by its fourth octet ^[7]. During analysis, valid `.m` queries returned 12.121.234.120 and malformed ones returned 12.19.29.30 ^[8]. In the worked example, `YCZ2.41414141303030.m.studiotikva[.]com` carried state 2 and the final octet 120 selected direct HTTPS ^[9].

When the Google path is chosen, the module takes the MD5 of its stored deployment ID and compares the first four bytes against the A record from a `.q` subdomain ^[10]. A mismatch sends it to `.p` queries for a replacement ^[11]. The offset-0 answer carries a one-byte length and the first three ID bytes; each further answer carries four ^[12]. The observed 74.65.75.102 decoded to a length of 74 followed by `AKf` ^[13], and one initial plus 18 continuation answers produced a 74-character ID redacted as `AKfycby46v0DPSEKWYa****dvQ` ^[14]. That is 75 bytes collected against a declared 74, which is why the DLL discards the last padding byte instead of asking for offset 76 ^[15][16]. The recovered ID is written back to conf.json; changes pushed by the `s_config` command live only in memory ^[17].

Two operational consequences. Rotation means a blocked deployment ID costs the operator one set of `.p` records, so deployment-ID indicators decay on the attacker's schedule, not the defender's ^[3][11]. And the error state is a feedback channel: the module tells the server which leg failed last time ^[6], so an environment that blocks direct HTTPS is quietly reporting that fact and inviting the server to keep the session on the Google relay. Filtering that stops at the domain name cannot see the difference.

The module is also replaceable. Kaspersky describes a local broker that discovers and loads DLL components, routes messages between them and supports runtime upgrades ^[18]; the module's first report is an inventory of DLLs under its base directory with company names and versions, XORed with 0xAC and Base64-encoded ^[19].

Worth watching: whether the `.q` validation and `.p` recovery pattern shows up outside this cluster, and whether DNS telemetry in affected estates retains enough resolver detail to spot short uppercase first labels over long hex ones. Kaspersky's earlier reporting on this framework ran in June 2026 through its threat intelligence service and in July on Securelist, with the components above found in early August 2026 ^[20][21][22], so further modules are a reasonable expectation.