Authentication Anomaly Alerts: Issues for Credential Stuffing and Account Takeover

Last verified on Nov 10, 2026.

What it catches

Attackers who want into accounts do not need a bug. They need passwords from another breach, a list of usernames and patience. The result is a login endpoint that works exactly as designed, for the wrong people. Nothing errors. The signals are in the shape of the traffic: many failures, many accounts, one stolen session used from two continents.

Authentication anomalies is the Sazabi detection for those shapes. The Sazabi agent sets it up for your project: the agent reads your logs, finds your login events and fields, and sets up sensors that ask about them, then keeps them current as your system changes. You do not write login rules.

What the agent's sensors can ask about:

• Bursts of failed logins, whether against one account or across many.
• Credential stuffing, where many different accounts each see a failed attempt or two from rotating addresses.
• Password spraying, where one common password is tried against many accounts.
• Impossible travel, where one account logs in from places too far apart for the time between them.
• Session reuse, where one session or token appears from a second location or client.

Example: stuffing against a login route

This is an example, not output from a real project. A service called accounts-api logs each authentication attempt with the account, the client address and the outcome:

2026-11-08T07:31:02Z INFO accounts-api login account=u_20031 ip=192.0.2.71 result=failed reason=bad_password
2026-11-08T07:31:02Z INFO accounts-api login account=u_20532 ip=192.0.2.88 result=failed reason=bad_password
2026-11-08T07:31:03Z INFO accounts-api login account=u_21107 ip=192.0.2.12 result=failed reason=bad_password
2026-11-08T07:31:03Z INFO accounts-api login account=u_20031 ip=192.0.2.93 result=success

Each address appears once or twice, and each account fails once. Per-address limits see nothing. Across the whole route, the shape is a flood of one-time failures against different accounts, with the odd success. The sensor asks whether failed logins are running far above their usual level, judged by outcome, and Sazabi opens an issue. An example of what it could say:

• Name: Credential stuffing against accounts-api login with successful takeovers
• Description: Failed logins across many distinct accounts rose far above the usual level, from rotating addresses. At least one account logged in successfully from a new address right after a failure.
• Severity: high

The evidence is the failure and success lines grouped by account and address. The agent analysis highlights the successes, because those are the accounts to act on first.

How the agent sets it up

You set nothing up. The agent writes, backtests and maintains the sensors for your project, so a login route with lots of honest mistyped passwords does not generate noise.

This only works if your logs have the events to question. If your identity provider is a separate service whose logs you do not send, the sensor has nothing to ask about. You can also ask support for a specific sensor in plain words, for example "tell me when the share of failed logins goes above its usual level". sazabi signals list --type sensor lists the sensor signals in your project.

What you see and how you get told

The issue sends an Issue triggered notification to in-app, email, Slack DM or SMS, or to a shared Slack or Microsoft Teams channel when a delivery rule matches severity, component or owning team. Ask follow-up questions in the issue, for example which accounts had a success after a failure. Run sazabi issues agent-prompt to hand the fix to a coding agent, such as adding throttling or a second factor prompt. Recurrences while the issue is open or ignored fold into it.

What it needs

Login and session events in your logs, from your app through OpenTelemetry or from a cloud platform such as AWS, including CloudTrail for console sign-ins.

What it does not cover

• Locking accounts, resetting passwords or forcing a logout. Sazabi reports.
• Logins that never reach your logs, such as events held inside a vendor you do not forward from.
• Access that is unusual but uses valid credentials in an ordinary way. Access anomalies as a general category are not covered today.
• A guarantee that every stuffing run is caught. A slow, low-volume attempt can stay inside normal variation.

For queries and thresholds you can apply by hand, see the impossible travel and credential stuffing guide. Definitions are in the glossary entries on credential stuffing and account takeover. Issue volume is metered; see pricing.

A stolen login often leads to a privilege change next.