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.
CAV3RN DNS control-plane response (Source – Securelist)
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.
DNS-based deployment-ID freshness check (Source – Securelist)
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.
DNS recovery of the Google Apps Script (Source – Securelist)
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):-
TypeIndicatorDescriptionFile nameUxTheme.dllCAV3RN-associated file listed in the sourceFile namenet.dllCAV3RN-associated file listed in the sourceFile namernp.dllCAV3RN local broker componentFile nameGoogleService.dllCAV3RN communication componentFile nametexture.dllCAV3RN-associated file listed in the sourceFile hash904784c9943d019da332bea2cd03996fHash listed for a CAV3RN-associated fileFile hashf9156d42410c8a5429dec43329bd72e02Hash listed for a CAV3RN-associated fileFile hashdcd4a8ac166404977cd3c48418a8cd998Hash listed for a CAV3RN-associated fileFile hash1c7404d31b8ce35ec88a6b290f354dHash listed for a CAV3RN-associated fileFile hash34d50eec364d920b8b5d885c9bc98607Hash listed for a CAV3RN-associated fileDomainstudiotikva[.]comCAV3RN DNS control infrastructureDomainapi.studiotikva[.]comDirect HTTPS C2 backendDomainns1.studiotikva[.]comAuthoritative DNS infrastructureDomainns2.studiotikva[.]comAuthoritative DNS infrastructureIP address144.172.115[.]17Infrastructure IP addressIP address144.172.104[.]82Infrastructure IP addressURLhxxps://api.studiotikva[.]com/api/v1/update/checkDirect HTTPS C2 endpointURLhxxps://api.studiotikva[.]com/acBackend 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
The post CAV3RN Uses Google Apps Script as C2 Relay to Hide Malware Traffic Behind Google Infrastructure appeared first on Cyber Security News.
