The attacks that no single
event ever reveals.

An attacker takes one common password and tries it against every account they can name. Each account sees one or two failures, comfortably under any lockout threshold, so nothing locks and nothing alerts. From the account side it looks like ordinary user error.

Per account thresholds are the standard control, and a spray is designed to defeat them. Five failures on one account is a lockout. One failure on fifty accounts is invisible, unless you group by the source instead of the target.

Block the source, then check whether any account in the sprayed set subsequently succeeded. A spray that found one working credential is a breach, not an attempt.

Repeated SSH authentication failures from one address, and then that same address logs in successfully. The failures are the attack. The success is the breach.

Most deployments alert on the failures and treat the success as a separate, benign event. The two are only meaningful together, and only when tied to the same source.

Treat the session as compromised. The account that succeeded is the one to rotate, and the source address is the one to block.

Five failed attempts against one account, then that account authenticates successfully. The attacker found the password, whether by guessing, by a list, or by trying a leaked credential that turned out to still work.

Grouped by account rather than by source, so it still fires when the attacker rotates addresses between attempts, which a source based rule would miss entirely.

Force a password reset on that account and review everything it did after the successful login. This is the correlation that most often turns into a real case.

One source address failing logins against several different machines. The attacker is looking for the weakest host in the estate rather than hammering a single door.

Every per host control sees a trickle and stays quiet. Only a view across the whole estate, grouped by source, shows the shape of it.

Block at the perimeter rather than on the individual hosts, and check whether the source reached anything it should not have been able to see.

One account authenticates successfully from two different countries inside the same hour. Nobody flies that fast. Either the credentials are shared between people, or they are in somebody else hands.

Both events are successful logins. Nothing about either one is anomalous on its own, and no severity threshold will ever surface them.

Confirm with the account owner before acting. Shared credentials and corporate VPN egress are the two common benign explanations, and both are worth fixing anyway.

A successful authentication whose source geography sits outside the countries you actually operate in. The simplest possible geographic control, and one of the most effective.

It is a successful login. There is nothing wrong with it except where it came from, which is context no single event rule carries.

Verify against your travel and contractor list. Then decide whether the country belongs on an allow list or the account belongs in a case.

A port scan or web probe from an address, and then an actual attack from that same address. The scan was the attacker choosing a target. The attack is them acting on it.

Internet facing hosts are scanned constantly. Alerting on scans is pure noise, and alerting only on attacks loses the context that this one was researched first.

Prioritise this above an unattributed attack. Somebody who scanned first knows what they found and is far more likely to come back.

A new account is created on a host, and then that account is added to a privileged group. Two entirely ordinary administrative actions that, back to back on one machine, are how an intruder keeps their access after you close the way they came in.

Accounts get created and groups get changed every week in a normal estate. Alerting on either produces noise nobody reads. The sequence on a single host is the signal.

Confirm against your change record. An account creation with no ticket behind it, followed by a privilege grant, is persistence until proven otherwise.

Four attack events against a host, then a user added on that same host. The attacker got in, escalated, and is now provisioning themselves a way back that survives a patch.

The attack events may each be blocked and logged as handled. The account creation looks like administration. Neither half raises an incident alone.

Treat the host as compromised and work the timeline backwards from the account creation. This is the highest severity correlation in the shipped set.