CAV3RN Uses Google Apps Script as C2 Relay to Hide Malware Traffic Behind Google Infrastructure

CAV3RN is a modular espionage framework that is becoming harder to see on a network.

Its newest communication component hides remote-control traffic behind Google Apps Script, a service many organizations use legitimately.

That design can make a harmful connection look less unusual at first glance. The framework has been used against targets in Israel and has continued to gain new components.

Researchers have not described the initial infection route in this update, but once installed, its modules can exchange messages, collect software details, receive tasks, and update parts of the toolkit without restarting the host.

Analysts at Securelist identified the new communication and control functions while tracking the cluster in early August.

Kaspersky said in a report shared with Cyber Security News (CSN) that CAV3RN can choose a direct web connection or a Google Apps Script relay for each exchange, using DNS answers to make that decision.

The result is a more resilient channel for espionage operations. Blocking one route may not end the operator’s access because the malware can switch methods, while its use of a familiar cloud service may complicate review of suspicious web traffic.

Similar abuse appears in cloud services C2 servers, where trusted platforms can shield malicious infrastructure. It raises the cost of detection where security tools broadly allow common cloud and DNS traffic.

CAV3RN Uses Google Apps Script as C2 Relay

The component is a 64-bit Windows DLL that starts by reporting a list of nearby DLLs and their versions.

It then regularly asks the DNS system which communication route to use. That lightweight check turns ordinary-looking DNS lookups into a control signal for the malware.

A DNS A-record response directs the module toward either direct HTTPS or Google Apps Script, depending on its last number and the connection’s current error state.

If the Google route fails, the next lookup can steer it to direct HTTPS. This fallback model resembles DNS traffic hidden channel, another technique that makes routine name resolution useful to attackers.

When Google mode is selected, CAV3RN sends a POST request to an Apps Script deployment that acts as a relay.

The relay receives an instruction to fetch content from an upstream server, then returns the result to the infected system. A normal browser request instead shows a harmless page stating that the application is running normally.

The malware can also check whether its Google deployment ID is current. It compares part of a cryptographic digest against a DNS response and, if it does not match, retrieves a replacement ID in small DNS response chunks.

This lets operators rotate the Google relay without replacing the malware itself.

Modular Broker Adds Staying Power

CAV3RN also uses a local broker that finds compatible DLL components, loads the newest version from each group, and passes messages between them.

It scans the host directory every second, allowing operators to add an upgraded module under a new path while the framework remains active.

That architecture gives the operators flexibility beyond a single backdoor. The broker can return a component inventory, while the communication module can pass received tasks to it.

Direct HTTPS traffic goes to an actor-controlled backend and requires a custom client header, adding another detail defenders can use when investigating unusual traffic.

Security teams should review DNS activity for unusual randomized subdomains under the listed domain, inspect unexpected connections to the identified web endpoint, and hunt for the named DLLs.

They should also avoid treating Google-hosted traffic as automatically safe, as Azure Functions malware campaign shows how legitimate hosted services can be repurposed for covert control.

Network monitoring should correlate DNS lookups, redirect chains, and process activity rather than relying on one indicator alone.

Organizations that find these signs should isolate the affected device, preserve relevant logs, and check for additional loaded DLLs.

The framework’s fast development and route-switching design mean early investigation matters. Longer DNS telemetry can also expose the framework’s repeating selection patterns.

Indicators of compromise (IoCs):-

Type	Indicator	Description
File name	UxTheme.dll	CAV3RN-associated file listed in the source
File name	net.dll	CAV3RN-associated file listed in the source
File name	rnp.dll	CAV3RN local broker component
File name	GoogleService.dll	CAV3RN communication component
File name	texture.dll	CAV3RN-associated file listed in the source
File hash	904784c9943d019da332bea2cd03996f	Hash listed for a CAV3RN-associated file
File hash	f9156d42410c8a5429dec43329bd72e02	Hash listed for a CAV3RN-associated file
File hash	dcd4a8ac166404977cd3c48418a8cd998	Hash listed for a CAV3RN-associated file
File hash	1c7404d31b8ce35ec88a6b290f354d	Hash listed for a CAV3RN-associated file
File hash	34d50eec364d920b8b5d885c9bc98607	Hash listed for a CAV3RN-associated file
Domain	studiotikva[.]com	CAV3RN DNS control infrastructure
Domain	api.studiotikva[.]com	Direct HTTPS C2 backend
Domain	ns1.studiotikva[.]com	Authoritative DNS infrastructure
Domain	ns2.studiotikva[.]com	Authoritative DNS infrastructure
IP address	144.172.115[.]17	Infrastructure IP address
IP address	144.172.104[.]82	Infrastructure IP address
URL	hxxps://api.studiotikva[.]com/api/v1/update/check	Direct HTTPS C2 endpoint
URL	hxxps://api.studiotikva[.]com/ac	Backend endpoint exposed during upstream timeout

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.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world