12 minhigh
Project CAV3RN continues: Google Apps Script as C2 relay and DNS-based C2 channel selection
Project CAV3RN is a modular espionage framework targeting Israeli entities. A newly identified communication module (GoogleService.dll) uses DNS A-record responses to select between direct HTTPS and a Google Apps Script relay for each C2 transaction. The DNS infrastructure also supports chunked retrieval and freshness validation of the Google Apps Script deployment ID, enabling operator rotation of the relay channel. A local DLL broker (rnp.dll) masquerades as the RNP OpenPGP library, coordinates modular components, and supports runtime upgrades via directory rescanning.
Sens:▲ 24h
Showing defanged values
- domainapi[.]studiotikva[.]comDirect HTTPS C2 endpoint subdomain. Hosts the /api/v1/update/check tasking endpoint and the /ac backend endpoint exposed during upstream timeout.
- domainns1[.]studiotikva[.]comAuthoritative nameserver for studiotikva.com, resolving to 144.172.115.17. Used for DNS-based C2 control plane.
- domainns2[.]studiotikva[.]comAuthoritative nameserver for studiotikva.com, resolving to 144.172.104.82. Used for DNS-based C2 control plane.
- domainstudiotikva[.]comPrimary C2 domain used for DNS-based channel selection, direct HTTPS C2, and authoritative DNS hosting. Registered May 12, 2026, redelegated May 19, 2026.
- filenameC:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdbEmbedded PDB path in rnp.dll revealing the attacker build environment and project structure (broker-cavern).
- filenameC:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdbEmbedded PDB path in GoogleService.dll revealing the attacker build environment and project structure (broker-cavern).
- filenameGoogleService.dllCommunication module DLL compiled with .NET 8 NativeAOT. Implements DNS-based C2 channel selection, Google Apps Script relay, and direct HTTPS communication.
- filenamernp.dllLocal broker DLL that masquerades as the RNP OpenPGP library. Scans for and loads DLL components, routes internal messages, and supports runtime upgrades.
- ip12[.]121[.]234[.]120DNS A-record response for valid .m.studiotikva.com queries. Fourth octet 120 (0x78) selects Direct HTTPS channel in error states or Google Apps Script in None state.
- ip12[.]19[.]29[.]30DNS A-record response treated as a rejection signal for malformed .m.studiotikva.com queries. Indicates C2 protocol rejection.
- ip144[.]172[.]104[.]82C2 hosting IP for studiotikva.com infrastructure. Hosted at RouterHosting LLC (AS 14956). Used for authoritative DNS and direct HTTPS C2.
- ip144[.]172[.]115[.]17C2 hosting IP for studiotikva.com infrastructure. Hosted at RouterHosting LLC (AS 14956). Used for authoritative DNS and direct HTTPS C2.
- md52dcd4a8ac166404977cd3c48418a8cd9MD5 hash of rnp.dll, the local inter-component broker that masquerades as the RNP OpenPGP library and coordinates modular DLL components.
- md534d50eec364d920b8b5d885c9bc98607MD5 hash of texture.dll, a CAV3RN framework component.
- md5904784c9943d019da332bea2cd03996fMD5 hash of CommunicationUxTheme.dll, a CAV3RN framework component.
- md5981c7404d31b8ce35ec88a6b290f354dMD5 hash of GoogleService.dll, the .NET 8 NativeAOT communication module that implements DNS-based C2 channel selection and Google Apps Script relay.
- md5f9156d42410c8a5429dec43329bd72e0MD5 hash of net.dll, a CAV3RN framework component.
- urlhxxps://api[.]studiotikva[.]com/acActor-controlled backend endpoint exposed during an upstream timeout from the Google Apps Script relay. Confirms the relay forwards to this server.
- urlhxxps://api[.]studiotikva[.]com/api/v1/update/checkDirect HTTPS C2 tasking endpoint. Expects X-Client-Id header. Returns XOR 0xAC + Base64 encoded task packets.
Detection / Hunteropenrouter
What Happened
A spying tool called CAV3RN continues to evolve and target organizations in Israel. The tool uses a clever trick where it sends DNS queries and reads the IP addresses in the responses to decide how to communicate with its controllers. It can route its communications through Google Apps Script (a legitimate Google service) to blend in with normal web traffic, making it harder to detect. The tool is built from multiple components that can be swapped or upgraded while running. Organizations should look for unusual DNS queries to specific domains, unexpected network connections to Google Apps Script endpoints, and suspicious DLL files on Windows systems.
Key Takeaways
- CAV3RN framework uses DNS A-record responses to dynamically select between direct HTTPS and Google Apps Script relay for C2 communication, encoding channel selection in the fourth octet of the returned IP
- Google Apps Script is abused as a C2 relay, with POST requests containing an authentication key and method field instructing the relay to proxy requests to an actor-controlled backend
- A local DLL broker (rnp.dll) masquerades as the RNP OpenPGP library, coordinates modular DLL components, supports runtime upgrades via directory rescanning, and routes internal messages
- The communication module (GoogleService.dll) is compiled with .NET 8 NativeAOT and uses XOR 0xAC with Base64 encoding for payload obfuscation
- DNS infrastructure supports chunked retrieval of a replacement Google Apps Script deployment ID via .p queries, with a 32-bit MD5 freshness check via .q queries
Affected Systems
- Windows 64-bit systems
- Targets located in Israel
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Deployment: CAV3RN framework deployed on target Windows system (initial access vector not described in this report)
- Broker Initialization: rnp.dll creates BROKER control structure, scans host directory for DLLs, and loads highest-version candidates exposing GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate exports
- C2 Channel Selection: GoogleService.dll sends DNS A-record query to <nonce><state>.<hex-client-id>.m.studiotikva.com and interprets the fourth octet of the response to select Google Apps Script or direct HTTPS
- C2 Communication: Module polls for tasks via selected channel; Google mode POSTs to script.google.com/macros/s/{ID}/exec with auth key and method fields; direct mode contacts api.studiotikva.com/api/v1/update/check with X-Client-Id header
- Task Execution: C2 task packets (type, cid, payload) are decoded from XOR 0xAC + Base64; broker-type tasks forwarded to rnp.dll for dispatch to loaded components
- Exfiltration: Component inventory and task results encoded with XOR 0xAC and Base64, then sent back through the selected C2 channel
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article does not include detection rules. Additional IOCs are stated to be available to Kaspersky Threat Intelligence Reporting customers only.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | DLL loading from unusual directories, file writes to conf.json, and the specific export names (GroupByCategory, CheckAvailability, IsPrimeNumber, OrderByDate) are visible to EDR. However, the masquerading of rnp.dll as a legitimate OpenPGP library and the use of .NET 8 NativeAOT compilation reduce traditional signature-based detection. |
| Network Visibility | Medium | DNS queries to studiotikva.com subdomains and direct HTTPS to api.studiotikva.com are visible. However, Google Apps Script relay traffic blends with legitimate Google services traffic. The DNS-based C2 encoding (using IP octets to carry data) may not be flagged by traditional DNS monitoring. |
| Detection Difficulty | Hard | The framework abuses legitimate Google infrastructure for C2 relay, uses DNS A-record encoding for control-plane signaling, masquerades DLLs as legitimate libraries, and employs XOR+Base64 payload obfuscation. Detecting the DNS control plane requires parsing IP octet values rather than standard domain or IP reputation matching. |
Required Log Sources
- DNS query and response logs (full A-record responses with all octets)
- HTTP/HTTPS proxy logs with request bodies and headers
- EDR process and DLL loading events
- EDR file write events
- Network flow logs for connections to Google Apps Script endpoints
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for DNS queries matching the pattern <short-alphanumeric>.<hex-string>.m.<domain> where the A-record response fourth octet is 120, 130, or 140, as this indicates DNS-based C2 channel selection. | DNS query logs and DNS response logs with full IP addresses | Command and Control | Low. The specific subdomain pattern and IP-octet encoding scheme is unlikely to appear in legitimate DNS traffic. |
| Consider hunting for POST requests to script.google.com/macros/s/ endpoints where the JSON body contains fields named k, m, h, b, ct, and r, as this indicates the Google Apps Script C2 relay protocol. | HTTP/HTTPS proxy logs with request body inspection or TLS inspection | Command and Control | Medium. Legitimate applications may use Google Apps Script, but the specific JSON field structure (k, m, h, b, ct, r) is distinctive. |
| Consider hunting for DLL files that export the functions GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate simultaneously, as this is the CAV3RN broker component interface. | EDR DLL load events with export table inspection, or file scanning tools that enumerate PE exports | Execution | Low. This combination of export names is unusual and not associated with legitimate software. |
| Consider hunting for HTTP requests containing an X-Client-Id header sent to api.studiotikva.com or other newly registered domains, as this is the direct HTTPS C2 authentication mechanism. | HTTP/HTTPS proxy logs with custom header inspection | Command and Control | Low. X-Client-Id is a non-standard header for typical web traffic. |
| Consider hunting for DNS queries to .p subdomains of a domain where A-record responses are used to reconstruct a multi-byte string in chunks, as this indicates the CAV3RN deployment ID recovery mechanism. | DNS query and response logs with correlation across sequential queries | Command and Control | Low. Sequential DNS queries with offset labels and data encoded in IP octets are not a normal DNS pattern. |
Control Gaps
- Network-based detection may not flag Google Apps Script traffic as malicious since it blends with legitimate Google services
- DNS monitoring that only checks domain reputation or blocks known-bad domains may miss the IP-octet encoding used for C2 control-plane signaling
- Signature-based AV may not detect .NET 8 NativeAOT compiled binaries or DLLs masquerading as legitimate libraries
- Proxy logs without request body inspection will not capture the JSON relay protocol fields used in Google Apps Script POST requests
Key Behavioral Indicators
- DNS queries matching pattern <random>.<hex-client-id>.m.studiotikva.com, *.q.studiotikva.com, or *.p.studiotikva.com
- POST requests to script.google.com/macros/s/ with JSON body containing fields k, m, h, b, ct, r
- HTTP requests with X-Client-Id header to api.studiotikva.com
- User-Agent string: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 (anachronistic Chrome 26 UA)
- DLL files exporting GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate
- PDB paths containing broker-cavern project directory structure
- rnp.dll with rnp_* exports where rnp_backend_string initiates broker functionality instead of legitimate RNP OpenPGP library behavior
- XOR 0xAC followed by Base64 encoding of JSON payloads in HTTP response bodies
- conf.json file in process working directory containing fields to, ad, ho, gi, de, mi, ma, ri, ga, gu, ua, mcc, mtc
False Positive Assessment
Low. The DNS subdomain patterns, specific DLL export names, JSON relay protocol fields, and anachronistic User-Agent string are distinctive and unlikely to appear in legitimate activity. The primary false positive risk is from legitimate Google Apps Script usage, but the specific JSON field structure (k, m, h, b, ct, r) differentiates C2 relay traffic from normal usage.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider blocking DNS resolution for studiotikva.com and its subdomains (api., ns1., ns2.) at recursive resolvers if consistent with your DNS filtering policies.
- Consider blocking network connections to 144.172.115.17 and 144.172.104.82 if your firewall or proxy supports IP-based blocking.
- Consider searching EDR and endpoint telemetry for the five MD5 hashes listed in the article and for DLL files exporting GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.
- If applicable, consider inspecting proxy logs for POST requests to script.google.com/macros/s/ containing JSON with fields k, m, h, b, ct, r to identify potential C2 relay activity.
Infrastructure Hardening
- Evaluate whether your DNS monitoring can detect data exfiltration or C2 signaling via IP-octet encoding in A-record responses, as traditional DNS monitoring may only check domain reputation.
- Consider implementing TLS inspection for traffic to script.google.com if your organization's legal and policy framework permits it, to detect the Apps Script relay protocol.
- If supported by your proxy or next-generation firewall, consider alerting on HTTP requests containing the non-standard X-Client-Id header to external domains.
User Protection
- Consider deploying endpoint detection rules for DLLs loaded from user-writable directories that export the specific function names GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.
- Evaluate whether your EDR can detect .NET 8 NativeAOT compiled binaries loaded as DLLs, as this compilation method may bypass traditional .NET assembly loading telemetry.
- Consider monitoring for the creation of conf.json files in process working directories with the specific field structure described in the article.
Security Awareness
- Consider incorporating awareness of legitimate cloud service abuse (Google Apps Script, Outlook) into existing security training programs, emphasizing that legitimate platforms can be used as C2 relays.
- If applicable to your organization, consider reminding personnel that newly registered or recently expired domains may be acquired by threat actors and used for C2 infrastructure.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping8 techniques
Tactic
Execution
Additional IOCs
- Ips:
12[.]121[.]234[.]120- DNS A-record response for valid .m.studiotikva.com queries. Fourth octet 120 (0x78) selects Direct HTTPS channel in error states or Google Apps Script in None state.12[.]19[.]29[.]30- DNS A-record response treated as a rejection signal for malformed .m.studiotikva.com queries. Indicates C2 protocol rejection.247[.]188[.]216[.]122- DNS A-record response for .q.studiotikva.com freshness check query. Contains raw bytes f7 bc d8 7a matching the first four MD5 bytes of the recovered Google Apps Script deployment ID.
- Domains:
ns1[.]studiotikva[.]com- Authoritative nameserver for studiotikva.com, resolving to 144.172.115.17. Used for DNS-based C2 control plane.ns2[.]studiotikva[.]com- Authoritative nameserver for studiotikva.com, resolving to 144.172.104.82. Used for DNS-based C2 control plane.
- File Hashes:
904784c9943d019da332bea2cd03996f(MD5) - MD5 hash of CommunicationUxTheme.dll, a CAV3RN framework component.f9156d42410c8a5429dec43329bd72e0(MD5) - MD5 hash of net.dll, a CAV3RN framework component.34d50eec364d920b8b5d885c9bc98607(MD5) - MD5 hash of texture.dll, a CAV3RN framework component.
- File Paths:
C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb- Embedded PDB path in GoogleService.dll revealing the attacker build environment and project structure (broker-cavern).C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb- Embedded PDB path in rnp.dll revealing the attacker build environment and project structure (broker-cavern).
- Other:
s3criitC0d3/8-)B-,)- Static authentication key used in Google Apps Script relay POST requests (k field) and observed as X-Client-Id header value in direct HTTPS C2 requests.33A4BA78-E286-4FF2-85EC-7365265F3D93- Fixed identifier used in initialization handshake between GoogleService.dll and the local broker. Module sends type-0 frame to this identifier; broker returns Err1:: with the identifier to confirm communication.AKfycby46v0DPSEKWYa****dvQ- Partially redacted Google Apps Script deployment ID recovered via DNS .p queries. 74 characters in length. Inserted into https://script.google.com/macros/s/\{deployment-ID\}/exec for C2 relay.