{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/attack.defense-impairment/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eAttackers with sufficient privileges within a Bitbucket project or repository may delete secret scanning rules. These rules are designed to automatically detect and prevent the committing of sensitive information like API keys, passwords, and tokens directly into the codebase. By removing these rules, adversaries can bypass security controls and introduce secrets into the repository undetected. This could be a precursor to a larger attack, where the leaked secrets are used to gain unauthorized access to systems, data, or other resources. This activity may occur as a part of a broader insider threat campaign or an external attacker who has gained control of a privileged account.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises a Bitbucket account with project or repository administrator privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Bitbucket web interface or uses the Bitbucket API with the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the project or repository settings where secret scanning rules are configured.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the secret scanning rules in place.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the deletion of one or more secret scanning rules through the Bitbucket web interface or API.\u003c/li\u003e\n\u003cli\u003eBitbucket processes the request and removes the specified secret scanning rules.\u003c/li\u003e\n\u003cli\u003eThe attacker (or another compromised account) commits code containing secrets, which are no longer detected due to the deleted rules.\u003c/li\u003e\n\u003cli\u003eThe committed secrets are then potentially used for lateral movement, data exfiltration, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of secret scanning rules in Bitbucket can lead to the undetected introduction of sensitive information into the codebase. This can result in unauthorized access to systems, data breaches, and other security incidents. The impact can range from minor data exposure to significant financial losses and reputational damage, depending on the scope and sensitivity of the leaked secrets. Organizations relying on Bitbucket for source code management are vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor Bitbucket audit logs for events related to secret scanning rule deletions, using the provided Sigma rule to detect suspicious activity (\u003ccode\u003ebitbucket_audit_secret_scanning_rule_deleted.yml\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to reduce the risk of account compromise.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege, ensuring that users only have the necessary permissions to perform their tasks.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Bitbucket user permissions and access controls.\u003c/li\u003e\n\u003cli\u003eImplement strong password policies and encourage users to use unique, complex passwords.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-17T14:22:00Z","date_published":"2024-11-17T14:22:00Z","id":"/briefs/2024-11-bitbucket-secret-rule-deletion/","summary":"Attackers may delete secret scanning rules in Bitbucket to impair defenses and introduce secrets into the code repository undetected, potentially leading to unauthorized access or data breaches.","title":"Bitbucket Secret Scanning Rule Deleted","url":"https://feed.craftedsignal.io/briefs/2024-11-bitbucket-secret-rule-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail","AWS EC2"],"_cs_severities":["low"],"_cs_tags":["attack.defense-impairment","attack.t1686.001","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe creation of new Network Access Control List (ACL) entries in Amazon Web Services (AWS) environments can be a sign of malicious activity. While legitimate use cases exist, adversaries can leverage these ACL changes to impair existing defenses, create new pathways for lateral movement, or establish persistence mechanisms. This activity is logged by CloudTrail and can be monitored to identify unauthorized or suspicious modifications to network security configurations. Attackers could create overly permissive rules that allow unauthorized access to critical resources or restrictive rules that disrupt legitimate traffic. Monitoring the creation of Network ACL entries is important for maintaining the integrity and security of AWS environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The \u003ccode\u003eCreateNetworkAclEntry\u003c/code\u003e event is logged in CloudTrail.\u003c/li\u003e\n\u003cli\u003eThe new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.\u003c/li\u003e\n\u003cli\u003eAlternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe creation of unauthorized Network ACL entries can have significant consequences. It can lead to the opening of new attack vectors, allowing unauthorized access to sensitive data and critical resources. In some scenarios, it can result in a denial-of-service condition, disrupting legitimate business operations. Depending on the scope of the compromised resources and data, the impact can range from minor inconvenience to significant financial loss and reputational damage. Early detection of this activity is crucial to mitigating potential risks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Network ACL Entry Added\u0026rdquo; to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateNetworkAclEntry\u003c/code\u003e events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.\u003c/li\u003e\n\u003cli\u003eReview and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for other related events, such as \u003ccode\u003eDeleteNetworkAclEntry\u003c/code\u003e or \u003ccode\u003eReplaceNetworkAclEntry\u003c/code\u003e, which may indicate further tampering with network security configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-26T14:27:00Z","date_published":"2024-10-26T14:27:00Z","id":"/briefs/2024-10-aws-network-acl-created/","summary":"Detection of new Network ACL entries in AWS CloudTrail logs can indicate potential defense impairment or the opening of new attack vectors within an AWS account by an adversary.","title":"New AWS Network ACL Entry Creation Detected","url":"https://feed.craftedsignal.io/briefs/2024-10-aws-network-acl-created/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1562.004","bitbucket"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eAttackers may target Bitbucket audit log configurations to reduce or eliminate logging, thereby hindering incident response and forensic investigations. Modifying audit settings is a defense evasion technique that allows malicious actors to operate with less visibility. This activity typically occurs post-compromise. This brief focuses on detecting such modifications. Visibility of audit events requires at least \u0026ldquo;Basic\u0026rdquo; log level configuration.\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 Bitbucket instance, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Bitbucket web interface or uses the Bitbucket API.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the audit log configuration settings within the Bitbucket administration panel.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the audit log settings, such as disabling logging for specific event categories or reducing the log retention period.\u003c/li\u003e\n\u003cli\u003eThe Bitbucket server processes the configuration change request.\u003c/li\u003e\n\u003cli\u003eAudit events related to the configuration change are logged (if auditing is still enabled for such events).\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities, such as creating unauthorized repositories or exfiltrating source code, with reduced risk of detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the Bitbucket audit log configuration allows attackers to operate with significantly reduced visibility. This can lead to delayed detection of breaches, prolonged dwell time, and increased data exfiltration. Without proper audit logging, organizations will struggle to identify the scope and impact of a compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Bitbucket Audit Log Configuration Updated\u0026rdquo; Sigma rule to your SIEM to detect changes to audit log configurations (logsource: bitbucket, service: audit).\u003c/li\u003e\n\u003cli\u003eEnsure Bitbucket audit logging is enabled at the \u0026ldquo;Basic\u0026rdquo; level or higher, as lower levels may not capture configuration changes (logsource: bitbucket, service: audit).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of audit log configuration changes to determine if they are authorized (Sigma rule: \u0026ldquo;Bitbucket Audit Log Configuration Updated\u0026rdquo;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-10-26T12:00:00Z","date_published":"2024-10-26T12:00:00Z","id":"/briefs/2024-10-bitbucket-audit-config-mod/","summary":"An attacker may modify the Bitbucket audit log configuration to impair security monitoring and evade detection.","title":"Bitbucket Audit Log Configuration Modified","url":"https://feed.craftedsignal.io/briefs/2024-10-bitbucket-audit-config-mod/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["high"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eThe disabling of GitHub\u0026rsquo;s secret scanning feature represents a significant security risk. Secret scanning is a critical control that prevents sensitive information, such as API keys, credentials, and tokens, from being committed to repositories. An attacker who gains administrative access to a GitHub organization or repository could disable this feature to facilitate the undetected introduction of secrets into the codebase. This action undermines the organization\u0026rsquo;s security posture, creating opportunities for unauthorized access and data breaches. The activity is logged via GitHub audit logs, providing an opportunity for detection. This brief focuses on detecting the actions that disable the secret scanning feature within GitHub.\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 account with administrative privileges for either an organization or a specific repository.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the security settings within the organization or repository.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the \u0026ldquo;Secret scanning\u0026rdquo; feature or related settings (e.g., \u0026ldquo;Secret scanning for new repositories\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe attacker disables the secret scanning feature using the GitHub UI or API. This generates an audit log event.\u003c/li\u003e\n\u003cli\u003eThe attacker commits code containing secrets to the repository.\u003c/li\u003e\n\u003cli\u003eBecause secret scanning is disabled, the secrets are not detected or flagged by GitHub.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the committed secrets to gain unauthorized access to other systems or data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which could include data exfiltration, lateral movement, or service disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling secret scanning can lead to the exposure of sensitive credentials within a codebase. If successful, attackers can leverage these exposed secrets to compromise systems, access sensitive data, and potentially cause significant financial and reputational damage. The number of affected repositories and the extent of the damage depend on the scope of the access the attacker gains and the criticality of the exposed secrets. This can affect any organization that uses Github for source code management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Github Secret Scanning Feature Disabled\u0026rdquo; Sigma rule to your SIEM to detect unauthorized disabling of the feature (logsource: github, service: audit).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of secret scanning being disabled to determine if they were authorized administrative actions.\u003c/li\u003e\n\u003cli\u003eEnable audit log streaming to ensure the required logs are available (see logsource definition).\u003c/li\u003e\n\u003cli\u003eReview GitHub access controls to ensure that only authorized personnel have the ability to modify secret scanning settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-19T00:00:00Z","date_published":"2024-07-19T00:00:00Z","id":"/briefs/2024-07-github-secret-scanning-disabled/","summary":"Detection of the disabling of GitHub secret scanning at the business or repository level, potentially increasing the risk of exposed credentials and secrets.","title":"GitHub Secret Scanning Feature Disabled","url":"https://feed.craftedsignal.io/briefs/2024-07-github-secret-scanning-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","policy-modification","attack.privilege-escalation","attack.credential-access","attack.persistence","attack.defense-impairment","attack.t1548","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eCompromised or malicious actors may attempt to modify Azure Conditional Access (CA) policies to weaken security controls, elevate privileges, or establish persistence within the Azure environment. Conditional Access policies are critical for enforcing organizational security standards, and unauthorized changes can have significant security implications. This activity is detected through Azure Audit Logs by monitoring for \u0026ldquo;Update conditional access policy\u0026rdquo; events. Defenders should investigate any modifications to Conditional Access policies to ensure they are legitimate and align with security best practices. Detecting and responding to unauthorized CA policy modifications is crucial for maintaining the integrity and security of the Azure environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access through compromised credentials or other means (not specified in source).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages existing privileges or exploits vulnerabilities to gain sufficient permissions to modify Conditional Access policies (e.g., through a compromised Global Administrator account).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Enumeration:\u003c/strong\u003e The attacker enumerates existing Conditional Access policies to identify targets for modification using tools like Azure PowerShell or the Azure portal.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Modification:\u003c/strong\u003e The attacker modifies a Conditional Access policy, for example, by weakening MFA requirements, excluding specific users or groups from the policy, or disabling the policy altogether.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e By weakening or disabling Conditional Access policies, the attacker establishes a persistent foothold in the environment, allowing them to bypass security controls and maintain unauthorized access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e With weakened MFA or other access controls, the attacker gains easier access to sensitive credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Impairment:\u003c/strong\u003e The modification of CA policies impairs the organization\u0026rsquo;s defense mechanisms, making it easier for the attacker to perform malicious activities undetected.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of Conditional Access policies can lead to significant security breaches, including unauthorized access to sensitive data, privilege escalation, and persistent compromise of the Azure environment. The number of affected users and resources depends on the scope of the modified policies. Organizations may experience data loss, financial losses, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;CA Policy Updated by Non Approved Actor\u0026rdquo; Sigma rule to your SIEM to detect unauthorized modifications to Conditional Access policies within your Azure environment.\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eproperties.message\u003c/code\u003e field in the Azure Audit Logs for \u0026ldquo;Update conditional access policy\u0026rdquo; events and compare \u0026ldquo;old\u0026rdquo; vs \u0026ldquo;new\u0026rdquo; values to understand the nature of the changes.\u003c/li\u003e\n\u003cli\u003eImplement strict role-based access control (RBAC) to limit the number of users who can modify Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule and verify whether the user identity, user agent, and/or hostname should be making changes in your environment.\u003c/li\u003e\n\u003cli\u003eEnable multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise (related to attack.credential-access tag).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-29T12:00:00Z","date_published":"2024-05-29T12:00:00Z","id":"/briefs/2024-05-29-azure-ca-policy-update/","summary":"An unauthorized actor modifies an Azure Conditional Access policy, potentially leading to privilege escalation, credential access, persistence, or defense impairment.","title":"Unauthorized Modification of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-05-29-azure-ca-policy-update/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.credential-access","attack.persistence","attack.privilege-escalation","attack.defense-impairment","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe addition of a new root certificate authority (CA) in Azure Active Directory (Azure AD) to support certificate-based authentication (CBA) can be a sign of malicious activity. While CBA offers passwordless authentication benefits, attackers can abuse it to establish persistent access, escalate privileges, or evade detection. An attacker with sufficient privileges in the Azure AD tenant can add a rogue CA, enabling them to authenticate as any user within the directory, even without their password. This bypasses multi-factor authentication (MFA) and grants unauthorized access to sensitive resources and data. Defenders should monitor Azure AD audit logs for unexpected modifications to the \u003ccode\u003eTrustedCAsForPasswordlessAuth\u003c/code\u003e setting, as this could indicate a compromised administrator account or an insider threat attempting to establish a backdoor.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eCompromise an Azure AD administrator account with sufficient privileges to modify tenant-wide settings. This may be achieved through phishing, credential stuffing, or exploiting vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses PowerShell cmdlets to interact with Azure AD.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to add a new, attacker-controlled root certificate authority to the \u003ccode\u003eTrustedCAsForPasswordlessAuth\u003c/code\u003e setting. This involves modifying the Company Information object.\u003c/li\u003e\n\u003cli\u003eThe attacker generates or obtains a certificate signed by the newly added root CA.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the certificate to authenticate to Azure AD as a targeted user, bypassing password requirements and multi-factor authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the targeted user\u0026rsquo;s resources, such as email, files, and applications.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the Azure AD tenant by impersonating highly privileged users or roles.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Azure AD tenant, even if the compromised administrator account is remediated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete compromise of the Azure AD tenant, including access to sensitive data, applications, and resources. Attackers can use the compromised tenant to move laterally to other systems, exfiltrate data, or disrupt business operations. The number of potential victims is dependent on the size of the Azure AD tenant. Organizations across all sectors are at risk, especially those heavily reliant on Azure AD for identity and access management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Root Certificate Authority Added\u0026rdquo; to your SIEM to detect unauthorized modifications to the \u003ccode\u003eTrustedCAsForPasswordlessAuth\u003c/code\u003e setting (rule).\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs regularly for suspicious activity related to the \u0026ldquo;Set Company Information\u0026rdquo; operation (logsource).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure AD accounts, including administrators, but understand that CBA can bypass it.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege and restrict the number of accounts with permissions to modify tenant-wide settings.\u003c/li\u003e\n\u003cli\u003eMonitor for the use of certificates signed by unknown or untrusted CAs to authenticate to Azure AD.\u003c/li\u003e\n\u003cli\u003eConsult the SpecterOps and Goodworkaround articles for more information on certificate-based authentication abuse in Azure AD (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-08T18:22:00Z","date_published":"2024-05-08T18:22:00Z","id":"/briefs/2024-05-azuread-root-ca-add/","summary":"An attacker may add a new root certificate authority to an Azure AD tenant to support certificate-based authentication for persistence, privilege escalation, or defense evasion.","title":"Azure AD Root Certificate Authority Added for Passwordless Authentication","url":"https://feed.craftedsignal.io/briefs/2024-05-azuread-root-ca-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub Enterprise Cloud"],"_cs_severities":["high"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThe GitHub push protection feature is designed to prevent secrets and sensitive information from being committed to repositories. Disabling this feature, whether at the organization, enterprise, or repository level, significantly increases the risk of accidental or intentional exposure of credentials, API keys, and other sensitive data. This can lead to unauthorized access, data breaches, and other security incidents. The actions detected can originate from administrative accounts or potentially compromised accounts with administrative privileges. This brief focuses on detecting the disabling of push protection, allowing security teams to respond and remediate the configuration.\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 account with administrative privileges, or a legitimate administrator performs the action.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the organization, enterprise, or repository settings in GitHub.\u003c/li\u003e\n\u003cli\u003eThe attacker locates the \u0026ldquo;Secret scanning\u0026rdquo; or \u0026ldquo;Push protection\u0026rdquo; configuration section.\u003c/li\u003e\n\u003cli\u003eThe attacker disables the push protection feature for the organization, enterprise, or specific repositories. This can be done via the GitHub UI or API.\u003c/li\u003e\n\u003cli\u003eGitHub audit logs record the event with the actions \u003ccode\u003ebusiness_secret_scanning_custom_pattern_push_protection.disabled\u003c/code\u003e, \u003ccode\u003ebusiness_secret_scanning_push_protection.disable\u003c/code\u003e, \u003ccode\u003eorg.secret_scanning_custom_pattern_push_protection_disabled\u003c/code\u003e, etc..\u003c/li\u003e\n\u003cli\u003eDevelopers unknowingly or intentionally commit code containing secrets or sensitive data to the affected repositories.\u003c/li\u003e\n\u003cli\u003eThe secrets are pushed to the remote repository without being blocked by push protection.\u003c/li\u003e\n\u003cli\u003eThe exposed secrets can be discovered by malicious actors, leading to account compromise, data breaches, or other security incidents.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling push protection can lead to the exposure of sensitive information such as API keys, passwords, and other credentials within GitHub repositories. This exposure can lead to account compromise, unauthorized access to systems and data, and potentially significant financial and reputational damage. The number of affected repositories and the severity of the impact depends on the scope of the push protection disabling and the types of secrets committed to the repositories.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Github Push Protection Disabled\u0026rdquo; to your SIEM and tune for your environment to detect when push protection is disabled.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of push protection being disabled in the GitHub audit logs (logsource: github, service: audit) to verify the legitimacy of the action.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all GitHub accounts, especially those with administrative privileges, to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit GitHub organization and repository settings to ensure that push protection is enabled and properly configured.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-03T12:00:00Z","date_published":"2024-05-03T12:00:00Z","id":"/briefs/2024-05-github-push-protection-disabled/","summary":"An administrator has disabled the GitHub push protection feature, potentially allowing secrets and other sensitive information to be pushed to repositories.","title":"GitHub Push Protection Disabled","url":"https://feed.craftedsignal.io/briefs/2024-05-github-push-protection-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eThis threat brief addresses the deletion of global secret scanning rules within Bitbucket environments. Secret scanning is a crucial defense mechanism used to prevent sensitive information, such as API keys and passwords, from being committed to repositories. An attacker with global administration privileges could intentionally delete these rules to bypass security controls. This action could occur post-compromise, as part of an insider threat, or due to accidental misconfiguration. The impact of this activity centers around an increased risk of sensitive data exposure, which can lead to further compromise or data breaches. Defenders should monitor Bitbucket audit logs for such deletions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains valid credentials with global administrator privileges within the Bitbucket environment, possibly through credential stuffing or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Bitbucket web interface or uses the Bitbucket API with their compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the global secret scanning rule configuration page.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies and selects one or more global secret scanning rules currently in effect.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the deletion process for the selected rules, confirming the action when prompted.\u003c/li\u003e\n\u003cli\u003eBitbucket processes the deletion request, removing the rules from the global configuration.\u003c/li\u003e\n\u003cli\u003eThe system generates an audit log event indicating the deletion of the global secret scanning rule.\u003c/li\u003e\n\u003cli\u003eWith secret scanning disabled, developers may inadvertently commit secrets into Bitbucket repositories, making them available to the attacker.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of global secret scanning rules can have significant impact. Without active secret scanning, developers may unintentionally commit sensitive information (API keys, passwords, tokens) into Bitbucket repositories. This could lead to account takeovers, data breaches, or lateral movement within the organization\u0026rsquo;s infrastructure. The number of affected repositories and exposed secrets will vary depending on the scope of the attacker\u0026rsquo;s access and the activity of developers during the period when the rules were disabled.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the deletion of global secret scanning rules in Bitbucket audit logs, focusing on \u003ccode\u003eauditType.category: 'Global administration'\u003c/code\u003e and \u003ccode\u003eauditType.action: 'Global secret scanning rule deleted'\u003c/code\u003e (Sigma rule).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of global secret scanning rule deletion to determine if the action was authorized and performed by a legitimate user.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly review Bitbucket user permissions and roles to ensure that users have only the necessary level of access.\u003c/li\u003e\n\u003cli\u003eEnable \u0026ldquo;Basic\u0026rdquo; logging level, as required, to ensure the necessary audit events are generated (logsource definition).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T14:00:00Z","date_published":"2024-04-29T14:00:00Z","id":"/briefs/2024-04-bitbucket-secret-rule-delete/","summary":"An adversary with administrative privileges may delete global secret scanning rules in Bitbucket to impair defenses and exfiltrate sensitive data without detection.","title":"Bitbucket Global Secret Scanning Rule Deletion","url":"https://feed.craftedsignal.io/briefs/2024-04-bitbucket-secret-rule-delete/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket Server"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1685","bitbucket"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eAttackers can weaken an organization\u0026rsquo;s security posture by disabling or bypassing security controls within Bitbucket. This allows sensitive information, such as API keys, passwords, and other credentials, to be committed to the repository without detection. By adding a repository to the secret scanning exemption list, attackers can effectively disable a key preventative measure, making it easier to introduce and maintain compromised credentials within the codebase. This can lead to unauthorized access, data breaches, and other serious security incidents. This technique allows attackers to impair defenses, avoiding detection of secrets being committed to the repository.\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 Bitbucket account with repository administration privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the repository settings within Bitbucket.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the secret scanning configuration for the repository.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the option to add the repository to the exemption list for secret scanning.\u003c/li\u003e\n\u003cli\u003eThe attacker adds the repository to the exemption list, effectively disabling secret scanning for that repository.\u003c/li\u003e\n\u003cli\u003eThe attacker commits sensitive information (secrets, credentials) to the now-exempt repository.\u003c/li\u003e\n\u003cli\u003eThe secrets are committed without triggering secret scanning alerts.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the committed secrets to gain unauthorized access to other systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising secrets within a Bitbucket repository can lead to a variety of negative consequences, including unauthorized access to sensitive data, compromised infrastructure, and data breaches. While the exact number of affected organizations is unknown, the potential impact is significant for any organization using Bitbucket to store code and manage secrets. Successful exploitation allows attackers to move laterally within the network and escalate privileges.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Bitbucket Secret Scanning Exempt Repository Added\u0026rdquo; to your SIEM to detect when a repository is added to the secret scanning exemption list (logsource: bitbucket).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of repositories being added to the secret scanning exemption list to determine if the change was authorized.\u003c/li\u003e\n\u003cli\u003eEnsure that appropriate access controls are in place to prevent unauthorized users from modifying repository settings.\u003c/li\u003e\n\u003cli\u003eReview Bitbucket audit logs regularly to identify suspicious activity related to secret scanning configuration changes (logsource: bitbucket).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T12:00:00Z","date_published":"2024-04-29T12:00:00Z","id":"/briefs/2024-04-bitbucket-secret-scanning-exempt/","summary":"An attacker may attempt to disable or bypass secret scanning on a Bitbucket repository to avoid detection of committed secrets, potentially leading to credential compromise and subsequent unauthorized access.","title":"Bitbucket Repository Exempted from Secret Scanning","url":"https://feed.craftedsignal.io/briefs/2024-04-bitbucket-secret-scanning-exempt/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Bitbucket"],"_cs_severities":["low"],"_cs_tags":["attack.defense-impairment","attack.t1685"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eThe addition of a secret scanning allowlist rule to a Bitbucket project can be abused by malicious actors to bypass security controls. While not inherently malicious, this action can be exploited to weaken an organization\u0026rsquo;s security posture. Secret scanning tools are designed to prevent the accidental or intentional commit of sensitive information (API keys, passwords, etc.) into version control systems. By adding an allowlist rule, specific patterns or files can be excluded from these scans. This could be leveraged by an attacker who has gained access to a Bitbucket account or project to intentionally introduce secrets while avoiding detection. The activity is logged by Bitbucket\u0026rsquo;s audit logs, providing an opportunity for detection.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to a Bitbucket account with sufficient privileges to modify project settings.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the project settings within Bitbucket.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the secret scanning configuration for the project.\u003c/li\u003e\n\u003cli\u003eThe attacker adds a new allowlist rule, specifying a pattern or file to be excluded from secret scanning.\u003c/li\u003e\n\u003cli\u003eThe attacker commits code containing secrets that match the allowlist rule, effectively bypassing the secret scanning tool.\u003c/li\u003e\n\u003cli\u003eThe changes are pushed to the Bitbucket repository.\u003c/li\u003e\n\u003cli\u003eThe secrets remain undetected due to the allowlist rule.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the exposed secrets for further malicious activities, such as gaining access to other systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could lead to the exposure of sensitive information such as API keys, passwords, or other credentials. This can result in unauthorized access to internal systems, data breaches, and reputational damage. The number of affected projects depends on the scope of the attacker\u0026rsquo;s access and the configuration of the allowlist rule. The addition of the allowlist rule itself does not directly cause damage but creates a window of opportunity for the introduction and persistence of secrets within the codebase.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the addition of secret scanning allowlist rules (logsource: bitbucket, service: audit).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of allowlist rule additions to verify their legitimacy and business justification.\u003c/li\u003e\n\u003cli\u003eReview and enforce strict access controls for Bitbucket projects to minimize the risk of unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eEnable \u0026ldquo;Basic\u0026rdquo; log level in Bitbucket to ensure that the audit events required for detection are captured, as indicated in the rule definition.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T12:00:00Z","date_published":"2024-04-29T12:00:00Z","id":"/briefs/2024-04-bitbucket-secret-scanning-allowlist/","summary":"An adversary may impair defenses by adding a secret scanning allowlist rule for Bitbucket projects, potentially allowing secrets to be committed and exposed.","title":"Bitbucket Project Secret Scanning Allowlist Added","url":"https://feed.craftedsignal.io/briefs/2024-04-bitbucket-secret-scanning-allowlist/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.credential-access","attack.persistence","attack.defense-impairment","attack.t1548","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis activity involves the addition of a user to an Azure Active Directory group that possesses the ability to modify Conditional Access (CA) policies. Conditional Access policies are used to enforce authentication requirements based on various conditions (user, location, device, etc.). If an attacker gains the ability to modify these policies, they can weaken security controls to facilitate privilege escalation, credential access, persistence within the environment, and impair defenses. This type of attack can be initiated by an insider threat or external compromise of an account. The goal is to manipulate CA policies to bypass multi-factor authentication, grant unauthorized access, or maintain persistence.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a user account or service principal with sufficient privileges to manage group memberships in Azure AD. This could be achieved through credential compromise or other initial access vectors.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target Azure AD group that has permissions to manage Conditional Access policies. These groups are often used to delegate administrative control over CA policies.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the Azure portal, PowerShell, or the Azure AD Graph API/Microsoft Graph API to add a malicious user account to the target group.\u003c/li\u003e\n\u003cli\u003eThe Azure Audit Logs record the \u0026ldquo;Add member from group\u0026rdquo; event, indicating the change in group membership.\u003c/li\u003e\n\u003cli\u003eThe newly added malicious user inherits the group\u0026rsquo;s permissions, which includes the ability to view, create, modify, and delete Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies existing CA policies to weaken security controls. For example, they might exclude themselves from MFA requirements or grant access to sensitive resources without proper authorization.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages their modified CA policies to gain unauthorized access to sensitive data or resources.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new CA policies that ensure their continued access, even if their initial access is revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this attack chain can lead to significant compromise of an organization\u0026rsquo;s Azure environment. Attackers can bypass MFA, gain access to sensitive resources, establish persistent access, and impair security defenses. The extent of the damage depends on the permissions associated with the compromised group and the scope of the modified Conditional Access policies. This can lead to data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect additions of users to groups with CA policy modification access and tune for your environment.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure AD group memberships, especially for groups with administrative privileges (as detected by the Sigma rule).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all users, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege when assigning permissions to Azure AD groups.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to group membership changes and Conditional Access policy modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:00Z","date_published":"2024-01-03T18:22:00Z","id":"/briefs/2024-01-azure-group-add/","summary":"An attacker adds a user to a privileged Azure Active Directory group with permissions to modify Conditional Access policies, potentially leading to privilege escalation, credential access, persistence, and defense impairment.","title":"User Added to Group with Conditional Access Policy Modification Access","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-group-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Network Firewall"],"_cs_severities":["medium"],"_cs_tags":["attack.impact","attack.defense-impairment","attack.t1686.001"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may target Azure Network Firewall Policies to weaken an organization\u0026rsquo;s security posture. By modifying existing policies, adversaries can introduce rules that allow malicious traffic, disable existing protections, or create backdoors for future access. Deleting firewall policies altogether removes a critical layer of defense, potentially exposing internal resources to external threats. This activity is typically conducted after gaining initial access to the Azure environment through compromised credentials or other means. Monitoring for unauthorized changes to firewall policies is critical for maintaining network security and preventing potential data breaches or service disruptions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure environment, possibly through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Azure Network Firewall Policies using Azure CLI or PowerShell commands.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a firewall policy to modify or delete to achieve their objectives.\u003c/li\u003e\n\u003cli\u003eIf modifying, the attacker uses commands such as \u003ccode\u003eSet-AzNetworkFirewallPolicy\u003c/code\u003e or the Azure portal to alter the policy rules, potentially adding permissive rules or disabling existing restrictions.\u003c/li\u003e\n\u003cli\u003eIf deleting, the attacker uses commands such as \u003ccode\u003eRemove-AzNetworkFirewallPolicy\u003c/code\u003e or the Azure portal to remove the firewall policy entirely.\u003c/li\u003e\n\u003cli\u003eThe changes are applied to the Azure Network Firewall, impacting network traffic filtering.\u003c/li\u003e\n\u003cli\u003eThe attacker validates the effectiveness of the modified or deleted policy by testing network connectivity to previously protected resources.\u003c/li\u003e\n\u003cli\u003eThe attacker proceeds to exploit the newly exposed resources for data exfiltration, lateral movement, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification or deletion of Azure Network Firewall policies can lead to significant security breaches. Attackers may be able to bypass network segmentation, gain unauthorized access to sensitive data, disrupt critical services, or deploy malicious code within the network. The impact can range from data theft and financial loss to reputational damage and regulatory penalties. The number of affected resources depends on the scope of the compromised firewall policy and the attacker\u0026rsquo;s subsequent actions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Azure Network Firewall Policy Modified or Deleted\u0026rdquo; to detect unauthorized changes to firewall policies (logsource: azure, service: activitylogs).\u003c/li\u003e\n\u003cli\u003eReview user identities and user agents associated with detected events to determine if the changes were made by authorized personnel or malicious actors, as detailed in the false positives section.\u003c/li\u003e\n\u003cli\u003eEnable multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege by granting users only the necessary permissions to manage firewall policies.\u003c/li\u003e\n\u003cli\u003eImplement continuous monitoring and alerting for all Azure resources, including network firewalls, to detect suspicious activity and potential security breaches.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:12:00Z","date_published":"2024-01-03T18:12:00Z","id":"/briefs/2024-01-azure-firewall-policy-changes/","summary":"An adversary may modify or delete Azure Network Firewall Policies to impair defenses and potentially impact network security.","title":"Azure Network Firewall Policy Modification or Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-firewall-policy-changes/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1578.003","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAn attacker can create a new AD Health ADFS service and a fake server to spoof AD FS signing logs. This involves adding a rogue AD FS service to Azure AD Hybrid Health. Once the attacker no longer requires the spoofed logs, they may delete the service to remove traces of their activity or to hinder investigations. This is achieved via HTTP requests to Azure, specifically targeting the deletion of the AD FS service instance. This activity is logged within Azure Activity Logs, providing an opportunity for detection. Defenders should monitor for unexpected deletions of AD FS service instances within their Azure AD environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure tenant with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker provisions a new, rogue AD FS service within the Azure AD Hybrid Health Service.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a fake server or modifies an existing one to generate spoofed AD FS signing logs.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the spoofed logs to conduct malicious activity, potentially bypassing security controls.\u003c/li\u003e\n\u003cli\u003eOnce the malicious activity is complete, the attacker initiates the deletion of the rogue AD FS service.\u003c/li\u003e\n\u003cli\u003eThe attacker sends an HTTP request to Azure to delete the service using the \u003ccode\u003eMicrosoft.ADHybridHealthService/services/delete\u003c/code\u003e operation.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record the deletion event with CategoryValue set to \u0026lsquo;Administrative\u0026rsquo; and ResourceProviderValue as \u0026lsquo;Microsoft.ADHybridHealthService\u0026rsquo;.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of the AD FS service instance can hinder forensic investigations and potentially mask malicious activity within the Azure AD environment. This can lead to delayed incident response and make it more difficult to identify the source and scope of the attack. The impact depends on the sophistication of the attacker and the extent to which they leveraged the spoofed logs for malicious purposes.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the deletion of AD FS service instances in Azure AD Hybrid Health (Azure Activity Logs).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u003ccode\u003eMicrosoft.ADHybridHealthService/services/delete\u003c/code\u003e operations where the \u003ccode\u003eResourceId\u003c/code\u003e contains \u003ccode\u003eAdFederationService\u003c/code\u003e in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for unexpected or unauthorized modifications to AD FS service configurations.\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-03-azuread-adfs-delete/","summary":"Threat actors may delete Azure AD Hybrid Health AD FS service instances after using them to spoof AD FS signing logs for defense evasion.","title":"Azure AD Hybrid Health AD FS Service Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azuread-adfs-delete/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Config","AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1562.008","aws"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting the disabling of AWS Config, a service that continuously monitors and records AWS resource configurations. An attacker might disable AWS Config to evade detection and prevent auditing of their malicious activities within the AWS environment. By deleting delivery channels or stopping the configuration recorder, an attacker can effectively blind the security team to changes made to AWS resources. This activity, if unauthorized, signifies a significant attempt to impair defenses. This brief provides detections based on AWS CloudTrail logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing AWS Config resources to identify the delivery channel and configuration recorder.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eDeleteDeliveryChannel\u003c/code\u003e API call to stop the delivery of configuration changes to the designated S3 bucket or SNS topic.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eStopConfigurationRecorder\u003c/code\u003e API call to halt the recording of configuration changes for AWS resources.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions within the AWS environment without the activity being recorded by AWS Config.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to delete CloudTrail logs, if they have sufficient permissions, to further cover their tracks.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as deploying malicious infrastructure, exfiltrating data, or disrupting services, without immediate detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of AWS Config allows attackers to operate undetected within an AWS environment. This can lead to a delayed response to security incidents, resulting in more significant data breaches, financial losses, or reputational damage. The number of affected AWS accounts and the scope of the damage depend on the attacker\u0026rsquo;s objectives and the duration of the undetected activity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS Config Disabling Channel/Recorder\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized disabling of AWS Config resources.\u003c/li\u003e\n\u003cli\u003eReview AWS IAM policies to ensure that only authorized personnel have the necessary permissions to modify or disable AWS Config settings.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for any attempts to disable or modify AWS Config resources, referencing the \u003ccode\u003eeventSource\u003c/code\u003e and \u003ccode\u003eeventName\u003c/code\u003e fields in the provided Sigma rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-aws-config-disable/","summary":"Detection of AWS Config Service disabling, potentially indicating an attempt to impair defenses by stopping configuration recording and delivery.","title":"AWS Config Service Disabling Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-config-disable/"}],"language":"en","title":"CraftedSignal Threat Feed — Attack.defense-Impairment","version":"https://jsonfeed.org/version/1.1"}