SURIQ
The notable thing about HollowGraph is not the calendar trick. It is that the command channel now looks exactly like ordinary Microsoft 365 traffic. Group-IB analyzed an espionage implant that reads its orders from, and ships stolen files back through, a compromised mailbox calendar over the Microsoft Graph API. There is no vulnerability here and nothing to patch. That one fact should change how you respond, because the reflex of find the CVE, apply the fix, move on does nothing against malware that rides a cloud service you pay Microsoft to run.
Group-IB, which named the implant, reported finding it on at least 12 systems, 3 of them still active in a window that ran from June 3 through July 9, 2026. The target was an organization in Israel, and the firm describes the intrusion as targeted espionage rather than opportunistic crime. Group-IB links HollowGraph to the Cavern backdoor framework, which Check Point has tied to an Iranian-nexus operator it tracks as Cavern Manticore, with overlaps to activity previously reported as MuddyWater and Lyceum. Group-IB itself stops short of attributing this specific activity to any named group, so treat the Iran link as reported and not settled.
How HollowGraph moves through Microsoft 365
The implant treats the mailbox calendar as a dead drop that works in both directions. Operator tasking is planted on calendar events dated far in the future, in these reports May 13, 2050, so the entries sit well outside any normal working view. Instructions travel as files attached to those events. The malware reads them, does the work, then creates its own future-dated event and uploads the stolen file as one or more attachments, a mechanism BleepingComputer detailed alongside Group-IB's findings. All of that moves as Microsoft Graph API calls, which is exactly why it blends in.
The component Group-IB examined is a small .NET library that supports only two operations: one to pull tasking, one to send data back. Traffic in each direction is wrapped in a mix of RSA and AES-256-GCM encryption, with separate keys for inbound tasking and outbound theft, so a defender who recovers one key does not automatically read both channels. Everything it needs to authenticate lives in a local configuration file: the Microsoft Entra tenant it targets, the registered application plus its client secret, the victim mailbox, the C2 domain, and a pair of RSA keys. A secondary channel refreshes those cloud credentials over DNS, using IPv6 address records from an attacker-controlled domain, so the operator can rotate access without ever touching the calendar.
- 1Account and app accessDetection point
- 2Tasking read from calendarDetection point
- 3Collection on hostDetection point
- 4Exfil as event attachmentDetection point
Why your network sensors will never see this
Point your egress filtering, DNS blocklists, and TLS inspection at this and they all wave it through, because the destination is Microsoft's own Graph endpoint. There is no rogue IP to block and no odd domain in the primary channel. The traffic is authenticated Microsoft 365 activity from an account and an app that already have consent. This is the part the coverage this week mostly skips: the calendar is a clever container, but the real shift is that the covert channel is now indistinguishable from sanctioned SaaS traffic. That is what defeats a perimeter model, not the year 2050.
We have watched this pattern harden for a while. DragonForce hid its C2 inside Microsoft Teams relays so network sensors saw a clean call. The Cavern operator we wrote up needed no CVE at all, abusing an IT provider's own tooling to get in. HollowGraph, tied to that same Cavern framework, is the cloud-native version of the idea: instead of borrowing a trusted tool on your network, it borrows a trusted service in Microsoft's cloud. In ATT&CK terms this is a web-service C2 channel, and if you are not sure why that framing matters for hunting, our primer on MITRE ATT&CK is a good starting point.
The far-future events are the attacker's tell, not just their trick
The date that hides the tasking is also the cheapest way to catch it. A calendar event set decades ahead that also carries file attachments is anomalous in almost any tenant, whether or not you have ever heard of HollowGraph. You do not need a signature for the malware to hunt the behavior. That inverts the usual problem: the operator chose 2050 to stay out of a human's normal view, but a query does not have a normal view, and a rule that surfaces future-dated events with attachments turns their stealth choice into your highest-fidelity alert.
The same logic applies to the app doing the writing. Legitimate users rarely create calendar entries through a registered application making raw Graph calls. An app-driven event write, especially one with attachments, from a workstation process is worth flagging on its own. These are behaviors, not indicators that expire when the operator changes a domain.
This is an identity compromise, so treat it like one
Because there is no software bug, remediation is account and application hygiene, not patching. The persistence primitive here is a mailbox-scoped app registration with the consent to read and write calendar items. That is the same class of exposure we covered when a connected OAuth app, not the platform, handed over Salesforce data: the platform was never breached, the delegated access was. Multi-factor authentication does little once a malicious app registration already holds a token, so do not assume MFA closed this door.
Group-IB's guidance points at the Microsoft 365 audit log as the place to look: application-driven calendar activity, events far in the future, and unusual subjects or attachments. To that, add Conditional Access policies that constrain which apps can touch mailboxes, a periodic review of OAuth consent grants, and DNS monitoring for the tunneling pattern that refreshes the operator's credentials.
Audit your Graph app registrations before you hunt the calendar
Start with the app layer, because that is where the access lives. Pull the list of registered applications and enterprise app consents that hold mailbox or calendar permissions, and treat anything unfamiliar or over-scoped as a lead to run down. Then write the two behavioral hunts: future-dated calendar events that carry attachments, and calendar writes made by an application rather than a signed-in user. If you find an app you cannot account for, revoke it and rotate its client secret before you go looking for the events, because the event trail confirms the compromise but the app registration is what keeps the operator inside.