LoFP LoFP / t1556

t1556

TitleTags
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.
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.
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 network interface configuration changes may trigger this detection during routine network maintenance or initial device setup. network administrators often need to create or modify interfaces as part of normal operations. to reduce false positives, consider implementing a baseline of expected administrative activities, including approved administrative usernames, typical times for interface configuration changes, and scheduled maintenance windows. you may also want to create a lookup table of approved interface naming conventions and filter out alerts for standard interface configurations.
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 device deactivation may occur legitimately during device rotation, user offboarding, or troubleshooting. for example, aws requires deactivation of an existing mfa device before adding a replacement. these actions are often performed by administrators following approved change-control processes. to reduce false positives, validate whether the deactivation aligns with a documented workflow, known device replacement, or expected maintenance window. if performed outside of expected operational hours, by an unexpected user, or from an unfamiliar source ip, this event should be investigated for potential credential compromise or unauthorized tampering.
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.
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.
some legitimate administrative workflows or ci/cd automation pipelines may temporarily configure or re-enable mfa devices using session-based credentials. validate the calling identity’s purpose, source ip, and user agent to confirm whether this activity was authorized. additionally, when a user creates or enables a virtual mfa device through the aws management console, the underlying cloudtrail event will also show a temporary credential (access key id beginning with asia), because the console itself issues short-lived sts session credentials for every logged-in user. these events are expected and should not be considered suspicious.
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.
unknown
unless it is a special case, it is uncommon to disable mfa or strong authentication
updates to approved and trusted ssh executables can trigger this rule.
user removed from the group is approved
users accessing their accounts from anonymized ip addresses, such as vpns or tor, may trigger this rule. if this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or ip ranges.
users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. if this is expected behavior, consider adjusting the rule or adding exceptions for specific users.
users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. if this is expected behavior, consider adjusting the rule or adding exceptions for specific users.