Shadow Webhooks - Hunting for Dangling Event Listeners in Enterprise Workspaces

Enterprise software-as-a-service workspaces collect webhooks from chat, ticketing, source control and CI/CD tools, and many keep sending events after their owners, services or domains are gone. The speaker defines a shadow webhook as an event connection that stays trusted even though its owner, destination or validation model has become unclear. The model splits each connection into a source, a registry entry, a destination, a receiver-side validator and an owner, and the trust breaks when one of those parts becomes uncertain.

The talk lays out four failure patterns: a retired destination, reclaimable infrastructure such as an expired domain or deleted cloud function, weak request validation, and an orphaned owner. The workflow runs from inventory and classification through fingerprinting and safe validation with synthetic events, then impact assessment and reporting. A controlled lab demonstrates two cases. A synthetic Jira-style event is delivered to a retired callback that still returns a success code, and a forged Slack-style request with an invalid signature is accepted by a weak receiver but rejected with an unauthorized response by a hardened one.

The speaker argues that a finding becomes triageable only when the trusted source is active, live delivery is proven, the ownership gap is clear, validation is weak, and the payload or workflow impact matters. Testers should prove trust without collecting real third-party data. Defenders are advised to assign named owners, enforce signatures and timestamp windows, set expiry dates, rotate secrets and monitor the lifecycle of linked domains and cloud resources.