Practical Protection: Investigating After an Attack 

I got a great reader question, which I will paraphrase to avoid giving away any details about the reader who wrote in: 

I’m a 1-man IT shop and I’m trying to assess the potential damage from a client’s user falling for a phishing email.  I reset their passwords and took other basic post-attack steps, but now I want to try to see if I can tell what damage they did or can do, i.e. what info they might have accessed. It’s been almost a week now and all we’ve found is 1 email the scammers sent out.  Seems weird that’s the extent of the damage—the client’s bank accounts haven’t been touched. 

Thanks, anonymous reader, for that excellent question. Let’s dig into some answers. 

What Should You Do First? 

I think you did the right thing by immediately moving to stop the attacker’s access. Immediately resetting passwords on all accounts will help, thanks to continuous access evaluation (CAE). CAE, an Entra ID feature, triggers immediate reauthentication in compatible applications when Entra ID reports security events such as password changes. Changing the passwords in this way kicks out legitimate users, but also forces attackers to reauthenticate, which hopefully the password change will prevent. 

In some circumstances, it might make sense to conduct a more detailed forensic analysis before moving to kick the attacker out—it’s common for larger enterprises that detect a persistent attack to investigate further (and to take steps to isolate the attack by preventing lateral movement, etc) before trying to remove the attacker, but as a small “army of one” the right move is probably to cut off access ASAP. 

What Indicators of Compromise to Look For 

For a phishing-initiated attack like this, there are several things you will want to look for: 

• Any indication in the sign-in logs of other potentially compromised accounts. Since you know that one account was compromised, you can look at its sign-in activity and then search for similar activity (e.g. sign-in from unfamiliar places, odd application IDs, and so on). 
• Unusual application activity. One of the most common things to look for is changes to mail forwarding rules, as attackers will often install these rules to redirect receipts or other evidence. 
• Failed access attempts—an attacker who’s trying to look for things will often stumble around trying to load SharePoint sites, shared mailboxes, and so on, that their stolen account doesn’t have access to. You should look for these unusual patterns of access in the unified audit log. 

Of course, you should also closely examine the compromised account’s resources, especially any Windows or macOS devices associated with the account. Thorough scanning for malware on all devices and a close inspection of downloads, sent mail items, and so on, will often reveal useful indicators of what an attacker might have sought, or found, in your tenant.   

How to Do Post-Attack Follow-up 

It’s a good sign that your client’s bank accounts don’t appear to have been touched. Many financial institutions do out-of-band notifications of security-sensitive events; for example, Fidelity will send paper mail to you to notify you when an account password has changed. That’s the good news; the bad news is that these notifications can often take 10-14 days to reach you, leaving an attacker a big window of opportunity before the notification hits. Most of us will have one or more critical systems or resources that aren’t directly integrated with, or reachable from, Microsoft 365. Bank accounts are a great example. For these items, there are a few avenues of follow-up that you should include in your playbook. 

First, I mentioned malware scans earlier because one common attack pattern is that the attacker will compromise a device, plant credential-stealing malware on it, wait for the victim to access their online bank account or whatever, and then use the stolen credentials. A fast-moving attacker can often pull this off in minutes. If you don’t see any evidence on the accounts that this was done, don’t assume that it couldn’t still be done. If you see any evidence that the device itself was compromised, that’s a big red flag that should spur you to move faster. 

Second, you should use offline verification to check these accounts. This can be a big hassle—as an IT consultant, you normally won’t just be able to call your client’s bank and ask to inspect their records, so you’ll need the client’s time and assistance. But it’s important to do this because the client’s bank, brokerage house, insurance company, etc. is the only true source for you to check for password or address changes or other unusual transactions. Time-consuming though it is, these checks need to be made. 

Finally, if you’re lucky the phishing attack only hit one (or a few) target accounts. Think about why that happened—was the user poorly trained? Were they tricked by a particularly good phish? Was social engineering part of the attack? What can you do to help harden the target users (and their organization) against the next attack? 

 Do a Good Postmortem 

Of all people, it might seem odd that I’d be the one to quote Google, but their explanation of the “blameless postmortem” is really useful: 

The primary goals of writing a postmortem are to ensure that the incident is documented, that all contributing root cause(s) are well understood, and, especially, that effective preventive actions are put in place to reduce the likelihood and/or impact of recurrence… For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior.  

Google

The last, and critically important, step in this process is to document what you found. What do you know about how the attacker got in? How did you establish what the attacker did during the attack? Did you find evidence, or not, of specific actions like stealing money, lateral movement, and so on? What did you learn during the investigation? What will your organization do differently as a result of your findings? It’s tempting to just say “STUPID USER, DON’T GET PHISHED” but that isn’t helpful because it doesn’t add to anyone’s understanding, and it definitely doesn’t help lower your risk of future attacks. 

Good luck, 1-man reader! I wish you a speedy and complete resolution to this incident. For the rest of you who didn’t send me questions, well, my inbox is always open; just don’t phish me.