Cybersecurity researchers have detailed a new step in the evolution of the Cavern (also known as Cav3rn) command-and-control framework. Widely associated with Iranian nation-state activity targeting organizations in Israel, Cavern’s latest communication changes make its traffic harder to spot by mixing malicious operations with services that appear ordinary on the internet.
Central to these findings is how DNS and Google Apps Script are combined to decide, transaction by transaction, whether the malware should connect directly via HTTPS or route through a Google Apps Script relay. That dynamic selection is supported by DNS A-record responses, giving the operator flexibility while reducing obvious indicators in network monitoring.
Why Cavern’s communication methods are changing
Cavern was publicly documented earlier in 2026, and it is built as a modular framework. In practice, that means an initial agent and multiple add-on modules cooperate to provide post-exploitation capabilities while limiting what defenders can easily observe. The goal is persistence and mission-specific functionality—without leaving a clear forensic trail.
Earlier components of the ecosystem have been linked to activities such as file operations, database discovery, Active Directory reconnaissance, LDAP brute-forcing, network reconnaissance, and traffic tunneling using SOCKS5 and WebSocket techniques. Researchers also noted relationships between Cavern-associated activity and other Iran-linked groups, including overlaps reported with families attributed to the same broader threat ecosystem.
DNS A-records as the steering mechanism
According to Kaspersky’s ongoing monitoring of the threat activity cluster since December 2025, researchers identified previously unreported capabilities that expand Cavern’s communications. The key element is a complex C2 module that uses DNS A-record responses to choose between two paths for each transaction.
Instead of using a single, predictable channel, the malware queries DNS and uses the answer to decide whether it should connect directly to an attacker-controlled endpoint over HTTPS, or relay the communication through a Google Apps Script deployment.
Kaspersky also describes how the same DNS infrastructure can validate and replace a deployment identifier. That allows the operator to rotate the Google channel over time, making static detection rules less effective.
Google Apps Script relay for transaction-by-transaction control
When the DNS response indicates the “Google mode,” the communication module sends requests to a Google Apps Script deployment. That script then forwards the requests to attacker-controlled backend infrastructure.
When the DNS response indicates “Direct HTTPS,” the malware skips the relay and contacts the configured address directly, again using HTTPS.
This design matters because both options leverage widely used, legitimate network behaviors. Security teams that rely heavily on perimeter blocking or simple allow/deny policies may find it more difficult to differentiate between routine traffic and command-and-control activity.
New module and internal component broker
Researchers say the latest communication update is associated with a new module named GoogleService.dll. The module reads a local configuration file on disk (referred to as conf.json) and then performs the DNS A-record query needed for the direct-vs-relayed decision.
In addition, Kaspersky reports the presence of an inter-component broker (identified as rnp.dll). The broker acts as a local bridge inside the framework: it discovers and loads DLL components, routes messages between them, and supports runtime upgrades.
Separately, the reporting notes that the primary domain linked to the activity (studiotikva[.]com) was first registered in February 2024, expired in February 2026, and was re-registered three months later. While domains can change for many reasons, these lifecycle details fit patterns seen in infrastructure management for long-running operations.
How modular architecture supports persistence and stealth
Cavern’s wider design philosophy centers on modularity. Kaspersky assesses that this plugin-like architecture was implemented in late April 2026, meaning the framework can be extended as new operational needs arise. Researchers also connect this evolution to activity attributed to OilRig (APT34), though the linkage is described as low confidence and based on indicators rather than direct code reuse or infrastructure overlap.
Among the indicators cited are the use of Microsoft-hosted services for C2 (for example, RDAT and OilCheck), the presence of a secondary recovery mechanism to obtain replacement OAuth refresh tokens (observed in OilBooster), and the use of compromised infrastructure associated with target regions (seen in Solar and Veaty malware).
In short, Cavern appears to be built to keep adapting: when one channel becomes risky or less effective, the operator can shift communications methods without needing to overhaul the entire framework.
Blend-in tactics: cloud services as a camouflage layer
In earlier reporting, Cavern-related work also showed an ability to use legitimate enterprise ecosystems as part of the communication and tasking strategy. In follow-up reporting, Group-IB and Kaspersky described another module dubbed HOLLOWGRAPH, which repurposes Microsoft 365 calendar data as covert C2 channels.
HOLLOWGRAPH uses the Microsoft Graph API to treat a compromised mailbox calendar as a two-way dead drop. Operators can plant tasking by creating calendar events, and the implant can exfiltrate stolen files by creating its own events with encrypted data attached.
To reduce attention from the mailbox owner, the events are dated far into the future (notably 13 May 2050 in the reporting). This attempt at operational camouflage is paired with DNS tunneling to refresh credentials used to authenticate to the Graph API, with updated values written locally.
The broader lesson for defenders is consistent: Cavern’s communications are designed to look like ordinary, policy-compliant user activity—calendar events in one case, Google-hosted relay traffic in another—making conventional network-based detection harder to apply.
APT42 and TAMECAT via spear-phishing
Alongside the Cavern update, separate research described the resurfacing of APT42 activity using TAMECAT in spear-phishing campaigns. DarkAtlas reported that attacks targeting individuals associated with the nuclear energy sector occurred as recently as April and May 2026.
In these campaigns, the phishing lures used LNK files masquerading as PDF documents. The social-engineering themes revolved around podcast and interview invitations, reflecting APT42’s preference for credible professional engagement before malware delivery.
Once executed, TAMECAT functions as a modular surveillance and collection framework. It supports enumeration and discovery, arbitrary command execution, and the collection of browser credentials and cookies. The malware can also collect Outlook `.ost` mailbox data, capture screenshots, and use fallback mechanisms for command-and-control and exfiltration.
Researchers further noted that the group has been observed leveraging generative AI to accelerate aspects of operations. Reported uses include developing specialized tooling, researching exploitation techniques, translation work, identifying official email addresses, and studying relevant organizations.
What organizations should take away
The most important takeaway from the Cavern findings is the shift toward channel flexibility. By combining DNS and Google Apps Script, the operator can choose between direct HTTPS and a relay that routes through a widely trusted platform. That approach increases the difficulty of simple detection strategies and complicates incident response when traffic looks “normal.”
It also highlights why defenders should focus on behavior and context, not only on the presence of well-known cloud services. If threat actors can make malicious traffic resemble legitimate enterprise activity, organizations need tighter visibility into authentication flows, unusual API usage patterns, and inconsistent tasking signals across systems.
Finally, both the Cavern communications updates and the separate APT42/TAMECAT campaign underscore the same theme: threat actors continue to iterate. As frameworks become more modular and operational tempo stays high, monitoring and detection engineering must evolve in parallel.
Source: https://thehackernews.com/2026/08/cavern-c2-uses-dns-and-google-apps.html
