CAV3RN DNS control-plane response
At a glance
- Malware family: Project CAV3RN
- Threat actor: Unattributed cyber espionage cluster
- Target or victims: Targeted organizations in Israel
- Delivery vector: Under investigation
- Key capabilities: DNS-based command selection, Google Apps Script relays, local DLL brokering
- Source: Kaspersky Labs
TL;DR
Kaspersky Labs tracks Project CAV3RN as an expanding cyber espionage operation. The operators recently added DNS routing and Google Apps Script relays to their toolkit.
Delivery
Security researchers continue tracking this threat cluster closely. Currently, the exact delivery mechanisms remain under investigation. The attackers direct these payloads exclusively at organizations in Israel. Initially, researchers observed the operators abusing Outlook calendar events. Now, the threat actors abuse Google web services to bypass network defenses. They deploy custom 64-bit DLL modules to targeted endpoints. Furthermore, the malware uses embedded configuration defaults when it first launches. The module reads a local configuration file or generates a random seven-character client identifier.
Infection chain
Once inside a network, the Project CAV3RN framework relies on a local broker named rnp.dll. This broker masquerades as a legitimate RNP OpenPGP library. It creates a control structure and initializes a message dispatcher. Then, it scans the host directory for other DLL components. The broker groups these components by company name and loads the newest versions.
Furthermore, the system rescans the directory every second. This frequent scanning allows operators to upgrade components without restarting the host. The broker coordinates messages between loaded modules. It routes specific packets, like command payloads, directly to the correct destination. If a component unloads, the broker halts its worker threads safely. The communication module itself is compiled with Microsoft NativeAOT. This module supports internal commands to manage diagnostic logging, write decoded files, and replace settings in memory.
Command-and-control and data-exfiltration behaviour
The malware uses a new communication module named GoogleService.dll. This module connects the local broker to external control servers. “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 report writes. Before polling for commands, it performs a DNS A-record query. The malware formats these queries with a random nonce and an error state indicator. The returned IP address dictates which channel the module uses next.
If the DNS query selects Google mode, the malware relies on a Google Apps Script deployment ID. The malware calculates an MD5 digest of its stored ID. It compares this hash with a specific DNS record. If they do not match, the malware fetches a new ID in chunks. “The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel,” the report notes.
During communication, the module routes traffic through the script relay. This relay forwards requests to an actor-controlled backend server. If the DNS query selects direct HTTPS, the module bypasses Google entirely. Instead, it connects straight to the attacker server using a custom client header.
Defense or detection guidance
Defenders face significant challenges blocking this multi-transport architecture. Security teams must monitor DNS queries for suspicious patterns. Specifically, look for large, alphanumeric labels containing the “.m.”, “.q.”, or “.p.” subdomains. Analysts should watch for unusual DNS TXT or A-record chunking behavior.
Additionally, organizations should scrutinize unusual Google Apps Script execution. Block unauthorized outbound connections to Google script domains if business policies allow. Monitor endpoints for unknown DLL files masking as OpenPGP libraries. Endpoint detection tools should flag unusual inter-process DLL loading activity. Network administrators must monitor for custom HTTP headers like “X-Client-Id” in traffic. Finally, maintain updated threat intelligence feeds to track new domain indicators tied to this group.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.