Cavern picks its C2 channel via a DNS query and hides inside Google Apps Script and Microsoft 365 calendars

Early July 2026. Check Point Research publicly documents Cavern (also written Cav3rn), a command-and-control framework used in attacks against Israeli entities. December 2025. Kaspersky begins tracking the same activity cluster. August 17, 2026. The vendor publishes an analysis revealing a previously unreported module: the malware issues a DNS query for every transaction to choose between a direct HTTPS channel and a Google Apps Script relay.

The finding matters for a precise reason. A C2 that moves over DNS and gets hosted by Google and Microsoft legitimate services leaves no dedicated infrastructure to block. Indicator blocklists — domains, IP addresses — lose much of their grip.

A framework that no longer looks like a C2

Cavern is described as a set of moving parts: an Agent and an assortment of modules that work together for post-exploitation, while minimizing forensic visibility and keeping persistent access.

The documented modules cover file operations, SQL database enumeration, Active Directory reconnaissance, LDAP brute-force, network reconnaissance, and SOCKS5 proxy plus WebSocket tunneling. In short, a complete espionage toolkit. Kaspersky links it to Cavern Manticore, a group affiliated with Iran’s Ministry of Intelligence (MOIS) that overlaps with MuddyWater and with the OilRig subgroup known as Lyceum.

What is changing is the architecture. Kaspersky dates the shift to a modular, plugin-based design to around late April 2026, and ties it to OilRig (APT34) with low confidence. There is no direct code reuse or infrastructure overlap, but there are matching signs: the use of Microsoft-hosted services for C2, a fallback mechanism to obtain replacement OAuth tokens, and the use of compromised infrastructure belonging to entities in targeted regions.

DNS as the switch point

The core of the new publication comes down to one module: GoogleService.dll. It reads a configuration file from disk — conf.json — then performs a DNS A-record query to decide, for each transaction, whether to go through a direct HTTPS channel or a Google Apps Script relay.

The technical detail matters. In Google mode, the module sends its requests to the Apps Script deployment, which forwards them to the attacker-controlled backend. In direct HTTPS mode, it contacts the configured address without the relay. And the same DNS infrastructure can validate and replace the relay deployment ID — letting the operator rotate the Google channel at will.

This is exactly the scheme that neutralizes domain-blocking defenses. The primary domain tied to the activity, studiotikva[.]com, was registered in February 2024, expired in February 2026, and was re-registered three months later. During the gaps, the Google relay keeps doing the work, and the operator only has to update a DNS record to change the fallback address.

A second component, rnp.dll, acts as an inter-component broker: it discovers and loads DLL components, routes messages between modules, and supports runtime upgrades. The whole thing forms a platform its author can extend without redeploying everything.

HOLLOWGRAPH, or the calendar as a dead-drop

Two back-to-back reports from Group-IB and Kaspersky document a separate module, HOLLOWGRAPH, that abuses the Microsoft Graph API to turn the Microsoft 365 calendar of a compromised mailbox into a two-way dead-drop.

The principle is simple. The implant treats the victim’s calendar as a drop point: operators plant tasking as events, and the implant exfiltrates stolen files by creating its own events with encrypted attachments. To avoid catching the mailbox owner’s attention, every event is dated far into the future — May 13, 2050 — with the payload attached as a file.

In parallel, the malware uses DNS tunneling to refresh the Microsoft Entra ID (formerly Azure AD) credentials used to authenticate to the Graph API, then writes the new values to a text file on disk. HOLLOWGRAPH, compiled in .NET NativeAOT, was first detected in the wild on June 7, 2026.

The lesson is the same as for GoogleService.dll: the command traffic looks disturbingly like a legitimate user checking their calendar.

This convergence is not an isolated case. The same DarkAtlas publication documents the return of APT42 with TAMECAT, a modular surveillance framework deployed via LNK files disguised as PDF in spear-phishing campaigns targeting the nuclear energy sector, observed as recently as May 2026. The Iranian group is also accelerating its operations with generative AI: building specialized tooling, translating, researching exploitation techniques, and identifying official addresses. The overall picture is consistent: Iranian state actors are industrializing the abuse of legitimate services and automation, further eroding detection built on indicators alone.

What this changes for network detection

The point Kaspersky makes explicitly deserves quoting: by abusing legitimate services — previously Outlook calendar events, now Google Apps Script — the framework blends its C2 traffic with normal enterprise activity, which complicates network-based detection.

For a CISO or a SOC, this moves the goalposts. Indicators of compromise (IoC) remain useful for correlation once an attack is documented, but they arrive after the fact. What you have to watch upstream are behaviors:

• unusual DNS queries toward low-reputation domains, or A-record answers that drive a channel choice;
• outbound HTTPS traffic toward Google Apps Script deployments or non-standard Microsoft Graph endpoints;
• calendar events created in bulk, dated far in the future, or carrying unusual attachments;
• unknown DLLs and configuration files (conf.json) appearing on workstations.

The technical answer is less a new tool than a posture: log and correlate the DNS resolved internally, and treat abuse of legitimate cloud services as a first-class signal rather than background noise.

Concretely, this means reviewing your DNS egress policy and your Google Workspace and Microsoft 365 audit logs with the same skepticism you apply to raw network flows. A calendar event dated in 2050, an Apps Script deployment nobody on the team remembers creating, a workstation resolving a domain that then pivots to a cloud relay, or a DLL and its conf.json appearing without a matching software update — each is higher-signal than a blocklist hit, because it describes what the attacker is doing right now rather than what they once did. The IoC tells you an attack was documented; the behavior tells you one is under way.

Verdict

If you run a SOC that still leans on IoC blocklists, the Cavern case is an argument for rebalancing your budget toward behavioral detection: anomalous DNS queries, tunneling over legitimate services, suspicious calendar events. The framework changes channel and host faster than your lists update.

If you are in an organization targeted by state actors — government, defense, energy, telecom — treat abuse of Microsoft 365 and Google Workspace as a plausible C2 vector, and review your DNS logs and your deployed Apps Script applications.

The bottom line: state-grade C2s no longer need dedicated infrastructure. They ride the channels your security policy allows by default. Detection has to follow the same path — from the domain to the behavior.

References

• The Hacker News — Cavern C2 Uses DNS and Google Apps Script to Blend Into Legitimate Traffic, August 17, 2026
• Kaspersky Securelist — Project Cav3rn continues: Google Apps Script relay and modular upgrades, accessed August 18, 2026
• Group-IB — HOLLOWGRAPH abuses Microsoft 365 calendars as a C2 dead-drop, accessed August 18, 2026
• Kaspersky Securelist — Project Cav3rn: cyberespionage framework using Outlook and DNS, accessed August 18, 2026