Operation MacroMaze: APT28 abusing webhooks for C2
Just caught the latest intel from S2 Grupo's LAB52 team regarding APT28. They've been busy with 'Operation MacroMaze,' specifically targeting entities in Western and Central Europe between September '25 and January '26.
What stands out here isn't sophisticated zero-days—it's the tradecraft shift. Instead of setting up a standard C2 infrastructure that's easy to blacklist, they are leveraging webhook-based malware inside macros. This effectively abuses legitimate services (likely generic HTTP endpoints or notification services) for command and control, making network detection significantly harder since the traffic blends in with legitimate API calls.
Given the timeline, if you have ties to Central Europe, I'd recommend scrubbing your logs for Office applications spawning unexpected processes or making outbound connections to unusual endpoints.
Here is a basic KQL query I'm using to hunt for this behavior, focusing on Word/Excel making outbound POST requests (common for webhooks):
DeviceProcessEvents
| where InitiatingProcessFileName in ~("winword.exe", "excel.exe", "powerpnt.exe")
| where NetworkDirection == "Outbound"
| where ActionType == "ConnectionSuccess"
| where RemotePort in (443, 80)
| extend URL = strcat(RemoteUrl, ":", RemotePort)
| project Timestamp, DeviceName, InitiatingProcessCommandLine, FileName, URL, RemoteIP
| sort by Timestamp desc
Since they rely on 'basic tooling' as the report notes, standard macro blocking policies should theoretically stop this, but phishing templates are getting better at bypassing user training.
How is everyone handling the macro enforcement balance? Are you blocking all internet-enabled macros entirely via GPO, or do you rely on specific ASR rules?
Good share. We started enforcing Attack Surface Reduction (ASR) rule 'Block Office applications from creating child processes' last year. It causes some noise with legitimate plugins, but it completely neutered this type of macro dropper. I highly recommend testing it in Audit mode first if you haven't already.
The webhook angle is interesting. It lowers the barrier for entry because they don't need to maintain infrastructure. We've been looking for this specific pattern in our proxy logs—User-Agent strings from Office apps hitting non-Microsoft domains. It’s a low-fidelity signal, but surprisingly effective when paired with the KQL query you posted.
From a pentester perspective, this is just the evolution of 'living off the land.' If I were testing your defenses, I'd check if your EDR is alerting on winword.exe spawning powershell.exe or cmd.exe. If that's suppressed, the webhooks don't matter—the code execution already happened. Ensure your process creation auditing is watertight.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access