Defense-Impairment — CraftedSignal Threat Feed

Bitbucket Global SSH Settings Changed

hello@craftedsignal.io — Fri, 01 Nov 2024 12:00:00 +0000

This brief focuses on the detection of unauthorized changes to Bitbucket’s global SSH settings. While the specific actor remains unknown, the modification of these settings is a significant security concern. The activity is detected via Bitbucket audit logs. Modification of global SSH settings can allow attackers to gain unauthorized access to repositories, potentially leading to code compromise, data breaches, or further lateral movement within the network. This activity is particularly important for organizations relying on Bitbucket for source code management and secure development workflows. The audit logs are the primary source of information, specifically focusing on events categorized as ‘Global administration’ with the action ‘SSH settings changed’.

Attack Chain

The attacker gains initial access to a Bitbucket account with administrative privileges, possibly through credential compromise or exploiting a vulnerability.
The attacker authenticates to the Bitbucket web interface.
The attacker navigates to the global SSH settings configuration page within the Bitbucket administration panel.
The attacker modifies global SSH settings, such as adding a new public key or changing authentication requirements.
Bitbucket logs the ‘SSH settings changed’ event in the audit logs under the ‘Global administration’ category.
The attacker leverages the modified SSH settings to clone repositories or push malicious code.
The attacker uses compromised code or data to move laterally within the organization’s network, targeting other systems and resources.

Impact

Successful modification of Bitbucket global SSH settings can allow unauthorized access to all repositories within the Bitbucket instance. This can lead to code theft, injection of malicious code, and data breaches. The impact may extend beyond the Bitbucket environment if the compromised code is deployed to production systems or used in other development processes. Organizations using Bitbucket for critical projects are at higher risk.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to Bitbucket global SSH settings in the audit logs.
Investigate any detected instances of “SSH settings changed” in the Bitbucket audit logs to determine the legitimacy of the changes.
Enforce multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to mitigate credential compromise as an initial access vector.
Review Bitbucket’s audit log configuration to ensure the “Advance” log level is enabled to capture the necessary audit events.

GitHub Push Protection Bypass Detection

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

This alert detects when a GitHub user bypasses the push protection mechanism designed to prevent secrets from being committed to a repository. GitHub’s push protection, part of its secret scanning feature, is intended to block commits containing sensitive information like API keys or credentials. A bypass indicates a deliberate attempt to circumvent this security measure. Successful bypass can lead to exposure of secrets, increasing the risk of unauthorized access and data breaches. The activity is logged within GitHub’s audit logs, provided that the audit log streaming feature is enabled.

Attack Chain

Developer attempts to commit code containing a secret to a GitHub repository.
GitHub’s push protection mechanism detects the secret and blocks the push.
The developer intentionally bypasses the push protection, potentially using allowed administrative activities to circumvent the block.
The code, including the secret, is successfully pushed to the repository.
The secret becomes exposed within the repository’s history.
Unauthorized actors may discover the exposed secret by scanning the repository.
Unauthorized actors may use the exposed secret to gain unauthorized access to systems or data.

Impact

A successful bypass of GitHub push protection can lead to secrets being exposed in a repository. This exposure can lead to unauthorized access to sensitive systems or data. The severity of the impact depends on the scope of access granted by the exposed secret, and the visibility of the repository.

Recommendation

Enable audit log streaming in GitHub to ensure relevant events are captured.
Deploy the Sigma rule “Github Push Protection Bypass Detected” to your SIEM and tune for your environment using GitHub audit logs.
Investigate any detected bypass events to determine the context and impact of the bypassed secret.

Azure Firewall Rule Collection Modification or Deletion

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

The modification or deletion of Azure Firewall rule collections (Application, NAT, and Network) can indicate malicious activity within an Azure environment. Threat actors may target these rules to bypass security controls, allowing unauthorized network traffic, enabling data exfiltration, or facilitating lateral movement. Monitoring these changes is crucial for maintaining the integrity of network security policies and detecting potential breaches. This activity directly impacts an organization’s ability to enforce its security posture, potentially exposing sensitive resources to unauthorized access.

Attack Chain

The attacker gains initial access to the Azure environment, potentially through compromised credentials or a vulnerability in an application.
The attacker enumerates existing Azure Firewall resources to identify rule collections (Application, NAT, and Network) that can be modified or deleted.
The attacker uses valid Azure credentials or exploits a misconfiguration to authenticate to the Azure Resource Manager API.
The attacker crafts a malicious request to modify the target rule collection, potentially altering allowed ports, IP addresses, or protocols.
Alternatively, the attacker crafts a request to delete an entire rule collection, effectively disabling its associated security controls.
The attacker sends the request to the Azure Resource Manager API, executing the change to the firewall configuration.
The modified or deleted rule collection now allows unauthorized traffic to bypass the firewall, potentially enabling lateral movement or data exfiltration.
The attacker exploits the newly opened network paths to achieve their final objective, such as deploying ransomware or accessing sensitive data.

Impact

Successful modification or deletion of Azure Firewall rule collections can have significant consequences. Unauthorized traffic could bypass security controls, enabling data exfiltration, lateral movement, or the deployment of malware. This could lead to data breaches, service disruptions, and financial losses. The impact depends on the scope of the modified or deleted rule collection and the resources it protects.

Recommendation

Deploy the Sigma rule “Azure Firewall Rule Collection Modified or Deleted” to your SIEM and tune for your environment to detect unauthorized changes to firewall configurations.
Review Azure Activity Logs for any events matching the operationName values specified in the Sigma rule to identify suspicious activity.
Implement multi-factor authentication (MFA) for all Azure accounts, especially those with permissions to manage firewall resources, to reduce the risk of credential compromise.
Regularly audit Azure role-based access control (RBAC) assignments to ensure the principle of least privilege is followed and that only authorized users have permissions to modify firewall configurations.

Spoofing AD FS Signing Logs via Azure AD Hybrid Health Service

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

This threat involves the creation of a rogue AD FS service instance within the Azure AD Hybrid Health Service to spoof AD FS signing logs. The attacker leverages the Azure AD Hybrid Health Service to create a new AD FS service and adds a fake server instance. This method allows the attacker to manipulate AD FS logging information without needing to compromise an on-premises AD FS server. The attack can be performed programmatically through HTTP requests to Azure, making it scalable and difficult to trace back to traditional on-premises attack vectors. This technique is particularly concerning because it undermines the integrity of AD FS logs, a crucial component for security monitoring and incident response.

Attack Chain

Compromise Azure Account: The attacker gains access to an Azure account, potentially through stolen credentials or exploiting a vulnerability.
Provision Rogue AD Health Service: The attacker programmatically provisions a new AD Health Service within the compromised Azure environment, specifically targeting AD FS.
Create Fake Server Instance: Within the newly created AD Health Service, the attacker creates a fake server instance, mimicking a legitimate AD FS server. The ResourceId will contain AdFederationService.
Manipulate Logs: Using the fake server instance, the attacker injects or alters AD FS signing logs, creating a false narrative of user authentication events.
Impersonate Users/Bypass Authentication: The attacker uses the manipulated logs to impersonate legitimate users or bypass authentication controls in applications relying on AD FS.
Lateral Movement/Privilege Escalation: Using the falsely acquired credentials or authentication tokens, the attacker moves laterally within the network, escalating privileges to access sensitive resources.
Data Exfiltration/System Compromise: The attacker exfiltrates sensitive data or gains control over critical systems using the compromised accounts and manipulated logs.

Impact

Successful exploitation allows attackers to spoof AD FS signing logs, potentially leading to unauthorized access, data breaches, and system compromise. The compromised logs can be used to cover the attacker’s tracks, making detection and incident response more difficult. Organizations relying on Azure AD Hybrid Health for AD FS monitoring are at risk of having their security posture undermined. The number of potential victims is substantial, as many organizations use AD FS for authentication and rely on its logs for security monitoring.

Recommendation

Deploy the Sigma rule Azure Active Directory Hybrid Health AD FS New Server to your SIEM to detect the creation of new AD FS server instances within the Azure AD Hybrid Health Service. Tune the rule for your environment to minimize false positives.
Monitor Azure Activity Logs for any unusual activity related to the Microsoft.ADHybridHealthService resource provider and the Microsoft.ADHybridHealthService/services/servicemembers/action operation, specifically the Administrative category.
Review and validate all AD FS server instances registered within the Azure AD Hybrid Health Service to ensure their legitimacy.
Implement multi-factor authentication (MFA) for all Azure accounts to prevent unauthorized access and mitigate the risk of initial compromise.

AWS CloudTrail Logging Disabled or Modified

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

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. By recording API calls, CloudTrail provides a history of AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. Attackers may attempt to disable or modify CloudTrail logging to remove traces of their malicious activity, hindering incident response and forensic investigations. This brief focuses on detecting actions that stop logging, update the trail configuration, or delete the trail altogether. These actions directly impact an organization’s ability to detect and respond to security incidents within their AWS environment.

Attack Chain

An attacker gains unauthorized access to an AWS account with sufficient privileges.
The attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.
The attacker executes the StopLogging API call against the CloudTrail service, effectively halting the recording of events.
Alternatively, the attacker may execute the UpdateTrail API call to modify the CloudTrail configuration. This could involve changing the S3 bucket destination, disabling log file validation, or altering event selectors to exclude specific events.
As another option, the attacker may execute the DeleteTrail API call, completely removing the CloudTrail configuration from the AWS account.
After disabling, modifying, or deleting the trail, the attacker proceeds with their malicious activities, knowing that their actions are less likely to be recorded and detected.
The attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.

Impact

Disabling or modifying CloudTrail logging can have severe consequences. It impairs an organization’s ability to detect and respond to security incidents in their AWS environment. Without proper logging, incident responders may struggle to determine the scope and impact of a breach, leading to delayed or ineffective remediation efforts. The inability to audit user activity can also hinder compliance efforts and potentially lead to regulatory penalties.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect StopLogging, UpdateTrail, and DeleteTrail events in CloudTrail logs.
Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.
Monitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.
Enable log file validation to ensure the integrity of CloudTrail logs.
Use AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.
Review AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.

Unauthorized Removal of Azure Conditional Access Policy

hello@craftedsignal.io — Tue, 09 Jan 2024 15:00:00 +0000

The unauthorized removal of a Conditional Access (CA) policy in Azure Active Directory can significantly weaken an organization’s security posture. Conditional Access policies are critical for enforcing multi-factor authentication, device compliance, and other security controls based on user, location, device, and application conditions. When a non-approved actor removes such a policy, it can open the door for privilege escalation, credential access, and persistence by malicious actors. This activity is often performed after an initial compromise to disable security controls and move laterally within the environment. Identifying and responding to such removals promptly is essential to maintain a strong security posture.

Attack Chain

Initial Access: The attacker gains initial access to an account with sufficient privileges to view and modify Azure Active Directory settings. This could be through phishing, password spraying, or exploiting a vulnerability.
Privilege Escalation: The attacker escalates privileges within Azure AD to gain the necessary permissions to manage Conditional Access policies. This might involve adding themselves to a privileged role or exploiting misconfigurations in existing roles.
Discovery: The attacker enumerates existing Conditional Access policies to identify targets for removal. They may focus on policies that enforce MFA or restrict access based on location.
Defense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.
Policy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a “Delete conditional access policy” event.
Credential Access: With the CA policy removed, the attacker may attempt to access sensitive resources or applications without MFA, potentially gaining access to credentials or sensitive data.
Persistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.
Lateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.

Impact

A successful removal of a Conditional Access policy can lead to widespread compromise. Attackers can bypass multi-factor authentication, gain unauthorized access to sensitive data, and escalate privileges within the organization. The impact can range from data breaches and financial losses to reputational damage and compliance violations. Depending on the scope of the compromised policy, the number of affected users could range from dozens to thousands.

Recommendation

Deploy the provided Sigma rule to detect the “Delete conditional access policy” event in Azure audit logs, indicating a CA policy removal.
Regularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.
Implement multi-factor authentication for all user accounts, especially those with administrative privileges.
Monitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.
Investigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.
Review and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.

GitHub Repository Archive Status Changed

hello@craftedsignal.io — Thu, 04 Jan 2024 15:00:00 +0000

This threat brief focuses on the detection of unauthorized changes to GitHub repository archive status. Attackers may archive or unarchive repositories as a means of persistence, to impact the availability of resources, or to impair defenses by hiding malicious code. The activity is logged within GitHub’s audit logs and can be monitored to identify potentially malicious actions. Monitoring these events can help organizations identify and respond to unauthorized modifications of their GitHub repositories. This is especially relevant for organizations relying heavily on GitHub for code management and collaboration.

Attack Chain

An attacker gains unauthorized access to a GitHub account with repository administration privileges.
The attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.
The attacker navigates to the settings page of a target repository.
The attacker modifies the repository’s archive status, either archiving or unarchiving it depending on their objective.
GitHub logs the ‘repo.archived’ or ‘repo.unarchived’ action in the organization’s audit logs.
(If archiving) Legitimate users may lose access to the repository and its code, causing disruption.
(If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.
The attacker may then attempt to exploit the unarchived repository for further malicious activities.

Impact

The impact of unauthorized repository archiving or unarchiving can range from temporary disruption of services to the reintroduction of vulnerable code. A successful attack could lead to data breaches, code compromise, or supply chain attacks. The number of affected repositories depends on the scope of the attacker’s access and objectives.

Recommendation

Deploy the Sigma rule “GitHub Repository Archive Status Changed” to your SIEM and tune for your environment. This rule detects the repo.archived and repo.unarchived actions in GitHub audit logs (logsource: github, service: audit).
Review GitHub audit logs regularly for unexpected repository archiving or unarchiving events.
Investigate any detected events to determine if the actions were authorized.

AWS GuardDuty Detector Deletion or Disablement

hello@craftedsignal.io — Wed, 03 Jan 2024 17:38:00 +0000

Attackers with sufficient AWS privileges may attempt to disable or delete AWS GuardDuty detectors to evade detection. GuardDuty is a threat detection service that monitors AWS accounts for malicious activity. Disabling it allows attackers to operate with less chance of being detected. This activity may occur post-compromise as part of a broader defense evasion strategy, or as a precursor to malicious activities. The deletion or disabling of GuardDuty detectors should be considered a critical event, warranting immediate investigation to verify legitimacy. The references suggest that this behavior has been observed in the wild and is documented across multiple security vendors.

Attack Chain

An attacker gains initial access to an AWS account through compromised credentials or other means (T1078).
The attacker enumerates existing GuardDuty detectors to identify the target for disabling or deletion (T1068).
The attacker authenticates to the AWS API using stolen credentials or an assumed role with sufficient permissions.
The attacker calls the DeleteDetector API to remove the GuardDuty detector entirely, erasing all existing findings (T1685.002).
Alternatively, the attacker calls the UpdateDetector API to disable the detector by setting the enable parameter to false (T1685.002).
AWS CloudTrail logs the DeleteDetector or UpdateDetector event with a Success or null error code.
With GuardDuty disabled, the attacker performs malicious actions such as lateral movement, data exfiltration, or resource compromise without immediate detection.
The attacker attempts to remove CloudTrail logs to further impair defenses (T1562.008).

Impact

A successful attack can lead to the complete loss of threat detection capabilities within the AWS environment. With GuardDuty disabled, malicious activities can go unnoticed, potentially leading to data breaches, unauthorized access, or resource compromise. The impact is significant because GuardDuty is a primary security control for many organizations using AWS. Depending on the attacker’s objectives, this could result in financial loss, reputational damage, or compliance violations. The references suggest that this is a known technique used by attackers to evade detection in AWS environments.

Recommendation

Deploy the Sigma rule “AWS GuardDuty Detector Deleted Or Updated” to your SIEM using AWS CloudTrail logs to detect attempts to disable or delete GuardDuty (logsource: aws, service: cloudtrail).
Investigate all instances of DeleteDetector and UpdateDetector events in CloudTrail, especially if initiated from unusual locations or IAM roles.
Implement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise (T1110).
Enforce the principle of least privilege by granting only necessary permissions to IAM roles (T1078).
Monitor CloudTrail logs for anomalies that could indicate malicious activity following a GuardDuty disablement.

Azure AD MFA Disabled to Bypass Authentication

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

Attackers may disable multi-factor authentication (MFA) within Azure Active Directory (Azure AD) to bypass security controls and gain unauthorized access to user accounts and resources. This activity can occur after initial compromise or as part of an insider threat scenario. The disabling of MFA typically manifests as a successful “Disable Strong Authentication” event within the Azure Active Directory activity logs. Defenders should monitor for these events, especially when initiated by accounts that do not typically perform administrative functions, as it may indicate malicious activity aimed at weakening the organization’s security posture and establishing persistence.

Attack Chain

An attacker gains initial access to an account with sufficient privileges in Azure AD, possibly through credential compromise or phishing.
The attacker authenticates to the Azure portal or uses Azure AD PowerShell modules.
The attacker identifies target user accounts for which they wish to disable MFA.
The attacker disables MFA for the targeted user accounts, resulting in an “Disable Strong Authentication.” event in the Azure AD activity logs.
The attacker attempts to authenticate to the targeted user accounts without MFA.
If successful, the attacker gains access to sensitive resources, such as email, files, or applications.
The attacker may then move laterally within the environment, accessing additional resources and escalating privileges.

Impact

Disabling MFA can significantly weaken an organization’s security posture, leading to unauthorized access to sensitive data and systems. Successful exploitation could result in data breaches, financial loss, and reputational damage. The impact is widespread, affecting any organization that relies on Azure AD for identity and access management, impacting potentially thousands of users and applications.

Recommendation

Deploy the provided Sigma rule to detect instances of MFA being disabled in Azure AD activity logs, focusing on “Disable Strong Authentication” events (eventSource: AzureActiveDirectory, eventName: 'Disable Strong Authentication.').
Investigate any detected instances of MFA being disabled, especially if the activity is performed by unusual accounts.
Implement multi-factor authentication (MFA) policies and monitor for unauthorized changes to MFA settings.
Review and enforce the principle of least privilege for Azure AD roles and permissions.
Enable logging for Azure Active Directory activity and sign-in logs (product: azure, service: activitylogs).

Remote Registry Lateral Movement via RPC Firewall

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

This threat brief focuses on detecting lateral movement attempts that leverage remote procedure calls (RPC) to modify registry keys on target systems. The technique abuses the remote registry protocol to achieve persistence or execute arbitrary code. Defenders can use RPC Firewall logs to identify and block this activity, specifically by monitoring for calls to the Registry Remote Protocol (MS-RRP) interface with specific operation numbers indicative of registry manipulation. This activity is often associated with post-exploitation phases, where attackers attempt to gain a foothold and expand their control within a network. The RPC Firewall detailed in this brief allows for monitoring and blocking of this behavior.

Attack Chain

The attacker gains initial access to a system within the network (e.g., through phishing or exploiting a vulnerability).
The attacker discovers accessible target systems on the network.
The attacker attempts to connect to the target system’s RPC endpoint for the Remote Registry service (UUID 338cd001-2244-31f1-aaaa-900038001003).
The attacker uses RPC calls with operation numbers 6, 7, 8, 13, 18, 19, 21, 22, 23, or 35 to interact with the registry remotely.
The attacker modifies registry keys related to startup programs or services.
The attacker triggers the execution of malicious code through the modified registry keys, achieving persistence.
The malicious code executes, allowing the attacker to perform actions such as data exfiltration or further lateral movement.

Impact

Successful exploitation allows attackers to achieve persistence, escalate privileges, and move laterally within the network. This can lead to data theft, system compromise, and disruption of services. If lateral movement succeeds, attackers can gain control over critical assets, leading to significant financial and reputational damage.

Recommendation

Install and configure RPC Firewall on all critical systems, auditing RPC calls to the Registry Remote Protocol interface (UUID 338cd001-2244-31f1-aaaa-900038001003) as described in the definition within the logsource section.
Deploy the provided Sigma rule to your SIEM to detect anomalous RPC calls related to registry modification as outlined in the detection section.
Investigate and block any identified malicious RPC connections using RPC Firewall based on the logs generated and reviewed from the deployed Sigma rule.

AWS GuardDuty IP Set Manipulation for Defense Impairment

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

An adversary may attempt to impair an organization’s defenses by manipulating the IP sets within AWS GuardDuty. GuardDuty IP sets are used to whitelist trusted IPs or blacklist known malicious IPs. By modifying these lists, an attacker can effectively disable alerts for their malicious activity, allowing them to operate undetected within the AWS environment. This activity is typically performed after initial access and lateral movement, as the attacker seeks to maintain persistence and evade detection. The changes could be made via the AWS Management Console, CLI, or programmatically through the AWS API, making it difficult to immediately recognize the change as malicious.

Attack Chain

The attacker gains initial access to the AWS environment through compromised credentials or an exposed IAM role.
The attacker enumerates existing GuardDuty IP sets using the ListIPSets API call to identify potential targets for modification.
The attacker creates a new IP set using CreateIPSet API call, which contains malicious IPs they intend to whitelist, or the legitimate IPs of internal scanners they wish to mimic.
GuardDuty validates the uploaded IP set list.
The attacker activates the newly created IP set within GuardDuty, making it the active trusted or threat list.
The attacker conducts malicious activity, such as lateral movement, data exfiltration, or resource exploitation, from the whitelisted IPs.
GuardDuty, configured with the modified IP sets, does not generate alerts for activity originating from the whitelisted IPs.
The attacker maintains persistence and achieves their objective (e.g., data theft, denial of service) without detection.

Impact

A successful attack can lead to significant data breaches, resource compromise, and prolonged unauthorized access. The modification of IP sets within GuardDuty directly impairs the ability of security teams to detect and respond to ongoing threats. By whitelisting malicious IPs, attackers can bypass security controls and operate freely within the AWS environment. The number of affected organizations depends on the scope of the compromised AWS accounts and the extent to which GuardDuty is relied upon for threat detection.

Recommendation

Deploy the Sigma rule “AWS GuardDuty IP Set Creation” to your SIEM to detect suspicious creation of IP sets in GuardDuty (logsource: aws, service: cloudtrail).
Investigate any changes to GuardDuty configurations, particularly the creation or modification of IP sets, using CloudTrail logs.
Implement multi-factor authentication (MFA) for all AWS accounts and IAM roles to prevent unauthorized access (related to initial access).
Regularly review and audit IAM roles and permissions to minimize the blast radius of compromised credentials.