Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
411 detections
Filters
Last updated
All Time
Detection languages
181
74
63
61
11
Contributors
113
62
55
52
32
Categories
140
133
102
96
49
Platforms
309
74
43
15
15
Products / Services
10,665
9,773
6,704
4,421
3,749
411
MITRE Techniques
126
125
81
72
64
CVEs
5
1
1
1
1
Detects action of git clone or git push in a repo where the source actor is not coming from a Corp IP Space. (Add your IP Blocks as needed to the filter)
Detects action of Repo branch protection being disabled. This would mean no PR or review process is needed for that repo and an actor (Insider or attacker) could push arbitrary code. Bypassing usual Security controls.
Detects action of SSH ertificate Auth being disabled. This would mean password auth is allowed.
This could indicate an Authentication downgrade attack, disabling Security controls.
This could indicate an Authentication downgrade attack, disabling Security controls.
Detection attempts to modify package manager configurations to point to potentially malicious repositories, enabling supply chain attacks through dependency confusion.
This rule detects the use of the malicious GitHub Action 'ci-quality/code-quality-check@v1' associated with the SANDWORM_MODE campaign. This action is designed to harvest CI secrets and propagate the malware by being referenced in a GitHub workflow file. The rule searches for the specific string of the malicious GitHub action within file content or file/audit paths, specifically targeting GitHub workflow files (.yml or .yaml) in '.github/workflows/' directories.
Detects programmatic GitHub data exfiltration by identifying non-interactive repository exports, clones, artifact downloads, or gist staging performed using tokens, OAuth applications, or GitHub Apps. The detection focuses on bursty or multi-repository activity within a short time window, which can indicate automated source code collection, misuse of programmatic credentials, or post-compromise data extraction.
Detects a suspicious sequence where a new credential (PAT, SSH key, or OAuth authorization) is created and then used to establish durable persistence via webhooks or deploy keys. This behavior typically occurs after an account compromise as an attacker attempts to "lock in" access that survives credential rotation and provides real-time exfiltration of repository data.
Detects the addition of an SSH public key to a GitHub account using programmatic access (Personal Access Tokens, OAuth, or GitHub Apps). Unlike keys added via the Web UI, programmatic creation often bypasses manual verification steps and provides long-lived access that survives password resets and MFA changes. This is a common technique for attackers to establish persistent command line access to repositories.
Detects the creation of a new Personal Access Token (PAT) in GitHub. Attackers frequently create PATs after gaining initial access to an account to maintain persistence that survives a password reset. Tokens with broad scopes (repo, admin:org) allow for full repository exfiltration and administrative manipulation of the organization.
Detects the creation or modification of repository webhooks in GitHub. Attackers can use webhooks for real-time data exfiltration of code pushes, pull request comments, and workflow data. Once a webhook is established, it operates independently of the creating user; revoking the creator's credentials will NOT stop the data flow. Only deleting the webhook itself terminates the exfiltration.
Detects unauthorized interactive modifications to CI/CD pipeline configurations that could indicate supply chain attack or malicious dependency code injection attempts.
This alert identifies a potential bypass of repository governance controls. It triggers when a GitHub repository's default branch is changed and then reverted or updated again within a 24-hour window. By temporarily changing the default branch to an unprotected branch, an actor can push code or merge pull requests to the primary branch (e.g., main) without satisfying mandatory status checks or peer review requirements.
Detects the creation of a persistent GitHub self-hosted runner named 'SHA1HULUD', a technique used by the Shai-Hulud 2.0 malware for persistence and remote command execution. The rule specifically looks for process command lines containing " --name SHA1HULUD".
Detects creation of branches and files matching indicators used by Shai-Hulud 2.0 for exfiltration
Detects GitHub Actions activity matching indicators used by Shai-Hulud 2.0 for exfiltration and persistence
This rule detects the creation of a public GitHub repository with the specific description "Sha1-Hulud: The Second Coming". This is an indicator of compromise (IOC) associated with the Shai-Hulud 2.0 worm, which uses these repositories to exfiltrate stolen credentials.
This search detects the creation of a public GitHub repository with the description "Sha1-Hulud: The Second Coming". This is a specific indicator of compromise (IOC) associated with the Shai-Hulud 2.0 worm, which uses these repositories to exfiltrate stolen credentials.
This rule detects when GitHub's push protection feature is disabled. This feature helps prevent sensitive information, such as secrets, from being accidentally committed to repositories. Disabling it could indicate an attempt to bypass security controls, potentially allowing secrets to be exposed in code.
Detects when a new member is added or invited to a GitHub organization. This activity could indicate an attempt by an adversary to gain persistence within an organization's GitHub environment by adding a controlled account or inviting a malicious user.
This rule detects when a user disables critical security features within a GitHub organization or repository. This includes disabling advanced security features, OAuth app access restrictions, or two-factor authentication requirements. Such actions can significantly weaken the security posture of a GitHub environment, potentially leading to unauthorized access or compromise.
Detects when an organization member or an outside collaborator is added to or removed from a project board or has their permission level changed or when an owner removes an outside collaborator from an organization or when two-factor authentication is required in an organization and an outside collaborator does not use 2FA or disables 2FA.
Page 13 of 20