Detecting identity attacks
A pattern, not a single event
On Day 0, Cedar Inc.'s identity provider rejects a sign-in to an account in the finance team: wrong password. On its own, that record means nothing, because people mistype passwords all day. But within an hour, the same thing happens to hundreds of Cedar accounts, from the same three networks, with the same few common passwords. Together the records show a password spraying attack, one of the patterns in Guessing, spraying, and stuffing.
Detection is the work of finding patterns like that in time to act on them. A detection rule asks a question that no single record can answer. How many accounts has this network tried in the last hour? Has this account ever signed in from this network before? Did a new sign-in method appear minutes after an unusual sign-in? The answers come from comparing records across accounts, across time and across kinds of events.
The shape of an attack over time matters as much as its size. The table compares Cedar's Day 0 spraying with a credential stuffing attack on the photo application, in which an attacker tries username and password pairs leaked from other services.
| Hour | Spraying at Cedar | Stuffing at the photo application |
|---|---|---|
| 06:00 | 212 failures on 212 accounts. None succeeded. | 31 failures on 29 accounts. None succeeded. |
| 07:00 | 208 failures on 208 accounts. None succeeded. | 9,412 failures on 9,380 accounts. 187 succeeded. |
| 08:00 | 215 failures on 214 accounts. None succeeded. | 8,960 failures on 8,901 accounts. 176 succeeded. |
| 09:00 | 206 failures on 206 accounts. None succeeded. | 44 failures on 42 accounts. 1 succeeded. |
The spraying is low and flat. Each hour, a couple of hundred accounts receive one or two attempts each, so no account sees enough guesses to stand out. Cedar's sign-in limits held the attack to about two hundred attempts an hour, and nothing succeeded. The stuffing arrives as a burst, each account tried once with its own leaked password, from more than a thousand addresses. Its danger is in the successes: 187 accounts in one hour signed in on the first attempt, because their owners had reused a password. A rule that counts failures per account would miss both attacks.
Signals worth watching
A signal is a fact in the records that makes an attack more or less likely. Each attack leaves its own traces:
- Failures across many accounts that share a password, a network or a timing pattern.
- A successful sign-in from a network or device the account has never used, especially a hosting provider or an anonymizing service.
- A session used from a different network or device than the one where it started, a sign of replay.
- Approval prompts denied again and again, then one approved, the pattern in Getting around MFA.
- A new sign-in method, recovery address or phone number soon after an unusual sign-in, one of the footholds attackers add.
- Consent to a rarely used application that asks to read or send mail, as in Attacks through apps and integrations.
- Mail rules that forward messages outside the organization.
- Requests to the help desk to reset MFA, especially for administrators.
- New role assignments, and changes to trusted identity providers.
- Tokens presented with no matching sign-in.
Only some of these come from the identity provider. Others live in the mail service, the help desk's tickets or an application's own records. Detection that reads only sign-in records sees how an attacker got in and misses most of what they did next.
Unusual is not the same as malicious
Every one of those signals also happens for innocent reasons. People travel, buy new phones and enroll new authenticators. They work over a mobile connection whose address places them in another city. Developers sign in from cloud workstations in hosting providers' networks. A rule that treats each of these as an attack fires constantly, and the people receiving its alerts learn to dismiss them. That is alert fatigue, and it is how a real alert ends up unread.
Impossible travel shows the problem. The rule compares two sign-ins and asks whether one person could have traveled between their locations in the time between them. But the locations come from network addresses, and an address shows where traffic leaves for the internet, not where the person is sitting. A company VPN sends everyone's traffic out through a few exit points, possibly in another country, and location databases are often simply wrong. Before treating impossible travel as evidence, an analyst checks whether either address belongs to the company's VPN or a mobile carrier, and whether the same device made both sign-ins.
The way out is a baseline: knowing what normal looks like, for the organization and for each account. Riley, in Cedar's finance team, signs in on weekday mornings from Cedar's office network, 198.51.100.0/24, on the same laptop. Against that baseline, a sign-in from a hosting network stands out. For a developer who uses cloud workstations every day, it would not. An alert about something harmless is a false positive, and an attack that raises no alert is a false negative. Every rule trades one against the other, and a baseline lets it be strict where activity really is out of character.
Combining weak signals
Cedar's alert on Day 2 shows why combinations work. At 09:14 on Day 1, Riley's account signed in from a hosting network and passed both the password and authenticator-code checks, because Riley had typed both into a relay page. Alone, that was a successful sign-in from an unfamiliar network. At 09:20, the same session added a new authenticator app. Alone, that is routine.
Together, the two are rare for legitimate users and common in takeovers. An attacker who has relayed one sign-in needs a way back in that no longer depends on the victim, and registering their own authenticator is the quickest. Cedar's rule combined three weak signals: a sign-in from a hosting provider, a new authenticator added minutes later, and a network Riley had never used. Each alone would have produced noise. Together they produced the alert that started Quinn's investigation.
Some detection systems turn signals into a risk score, adding weight for each one and acting above a threshold. Others write explicit rules for known sequences. Either way, order and timing carry meaning. A password reset, then a sign-in from a new network, then a new authenticator four minutes later tells a story that the same three events spread across a month do not. Signals from different systems can be joined as well, though at Cedar nothing linked a refused help-desk call to Riley's account until the investigation.
Responding automatically
Some signals call for action faster than a person can read an alert. A detection system can respond on its own, from gentle to drastic:
- let the request through, and give the account's later activity extra weight;
- ask for stronger authentication, preferably a phishing-resistant method, because a relay passes codes straight through;
- notify the account owner through a channel the attacker is unlikely to control;
- hold a sensitive change, such as a new sign-in method, until the owner confirms it;
- block the request, or end the account's sessions and revoke its tokens.
The response should match both the confidence and the stakes. Blocking every sign-in from a hosting network would lock out developers who work from cloud workstations, while asking them for a passkey costs a few seconds. At Cedar, holding the 09:20 change until it was confirmed with a passkey would have stopped it, because a relay can pass along a code a second time but cannot use a passkey for a look-alike address.
Notifications need care. An email announcing a new authenticator goes to the mailbox an attacker may already be reading, and they can delete it before the owner sees it. A notification to a phone, or to a manager, is harder to intercept. Automated responses should also be recorded, reversible and visible to whoever handles the alert, so a blocked legitimate user can be helped quickly. An identity provider that ends a session can also tell the applications that rely on it.
Alerts someone can act on
When a rule needs a person, the alert is that person's starting point. Here is the fictional alert Quinn received on Day 2:
ALERT New authenticator after unusual sign-in Severity: high
Fired: Day 2 08:50
Account: usr_4182 (Riley, Finance)
Summary: An authenticator app was added from a network this account has
never used, 6 minutes after a sign-in from a hosting provider.
Evidence: Day 1 09:14:06 sign_in.succeeded 203.0.113.24 s-7a91
Day 1 09:20:41 authenticator.added 203.0.113.57 s-7a91
request req_7f3a2c90
Baseline: 214 sign-ins in 90 days, all from 198.51.100.0/24
Next: Confirm with the owner by phone or in person, not by email.
Follow the account takeover procedure.It says what happened in plain words and names the account, so Quinn knows at once that it belongs to someone who handles payments. It carries its evidence, with session and request IDs that lead straight to the records. It shows the baseline that made the activity unusual, and it says what to do next, including what not to do.
Alerts also have to suit the people reading them. Related events are grouped, so a spraying wave produces one alert listing the accounts it touched, not hundreds. Each rule is measured by how often it fires and how often it turns out to be real, and rules that only produce noise are tuned or retired. Speed matters too. Cedar's alert arrived nearly a day after the authenticator was added, and every hour between a signal and a response is an hour the attacker keeps working.
Here are five alerts of the kind an analyst might see in a single day. Decide what each one most likely is.
Triage the alerts
Simulation. These five alerts are made up. Decide whether each is likely an attack, likely benign, or needs more information before anyone can tell; answering sends nothing anywhere.
Quinn's alert was real. Investigating an account compromise follows what Quinn did next.