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.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildGoogleService.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.
