LoFP LoFP / t1556

t1556

TitleTags
a mfa device may be deactivated by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. mfa device deactivations from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
a windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative action. following this, the administrator may have reset the mfa credentials for themselves and then logged into the okta console for ad directory services integration management.
administrators may remove 2-step verification (2sv) temporarily for testing or during maintenance. if 2sv was previously enabled, it is not common to disable this policy for extended periods of time.
approved administrator/owner activities.
authorized changes to the aws account's identity provider
authorized modification by administrators
authorized third party network logon providers.
aws administrators may disable mfa but it is highly unlikely for this event to occur without prior notice to the company
consider adding exceptions to this rule to filter false positives if sign on policies for okta applications are regularly modified or deleted in your organization.
disabling a dkim configuration may be done by a system or network administrator. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
fidelity of this is high as okta is specifying malicious infrastructure. filter and modify as needed.
if a mfa reset or deactivated was performed by a system administrator.
if the behavior of deactivating mfa for okta user accounts is expected, consider adding exceptions to this rule to filter false positives.
if this was approved by system administrator.
legitimate administrative use
legitimate use case may require for users to disable mfa. filter as needed.
legitimate use case may require for users to disable mfa. filter lightly and monitor for any unusual activity.
logon errors may not be malicious in nature however it may indicate attempts to reuse a token or password obtained via credential access attack.
mfa settings may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
misconfigured role permissions
modifications in the msds-keycredentiallink attribute can be done legitimately by the azure ad connect synchronization account or the adfs service account. these accounts can be added as exceptions.
newly onboarded users who are registering an mfa method for the first time will also trigger this detection.
potential to be triggered by an administrator disabling protections for troubleshooting purposes.
public access is a common configuration used to enable access from outside a private vpc. ensure that the instance should not be modified in this way before taking action.
trusted openssh executable updates. it's recommended to verify the integrity of openssh binary changes.
trusted system module updates or allowed pluggable authentication module (pam) daemon configuration changes.
unless it is a special case, it is uncommon to disable mfa or strong authentication
unlikely
updates to approved and trusted ssh executables can trigger this rule.
user removed from the group is approved