https://feed.craftedsignal.io/tags/supply_chain/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jan 2024 12:00:00 +0000https://feed.craftedsignal.io/briefs/2024-01-03-github-2fa-disabled/Wed, 03 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-03-github-2fa-disabled/The disabling of two-factor authentication (2FA) in GitHub Organizations is detected through audit log monitoring, potentially indicating an attacker's attempt to weaken account security and facilitate unauthorized access.This detection identifies instances where two-factor authentication (2FA) requirements are disabled within GitHub Organizations. By monitoring GitHub Organizations audit logs, this analytic tracks changes to 2FA requirements, capturing details about the actor, organization, and associated metadata. Disabling 2FA weakens security controls, increasing the risk of account compromise via password-based attacks. The absence of 2FA can lead to unauthorized access to sensitive code repositories, intellectual property, and potential compromise of the software supply chain. The activity observed in this analytic aligns with actions outlined in the MITRE ATT&CK framework such as impair defenses (T1562.001) and supply chain compromise (T1195).

Attack Chain

1. An attacker gains initial access to a privileged GitHub account, possibly through credential compromise or social engineering.
2. The attacker authenticates to the GitHub organization with the compromised account.
3. The attacker navigates to the organization’s security settings within GitHub.
4. The attacker disables the requirement for two-factor authentication (2FA) for the organization.
5. GitHub audit logs record the “org.disable_two_factor_requirement” event, capturing details of the actor and organization.
6. With 2FA disabled, the attacker can now access other accounts within the organization more easily without needing to bypass multi-factor authentication.
7. The attacker then uses the compromised accounts to access sensitive code repositories or other resources within the organization.
8. The attacker exfiltrates sensitive data or injects malicious code into the software supply chain.

Impact

Disabling 2FA in GitHub organizations increases the risk of account takeover and unauthorized access to sensitive code and intellectual property. A successful attack could lead to the compromise of the software supply chain, impacting not only the organization itself but also its customers and users. This can result in reputational damage, financial losses, and legal liabilities. The Google Cloud Community reported on using Google Security to monitor for suspicious GitHub activity.

Recommendation

• Enable and maintain the Splunk Add-on for GitHub to ingest GitHub Organizations audit logs as detailed in the references.
• Deploy the Sigma rule GitHub Organizations Disable 2FA Requirement to detect instances of 2FA being disabled.
• Investigate any alerts generated by the Sigma rule, focusing on the actor, actor_id, and actor_ip fields to identify potentially compromised accounts.
• Monitor user agent strings (user_agent field) for suspicious or anomalous activity related to the disabling of 2FA.
• Review and enforce strong password policies and educate users about the importance of 2FA to prevent initial account compromise.

]]>mediumadvisorygithub2fasecurity_controlssupply_chainhttps://feed.craftedsignal.io/briefs/2024-01-github-enterprise-runner/Wed, 03 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-github-enterprise-runner/A self-hosted runner was created in GitHub Enterprise, which could be exploited by attackers to execute malicious code, access sensitive data, or pivot to other systems.This alert identifies the creation of a self-hosted runner in GitHub Enterprise by monitoring GitHub Enterprise audit logs. Self-hosted runners execute workflow jobs on customer-controlled infrastructure. Attackers can abuse compromised runners to execute malicious code, access sensitive data, or pivot to other systems within the environment. While self-hosted runners are a legitimate feature, their creation should be carefully controlled as compromised runners pose significant security risks. It is crucial to investigate any unexpected runner creation events to ensure they are authorized and properly secured, especially if initiated by unfamiliar users or in unusual contexts. This activity may indicate a supply chain attack or other malicious activity.

Attack Chain

1. An attacker gains access to a GitHub Enterprise account or obtains sufficient privileges to register a self-hosted runner.
2. The attacker registers a new self-hosted runner within the GitHub Enterprise organization or enterprise account. This action is logged in the GitHub Enterprise audit logs.
3. The newly registered runner is configured to execute workflow jobs within the GitHub Enterprise environment.
4. The attacker modifies or injects malicious code into a GitHub workflow that will be executed by the compromised runner. This may involve actions such as pull requests or direct commits to the repository.
5. The compromised runner executes the malicious workflow job, allowing the attacker to execute arbitrary code on the runner infrastructure.
6. The attacker leverages the compromised runner to access sensitive data stored within the GitHub environment or accessible to the runner.
7. The attacker pivots from the compromised runner to other systems within the network, potentially gaining access to additional resources and sensitive information.
8. The attacker may exfiltrate data from the environment or maintain persistence on the compromised systems for future malicious activities.

Impact

Successful exploitation via a compromised self-hosted runner can lead to remote code execution, data exfiltration, and lateral movement within the targeted environment. A compromised runner allows attackers to execute arbitrary code, access sensitive data, and potentially pivot to other systems, resulting in significant damage and potential data breaches. The scope of the impact depends on the permissions and access levels of the compromised runner.

Recommendation

• Enable GitHub Enterprise Audit log streaming to a SIEM like Splunk, as described in the GitHub documentation, to capture runner registration events.
• Deploy the Sigma rule GitHub Enterprise Register Self Hosted Runner to detect unauthorized or suspicious runner creations.
• Monitor the user_agent field in the audit logs for unusual or unexpected values associated with runner registration events.
• Investigate any alerts generated by the Sigma rule, focusing on the actor, actor_id, and user_agent fields.
• Implement strong access controls and multi-factor authentication for GitHub Enterprise accounts, especially those with permissions to manage runners.
• Regularly review and audit the list of registered self-hosted runners in GitHub Enterprise to identify any unauthorized or suspicious entries.

]]>mediumadvisorygithubsupply_chainself_hosted_runnerhttps://feed.craftedsignal.io/briefs/2024-01-github-branch-protection-disabled/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-github-branch-protection-disabled/Detection of disabled classic branch protection rules in GitHub Enterprise, indicating potential bypass of code review and security controls, leading to unauthorized code changes and supply chain compromise.This brief focuses on the detection of disabled classic branch protection rules within a GitHub Enterprise environment. The detection is based on monitoring GitHub Enterprise audit logs for events related to the removal of branch protections. Attackers may disable these rules to bypass code review processes and introduce malicious code or vulnerabilities directly into protected branches. This action can be part of a larger attack, where adversaries first weaken security controls before injecting malicious content. Identifying and responding to these events is crucial for maintaining the integrity and security of the software supply chain. This analytic is sourced from Splunk’s security content and is designed to run on GitHub Enterprise audit logs ingested into Splunk.

Attack Chain

1. An attacker gains unauthorized access to a GitHub Enterprise account with sufficient privileges.
2. The attacker navigates to the repository settings within the GitHub Enterprise instance.
3. The attacker identifies the classic branch protection rules configured for a target branch.
4. The attacker disables one or more of these branch protection rules, such as code review enforcement or restrictions on force pushes. This generates a protected_branch.destroy event in the audit logs.
5. The attacker commits and pushes unauthorized or malicious code directly to the protected branch, bypassing established security controls.
6. The malicious code is merged into the main branch, potentially affecting production systems or downstream consumers of the code.
7. The attacker may attempt to cover their tracks by deleting audit logs or manipulating other security controls.

Impact

The impact of disabled branch protection rules can be significant. Successful exploitation can lead to the introduction of vulnerabilities, malicious code, or backdoors into the software supply chain. This can result in data breaches, system compromise, and reputational damage. The number of affected systems and the extent of the damage depend on the scope and nature of the malicious code injected. The targets are GitHub Enterprise organizations that rely on branch protection rules to maintain code quality and security.

Recommendation

• Enable GitHub Enterprise Audit log streaming to a SIEM or log management solution to capture protected_branch.destroy events as described in the GitHub Enterprise documentation.
• Deploy the Sigma rule GitHub Enterprise Disable Classic Branch Protection Rule to detect instances where branch protection rules are disabled and tune it for your environment.
• Investigate any alerts generated by the Sigma rule, focusing on the actor, repo, and user_agent fields to understand the context of the event.
• Implement multi-factor authentication (MFA) for all GitHub Enterprise accounts, especially those with administrative privileges.
• Regularly review and audit GitHub Enterprise configurations to ensure that branch protection rules are properly configured and enforced.

]]>mediumadvisorygithubbranch_protectionsupply_chain