A Zap as an exfil channel: why your egress firewall is useless

iPaaS tools run automations server-side using the app connections you already authorized. That makes a malicious Zap itself the exfiltration channel, and it never touches your network.

How the attack works

An attacker with workspace access creates a new multi-step Zap that triggers on CRM records and uses an outbound webhook as its action. They point the webhook at an attacker-controlled endpoint and switch the Zap on. Every new record, plus a backfill via a search step, is sent to the external sink through Zapier’s servers, and task history shows continuous successful runs. In ATT&CK terms this is T1648, Serverless Execution, paired with T1567, Exfiltration Over Web Service.

Why it works

Anyone with workspace access could build a Zap over broadly-scoped connected apps, with no control over where data could be sent. Because the Zap executes in Zapier’s cloud on already-authorized tokens, the source app sees no external login and your corporate egress never sees the traffic.

How to fix it

Disable and delete the malicious Zap to stop the runs, then disable its connected-app connections and rotate the connected-app OAuth tokens so it cannot be re-authorized. The non-obvious point is that an egress firewall rule is irrelevant here and a password reset does not stop a live server-side Zap. Scope what was sent from the Zapier task history, which logs each run’s data, not from the Zap configuration, which only shows capability. As a class fix, restrict who can create Zaps and add connections, enforce SSO and MFA with least-privilege scopes, allowlist outbound webhook destinations, and audit existing Zaps for unapproved sinks.

Practice it

We built this as a GraphLattice Range scenario so teams can rehearse disabling the Zap, rotating its connections, and scoping the leak from task history.