OAuth Token Leaks on GitHub and Dark Web: Detection Guide

Introduction

In early 2025, a Fortune 500 SaaS company suffered a catastrophic account takeover when an OAuth token for a privileged service account was discovered exposed in a public GitHub repository. The token, left behind by a developer in a configuration file push, had been active for 47 days. During that window, threat actors who discovered the leak via automated GitHub scanning used the token to pivot through the victim's Google Workspace, exfiltrating hundreds of gigabytes of customer data from Google Drive and BigQuery. This incident — one of dozens documented by security firms in the past 18 months — underscores why credential leak detection for OAuth tokens is no longer optional for engineering and security teams. This guide walks through how OAuth tokens leak, where to find them on the dark web and public code repositories, and the specific detection methods available to stop credential exposure before it leads to a breach.

This article is written for DevSecOps engineers, SOC analysts, identity and access management (IAM) teams, and CISOs who need a practical, technically grounded understanding of OAuth token leakage. It answers the question: How do you detect exposed OAuth tokens in the wild, and what tools and processes enable effective response?

How OAuth Tokens Leak: Public Repositories and Dark Markets

OAuth tokens — short-lived credentials issued by identity providers like Google, Microsoft, GitHub, and Okta — are designed to grant scoped access to APIs and cloud resources without requiring user passwords. But their convenience creates a dangerous attack surface. When tokens leak, they function as a complete authentication bypass, granting threat actors access to the same APIs, data, and infrastructure the intended application had.

What exactly is an OAuth token leak, and how is it different from a password leak?

An OAuth token leak is the unauthorised exposure of an access token, refresh token, or service account credential that authenticates and authorises API calls. Unlike password leaks, which require attackers to authenticate through an identity provider (often triggering MFA alerts), leaked OAuth tokens grant direct, credential-free access to protected resources — frequently without any second-factor verification.

• Hardcoded tokens in source code: Developers frequently embed OAuth tokens directly in application code, configuration files, environment variable stubs, or Dockerfiles. When pushed to public GitHub, GitLab, or Bitbucket repositories, these tokens are immediately discoverable by automated security scanners — both legitimate and malicious.
• Exposed CI/CD pipeline variables: Continuous integration platforms like GitHub Actions, Jenkins, CircleCI, and GitLab CI store OAuth tokens as pipeline secrets. Misconfigured pipeline logs or improperly scoped environment variables can expose tokens in plain text within build output, which attackers harvest using credential scanning infrastructure.
• Infostealer log exfiltration: Malware families such as RedLine Stealer, Vidar, Lumma Stealer, and META Stealer actively target browser credential stores where OAuth tokens from Google, Microsoft, GitHub, Salesforce, and other SaaS platforms reside. Stolen tokens are packaged into logs and sold on dark web markets like Russian Market, 2easy Market, and Telegram channels.
• Combo list aggregation: Threat actors compile leaked OAuth tokens into structured lists for automated credential abuse. These combo lists — often sold alongside traditional password dumps — allow attackers to test tokens against supported APIs without additional verification.

According to the SpyCloud Annual Identity Exposure Report 2024, more than 40% of all exposed credentials discovered in the past year came from infostealer-infected devices, and GitHub is the single largest source of hardcoded secrets discovered in public code repositories.

Detection Approaches: GitHub and Dark Web Monitoring

Detecting leaked OAuth tokens requires a dual approach: scanning public code repositories for hardcoded secrets, and monitoring the dark web for credential exposure from infostealer logs and combo lists. Each approach covers a different leak vector, and security teams need both.

How do you scan GitHub for leaked OAuth tokens?

GitHub secret scanning is the first line of defence. You configure webhook-based alerting on your organisation's repositories, and use push protection to block commits containing high-confidence patterns for known token formats. But GitHub's built-in scanning only covers first-party patterns (such as GitHub Personal Access Tokens and OAuth App tokens) and a limited set of third-party patterns. For comprehensive coverage of all OAuth token types — including Google service account keys, Okta API tokens, Salesforce OAuth tokens, AWS IAM keys used for OAuth flows, and custom enterprise tokens — you need external scanning.

• Regex-based scanning with GitLeaks, truffleHog, or custom rules: Open-source tools like GitLeaks and truffleHog scan repository history — not just the latest commit — for entropy-based token patterns. Custom regex rules extend coverage to proprietary token formats used by your organisation's identity provider.
• Continuous scanning via CI/CD pipeline integration: Integrate secret scanning tools into every CI/CD pipeline step so that commits containing tokens are blocked before reaching the remote repository. This is the highest-fidelity detection point, because tokens are caught before they become visible to the public.
• Historical repository scanning: Even with push protection in place, tokens may already exist in past commits. Pull the complete history of public and private repositories (where access is granted) and run a full retrospective scan. Any discovered tokens must be considered compromised and rotated immediately.

Dark Web Monitoring for Compromised OAuth Tokens

While public repository scanning catches tokens leaked accidentally by developers, dark web monitoring identifies tokens stolen by infostealer malware and sold on credential markets. These tokens are often packaged alongside session cookies, browser credentials, cryptocurrency wallet keys, and VPN configurations. Monitoring these sources requires continuous ingestion of stealer logs, forum posts, and marketplace listings.

What dark web sources should you monitor for OAuth token leaks?

Credential leak detection for OAuth tokens must cover three primary dark web data types: infostealer logs from major monitoring sources, combo lists aggregated from multiple breaches, and forum or marketplace listings offering specific token types. Each source requires different monitoring infrastructure.

• Infostealer log streams: Threat actors operating malware families like RedLine Stealer and Lumma Stealer sell raw exfiltration logs containing browser-saved credentials, including OAuth tokens. These logs are posted on marketplaces like Russian Market and 2easy Market, as well as Telegram channels. A credential leak detection platform must ingest these logs, parse token structures, and match them against monitored domains and cloud tenants.
• Combo list feeds: Attackers aggregate stolen credentials into structured comma-separated files (email:token) for automated abuse. These combo lists circulate on Exploit.in, BreachForums successors, and RAMP. Monitoring these feeds requires extracting OAuth-specific token patterns from lists that may also include passwords, session cookies, and API keys.
• Telegram and forum chatter: Initial access brokers (IABs) and affiliate marketers frequently post sample tokens on Telegram channels and dark web forums to validate the quality of their logs. Credential leak monitoring must scan these unstructured text sources for patterns matching your organisation's tenant IDs, service principal names, or OAuth app client IDs.

The IBM Cost of a Data Breach Report 2024 found that breaches involving compromised credentials — including OAuth tokens and API keys — were the most common attack vector, accounting for 16% of all breaches, with an average total cost of $4.81 million per incident.

How to Detect Leaked OAuth Tokens: Step-by-Step

1. Step 1: Map your OAuth token inventory and classify token sensitivity

   Before you can detect leaked tokens, you need to know what tokens exist. Inventory every OAuth client ID, service account, and application registration in your identity provider. Classify tokens by scope: tokens with broad permissions (e.g., scopes like admin.googleapis.com, File.Read.All, or customer.management) are critical; tokens with read-only user-scoped access are lower risk. Document the token type for each: access token, refresh token, service account key (JSON or P12), or JWT bearer token. This classification drives the detection priority and rotation urgency.

2. Step 2: Configure GitHub secret scanning with custom patterns

   Enable GitHub secret scanning for all organisation repositories. In GitHub's settings, add custom patterns for your identity provider's token format. For example, if you use Google Workspace service accounts, add a pattern that matches the service_account field in JSON key files. For Okta API tokens, add a regex matching the format 00... followed by a 40-character base64 string. Configure push protection to block commits matching these patterns — this prevents tokens from reaching the remote repository. For GitLab and Bitbucket, enable equivalent native secret scanning or use a third-party integration.

3. Step 3: Deploy historical repository scanning

   Clone all organisation repositories to a secure scanning environment. Run truffleHog with the --include-strings flag for your custom token patterns, and use GitLeaks for entropy-based scanning against the full commit history. Export results to a central security information and event management (SIEM) or case management platform. For any discovered tokens, flag the commit, notify the developer who pushed it, and initiate token rotation within the identity provider. Do not assume that old tokens are irrelevant — many refresh tokens have long lifetimes or are never revoked.

4. Step 4: Subscribe to a credential leak detection platform with dark web coverage

   Enable credential leak detection that ingests infostealer logs and combo list feeds. Configure the platform to monitor for your organisation's primary domain, all subdomains, and any tenant IDs or OAuth app client IDs. When a stealer log containing a token matching your monitored scope is published, the platform should extract the token value, validate it against your identity provider's token introspection endpoint (if available), and alert your SOC with severity scoring based on token scope and age. This automated detection is the only way to identify tokens stolen by infostealer malware before attackers use them.

5. Step 5: Implement automated token revocation workflows

   When a leaked OAuth token is detected, the response must be measured in minutes, not days. Build automated playbooks that: (a) revoke the compromised token via the identity provider's API, (b) rotate the associated client secret or service account key, (c) notify the resource owner and security team, and (d) block the compromised token in any existing session stores or caches. For critical tokens — those with admin scopes or access to sensitive data — consider automatic revocation without human approval. Integrate the credential leak detection platform with your SOAR tool (like Splunk Phantom or Palo Alto Cortex XSOAR) to trigger these workflows.

Credential Leak Detection vs. Traditional Secret Management

Many organisations assume that adopting a secrets manager — whether AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault — eliminates the risk of OAuth token leaks. This is a dangerous misconception. Secrets managers prevent tokens from being hardcoded in source code by providing runtime access to secrets, but they do not prevent developers from extracting tokens and embedding them elsewhere. A developer can still copy a token from a secrets manager into a configuration file, a local script, a CI/CD pipeline, or even a support ticket.

What is the difference between credential leak detection for OAuth tokens and classic secret management?

Secret management controls access to tokens at the point of storage and retrieval, while credential leak detection focuses on identifying tokens that have already been exposed outside approved systems. Both are necessary, but they address different phases of the threat landscape. Secret management is preventive; credential leak detection is detective and responsive. Without detection, preventive controls have no feedback loop to identify when they have been bypassed.

A CISA advisory from late 2024 noted that threat actors increasingly target OAuth applications and service principals as a persistence mechanism once they gain initial access, because OAuth tokens often outlive user account compromise detection.

How DarkThreat.AI Approaches OAuth Token Leak Detection

DarkThreat.AI's credential leak detection solution delivers continuous monitoring across both GitHub and dark web sources specifically for OAuth tokens and other non-password credentials. The platform ingests stealer logs from high-volume marketplaces and Telegram channels, parsing them for token structures matching your organisation's identity provider and cloud tenants. When a token is found, DarkThreat.AI applies severity scoring based on token scope, age, and the sensitivity of the associated resource. Alerts integrate with SIEM platforms (including Splunk, Sentinel, and Elastic) and SOAR workflows to enable automated token revocation. For organisations with custom OAuth token formats, DarkThreat.AI supports regex-based custom patterns, ensuring coverage extends beyond stock token templates. The platform's domain-wide credential monitoring surfaces tokens associated with any employee or service account under your organisation's managed domains, providing the dedicated detection layer that secret managers cannot offer.

Related Resources

• What Is Credential Leak Detection? — Foundational overview of how credential leak detection works, including token exposure types and detection methodologies.
• Stealer Malware: Credential Theft and Detection — Deep dive into how infostealer families like RedLine and Vidar steal OAuth tokens and how to detect them.
• Combo Lists Explained: Monitoring and Response — Understand how stolen tokens are aggregated into combo lists and the monitoring approach for these feeds.
• Credential Leak Detection SIEM Integration — Technical guide to integrating leak detection alerts into your existing security operations pipeline.

Conclusion

OAuth token leaks represent a critical blind spot in many security programmes. Traditional secret management prevents tokens from being hardcoded but does nothing to catch tokens already exposed in public repositories or stolen by infostealer malware. Effective credential leak detection requires a two-pronged strategy: continuous scanning of GitHub and other code repositories with push protection and retrospective scanning, combined with dark web monitoring for stealer logs, combo lists, and forum posts targeting your organisation's OAuth tokens. Automated response workflows are essential to revoking compromised tokens before attackers weaponise them.

As identity-based attacks continue to dominate the threat landscape, credential leak detection will only become more critical. The organisations that invest in detection for OAuth tokens — rather than relying solely on preventive controls — are the ones that will stay ahead of initial access brokers and credential-harvesting campaigns. DarkThreat.AI provides the dedicated monitoring layer that turns leak detection from a manual reactive process into an automated, continuous defence. The next token that leaks could be the one that saves your next breach from turning into a disclosure.