Project CAV3RN, an espionage framework targeting entities in Israel, has continued to evolve its command-and-control (C2) capabilities, now incorporating a sophisticated multi-transport communication module. This module, identified as `GoogleService.dll`, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT, and it leverages DNS A-record responses to dynamically select between direct HTTPS communication and a Google Apps Script relay for each C2 transaction.
The `GoogleService.dll` module, whose PDB path was found to be `C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb`, exports functions such as `GroupByCategory`, `CheckAvailability`, `IsPrimeNumber`, and `OrderByDate`. Upon initialization, the module registers a callback with its local broker and begins a `CheckAvailability` routine. After three seconds, it sends a type-0 frame to a fixed identifier, `33A4BA78-E286-4FF2-85EC-7365265F3D93`, expecting a specific error response (`Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93`) to learn the broker's name before commencing C2 operations.
C2 packets processed by the framework include fields for type, client ID (`cid`), and payload. Packets of type `icmgdd` are handled internally by the communication module, while `broker` type packets are forwarded to the local broker. Command payloads use `_;;_` to separate commands from arguments and `_,_` for individual arguments. At startup, the module sends an `s_version_;;_` command, which triggers an inventory of DLLs in `AppContext.BaseDirectory`, collecting their company names and versions, along with the communication module's and local broker's names. This inventory is then serialized as JSON, XORed with `0xAC`, Base64-encoded, and sent as the initial C2 report.
The module supports five internal commands: `s_version` (returns DLL inventory), `s_config` (returns or replaces configuration in memory), `s_enLog` (enables debug logging), `s_deLog` (disables logging, sets level to Fatal), and `s_write` (Base64-decodes and GZip-decompresses data to a specified file path). The module reads its configuration from `conf.json` in the current working directory. If this file is absent, it generates a seven-character client identifier and writes embedded default settings to disk.
The configuration includes parameters such as a client ID, a direct C2 URL (`https://api.studiotikva.com/api/v1/update/check`), a DNS domain (`studiotikva.com`), a Google Apps Script deployment ID (redacted in reports), debug logging settings, poll delays, a base DNS recovery delay, an Apps Script relay authentication key (`s3criitC0d3/8-)B-,)`), the Google Apps Script URL format (`https://script.google.com/macros/s/{0}/exec`), and a user agent string. While the `s_config` command can update these settings in memory, only a recovered Apps Script deployment ID is written back to `conf.json`.
Before each command poll or result transmission, the module performs a DNS A-record query to determine the C2 channel. The query format is `[random nonce][error state].[hex-encoded client ID].m.studiotikva.com`. The first label combines a three- or four-character uppercase alphanumeric nonce with an error state (0 for None, 1 for GIDFailed, 2 for GoogleFailed, 3 for DirectFailed). Each new transaction begins in state 0. A specific response of `12.19.29[.]30` indicates a rejection. Other responses are interpreted based on their fourth octet, which dictates whether to use Google Apps Script or direct HTTPS, or to close the transaction. For instance, a fourth octet of `120 (0x78)` selects Google Apps Script if the error state is None, but Direct HTTPS if the state is GIDFailed, GoogleFailed, or DirectFailed. During analysis, valid `.m` queries returned `12.121.234[.]120`, while malformed queries returned `12.19.29[.]30`.
When the Google Apps Script mode is selected, the module verifies the freshness of its stored deployment ID by comparing the first four bytes of its MD5 digest with an A record returned by a query to `[random5].[hex-ID].q.studiotikva[.]com`. A mismatch triggers a retrieval process for a new deployment ID via `.p` queries to `[random5].[hex-ID].p.studiotikva[.]com`. The DNS recovery mechanism for the Google Apps Script deployment ID involves an initial response providing a one-byte length and the first three ID characters, followed by subsequent responses each contributing four bytes. An observed example showed an initial response of `74.65.75.102` (representing 4A 41 4B 66), indicating a length of 74 characters and the initial characters "AKf". One initial response and 18 continuation responses were observed to reconstruct a 74-character deployment ID, partially disclosed as `AKfycby46v0DPSEKWYa****dvQ`. This DNS infrastructure allows the operators to validate and rotate the Google Apps Script relay deployment ID.
The framework also includes a local broker component responsible for discovering and loading DLL components, routing messages between them, and facilitating runtime upgrades. This modular design and dynamic C2 channel selection highlight the advanced capabilities of the Project CAV3RN espionage framework.
