{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/attack.privilege-escalation/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EC2"],"_cs_severities":["high"],"_cs_tags":["attack.privilege-escalation","attack.initial-access","attack.persistence","attack.stealth","attack.t1078","attack.t1078.002"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis activity focuses on the potential misuse of AWS Instance Metadata Service (IMDS) credentials. When an EC2 instance is compromised, an attacker can extract the temporary credentials stored within the IMDS. These credentials, associated with an assumed role, grant the attacker the ability to interact with other AWS services. The abnormal use of these credentials outside of the expected AWS Simple Systems Manager (SSM) service may indicate malicious activity such as lateral movement, data exfiltration, or resource compromise. This is particularly concerning when the compromised instance is being used as a pivot point to access other AWS resources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn EC2 instance is compromised through an initial access vector (e.g., software vulnerability, misconfiguration, or credential compromise).\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the compromised EC2 instance\u0026rsquo;s operating system.\u003c/li\u003e\n\u003cli\u003eThe attacker queries the IMDS endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/) to obtain temporary AWS credentials associated with the instance\u0026rsquo;s IAM role.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their local AWS CLI or SDK with the exfiltrated credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to perform actions against other AWS services using the exfiltrated credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges or move laterally within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access, modify, or exfiltrate sensitive data from other AWS services.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by creating new IAM users or roles with excessive permissions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive data stored in AWS services such as S3, DynamoDB, and RDS. This could result in data breaches, financial loss, and reputational damage. Attackers can also leverage the compromised credentials to pivot to other AWS resources, potentially impacting critical infrastructure and services. Organizations with lax security configurations and overly permissive IAM roles are at higher risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Malicious Usage Of IMDS Credentials Outside Of AWS Infrastructure\u0026rdquo; to your SIEM and tune for your environment to detect anomalous use of IMDS credentials.\u003c/li\u003e\n\u003cli\u003eReview and restrict IAM roles assigned to EC2 instances to follow the principle of least privilege, limiting the scope of potential damage from credential exfiltration.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for unusual API calls originating from EC2 instances with assumed roles, specifically those not related to SSM.\u003c/li\u003e\n\u003cli\u003eHarden EC2 instances to prevent initial compromise by applying security patches, configuring strong authentication, and regularly scanning for vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-07-11T00:00:00Z","date_published":"2024-07-11T00:00:00Z","id":"/briefs/2024-07-aws-imds-abuse/","summary":"Compromised EC2 instances may be leveraged to exfiltrate and misuse AWS Instance Metadata Service (IMDS) credentials to perform actions outside of the expected AWS Simple Systems Manager (SSM) service, indicating potential lateral movement or data exfiltration.","title":"Malicious Usage of AWS IMDS Credentials Outside of Expected Services","url":"https://feed.craftedsignal.io/briefs/2024-07-aws-imds-abuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","policy-modification","attack.privilege-escalation","attack.credential-access","attack.persistence","attack.defense-impairment","attack.t1548","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eCompromised or malicious actors may attempt to modify Azure Conditional Access (CA) policies to weaken security controls, elevate privileges, or establish persistence within the Azure environment. Conditional Access policies are critical for enforcing organizational security standards, and unauthorized changes can have significant security implications. This activity is detected through Azure Audit Logs by monitoring for \u0026ldquo;Update conditional access policy\u0026rdquo; events. Defenders should investigate any modifications to Conditional Access policies to ensure they are legitimate and align with security best practices. Detecting and responding to unauthorized CA policy modifications is crucial for maintaining the integrity and security of the Azure environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access through compromised credentials or other means (not specified in source).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages existing privileges or exploits vulnerabilities to gain sufficient permissions to modify Conditional Access policies (e.g., through a compromised Global Administrator account).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Enumeration:\u003c/strong\u003e The attacker enumerates existing Conditional Access policies to identify targets for modification using tools like Azure PowerShell or the Azure portal.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Modification:\u003c/strong\u003e The attacker modifies a Conditional Access policy, for example, by weakening MFA requirements, excluding specific users or groups from the policy, or disabling the policy altogether.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e By weakening or disabling Conditional Access policies, the attacker establishes a persistent foothold in the environment, allowing them to bypass security controls and maintain unauthorized access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e With weakened MFA or other access controls, the attacker gains easier access to sensitive credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Impairment:\u003c/strong\u003e The modification of CA policies impairs the organization\u0026rsquo;s defense mechanisms, making it easier for the attacker to perform malicious activities undetected.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of Conditional Access policies can lead to significant security breaches, including unauthorized access to sensitive data, privilege escalation, and persistent compromise of the Azure environment. The number of affected users and resources depends on the scope of the modified policies. Organizations may experience data loss, financial losses, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;CA Policy Updated by Non Approved Actor\u0026rdquo; Sigma rule to your SIEM to detect unauthorized modifications to Conditional Access policies within your Azure environment.\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eproperties.message\u003c/code\u003e field in the Azure Audit Logs for \u0026ldquo;Update conditional access policy\u0026rdquo; events and compare \u0026ldquo;old\u0026rdquo; vs \u0026ldquo;new\u0026rdquo; values to understand the nature of the changes.\u003c/li\u003e\n\u003cli\u003eImplement strict role-based access control (RBAC) to limit the number of users who can modify Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule and verify whether the user identity, user agent, and/or hostname should be making changes in your environment.\u003c/li\u003e\n\u003cli\u003eEnable multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise (related to attack.credential-access tag).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-29T12:00:00Z","date_published":"2024-05-29T12:00:00Z","id":"/briefs/2024-05-29-azure-ca-policy-update/","summary":"An unauthorized actor modifies an Azure Conditional Access policy, potentially leading to privilege escalation, credential access, persistence, or defense impairment.","title":"Unauthorized Modification of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-05-29-azure-ca-policy-update/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.credential-access","attack.persistence","attack.privilege-escalation","attack.defense-impairment","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe addition of a new root certificate authority (CA) in Azure Active Directory (Azure AD) to support certificate-based authentication (CBA) can be a sign of malicious activity. While CBA offers passwordless authentication benefits, attackers can abuse it to establish persistent access, escalate privileges, or evade detection. An attacker with sufficient privileges in the Azure AD tenant can add a rogue CA, enabling them to authenticate as any user within the directory, even without their password. This bypasses multi-factor authentication (MFA) and grants unauthorized access to sensitive resources and data. Defenders should monitor Azure AD audit logs for unexpected modifications to the \u003ccode\u003eTrustedCAsForPasswordlessAuth\u003c/code\u003e setting, as this could indicate a compromised administrator account or an insider threat attempting to establish a backdoor.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eCompromise an Azure AD administrator account with sufficient privileges to modify tenant-wide settings. This may be achieved through phishing, credential stuffing, or exploiting vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses PowerShell cmdlets to interact with Azure AD.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to add a new, attacker-controlled root certificate authority to the \u003ccode\u003eTrustedCAsForPasswordlessAuth\u003c/code\u003e setting. This involves modifying the Company Information object.\u003c/li\u003e\n\u003cli\u003eThe attacker generates or obtains a certificate signed by the newly added root CA.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the certificate to authenticate to Azure AD as a targeted user, bypassing password requirements and multi-factor authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the targeted user\u0026rsquo;s resources, such as email, files, and applications.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the Azure AD tenant by impersonating highly privileged users or roles.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Azure AD tenant, even if the compromised administrator account is remediated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete compromise of the Azure AD tenant, including access to sensitive data, applications, and resources. Attackers can use the compromised tenant to move laterally to other systems, exfiltrate data, or disrupt business operations. The number of potential victims is dependent on the size of the Azure AD tenant. Organizations across all sectors are at risk, especially those heavily reliant on Azure AD for identity and access management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Root Certificate Authority Added\u0026rdquo; to your SIEM to detect unauthorized modifications to the \u003ccode\u003eTrustedCAsForPasswordlessAuth\u003c/code\u003e setting (rule).\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs regularly for suspicious activity related to the \u0026ldquo;Set Company Information\u0026rdquo; operation (logsource).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure AD accounts, including administrators, but understand that CBA can bypass it.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege and restrict the number of accounts with permissions to modify tenant-wide settings.\u003c/li\u003e\n\u003cli\u003eMonitor for the use of certificates signed by unknown or untrusted CAs to authenticate to Azure AD.\u003c/li\u003e\n\u003cli\u003eConsult the SpecterOps and Goodworkaround articles for more information on certificate-based authentication abuse in Azure AD (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-08T18:22:00Z","date_published":"2024-05-08T18:22:00Z","id":"/briefs/2024-05-azuread-root-ca-add/","summary":"An attacker may add a new root certificate authority to an Azure AD tenant to support certificate-based authentication for persistence, privilege escalation, or defense evasion.","title":"Azure AD Root Certificate Authority Added for Passwordless Authentication","url":"https://feed.craftedsignal.io/briefs/2024-05-azuread-root-ca-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Entra ID"],"_cs_severities":["high"],"_cs_tags":["attack.stealth","attack.t1078","attack.persistence","attack.privilege-escalation","attack.initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting suspicious sign-in activity within Azure Active Directory (Azure AD). Specifically, it targets sign-ins originating from countries or regions that are new or unusual for a given user. This behavior can be indicative of compromised credentials, travel without notification, or the use of VPN/proxy services to mask the true origin of the sign-in. Microsoft Entra ID Protection identifies \u0026ldquo;new country\u0026rdquo; as a risk event when a user signs in from a location that is drastically different from their recent sign-in history. Detecting these anomalies is crucial for preventing unauthorized access and mitigating potential data breaches. The detection uses Azure AD\u0026rsquo;s risk detection logs to identify such events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains access to a valid user\u0026rsquo;s credentials, potentially through phishing, credential stuffing, or malware. (T1078)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnomalous Login:\u003c/strong\u003e The attacker attempts to sign in to Azure AD using the compromised credentials from a country or region not typically associated with the user.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRisk Detection Trigger:\u003c/strong\u003e Azure AD Identity Protection identifies the sign-in as high-risk due to the new country/region and logs a \u0026ldquo;newCountry\u0026rdquo; risk event.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker may establish persistent access by creating new accounts or modifying existing ones.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e If the compromised account has elevated privileges, the attacker may attempt to escalate their privileges within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker may use the compromised account to move laterally within the organization, accessing other resources and data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker accesses sensitive data and attempts to exfiltrate it from the environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objectives, which could include data theft, financial fraud, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack following a sign-in from a new country can result in unauthorized access to sensitive data, compromised user accounts, and potential data breaches. Organizations may experience financial losses, reputational damage, and legal liabilities. The number of victims and the extent of the damage depend on the privileges of the compromised account and the attacker\u0026rsquo;s objectives. Immediate containment is crucial to prevent further damage if a new country sign-in is verified as malicious.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM or security analytics platform to detect \u0026ldquo;newCountry\u0026rdquo; risk events in Azure AD (logsource: azure, service: riskdetection).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule in the context of other sign-in activities for the affected user to rule out false positives.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users to mitigate the risk of account compromise (T1078).\u003c/li\u003e\n\u003cli\u003eMonitor user activity logs for other suspicious behaviors, such as unusual access patterns or attempts to escalate privileges.\u003c/li\u003e\n\u003cli\u003eReview and enforce conditional access policies to restrict access based on location, device, and other factors.\u003c/li\u003e\n\u003cli\u003eEducate users about phishing and other social engineering tactics to prevent credential theft.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-30-azure-new-country-signin/","summary":"Detection of Azure AD sign-ins originating from countries or regions not previously associated with a user, indicating potential account compromise or anomalous activity.","title":"Azure AD Sign-in from New Country/Region","url":"https://feed.craftedsignal.io/briefs/2024-01-30-azure-new-country-signin/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.t1547.001"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers can manipulate Windows Registry Classes keys, an autostart extensibility point (ASEP), to achieve persistence. This involves modifying registry entries that control how the operating system handles specific file types or shell actions. By modifying these keys, adversaries can ensure their malicious code executes whenever a user interacts with a specific file type (e.g., opening an .exe) or performs a specific action within the shell. This technique, which has been observed since at least 2019, allows malicious actors to maintain a persistent foothold on compromised systems. While legitimate software also utilizes these registry keys, careful filtering and monitoring are crucial for distinguishing malicious modifications from benign software installations. Detection can be noisy due to the legitimate use of these keys, so tuning and review is critical.\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 through a separate vector (e.g., phishing, exploit). This stage is not covered by this detection, which focuses on post-exploitation activity.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation (if needed): The attacker may need elevated privileges to modify certain registry keys. This can involve exploiting vulnerabilities or leveraging existing administrative rights.\u003c/li\u003e\n\u003cli\u003eRegistry Key Modification: The attacker modifies specific keys under \u003ccode\u003e\\Software\\Classes\u003c/code\u003e in the Windows Registry. Common targets include \u003ccode\u003e\\Folder\\ShellEx\\ExtShellFolderViews\u003c/code\u003e, \u003ccode\u003e\\.exe\u003c/code\u003e, and \u003ccode\u003e\\Directory\\Shellex\\DragDropHandlers\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003ePayload植入：攻击者修改注册表项指向一个恶意可执行文件或脚本。这可能涉及替换默认命令或添加新的处理程序。\u003c/li\u003e\n\u003cli\u003eExecution Trigger: The malicious code is configured to execute when a user interacts with the associated file type or shell action (e.g., opening a .exe file, right-clicking a folder).\u003c/li\u003e\n\u003cli\u003eMalicious Payload Execution: When the configured trigger occurs, the malicious payload executes, giving the attacker control over the system.\u003c/li\u003e\n\u003cli\u003ePersistence Maintained: The modified registry keys ensure that the malicious payload will continue to execute whenever the trigger occurs, maintaining persistence across reboots or user logons.\u003c/li\u003e\n\u003cli\u003eObjective Achieved: The attacker leverages persistent access to achieve their objectives, such as data exfiltration, lateral movement, or deploying ransomware.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to maintain persistent access to compromised systems, bypassing traditional security measures. This can lead to significant data breaches, financial losses, and reputational damage. The number of potential victims is broad, as any Windows system is potentially vulnerable. The types of damage possible range from credential theft to ransomware deployment, depending on the attacker\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Windows Registry auditing and monitor \u003ccode\u003eregistry_set\u003c/code\u003e events for modifications to keys under \u003ccode\u003e\\Software\\Classes\u003c/code\u003e to identify suspicious activity.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Classes Autorun Keys Modification\u0026rdquo; to your SIEM and tune the filters (filter_main_\u003cem\u003e, filter_optional_\u003c/em\u003e) for your specific environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any registry modifications detected by the Sigma rule, focusing on unusual executables or scripts being launched from these locations.\u003c/li\u003e\n\u003cli\u003eRegularly review and update the filters in the Sigma rule to account for legitimate software changes in your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-28T12:00:00Z","date_published":"2024-01-28T12:00:00Z","id":"/briefs/2024-01-28-classes-autorun-keys-modification/","summary":"Adversaries modify Windows Registry Classes keys to establish persistence by executing malicious code when specific file types are opened or actions are performed, potentially leading to privilege escalation and persistent access.","title":"Windows Registry Classes Autorun Keys Modification for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-28-classes-autorun-keys-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.credential-access","attack.persistence","attack.defense-impairment","attack.t1548","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis activity involves the addition of a user to an Azure Active Directory group that possesses the ability to modify Conditional Access (CA) policies. Conditional Access policies are used to enforce authentication requirements based on various conditions (user, location, device, etc.). If an attacker gains the ability to modify these policies, they can weaken security controls to facilitate privilege escalation, credential access, persistence within the environment, and impair defenses. This type of attack can be initiated by an insider threat or external compromise of an account. The goal is to manipulate CA policies to bypass multi-factor authentication, grant unauthorized access, or maintain persistence.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a user account or service principal with sufficient privileges to manage group memberships in Azure AD. This could be achieved through credential compromise or other initial access vectors.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target Azure AD group that has permissions to manage Conditional Access policies. These groups are often used to delegate administrative control over CA policies.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the Azure portal, PowerShell, or the Azure AD Graph API/Microsoft Graph API to add a malicious user account to the target group.\u003c/li\u003e\n\u003cli\u003eThe Azure Audit Logs record the \u0026ldquo;Add member from group\u0026rdquo; event, indicating the change in group membership.\u003c/li\u003e\n\u003cli\u003eThe newly added malicious user inherits the group\u0026rsquo;s permissions, which includes the ability to view, create, modify, and delete Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies existing CA policies to weaken security controls. For example, they might exclude themselves from MFA requirements or grant access to sensitive resources without proper authorization.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages their modified CA policies to gain unauthorized access to sensitive data or resources.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new CA policies that ensure their continued access, even if their initial access is revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this attack chain can lead to significant compromise of an organization\u0026rsquo;s Azure environment. Attackers can bypass MFA, gain access to sensitive resources, establish persistent access, and impair security defenses. The extent of the damage depends on the permissions associated with the compromised group and the scope of the modified Conditional Access policies. This can lead to data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect additions of users to groups with CA policy modification access and tune for your environment.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure AD group memberships, especially for groups with administrative privileges (as detected by the Sigma rule).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all users, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege when assigning permissions to Azure AD groups.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to group membership changes and Conditional Access policy modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:00Z","date_published":"2024-01-03T18:22:00Z","id":"/briefs/2024-01-azure-group-add/","summary":"An attacker adds a user to a privileged Azure Active Directory group with permissions to modify Conditional Access policies, potentially leading to privilege escalation, credential access, persistence, and defense impairment.","title":"User Added to Group with Conditional Access Policy Modification Access","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-group-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.initial-access","attack.stealth","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert focuses on detecting potentially risky authentication events within Azure Active Directory. Specifically, it flags successful logins to applications deemed \u0026ldquo;important\u0026rdquo; where the authentication process only involved a single factor. This bypasses the added security of multi-factor authentication (MFA), potentially exposing these applications to compromise if the single factor (e.g., password) is weak, stolen, or compromised. The alert is designed to identify deviations from a secure authentication baseline, particularly in environments where MFA is expected for sensitive resources. The applications considered \u0026ldquo;important\u0026rdquo; must be pre-defined by the defender for this detection to function effectively.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to a valid username and password through phishing, credential stuffing, or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to a pre-defined, high-value application within the Azure AD environment.\u003c/li\u003e\n\u003cli\u003eAzure AD processes the authentication request.\u003c/li\u003e\n\u003cli\u003eThe application is configured to allow single-factor authentication.\u003c/li\u003e\n\u003cli\u003eAzure AD verifies the supplied username and password against its directory.\u003c/li\u003e\n\u003cli\u003eUpon successful verification, Azure AD grants the attacker access to the application.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the application\u0026rsquo;s data and functionality.\u003c/li\u003e\n\u003cli\u003eDepending on the application and attacker\u0026rsquo;s motives, this could lead to data exfiltration, privilege escalation, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe impact of successful single-factor authentication to critical applications can range from minor data breaches to significant compromises of sensitive systems. The number of potential victims depends on the application\u0026rsquo;s user base and the sensitivity of the data it manages. Sectors most at risk include those handling financial, healthcare, or sensitive personal information. A successful attack could lead to data theft, financial loss, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePopulate the \u003ccode\u003eAppId\u003c/code\u003e field in the Sigma rule with the Application IDs of your organization\u0026rsquo;s critical applications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the single-factor authentication.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all users accessing critical applications to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and update Azure AD Conditional Access policies to ensure appropriate authentication requirements are in place.\u003c/li\u003e\n\u003cli\u003eTune the Sigma rule based on observed false positives in your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-03-azure-single-factor-auth/","summary":"Detection of successful Azure AD authentications to critical applications that only required single-factor authentication, potentially indicating a security lapse or policy violation leading to unauthorized access.","title":"Azure AD Authentication to Important Apps Using Single-Factor Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-single-factor-auth/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.initial-access","attack.stealth","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting unauthorized elevation of privileges within Azure environments. Specifically, it addresses the assignment of the \u0026lsquo;User Access Administrator\u0026rsquo; role to a user, which allows managing access to all Azure subscriptions. This activity can be indicative of malicious actors attempting to gain control over an Azure environment or an insider threat escalating their privileges without proper authorization. The detection is based on Azure Audit Logs and can help identify potentially compromised accounts or misconfigurations. A successful elevation can lead to unauthorized access, data breaches, and service disruptions. Defenders should closely monitor these events and investigate any unexpected privilege escalations.\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 Azure account, possibly through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to assign the \u0026lsquo;User Access Administrator\u0026rsquo; role to themselves or another account they control.\u003c/li\u003e\n\u003cli\u003eThis assignment generates an \u0026lsquo;Administrative\u0026rsquo; audit log event with the OperationName \u0026lsquo;Assigns the caller to user access admin\u0026rsquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker now has the ability to manage user access to all Azure subscriptions within the tenant.\u003c/li\u003e\n\u003cli\u003eThe attacker creates new user accounts with elevated privileges within the subscriptions.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly created accounts to access sensitive resources and data.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance activities to identify critical assets and data stores.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or deploys malicious workloads within the compromised subscriptions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation to the \u0026lsquo;User Access Administrator\u0026rsquo; role can have severe consequences. It grants the attacker complete control over the Azure subscriptions, allowing them to access sensitive data, disrupt services, and potentially compromise the entire cloud environment. The number of affected subscriptions depends on the scope of the compromised account. This attack targets any organization utilizing Azure subscriptions and is particularly impactful for those storing sensitive data or running critical applications in the cloud.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Azure Subscription Permission Elevation Via AuditLogs\u0026rdquo; to your SIEM and tune it for your environment to detect the \u0026lsquo;Assigns the caller to user access admin\u0026rsquo; event in the Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of this event to determine if the privilege elevation was authorized and legitimate.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all Azure accounts to minimize the impact of potential compromises; reference the Microsoft Entra documentation for guidance.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to prevent unauthorized access via compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-03-azure-privilege-elevation/","summary":"Detection of a user being assigned the 'User Access Administrator' role, which grants the ability to manage all Azure Subscriptions, potentially leading to privilege escalation and unauthorized access.","title":"Detection of Azure Subscription Permission Elevation","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-privilege-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.initial-access","attack.stealth","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies a potentially malicious increase in successful sign-ins within an Azure Active Directory environment. An attacker who has compromised credentials may attempt to leverage them repeatedly, resulting in a higher-than-normal volume of successful authentications. While not definitive proof of compromise, a sudden spike warrants further investigation. This behavior is typically observed during the initial access, persistence, privilege escalation, or stealth phases of an attack. This detection focuses on identifying increases of 10% or greater, providing a starting point for identifying anomalous activity. Defenders should investigate the source of the increase, focusing on specific users, applications, or geographic locations involved.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e The attacker obtains valid user credentials through phishing, brute-force, or credential stuffing attacks against Azure AD.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker uses the compromised credentials to successfully authenticate to Azure AD, gaining initial access to the environment (T1078).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEnumeration:\u003c/strong\u003e The attacker enumerates available resources, applications, and user accounts within the Azure AD environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in Azure AD or related applications. This may involve authenticating to multiple resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence mechanisms, such as creating new accounts or modifying existing ones, to maintain access to the environment. This may involve repeatedly authenticating to refresh tokens or maintain sessions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker uses the compromised account to access other resources or accounts within the Azure AD environment, potentially triggering further successful sign-ins.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Damage:\u003c/strong\u003e The attacker uses the compromised access to exfiltrate sensitive data or disrupt business operations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCovering Tracks:\u003c/strong\u003e The attacker attempts to cover their tracks by disabling logging or deleting audit trails to avoid detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack following a measurable increase in authentications can lead to unauthorized access to sensitive data, financial loss, reputational damage, and disruption of business operations. The specific impact depends on the level of access gained by the attacker and the resources they are able to compromise. For example, an attacker gaining access to an administrator account could potentially take control of the entire Azure AD environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Measurable Increase Of Successful Authentications\u0026rdquo; Sigma rule to your SIEM and tune for your environment. This rule detects increases of 10% or greater in successful sign-ins (rule, logsource: azure, service: signinlogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on identifying the source of the increased authentications and the users/applications involved.\u003c/li\u003e\n\u003cli\u003eReview the Microsoft Entra ID Protection reports for unusual sign-in activity, as referenced in the source material: \u003ca href=\"https://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins\"\u003ehttps://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor for other suspicious activities, such as unusual sign-in locations, access to sensitive resources, or changes to user accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-azure-auth-increase/","summary":"This detection identifies a statistically significant (10% or greater) increase in successful sign-ins to Azure Active Directory, potentially indicating credential compromise or account takeover attempts.","title":"Azure AD Successful Authentication Increase","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-auth-increase/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation","attack.privilege-escalation","attack.t1548"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief addresses the creation of a new Conditional Access (CA) policy within Azure Active Directory (Azure AD) by an actor not authorized to perform such actions. Conditional Access policies are critical security controls that enforce organizational policies based on various conditions, such as user identity, location, device, and application. Unauthorized modification or creation of these policies can lead to significant security breaches, allowing attackers to bypass security controls, escalate privileges, and gain unauthorized access to sensitive resources. This activity is detected via Azure Audit Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to an account with sufficient privileges to interact with Azure AD, potentially through compromised credentials or an insider threat.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (If Needed):\u003c/strong\u003e The attacker escalates privileges within Azure AD to a role that permits the creation or modification of Conditional Access policies.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Creation:\u003c/strong\u003e The attacker creates a new Conditional Access policy using the Azure portal, PowerShell, or Azure CLI.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Configuration:\u003c/strong\u003e The attacker configures the CA policy to weaken security controls, such as disabling MFA for specific users, locations, or applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBypass Security Controls:\u003c/strong\u003e The newly created or modified CA policy allows the attacker to bypass intended security controls, granting them unauthorized access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With bypassed security controls, the attacker moves laterally within the network, accessing sensitive resources and data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e The attacker achieves their final objective, such as exfiltrating sensitive data or causing disruption to business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe creation of unauthorized Conditional Access policies can have severe consequences, including unauthorized access to sensitive data, privilege escalation, and circumvention of security controls. The impact can range from data breaches and financial loss to reputational damage and disruption of critical business services. If successful, attackers could gain complete control over the Azure AD environment, affecting all connected services and applications.\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 CA policy creation events in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eReview Azure AD role assignments to ensure least privilege and restrict CA policy management to authorized personnel only.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to identify the actor and the details of the created CA policy.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for other suspicious activities, such as changes to user accounts, group memberships, and application registrations.\u003c/li\u003e\n\u003cli\u003eEstablish a baseline of expected CA policy configurations and alert on deviations from this baseline.\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-ca-policy-add/","summary":"An unauthorized actor created a new Conditional Access policy in Azure AD, potentially leading to privilege escalation and unauthorized access.","title":"Unauthorized Conditional Access Policy Creation in Azure AD","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-ca-policy-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Microsoft Office"],"_cs_severities":["medium"],"_cs_tags":["attack.privilege-escalation","attack.persistence","attack.t1547.001"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may target Microsoft Office applications\u0026rsquo; autostart extensibility points (ASEPs) in the Windows Registry to establish persistence. By modifying specific registry keys, malicious actors can ensure that their code is executed each time an Office application, such as Word, Excel, or Outlook, is launched. This technique is often employed to maintain a foothold on a compromised system. While legitimate add-ins also leverage these registry keys, unauthorized modifications can lead to the execution of arbitrary code, potentially resulting in data theft, system compromise, or further exploitation. Defenders should be aware that many legitimate applications modify these keys. Thorough testing and tuning is required.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the system via an unrelated method.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the relevant Office application ASEP registry keys: \u003ccode\u003e\\Software\\Wow6432Node\\Microsoft\\Office\u003c/code\u003e, \u003ccode\u003e\\Software\\Microsoft\\Office\u003c/code\u003e and specific application keys like \u003ccode\u003e\\Word\\Addins\u003c/code\u003e, \u003ccode\u003e\\Excel\\Addins\u003c/code\u003e, etc.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the registry key to point to a malicious executable or script. This could be achieved using tools like \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell.\u003c/li\u003e\n\u003cli\u003eThe registry modification ensures that the malicious code is executed upon the next launch of the targeted Office application.\u003c/li\u003e\n\u003cli\u003eThe user launches the Office application (e.g., Word, Excel, Outlook).\u003c/li\u003e\n\u003cli\u003eThe Office application reads the modified registry key and executes the associated malicious code.\u003c/li\u003e\n\u003cli\u003eThe malicious code performs its intended actions, such as downloading additional payloads, establishing command and control, or stealing data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence on the system through the modified registry key, ensuring continued access and control.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to achieve persistence on compromised systems. This can lead to data exfiltration, deployment of ransomware, or further lateral movement within the network. The modification of these keys is often performed to maintain a persistent presence, allowing attackers to regain access to the system even after reboots or user logoffs. While the number of direct victims is unknown, the potential for widespread impact is significant, especially in organizations heavily reliant on Microsoft Office applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable registry modification logging and deploy the provided Sigma rules to your SIEM to detect suspicious changes to Office application autostart registry keys.\u003c/li\u003e\n\u003cli\u003eRegularly audit the Office application add-ins installed on systems to identify and remove any unauthorized or malicious extensions (reference: Sigma rules).\u003c/li\u003e\n\u003cli\u003eImplement application whitelisting to prevent the execution of unauthorized executables and scripts (reference: Attack Chain).\u003c/li\u003e\n\u003cli\u003eMonitor process execution events for Office applications launching unusual or suspicious child processes (reference: Attack Chain).\u003c/li\u003e\n\u003cli\u003eTune and customize the provided Sigma rules based on your environment\u0026rsquo;s baseline of legitimate Office add-in activity to minimize false positives (reference: Sigma rules).\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-03-office-autorun-registry-modification/","summary":"Adversaries modify Office application autostart extensibility point (ASEP) registry keys to achieve persistence and execute malicious code when Office applications are launched.","title":"Office Application Autorun Registry Key Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-office-autorun-registry-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Windows"],"_cs_severities":["high"],"_cs_tags":["attack.execution","attack.privilege-escalation","attack.persistence","attack.t1053.005"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis brief focuses on the detection of malicious activity related to the deletion or disabling of important scheduled tasks within a Windows environment. Adversaries may target these tasks to disrupt normal system operations, escalate privileges, establish persistence, or facilitate data destruction. The targeted tasks often include critical system functions like System Restore, Windows Defender updates, BitLocker encryption, Windows Backup processes, and Windows Update mechanisms. This…\u003c/p\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-scheduled-task-deletion/","summary":"Adversaries delete or disable critical scheduled tasks, such as those related to system restore, Windows Defender, BitLocker, Windows Backup, or Windows Update, to disrupt operations and potentially conduct data destructive activities.","title":"Detection of Important Scheduled Task Deletion or Disablement","url":"https://feed.craftedsignal.io/briefs/2024-01-scheduled-task-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.initial-access","attack.persistence","attack.privilege-escalation","attack.stealth","attack.t1098.003","attack.t1078"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may attempt to add new members to administrative roles in Azure Active Directory to establish persistence and elevate privileges. This allows them to perform actions as a highly privileged user, potentially bypassing security controls and accessing sensitive resources. The activity is logged within Azure Activity Logs, specifically when the \u0026lsquo;Add member to role\u0026rsquo; operation is executed within the \u0026lsquo;AzureActiveDirectory\u0026rsquo; workload, targeting roles with names ending in \u0026lsquo;Admins\u0026rsquo; or \u0026lsquo;Administrator\u0026rsquo;. Monitoring these events can help detect unauthorized privilege escalation and potential malicious activity within the Azure environment. This activity could be the result of compromised credentials or an insider threat.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eCompromise an existing user account with sufficient permissions to modify Azure AD roles.\u003c/li\u003e\n\u003cli\u003eAuthenticate to the Azure portal or utilize Azure CLI with the compromised account.\u003c/li\u003e\n\u003cli\u003eIdentify a target Azure AD administrative role (e.g., Global Administrator, Security Administrator).\u003c/li\u003e\n\u003cli\u003eExecute the \u0026lsquo;Add member to role\u0026rsquo; operation, adding the attacker-controlled user to the target role. This can be performed via the Azure portal, PowerShell, or Azure CLI.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record the \u0026lsquo;Add member to role.\u0026rsquo; event, with the \u0026lsquo;Workload\u0026rsquo; as \u0026lsquo;AzureActiveDirectory\u0026rsquo;.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eModifiedProperties{}.NewValue\u003c/code\u003e field reflects the addition of the user to the admin role, containing strings like \u0026ldquo;Admins\u0026rdquo; or \u0026ldquo;Administrator.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates as the newly added user, inheriting the privileges of the administrative role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive data, modify configurations, or deploy malicious applications.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful addition of a user to an Azure AD administrative role grants the attacker extensive control over the Azure environment. This can lead to data breaches, service disruptions, and the deployment of malicious applications.  Compromised administrator accounts can be used to disable security features, modify audit logs, and create backdoors for persistent access. Detection is critical to limit the scope and duration of the attack.\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 instances of users being added to Azure AD administrative roles (logsource: azure, service: activitylogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of the \u0026ldquo;Add member to role.\u0026rdquo; operation in Azure AD Activity Logs where the ModifiedProperties{}.NewValue ends with \u0026lsquo;Admins\u0026rsquo; or \u0026lsquo;Administrator\u0026rsquo; to validate legitimate administrative changes.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of compromised credentials.\u003c/li\u003e\n\u003cli\u003eRegularly review Azure AD role assignments to identify and remove unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eMonitor for unusual activity from newly added members of administrative roles after the \u0026lsquo;Add member to role\u0026rsquo; event.\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-azuread-admin-role-add/","summary":"An adversary adds a user to an Azure Active Directory administrative role to gain initial access, persist in the environment, escalate privileges, and potentially operate stealthily.","title":"Azure AD User Added to Administrator Role","url":"https://feed.craftedsignal.io/briefs/2024-01-azuread-admin-role-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS STS"],"_cs_severities":["medium"],"_cs_tags":["attack.lateral-movement","attack.privilege-escalation","attack.t1548","attack.t1550","attack.t1550.001"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe AWS Security Token Service (STS) AssumeRole function allows users or applications to assume a different IAM role, granting temporary access to resources and permissions associated with that role.  Attackers who gain initial access to an AWS account can misuse AssumeRole to move laterally to other roles and escalate their privileges. This can occur if the initial role has overly permissive trust relationships or if an attacker can manipulate the role assumption process.  This activity is detected through CloudTrail logs that record the AssumeRole event. The impact of this activity can be significant, depending on the permissions associated with the roles assumed.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies IAM roles within the AWS environment that they may be able to assume.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to use the \u003ccode\u003eAssumeRole\u003c/code\u003e API call to assume a different role. This call includes parameters specifying the target role ARN and a session name.\u003c/li\u003e\n\u003cli\u003eAWS STS validates the request.  Successful validation depends on the trust policy of the target role and the permissions of the initial user or role.\u003c/li\u003e\n\u003cli\u003eIf the validation is successful, AWS STS returns temporary security credentials (access key ID, secret access key, and session token) to the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker uses these temporary credentials to access AWS resources and perform actions authorized by the assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker continues to move laterally and escalate privileges by assuming additional roles.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as accessing sensitive data, modifying configurations, or disrupting services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to a wide range of impacts, including unauthorized access to sensitive data stored in S3 buckets or databases, modification or deletion of critical infrastructure configurations, and disruption of AWS services. The scope of the impact depends on the permissions associated with the roles that the attacker is able to assume. This can affect any organization using AWS, and the consequences can range from data breaches and financial losses to reputational damage and 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 and tune for your environment to detect suspicious \u003ccode\u003eAssumeRole\u003c/code\u003e activity based on \u003ccode\u003euserIdentity.type\u003c/code\u003e and \u003ccode\u003euserIdentity.sessionContext.sessionIssuer.type\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eReview and harden IAM role trust policies to ensure that only authorized entities can assume roles.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for unusual patterns of \u003ccode\u003eAssumeRole\u003c/code\u003e API calls, especially those originating from unfamiliar user identities or locations.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to reduce the risk of credential compromise.\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-aws-assumerole-misuse/","summary":"Abuse of AWS STS AssumeRole can allow attackers to move laterally within an AWS environment and escalate privileges, potentially leading to unauthorized access to sensitive resources and data.","title":"AWS STS AssumeRole Misuse for Lateral Movement and Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-assumerole-misuse/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","pim","role-assignment","attack.initial-access","attack.stealth","attack.t1078","attack.persistence","attack.privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized assignment of privileged roles outside of Azure Privileged Identity Management (PIM) represents a significant security risk. Attackers may attempt to bypass PIM controls to gain persistent access, escalate privileges, or move laterally within the Azure environment. Detecting these anomalous role assignments is crucial for identifying potentially compromised accounts or malicious insiders. This activity is a common tactic used by attackers to establish persistence and maintain control over cloud resources. Monitoring for this behavior can help security teams quickly identify and respond to potential breaches, limiting the impact of successful attacks. This activity can be associated with lateral movement, privilege escalation, and persistence within the cloud environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised user account or service principal within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to identify existing privileged roles and permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses PIM to directly assign themselves a privileged role (e.g., Global Administrator, Security Administrator) using Azure CLI, PowerShell, or the Azure portal.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates their permissions without triggering PIM alerts or requiring approval.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly assigned privileged role to access sensitive data, modify configurations, or create new resources.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new accounts or modifying existing ones with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally to other Azure resources or subscriptions using their increased access.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, service disruption, or deployment of malicious code.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising privileged roles within Azure can have severe consequences, potentially impacting all resources within the affected Azure Active Directory tenant. Successful attacks can lead to unauthorized data access, service disruption, financial loss, and reputational damage. The scope of the impact depends on the level of privilege gained by the attacker and the sensitivity of the targeted resources. Without proper detection and response, organizations may remain unaware of the breach, allowing attackers to maintain persistent access and continue their malicious activities undetected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eRoles Assigned Outside PIM\u003c/code\u003e to your SIEM to detect unauthorized role assignments within your Azure environment.\u003c/li\u003e\n\u003cli\u003eInvestigate all instances flagged by the Sigma rule \u003ccode\u003eRoles Assigned Outside PIM\u003c/code\u003e to determine the legitimacy of the role assignment and the identity of the assigner.\u003c/li\u003e\n\u003cli\u003eImplement controls to restrict the ability to assign privileged roles outside of PIM, as described in the Microsoft documentation reference.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege to minimize the potential impact of compromised accounts.\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-azure-pim-role-assigned-outside/","summary":"Detection of privilege role assignments outside of Azure Privileged Identity Management (PIM) can indicate potential attacker activity related to initial access, stealth, persistence, or privilege escalation within the Azure environment.","title":"Azure PIM - Role Assignment Outside of Privileged Identity Management","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-role-assigned-outside/"}],"language":"en","title":"CraftedSignal Threat Feed — Attack.privilege-Escalation","version":"https://jsonfeed.org/version/1.1"}