LoFP LoFP / t1110

t1110

TitleTags
a host failing to authenticate with multiple disabled domain users is not a common behavior for legitimate systems. possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems missconfigured systems.
a host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems and missconfigured systems.
a host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. if this detection triggers on a host other than a domain controller, the behavior could represent a password spraying attack against the host's local accounts.
a host failing to authenticate with multiple valid users against a remote host is not a common behavior for legitimate systems. possible false positive scenarios include but are not limited to vulnerability scanners, remote administration tools, missconfigyred systems, etc.
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 process failing to authenticate with multiple users is not a common behavior for legitimate user sessions. possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems.
a source ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior.
a source ip failing to authenticate with multiple users is not a common for legitimate behavior.
a source user failing attempting to authenticate multiple users on a host is not a common behavior for regular systems. some applications, however, may exhibit this behavior in which case sets of users hosts can be added to an allow list. possible false positive scenarios include systems where several users connect to like mail servers, identity providers, remote desktop services, citrix, etc.
a user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application.
a user with successful authentication events from different ips may also represent the legitimate use of more than one device. filter as needed and/or customize the threshold to fit your environment.
account fallback reasons (after failed login with specific account)
administrator tooling or automated scripts may make these calls but it is highly unlikely to make several calls in a short period of time.
although unusual, users who have lost their passwords may trigger this detection. filter as needed.
an ip address with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application.
an okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.
applications that deal with non-domain joined authentications. recommend adjusting the upperbound_unique eval for tailoring the correlation to your environment, running with a 24hr search window will smooth out some statistical noise.
automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives.
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.
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.
details for the risk calculation algorithm used by identity protection are unknown and may be prone to false positives.
domain controllers, authentication chokepoints, and vulnerability scanners.
false positives may be generated by normal provisioning workflows for user device registration.
false positives may be present. tune okta and tune the analytic to ensure proper fidelity. modify risk score as needed. drop to anomaly until tuning is complete.
false positives will be limited to the number of events generated by the analytics tied to the stories. analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization.
if this was approved by system administrator.
it is common to see a spike of legitimate failed authentication events on monday mornings.
known legacy accounts
legitimate or intentional inbound connections from public ip addresses on the smb port.
legitimate user wrong password attempts.
misconfigured systems
multiple account lockouts may be also triggered by an application malfunction. filter as needed, and monitor for any unusual activity.
no known false positives for this detection. please review this alert
no known false postives for this detection. please review this alert
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 systems such as kiosks and conference room computers may be used by multiple users.
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
the threshold for alert is above 10 attempts and this should reduce the number of false positives.
this detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of vpns or cloud services that rotate ip addresses. filter as needed.
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
unlikely. except due to misconfigurations
user has been put in acception group so they can use legacy authentication
users actually login but miss-click into the deny button when mfa prompt.
users may genuinely mistype or forget the password.
users may genuinely reset the rds password.
users may share an endpoint related to work or personal use in which separate okta accounts are used.
vulnerability scanners
vulnerability scanners or system administration tools may also trigger this detection. filter as needed.
vulnerability scanners, print servers, and applications that deal with non-domain joined authentications. recommend adjusting the upperbound_unique eval for tailoring the correlation to your environment, running with a 24hr search window will smooth out some statistical noise.
we recommend investigating the sessions flagged by this detection in the context of other sign-ins from the user.