Investigating an account compromise

Starting from one alert

At 08:50 on Day 2, Quinn, on Cedar Inc.'s security team, receives an alert about Riley's account. Riley works in finance and normally signs in from Cedar's office network, 198.51.100.0/24. The alert says that at 09:20 the day before, an authenticator app was added to Riley's account from a network the account had never used, six minutes after a sign-in from a hosting provider's network, 203.0.113.0/24.

The alert describes one change. It does not say how the attacker got in, what else they did, or whether they are still inside. An investigation answers those questions from the records. Quinn's first decision is how urgent this is. The account belongs to someone who handles invoices and payments, the change is nearly a day old, and anyone holding a working authenticator for the account may be able to come back whenever they like. Quinn treats it as an active compromise and opens an incident record: a running document of findings, times, decisions and the people involved.

The incident record matters more than it might seem. Investigations involve several people over hours or days, and the responders' own actions, such as ending a session or exporting a mailbox, appear in the same records as the attacker's. Writing down what responders did, and when, is what keeps the two apart later.

Questions an investigation answers

Every account investigation works toward the same four questions:

1. How did the attacker get in, and when?
2. What did they do and change while inside?
3. What access do they still have?
4. Who and what else is affected?

Each question points at different records. The first lives in sign-in records: which sign-in started the attacker's session, from where, and with which methods. The second needs the audit history of the account and of the services it reaches, such as method changes, consents, mail rules, and messages read or sent. The third is a list of footholds, everything that would let the attacker return, of the kinds described in How attackers stay in. The fourth turns outward, to other accounts, other systems, and the people and organizations whose information passed through the account.

Throughout, Quinn keeps facts and hypotheses apart. "Session s-7a91 added an authenticator at 09:20 from 203.0.113.57" is a fact taken from a record. "Riley was phished" is a hypothesis until the records, or Riley, confirm it. Writing hypotheses down as hypotheses stops an early guess from quietly becoming the conclusion.

Building a timeline

A timeline puts every relevant event in one sequence. Quinn builds it by pivoting: starting from one known value in the alert and searching for every record that shares it. The authenticator was added by session s-7a91, so Quinn searches for that session. It was created by a sign-in at 09:14 on Day 1 from 203.0.113.24, which passed both the password and the authenticator-code checks. Later that morning, the same session approved a third-party app called Invoice Sync.

Each finding gives new values to pivot on. The app's client ID leads to the mail service's records of what Invoice Sync read. The attacker's network leads to a mail rule created from 203.0.113.57. Searching the help desk's tickets from that morning turns up a refused call from a supposed IT contractor on Cedar's mail migration, a project discussed at length in Riley's mail. Request IDs connect records that different services wrote for the same request, and synchronized clocks let records from different systems sit in one trustworthy order, as Recording identity activity explains.

Combined with what Riley later remembered, the records give this timeline:

1. Day 0

   A wave of guesses using a few common passwords hits hundreds of Cedar accounts within an hour, from three networks. Sign-in limits slow it down, and nothing succeeds. Quinn finds no successful sign-in from the wave.

2. Day 1, 09:02

   Riley receives an email about a shared invoice. Its link leads to a relay page at login-cedar.example, a look-alike of Cedar's sign-in.

3. Day 1, 09:14

   Riley enters a password and an authenticator-app code on that page. The relay passes both to Cedar's identity provider, which records a successful sign-in from 203.0.113.24 and issues session s-7a91. The relay keeps the session cookie.

4. Day 1, 09:20

   From 203.0.113.57, session s-7a91 registers a new authenticator app, passing a recent sign-in check that a minutes-old stolen session always passes.

5. Day 1, 09:31

   The same session approves Invoice Sync to read and send mail as Riley.

6. Day 1, 09:40

   A mail rule appears that forwards messages containing "invoice" to an outside address.

7. Day 1, 10:05

   A caller posing as an IT contractor asks Rowan, on the help desk, to reset MFA on an administrator's account. A callback to the administrator shows they made no such request, and Rowan refuses and records it.

8. Day 1, 11:30

   Invoice Sync reads an email from Cedar's payments vendor that contains an API key.

9. Day 2, 08:50

   The alert fires.

The timeline also shows what did not happen: no password change, no change to recovery settings, no new role. The 11:30 read leaves the identity system altogether, because a key for the payments vendor now has to be treated as exposed. Rotating credentials and keys after exposure follows that thread.

Telling the attacker from the owner

Every record in that timeline names the same actor: Riley's account. And while the attacker worked, Riley was working too, from the office, in a session that started at 08:41. The identity provider cannot tell people apart, only sessions, so Quinn separates them by the evidence around each event: the session ID, the network, the device and the time.

Riley's session, s-2b64, started at 08:41 from 198.51.100.24 on Riley's usual laptop and stayed there all day. Session s-7a91 started at 09:14 from the relay's address and was then used from 203.0.113.57, on a device that had never signed in to Cedar before. Every change that worried Quinn belongs to s-7a91. Some records are less clear. The mail service recorded the rule created at 09:40:17 with the account and the network, but no session, so Quinn attributes it by network and timing and notes in the incident record that the attribution is an inference.

The quickest way to resolve doubt is to ask the owner, through a channel the attacker cannot read. Quinn does not email Riley, because the attacker can read Riley's mail and a rule is already copying some of it elsewhere. Quinn avoids chat for the same reason: it is reached through the same account. Instead, Quinn calls Riley's desk phone, using the number in Cedar's directory, and then walks over to talk in person. Riley remembers the invoice email, a page that asked for a code, and then an ordinary page that never showed the invoice. Riley did not add an authenticator or approve any app.

Memories are imperfect, and people can feel embarrassed about having followed a link. Quinn asks what happened, not who was at fault. A relay page is built to be indistinguishable from the real one, as Phishing and relayed sign-ins explains. Riley's description of the morning confirms Quinn's hypothesis, and the records confirm Riley's description.

Following the trail to other accounts

An attacker who phished one person rarely stops at one. Quinn widens the investigation's scope along every thread the timeline offers:

• The invoice email: who else received it, and whether any other account signed in from the relay's address.
• The attacker's network: any other account with sign-ins or session use from 203.0.113.0/24.
• Invoice Sync: any other account that approved the same app, found by its client ID.
• The help-desk call: the administrator the caller named, checked for sign-ins, method changes and recovery attempts, and warned directly.
• The vendor key: what it allows, and whether the vendor's records show it being used from anywhere other than Cedar's own network addresses.
• The mail itself: which vendors and customers had messages forwarded out, and whether anything was sent in Riley's name.

Quinn finds the same email in four other finance mailboxes. None of those accounts shows a sign-in from 203.0.113.0/24, and nobody else approved Invoice Sync. The administrator's account shows no change since the refused call. That leaves Riley's account, the forwarded mail and the vendor key within scope. Quinn records this as the current scope rather than a final answer, because new evidence can still widen it.

You can work through Quinn's records yourself. Each step shows the kind of record an investigator reads, and asks the next question in turn.

When            Result     Methods                         Network        Session
Day 0 07:12:44  rejected   wrong password                  192.0.2.25     -
Day 1 08:41:07  succeeded  password + authenticator code   198.51.100.24  s-2b64
Day 1 09:14:06  succeeded  password + authenticator code   203.0.113.24   s-7a91

Time      Event                   Session  Network
09:05:12  mail.sent               s-2b64   198.51.100.24
09:14:06  sign_in.succeeded       s-7a91   203.0.113.24
09:17:40  calendar.event_created  s-2b64   198.51.100.24
09:20:41  authenticator.added     s-7a91   203.0.113.57   actor usr_4182, recent sign-in check passed
09:31:02  consent.granted         s-7a91   203.0.113.57   app Invoice Sync, read and send mail
09:40:17  mailbox.rule.created    -        203.0.113.57   no session recorded

Authenticator apps
  auth_08a   added at enrollment, 14 months ago   198.51.100.24
  auth_31c   added Day 1 09:20:41                 203.0.113.57
Apps with access
  Invoice Sync   read and send mail   approved Day 1 09:31:02   refresh token active
Mail rules
  Forward invoices   message contains "invoice"
                     forward to [email protected]   created Day 1 09:40:17

Ticket HD-2291          Day 1 10:05          Agent: Rowan
Caller said:   IT contractor on the mail migration
Cited:         change ticket CHG-20417
Request:       reset MFA for [email protected] (IT administrator)
Verification:  callback to the number in Cedar's directory
Result:        administrator had made no such request
Outcome:       refused, no change made

Day 1 11:30:18   message read
  Mailbox:   usr_4182 (Riley)
  Read by:   app Invoice Sync, on Riley's behalf, from 203.0.113.57
  From:      [email protected]
  Subject:   Your new API key

Before anything is cleaned up

Once the footholds are known, the urge is to remove them at once. Quinn first captures what cleanup would destroy. Revoking Invoice Sync's access can remove the record of which permissions it held. Deleting the mail rule removes its forwarding address. Removing the attacker's authenticator removes its registration details. Quinn exports the relevant sign-in records, audit entries, the mail rule, the app's details and the phishing email into the incident record, and asks for those records to be kept beyond their normal retention period so they cannot age out mid-investigation.

Preservation is no reason to leave an attacker working. When harm is ongoing, capturing the essentials takes minutes, not days, and containment follows straight after. At Cedar, mail was still being forwarded, so Quinn captured the records quickly and moved on to containment the same morning.

There is a second reason to wait until the list of footholds is complete. Removing them one at a time warns an attacker who still holds the others. Reset Riley's password alone, and the attacker's authenticator, the app's access and the mail rule all keep working, and the attacker, now alerted, may add another foothold before anyone notices. Containment works best as one planned action that removes everything together, which is where Containing and recovering begins.