Organizations increasingly rely on GitHub to develop and store proprietary source code, internal documentation, and other software assets. This makes GitHub Personal Access Tokens (PATs) an attractive target for attackers, as a compromised token can provide access to private repositories and expose secrets such as cloud credentials, API keys, and private keys that may enable further compromise.
Recently, the Wiz Customer Incident Response Team (CIRT) investigated a coordinated campaign in which compromised GitHub PATs were used to conduct repository reconnaissance and mass repository exfiltration across multiple organizations. Active from mid-May through early June 2026, the campaign progressed through several distinct stages, from reconnaissance and access validation to large-scale repository cloning and follow-on attempts to leverage exfiltrated credentials.
In this blog, we walk through a practical approach to investigating GitHub PAT compromise. Using a real-world campaign investigated by Wiz CIRT as an example (Wiz customers can see the Threat Intel Center advisory for campaign details and IOCs), we demonstrate how to reconstruct the attack timeline, identify the full blast radius, and hunt for follow-on activity.
First Investigation Lead: Mass Repository Cloning
For most impacted organizations, the observable indication of the campaign was a significant increase in git.clone activity on June 1, as seen in GitHub Audit Logs. Between 09:14 and 14:55 UTC, the actor used 102 AWS IP addresses located in the ca-central-1 region to clone up to thousands of repositories per organization. The activity used the git/2.43.0 user agent and was highly parallelized, indicating automated tooling.
The cloning operations were performed using valid PATs belonging to employees of the affected organizations.
Step 1: Contain the Compromised PAT
The first priority is to identify the PAT used in the cloning activity and prevent any unauthorized repository access using the compromised PAT.
Containment options depend on the type of PAT involved and the organization’s identity configuration:
Fine-grained PAT: Organization owners can view and revoke individual fine-grained PATs with access to organization resources. Revoking the token’s organization access does not necessarily delete the underlying token.
Classic PAT with SAML SSO: If SAML SSO is enforced, organizations can view PATs authorized to access the organization and revoke their SSO authorization. This removes the token’s access to SSO-protected organization resources but does not delete the underlying token.
Classic PAT without SAML SSO: Organization and enterprise owners generally do not have direct visibility into or control over individual classic PATs. The affected user can delete the token from their GitHub account. If responders know the actual token value, the token can also be revoked through GitHub’s REST API.
Enterprise Managed Users (EMU): Enterprises using Enterprise Managed Users can centrally delete a user’s tokens and other credentials. Based on Wiz CIRT’s experience, Enterprise Managed Users are less commonly deployed across GitHub environments.
Because organization owners may be unable to independently verify the revocation of a PAT or rule out the compromise of additional tokens associated with the user, the user should also be temporarily removed from the organization while the investigation continues.
Because a compromised PAT may indicate broader compromise of the user’s endpoint or other credential stores, responders should also consider restricting the user’s access to other sensitive systems and isolating potentially affected endpoints until the source and scope of the compromise have been determined.
Step 2: Expand the Investigation Timeline
The next step is to expand the investigation by reviewing GitHub activity associated with the compromised PATs.
Responders should first establish the user's normal activity patterns, using GitHub audit logs, including typical source IP addresses, geolocations, user agents, access times, and repository activity, and use this baseline to identify anomalous events associated with the compromised PAT or user.
Responders should also review the user’s personal GitHub security log, as it may contain relevant personal account events that are not recorded in the organization audit log. In EMU environments, equivalent user-level security events are available in the enterprise audit log. In non-EMU environments, organization owners generally cannot access a personal user’s security log directly, so the affected user may need to review or export this information for the investigation.
In parallel, pivot on any known indicators of compromise (IOCs), such as source IP addresses and user agents, to identify additional related activity that may not be associated with the compromised user.
In confirmed compromise scenarios, responders should also consider engaging GitHub Support and providing relevant details about the incident. Depending on the circumstances, GitHub may be able to provide additional logs that are not directly available to the organization, potentially offering further visibility into the compromise.
Wiz customers can use the following Wiz Cloud Events query to retrieve activity conducted by a compromised PAT in order to identify anomalies. Additionally, use the Activity tab in the GitHub user’s drawer to see additional queries that can help with baselining like “Source ASO for Resource” and “Events by Resource” over time.
In this investigation, this approach uncovered two earlier stages that preceded the mass cloning event.
Repository Reconnaissance
Prior to the mass clone, on May 15, the threat actor used the GitHub API to query the /repositories/{id}/readme endpoint from a single AWS IP address (13.221.167.217). Based on the AWS IP address documentation, this IP address is associated with the EC2 services and located in us-east-1. The requests originated from a standard Chrome browser user agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36).
These requests likely allowed the actor to collect information regarding accessible repositories and identify targets before performing any cloning activity.
One important observation is that these requests generate api.request events, which are available through GitHub Enterprise Log Streaming but are not included in standard GitHub audit logs. Organizations without Enterprise Log Streaming therefore do not have visibility into this reconnaissance activity.
Low-Volume Validation
Additional related activity occurred between May 29 and May 31. The same compromised PATs were used to perform a limited number of git.clone operations from 107.174.201.183 (HostPapa, US) using the git/2.25.1 user agent.
Unlike the June 1 activity, only a small subset of repositories was cloned. These cloning operations began within seconds of one another (approximately 05:42-05:44 UTC) across several different victims, suggesting automated tooling.
This activity appears to represent a validation phase.
At this stage, the investigation had reconstructed the following three phases of the campaign:
With the attack timeline reconstructed, the next objective was to determine what the attacker had actually obtained and assess the resulting blast radius.
Step 3: Identify the source of the leaked PAT
After expanding the timeline, the next step is determining how the compromised token was exposed. Identifying the source of the leaked PAT may reveal additional leaked credentials.
Common sources include endpoint compromise or plaintext secrets in cloud resources (e.g., hardcoded in code, configuration files, or environment variables).
Use the following Wiz Graph query to search for Secret Findings associated with the compromised hashed_token.
In this investigation, across all impacted organizations, the initial access vector was not identified. Our investigation did not identify the compromised tokens in code or cloud resources, and we found no evidence indicating that they were exposed through those environments.
The method by which the actor obtained valid PATs across multiple unrelated organizations therefore remains an open question. Given that the investigation did not identify a code or cloud-based source of exposure, and based on Wiz CIRT’s experience with credential theft, endpoint compromise is considered a possible initial access vector, although this could not be confirmed.
Step 4: Assess the Blast Radius
The next objective is to determine what the attacker obtained and assess the resulting blast radius.
Repository exfiltration should be treated as more than source code theft. Repositories frequently contain cloud credentials, SaaS tokens, internal documentation, private keys, and sensitive data that can significantly increase the impact of a compromise.
Investigators should account for GitHub’s audit-log retention limitations when assessing repository access. In GitHub Enterprise Cloud, Git events such as git.clone, git.fetch, and git.push are retained by GitHub for only seven days. If these events were not already streamed to an external system, such as Wiz, activity outside this retention window may no longer be available, potentially limiting the ability to establish the full scope of repository exfiltration.
To understand the full scope of the breach, use the GitHub audit logs to identify every repository the actor cloned. This serves as the foundation for the next steps - identifying any secrets and sensitive data exposed within those repositories.
Use the following Wiz Cloud Events query with any relevant IOCs (IPs, user agents, hashed tokens) to list all affected repositories. The search results can be extracted to a CSV to be used in the next steps.
Identify Exposed Secrets
Review the affected repositories for secrets that could provide access to additional systems, including cloud provider credentials, SaaS tokens, private keys, database credentials, CI/CD secrets, and internal service credentials.
Use the following Wiz Cloud Events query with any relevant IOCs (IPs, user agents, hashed tokens) to list all affected repositories. The search results can be exported to a CSV to be used in the next steps.
Use the Validation Status filter to identify secrets that are still valid by excluding any invalid secrets.
Filter by Secret Type and Severity based on your organization's concerns.
Group by Secret Data to identify unique secrets.
Any valid secret present within an exfiltrated repository should be treated as potentially compromised.
Identify Sensitive Data
Repositories may also contain regulated or business-sensitive information including PII, PHI, business confidential information, and financial information. Identifying such information helps determine the organization’s full exposure and assess whether regulatory notification or disclosure obligations may apply.
Use Wiz Data Findings with the repository Resource IDs from the CSV to determine which data may exist in these repositories:
Any credential present within an exfiltrated repository should be treated as potentially compromised.
Before rotating credentials, document each rotated credential, including the credential identifier, affected service and rotation time, as this information will be required during the next phase of the investigation.
Once the inventory has been established, rotate all exposed credentials as quickly as possible, including cloud provider credentials, SaaS API keys, GitHub tokens, private keys, certificates, database credentials, CI/CD credentials, and internal service accounts.
Step 6: Hunt for unauthorized use of leaked secrets
After collecting the list of exposed credentials, search for any unauthorized activity performed using those secrets prior to rotation.
This can help determine whether the actor moved beyond repository access into cloud or other environments. Hunt across all relevant services - cloud provider credentials (e.g., AWS, GCP, Azure), SaaS platform tokens (e.g., GitHub, GitLab), internal service credentials etc.
Example Wiz Cloud Events query that searches for activity associated with the leaked AWS access key and summarizes the results by user agent and IP address to help identify anomalous activity.
Conclusion
GitHub PAT compromise can escalate quickly - from initial reconnaissance to mass repository exfiltration and subsequent credential abuse across cloud environments. The investigation playbook outlined above - contain, expand the timeline, identify the leak source, assess blast radius, rotate credentials, and hunt for unauthorized use - provides a structured approach for responders to work through methodically under pressure.
A key challenge in investigating GitHub PAT compromise is that the evidence spans multiple disconnected systems - GitHub audit logs, cloud provider control planes, and code repositories. As demonstrated throughout this post, Wiz unifies these signals into a single investigation surface - from querying GitHub audit log activity and identifying exposed secrets across exfiltrated repositories, to hunting for unauthorized use of leaked credentials in cloud environments. This unified visibility reduces investigation time and minimizes the risk of missing follow-on activity that crosses from GitHub into cloud environments.
To improve detection and response for these types of attacks, Wiz recommends that organizations stream GitHub audit logs to Wiz, preferably enterprise-level audit logs, alongside cloud provider logs, to enable cross-platform threat correlation.
Correlating GitHub activity with cloud control-plane events makes it possible to trace an attacker's path from a compromised PAT through to unauthorized cloud access across the full attack chain.
Wiz Defend includes Threat Detection Rules (TDRs) that detect suspicious and malicious activity across GitHub environments. Some of these rules reflect techniques observed in this campaign, while others provide broader coverage for GitHub account, credential, and repository compromise. The following rules help organizations detect activity across different stages of GitHub-based attacks:
Rule Name
Rule ID
Mass Clone Operations Of Private Repositories Performed By User