{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/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":["lateral-movement","defense-impairment","bitbucket"],"_cs_type":"advisory","_cs_vendors":["Atlassian"],"content_html":"\u003cp\u003eThis brief focuses on the detection of unauthorized changes to Bitbucket\u0026rsquo;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 \u0026lsquo;Global administration\u0026rsquo; with the action \u0026lsquo;SSH settings changed\u0026rsquo;.\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 Bitbucket account with administrative privileges, possibly through credential compromise or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Bitbucket web interface.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the global SSH settings configuration page within the Bitbucket administration panel.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies global SSH settings, such as adding a new public key or changing authentication requirements.\u003c/li\u003e\n\u003cli\u003eBitbucket logs the \u0026lsquo;SSH settings changed\u0026rsquo; event in the audit logs under the \u0026lsquo;Global administration\u0026rsquo; category.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified SSH settings to clone repositories or push malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker uses compromised code or data to move laterally within the organization\u0026rsquo;s network, targeting other systems and resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\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 unauthorized changes to Bitbucket global SSH settings in the audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u0026ldquo;SSH settings changed\u0026rdquo; in the Bitbucket audit logs to determine the legitimacy of the changes.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all Bitbucket accounts, especially those with administrative privileges, to mitigate credential compromise as an initial access vector.\u003c/li\u003e\n\u003cli\u003eReview Bitbucket\u0026rsquo;s audit log configuration to ensure the \u0026ldquo;Advance\u0026rdquo; log level is enabled to capture the necessary audit events.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-01T12:00:00Z","date_published":"2024-11-01T12:00:00Z","id":"/briefs/2024-11-bitbucket-ssh-change/","summary":"An attacker modifies Bitbucket global SSH settings to potentially enable unauthorized access and lateral movement.","title":"Bitbucket Global SSH Settings Changed","url":"https://feed.craftedsignal.io/briefs/2024-11-bitbucket-ssh-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["low"],"_cs_tags":["defense-impairment","t1685","github"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eThis alert detects when a GitHub user bypasses the push protection mechanism designed to prevent secrets from being committed to a repository. GitHub\u0026rsquo;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\u0026rsquo;s audit logs, provided that the audit log streaming feature is enabled.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eDeveloper attempts to commit code containing a secret to a GitHub repository.\u003c/li\u003e\n\u003cli\u003eGitHub\u0026rsquo;s push protection mechanism detects the secret and blocks the push.\u003c/li\u003e\n\u003cli\u003eThe developer intentionally bypasses the push protection, potentially using allowed administrative activities to circumvent the block.\u003c/li\u003e\n\u003cli\u003eThe code, including the secret, is successfully pushed to the repository.\u003c/li\u003e\n\u003cli\u003eThe secret becomes exposed within the repository\u0026rsquo;s history.\u003c/li\u003e\n\u003cli\u003eUnauthorized actors may discover the exposed secret by scanning the repository.\u003c/li\u003e\n\u003cli\u003eUnauthorized actors may use the exposed secret to gain unauthorized access to systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable audit log streaming in GitHub to ensure relevant events are captured.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Github Push Protection Bypass Detected\u0026rdquo; to your SIEM and tune for your environment using GitHub audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected bypass events to determine the context and impact of the bypassed secret.\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-github-push-protection-bypass/","summary":"Detection of a GitHub user bypassing push protection, potentially leading to the exposure of secrets.","title":"GitHub Push Protection Bypass Detection","url":"https://feed.craftedsignal.io/briefs/2024-04-github-push-protection-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Firewall"],"_cs_severities":["medium"],"_cs_tags":["azure","firewall","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe 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\u0026rsquo;s ability to enforce its security posture, potentially exposing sensitive resources to unauthorized access.\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, potentially through compromised credentials or a vulnerability in an application.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Azure Firewall resources to identify rule collections (Application, NAT, and Network) that can be modified or deleted.\u003c/li\u003e\n\u003cli\u003eThe attacker uses valid Azure credentials or exploits a misconfiguration to authenticate to the Azure Resource Manager API.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious request to modify the target rule collection, potentially altering allowed ports, IP addresses, or protocols.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker crafts a request to delete an entire rule collection, effectively disabling its associated security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the request to the Azure Resource Manager API, executing the change to the firewall configuration.\u003c/li\u003e\n\u003cli\u003eThe modified or deleted rule collection now allows unauthorized traffic to bypass the firewall, potentially enabling lateral movement or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the newly opened network paths to achieve their final objective, such as deploying ransomware or accessing sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Firewall Rule Collection Modified or Deleted\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized changes to firewall configurations.\u003c/li\u003e\n\u003cli\u003eReview Azure Activity Logs for any events matching the \u003ccode\u003eoperationName\u003c/code\u003e values specified in the Sigma rule to identify suspicious activity.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts, especially those with permissions to manage firewall resources, to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-31T12:00:00Z","date_published":"2024-01-31T12:00:00Z","id":"/briefs/2024-01-azure-firewall-rule-collection-modification/","summary":"An attacker may modify or delete Azure Firewall rule collections (Application, NAT, and Network) to impair defenses and potentially enable malicious traffic.","title":"Azure Firewall Rule Collection Modification or Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-firewall-rule-collection-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory","AD FS"],"_cs_severities":["medium"],"_cs_tags":["cloud","azure","adfs","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCompromise Azure Account:\u003c/strong\u003e The attacker gains access to an Azure account, potentially through stolen credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProvision Rogue AD Health Service:\u003c/strong\u003e The attacker programmatically provisions a new AD Health Service within the compromised Azure environment, specifically targeting AD FS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCreate Fake Server Instance:\u003c/strong\u003e Within the newly created AD Health Service, the attacker creates a fake server instance, mimicking a legitimate AD FS server. The \u003ccode\u003eResourceId\u003c/code\u003e will contain \u003ccode\u003eAdFederationService\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eManipulate Logs:\u003c/strong\u003e Using the fake server instance, the attacker injects or alters AD FS signing logs, creating a false narrative of user authentication events.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpersonate Users/Bypass Authentication:\u003c/strong\u003e The attacker uses the manipulated logs to impersonate legitimate users or bypass authentication controls in applications relying on AD FS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement/Privilege Escalation:\u003c/strong\u003e Using the falsely acquired credentials or authentication tokens, the attacker moves laterally within the network, escalating privileges to access sensitive resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/System Compromise:\u003c/strong\u003e The attacker exfiltrates sensitive data or gains control over critical systems using the compromised accounts and manipulated logs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure Active Directory Hybrid Health AD FS New Server\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for any unusual activity related to the \u003ccode\u003eMicrosoft.ADHybridHealthService\u003c/code\u003e resource provider and the \u003ccode\u003eMicrosoft.ADHybridHealthService/services/servicemembers/action\u003c/code\u003e operation, specifically the \u003ccode\u003eAdministrative\u003c/code\u003e category.\u003c/li\u003e\n\u003cli\u003eReview and validate all AD FS server instances registered within the Azure AD Hybrid Health Service to ensure their legitimacy.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to prevent unauthorized access and mitigate the risk of initial compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-azuread-adfs-spoofing/","summary":"A threat actor can create a new, rogue AD Health ADFS service within Azure and then create a fake server instance, which can be leveraged to spoof AD FS signing logs without compromising on-prem AD FS servers.","title":"Spoofing AD FS Signing Logs via Azure AD Hybrid Health Service","url":"https://feed.craftedsignal.io/briefs/2024-01-23-azuread-adfs-spoofing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail"],"_cs_severities":["medium"],"_cs_tags":["defense-impairment","cloud"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAWS 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\u0026rsquo;s ability to detect and respond to security incidents within their AWS environment.\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 with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eStopLogging\u003c/code\u003e API call against the CloudTrail service, effectively halting the recording of events.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker may execute the \u003ccode\u003eUpdateTrail\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eAs another option, the attacker may execute the \u003ccode\u003eDeleteTrail\u003c/code\u003e API call, completely removing the CloudTrail configuration from the AWS account.\u003c/li\u003e\n\u003cli\u003eAfter 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.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling or modifying CloudTrail logging can have severe consequences. It impairs an organization\u0026rsquo;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.\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 \u003ccode\u003eStopLogging\u003c/code\u003e, \u003ccode\u003eUpdateTrail\u003c/code\u003e, and \u003ccode\u003eDeleteTrail\u003c/code\u003e events in CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.\u003c/li\u003e\n\u003cli\u003eEnable log file validation to ensure the integrity of CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eUse AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.\u003c/li\u003e\n\u003cli\u003eReview AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-aws-cloudtrail-disable-logging/","summary":"Detection of AWS CloudTrail being disabled, deleted, or updated by an adversary to impair defenses and evade detection.","title":"AWS CloudTrail Logging Disabled or Modified","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-cloudtrail-disable-logging/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation","credential-access","persistence","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized removal of a Conditional Access (CA) policy in Azure Active Directory can significantly weaken an organization\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial 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.\u003c/li\u003e\n\u003cli\u003ePrivilege 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.\u003c/li\u003e\n\u003cli\u003eDiscovery: 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.\u003c/li\u003e\n\u003cli\u003eDefense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.\u003c/li\u003e\n\u003cli\u003ePolicy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a \u0026ldquo;Delete conditional access policy\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eCredential 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.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the \u0026ldquo;Delete conditional access policy\u0026rdquo; event in Azure audit logs, indicating a CA policy removal.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all user accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eReview and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"/briefs/2024-01-09-azure-ca-policy-removal/","summary":"An unauthorized actor removes a Conditional Access policy in Azure, potentially weakening the organization's security posture and enabling privilege escalation or credential access.","title":"Unauthorized Removal of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-01-09-azure-ca-policy-removal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GitHub"],"_cs_severities":["low"],"_cs_tags":["github","repository","archive","unarchive","persistence","impact","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eThis 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\u0026rsquo;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.\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 repository administration privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the GitHub platform using the compromised credentials or a stolen session token.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the settings page of a target repository.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the repository\u0026rsquo;s archive status, either archiving or unarchiving it depending on their objective.\u003c/li\u003e\n\u003cli\u003eGitHub logs the \u0026lsquo;repo.archived\u0026rsquo; or \u0026lsquo;repo.unarchived\u0026rsquo; action in the organization\u0026rsquo;s audit logs.\u003c/li\u003e\n\u003cli\u003e(If archiving) Legitimate users may lose access to the repository and its code, causing disruption.\u003c/li\u003e\n\u003cli\u003e(If unarchiving) The attacker might reintroduce vulnerable code or malicious content into an active repository.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to exploit the unarchived repository for further malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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\u0026rsquo;s access and objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;GitHub Repository Archive Status Changed\u0026rdquo; to your SIEM and tune for your environment. This rule detects the \u003ccode\u003erepo.archived\u003c/code\u003e and \u003ccode\u003erepo.unarchived\u003c/code\u003e actions in GitHub audit logs (logsource: github, service: audit).\u003c/li\u003e\n\u003cli\u003eReview GitHub audit logs regularly for unexpected repository archiving or unarchiving events.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected events to determine if the actions were authorized.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T15:00:00Z","date_published":"2024-01-04T15:00:00Z","id":"/briefs/2024-01-github-repo-archive-status-changed/","summary":"Detection of GitHub repository archiving or unarchiving events, which could indicate malicious activity such as persistence, impact, or defense impairment.","title":"GitHub Repository Archive Status Changed","url":"https://feed.craftedsignal.io/briefs/2024-01-github-repo-archive-status-changed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["GuardDuty"],"_cs_severities":["high"],"_cs_tags":["defense-impairment","aws","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAttackers 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.\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 through compromised credentials or other means (T1078).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing GuardDuty detectors to identify the target for disabling or deletion (T1068).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the AWS API using stolen credentials or an assumed role with sufficient permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker calls the \u003ccode\u003eDeleteDetector\u003c/code\u003e API to remove the GuardDuty detector entirely, erasing all existing findings (T1685.002).\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker calls the \u003ccode\u003eUpdateDetector\u003c/code\u003e API to disable the detector by setting the \u003ccode\u003eenable\u003c/code\u003e parameter to \u003ccode\u003efalse\u003c/code\u003e (T1685.002).\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the \u003ccode\u003eDeleteDetector\u003c/code\u003e or \u003ccode\u003eUpdateDetector\u003c/code\u003e event with a \u003ccode\u003eSuccess\u003c/code\u003e or \u003ccode\u003enull\u003c/code\u003e error code.\u003c/li\u003e\n\u003cli\u003eWith GuardDuty disabled, the attacker performs malicious actions such as lateral movement, data exfiltration, or resource compromise without immediate detection.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to remove CloudTrail logs to further impair defenses (T1562.008).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS GuardDuty Detector Deleted Or Updated\u0026rdquo; to your SIEM using AWS CloudTrail logs to detect attempts to disable or delete GuardDuty (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate all instances of \u003ccode\u003eDeleteDetector\u003c/code\u003e and \u003ccode\u003eUpdateDetector\u003c/code\u003e events in CloudTrail, especially if initiated from unusual locations or IAM roles.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege by granting only necessary permissions to IAM roles (T1078).\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for anomalies that could indicate malicious activity following a GuardDuty disablement.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:38:00Z","date_published":"2024-01-03T17:38:00Z","id":"/briefs/2024-01-03-aws-guardduty-disable/","summary":"Attackers may delete or disable AWS GuardDuty detectors to impair defenses and evade detection of malicious activities within the AWS environment.","title":"AWS GuardDuty Detector Deletion or Disablement","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-guardduty-disable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","mfa","credential-access","persistence","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers 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 \u0026ldquo;Disable Strong Authentication\u0026rdquo; 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\u0026rsquo;s security posture and establishing persistence.\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 account with sufficient privileges in Azure AD, possibly through credential compromise or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure AD PowerShell modules.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies target user accounts for which they wish to disable MFA.\u003c/li\u003e\n\u003cli\u003eThe attacker disables MFA for the targeted user accounts, resulting in an \u0026ldquo;Disable Strong Authentication.\u0026rdquo; event in the Azure AD activity logs.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to the targeted user accounts without MFA.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains access to sensitive resources, such as email, files, or applications.\u003c/li\u003e\n\u003cli\u003eThe attacker may then move laterally within the environment, accessing additional resources and escalating privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling MFA can significantly weaken an organization\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect instances of MFA being disabled in Azure AD activity logs, focusing on \u0026ldquo;Disable Strong Authentication\u0026rdquo; events (\u003ccode\u003eeventSource: AzureActiveDirectory\u003c/code\u003e, \u003ccode\u003eeventName: 'Disable Strong Authentication.'\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of MFA being disabled, especially if the activity is performed by unusual accounts.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) policies and monitor for unauthorized changes to MFA settings.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for Azure AD roles and permissions.\u003c/li\u003e\n\u003cli\u003eEnable logging for Azure Active Directory activity and sign-in logs (\u003ccode\u003eproduct: azure\u003c/code\u003e, \u003ccode\u003eservice: activitylogs\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-mfa-disabled/","summary":"An adversary may disable multi-factor authentication (MFA) in Azure Active Directory to weaken an organization's security posture and bypass authentication mechanisms, potentially gaining unauthorized access to sensitive resources and maintaining persistence.","title":"Azure AD MFA Disabled to Bypass Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-mfa-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["lateral-movement","defense-impairment","persistence","rpc"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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.\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 system within the network (e.g., through phishing or exploiting a vulnerability).\u003c/li\u003e\n\u003cli\u003eThe attacker discovers accessible target systems on the network.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to connect to the target system\u0026rsquo;s RPC endpoint for the Remote Registry service (UUID 338cd001-2244-31f1-aaaa-900038001003).\u003c/li\u003e\n\u003cli\u003eThe attacker uses RPC calls with operation numbers 6, 7, 8, 13, 18, 19, 21, 22, 23, or 35 to interact with the registry remotely.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies registry keys related to startup programs or services.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers the execution of malicious code through the modified registry keys, achieving persistence.\u003c/li\u003e\n\u003cli\u003eThe malicious code executes, allowing the attacker to perform actions such as data exfiltration or further lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eInstall 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 \u003ccode\u003edefinition\u003c/code\u003e within the \u003ccode\u003elogsource\u003c/code\u003e section.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect anomalous RPC calls related to registry modification as outlined in the \u003ccode\u003edetection\u003c/code\u003e section.\u003c/li\u003e\n\u003cli\u003eInvestigate and block any identified malicious RPC connections using RPC Firewall based on the logs generated and reviewed from the deployed 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-remote-registry-lateral-movement/","summary":"This brief details detection of lateral movement attempts using remote RPC calls to modify the registry, potentially leading to code execution, detected via RPC Firewall logs.","title":"Remote Registry Lateral Movement via RPC Firewall","url":"https://feed.craftedsignal.io/briefs/2024-01-remote-registry-lateral-movement/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS GuardDuty"],"_cs_severities":["high"],"_cs_tags":["defense-impairment","aws"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAn adversary may attempt to impair an organization\u0026rsquo;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.\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 AWS environment through compromised credentials or an exposed IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing GuardDuty IP sets using the \u003ccode\u003eListIPSets\u003c/code\u003e API call to identify potential targets for modification.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new IP set using \u003ccode\u003eCreateIPSet\u003c/code\u003e API call, which contains malicious IPs they intend to whitelist, or the legitimate IPs of internal scanners they wish to mimic.\u003c/li\u003e\n\u003cli\u003eGuardDuty validates the uploaded IP set list.\u003c/li\u003e\n\u003cli\u003eThe attacker activates the newly created IP set within GuardDuty, making it the active trusted or threat list.\u003c/li\u003e\n\u003cli\u003eThe attacker conducts malicious activity, such as lateral movement, data exfiltration, or resource exploitation, from the whitelisted IPs.\u003c/li\u003e\n\u003cli\u003eGuardDuty, configured with the modified IP sets, does not generate alerts for activity originating from the whitelisted IPs.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence and achieves their objective (e.g., data theft, denial of service) without detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS GuardDuty IP Set Creation\u0026rdquo; to your SIEM to detect suspicious creation of IP sets in GuardDuty (logsource: aws, service: cloudtrail).\u003c/li\u003e\n\u003cli\u003eInvestigate any changes to GuardDuty configurations, particularly the creation or modification of IP sets, using CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all AWS accounts and IAM roles to prevent unauthorized access (related to initial access).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit IAM roles and permissions to minimize the blast radius of compromised credentials.\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-guardduty-ipset/","summary":"An attacker modifies AWS GuardDuty IP sets, potentially whitelisting malicious IPs to disable security alerts and impair defenses.","title":"AWS GuardDuty IP Set Manipulation for Defense Impairment","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-guardduty-ipset/"}],"language":"en","title":"CraftedSignal Threat Feed — Defense-Impairment","version":"https://jsonfeed.org/version/1.1"}