Prep for Release 9.3 (#5548)

rules/integrations/github/defense_evasion_secret_scanning_disabled.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,37 @@ index = ["logs-github.audit-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "GitHub Secret Scanning Disabled"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating GitHub Secret Scanning Disabled
+
+This rule triggers when secret scanning is disabled on a repository, signaling an attempt to hide exposed tokens, keys, or passwords that can enable lateral movement, persistence, and data exfiltration. An attacker who gains admin or bot access may disable scanning, push a commit embedding plaintext credentials, and modify a workflow to export them via CI jobs, then use those secrets to authenticate to external services or cloud accounts and expand control.
+
+### Possible investigation steps
+
+- Identify the actor (user, bot, or GitHub App), their auth method and source IP, confirm admin privileges, and validate whether the change was planned and approved.
+- Immediately re-enable Secret Scanning and Push Protection on the repository and, if possible, enforce them via an organization policy, recording change control and justification.
+- Review commits, pull requests, and workflow file changes near the disable timestamp to detect added plaintext credentials, secret files, or code paths that read or export secrets.
+- Examine recent GitHub Actions runs, artifacts, and logs for secrets printed, unusual network egress, or jobs using elevated token scopes, and check for newly added or modified repo/org secrets.
+- Correlate IdP, cloud, and third-party service logs for authentication or API activity shortly after the disable event, revoking and rotating any credentials suspected to be exposed.
+
+### False positive analysis
+
+- A repository admin temporarily disables Secret Scanning during a planned maintenance or configuration test to address noisy detections or performance issues, then re-enables it, generating a benign disable event.
+- Organization-managed templates or automation enforce a settings baseline that disables Secret Scanning for non-code or ephemeral repos (e.g., mirrors, docs, or test sandboxes), causing the event as part of expected governance.
+
+### Response and remediation
+
+- Immediately re-enable Secret Scanning and Push Protection on the affected repository, lock the default branch with "Require pull request reviews" and "Restrict who can push," and temporarily pause GitHub Actions workflows that access repo or org secrets.
+- Revert or rewrite commits made while scanning was disabled to remove credentials from files like .env, config.yml, and .github/workflows/*.yml, and delete build artifacts and caches that may contain sensitive values.
+- Revoke and rotate exposed credentials by disabling compromised PATs, rotating cloud API keys and service tokens, and updating organization and repository secrets in Settings > Secrets and variables.
+- Validate recovery by confirming Secret Scanning and Push Protection are enabled in repository settings, re-running a full secret scan across HEAD, tags, and protected branches, and restoring merges and deployments only after clean results.
+- Escalate to incident response if the actor is unknown or unauthorized, if plaintext secrets appear in commits or workflow logs, or if external authentications use repo-linked credentials within 24 hours of the disable event.
+- Harden by enforcing org-wide policies requiring Secret Scanning and Push Protection for all repositories, adding repository rulesets to require status checks and pull request reviews before merging, and limiting Actions token permissions with protected environments and branch protections.
+"""
 references = [
     "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
     "https://trigger.dev/blog/shai-hulud-postmortem",
@@ -29,6 +60,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Defense Evasion",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/integrations/github/exfiltration_github_private_repository_turned_public.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,37 @@ index = ["logs-github.audit-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "GitHub Private Repository Turned Public"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating GitHub Private Repository Turned Public
+
+This rule flags when a previously private repository is made public, a high-risk change that can expose proprietary code, credentials, and internal documentation. Attackers who hijack a maintainer’s account often flip visibility via the UI or API, then immediately fork or mirror the repo to an external account to retain access and harvest embedded secrets even if the org reverts the change.
+
+### Possible investigation steps
+
+- Identify the actor and authentication method used for the visibility change, verify their repository role, and confirm the action against an approved change request or ticket.
+- Pull a time-bounded audit trail around the event for the actor and repository to surface related risky operations such as forking, transfers, collaborator additions, webhook edits, branch protection changes, or archive downloads.
+- Enumerate forks, mirrors, stars, and watchers added after the change via the repository network graph and correlate with external accounts or suspicious clusters.
+- Inspect GitHub Actions runs, deployments, and webhooks triggered post-change for workflows that export code or secrets to external destinations.
+- Perform rapid secret scanning across the repository history and HEAD, triage any exposed credentials, and initiate rotation while mapping impacted services and environments.
+
+### False positive analysis
+
+- A planned, approved open-source release where a maintainer intentionally flips a sanitized repository from private to public as part of a documented change.
+- Bulk visibility changes during an organization-wide cleanup or migration that publishes templates, sample repos, or empty scaffolds, executed by an authorized service account.
+
+### Response and remediation
+
+- Immediately revert the repository to private, remove outside collaborators, lock access to the core maintainers team, disable GitHub Actions and webhooks, and delete any release assets or packages published during the exposure window.
+- Enumerate new forks, mirrors, stars, and watchers created after the visibility change and file takedown requests with GitHub Trust & Safety for unauthorized public copies while removing any deploy keys and uninstalling suspicious GitHub App installations added around the event.
+- Run a rapid secret scan across the repository history and HEAD, rotate exposed credentials (cloud keys, API tokens, SSH keys), invalidate compromised service accounts, and purge cached artifacts or container images built from the public commit range.
+- Restore secure settings from baseline by re-applying branch protection rules, CODEOWNERS, required reviews, signed commits, and protected environments, then re-enable workflows only after reviewing job steps and outputs for any export of code or secrets.
+- Escalate to Security IR and Legal if the actor denies making the change, the repo network graph shows new public forks under unknown accounts, regulated data is present, or external users downloaded source zips or release archives during the public period.
+- Restrict who can change repository visibility to organization owners, enforce SSO and 2FA for maintainers, disable forking of private repositories, limit Actions to trusted runners and verified actions, and enable secret scanning with push protection across the organization.
+"""
 risk_score = 21
 rule_id = "8c707e4c-bd20-4ff4-bda5-4dc3b34ce298"
 severity = "low"
@@ -25,6 +56,7 @@ tags = [
     "Tactic: Exfiltration",
     "Tactic: Impact",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/integrations/github/exfiltration_high_number_of_cloning_by_user.toml

@@ -2,7 +2,7 @@
 creation_date = "2025/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ interval = "8m"
 language = "esql"
 license = "Elastic License v2"
 name = "GitHub Exfiltration via High Number of Repository Clones by User"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating GitHub Exfiltration via High Number of Repository Clones by User
+
+This rule flags a single user rapidly cloning dozens of repositories, a strong indicator of bulk source code exfiltration. Mass cloning enables quick siphoning of proprietary code, embedded secrets, and build artifacts across teams before defenses can respond. A typical pattern is a stolen personal access token used in a script to enumerate org repositories and clone them in rapid succession from a CI runner or cloud VM, including private and internal repos, to stage data for off-platform transfer.
+
+### Possible investigation steps
+
+- Validate whether the actor is a known automation or service account with a documented need to mass-clone, and quickly confirm intent with the account owner and affected repo admins.
+- Enumerate the cloned repositories and their visibility, deprioritizing activity dominated by public repos while fast-tracking private/internal codebases with sensitive content across orgs.
+- Pivot on the token identifier to determine the token owner, scopes, and creation/last-use details, compare to normal usage patterns, and revoke/reset credentials if anomalous.
+- Analyze the user agent and agent identifier to attribute the activity to a specific host or CI runner, correlating with pipeline logs and login locations/times for anomalies.
+- Correlate with endpoint/network telemetry from the originating host for large outbound transfers, external Git remotes, or bulk archiving indicating off-platform exfiltration following the clones.
+
+### False positive analysis
+
+- A developer rebuilding a workstation or creating an approved local mirror may legitimately clone dozens of repositories in a short window, especially when activity is dominated by public or low-sensitivity repos.
+- A shared automation/service account running scheduled builds or org-wide maintenance tasks can trigger fresh clones across many repositories due to pipeline configuration or cache resets, inflating counts without exfiltration intent.
+
+### Response and remediation
+
+- Immediately revoke the GitHub token used for the clones, force sign out, require password reset and 2FA re-verification for the user, and suspend the account if unauthorized.
+- Block and quarantine the originating host or CI runner by revoking its runner registration, removing its SSH keys/credentials, and firewalling its IP until imaged.
+- On the cloned private/internal repositories, remove the user from teams, rotate or disable deploy keys and GitHub App installations, and enforce SAML SSO.
+- Rotate repository and organization secrets present in those repos (Actions secrets, PATs, SSH keys, cloud access keys) and invalidate any secrets found in commit history.
+- Recover by restoring only minimal access after owner approval, issuing a new fine-grained PAT with least privilege and expiry, and re-enabling builds while monitoring for further clone bursts.
+- Escalate to incident response leadership and Legal if any private or export-controlled repos were cloned or cloning continues post-revocation, and harden by enforcing org-wide SSO, disallowing classic PATs, IP allowlisting for PAT use, enabling secret scanning with push protection, and alerting on burst git clone patterns from runners and unusual user agents.
+"""
 references = [
     "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
     "https://trigger.dev/blog/shai-hulud-postmortem",
@@ -28,6 +59,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Exfiltration",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/integrations/github/impact_high_number_of_closed_pull_requests_by_user.toml

@@ -2,7 +2,7 @@
 creation_date = "2025/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ interval = "8m"
 language = "esql"
 license = "Elastic License v2"
 name = "High Number of Closed Pull Requests by User"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating High Number of Closed Pull Requests by User
+
+This rule flags a single user rapidly closing many pull requests in a short window, a disruptive pattern that suppresses review history, delays releases, and masks unauthorized changes. An attacker with stolen maintainer access mass-closes pull requests across multiple repositories, then force-pushes branches and opens new pull requests that sidestep earlier review threads, making malicious edits appear routine amid churn.
+
+### Possible investigation steps
+
+- Determine if the actor is a bot or sanctioned maintenance by confirming account type, scheduled workflows, and change advisories from repo/org owners.
+- Open a sample of the closed PRs to review comments, labels, linked issues, and whether closure coincided with branch deletions, force-pushes, or unusual commit history in the target branches.
+- Correlate the closure burst with audit events for permission changes, role assignments, repository settings edits, or protection rule modifications to detect potential sabotage.
+- Validate the actor’s IPs, geolocation, and user agents against baselines and check for recent PAT creations, OAuth app grants, or SSO anomalies indicating credential theft.
+- Identify whether closed PRs were immediately replaced by new PRs carrying similar diffs that bypass prior review threads and required checks, and verify branch protection remained enforced.
+
+### False positive analysis
+
+- A maintainer or org-owned bot performs scheduled backlog hygiene, closing stale, duplicate, or superseded PRs across multiple repositories after a default branch rename or policy update, resulting in a high closure count from one account.
+- During a planned migration or archival, a release manager closes PRs tied to deprecated branches and consolidates work into new targets, legitimately generating a burst of closures attributed to a single user.
+
+### Response and remediation
+
+- Immediately contain by removing the user from teams with Triage/Write permissions on affected repositories, revoking their personal access tokens from Tokens & keys, and tightening branch protection by disallowing force-pushes and restricting who can push to main and release branches.
+- Trigger escalation to Security Incident Response if closed pull requests span more than five repositories within one hour, coincide with branch deletions or forced pushes, or originate from a new user agent/IP, and disable the account at the identity provider while contacting GitHub Support.
+- Eradicate impact by reopening legitimate PRs via each closed PR URL, using Restore branch or recreating the head branch from the last known commit SHA, and reapplying required labels and reviewers.
+- Recover repository state by comparing diffs of closed PRs to any newly opened PRs by the same user, reverting unauthorized commits in target branches with git revert, and re-running required status checks before merging.
+- Harden controls by enforcing branch protection rules (require two approvals, restrict who can dismiss reviews, require signed commits), enabling CODEOWNERS for critical paths, and turning off Allow deletions on default and release branches.
+- Prevent recurrence by disabling classic PATs and requiring short-lived fine-grained PATs, revoking unusual OAuth app grants, mandating SSO with hardware-backed MFA, and installing a GitHub App/Action that notifies on PR closures with PR URLs, repos, and branches and requires a reason-coded label per policy.
+"""
 references = [
     "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
     "https://trigger.dev/blog/shai-hulud-postmortem",
@@ -29,6 +60,7 @@ tags = [
     "Tactic: Impact",
     "Tactic: Exfiltration",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/integrations/github/impact_high_number_of_failed_protected_branch_force_pushes_by_user.toml

@@ -2,7 +2,7 @@
 creation_date = "2025/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,37 @@ interval = "8m"
 language = "esql"
 license = "Elastic License v2"
 name = "Several Failed Protected Branch Force Pushes by User"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Several Failed Protected Branch Force Pushes by User
+
+This rule flags a single user generating multiple failed force push attempts to protected branches within a short span, indicating attempts to rewrite commit history and bypass branch protections. An attacker with a compromised maintainer role repeatedly tries to roll back a security fix, delete prior commits, and erase history entries before pushing a malicious revision. This activity threatens code integrity, disrupts pipelines, and can propagate harmful changes across repositories.
+
+### Possible investigation steps
+
+- Pull audit entries for the rejected updates to confirm the rejection reasons and the exact org/repo/branch targets, then reconstruct the timeline and sequence of attempts.
+- Verify the user's current and recent permissions, team membership, and role changes, and confirm whether any admin or ownership transfers occurred before the attempts.
+- Correlate the attempts with authentication and token activity (SSO logins, PAT/SSH key usage, IP/device fingerprints, geo), flagging any new or unusual sources.
+- Review branch protection settings and recent edits (require status checks, linear history, admin enforcement, force push exemptions) to detect policy tampering or misconfiguration.
+- Identify the specific commits the force pushes sought to overwrite by diffing the attempted ref against the protected branch head, prioritizing impacts to security fixes, release branches, or signed commits.
+
+### False positive analysis
+
+- During a repository migration or history cleanup, a maintainer runs a local script that loops through branches and tries to push rewritten commits with --force, but newly tightened branch protection rejects each attempt, resulting in multiple failures.
+- A developer who previously had a force-push exemption on a protected release branch loses that permission during a role or team change and continues their usual rebase-and-force-push workflow, causing several rapid rejected ref updates.
+
+### Response and remediation
+
+- Immediately block the user in the GitHub organization, revoke all active personal access tokens and SSH keys from their account, and force sign-out to stop further push attempts.
+- On each affected repository and branch (e.g., main, release/*), remove any force-push exemptions, enable “Include administrators,” require signed commits and status checks, and restrict push access to specific teams.
+- Purge staging artifacts by deleting any branches or tags the user created around the attempts, rotate the user’s password and regenerate PATs/SSH keys, and remove newly registered keys or OAuth apps added during the window.
+- Validate recovery by confirming the protected branch HEAD matches the last known good signed commit SHA, re-running CI for impacted repos, and creating a restore point tag for rapid rollback.
+- Escalate to incident response if any attempts targeted main or release branches, originated from a newly created PAT/SSH key or an unrecognized IP/device, or the user holds repo admin/organization owner rights.
+- Harden long term by enforcing org-wide 2FA/SSO, removing all standing force-push exemptions, requiring CODEOWNERS approvals on protected branches, and enabling audit alerts for branch protection edits and new credential creation.
+"""
 references = [
     "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
     "https://trigger.dev/blog/shai-hulud-postmortem",
@@ -30,6 +61,7 @@ tags = [
     "Tactic: Impact",
     "Tactic: Exfiltration",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/integrations/github/impact_high_number_of_protected_branch_force_pushes_by_user.toml

@@ -2,7 +2,7 @@
 creation_date = "2025/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,37 @@ interval = "8m"
 language = "esql"
 license = "Elastic License v2"
 name = "High Number of Protected Branch Force Pushes by User"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating High Number of Protected Branch Force Pushes by User
+
+This rule flags a single user performing many force pushes to protected branches in a short window, signaling aggressive history rewrites on critical repositories. Such activity can erase commits, hide unauthorized changes, and disrupt builds or releases, indicating potential data destruction or sabotage. Example: a compromised maintainer acquires elevated access and repeatedly force-pushes rewritten history to the main branch to purge prior commits, remove security fixes, and introduce a backdoor while bypassing merge protections.
+
+### Possible investigation steps
+
+- Verify the user's current and recent org/repo roles and bypass permissions, along with any recent elevation, SSO changes, or new PAT/GitHub App installations linked to the account.
+- Enumerate impacted repositories and protected branches, then reconstruct the overwritten history by comparing before/after SHAs from audit logs or local mirrors to determine what commits were removed or rewritten.
+- Assess intent and legitimacy by contacting repo owners and checking change tickets or maintenance windows for planned history rewrites, and suspend override permissions if unplanned while preserving forensic evidence.
+- Analyze sign-in and authentication telemetry around the events (IP, geo, MFA status, device, OAuth/PAT/App identifiers, off-hours) to spot account compromise indicators and pivot to other activity by the same token.
+- Review diffs of the resulting branch heads and CI/CD artifacts to detect malicious changes (e.g., removed security fixes, inserted secrets/backdoors), and check for anomalous releases or workflows triggered by the rewritten commits.
+
+### False positive analysis
+
+- An authorized maintainer conducts a planned history rewrite (rebases/resets to remove problematic commits) across protected branches in multiple repositories, legitimately invoking policy overrides and issuing many force pushes in quick succession.
+- A release owner executes an emergency rollback by resetting protected branches to a known-good commit across several repositories, causing repeated, intentional force pushes and protected-branch overrides.
+
+### Response and remediation
+
+- Immediately contain by removing the user from repo admin/maintain teams, revoking all active PATs/OAuth/App tokens linked to the account, and updating branch protection on affected branches to disallow force pushes and restrict pushes to a small trusted group.
+- Freeze each impacted protected branch by creating an annotated tag at the last known-good commit SHA prior to the force pushes and temporarily pausing CI/CD workflows that build from those branch heads.
+- Recover by restoring each branch head to the last known-good commit or signed tag from a trusted mirror/backup, verifying the target SHA, and re-enabling protections and required status checks after integrity confirmation.
+- Eradicate unauthorized changes by diffing the pre-override and post-override branch heads, reverting malicious edits, rotating repository secrets referenced in code/workflows, and removing suspicious GitHub Apps installed by the user.
+- Escalate to incident response and legal if any overwritten history includes production release branches or signed tags, if the user denies authorization, or if pushes originated from a new token/App unknown to repo owners.
+- Harden by enforcing rulesets that block force pushes and require linear history on main and release/* branches, enabling CODEOWNERS-required reviews and signed commits, limiting bypass permissions to a small admin group, and using deploy keys or CI bots with short-lived tokens for pushes.
+"""
 references = [
     "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
     "https://trigger.dev/blog/shai-hulud-postmortem",
@@ -30,6 +61,7 @@ tags = [
     "Tactic: Impact",
     "Tactic: Exfiltration",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "esql"

rules/integrations/github/persistence_new_pat_created.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/12/16"
 integration = ["github"]
 maturity = "production"
-updated_date = "2025/12/16"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ index = ["logs-github.audit-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "New GitHub Personal Access Token (PAT) Added"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating New GitHub Personal Access Token (PAT) Added
+
+This alert triggers when someone creates and authorizes a new GitHub personal access token, signaling a fresh long‑lived credential that outlasts sessions and enables broad API access. A common abuse path: after compromising a developer account, the adversary mints a PAT with repo and organization scopes and uses it from an external host to enumerate and clone private repositories via the API.
+
+### Possible investigation steps
+
+- Retrieve token details (type fine‑grained vs classic, scopes, repository/org binding, and expiration) and verify they match the user’s role and least‑privilege expectations.
+- Correlate the creation IP, geolocation, and user agent with the user’s recent login history and corporate network ranges to identify anomalous origin.
+- Determine whether the token is SSO‑enforced and organization‑scoped; lack of SSO or broad classic scopes increases risk and warrants expedited review.
+- Pivot to recent Git and API events by this actor since the token was created to see private repo enumeration/clones or org/admin actions indicating misuse.
+- Check for concurrent account security changes (2FA status modifications, new SSH/GPG keys, email/password changes, or OAuth app grants) that suggest account takeover and escalate if present.
+
+### False positive analysis
+
+- A developer performs planned token rotation or migrates from a classic to a fine‑grained PAT to comply with expiration and least‑privilege policies, generating a legitimate personal_access_token.access_granted creation event.
+- Expected onboarding or maintenance activities create PATs for service or automation use with scoped repository access and set expiration, producing anticipated alerts from known corporate locations.
+
+### Response and remediation
+
+- Revoke the specific PAT referenced in the alert via GitHub UI or API immediately, and temporarily lock the user account if the token’s origin, scopes, or target repositories are not expected.
+- If any activity is observed with this PAT, rotate repository and organization secrets, remove newly added deploy keys and suspicious OAuth app grants, and strip unauthorized collaborator or team role changes.
+- Force a password reset for the account owner, invalidate active sessions, require fresh 2FA re-enrollment, and delete any other nonessential PATs before restoring normal access.
+- Review audit and repository logs for API calls authenticated with this PAT since its creation, block offending source IPs in network controls, and enable GitHub IP allow lists or SSO enforcement to restrict token use to trusted contexts.
+- Escalate to incident response if the PAT has admin or organization owner scopes, was created from an unfamiliar location or device, or was used to clone private repositories or change security settings.
+- Harden going forward by enforcing fine-grained, expiring, SSO-enforced PATs, disabling classic tokens at the organization, requiring approval for new PATs, and migrating automation to GitHub Apps with least-privilege permissions.
+"""
 references = [
     "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
     "https://trigger.dev/blog/shai-hulud-postmortem",
@@ -29,6 +60,7 @@ tags = [
     "Tactic: Persistence",
     "Tactic: Credential Access",
     "Data Source: Github",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"