Weaponizing Automation: n8n Webhooks as a Phishing Vector
Just read the latest report on threat actors abusing n8n workflows since late 2025. It’s a classic case of "trusted infrastructure" being turned against us. By leveraging n8n's webhooks, attackers are automating phishing campaigns that often bypass traditional SEGs because the traffic originates from legitimate automation platforms rather than sketchy VPSs.
What makes this tricky is the sophistication. The workflows aren't just spammers; they can perform device fingerprinting before delivering the payload.
For those of you running SIEMs, you might want to start hunting for indicators of automation tool abuse. We're looking at specific User-Agent strings and traffic patterns. Here is a snippet I'm testing to catch suspicious automation traffic hitting our perimeter:
CommonSecurityLog
| where DeviceVendor in ("Palo Alto Networks", "Fortinet", "Cisco")
| where RequestURL contains "webhook" or RequestURL contains "/rest/"
| where UserAgent contains "n8n" or UserAgent contains "axios" or UserAgent contains "node-fetch"
| extend FullURL = strcat("https://", DestinationHostname, RequestURL)
| summarize Count=count() by SourceIP, UserAgent, FullURL, bin(TimeGenerated, 1h)
| where Count > 10
| project-away Count
We’re debating whether to outright block known n8n User-Agents at the perimeter, but that risks breaking legitimate business processes.
How are you guys handling "Shadow Automation" in your environments? Are you blocking these tools wholesale, or have you found a way to inspect the payload effectively?
Shadow IT is the real root cause here. We audited our network last month and found three different departments running self-hosted n8n and Zapier instances without InfoSec approval. We've since moved them to a sanctioned, internal tenant behind a CASB. If you can inspect the traffic, you can apply DLP policies to the automation inputs/outputs, but you have to know the instances exist first.
From a pentester's perspective, this is huge. Bypassing reputation filters by abusing legitimate SaaS IP ranges is the easiest way to get into a secure inbox. I'd recommend checking your SPF/DKIM records for any "include:" mechanisms that might be overly permissive for automation services. If an attacker compromises a specific workflow in a hosted automation platform, they are effectively inheriting the domain's reputation.
We started tagging User-Agents associated with known automation frameworks (n8n, Power Automate, Zapier) in our proxy logs. While we don't block them by default, we route that specific traffic through a higher-latency inspection sandbox to analyze the email headers before they hit the internal mail server. It's added some latency, but it caught a similar attempt using Make.com last week.
Good point on User-Agents, Sarah, but spoofing is trivial. We’ve had success hunting for the specific URL structure of n8n webhooks, which often utilize static paths with appended UUIDs. Detecting high-frequency requests to a single webhook endpoint can reveal automation abuse. You can use this regex in your SIEM to flag suspicious patterns:
\bwebhook/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\b
Building on the sophistication angle, since these workflows often involve headless browsers for fingerprinting, we look beyond User-Agents to TLS fingerprints (JA3). It's much harder for automation frameworks to spoof the TLS handshake than the HTTP headers.
We correlate traffic spikes with known non-browser JA3 hashes. You can start hunting for anomalies in your proxy logs:
NetworkEvents | where TlsClientHello contains "HeadlessChrome" or Ja3Hash in ("known_automation_hashes")
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access