TL;DR: Our analysis shows attackers are now enumerating or pulling data within 15 minutes of getting into an environment, and the tools that should have caught them were not effective. We will discuss three common attack patterns in which we observed this behavior.
- Stolen developer tokens. Poisoned npm packages and infostealers pull GitHub tokens from developer laptops; attackers later use those tokens to exfiltrate data from GitHub. GitHub has no native detections for how a token is used, leaving enterprises vulnerable to code exfiltration
- ClickFix lures for AI tools. Fake Claude Code install commands in shared Claude chats load a macOS stealer that takes browser cookies and cloud credentials. The victim runs the commands themselves, much like they would when installing any tool, which may or may not trigger an endpoint detection.
- Help desk vishing. Attackers leverage social engineering and pose as IT to get an employee to approve a real MFA prompt on a look-alike sign-in page. Identity providers can treat the attacker's login as legitimate, making them ineffective at detecting these issues.
Catching these incidents takes detection built on data and behavior. Stopping them takes an autonomous response. We cover both of these topics.
In March, a developer installed GitHub Desktop, signed in, and stopped using it the same day. The OAuth token it created sat in the Mac's keychain for 95 days. On June 19, someone else started using it.
The token pulled 76 repositories in about 15 seconds through residential proxies in more than two dozen European cities. GitHub raised no alert because nothing in GitHub watches how tokens are used. The Exaforce platform flagged it within five minutes and had it triaged within 10 minutes.
Our MDR analysts confirmed the exfiltration and notified the customer minutes after the detection fired. But by the time any action was taken, the attacker had exfiltrated data from 472 of the 638 repos.
This case shows both halves of the problem. Without anomaly detection, nobody would have known the token was in use. With proper detection in place, containment would still have required human approval, giving the attacker sufficient time to exfiltrate data.
Sleeper tokens on developer laptops
GitHub's security features are focused on inspecting code and secrets, not token misuse. We caught this GitHub token compromise by stacking weak signals on a single GitHub session. Sign-ins to the account came from networks and cities never seen before.
It was pulling ZIP archives at machine speed, with a Windows user agent, on an account that had only ever used macOS. Each of these signals can potentially be explained, but all of them combined are indicative of something malicious.
OAuth app tokens like this one, prefixed gho_ , don't expire, and GitHub revokes them on its own only after a year. In our testing, the organization's SSO page does not even list these tokens, and they are visible only through the CLI. Disabling the developer in the identity provider doesn't stop the token either.
Without SCIM, GitHub keeps honoring tokens until someone revokes them or removes the user from the org.
Developers using AI coding tools install npm packages and connect MCP servers all day, mostly outside the pipelines that security teams monitor, and worms like Shai-Hulud sweep a machine for GitHub and cloud tokens the moment a poisoned package is installed.
This happens before anything is committed, which is why scanning your repositories to determine whether a compromised npm package may have affected you is not sufficient.
ClickFix goes after AI tool installs
Stealing a token from the macOS keychain usually requires an infostealer that phishes for the login password.
The latest ClickFix lures leverage trust from AI tools. In one such incident, an employee who was searching for Claude Code install instructions landed on a shared Claude conversation with a one-line install command.
The command loads a macOS stealer (we did a deep analysis with indicators) that fakes a System Preferences prompt for the password, then copies the keychain, browser cookies, saved passwords, and cloud credentials.
Because the victim runs the command, email filtering and download controls are bypassed. The most effective approach to catching these types of attacks is an endpoint detection solution. Assessing the scope of the impact should involve a comprehensive analysis of all tokens/credentials minted by the user.
Fake IT calls that end in stolen sessions
In the vishing cases we worked this year, the attacker registered their own MFA device and started a bulk download script 2.5 7 minutes after the victim approved the push. In one such case, the attacker exfiltrated 140,000 files and requested a ransom for the leaked data.
Most of these calls follow the help desk script commonly leveraged by the Scattered Spider group. A caller posing as IT sends the employee to a sign-in page with the company's name in the URL, such as the passkey-themed contoso.add-passkey[.]com in Microsoft's September write-up.
The page either relays the login through an adversaryin-the-middle AiTM) proxy, or the attacker guides the victim through a device-code sign-in.
One kit we took apart, hosted on oskeysetup[.]com, was written from scratch, so detections built for Evilginx and the other public kits are not going to be effective.
In most instances, we observed that detections from identity providers are ineffective because victims approve a real MFA prompt. In a July session hijack we worked on, Microsoft flagged the attacker's first sign-in as risky, then marked the risk remediated because the user had passed MFA. Within minutes, the stolen token was replayed from two other countries within one second, and Microsoft's later alerts raised the user's risk level.
Exaforce caught it by tying the Okta and Microsoft sign-ins together and checking them against the user's history: this was the account's first-ever sign-in from the United States, on a Linux device, and through a home ISP the account had never used. In these cases the earliest strong signal is usually a new MFA method from a device and network the user has never touched.
We also noticed that attackers target the same company through multiple employees, often using the same servers and domains.
Autonomous response actions
An effective approach to counter the incidents discussed so far is to move toward autonomous response. Automating response is certainly not new, but the fear has always been about the consequences of a wrong action that can lock out an executive or break a production integration.
We find it's better to sort actions by friction instead: how much would a mistaken response action cost the person who owns the credential? If it costs them a fresh sign-in or a re-enrolled phone, the action is low-friction and can fire on a high-confidence finding. That covers revoking sessions, removing an MFA method registered during the flagged session, and deactivating a key that can be switched back on.
Password resets, account disablement, permanent deletions, and anything a production service depends on should require human approval. The human can be the target user and their manager, confirming in a quick message that the sign-in wasn't theirs.
Although most of the actions discussed are related to an identity or its associated credentials, they cannot be limited to the identity provider. Resetting the user's Okta password or killing their Okta session doesn't revoke tokens that Microsoft 365, Google Workspace, or GitHub already issued, and AWS and Snowflake sessions started through SSO keep running.
In our vishing cases, we found that data exfiltration continued for between 44 minutes and 3 hours after the user's IdP session was revoked, and in one case the attacker's inbox rules survived a password reset. Okta's Universal Logout reaches some apps, like Google Workspace and Slack, but not GitHub, Snowflake, or the AI model providers.
It's best to build each application's revocation actions ahead of time, along with the account that runs them. We've watched a response action fail mid-incident with a 403 because nobody had granted the required permissions.
It may be daunting to build these responses for every source of data. We recommend starting with services that hold your most critical data.
- Productivity: Google Workspace, Office 365, Box, Dropbox, Slack
- Cloud: AWS, GCP, Azure
- AI services: Anthropic, OpenAI
- Data: Snowflake, Databricks
- Code: GitHub, GitLab
Recommended low-friction responses to start with and how to implement them:
OKTA
Action: Revoke sessions and the OAuth tokens Okta issued
API: DELETE /api/v1/users/{id}/sessions?oauthTokens=true
Permissions it needs: okta.users.read and okta.users.manage scopes, plus a custom admin role holding only okta.users.read and okta.users.lifecycle.clearSessions
Action: Reset all of the user's factors, including the attacker's
API: POST /api/v1/users/{id}/lifecycle/reset_factors
Permissions it needs: Same scopes, with okta.users.credentials.resetFactors added to the role
Microsoft Entra ID
Action: Revoke refresh tokens and session cookies
API: POST /users/{id}/revokeSignInSessions
Permissions it needs: User.RevokeSessions.All, plus User.Read.All to look up the user
Action: Delete the user's MFA methods, including the attacker's
API: DELETE /users/{id}/authentication/{type}Methods/{methodId} for each phone, Authenticator app, software OATH, FIDO2, Windows Hello, and Temporary Access Pass method
Permissions it needs: UserAuthenticationMethod.ReadWrite.All, plus User.Read.All
Google Workspace
Action: End web and device sessions, and revoke the app's OAuth tokens
API: POST /admin/directory/v1/users/{userKey}/signOut, DELETE /admin/directory/v1/users/{userKey}/tokens/{clientId}
Permissions it needs: admin.directory.user.security scope, plus a delegated admin role
GitHub Enterprise Cloud, orglevel SAML SSO
Action: Delete the stolen token from the organization
API: GET /orgs/{org}/credential-authorizations?login= {user} to find it, then DELETE /orgs/{org}/credentialauthorizations/{credential_id}
Permissions it needs: Org owner with admin:org, or a GitHub App with org Administration (write). There's no narrower option
Snowflake
Action: Disable a programmatic access token
API: Your own SQL, such as ALTER USER {name} MODIFY PAT {token} SET DISABLED TRUE, sent through the SQL API POST /api/v2/statements)
Permissions it needs: A dedicated service user whose role has MODIFY PROGRAMMATIC AUTHENTICATION METHODS on the user
AWS
Action: End the STS sessions already issued to an IAM user
API: PutUserPolicy with an inline deny on sessions issued before now (aws:TokenIssueTime)
Permissions it needs: iam:PutUserPolicy, plus iam:GetUser and iam:GetUserPolicy
Anthropic
Action: Deactivate an API key
API: POST /v1/organizations/api_keys/{id} with {"status":"inactive"}
Permissions it needs: Admin API key
How Exaforce handled these attacks
Exaforce is an Agentic SOC platform with an optional MDR service. Our agents Exabots) handle detection engineering, alert triage, investigations, threat hunting, and response. The agents work on a unified data platform that can act as your SIEM or work alongside your SIEM.
The platform comes with 800 AI/ML anomaly detections that help detect the types of incidents we described across critical Cloud, SaaS, Identity, Endpoint, and AI services. There are 100+ dynamic response actions that agents can execute, so you don't have to build and maintain them yourselves for all your critical services.
You can read about more similar incidents under our ExaFiles research blogs here.
Sponsored and written by Exaforce.