Mfa — CraftedSignal Threat Feed

Successful AWS Console Login Without MFA

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

The 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.

Attack Chain

An attacker obtains valid AWS credentials, possibly through phishing, credential stuffing, or by exploiting a vulnerable service.
The attacker uses the compromised credentials to attempt to log in to the AWS Management Console.
The attacker successfully authenticates without providing an MFA code, indicating MFA is not enabled or is bypassed for the compromised user.
After successful login, the attacker enumerates existing AWS resources, including EC2 instances, S3 buckets, and IAM roles, using the AWS CLI or Console.
The attacker attempts to escalate privileges by exploiting IAM misconfigurations or vulnerabilities to gain access to more sensitive resources.
The attacker modifies security configurations, such as disabling CloudTrail logging or creating new IAM users with elevated permissions, to establish persistence.
The attacker accesses sensitive data stored in S3 buckets or databases, potentially exfiltrating it to an external location.

Impact

A 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.

Recommendation

Deploy the “AWS Successful Console Login Without MFA” Sigma rule to your SIEM to detect logins without MFA (rule).
Enforce MFA for all AWS IAM users, especially those with administrative privileges to prevent initial access (reference: https://securitylabs.datadoghq.com/cloud-security-atlas/vulnerabilities/iam-user-without-mfa/).
Regularly audit IAM configurations to identify and remediate misconfigurations that could allow privilege escalation.
Monitor CloudTrail logs for suspicious activity following a console login, such as resource enumeration or IAM policy changes (logsource).

Azure PIM Role Activation Without MFA

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

The 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.

Attack Chain

An attacker gains initial access to a user account, potentially through phishing or credential stuffing.
The attacker identifies a privileged role within Azure PIM that the compromised user is eligible to activate.
The attacker attempts to activate the privileged role using the compromised user’s credentials.
Due to misconfiguration, MFA is not required for the role activation process.
The attacker successfully activates the privileged role without providing a second factor of authentication.
The attacker leverages the newly acquired privileges to access sensitive resources and data within the Azure environment.
The attacker performs malicious actions such as creating new accounts, modifying configurations, or exfiltrating data.
The attacker establishes persistence by creating backdoors or modifying access control policies.

Impact

The 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.

Recommendation

Deploy the Sigma rule “Roles Activation Doesn’t Require MFA” to your SIEM and tune for your environment to detect instances where privileged roles are activated without MFA based on riskEventType: 'noMfaOnRoleActivationAlertIncident' in Azure PIM logs.
Review and enforce MFA policies for all privileged role activations within Azure PIM, as recommended in the Microsoft documentation (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).

Okta MFA Reset or Deactivation Attempt

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

Attackers 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.

Attack Chain

The attacker gains initial access to a user’s Okta account, possibly through phishing or credential compromise.
The attacker authenticates to the Okta tenant using the compromised credentials.
The attacker initiates a request to reset or deactivate one or more of the user’s MFA factors through the Okta API or web interface.
Okta generates a system log event of type user.mfa.factor.deactivate or user.mfa.factor.reset_all.
If successful, the attacker can then authenticate without providing the MFA factor, bypassing a critical security control.
The attacker leverages the compromised account to access sensitive applications and data within the Okta environment.
The attacker may perform lateral movement to access other user accounts or systems.
The final objective may include data exfiltration, financial fraud, or other malicious activities.

Impact

Successful MFA deactivation or reset can lead to complete account takeover. Depending on the compromised user’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.

Recommendation

Deploy the provided Sigma rules to your SIEM to detect suspicious MFA reset or deactivation attempts in Okta logs.
Investigate any triggered alerts for user.mfa.factor.deactivate or user.mfa.factor.reset_all events, as described in the Sigma rule.
Review Okta system logs for unusual authentication patterns, focusing on users with recently deactivated MFA factors, as detailed in the Okta API documentation.
Implement strict access controls and monitoring for Okta administrator accounts to prevent unauthorized MFA modifications.
Educate users about phishing and credential security to reduce the risk of initial access compromise.

Azure AD MFA Disabled to Bypass Authentication

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

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

Attack Chain

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

Impact

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

Recommendation

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