ctipilot.ch
← Back to the live brief
NOTABLEupdateNATOB2threat

UPDATE — Project CAV3RN now decides per transaction whether to talk directly or relay through Google Apps Script, and a DNS answer's fourth octet is what makes the choice

discovered 2026-08-12 04:51 UTCrun 2026-08-12T0411Z-intel1 sourcesingle-source

UPDATE · originally covered Kaspersky corroborates the Cavern/HOLLOWGRAPH cluster, associates it (low confidence) with OilRig (APT34), and details a DNS AAAA-record C2 config-recovery fallback (2026-07-22)

Kaspersky's GReAT team published a further instalment on Project CAV3RN on 2026-08-11, describing it as "a modular espionage framework used against targets in Israel" and expanding on two earlier publications (Kaspersky Securelist, 2026-08-11). The prior entry here covered the framework's DNS-based C2 fallback and Kaspersky's low-confidence association with OilRig. The delta is a channel-selection design that is worth carrying into detection engineering regardless of who operates it.

Kaspersky states: "The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel" (Kaspersky Securelist, 2026-08-11). The mechanics are specific enough to hunt on. The communication module is a 64-bit DLL compiled with .NET 8 NativeAOT. Before polling for commands or sending a result, it issues an A-record query for a name built from a short random nonce concatenated with a numeric error state, then a hex-encoded client identifier, under a fixed operator-controlled domain. One exact address is treated as a rejection; otherwise the module reads the fourth octet of the answer and maps it, in combination with the current error state, onto direct HTTPS, the Apps Script relay, an exception, or closing the transaction with no channel at all. A recovered Apps Script deployment ID is written back to the module's on-disk configuration, while other configuration changes pushed by the operator stay in memory. The two channels differ in shape as well as destination. On the direct-HTTPS path the module contacts a configured attacker-controlled address whose endpoint is gated on a custom client-identifier HTTP header, returning a failure response to requests without it and an encoded tasking body to requests carrying it. On the Apps Script path the module instead POSTs a JSON envelope to the deployment URL, with the upstream method and the headers to replay — the same client-identifier value among them — carried as fields inside that JSON body rather than as headers on the request to Google. Tasking comes back base64-encoded and XORed either way.

The second new component is an inter-component broker, a 64-bit Visual C++ DLL that masquerades as the RNP OpenPGP library through a set of rnp_* exports, with one of those exports starting the broker. At startup it creates its control structure, initialises a message dispatcher and scans the host directory for DLLs, grouping candidates by their CompanyName resource and loading the highest-versioned member of each group that exposes four specific named exports. It rescans that directory every second, so a component can be added or upgraded without restarting the host — but only by dropping a higher-versioned DLL under a new path, because replacing a file in place is not detected (Kaspersky Securelist, 2026-08-11).

Triage: high-volume DNS lookups under a single parent domain are also how legitimate telemetry agents, CDN clients and some licence checks behave, so the query volume alone is not the signal. The discriminators the described mechanism supports are the label structure — a short changing nonce plus a stable hex-encoded identifier per host, rather than a service-shaped name — and the tight temporal coupling, with one lookup preceding each outbound connection rather than a periodic refresh independent of traffic. Note what is not available as a discriminator on the relay path: the custom client-identifier travels inside the JSON body of a TLS POST to a legitimate Google endpoint, so it is not visible to header inspection or to anything short of TLS interception at the proxy.

Project CAV3RN is a modular espionage framework used against targets in Israel.

The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

Kaspersky Securelist (GReAT) 2026-08-11

ATT&CK mapping

6 techniques mapped from the cited reporting · MITRE ATT&CK v19.2

Stealth TA0005
T1027Obfuscated Files or Information

Adversaries may attempt to make an executable or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the system or in transit. This is common behavior that can be used across different platforms and the network to evade defenses.

overlap matrix · ATT&CK page ↗

T1036.005Masquerading: Match Legitimate Resource Name or Location

Adversaries may match or approximate the name or location of legitimate files, Registry keys, or other resources when naming/placing them. This is done for the sake of evading defenses and observation.

overlap matrix · ATT&CK page ↗

Command and Control TA0011
T1071.004Application Layer Protocol: DNS

Adversaries may communicate using the Domain Name System (DNS) application layer protocol to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.

overlap matrix · ATT&CK page ↗

T1102.002Web Service: Bidirectional Communication

Adversaries may use an existing, legitimate external Web service as a means for sending commands to and receiving output from a compromised system over the Web service channel. Compromised systems may leverage popular websites and social media to host command and control (C2) instructions. Those infected systems can then send the output from those commands back over that Web service channel. The return traffic may occur in a variety of ways, depending on the Web service being utilized. For example, the return traffic may take the form of the compromised system posting a comment on a forum, issuing a pull request to development project, updating a document hosted on a Web service, or by sending a Tweet.

overlap matrix · ATT&CK page ↗

T1105Ingress Tool Transfer

Adversaries may transfer tools or other files from an external system into a compromised environment. Tools or files may be copied from an external adversary-controlled system to the victim network through the command and control channel or through alternate protocols such as ftp. Once present, adversaries may also transfer/spread tools between victim devices within a compromised environment (i.e. Lateral Tool Transfer).

overlap matrix · ATT&CK page ↗

T1568Dynamic Resolution

Adversaries may dynamically establish connections to command and control infrastructure to evade common detections and remediations. This may be achieved by using malware that shares a common algorithm with the infrastructure the adversary uses to receive the malware's communications. These calculations can be used to dynamically adjust parameters such as the domain name, IP address, or port number the malware uses for command and control.

overlap matrix · ATT&CK page ↗

PROVENANCE

AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.