The exact response 12.19.29[.]30 is treated as a rejection — a small, specific marker in DNS traffic that in Project CAV3RN determines whether an infected host will talk directly to an actor-controlled HTTPS endpoint or route through a Google Apps Script relay.
DNS-based channel selection: a binary switch hidden in A records
The CAV3RN framework uses DNS A-record responses as a control plane to choose per-transaction command-and-control (C2) transport. For each transaction the malware issues a query of the form <random nonce><error state>.<hex-ID>.m.studiotikva.com. The first label mixes a three- or four-character uppercase alphanumeric nonce with an error state encoded as 0 (None), 1 (GIDFailed), 2 (GoogleFailed), or 3 (DirectFailed). The malware treats one exact IP — 12.19.29[.]30 — as a rejection. Otherwise the fourth octet of the A record tells the client which channel to use: when it is 120 (0x78) or 130 (0x82) the client will select Direct HTTPS in many state combinations; when it is 120 in certain states, Google Apps Script may be used; 140 (0x8C) signals an exception. All other final-octet values cause the module to choose the Google Apps Script relay. During analysis, observed valid .m queries returned 12.121.234[.]120 while malformed queries returned the rejection address 12.19.29[.]30.
Google Apps Script relay and DNS-driven deployment-ID recovery
When DNS directs the module to use Google mode, the communication DLL (GoogleService.dll) inserts a deployment ID into the Apps Script URL pattern https://script.google.com/macros/s/{{deployment-ID}}/exec and issues an outer POST whose body tells the relay to perform a GET upstream. The Apps Script relay responds with a 302 followed by a 200 that contains a JSON envelope; the module decodes the returned "b" field, double-decodes and XORs with 0xAC to interpret tasking. During a timeout the relay exposed the upstream api endpoint at https://api.studiotikva[.]com/ac, confirming the Apps Script deployment forwards to an actor-controlled backend.
The framework also implements a DNS-based freshness check and recovery for the deployment ID. It computes the MD5 of the stored deployment ID and compares the first four bytes to the A record returned by a <random5>.<hex-ID>.q.studiotikva[.]com query. If those bytes do not match, the malware issues a sequence of chunked .p queries (offset-0 provides a length byte plus three characters; subsequent offsets return four-byte chunks) to reconstruct a replacement deployment ID. Analysts recovered a 74-character deployment ID via one initial response and 18 continuation responses; the corresponding .q response contained bytes matching the first four MD5 bytes of the recovered ID, demonstrating a 32-bit freshness check.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageGoogleService.dll: how the communication module reports and accepts commands
GoogleService.dll is a 64-bit module compiled with Microsoft .NET 8 NativeAOT. Its startup behavior includes registering with the host broker, sending an initial type-0 frame to a fixed identifier (33A4BA78-E286-4FF2-85EC-7365265F3D93) and then launching a C2 worker. C2 packets use fields named type, cid, and payload; the module itself handles packets of type icmgdd and forwards others (including broker tasks) to the local broker. On initialization the worker sends {"type":"icmgdd","cid":0,"payload":"s_version_;;_"}, which causes s_version to enumerate DLLs in the host directory, collect company names and versions, add the communication module and broker name, JSON-serialize the inventory, XOR it with 0xAC, Base64-encode it, and send it as the initial report.
The module reads conf.json from the process working directory or generates a seven-character client ID and writes embedded defaults if the file is missing. Defaults include a direct C2 URL (https://api.studiotikva.com/api/v1/update/check), host name (studiotikva.com), a stored Apps Script deployment ID placeholder, an Apps Script relay key, and a relay URL template. s_config can replace settings in memory; DNS-driven recovered deployment IDs are written back to conf.json. The module also exposes five internal commands: s_version, s_config, s_enLog, s_deLog, and s_write (which decodes, decompresses, and writes arbitrary data to disk).
rnp.dll: the local broker that orchestrates components
The inter-component broker, rnp.dll, is a 64-bit Visual C++ DLL whose exported rnp_backend_string starts the broker. It builds a BROKER control structure, initializes a dispatcher, and continuously scans the host directory for DLLs. Components are grouped by CompanyName; the broker loads the highest-version candidate from each group only if it exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. The scanner rescans every second, permitting runtime upgrades by placing a higher-version DLL under a new path (replacing a file in-place is not detected).
Loaded components exchange messages via the broker; destinations are resolved and callbacks invoked. Unknown destinations return Err1::, and unavailable components return Err2::. The broker supports commands that list loaded component names/versions, discovered DLL paths, and each loaded component’s path, name, and version. When asked to unload or replace a component the broker calls its IsPrimeNumber export and waits for worker threads to stop before unloading the DLL.
Infrastructure, domain history, and operational assessment
The domain studiotikva[.]com and related names (api.studiotikva[.]com, ns1.studiotikva[.]com, ns2.studiotikva[.]com) resolved to 144.172.115[.]17 and 144.172.104[.]82 and used authoritative DNS plus a direct HTTPS C2 endpoint. Public records show studiotikva[.]com was first registered in February 2024, expired in February 2026, and was re-registered on May 12, 2026 before redelegation on May 19. Wayback captures showed a Wix disconnected-domain page at earlier times; after re-registration the domain hosted a generic "Studio Tikva" site. File hashes and additional IoCs are listed in the report; Kaspersky notes that more Indicators are available to customers of its Threat Intelligence Reporting service and offers intelreports@kaspersky.com for enquiries.
Project CAV3RN continues to evolve, blending native Windows components (GoogleService.dll, rnp.dll and others) with DNS control-plane signaling and application-layer relays. The report states this modular, multi-transport architecture allows operators to rotate channels and recover relay deployment IDs via DNS, complicating detection and enforcement. Kaspersky concludes it will continue tracking the framework and publishing updates.
