GBHackers

Project CAV3RN Uses Google Apps Script and DNS to Hide C2 Traffic in Israeli Cyberespionage Attacks


Project CAV3RN, a modular cyberespionage framework targeting organizations in Israel, has added a sophisticated command-and-control design that dynamically blends direct HTTPS traffic with Google Apps Script relays.

The latest findings show an operator prioritizing resilience, modularity and network camouflage rather than reliance on a single C2 channel.

Earlier reporting documented its use of Microsoft Outlook Calendar events through Microsoft Graph, with DNS used as a recovery mechanism.

The newly identified implementation replaces that model with a multi-transport architecture that can shift communications between attacker-controlled infrastructure and Google’s legitimate cloud service.

At the centre of this development is GoogleService.dll, a 64-bit .NET 8 NativeAOT communication module.

The DLL is responsible for polling the C2 server, receiving tasking, relaying commands to the local framework broker and returning execution results.

Its configuration includes a direct C2 endpoint at api.studiotikva[.]com, an Apps Script deployment ID, an embedded authentication key and a hard-coded browser-like User-Agent string.

Rather than making a fixed decision about which transport to use, the malware queries DNS A records under m.studiotikva[.]com before each C2 transaction.

The final octet of the returned IPv4 address acts as a compact control signal. Depending on both the value and the module’s current error state, the malware selects either a direct HTTPS request, an Apps Script relay, or terminates the transaction.

This provides the operator with per-request traffic steering without modifying the malware or its on-disk configuration.

The DNS channel also functions as a recovery plane for the Google relay. CAV3RN verifies the configured Apps Script deployment ID by comparing the first four bytes of its MD5 digest against a DNS response.


DNS-based deployment-ID freshness check (Source : Kaspersky).
DNS-based deployment-ID freshness check (Source : Kaspersky).

If validation fails, it retrieves a replacement deployment ID in chunks through specially formatted .p subdomain queries.

The recovered value is written back to conf.json, allowing the operators to rotate their Google-hosted relay while retaining access to compromised systems.

When Google mode is selected, the malware communicates with an Apps Script endpoint using JSON-formatted POST requests.

Kaspersky Researchers said that, CAV3RN has evolved rapidly from a basic downloader, executor and uploader model into a controller-driven platform capable of loading, replacing and coordinating plugins at runtime.

The relay accepts an outer request, then proxies a GET or POST operation to the actor-controlled backend. To ordinary network monitoring systems, the traffic may resemble access to a common Google-hosted automation service.

A direct browser request returns a benign page titled “My App” stating that the application is running normally, creating an additional layer of operational cover.

Project CAV3RN Uses Google Apps

The direct HTTPS path connects to https://api.studiotikva[.]com/api/v1/update/check and requires a custom X-Client-Id header.

Responses are Base64-encoded and XOR-obfuscated with 0xAC before being handed to the framework’s local broker.

This broker, identified as rnp.dll, masquerades through exports associated with the RNP OpenPGP library.

Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID (Source : Kaspersky).

Internally, it scans for compatible DLLs, groups candidates by company name, loads the highest-version component and rescans the host directory every second for upgrades.

This design enables CAV3RN operators to introduce or replace modules without restarting the host process. The broker routes messages between loaded components and exposes inventory commands that can enumerate installed plugins and their paths.

Such local orchestration supports long-term espionage by making the framework adaptable after initial compromise.

The associated studiotikva[.]com domain appears to have been re-registered in May 2026 after expiration.

It hosted authoritative DNS services, the direct HTTPS backend and a locally credible “Studio Tikva” cover site. “Tikva” means “hope” in Hebrew, an apparent attempt to make the infrastructure appear contextually plausible.

For defenders, the most valuable signals are unusual DNS queries access to dynamically generated subdomains beneath studiotikva[.]com, DNS answers whose final octets determine application behavior, and POST activity to Google Apps Script endpoints followed by redirects to script.googleusercontent.com.

Security teams should also correlate these artifacts with anomalous X-Client-Id headers, .NET NativeAOT DLLs and suspicious component-loading behavior.

CAV3RN’s shift from Outlook Calendar to Google Apps Script underscores a clear operational pattern: legitimate cloud platforms are being repurposed as disposable, rotatable C2 infrastructure that is significantly harder to block using conventional domain reputation controls alone.

IOCs

MD5 hashFile name
904784c9943d019da332bea2cd03996fCommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0net.dll
2dcd4a8ac166404977cd3c48418a8cd9rnp.dll
981c7404d31b8ce35ec88a6b290f354dGoogleService.dll
34d50eec364d920b8b5d885c9bc98607texture.dll

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

[Live Webinar] Join Elastic & UnderDefense to learn how small security teams can unify AI visibility and agentic response into one operating model. -> Register Now



Source link