APT28's NotDoor Backdoor: When Webhooks Become Weapons

Russian state-sponsored threat group APT28, also known as Fancy Bear, has been attributed to a new Microsoft Outlook backdoor named NotDoor. The malware has been used in attacks against organisations across multiple sectors in NATO member countries, and its command-and-control mechanism is notable: it beacons to webhook.site, a legitimate developer tool that most firewalls and security products have no reason to block.

That is the detail that caught our attention. At The API Guys, we work with webhooks every day. They are a fundamental part of modern API integration. The fact that attackers are now routing their command infrastructure through the same tooling that developers use for testing and debugging is a reminder that legitimacy and safety are not the same thing.

What Is NotDoor?

NotDoor is a Visual Basic for Applications (VBA) macro project designed to run inside Microsoft Outlook. It was analysed by threat intelligence researchers at LAB52, the research team of Spanish cybersecurity company S2 Grupo, and the name comes from the word "Nothing" used within the malware's source code.

At its core, NotDoor turns Outlook into a covert command-and-control channel. It hooks into two Outlook application events: Application.MAPILogonComplete, which fires every time Outlook starts, and Application.NewMailEx, which fires every time a new message arrives. This means the backdoor is active whenever Outlook is open and does not require the victim to interact with any email to run.

The malware monitors incoming emails for a specific trigger string, for example "Daily Report." When an email containing that trigger arrives, NotDoor extracts commands embedded in the message and executes them on the victim's machine. Results are sent back to the attacker via a Proton Mail address, and any files staged for exfiltration are encrypted using a custom encoding scheme before being sent as email attachments.

Four Commands, One Persistent Foothold

NotDoor supports four commands that give the attacker full remote access to an infected machine:

• cmd - execute a command and return the standard output as an email attachment
• cmdno - execute a command silently, with no output returned
• dwn - exfiltrate files from the victim's machine as email attachments
• upl - drop files onto the victim's machine

The combination of upload and download capability alongside arbitrary command execution means that once NotDoor is installed, the attacker has everything they need to maintain persistence, move laterally, and extract data at will.

How It Gets In

The initial delivery mechanism is not fully confirmed, but analysis of the malware shows it is deployed using a technique called DLL side-loading. The attacker abuses Microsoft's own OneDrive executable, onedrive.exe, to load a malicious DLL named SSPICLI.dll. Because onedrive.exe is a trusted, signed Microsoft binary, this technique helps the malware avoid detection by security software that monitors process behaviour.

Once the malicious DLL executes, it installs the NotDoor VBA project into Outlook, disables macro security protections, suppresses Outlook dialogue boxes that might alert the user, and sets up Registry persistence so the backdoor survives reboots.

Before any of that, the malware runs Base64-encoded PowerShell commands that beacon to webhook.site to register the infected machine with the attacker's infrastructure.

Why Webhook.site?

This is the part that deserves particular attention. Webhook.site is a real, widely used service that allows developers to capture and inspect HTTP requests in real time. It is commonly used for testing webhook integrations, debugging API callbacks, and verifying that services are sending the expected payloads. Many development teams use it routinely.

From an attacker's perspective, routing initial beaconing through webhook.site is a clever choice. Most corporate firewalls allow outbound HTTPS traffic to webhook.site without restriction. Security products that inspect traffic based on reputation or category would have no particular reason to flag it. The traffic looks like a developer testing an integration, not a state-sponsored actor registering a new compromised machine.

This technique is not unique to APT28. The broader trend of abusing legitimate cloud and developer services for command-and-control, sometimes called "living off trusted infrastructure," has been growing for several years. We have seen attackers use GitHub Gists, Pastebin, Telegram bots, Google Drive, and now webhook services for this purpose. If you are interested in how webhooks work legitimately, we wrote about the fundamentals in our post on webhooks versus polling.

The Gamaredon Connection

The NotDoor disclosure also coincides with newly published research on Gamaredon, a separate Russian-linked threat group also known as APT-C-53. Gamaredon has been observed using Telegram's Telegraph publishing platform as a dead-drop resolver to point infected machines towards their real command-and-control servers, and abusing Microsoft Dev Tunnels, a service designed to let developers expose local servers to the internet for testing, as live C2 domains.

The pattern is consistent across both groups: use legitimate, trusted developer infrastructure to mask malicious traffic. Dev Tunnels and webhook.site both exist to solve real developer problems. That utility is precisely what makes them attractive to attackers.

What This Means for Your Business

A few things are worth taking away from this.

Macro execution in Office applications remains a significant risk. NotDoor requires macros to be enabled. Microsoft has tightened macro defaults over the past few years, particularly for files downloaded from the internet, but macros enabled via DLL side-loading can bypass these protections. If your organisation does not have a documented need for Outlook VBA macros, consider whether macro execution should be disabled at the group policy level.

Outbound traffic inspection matters. Blocking known malicious IPs and domains is necessary but not sufficient. Attackers routing traffic through webhook.site, GitHub, or Telegram will bypass blocklists entirely. Behavioural detection, which looks at what a process is doing rather than where it is connecting, is increasingly important.

Developer tools have dual use. Webhook.site, Dev Tunnels, ngrok, and similar services are used legitimately every day. Consider whether outbound connections to these services should be permitted from production and corporate machines, or whether access should be restricted to development environments.

DLL side-loading via trusted binaries is a persistent technique. Attackers using onedrive.exe as a loader is a reminder that process reputation alone is not a reliable security signal. Monitoring for unexpected DLL loading from known system binaries is worth adding to your endpoint detection configuration if it is not already there.

APT28 in Context

APT28 is one of the most well-resourced and persistent threat actors tracked by the security community. Attributed to Russian military intelligence (the GRU), the group has been active for well over a decade and has targeted governments, defence organisations, media companies, and technology firms across NATO countries. Their tooling evolves steadily, and NotDoor represents a continuation of their preference for stealthy, low-noise access over dramatic, destructive attacks.

The use of Outlook as a C2 channel is particularly patient. Rather than using a dedicated network protocol that might be flagged by intrusion detection systems, NotDoor lives entirely within normal email traffic. Commands arrive in emails. Results leave in emails. From a network monitoring perspective, it is nearly invisible unless you know what to look for.

What to Do

If your organisation uses Microsoft Outlook and has not reviewed its macro policies recently, now is a good time to do so. Ensure endpoint detection and response tooling is monitoring for DLL side-loading activity, particularly from Microsoft-signed binaries in unexpected locations. Review whether outbound access to webhook and tunnelling services is necessary from corporate machines.

For development teams using webhook.site and similar tools as part of their integration work, that use is entirely legitimate. The risk sits at the boundary between development tooling and production/corporate environments, not in the tools themselves.

If you have concerns about the security posture of your API infrastructure or want to discuss how to separate development tooling access from your production environment, get in touch with us. This is exactly the kind of security architecture question we work through with clients regularly.