How Attackers Steal Developer Tokens, Hijack MFA Sessions and Exfiltrate Data in Minutes

TL;DR: Attackers are enumerating systems or retrieving data within 15 minutes of entering an environment. Security tools intended to detect these attacks can be ineffective when they lack visibility into token usage, endpoint activity or cross-application identity behavior. This analysis examines three common attack patterns and explains why autonomous response is needed to contain them quickly.

• Stolen developer token: A poisoned npm package and information stealer extract GitHub tokens from a developer’s laptop. Attackers later use those tokens to access repositories and steal data. GitHub has no native capability to monitor how these tokens are used, leaving organizations vulnerable to code leaks.
• ClickFix lure targeting AI tools: A fake Claude Code installation command posted in a shared Claude conversation loads a macOS stealer that retrieves browser cookies and cloud credentials. Because the victim executes the command, the activity may not trigger endpoint detection.
• Help desk social engineering: Attackers impersonate IT staff and convince employees to approve a legitimate MFA prompt on a lookalike sign-in page. Because the login may appear legitimate to the identity provider, the attack can be difficult to detect.

Detecting these incidents requires data- and behavior-based detection. Stopping them requires an autonomous response that can quickly revoke sessions, remove attacker-controlled authentication methods and disable compromised credentials.

Attackers can exploit dormant GitHub tokens within minutes

In March, a developer installed GitHub Desktop, signed in and stopped using it the same day. The resulting OAuth token was stored in the Mac’s keychain for 95 days. On June 19, another person began using the token.

The token was used to pull 76 repositories in approximately 15 seconds through residential proxies located in more than 20 European cities. GitHub did not generate an alert because it does not provide native visibility into how these tokens are used. The Exaforce platform flagged the activity within five minutes and triaged it within 10 minutes.

Exaforce MDR analysts confirmed the breach and notified the customer minutes after detection. However, by the time action was taken, the attackers had exfiltrated data from 472 of the organization’s 638 repositories.

This case demonstrates both sides of the problem. Without anomaly detection, no one would have known that the token was being used. With detection in place, containment still required human approval, giving the attackers enough time to exfiltrate data.

Sleeper tokens on developer laptops

GitHub’s security features focus on inspecting code and secrets rather than identifying malicious use of tokens. The GitHub token compromise analysis describes how several weak signals can reveal suspicious activity within a single GitHub session.

In this case, the account was accessed from a network and city it had never previously used. The account had only been used with macOS, but the attacker pulled ZIP archives at machine speed using a Windows user agent. Each signal could have had an innocent explanation individually, but the combined behavior indicated malicious activity.

GitHub OAuth app tokens are prefixed with Go_. They do not have an expiration date, and GitHub independently revokes them only after one year. In our test, the organization’s SSO page did not list these tokens; they were visible only through the command-line interface. Disabling a developer at the identity provider does not terminate the token.

Without SCIM, GitHub continues to honor the token until someone revokes it or removes the user from the organization.

Developers using AI coding tools install npm packages and connect to MCP servers throughout the day. Worms such as Shai-Hulud can search machines for GitHub and cloud tokens as soon as a tainted package is installed, often outside pipelines monitored by security teams.

This activity can occur before anything is committed, so scanning the repository alone may not reveal that a compromised npm package was responsible.

ClickFix attacks use fake AI-tool installation instructions

Stealing tokens from the macOS Keychain typically requires an information stealer capable of phishing login passwords.

The latest ClickFix lures exploit trust in AI tools. In one incident, an employee searching for Claude Code installation instructions reached a shared Claude conversation that contained a one-line installation command.

Executing the command installed a macOS stealer. As described in this detailed analysis, the malware spoofed password prompts in System Preferences and copied keychains, browser cookies, saved passwords and cloud credentials.

Email filtering and download controls can be bypassed because the victim executes the command directly. Endpoint detection is therefore one of the most effective ways to identify this type of attack. Organizations also need a comprehensive analysis of all user-created tokens and credentials to determine the scope of impact.

Fake IT calls can end with a stolen session

In a malicious case investigated this year, an attacker registered their own MFA device and initiated a bulk-download script 2.5 to 7 minutes after the victim approved an MFA push. In one case, the attackers leaked 140,000 files and demanded a ransom for the stolen data.

These calls often follow help desk social-engineering scripts associated with the Scattered Spider group. Callers impersonating IT staff direct employees to sign-in pages that include the company name in the URL, such as the passkey-themed contoso.add-passkey[.] domain described in Microsoft’s September article.

The page either relays the login through an adversary-in-the-middle (AiTM) proxy or tricks the victim into completing a device-code sign-in.

The disassembled kit hosted on oskeysetup[.]com was built from scratch. As a result, detections designed for Evilginx and other publicly available kits would not be effective.

Identity-provider detection was ineffective because the victim approved the legitimate MFA prompt. During a July session-hijacking incident, Microsoft flagged the attacker’s initial sign-in as risky, then marked the risk as resolved after the user completed MFA. Within minutes, stolen tokens were regenerated from two other countries within one second, and a subsequent Microsoft warning raised the risk level for users.

Exaforce detected the incident by correlating Okta and Microsoft sign-ins with the user’s historical activity. It was the account’s first sign-in from the United States, from a Linux device and through a home ISP the user had never used. In these cases, one of the earliest strong signals is often a new MFA method registered from a device or network the user has never accessed.

Attackers were also observed targeting the same company through multiple employees, often using the same servers and domains.

Why autonomous response is needed

An effective way to address these incidents is to use autonomous response. Automated response is not new, but organizations have traditionally been concerned that an incorrect action could lock out executives or disrupt production integrations.

A more useful approach is to categorize response actions by friction: how much damage an incorrect action could cause to the credential owner. Actions such as canceling sessions, removing MFA methods registered during a flagged session and deactivating keys that can be re-enabled are relatively low-friction. They can produce reliable results while still allowing the user to sign in again or re-register a phone.

Password resets, account deactivations, permanent deletions and actions affecting operational services should require human approval. The user and their manager can confirm with a simple message whether the sign-in was legitimate.

Response actions cannot be limited to the identity provider. Resetting an Okta password or terminating an Okta session does not revoke tokens already issued by Microsoft 365, Google Workspace or GitHub. AWS and Snowflake sessions initiated through SSO may also continue running.

In severe cases, the data breach continued for 44 minutes to three hours after the user’s identity-provider session was canceled. In one case, the attacker’s inbox rules persisted even after a password reset. Okta’s universal logout reaches some applications, including Google Workspace and Slack, but not GitHub, Snowflake or AI model providers.

Organizations should pre-build an undo action for each application and identify the account that will perform it. Response actions have failed during 403 errors because the required permissions were not granted in advance.

Creating responses for every data source can be daunting. Start with the services that contain the organization’s most important data:

• Productivity: Google Workspace, Microsoft 365, Box, Dropbox and Slack
• Cloud: AWS, Google Cloud and Azure
• AI services: Human and OpenAI
• Data: Snowflake and Databricks
• Code: GitHub and GitLab

Recommended low-friction response actions

The following response actions and API requirements can help organizations prepare for identity and token compromise.

Okta

Action: Revoke sessions and OAuth tokens issued by Okta
API: DELETE /api/v1/users/{id}/sessions?oauthTokens=true
Required permissions: A custom admin role with the okta.users.read and okta.users.manage scopes, plus okta.users.read and okta.users.lifecycle.clearSessions

Action: Reset all user factors, including attacker-controlled factors
API: POST /api/v1/users/{id}/lifecycle/reset_factors
Required permissions: Add okta.users.credentials.resetFactors to the role

Microsoft Entra ID

Action: Revoke refresh tokens and session cookies
API: POST /users/{id}/revokeSignInSessions
Required permissions: User.RevokeSessions.All and User.Read.All to search for users

Action: Remove the user’s MFA methods, including attacker-controlled methods
API: DELETE /users/{id}/authentication/{type}Methods/{methodId} for each phone, Authenticator app, software OATH, FIDO2, Windows Hello and temporary access pass method
Required permissions: UserAuthenticationMethod.ReadWrite.All and User.Read.All

Google Workspace

Action: Terminate web and device sessions and revoke OAuth tokens for your app
API: POST /admin/directory/v1/users/{userKey}/signOut and DELETE /admin/directory/v1/users/{userKey}/tokens/{clientId}
Required permissions: admin.directory.user.security scope and delegated administrator roles

GitHub Enterprise Cloud with organization-level SAML SSO

Action: Remove stolen tokens from the organization
API: Retrieve and find /orgs/{org}/credential-authorizations?login={user}, then use DELETE /orgs/{org}/credentialauthorizations/{credential_id}
Required permissions: An organization owner with admin:org or a GitHub App with organization-management write access. There are no narrower options.

Snowflake

Action: Disable access tokens programmatically
API: Use SQL such as ALTER USER {name} MODIFY PAT {token} SET DISABLED TRUE, sent through the SQL API using POST /api/v2/statements
Required permissions: A dedicated service user with the MODIFY PROGRAMMATIC AUTHENTICATION METHODS role for users

AWS

Action: Terminate an STS session already issued to an IAM user
API: Use PutUserPolicy with an aws:TokenIssueTime inline denial for sessions issued so far
Required permissions: iam:PutUserPolicy, iam:GetUser and iam:GetUserPolicy

Human

Action: Deactivate an API key
API: POST /v1/organizations/api_keys/{id} with {"status":"inactive"}
Required permissions: Admin API key

How Exaforce responds to identity and token attacks

Exaforce is an Agent SOC platform with optional MDR services. Its agents, called Exabots, handle detection engineering, alert triage, investigation, threat hunting and response. The agents run on a unified data platform that can function as a SIEM or work alongside an existing SIEM.

The platform includes 800 AI/ML anomaly detections designed to identify incidents across critical cloud, SaaS, identity, endpoint and AI services. It also includes more than 100 dynamic response actions that agents can perform, reducing the need to build and maintain individual actions for every important service.

Read more related incident research on the ExaFiles research blog.

Sponsored and written by Exaforce.