Containing and recovering

Cutting off access

By mid-morning on Day 2, Quinn, on Cedar Inc.'s security team, knows what happened to Riley's account in finance. On Day 1, an attacker relayed Riley's password and authenticator code through a fake sign-in page and kept the session that Cedar's identity provider issued. With that session, they registered their own authenticator app, approved an app called Invoice Sync to read and send Riley's mail, and created a rule forwarding messages about invoices to an outside address. They still know Riley's password.

Containment stops the attacker's access before anything else is repaired. The order matters, because the attacker holds several ways in at once. With Riley's password and their own authenticator, they can complete a fresh sign-in whenever they like. Invoice Sync reads mail with its own refresh token, and the mail rule needs no sign-in at all. Remove one of these and the others keep working, and an attacker who notices one door closing tends to open another.

Cedar removes them together, in one short planned window:

Blocking new sign-ins comes first, because ending sessions while the attacker can still sign in only invites them to start another. With sign-in blocked, Cedar ends every session on the account, revokes Invoice Sync's access and the tokens issued under it, then removes the attacker's authenticator and the mail rule and checks the recovery settings for anything else that changed. Only then does Riley get the account back. Blocking sign-in also locks Riley out for a while, so Quinn tells Riley in person before it starts.

The dotted path is the shortcut people take under pressure: reset the password first. It feels decisive, and on many systems it ends the account's sessions. But the attacker's authenticator stays registered as one of Riley's methods, Invoice Sync keeps reading mail, and the rule keeps forwarding it. If Cedar's self-service recovery accepted an authenticator code on its own, the attacker could even reset the password themselves. A reset done alone also tells the attacker they have been noticed.

Removing every way back

The list of footholds comes from the investigation, and for a taken-over account it is usually longer than people expect. How attackers stay in describes each kind. A complete cleanup checks for:

• sessions at the identity provider, and in each application that keeps its own session after sign-in;
• refresh tokens and app grants, which survive a password change on many systems;
• added sign-in methods: authenticator apps, passkeys, security keys and phone numbers;
• recovery settings, such as a changed recovery address or phone number;
• app passwords and personal access tokens, which skip the sign-in page entirely;
• mail rules, forwarding settings and mailbox delegates;
• roles, group memberships and configuration the account was able to change.

Each kind of access ends differently, as Revoking access and sharing security events explains. Ending Riley's session at the identity provider does not end a session that an application created after Riley signed in. That application has to be told, either directly or through a security event it receives, and an access token it already accepted may keep working until it expires. Quinn checks each application Riley uses, not just the identity provider.

An added passkey or security key deserves particular attention, because it can complete a sign-in with no password at all. Had the attacker registered a passkey instead of an authenticator app, a password reset would not have slowed them down for a moment. Any method Riley does not recognize goes. Cedar goes further and removes every method on the account, so that Riley enrolls again from scratch and nothing is left that anyone has to reason about.

Some footholds reach beyond one account. Cedar blocks Invoice Sync for the whole organization, so nobody else can approve it, as Attacks through apps and integrations recommends for apps like it. It also stops automatic forwarding to outside addresses for the finance team.

Giving the account back

Returning the account means being sure the person who receives it is Riley. Every channel the attacker touched is ruled out. Riley's mailbox is out, because the attacker read it. So is a code from an authenticator app, because until this morning one of the authenticators on the account belonged to the attacker. Cedar uses a channel the attacker never controlled: Riley comes to the help desk in person, where Rowan checks Riley against the photo in Cedar's directory. For someone working remotely, a video call with their manager, or a call to a phone number recorded before the incident, does the same job. Attacks on recovery and the help desk explains why each of these holds up.

Riley then sets a new password and enrolls new methods. Because the attacker got in by relaying a code, Cedar moves Riley to a passkey. A relay page cannot use it, because the browser ties each passkey to Cedar's real sign-in address, as Phishing and relayed sign-ins describes.

The account comes back carefully. For the first few days, Cedar asks Riley to confirm sensitive changes, such as adding a method or approving an app, with the new passkey, and the security team watches the account closely. Quinn also explains to Riley what happened and why, without blame. The page was convincing, and the fixes that matter most are to the system, not to Riley.

Try putting Cedar's cleanup in order.

Repairing what changed

Cutting off access does not undo what the attacker did while inside. Some changes can be reversed: the mail rule is gone, and the authenticator with it. Others cannot. Messages already forwarded to the outside address stay there, and the API key that Invoice Sync read from the payments vendor's email at 11:30 on Day 1 has been seen.

Quinn works through what the timeline shows. The rule forwarded every message mentioning an invoice for a full day, so Cedar lists those messages and works out whose information they contained: vendors, customers, bank details. If anything was sent in Riley's name, its recipients hear from Cedar directly, because a request to change payment details from a genuine Cedar mailbox is very convincing. The vendor key is replaced and its use checked, as Rotating credentials and keys after exposure describes. Depending on the information involved and where Cedar operates, some of this may also have to be reported to the people affected or to regulators, a decision for Cedar's legal and privacy staff.

Configuration needs the same care. The administrator's account should be untouched, because the help desk refused the caller's MFA reset, but Quinn confirms that from the records rather than assuming it.

Watching for a return

An attacker who loses access often tries again. They know Riley's role, which vendors Cedar pays and what Cedar's invoices look like, and they may hold something the cleanup missed. For the following weeks, Cedar watches for the specific traces of this incident:

• sign-in attempts to Riley's account, or any account, from 203.0.113.0/24;
• attempts to approve Invoice Sync, now blocked, or other apps asking for access to mail;
• new mail rules forwarding outside Cedar;
• requests to reset sign-in methods for Cedar's administrators;
• requests made with the old vendor key.

Specific traces like these are indicators: values that tie activity to one incident. They lose their value quickly, because attackers change networks, app names and stories, so Cedar also strengthens the general rule that caught this incident. A rejected sign-in with Riley's old password from the attacker's network is useful news: the cleanup held, and the attacker is still interested.

Learning from the incident

Once the account is back and the watch is in place, Cedar holds a post-incident review. Quinn, Rowan and the teams that run sign-in, mail and payments walk through the timeline together. The review is blameless: it asks how the attack worked and why each defense let it through, not who made a mistake. Riley did what many careful people do with a convincing page, and a defense that depends on nobody ever being fooled will fail again. People who expect blame also stop reporting the next suspicious email.

The review's output is a list of findings, each one a specific change with an owner and a date. The review meets again later to check which of those changes actually happened. Findings about the attack itself, such as which defense would have stopped the relay or the app approval, are the subject of Layered defenses and secure defaults, which maps every step of the incident to the layer that would have stopped it.

Two of Cedar's findings came from the response rather than the attack. The mail service had recorded the forwarding rule without a session ID, so Quinn could tie it to the attacker only by network and timing. The mail team takes that finding, and from then on records the session behind every mailbox change. The second finding concerns the alert. It fired almost a day after the authenticator was added, and the attacker spent that day reading mail. Why the rule took so long, and how to make it fire within minutes, goes to the security team as a finding of its own. The review also records what worked, such as records detailed enough to rebuild the morning, so that those are kept and tested rather than taken for granted.