Most people picture malware “phoning home” to a shady server in a country you can’t find on a map. Your firewall blocks the IP, your DNS filter kills the domain, and the threat is contained. That mental model is why the HOLLOWGRAPH campaign is worth your attention.
In July 2026, Group-IB’s Threat Intelligence team published research on a Windows implant that doesn’t contact attacker infrastructure at all. Instead, it logs into a compromised Microsoft 365 mailbox and uses the calendar as a dead drop — operators leave instructions in appointments, the malware picks them up, does its job, and posts stolen files back as attachments on calendar events it creates itself.
The appointments are dated May 13, 2050.
No one scrolls to 2050.
How it actually works
HOLLOWGRAPH is a lean .NET NativeAOT DLL — reported as AzureCommunication.dll — that supports exactly two commands: get and send. That’s the whole vocabulary.
getsearches the compromised mailbox’s calendar for events planted by the operator, using subject lines formatted likeEvent ID: <agent-id>. It downloads the attached command data, decrypts it, and deletes the event to clean up behind itself.sendencrypts collected files and uploads them as attachments on newly created appointments, with attachment names following aFile{n}.txtpattern.
Everything moves over the Microsoft Graph API. The implant authenticates to Microsoft Entra ID using OAuth 2.0 application credentials — a tenant ID, client ID, and client secret that are hardcoded in its configuration and written to disk in a file named logAzure.txt, which also holds the target mailbox address, a C2 domain, and two RSA keys.
Two keys, because the traffic uses hybrid RSA plus AES-256-GCM encryption with separate key pairs for each direction. Breaking inbound tasking wouldn’t expose outbound exfiltration, and vice versa.
There’s a fallback channel too. When cloud authentication fails, the malware uses DNS tunneling — IPv6 AAAA record lookups to an attacker-controlled domain — to refresh its Entra credentials and configuration, then rewrites logAzure.txt with the new values. Two independent channels, which means blocking one accomplishes very little.
Group-IB ties HOLLOWGRAPH with high confidence to the Cavern modular backdoor framework, which has been linked to Iran-nexus activity. Attribution to a specific group remains unconfirmed; some researchers have floated an OilRig subgroup connection at low confidence. Group-IB counted 12 infected systems, only around three of which were actively communicating during the observation window, and the recovered indicators — an Israeli mailbox used for exfiltration, samples uploaded from Israel — point to narrow espionage targeting rather than a spray-and-pray campaign.
Why this should matter to you even if you’re not a defense contractor in Tel Aviv
Two reasons.
First, there is no patch. This is not a Microsoft 365 vulnerability. Nobody found a hole in Graph. The attackers are abusing permissions, trust, and API traffic that your tenant already allows and that your tooling already treats as normal. There is nothing to remediate on Patch Tuesday. The work is identity governance and monitoring.
Second, techniques trickle down. Nation-state tradecraft has a reliable habit of showing up in commodity crimeware eighteen to twenty-four months later. Living-off-trusted-cloud-services is an obvious growth area: it defeats network-based detection, it survives IP and domain blocklists, and it rides inside TLS to graph.microsoft.com — a destination you cannot block without breaking your business.
If your security posture is “we have a good firewall and a DNS filter,” this class of attack walks straight past it. Your outbound traffic to Microsoft looks exactly like everyone else’s outbound traffic to Microsoft.
What to look for
A useful caution up front: an unexpected calendar invite is not evidence of compromise. Calendar spam is ordinary and noisy. HOLLOWGRAPH operates through an already compromised mailbox — the calendar is the C2 channel, not the initial access vector. Don’t sweep every employee’s calendar and panic at anything dated far in the future. The signal is the combination of indicators.
In Microsoft 365 audit data:
- Calendar events created more than two years in the future — particularly with file attachments
- Subject lines matching
Event ID:orBoss{..}ID{..}patterns - Attachments named
File1.txt,File2.txt, and so on calendarViewcalls filtering on fixed strings likeEvent IDorBoss- Mailbox audit entries showing calendar operations performed by an application identity rather than a user
- Calendar modifications by OAuth apps that were registered recently and have never touched the calendar before
In Entra ID:
- App registrations holding
Calendars.ReadWriteas an application permission rather than delegated — that’s the pattern this telemetry shows - New client secrets created on existing app registrations
- Service principals with mailbox or calendar access that nobody can account for
In DNS:
- Repeated AAAA (IPv6) queries to a single external domain from an endpoint, especially one that has no business making them
On the endpoint:
- A file named
logAzure.txt— validate the path and creation time before assuming the worst - Suspicious DLLs; compare hashes against Group-IB’s published indicator list
If you get a hit, isolate the host before you start deleting things. The config file on disk is evidence, and it will tell you which tenant, which mailbox, and which app registration the operators were using.
What to actually do about it
None of this requires exotic tooling. It requires treating cloud identity as your real perimeter.
- Inventory every app registration and service principal in your tenant. Anything holding application-level Mail or Calendars permissions needs a named owner and a documented business reason. If nobody can explain it, it shouldn’t exist.
- Alert on new client secrets and certificates added to app registrations. This is a high-signal, low-noise detection, and it’s cheap to build.
- Turn on mailbox auditing and make sure your unified audit log retention is long enough to matter. Thirty days is not an investigation.
- Restrict OAuth2 client-credentials apps. Prefer certificates or managed identities over long-lived secrets, rotate what you do have, and apply Conditional Access policies for workload identities where your licensing supports it.
- Monitor DNS at the endpoint, not just at the edge. Volumetric AAAA queries to one domain is a pattern worth catching.
- Watch Graph API activity. If you’re on E5 you have Graph Activity Logs — use them. If you’re not, mailbox and Entra audit logs still carry most of this signal.
The bigger point
For years the security advice was “watch what leaves your network.” Attackers have adapted by making sure nothing suspicious leaves it. When the malware’s C2 server is your own Microsoft 365 tenant, network monitoring has nothing to flag — the connection is legitimate, encrypted, and going exactly where it should.
HOLLOWGRAPH is a targeted espionage tool that most organizations will never encounter. The technique is going to be everywhere. Now is a good time to find out how many applications have standing permission to read your mail and write to your calendars, and whether you’d notice if one more quietly appeared.

