GitHub Actions — CraftedSignal Threat Feed

AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure

hello@craftedsignal.io — Wed, 22 Apr 2026 17:45:55 +0000

This 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 github-actions 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.

Attack Chain

An attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.
The 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.
The attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.
The attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker’s source IP address and ASN.
The attacker performs reconnaissance activities, such as calling sts:GetCallerIdentity, ListBuckets, DescribeInstances, or ListUsers, to understand the AWS environment and identify potential targets.
The attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.
The 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.

Impact

Successful 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’s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.

Recommendation

Deploy the Sigma rule “AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure” to your SIEM and tune for your environment to detect suspicious usage patterns.
Rotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.
Implement OIDC-based authentication (aws-actions/configure-aws-credentials with role-to-assume) instead of long-lived access keys as mentioned in the rule documentation.
If using OIDC, add IP condition policies to the IAM role trust policy to restrict AssumeRoleWithWebIdentity to known GitHub runner IP ranges, based on the information in the rule documentation.

Detection of New GitHub Actions Secrets Creation

hello@craftedsignal.io — Tue, 30 Jan 2024 12:00:00 +0000

This 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’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.

Attack Chain

An attacker gains initial access to a GitHub account, potentially through compromised credentials or phishing (T1078.004).
The attacker authenticates to the GitHub organization or repository.
The attacker navigates to the settings for the organization, environment, codespaces, or repository.
The attacker creates a new secret within the GitHub Actions settings, using the GitHub API or web interface.
The secret is stored within GitHub’s infrastructure, accessible to GitHub Actions workflows.
The attacker modifies or creates a GitHub Actions workflow that utilizes the newly created secret.
The workflow executes, using the secret to perform privileged actions such as accessing sensitive data or deploying malicious code.
The attacker achieves persistence or elevates their privileges within the GitHub environment, potentially compromising the entire software supply chain.

Impact

Successful 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.

Recommendation

Enable GitHub audit log streaming to capture the events necessary for this detection (see logsource definition).
Deploy the Sigma rule Github New Secret Created to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule, focusing on the “actor” involved in creating the secret.

GitHub Self-Hosted Runner Configuration Changes Detected

hello@craftedsignal.io — Wed, 03 Jan 2024 14:30:00 +0000

This 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.

Attack Chain

An 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.
The attacker modifies the configuration of an existing self-hosted runner group or creates a new runner group (org.runner_group_created).
The attacker adds or removes runners from a runner group (org.runner_group_runners_added, org.runner_group_runner_removed, org.runner_group_updated).
Alternatively, the attacker registers a new self-hosted runner within the environment (repo.register_self_hosted_runner).
The attacker removes an existing self-hosted runner from the environment (repo.remove_self_hosted_runner, org.remove_self_hosted_runner).
The attacker uses the compromised runner or runner group to execute malicious code within the GitHub Actions workflow, potentially collecting sensitive data or escalating privileges.
The attacker leverages the compromised runner to establish persistence within the GitHub environment, ensuring continued access.
The attacker exploits the compromised runner to gain initial access to other systems or networks connected to the GitHub environment.

Impact

Compromised 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.

Recommendation

Enable the audit log streaming feature in GitHub to capture events related to self-hosted runner modifications, as required by the logsource definition.
Deploy the Sigma rule “Github Self Hosted Runner Changes Detected” to your SIEM and tune for your specific environment to detect suspicious configuration changes.
Regularly review the audit logs in the GitHub UI to validate any detected changes to self-hosted runners and runner groups to ensure legitimate modifications.
Implement strict access control policies for managing self-hosted runners, limiting permissions to only authorized personnel.