CAV3RN malware uses Google Apps Script to hide C2 traffic

Key Takeaways

• CAV3RN, a modular espionage framework, has adopted Google Apps Script to conceal its command-and-control (C2) communications.
• This new technique allows the malware to blend malicious traffic with legitimate Google cloud services, complicating detection.
• The framework employs a dynamic DNS-based mechanism to switch between direct HTTPS and Google Apps Script C2 channels, enhancing its resilience.
• Targets in Israel have been impacted by CAV3RN, which continuously gains new components and capabilities.
• Defenders must implement advanced network monitoring, correlating DNS activity and process behavior, and avoid automatically whitelisting Google-hosted traffic.

CAV3RN Malware Leverages Google Apps Script for Covert C2 Operations

The CAV3RN espionage framework has evolved, now employing Google Apps Script as a sophisticated method to obscure its command-and-control (C2) traffic. This tactical shift allows the malware to camouflage its malicious communications within legitimate Google cloud infrastructure, presenting a significant challenge for network defenders attempting to distinguish between benign and malicious activity.

First identified in early August by Securelist analysts, this updated communication module represents a strategic enhancement to CAV3RN’s operational stealth. The framework, which has been observed targeting entities in Israel, is designed with a modular architecture that supports dynamic updates and task execution without requiring a host system reboot. While the initial compromise vector for this iteration of CAV3RN has not been publicly detailed, once established, its various modules can facilitate message exchange, gather system information, and receive new instructions.

Evasive Communication Channels

The core of CAV3RN’s new evasion strategy lies in its ability to dynamically select communication channels. Kaspersky said in a report that CAV3RN can opt for either a direct web connection or a Google Apps Script relay for each C2 exchange. This decision-making process is guided by DNS responses, allowing the malware to adapt its communication route based on network conditions and operational requirements. This dual-channel approach significantly boosts the framework’s resilience; should one communication path be blocked, the malware can seamlessly pivot to another, maintaining persistent access for its operators.

The use of widely trusted cloud services like Google Apps Script complicates detection efforts. Security tools often broadly permit traffic to and from common cloud platforms, making it difficult to flag suspicious activity without deep packet inspection and behavioral analysis. This method elevates the cost and complexity of threat detection, as malicious traffic effectively hides in plain sight behind legitimate infrastructure.

Google Apps Script as a C2 Relay

The new communication component of CAV3RN is implemented as a 64-bit Windows DLL. Upon execution, it first enumerates and reports local DLLs and their versions. Subsequently, it performs regular DNS queries to determine its C2 communication method. This seemingly innocuous DNS activity serves as a covert control signal for the malware.

Specifically, a DNS A-record response dictates whether the module should use direct HTTPS or Google Apps Script. This decision is influenced by the last octet of the IP address in the DNS response and the current error state of the connection. Should the Google Apps Script route fail, subsequent DNS lookups can redirect the malware to a direct HTTPS connection, illustrating a robust fallback mechanism. This technique mirrors other DNS-based covert channels, where routine name resolution is weaponized by attackers.

When the Google Apps Script mode is active, CAV3RN dispatches a POST request to a designated Apps Script deployment, which functions as a relay. This relay fetches content from an upstream C2 server and then transmits the response back to the infected system. For a standard browser request, the same Apps Script deployment would simply display a benign message confirming the application’s normal operation, further masking the malicious activity.

The malware also includes a mechanism to verify the currency of its Google deployment ID. It cross-references a portion of a cryptographic digest against a DNS response. If a mismatch is detected, the malware retrieves a new deployment ID through fragmented DNS responses. This capability allows operators to rotate their Google Apps Script relays without needing to redeploy the malware itself, enhancing operational agility and evasion.

Modular Design Enhances Persistence

CAV3RN’s architecture incorporates a local broker that manages its various DLL components. This broker identifies compatible DLLs, loads the most recent version of each, and facilitates inter-component communication. By continuously scanning the host directory every second, the framework enables operators to introduce upgraded modules via new file paths while the malware remains active and undetected. This modularity offers significant operational flexibility, moving beyond the constraints of a single, static backdoor.

The broker can provide an inventory of installed components, and the communication module relays received tasks to it. Direct HTTPS traffic from the malware targets an actor-controlled backend and requires a specific custom client header. This header serves as a potential indicator that defenders can leverage during investigations of unusual network traffic.

What You Should Do

• Enhanced DNS Monitoring: Scrutinize DNS activity for anomalous randomized subdomains associated with the identified CAV3RN control infrastructure (e.g., studiotikva[.]com). Implement advanced DNS logging and analytics to detect unusual query patterns or responses.
• Inspect Google-Hosted Traffic: Do not automatically trust traffic destined for Google-hosted services. Implement deeper inspection and behavioral analysis for connections to Google Apps Script and other cloud services to identify malicious relays.
• Correlate Network and Process Data: Move beyond single indicators. Correlate DNS lookups, redirect chains, and process activity on endpoints to build a comprehensive picture of potential compromise. Longer-term DNS telemetry can help identify recurring patterns indicative of CAV3RN’s route-switching behavior.
• Hunt for Known IoCs: Actively scan for the listed DLLs (e.g., UxTheme.dll, net.dll, rnp.dll, GoogleService.dll, texture.dll) and their associated file hashes. Monitor for connections to the identified domains (studiotikva[.]com, api.studiotikva[.]com, ns1.studiotikva[.]com, ns2.studiotikva[.]com) and IP addresses (144.172.115[.]17, 144.172.104[.]82), as well as the specified URLs (hxxps://api.studiotikva[.]com/api/v1/update/check, hxxps://api.studiotikva[.]com/ac).
• Incident Response Protocol: Upon detecting signs of CAV3RN, immediately isolate affected devices, preserve all relevant logs for forensic analysis, and conduct a thorough investigation for additional loaded DLLs or persistent mechanisms. The rapid development and adaptive nature of this framework necessitate swift response.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.