Attack.defense-Impairment — CraftedSignal Threat Feed

Bitbucket Secret Scanning Rule Deleted

hello@craftedsignal.io — Sun, 17 Nov 2024 14:22:00 +0000

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

Attack Chain

The attacker compromises a Bitbucket account with project or repository administrator privileges.
The attacker authenticates to the Bitbucket web interface or uses the Bitbucket API with the compromised account.
The attacker navigates to the project or repository settings where secret scanning rules are configured.
The attacker identifies the secret scanning rules in place.
The attacker initiates the deletion of one or more secret scanning rules through the Bitbucket web interface or API.
Bitbucket processes the request and removes the specified secret scanning rules.
The attacker (or another compromised account) commits code containing secrets, which are no longer detected due to the deleted rules.
The committed secrets are then potentially used for lateral movement, data exfiltration, or other malicious activities.

Impact

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

Recommendation

Monitor Bitbucket audit logs for events related to secret scanning rule deletions, using the provided Sigma rule to detect suspicious activity (bitbucket_audit_secret_scanning_rule_deleted.yml).
Implement multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to reduce the risk of account compromise.
Enforce the principle of least privilege, ensuring that users only have the necessary permissions to perform their tasks.
Regularly review and audit Bitbucket user permissions and access controls.
Implement strong password policies and encourage users to use unique, complex passwords.

New AWS Network ACL Entry Creation Detected

hello@craftedsignal.io — Sat, 26 Oct 2024 14:27:00 +0000

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

Attack Chain

An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
The attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).
The attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The CreateNetworkAclEntry event is logged in CloudTrail.
The new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.
Alternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.
The attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.
The attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.

Impact

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

Recommendation

Deploy the Sigma rule “New Network ACL Entry Added” to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).
Investigate any CreateNetworkAclEntry events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.
Review and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.
Monitor CloudTrail logs for other related events, such as DeleteNetworkAclEntry or ReplaceNetworkAclEntry, which may indicate further tampering with network security configurations.

Bitbucket Audit Log Configuration Modified

hello@craftedsignal.io — Sat, 26 Oct 2024 12:00:00 +0000

Attackers 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 “Basic” log level configuration.

Attack Chain

An attacker gains unauthorized access to a Bitbucket instance, potentially through compromised credentials or exploiting a vulnerability.
The attacker authenticates to the Bitbucket web interface or uses the Bitbucket API.
The attacker navigates to the audit log configuration settings within the Bitbucket administration panel.
The attacker modifies the audit log settings, such as disabling logging for specific event categories or reducing the log retention period.
The Bitbucket server processes the configuration change request.
Audit events related to the configuration change are logged (if auditing is still enabled for such events).
The attacker performs malicious activities, such as creating unauthorized repositories or exfiltrating source code, with reduced risk of detection.

Impact

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

Recommendation

Deploy the “Bitbucket Audit Log Configuration Updated” Sigma rule to your SIEM to detect changes to audit log configurations (logsource: bitbucket, service: audit).
Ensure Bitbucket audit logging is enabled at the “Basic” level or higher, as lower levels may not capture configuration changes (logsource: bitbucket, service: audit).
Investigate any detected instances of audit log configuration changes to determine if they are authorized (Sigma rule: “Bitbucket Audit Log Configuration Updated”).

GitHub Secret Scanning Feature Disabled

hello@craftedsignal.io — Fri, 19 Jul 2024 00:00:00 +0000

The disabling of GitHub’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’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.

Attack Chain

An attacker gains unauthorized access to a GitHub account with administrative privileges for either an organization or a specific repository.
The attacker navigates to the security settings within the organization or repository.
The attacker identifies the “Secret scanning” feature or related settings (e.g., “Secret scanning for new repositories”).
The attacker disables the secret scanning feature using the GitHub UI or API. This generates an audit log event.
The attacker commits code containing secrets to the repository.
Because secret scanning is disabled, the secrets are not detected or flagged by GitHub.
The attacker leverages the committed secrets to gain unauthorized access to other systems or data.
The attacker achieves their final objective, which could include data exfiltration, lateral movement, or service disruption.

Impact

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

Recommendation

Deploy the “Github Secret Scanning Feature Disabled” Sigma rule to your SIEM to detect unauthorized disabling of the feature (logsource: github, service: audit).
Investigate any detected instances of secret scanning being disabled to determine if they were authorized administrative actions.
Enable audit log streaming to ensure the required logs are available (see logsource definition).
Review GitHub access controls to ensure that only authorized personnel have the ability to modify secret scanning settings.

Unauthorized Modification of Azure Conditional Access Policy

hello@craftedsignal.io — Wed, 29 May 2024 12:00:00 +0000

Compromised 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 “Update conditional access policy” 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.

Attack Chain

Initial Access: The attacker gains initial access through compromised credentials or other means (not specified in source).
Privilege Escalation: 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).
Policy Enumeration: The attacker enumerates existing Conditional Access policies to identify targets for modification using tools like Azure PowerShell or the Azure portal.
Policy Modification: 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.
Persistence: 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.
Credential Access: With weakened MFA or other access controls, the attacker gains easier access to sensitive credentials.
Defense Impairment: The modification of CA policies impairs the organization’s defense mechanisms, making it easier for the attacker to perform malicious activities undetected.

Impact

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

Recommendation

Deploy the “CA Policy Updated by Non Approved Actor” Sigma rule to your SIEM to detect unauthorized modifications to Conditional Access policies within your Azure environment.
Review the properties.message field in the Azure Audit Logs for “Update conditional access policy” events and compare “old” vs “new” values to understand the nature of the changes.
Implement strict role-based access control (RBAC) to limit the number of users who can modify Conditional Access policies.
Investigate 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.
Enable 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).

Azure AD Root Certificate Authority Added for Passwordless Authentication

hello@craftedsignal.io — Wed, 08 May 2024 18:22:00 +0000

The 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 TrustedCAsForPasswordlessAuth setting, as this could indicate a compromised administrator account or an insider threat attempting to establish a backdoor.

Attack Chain

Compromise an Azure AD administrator account with sufficient privileges to modify tenant-wide settings. This may be achieved through phishing, credential stuffing, or exploiting vulnerabilities.
The attacker authenticates to the Azure portal or uses PowerShell cmdlets to interact with Azure AD.
The attacker executes commands to add a new, attacker-controlled root certificate authority to the TrustedCAsForPasswordlessAuth setting. This involves modifying the Company Information object.
The attacker generates or obtains a certificate signed by the newly added root CA.
The attacker uses the certificate to authenticate to Azure AD as a targeted user, bypassing password requirements and multi-factor authentication.
The attacker gains access to the targeted user’s resources, such as email, files, and applications.
The attacker escalates privileges within the Azure AD tenant by impersonating highly privileged users or roles.
The attacker maintains persistent access to the Azure AD tenant, even if the compromised administrator account is remediated.

Impact

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

Recommendation

Deploy the Sigma rule “New Root Certificate Authority Added” to your SIEM to detect unauthorized modifications to the TrustedCAsForPasswordlessAuth setting (rule).
Review Azure AD audit logs regularly for suspicious activity related to the “Set Company Information” operation (logsource).
Implement multi-factor authentication (MFA) for all Azure AD accounts, including administrators, but understand that CBA can bypass it.
Enforce the principle of least privilege and restrict the number of accounts with permissions to modify tenant-wide settings.
Monitor for the use of certificates signed by unknown or untrusted CAs to authenticate to Azure AD.
Consult the SpecterOps and Goodworkaround articles for more information on certificate-based authentication abuse in Azure AD (references).

GitHub Push Protection Disabled

hello@craftedsignal.io — Fri, 03 May 2024 12:00:00 +0000

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

Attack Chain

An attacker gains unauthorized access to a GitHub account with administrative privileges, or a legitimate administrator performs the action.
The attacker navigates to the organization, enterprise, or repository settings in GitHub.
The attacker locates the “Secret scanning” or “Push protection” configuration section.
The attacker disables the push protection feature for the organization, enterprise, or specific repositories. This can be done via the GitHub UI or API.
GitHub audit logs record the event with the actions business_secret_scanning_custom_pattern_push_protection.disabled, business_secret_scanning_push_protection.disable, org.secret_scanning_custom_pattern_push_protection_disabled, etc..
Developers unknowingly or intentionally commit code containing secrets or sensitive data to the affected repositories.
The secrets are pushed to the remote repository without being blocked by push protection.
The exposed secrets can be discovered by malicious actors, leading to account compromise, data breaches, or other security incidents.

Impact

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

Recommendation

Deploy the Sigma rule “Github Push Protection Disabled” to your SIEM and tune for your environment to detect when push protection is disabled.
Investigate any detected instances of push protection being disabled in the GitHub audit logs (logsource: github, service: audit) to verify the legitimacy of the action.
Enforce multi-factor authentication (MFA) for all GitHub accounts, especially those with administrative privileges, to prevent unauthorized access.
Regularly review and audit GitHub organization and repository settings to ensure that push protection is enabled and properly configured.

Bitbucket Global Secret Scanning Rule Deletion

hello@craftedsignal.io — Mon, 29 Apr 2024 14:00:00 +0000

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

Attack Chain

The attacker gains valid credentials with global administrator privileges within the Bitbucket environment, possibly through credential stuffing or phishing.
The attacker authenticates to the Bitbucket web interface or uses the Bitbucket API with their compromised credentials.
The attacker navigates to the global secret scanning rule configuration page.
The attacker identifies and selects one or more global secret scanning rules currently in effect.
The attacker initiates the deletion process for the selected rules, confirming the action when prompted.
Bitbucket processes the deletion request, removing the rules from the global configuration.
The system generates an audit log event indicating the deletion of the global secret scanning rule.
With secret scanning disabled, developers may inadvertently commit secrets into Bitbucket repositories, making them available to the attacker.

Impact

Successful 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’s infrastructure. The number of affected repositories and exposed secrets will vary depending on the scope of the attacker’s access and the activity of developers during the period when the rules were disabled.

Recommendation

Deploy the provided Sigma rule to detect the deletion of global secret scanning rules in Bitbucket audit logs, focusing on auditType.category: 'Global administration' and auditType.action: 'Global secret scanning rule deleted' (Sigma rule).
Investigate any detected instances of global secret scanning rule deletion to determine if the action was authorized and performed by a legitimate user.
Implement multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to reduce the risk of credential compromise.
Regularly review Bitbucket user permissions and roles to ensure that users have only the necessary level of access.
Enable “Basic” logging level, as required, to ensure the necessary audit events are generated (logsource definition).

Bitbucket Repository Exempted from Secret Scanning

hello@craftedsignal.io — Mon, 29 Apr 2024 12:00:00 +0000

Attackers can weaken an organization’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.

Attack Chain

An attacker gains unauthorized access to a Bitbucket account with repository administration privileges.
The attacker navigates to the repository settings within Bitbucket.
The attacker accesses the secret scanning configuration for the repository.
The attacker identifies the option to add the repository to the exemption list for secret scanning.
The attacker adds the repository to the exemption list, effectively disabling secret scanning for that repository.
The attacker commits sensitive information (secrets, credentials) to the now-exempt repository.
The secrets are committed without triggering secret scanning alerts.
The attacker uses the committed secrets to gain unauthorized access to other systems or data.

Impact

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

Recommendation

Deploy the Sigma rule “Bitbucket Secret Scanning Exempt Repository Added” to your SIEM to detect when a repository is added to the secret scanning exemption list (logsource: bitbucket).
Investigate any detected instances of repositories being added to the secret scanning exemption list to determine if the change was authorized.
Ensure that appropriate access controls are in place to prevent unauthorized users from modifying repository settings.
Review Bitbucket audit logs regularly to identify suspicious activity related to secret scanning configuration changes (logsource: bitbucket).

Bitbucket Project Secret Scanning Allowlist Added

hello@craftedsignal.io — Mon, 29 Apr 2024 12:00:00 +0000

The 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’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’s audit logs, providing an opportunity for detection.

Attack Chain

The attacker gains unauthorized access to a Bitbucket account with sufficient privileges to modify project settings.
The attacker navigates to the project settings within Bitbucket.
The attacker accesses the secret scanning configuration for the project.
The attacker adds a new allowlist rule, specifying a pattern or file to be excluded from secret scanning.
The attacker commits code containing secrets that match the allowlist rule, effectively bypassing the secret scanning tool.
The changes are pushed to the Bitbucket repository.
The secrets remain undetected due to the allowlist rule.
The attacker leverages the exposed secrets for further malicious activities, such as gaining access to other systems or data.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the addition of secret scanning allowlist rules (logsource: bitbucket, service: audit).
Investigate any detected instances of allowlist rule additions to verify their legitimacy and business justification.
Review and enforce strict access controls for Bitbucket projects to minimize the risk of unauthorized modifications.
Enable “Basic” log level in Bitbucket to ensure that the audit events required for detection are captured, as indicated in the rule definition.

User Added to Group with Conditional Access Policy Modification Access

hello@craftedsignal.io — Wed, 03 Jan 2024 18:22:00 +0000

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

Attack Chain

The 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.
The 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.
The 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.
The Azure Audit Logs record the “Add member from group” event, indicating the change in group membership.
The newly added malicious user inherits the group’s permissions, which includes the ability to view, create, modify, and delete Conditional Access policies.
The 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.
The attacker leverages their modified CA policies to gain unauthorized access to sensitive data or resources.
The attacker establishes persistence by creating new CA policies that ensure their continued access, even if their initial access is revoked.

Impact

Successful exploitation of this attack chain can lead to significant compromise of an organization’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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect additions of users to groups with CA policy modification access and tune for your environment.
Regularly review and audit Azure AD group memberships, especially for groups with administrative privileges (as detected by the Sigma rule).
Implement multi-factor authentication for all users, especially those with administrative privileges.
Enforce the principle of least privilege when assigning permissions to Azure AD groups.
Monitor Azure AD audit logs for suspicious activity related to group membership changes and Conditional Access policy modifications.

Azure Network Firewall Policy Modification or Deletion

hello@craftedsignal.io — Wed, 03 Jan 2024 18:12:00 +0000

Attackers may target Azure Network Firewall Policies to weaken an organization’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.

Attack Chain

The attacker gains initial access to the Azure environment, possibly through compromised credentials or a vulnerability in a deployed application.
The attacker enumerates existing Azure Network Firewall Policies using Azure CLI or PowerShell commands.
The attacker identifies a firewall policy to modify or delete to achieve their objectives.
If modifying, the attacker uses commands such as Set-AzNetworkFirewallPolicy or the Azure portal to alter the policy rules, potentially adding permissive rules or disabling existing restrictions.
If deleting, the attacker uses commands such as Remove-AzNetworkFirewallPolicy or the Azure portal to remove the firewall policy entirely.
The changes are applied to the Azure Network Firewall, impacting network traffic filtering.
The attacker validates the effectiveness of the modified or deleted policy by testing network connectivity to previously protected resources.
The attacker proceeds to exploit the newly exposed resources for data exfiltration, lateral movement, or other malicious activities.

Impact

Successful 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’s subsequent actions.

Recommendation

Implement the Sigma rule “Azure Network Firewall Policy Modified or Deleted” to detect unauthorized changes to firewall policies (logsource: azure, service: activitylogs).
Review 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.
Enable multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.
Enforce the principle of least privilege by granting users only the necessary permissions to manage firewall policies.
Implement continuous monitoring and alerting for all Azure resources, including network firewalls, to detect suspicious activity and potential security breaches.

Azure AD Hybrid Health AD FS Service Deletion for Defense Evasion

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

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

Attack Chain

The attacker gains initial access to an Azure tenant with sufficient privileges.
The attacker provisions a new, rogue AD FS service within the Azure AD Hybrid Health Service.
The attacker creates a fake server or modifies an existing one to generate spoofed AD FS signing logs.
The attacker uses the spoofed logs to conduct malicious activity, potentially bypassing security controls.
Once the malicious activity is complete, the attacker initiates the deletion of the rogue AD FS service.
The attacker sends an HTTP request to Azure to delete the service using the Microsoft.ADHybridHealthService/services/delete operation.
The Azure Activity Logs record the deletion event with CategoryValue set to ‘Administrative’ and ResourceProviderValue as ‘Microsoft.ADHybridHealthService’.

Impact

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

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the deletion of AD FS service instances in Azure AD Hybrid Health (Azure Activity Logs).
Investigate any detected instances of Microsoft.ADHybridHealthService/services/delete operations where the ResourceId contains AdFederationService in the Azure Activity Logs.
Monitor Azure Activity Logs for unexpected or unauthorized modifications to AD FS service configurations.

AWS Config Service Disabling Detection

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

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

Attack Chain

An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.
The attacker enumerates existing AWS Config resources to identify the delivery channel and configuration recorder.
The attacker executes the DeleteDeliveryChannel API call to stop the delivery of configuration changes to the designated S3 bucket or SNS topic.
The attacker executes the StopConfigurationRecorder API call to halt the recording of configuration changes for AWS resources.
The attacker performs malicious actions within the AWS environment without the activity being recorded by AWS Config.
The attacker may attempt to delete CloudTrail logs, if they have sufficient permissions, to further cover their tracks.
The attacker achieves their objective, such as deploying malicious infrastructure, exfiltrating data, or disrupting services, without immediate detection.

Impact

Successful 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’s objectives and the duration of the undetected activity.

Recommendation

Deploy the Sigma rule “AWS Config Disabling Channel/Recorder” to your SIEM and tune for your environment to detect unauthorized disabling of AWS Config resources.
Review AWS IAM policies to ensure that only authorized personnel have the necessary permissions to modify or disable AWS Config settings.
Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise.
Monitor CloudTrail logs for any attempts to disable or modify AWS Config resources, referencing the eventSource and eventName fields in the provided Sigma rule.