Why attackers go after identity
A sign-in that wasn't Riley's
At 08:50 one morning, an alert reaches Quinn on Cedar Inc.'s security team. It combines three weak signals from the day before. Riley's account signed in from a hosting provider, a company that rents servers to anyone who pays. Minutes later, a new authenticator app was added to the account. And it was added from a network Riley had never used. Riley works in Cedar's finance team and normally signs in from the office network, 198.51.100.0/24. Quinn pulls the records for Riley's account, usr_4182.
Day 1 event actor session source
09:14:06 sign_in.succeeded usr_4182 s-7a91 203.0.113.24
09:20:41 authenticator.added usr_4182 s-7a91 203.0.113.57There is no sign of a break-in. No server was compromised, and no flaw in Cedar's software was exploited. Riley had followed a link in an email about a shared invoice to a page that looked like Cedar's sign-in. The page passed Riley's password and code to the real identity provider and kept the session it issued. This is phishing: a message designed to trick someone into handing over the evidence that opens their account. From then on, Cedar's systems treated the attacker as Riley.
That is why attackers go after identity. Breaking into software means finding a flaw its builders missed. A sign-in page exists to let people in, and, as Proving control of an account points out, someone who obtains the right evidence may satisfy the same check as its owner. An attacker who signs in inherits everything the account can do, and their activity looks like ordinary work.
What an identity is worth
Riley's password sounds like the prize, but it is only one of several things an attacker can take. A stolen password allows new sign-ins. A stolen session skips the sign-in entirely, second factor included, because the service has already accepted it. Staying signed in explains why: possession of a session identifier can be enough to use the session.
| What is taken | What it gives the attacker | What limits it |
|---|---|---|
| Credential | New sign-ins from anywhere, until it is changed or removed | Methods that resist phishing, refusing known passwords |
| Session | Access with no sign-in check, until the session ends | Shorter lifetimes, sessions tied to a device |
| Token | Calls to an API within the access it grants, until it expires | Narrow scopes, short lifetimes, revocation |
| Signing key | Tokens for any account, with no sign-in at all | Keys that cannot be exported, watching their use |
| Role | Changes to other people's accounts, policies and settings | Fewer administrators, stronger sign-in |
| Trust relationship | Access through a provider or app the organization already trusts | Limits on who can add or approve them |
Each of these lasts a different time and is checked at a different point, so each needs its own protection. Changing a password ends the value of a stolen password, but it may leave a stolen session, a newly added authenticator or an app's access working. A signing key is the most valuable of all. Every application that trusts it accepts the tokens it signs, and no sign-in record exists for them, because no sign-in happened. As Digital signatures explains, a valid signature shows which key signed, not who was holding it.
Getting in, staying in, gaining more
Attacks on identity rarely stop at the first sign-in. Getting in is the first access to an account. Staying in, often called persistence, means arranging ways back that keep working after the owner changes a password or signs out. Gaining more, or escalation, turns one account into more: other accounts, administrative roles or other systems. Finally the attacker acts: reading data, moving money, or sending messages that people trust because of who appears to send them. Here is the Cedar incident at a glance. Like every scenario in these lessons, it is fictional.
Day 0
From three addresses, a few common passwords are tried against hundreds of Cedar accounts within an hour. Sign-in limits slow the guessing, and nothing succeeds.
Getting in, attempted
Day 1, 09:02
Riley receives an email about a shared invoice. Its link leads to a relay page at a look-alike address, login-cedar.example.
Getting in
Day 1, 09:14
Riley enters a password and an authenticator-app code. The relay passes both to Cedar's identity provider and keeps the session it issues. Riley sees an ordinary-looking page, never the invoice.
Getting in, succeeded
Day 1, 09:20
From a hosting network, the attacker uses the stolen session to add their own authenticator app. The session is minutes old, so a recent sign-in check lets it through.
Staying in
Day 1, 09:31
The attacker approves a third-party app called Invoice Sync to read and send Riley's mail.
Staying in
Day 1, 10:05
Posing as an IT contractor, the attacker asks Rowan at the help desk to reset MFA on an administrator's account. Rowan calls back the number in Cedar's directory, and the request is refused and recorded.
Gaining more, refused
Day 1, 11:30
Using the access approved at 09:31, Invoice Sync reads a vendor email that contains an API key for Cedar's payments vendor.
Gaining more
Day 2, 08:50
The alert fires, and Quinn investigates.
Detected
Day 2, later
Cedar contains the incident, gives Riley the account back and replaces the vendor's API key.
Response
The guessing on Day 0 and the relay on Day 1 were both attempts to get in, and only the second worked. The authenticator app, the Invoice Sync approval and the mail rule are three ways to stay in, each able to survive a password change. The help desk call and the vendor key were attempts to gain more. Everything pointed toward acting: Invoice Sync could send mail as Riley, and the forwarding rule collected exactly the conversations a convincing fake payment request would need.
Every stage also gave Cedar a chance. Sign-in limits blunted the guessing, Rowan's callback stopped the help desk request, and the records of the sign-in and the new authenticator raised the alert. Phishing and relayed sign-ins follows the relay, How attackers stay in explains why the changes made between 09:20 and 09:40 outlast a password reset, and Investigating an account compromise rebuilds this timeline from Quinn's records.
Customers and employees
The attacker chose Riley. The email was about an invoice because Riley works in finance, and the help desk call named an administrator because that account could change everyone else's. This is a targeted attack: the attacker picks the organization, often the person, and puts effort into making each step convincing.
Customers of the photo application from the Identity fundamentals lessons are mostly attacked at scale. Someone holding millions of email and password pairs leaked from other services tries them all, knowing that a small fraction will work because people reuse passwords. This is credential stuffing, and nobody chooses the customers it catches. Each account is worth little on its own, so the attacker relies on volume and on the cheapest possible attempt.
The difference shapes the defenses. An employer can require particular sign-in methods, manage the devices people use and train its help desk. A consumer service cannot choose its customers' devices, and it must let people who have lost everything recover their accounts without a help desk that knows them. Its strongest tools work across the whole service, such as limits that notice one password tried against thousands of accounts, which Guessing, spraying, and stuffing covers in detail.
The line is not sharp. Automated guessing reached Cedar on Day 0, and a well-known customer of the photo application can be targeted personally. Both face the same paths into an account.
The weakest path wins
Suppose a customer of the photo application signs in with a passkey. As Security keys, passkeys, and biometrics explains, a passkey cannot be guessed, reused from someone else's breach, or used on a fake page. But the account also offers "Lost your passkey?", which sends a code by text message, and a phone number can be moved to another SIM. An attacker simply ignores the passkey and chooses the text message. The account is only as strong as the weakest path into it, not the method its owner uses every day.
Counting those paths is the start of defending an account. Sign-in methods and their fallbacks are one. Recovery is another, and so is the help desk. Sessions already issued, apps already granted access, and the signing key behind every token are each a separate way to end up acting as the account.
At Cedar, Riley's password and authenticator-app code both passed straight through the relay. The help desk path held because Rowan called back the number in Cedar's directory instead of trusting the caller. Paths outside the sign-in page are often run by people and older systems, and are sometimes protected by little more than a few personal details that can be found or guessed.
The map also runs the other way. What lies beyond an account decides how much each path into it is worth. Riley's mailbox held a key to a payments vendor, and an administrator's account would have opened every other account at Cedar. Finding these paths before an attacker does is the work of Threat modeling an identity system.