Attackers Achieve Data Exfiltration Within Minutes of Initial Compromise, Underscoring Critical Gaps in Traditional Security Measures

Attackers are now demonstrating an alarming speed in data exfiltration, achieving significant data pulls within just 15 minutes of gaining initial access to an organization’s environment. This rapid timeline, coupled with the observed ineffectiveness of traditional security tools in detecting and stopping these intrusions, highlights a growing chasm in cybersecurity defenses. Analysis reveals three prevalent attack patterns where this accelerated exfiltration has been observed, underscoring the urgent need for detection capabilities built on nuanced data analysis and behavioral anomalies, and response mechanisms that are both swift and autonomous.

The stark reality is that conventional security perimeters and signature-based detection methods are proving insufficient against sophisticated, rapid-strike attacks. The speed at which attackers are operating suggests a significant shift in tactics, moving beyond slow, methodical lateral movement to swift, opportunistic data grabs. This necessitates a paradigm shift in how organizations approach threat detection and response, emphasizing proactive anomaly detection and the automation of containment actions.

The Rise of Sleeper Tokens and Accelerated Exploitation

One of the most concerning attack vectors involves the exploitation of seemingly dormant credentials, particularly OAuth tokens, which can lie undetected for extended periods before being weaponized. A recent case analyzed by security researchers vividly illustrates this threat. In March, a developer installed GitHub Desktop and authenticated with an OAuth token. While the developer ceased using the application the same day, the generated token remained embedded in the macOS keychain for a significant duration – 95 days. It wasn’t until June 19 that this dormant credential was activated by an unauthorized actor.

The speed of the subsequent compromise was astonishing. Within approximately 15 seconds, the attacker utilized the token to pull data from 76 repositories. This rapid exfiltration was facilitated through the use of residential proxies, strategically deployed across more than two dozen European cities, a tactic designed to obscure the attacker’s true origin and blend in with legitimate user traffic. Compounding the issue, GitHub’s native security features did not flag this activity, as they are primarily focused on code inspection and secret scanning, rather than the anomalous usage patterns of API tokens.

This incident was detected by the Exaforce platform within five minutes of the suspicious activity, with triage completed within 10 minutes. However, even with rapid detection, the time required for human review and approval of response actions proved to be a critical window for the attacker. By the time the customer was notified and containment measures could be initiated, the adversary had already exfiltrated data from a staggering 472 out of 638 targeted repositories. This case serves as a potent reminder that while anomaly detection is crucial for identifying compromises, the speed of response is equally vital to mitigate the extent of damage.

The Silent Threat of ‘Sleeper Tokens’ on Developer Laptops

The security posture of developer workstations and the credentials they manage represent a significant blind spot in many organizations’ defenses. OAuth tokens, such as those generated by GitHub (often prefixed with "gho_"), do not inherently expire and are typically only revoked by GitHub after a year of inactivity or upon explicit manual removal. Compounding this risk, these tokens are often not readily visible through standard Single Sign-On (SSO) interfaces, remaining discoverable primarily through command-line interfaces. Even disabling a developer account within an identity provider (IdP) does not automatically invalidate these pre-existing tokens, especially in the absence of automated provisioning and deprovisioning mechanisms like SCIM (System for Cross-domain Identity Management).

This vulnerability is exacerbated by the increasing reliance on AI coding tools. Developers frequently install new npm packages and connect to various servers, often outside the purview of formal security pipelines. This creates an opportune environment for malicious code embedded within these packages, such as the "Shai-Hulud" worm, to actively scan a compromised machine for sensitive tokens, including those for GitHub and cloud services, immediately upon installation. This occurs before any code is committed, rendering repository scanning as a post-compromise mitigation strategy insufficient. The risk extends beyond code repositories, with attackers targeting cloud credentials and other sensitive authentication mechanisms.

ClickFix Exploits Trust in AI Tools for Credential Theft

A new wave of phishing and social engineering tactics is leveraging the trust placed in AI tools to facilitate credential theft. In one observed scenario, an employee searching for installation instructions for the Claude Code AI tool encountered what appeared to be a legitimate shared conversation containing a single-line installation command. However, this command was a sophisticated lure designed to deploy a macOS infostealer – a type of malware that Exaforce has extensively analyzed and documented.

Upon execution, this malicious command would prompt the user with a fake System Preferences dialog, soliciting their login password. Once obtained, the infostealer would proceed to exfiltrate sensitive data, including the contents of the macOS keychain, browser cookies, saved passwords, and cloud credentials. The effectiveness of this attack lies in its ability to bypass traditional security controls like email filtering and download restrictions, as the victim willingly executes the malicious command. The primary defense against such sophisticated attacks is robust endpoint detection and response (EDR) solutions capable of identifying anomalous process behavior and unauthorized access to sensitive system data. A comprehensive analysis of all tokens and credentials issued to the affected user is crucial for assessing the full scope of the breach.

Vishing Campaigns Leverage Fake IT Support for Session Hijacking

Voice phishing (vishing) attacks continue to evolve, with attackers increasingly employing elaborate social engineering schemes to gain access to user accounts and facilitate rapid data exfiltration. In several cases investigated this year, attackers successfully registered their own multi-factor authentication (MFA) devices. Within minutes of a victim approving a legitimate-looking push notification, the attackers initiated bulk download scripts. In one particularly egregious instance, an attacker exfiltrated 140,000 files before demanding a ransom for the leaked data.

These vishing operations often mimic the playbook of known threat actor groups, such as Scattered Spider, by posing as IT support personnel. Attackers guide victims to convincing phishing pages that bear the company’s branding and often feature domain names designed to appear legitimate, such as "contoso.add-passkey[.]com." These pages are typically equipped with Adversary-in-the-Middle (AiTM) proxies or guide the victim through a device-code sign-in process, effectively relaying credentials and MFA approvals to the attacker in real-time.

The sophistication of these AiTM kits is also increasing. Security researchers have analyzed custom-built infrastructure designed from the ground up, rendering traditional detection methods tuned for known kits like Evilginx ineffective. Furthermore, identity provider (IdP) alerts can often be misleading. In one observed session hijacking, Microsoft initially flagged an attacker’s sign-in as risky but subsequently marked the risk as remediated once the user successfully passed MFA. Within seconds, the stolen session was replayed from multiple geographic locations, and only then did subsequent alerts reflect the true level of risk. Exaforce’s detection in such scenarios relies on correlating disparate sign-in events – for example, an Okta login followed by a Microsoft sign-in – and comparing them against a user’s historical activity. Anomalies such as the first-ever sign-in from an unusual country, on an unfamiliar device type, or via an uncharacteristic network provider, serve as strong indicators of compromise. Often, the earliest definitive signal of a compromised session is the registration of a new MFA method from an unfamiliar device and network. A common tactic observed is attackers targeting multiple employees within the same organization, often reusing the same infrastructure and domains to maintain operational efficiency.

The Imperative of Autonomous Response Actions

The rapid and sophisticated nature of these attacks necessitates a fundamental shift towards autonomous response capabilities. While the concept of automating security responses is not new, organizations have historically hesitated due to concerns about the potential fallout from erroneous actions, such as locking out critical executives or disrupting essential business operations. However, the escalating speed of threat actors compels a re-evaluation of this approach.

A more effective strategy involves categorizing response actions based on their "friction level" – the degree of disruption or inconvenience a mistaken action would cause to the credential owner. Low-friction actions, such as revoking active sessions, removing newly registered MFA methods, or temporarily deactivating non-critical keys, can be automated to trigger immediately upon high-confidence threat detections. These actions are reversible and cause minimal disruption, allowing for swift containment without requiring immediate human intervention.

Conversely, high-friction actions, including password resets, account disablement, permanent data deletion, or any action impacting production services, should continue to require human approval. This approval process can be streamlined by involving the affected user and their manager, who can quickly confirm whether the suspicious activity was indeed unauthorized.

Crucially, automated responses cannot be confined solely to the identity provider. Revoking a user’s Okta session, for instance, does not automatically invalidate tokens issued by other critical services like Microsoft 365, Google Workspace, or GitHub. Similarly, active AWS or Snowflake sessions initiated via SSO may persist even after the IdP session is terminated. The analysis of vishing cases revealed that data exfiltration often continued for up to three hours after an IdP session was revoked, and in one instance, an attacker’s inbox rules remained active even after a password reset. While some universal logout solutions exist, their coverage is often incomplete, failing to encompass all critical applications and services.

To address this, organizations should proactively define and pre-configure revocation actions for each critical application and the associated service accounts required to execute them. Failure to adequately provision permissions for these automated response actions can lead to their failure mid-incident, rendering them ineffective. A pragmatic approach is to prioritize the implementation of automated responses for services that house the organization’s most sensitive data.

Recommended Low-Friction Autonomous Response Actions and Implementation

To facilitate the adoption of autonomous response, a tiered approach to implementing low-friction actions across key platforms is recommended:

Okta

• Action: Revoke active sessions and associated OAuth tokens.
  • API Endpoint: DELETE /api/v1/users/id/sessions?oauthTokens=true
  • Required Permissions: okta.users.read, okta.users.manage scopes, and a custom admin role with okta.users.read and okta.users.lifecycle.clearSessions.
• Action: Reset all user factors, including those registered by the attacker.
  • API Endpoint: POST /api/v1/users/id/lifecycle/reset_factors
  • Required Permissions: Same scopes as above, with the addition of okta.users.credentials.resetFactors.

Microsoft Entra ID (formerly Azure AD)

• Action: Revoke all active refresh tokens and session cookies.
  • API Endpoint: POST /users/id/revokeSignInSessions
  • Required Permissions: User.RevokeSessions.All, and User.Read.All for user lookup.
• Action: Delete all user MFA methods, including those provisioned by the attacker.
  • API Endpoint: DELETE /users/id/authentication/typeMethods/methodId (for each MFA type: phone, Authenticator app, software OATH, FIDO2, Windows Hello, Temporary Access Pass).
  • Required Permissions: UserAuthenticationMethod.ReadWrite.All, and User.Read.All.

Google Workspace

• Action: Terminate all active web and device sessions, and revoke associated OAuth tokens.
  • API Endpoints: POST /admin/directory/v1/users/userKey/signOut and DELETE /admin/directory/v1/users/userKey/tokens/clientId.
  • Required Permissions: admin.directory.user.security scope, and a delegated administrator role.

GitHub Enterprise Cloud (with organization-level SAML SSO)

• Action: Remove unauthorized OAuth tokens from the organization.
  • API Endpoints: GET /orgs/org/credential-authorizations?login= user to identify the token, followed by DELETE /orgs/org/credentialauthorizations/credential_id.
  • Required Permissions: Organization owner with admin:org scope, or a GitHub App with organization Administration (write) permissions.

Snowflake

• Action: Disable compromised programmatic access tokens (PATs).
  • API: Executed via SQL API POST /api/v2/statements) using SQL commands like ALTER USER name MODIFY PAT token SET DISABLED TRUE.
  • Required Permissions: A dedicated service user with a role possessing MODIFY PROGRAMMATIC AUTHENTICATION METHODS privilege on the target user.

AWS

• Action: Terminate all active STS sessions issued to an IAM user.
  • API: Utilize PutUserPolicy with an inline deny statement on sessions issued before the current time (aws:TokenIssueTime).
  • Required Permissions: iam:PutUserPolicy, iam:GetUser, and iam:GetUserPolicy.

Anthropic (for AI models)

• Action: Deactivate compromised API keys.
  • API Endpoint: POST /v1/organizations/api_keys/id with "status":"inactive".
  • Required Permissions: An administrative API key.

Exaforce’s Agentic SOC Platform Approach

Exaforce operates as an Agentic Security Operations Center (SOC) platform, offering an optional Managed Detection and Response (MDR) service. Its core architecture is powered by Exabots, AI-driven agents responsible for a comprehensive suite of security functions, including detection engineering, alert triage, in-depth investigations, proactive threat hunting, and automated response actions. These agents function atop a unified data platform that can serve as a standalone Security Information and Event Management (SIEM) solution or integrate seamlessly with existing SIEM infrastructure.

The platform boasts over 800 AI/ML-powered anomaly detections, specifically designed to identify the types of sophisticated threats detailed in this analysis across critical domains such as Cloud, SaaS, Identity, Endpoint, and AI services. Furthermore, Exaforce provides more than 100 dynamic response actions that its agents can autonomously execute, alleviating the burden on security teams to manually build and maintain response playbooks for every critical service.

Organizations seeking further insights into similar security incidents and advanced threat research can explore Exaforce’s extensive ExaFiles research blogs.

Sponsored and written by Exaforce.