LoFP LoFP / t1110

t1110

TitleTags
a legitimate application that has been deleted from the tenant while a client continues to authenticate against its former client id via ropc can generate error code 700016. a misconfigured legacy client submitting an incorrect client id is also possible. in both cases the client id is typically stable and low-volume, unlike the many distinct or randomized identifiers seen in spoofing. verify the application identifier, the source infrastructure, and whether the same principal is targeted by many different unresolved client ids.
a misconfigured service account can trigger this alert. a password change on an account used by an email client can trigger this alert. security test cycles that include brute force or password spraying activities may trigger this alert.
a user experiencing legitimate login issues (forgotten password, typos) may trigger credential attack alerts before successfully authenticating.
a user experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
account fallback reasons (after failed login with specific account)
an okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.
automated monitoring or penetration testing tools scanning from multiple ips.
automated password reset flows where a user fails multiple times then succeeds after resetting their password.
automated processes or misconfigured applications retrying authentication may trigger this rule.
automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives.
automated testing or monitoring tools that do not persist cookies may trigger this rule.
based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed totp code attempts in a short time-span over multiple sessions.
build servers and ci systems can sometimes trigger this alert. security test cycles that include brute force or password spraying activities may trigger this alert.
corporate proxy or vpn exit nodes may aggregate traffic from multiple legitimate users.
expected red team assessments or penetration tests may utilize teamfiltration to evaluate the security posture of azure or microsoft 365 environments. if this is expected behavior, consider adjusting the rule or adding exceptions for specific ip addresses, registered applications, jwt tokens, prts or user
known legacy accounts
large enterprises with many users experiencing simultaneous password issues during credential rotation events.
legitimate administrative or security assessment activities may use these user-agents, especially in environments where teamfiltration is employed for authorized audits. if this is expected behavior, consider adjusting the rule or adding exceptions for specific user-agents or ip addresses.
legitimate failed login attempts by authorized users. investigate the source of repeated failed login attempts.
legitimate or intentional inbound connections from public ip addresses on the rdp port.
legitimate user wrong password attempts.
misconfigured phones, expired credentials, or provisioning errors can generate repeated register failures from a single device. validate the client, affected extensions, and registration state before escalating.
misconfigured systems
security audits may trigger this alert. conditions that generate bursts of failed logins, such as misconfigured applications or account lockouts could trigger this alert.
service account misconfigured
shared egress addresses, managed service providers, help desks, identity-provider outages, password rotation, or several legitimate users entering incorrect credentials before another user successfully authenticates may trigger this rule. add exceptions only for confirmed shared-service sources and scope them to the relevant appliance.
shared service accounts accessed from multiple legitimate infrastructure ips.
shared systems such as kiosks and conference room computers may be used by multiple users.
shared systems such as kiosks or conference room computers may have multiple users authenticating.
software that uses the caret encased keywords pass and user in its command line
systems with names equal to the spoofed ones used by the brute force tools
this event could stem from users changing an account's password that's used to authenticate via a job or an automated process. investigate the source of such events and mitigate them
tools that use similar command line flags and values
unknown
unlikely. except due to misconfigurations
user has been put in acception group so they can use legacy authentication
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 actually login but miss-click into the deny button when mfa prompt.
users may share an endpoint related to work or personal use in which separate okta accounts are used.
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.
users with legitimate multi-location access (mobile + home + office) experiencing concurrent login issues.
vulnerability scanners
we recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user.