What to preserve before you reset credentials after a breach

Before you reset anything, export five things for the affected account: the sign-in history, the audit log, the mailbox rules and forwarding settings, the list of applications the user has consented to, and the registered MFA methods and devices. Then take the containment steps. The export takes minutes; the reset is often what destroys the evidence, because some of these records are overwritten or lost when the account state changes. If the attacker is actively doing damage, contain first. Most of the time, you have the minutes.

Why the order matters

An investigation has to answer three questions: how did they get in, what did they do, and are they still here. The records that answer them are mostly attached to the account, and some of them are fragile. A password reset and a session revoke are the right containment moves (I've written about the order), but they also change the state you're trying to study. NIST's guidance on integrating forensics into incident response is built on a simple principle: collect in order of volatility, and document what you did and when, so that what you collected can be relied on later (Kent et al., 2006).

"Relied on later" is the part people skip. If this incident becomes a regulatory notification, an insurance claim, or litigation, someone will ask how you know what you know. A screenshot taken by a help-desk analyst at 11 p.m. with no note of what it is or when it was taken is better than nothing, but not by much.

The list, with the reason for each

Sign-in history. Where the logins came from, when, from what device, and whether MFA was satisfied. This is how you find the first bad login, which tells you how long the attacker has been in, and whether other accounts show the same source.

Audit log. What changed: rules created, permissions altered, files accessed or shared, mail sent. In Microsoft 365, Microsoft's own compromised-account guidance has you review the Entra sign-in and audit logs and the Defender audit log from before the suspicious activity began (Microsoft, 2026). Google Workspace has equivalent reports. Export them to a file you control.

Mailbox rules and forwarding. The commonest thing an attacker does with a mailbox is quietly forward it. Rules can be hidden from the user's view. Capture them before you delete them, because the rule's target address is evidence of where the data went.

Application consents. Attackers grant their own apps access to the account so they survive a password reset. The list of consented applications, with dates, shows you that persistence and sometimes identifies the toolkit used.

MFA registrations. An extra phone number or authenticator added last Tuesday is both a persistence mechanism and a timestamp.

To those five, add two if you can: a copy of the mailbox or drive contents as they stand (a legal hold or an export, not a manual look-through), and the endpoint, if the compromise may have involved the user's device. For the device, the forensic answer is an image of the disk and memory before anyone "cleans" it (Kent et al., 2006).

How to handle what you've collected

Write down what you exported, from where, at what time, and who did it. Put the files somewhere the attacker can't reach, which rules out the compromised user's own drive and, if the tenant admin is in question, possibly the tenant itself. Keep an original copy untouched and work from a second. None of this needs special tools. It needs discipline at the moment you least feel like being disciplined.

Legal guidance on breach response makes the same point from the other direction: early preservation is what limits scope later, because it lets you prove what wasn't accessed as well as what was (American Bar Association, n.d.).

The failure I'd plan against

The help desk resets the password at 9 a.m., deletes "the weird rule," and closes the ticket. At 4 p.m. security realises the same source IP hit six other accounts, and the one record that would have shown when it started is gone. The fix isn't a forensic team on the help desk. It's a five-line checklist and the authority to spend ten minutes on it before the reset.

What I'd do next

Write the five-item export into your account-compromise runbook with the exact console paths or commands for your platform, and have the help desk do it once on a test account. If you'd like me to review how your first-responder process would hold up in front of a regulator or an insurer, request a briefing. The rest of my writing on this is in Incident response.