A leaked Teams webhook URL is a phishing cannon in a trusted channel
A leaked incoming-webhook URL lets anyone post spoofed internal alerts into a Teams channel. There is no account to suspend, because the URL itself is the secret.
A Microsoft Teams incoming webhook lets a system post into a channel with nothing but a URL, no login and no user. If that URL leaks from a repo, a script, or a screenshot, anyone holding it can post what looks like a trusted internal alert.
How the attack works
The attacker uses the leaked webhook URL to post a message styled as an internal IT or security alert, urging users to reverify their account at a link. The post appears in a familiar channel with a bot-like name and no real sender, so users read it as an internal notice rather than external phishing. The link leads to a credential-harvesting page styled like the corporate login, and harvested credentials are then reused to attempt sign-ins. This is Phishing, T1566, delivered as Internal Spearphishing, T1534, with Impersonation, T1656.
Why it works
An incoming webhook authorizes posting purely by possession of the URL, so there is no user identity behind the message. A real internal alert comes from a known user or a sanctioned, identifiable system, but a trusted channel makes the spoofed alert more convincing, not less.
How to fix it
There is no account to suspend, and deleting the messages leaves the URL working. The webhook URL is the secret, so delete or rotate the incoming-webhook connector to invalidate the leaked URL, then treat the posted links as phishing and protect anyone who clicked by forcing resets and revoking sessions. For the class fix, inventory and govern Teams connectors, restrict who can create incoming webhooks, store URLs as secrets, and alert on connector creation and webhook posts.
Practice it
We built this as a GraphLattice Range scenario so responders can rehearse attributing a connector post, killing the leaked URL, and scoping who was exposed.