{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/github-actions/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","GitHub Actions"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","github","credential-theft","initial-access","lateral-movement"],"_cs_type":"advisory","_cs_vendors":["Amazon","Microsoft","Google"],"content_html":"\u003cp\u003eThis threat involves the unauthorized use of AWS credentials stolen from GitHub Actions secrets. Attackers exfiltrate these credentials and use them from their own infrastructure, bypassing the intended CI/CD environment. The activity is detected by observing AWS access keys appearing in CloudTrail logs originating from both legitimate GitHub Actions runners (identified by Microsoft ASN or the \u003ccode\u003egithub-actions\u003c/code\u003e user agent string) and suspicious infrastructure outside the expected CI/CD provider ASNs (Amazon, Google, Microsoft). This indicates a breach of GitHub repository or organization secrets, leading to potential unauthorized access and control over AWS resources. This activity can begin with compromised Github accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker\u0026rsquo;s source IP address and ASN.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities, such as calling \u003ccode\u003ests:GetCallerIdentity\u003c/code\u003e, \u003ccode\u003eListBuckets\u003c/code\u003e, \u003ccode\u003eDescribeInstances\u003c/code\u003e, or \u003ccode\u003eListUsers\u003c/code\u003e, to understand the AWS environment and identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim\u0026rsquo;s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure\u0026rdquo; to your SIEM and tune for your environment to detect suspicious usage patterns.\u003c/li\u003e\n\u003cli\u003eRotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.\u003c/li\u003e\n\u003cli\u003eImplement OIDC-based authentication (\u003ccode\u003eaws-actions/configure-aws-credentials\u003c/code\u003e with \u003ccode\u003erole-to-assume\u003c/code\u003e) instead of long-lived access keys as mentioned in the rule documentation.\u003c/li\u003e\n\u003cli\u003eIf using OIDC, add IP condition policies to the IAM role trust policy to restrict \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to known GitHub runner IP ranges, based on the information in the rule documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T17:45:55Z","date_published":"2026-04-22T17:45:55Z","id":"/briefs/2024-01-aws-github-actions-credential-theft/","summary":"Attackers are stealing AWS credentials configured as GitHub Actions secrets and using them from non-CI/CD infrastructure, indicating potential credential theft and unauthorized access to AWS resources.","title":"AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-github-actions-credential-theft/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Actions"],"_cs_severities":["low"],"_cs_tags":["github","persistence","privilege-escalation","initial-access"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis detection identifies the creation of new secrets within GitHub Actions. Threat actors may create or modify secrets to gain unauthorized access, establish persistence, or escalate privileges within the GitHub environment. The activity is captured via GitHub\u0026rsquo;s audit logs. The scope of this detection encompasses the creation of secrets at the organization, environment, codespaces, or repository level. Successful detection of this activity allows security teams to investigate potentially malicious modifications to GitHub Actions secrets, which could lead to supply chain compromise or data exfiltration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub organization or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings for the organization, environment, codespaces, or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.\u003c/li\u003e\n\u003cli\u003eThe secret is stored within GitHub\u0026rsquo;s infrastructure, accessible to GitHub Actions workflows.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.\u003c/li\u003e\n\u003cli\u003eThe workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive data, code injection, and supply chain compromise. The impact ranges from low, in cases where the secret is used for benign purposes, to critical if the secret is used to deploy malicious code into production environments. While the number of affected organizations is unknown, the potential for widespread impact across the software supply chain makes this a critical area for monitoring.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable GitHub audit log streaming to capture the events necessary for this detection (see \u003ccode\u003elogsource\u003c/code\u003e definition).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eGithub New Secret Created\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the \u0026ldquo;actor\u0026rdquo; involved in creating the secret.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-github-secret-creation/","summary":"This analytic detects the creation of new GitHub Actions secrets at the organization, environment, codespaces, or repository level, potentially indicating malicious persistence or privilege escalation.","title":"Detection of New GitHub Actions Secrets Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-github-secret-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Actions"],"_cs_severities":["low"],"_cs_tags":["github","self-hosted-runner","audit-log","devops","supply-chain"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting changes to self-hosted runner configurations within GitHub environments. Self-hosted runners are systems deployed and managed by users to execute jobs from GitHub Actions, providing flexibility and control over the execution environment. Monitoring these runners is crucial because unauthorized modifications can lead to various malicious activities, including data collection, persistence, privilege escalation, or even initial access. The rule provided detects such changes based on audit logs, requiring administrators to validate the changes through the GitHub UI for complete context. Detecting these modifications early can help prevent or mitigate potential security breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a GitHub organization or repository with permissions to manage self-hosted runners. This could be achieved through compromised credentials (T1078.004) or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).\u003c/li\u003e\n\u003cli\u003eThe attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).\u003c/li\u003e\n\u003cli\u003eThe attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised runner or runner group to execute malicious code within the GitHub Actions workflow, potentially collecting sensitive data or escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the compromised runner to gain initial access to other systems or networks connected to the GitHub environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised self-hosted runners can lead to a range of impacts, including data exfiltration, code injection, and privilege escalation within the targeted GitHub environment. Successful attacks could result in unauthorized access to sensitive repositories, modification of code, or deployment of malicious software. The impact can vary depending on the scope of the compromised runner and the permissions associated with it. The effects could extend beyond the GitHub environment if the compromised runner has access to other systems or networks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the audit log streaming feature in GitHub to capture events related to self-hosted runner modifications, as required by the logsource definition.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Github Self Hosted Runner Changes Detected\u0026rdquo; to your SIEM and tune for your specific environment to detect suspicious configuration changes.\u003c/li\u003e\n\u003cli\u003eRegularly review the audit logs in the GitHub UI to validate any detected changes to self-hosted runners and runner groups to ensure legitimate modifications.\u003c/li\u003e\n\u003cli\u003eImplement strict access control policies for managing self-hosted runners, limiting permissions to only authorized personnel.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-github-runner-changes/","summary":"Detection of changes to self-hosted runner configurations in GitHub environments can indicate potential impact, discovery, collection, persistence, privilege escalation, initial access, or stealth activities.","title":"GitHub Self-Hosted Runner Configuration Changes Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-github-runner-changes/"}],"language":"en","title":"CraftedSignal Threat Feed — GitHub Actions","version":"https://jsonfeed.org/version/1.1"}