Slack and Teams Bot Tokens as Persistent Attacker Footholds

Disabling a compromised account should stop the attacker from using it. In Slack and Teams, that assumption can fail when the attacker holds a credential outside the user account’s lifecycle. Slack bot tokens belong to app installations, while Teams device code attacks can yield refresh tokens that survive password changes. Defending against this persistence requires finding and revoking the credential that grants access.

How attacker access enters through the collaboration layer in the first place

Attackers can enter collaboration platforms through stolen local credentials, deceptive authorization requests, or compromised accounts that already look trustworthy. These paths produce different credentials. That distinction determines what an attacker can retain after the original compromise is discovered, so “the account was compromised” is not a complete description of the incident.

Researcher Brahim El Fikhi detailed in October 2025 how Teams stores encrypted cookies in AppData through its embedded msedgewebview2.exe browser component. The encryption key sits in a JSON configuration file in the local cache. Extracting both and applying AES-256-GCM decryption yields valid authentication tokens without a credential prompt. The attacker obtains access material from the endpoint rather than persuading the user to type a password into a false login page. No new login prompt means no new opportunity for the user to notice one.

Device code phishing takes a different route. The victim visits the legitimate microsoft.com/devicelogin page and enters an attacker-controlled code, causing the platform to issue a refresh token to the attacker. Under default Entra ID configuration, that token remains valid for an extended period and survives a password change. This user-associated credential exposes the same danger of choosing a remedy that does not invalidate the access material.

In Slack, OAuth consent abuse and overbroad app installations can grant ongoing API access through an app’s token. An authenticated conversation can help an attacker get that authorization because the request comes from inside a place the user already trusts. Unit 42 found that endpoint alerts tied to collaboration tools more than quadrupled in a year, with the overwhelming share tracing to chat phishing from compromised authenticated accounts. The conversation supplies credibility. The credential then lets the attacker keep access after the conversation ends.

Why disabling a user account does not evict an attacker who controls a bot token

Slack bot tokens are bound to the app installation and bot identity. NHI Mgmt Group’s FAQ identifies this as the reason a bot can keep operating even after the original installing user is entirely gone. The account and the installation have separate lifecycles.

Slack bot tokens use xoxb-, while app-level tokens use xapp- and workflow tokens use xwfp-. Those additional classes also sit outside the user-account remediation model. A response that treats every credential as a user session can therefore finish its checklist without reaching the credential the attacker controls. The paperwork can be complete while the access remains open.

The FAQ states the operational consequence directly. A bot token may remain valid unless the app is revoked or uninstalled, even when the associated user account has been remediated. On Teams, the device code case requires a different response because the persistent credential is a refresh token. After a password reset alone, the refresh token still requires explicit revocation in Entra ID. Across their different token architectures, both platforms share a mismatch between the credential and the control used against it.

This survival property is deliberate. Legitimate ChatOps and incident-response automation must keep working when staff change, and tying every bot to one employee’s continued presence would make routine turnover disruptive. Disabling all bot tokens would break production workflows and leave app access inadequately governed. The useful feature becomes an attacker foothold when nobody checks whether the installation is still trusted, its credential is still controlled, and its access is still needed.

What attackers do with a live bot token once user remediation has closed

A live bot token can be more than a way to send messages. It can represent an execution identity with channel visibility, tool access, and the ability to chain actions across connected systems. Its reach depends on the permissions granted to the bot. That is where a seemingly contained collaboration incident can widen. The attacker has inherited an automation role.

Message-history permissions make that distinction concrete. A token with channels:history, groups:history, or im:history can read content across the relevant conversations the bot has been added to. That reach may extend well beyond the conversations any individual user has personally accessed. Broad grants to read messages, access files, or edit channels enlarge the available surface further. A bot installed for a small task can thus expose far more than its name or what it appears to do would suggest.

The next boundary is between collaboration access and connected secrets. ashifly’s red-team research shows that the bot token can be an entry point to secrets stored in the bot’s environment. That finding changes the scope of the investigation. Cutting off the original token addresses one credential, but it does not establish whether companion secrets were exposed through that foothold. Signing secrets, OAuth client secrets, and refresh material therefore belong in the incident review rather than being treated as unrelated application housekeeping.

A familiar bot also gives an attacker borrowed credibility. Messages posted under its name give an unsolicited approach from outside the appearance of automation inside a channel where people already work. An attacker controlling that token can exploit the distinction to deliver phishing links or social engineering. A user who would distrust an unfamiliar sender may be less guarded when the request appears to come from an established workplace integration.

How the commoditization of token-theft tooling changed the threat population for this technique

Token persistence no longer depends on an operator building the entire attack themselves. Device code phishing techniques tied to state-sponsored operations now come in crime kits that attackers with fewer skills can buy through a subscription. The technique has become easier to acquire. That changes who can exploit a remediation gap even though the underlying authorization mechanism has not changed.

Microsoft reported that Storm-2372’s device code phishing campaign had been active since August 2024. The group reached out to people through messaging services including WhatsApp, Signal, and Microsoft Teams, then used phishing emails to invite them to online events or meetings. Victims were directed to the legitimate device login page and asked to enter an attacker-supplied code. The trusted page completed the authorization the attacker had arranged.

Microsoft also described the group’s use of the Microsoft Authentication Broker client ID. That allowed it to receive a refresh token, request another token for the device registration service, and register an actor-controlled device in Entra ID. The group used connected devices to collect emails.

By March 2026, the EvilTokens phishing-as-a-service kit was driving a surge in device code phishing attacks, while platforms including Kali365 had incorporated the technique into their offerings. The skill floor had dropped. Organized criminal groups could use packaged capabilities rather than reproduce the work of an espionage operation. For defenders, the practical consequence is that token-aware response cannot be reserved for incidents involving unusually sophisticated adversaries.

Why standard access reviews fail to catch bot tokens and what they miss

Many SaaS access reviews ask whether the employees on the list are still there and still need the access they have. Those questions are valid but incomplete. A review can sign off on the list of people without checking bot tokens, OAuth grants, or changes to app privileges. It then says little about the identities that actually move data or change settings. The review creates confidence in a surface it did not examine.

The FAQ identifies the underlying framing error as treating Slack’s privileged access channel as a software entitlement. Under that model, integrations and external sharing escape normal review, while bots, tokens, nested admin paths, and privilege drift remain out of sight. Ownership can drift just as easily. The workspace team assumes the app owner watches the token, and the app owner assumes identity operations will revoke it. Neither has a complete inventory of where the credential exists or what it can reach.

Detection has a related operational gap, though it is not an absence of logging. Slack’s official documentation says that audit logs can be viewed directly and exported as CSV, while Slack Enterprise Grid has an Audit Logs API for custom monitoring. Basic access needs no additional setup. Programmatic monitoring and retention at scale, however, require integration with external tools such as a SIEM. An available log is not the same thing as an alert someone will investigate.

AI agents make this review gap more consequential. A person may have access to many channels but open only a few, while an agent with the same grant can read all of them in seconds and retrieve specific content. Human access is constrained by attention. Agent access is constrained by scope, so a review that overlooks agent identities misses a category of token holder whose use of broad permissions can be much more extensive.

What remediation actually requires when bot tokens are in scope

The token class determines which revocation action to take. User, bot, app-level, and workflow credentials do not all share a remediation path. For a Slack bot token, the app installation is the security boundary that the response must address through app revocation or uninstalling. For a Teams device code-issued refresh token, explicit revocation in Entra ID is required. A password reset is not a substitute for that action.

The investigation must also extend beyond the primary token. Companion signing secrets, OAuth client secrets, and refresh material need auditing because the bot’s environment may expose additional credentials. Preventive work begins with a live inventory of every bot, app, and non-human identity, including its owner, scopes, and channel access. Without that inventory, revocation becomes guesswork. Least-privilege review at installation should remove message-history grants such as channels:history, groups:history, and im:history where the bot does not need them.

A Microsoft-managed Conditional Access policy blocking device code flow was released in 2025, but blocking the flow may break legitimate workflows that depend on it. Teams should check whether approved workflows need it before turning on the policy. Detection also needs Slack audit logs connected to a SIEM, with alerts for token usage, new app installations, admin role changes, and automation that runs at unusual times. Outbound webhook traffic from systems with no approved integration also warrants hunting because a webhook can serve as an exfiltration channel without other malware.

Agents need their own access review, scope controls, and runtime monitoring, separate from checks on employee access. Because agents work so fast, giving them too much permission can do more harm. Real-time visibility and enforceable policy controls are needed alongside logs examined after the event. Every live token must have an owner, scopes that fit its purpose, and a reason it is still needed.