{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/mfa/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS Management Console"],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","mfa","initial-access"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe absence of multi-factor authentication (MFA) during AWS console logins presents a significant security risk. Threat actors often target AWS environments due to the high value of data and services hosted within. An attacker gaining initial access through compromised credentials can move laterally, escalate privileges, and potentially exfiltrate sensitive data, deploy malicious workloads, or disrupt critical services. This activity can go unnoticed for extended periods, increasing the potential for damage. Detecting successful console logins without MFA is crucial for identifying potential breaches and ensuring the enforcement of security best practices. This brief focuses on detecting these logins to mitigate the risk of unauthorized access and potential data breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid AWS credentials, possibly through phishing, credential stuffing, or by exploiting a vulnerable service.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to attempt to log in to the AWS Management Console.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully authenticates without providing an MFA code, indicating MFA is not enabled or is bypassed for the compromised user.\u003c/li\u003e\n\u003cli\u003eAfter successful login, the attacker enumerates existing AWS resources, including EC2 instances, S3 buckets, and IAM roles, using the AWS CLI or Console.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting IAM misconfigurations or vulnerabilities to gain access to more sensitive resources.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies security configurations, such as disabling CloudTrail logging or creating new IAM users with elevated permissions, to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses sensitive data stored in S3 buckets or databases, potentially exfiltrating it to an external location.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful AWS console login without MFA can lead to a full compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious workloads. The lack of MFA increases the likelihood of successful credential-based attacks, potentially affecting a large number of organizations hosting data and applications in AWS. Consequences include data breaches, financial losses, reputational damage, and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS Successful Console Login Without MFA\u0026rdquo; Sigma rule to your SIEM to detect logins without MFA (rule).\u003c/li\u003e\n\u003cli\u003eEnforce MFA for all AWS IAM users, especially those with administrative privileges to prevent initial access (reference: \u003ca href=\"https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/)\"\u003ehttps://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eRegularly audit IAM configurations to identify and remediate misconfigurations that could allow privilege escalation.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for suspicious activity following a console login, such as resource enumeration or IAM policy changes (logsource).\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-aws-console-login-no-mfa/","summary":"Successful AWS console logins without multi-factor authentication can indicate compromised credentials, misconfigured security settings, or unauthorized access attempts.","title":"Successful AWS Console Login Without MFA","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-console-login-no-mfa/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","mfa","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe absence of multi-factor authentication (MFA) during the activation of privileged roles in Azure Privileged Identity Management (PIM) poses a significant security risk. When roles can be activated without MFA, attackers who have already compromised a user account can escalate their privileges without needing to bypass an MFA challenge. This scenario circumvents a critical security control, making the environment vulnerable to lateral movement, data exfiltration, and other malicious activities. This brief is based on Sigma rule 94a66f46-5b64-46ce-80b2-75dcbe627cc0, published on 2023-09-14. Defenders need to monitor PIM configurations to ensure that MFA is enforced for all privileged role activations, mitigating the risk of unauthorized access and privilege escalation.\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 user account, potentially through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a privileged role within Azure PIM that the compromised user is eligible to activate.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to activate the privileged role using the compromised user\u0026rsquo;s credentials.\u003c/li\u003e\n\u003cli\u003eDue to misconfiguration, MFA is not required for the role activation process.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully activates the privileged role without providing a second factor of authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly acquired privileges to access sensitive resources and data within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions such as creating new accounts, modifying configurations, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating backdoors or modifying access control policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe absence of MFA during PIM role activation can lead to significant damage, potentially affecting all resources within the Azure environment accessible to the compromised privileged role. Successful exploitation allows attackers to bypass a critical security control, leading to privilege escalation, data breaches, and system compromise. The impact spans data confidentiality, integrity, and availability, and could result in regulatory fines, reputational damage, and financial losses.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Roles Activation Doesn\u0026rsquo;t Require MFA\u0026rdquo; to your SIEM and tune for your environment to detect instances where privileged roles are activated without MFA based on \u003ccode\u003eriskEventType: 'noMfaOnRoleActivationAlertIncident'\u003c/code\u003e in Azure PIM logs.\u003c/li\u003e\n\u003cli\u003eReview and enforce MFA policies for all privileged role activations within Azure PIM, as recommended in the Microsoft documentation (\u003ca href=\"https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts#roles-dont-require-multi-factor-authentication-for-activation\"\u003ehttps://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts#roles-dont-require-multi-factor-authentication-for-activation\u003c/a\u003e).\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-azure-pim-no-mfa/","summary":"Detection of Azure Privileged Identity Management (PIM) roles being activated without requiring multi-factor authentication, potentially leading to unauthorized privilege escalation and persistence.","title":"Azure PIM Role Activation Without MFA","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-no-mfa/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Cloud"],"_cs_severities":["medium"],"_cs_tags":["okta","mfa","credential-access","persistence"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eAttackers may attempt to disable or reset MFA to bypass security controls and gain unauthorized access to user accounts. This activity is often part of a broader attack campaign, such as credential stuffing or account takeover. The Okta platform provides detailed logs of user authentication events, including MFA resets and deactivations. Monitoring these events is crucial for detecting and responding to potential account compromise attempts. These attempts can originate from various sources, including compromised administrator accounts or direct attacks on user accounts. The impact of successful MFA bypass can be significant, potentially leading to data breaches, financial loss, and reputational damage.\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\u0026rsquo;s Okta account, possibly through phishing or credential compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta tenant using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a request to reset or deactivate one or more of the user\u0026rsquo;s MFA factors through the Okta API or web interface.\u003c/li\u003e\n\u003cli\u003eOkta generates a system log event of type \u003ccode\u003euser.mfa.factor.deactivate\u003c/code\u003e or \u003ccode\u003euser.mfa.factor.reset_all\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker can then authenticate without providing the MFA factor, bypassing a critical security control.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to access sensitive applications and data within the Okta environment.\u003c/li\u003e\n\u003cli\u003eThe attacker may perform lateral movement to access other user accounts or systems.\u003c/li\u003e\n\u003cli\u003eThe final objective may include data exfiltration, financial fraud, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful MFA deactivation or reset can lead to complete account takeover. Depending on the compromised user\u0026rsquo;s role and access permissions, this could result in significant data breaches, unauthorized access to sensitive systems, and financial losses. The impact scales with the number of compromised accounts and the sensitivity of the data they can access. This activity targets all sectors relying on Okta for identity and access management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect suspicious MFA reset or deactivation attempts in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts for \u003ccode\u003euser.mfa.factor.deactivate\u003c/code\u003e or \u003ccode\u003euser.mfa.factor.reset_all\u003c/code\u003e events, as described in the Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview Okta system logs for unusual authentication patterns, focusing on users with recently deactivated MFA factors, as detailed in the Okta API documentation.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and monitoring for Okta administrator accounts to prevent unauthorized MFA modifications.\u003c/li\u003e\n\u003cli\u003eEducate users about phishing and credential security to reduce the risk of initial access 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-okta-mfa-reset/","summary":"An attacker attempts to disable or reset multi-factor authentication (MFA) for a user account in Okta, potentially leading to unauthorized access and account compromise.","title":"Okta MFA Reset or Deactivation Attempt","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-mfa-reset/"},{"_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/"}],"language":"en","title":"CraftedSignal Threat Feed — Mfa","version":"https://jsonfeed.org/version/1.1"}