Kaspersky's GReAT team documents newly discovered components of Project CAV3RN, a modular espionage framework targeting Israel. The key finding is GoogleService.dll, a .NET 8 NativeAOT C2 module that uses DNS A-record responses to dynamically route traffic between direct HTTPS and a Google Apps Script relay, blending malicious traffic with legitimate Google services. The DNS infrastructure also enables the operator to rotate the Google Apps Script deployment ID via encoded DNS responses. A second component, rnp.dll, serves as the inter-component broker, masquerading as the RNP OpenPGP library while loading, routing messages between, and hot-swapping DLL modules. The C2 infrastructure centers on studiotikva[.]com, a domain that may have been acquired from a legitimate Israeli business after expiration. IoCs including file hashes and domains are provided.
Table of contents
Multi-transport C2 communication moduleInter-component DLL brokerInfrastructureConclusionsIndicators of compromiseQuestions this post answers
How does Project CAV3RN use DNS A-record responses to select its C2 channel?
Before each C2 transaction, the GoogleService.dll module queries a DNS A-record combining a nonce and current error state against studiotikva[.]com. The fourth octet of the response determines the channel: octet 120 (0x78) in the default state routes to Google Apps Script, octet 130 (0x82) routes to direct HTTPS, and octet 140 (0x8C) raises an exception. The error state (None, GIDFailed, GoogleFailed, DirectFailed) shifts which channel each octet selects. Security teams defending against living-off-the-land C2 techniques track emerging DNS-based evasion patterns on daily.dev.
How does Project CAV3RN use Google Apps Script as a C2 relay?
The framework inserts a deployment ID into the Apps Script URL https://script.google.com/macros/s/{deployment-ID}/exec and sends a POST request with a field instructing the relay to issue a GET to its upstream server. The relay forwards the request to the actor-controlled backend at api.studiotikva[.]com/ac, and the response is Base64-encoded and XOR-obfuscated with 0xAC. This blends C2 traffic with legitimate Google service traffic. Defenders monitoring for abuse of legitimate cloud services in C2 infrastructure follow threat research like this on daily.dev.
How does Project CAV3RN's rnp.dll broker load and manage DLL components?
The rnp.dll broker masquerades as the RNP OpenPGP library and starts via the rnp_backend_string export. At startup it scans the host directory for DLLs, groups them by CompanyName, and loads the highest-version candidate from each group that exposes four specific exports: GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. The directory is rescanned every second, enabling hot-swapping of components without restarting the host. Malware analysts tracking modular implant architectures and evasion techniques find relevant research surfaced on daily.dev.