{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/attack.credential-access/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_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":["Okta Identity Engine"],"_cs_severities":["high"],"_cs_tags":["attack.credential-access","attack.t1552","okta","password-leak"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eOkta, a leading identity and access management provider, retains login attempt data in its system logs. This data can be valuable for security monitoring and incident response. However, a misconfiguration or user error can lead to sensitive information, such as passwords, being inadvertently captured within these logs. Specifically, if a user mistakenly enters their password in the username field (referred to as \u0026lsquo;alternateId\u0026rsquo; in Okta logs) during a failed login attempt, the password may be stored in plain text within the log entry. This exposes the password to anyone with access to Okta system logs. This issue was highlighted in a Mitiga blog post, underscoring the risk to user data. Defenders must implement measures to detect and prevent such occurrences to maintain the confidentiality of user credentials and the overall security posture.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUser attempts to log in to an Okta-protected application.\u003c/li\u003e\n\u003cli\u003eThe user mistakenly enters their password in the username (alternateId) field.\u003c/li\u003e\n\u003cli\u003eThe Okta authentication process fails due to incorrect credentials.\u003c/li\u003e\n\u003cli\u003eOkta logs the failed login attempt, including the \u0026lsquo;core.user_auth.login_failed\u0026rsquo; event.\u003c/li\u003e\n\u003cli\u003eThe password, entered in the alternateId field, is recorded in the Okta system log.\u003c/li\u003e\n\u003cli\u003eAn attacker gains unauthorized access to Okta system logs, potentially through compromised credentials or a misconfigured integration.\u003c/li\u003e\n\u003cli\u003eThe attacker searches for \u0026lsquo;core.user_auth.login_failed\u0026rsquo; events and examines the \u0026lsquo;actor.alternateId\u0026rsquo; field.\u003c/li\u003e\n\u003cli\u003eThe attacker discovers exposed passwords within the \u0026lsquo;actor.alternateId\u0026rsquo; field, potentially enabling account takeover or further lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack exploiting this vulnerability could lead to widespread credential compromise. The number of potentially affected users depends on how frequently users make this mistake and the duration for which logs are retained. Sectors heavily reliant on Okta for authentication, such as technology, finance, and healthcare, are particularly at risk. If passwords are leaked, attackers can gain unauthorized access to sensitive data, applications, and systems, leading 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 \u0026ldquo;Okta Password Entered in AlternateID Field\u0026rdquo; to your SIEM to detect instances of passwords potentially being logged in the \u003ccode\u003eactor.alternateId\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eReview and adjust the regular expression in the Sigma rule\u0026rsquo;s \u003ccode\u003efilter_main\u003c/code\u003e section to align with the specific character restrictions in your Okta username configuration.\u003c/li\u003e\n\u003cli\u003eImplement stricter input validation on Okta login pages to prevent users from entering passwords in the username field.\u003c/li\u003e\n\u003cli\u003eRegularly audit Okta system logs for sensitive information and enforce least privilege access to log data.\u003c/li\u003e\n\u003cli\u003eEducate users about the proper use of login forms to reduce the likelihood of entering passwords in the username field.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to mitigate the impact of compromised passwords, as referenced in security best practices.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-02-29T12:00:00Z","date_published":"2024-02-29T12:00:00Z","id":"/briefs/2024-02-okta-password-alternateid/","summary":"Okta logs may contain user passwords if a user mistakenly enters their password into the username field during login, potentially exposing credentials in logs.","title":"Okta Password Entered in AlternateID Field","url":"https://feed.craftedsignal.io/briefs/2024-02-okta-password-alternateid/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["IOS"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-evasion","attack.persistence","attack.credential-access","attack.t1562.001","attack.t1556.004"],"_cs_type":"advisory","_cs_vendors":["Cisco"],"content_html":"\u003cp\u003eThe disabling of 802.1X authentication on a Cisco network device can bypass Network Access Control (NAC) mechanisms, potentially granting unauthorized devices access to the internal network. Attackers or malicious insiders might disable dot1x to establish persistence or facilitate lateral movement by connecting rogue devices to the network. This can be accomplished through CLI commands such as \u0026lsquo;access-session port-control force-authorized\u0026rsquo; or \u0026rsquo;no dot1x system-auth-control\u0026rsquo;, depending on the IOS version. These commands either disable 802.1X on a specific interface or globally across the device. The targeted scope is Cisco network devices utilizing 802.1X for network access control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains privileged access to a Cisco network device via compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eAttacker executes CLI commands to disable 802.1X authentication on a specific interface or globally.\u003c/li\u003e\n\u003cli\u003eCommands used may include \u0026lsquo;access-session port-control force-authorized\u0026rsquo;, \u0026lsquo;authentication port-control force-authorized\u0026rsquo;, \u0026lsquo;dot1x port-control force-authorized\u0026rsquo;, \u0026rsquo;no access-session port-control\u0026rsquo;, \u0026rsquo;no authentication port-control\u0026rsquo;, \u0026rsquo;no dot1x port-control\u0026rsquo;, or \u0026rsquo;no dot1x system-auth-control\u0026rsquo;.\u003c/li\u003e\n\u003cli\u003eThe network interface transitions to a force-authorized state, bypassing the normal authentication process.\u003c/li\u003e\n\u003cli\u003eAn unauthorized device is connected to the compromised network interface.\u003c/li\u003e\n\u003cli\u003eThe unauthorized device gains network access without proper authentication or authorization.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the unauthorized access for lateral movement to other systems on the network.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or deploys malicious payloads across the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful disabling of dot1x can lead to unauthorized network access, allowing attackers to bypass security controls. This can result in the compromise of sensitive data, the spread of malware, and the disruption of network services. The number of affected devices and the scope of the compromise depend on the network architecture and the attacker\u0026rsquo;s objectives. The impact could range from a single compromised workstation to a full-scale network breach affecting thousands of devices and users.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eCisco Dot1x Disabled\u003c/code\u003e to your SIEM to detect the execution of commands that disable 802.1X authentication.\u003c/li\u003e\n\u003cli\u003eMonitor Cisco AAA logs for events containing keywords such as \u0026lsquo;access-session port-control force-authorized\u0026rsquo; and \u0026rsquo;no dot1x system-auth-control\u0026rsquo; to identify potential attempts to disable dot1x.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all administrative access to Cisco network devices to prevent unauthorized command execution.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit the configuration of Cisco network devices to ensure that 802.1X is enabled and properly configured on all relevant interfaces.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:23:00Z","date_published":"2024-01-03T18:23:00Z","id":"/briefs/2024-01-cisco-dot1x-disabled/","summary":"Detection of manual disablement of IEEE 802.1X (dot1x) on a Cisco network device interface, potentially allowing unauthorized network access and lateral movement.","title":"Cisco 802.1X (dot1x) Disabled on Network Interface","url":"https://feed.craftedsignal.io/briefs/2024-01-cisco-dot1x-disabled/"},{"_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/"}],"language":"en","title":"CraftedSignal Threat Feed — Attack.credential-Access","version":"https://jsonfeed.org/version/1.1"}