Ctrl+Alt+Route

Phishing emails are one of the most common security incidents IT teams deal with. Some are obvious spam, while others are designed to steal Microsoft 365 credentials, deliver malware, or compromise an account.

The important part is having a consistent process for investigating the message, determining whether anyone interacted with it, and making sure the threat has been fully removed.

This guide covers the process I use when investigating phishing emails in a Microsoft 365 environment using Microsoft Defender, Microsoft Entra ID, VirusTotal, and MXToolbox.

Important: Never open suspicious attachments or execute files from a suspected phishing email on your normal workstation or a production device. Suspicious files should only be handled in an isolated sandbox environment.

1. Gather Information

Start with the email that was reported.

If the original message was attached to a ticket or forwarded to IT, collect:

• Sender name
• Sender email address
• Subject
• Date and time received
• Recipient

You’ll use this information later when searching Defender or running a message trace.

Next, talk to the user and find out what they did with the email.

Ask whether they:

• Clicked any links
• Opened or downloaded an attachment
• Entered credentials
• Approved an MFA request
• Replied to the email
• Provided any information to the sender
• Took any other action related to the message

This is usually what determines how far the investigation needs to go.

If the user reported the email without interacting with it, the response may be fairly simple.

If they entered credentials, approved an MFA request, or ran something from the email, you now have a potential account or device compromise to investigate.

2. Locate and Validate the Email

The next step is figuring out whether the message is actually malicious.

Microsoft Defender

In a Microsoft 365 environment, Defender should usually be your starting point.

Go to:

Microsoft Defender > Email & Collaboration > Explorer

Search for the message using:

• Sender address
• Sender domain
• Subject
• Recipient

A message trace can also be useful, especially if you just need to confirm whether something was delivered. For the actual security investigation, Defender Explorer gives you more useful information.

VirusTotal

VirusTotal is useful for checking:

• URLs
• Domains
• IP addresses
• File hashes
• Suspicious files

Be careful with file uploads.

Don’t upload confidential company documents or anything containing sensitive information to a public analysis service. If possible, use the file hash instead.

The same goes for suspicious URLs and domains. You can often get what you need without directly visiting them.

MXToolbox

MXToolbox can help when you want to look further into the sending domain or mail infrastructure.

Some of the things worth checking include:

• DNS records
• MX records
• SPF records
• Mail servers
• Domain configuration
• Email headers

This can be useful when you’re trying to determine whether the sending infrastructure makes sense for the organization the email claims to be from.

Review the Message

Once you’ve found the email in Defender, start going through the details.

Check:

• Sender address
• Sender domain
• Display-name impersonation
• Domain impersonation
• SPF
• DKIM
• DMARC
• Email headers
• URLs
• Attachments
• Defender detections

Don’t rely on one indicator to make the call.

An SPF failure, for example, can look suspicious, but forwarding and unusual mail-routing configurations can also cause legitimate emails to fail authentication.

Look at everything together.

Check the Reply-To Address

Always check the Reply-To address.

An attacker may make an email appear to come from a legitimate sender while directing replies somewhere completely different.

For example:

From:accounting@legitimatecompany.com
Reply-To:accounting.company@gmail.com

That doesn’t automatically mean the message is malicious, but it gives you another reason to dig deeper.

If something doesn’t look right, review the message headers and confirm where the email actually came from.

3. Determine the Scope

Once you’ve confirmed the email is malicious, find out how far it spread.

Search Defender using:

• Sender email address
• Sender domain
• Subject

These are usually the best values for finding related messages.

You can also search using URLs or attachment hashes, but attackers may change those between messages.

At this point, you want to know:

• How many users received the email
• Whether the messages were delivered
• Whether Defender quarantined any copies
• Whether anyone interacted with them

A report from one person may be the only copy of the email, or it may be the first sign of a much larger phishing campaign.

If several users received the same message, use Defender to investigate and remediate them together rather than going mailbox by mailbox.

4. Determine Whether Anyone Interacted With It

The next question is whether anyone actually did anything with the email.

Users don’t always remember exactly what they clicked, especially if the message initially looked legitimate.

Use Defender to check for:

• URL clicks
• Attachment activity
• Security detections
• Message activity

Compare any recorded URL clicks against the URLs in the original email.

If the user clicked something, investigate the destination.

VirusTotal can help identify whether the URL or domain has been reported as malicious, but remember that phishing links often redirect through several services before reaching the final site.

Review Entra ID Sign-In Activity

If the user clicked a phishing link, entered credentials, or approved an unexpected MFA request, check their Entra ID sign-in logs.

Focus on activity around the same time as the phishing incident.

Look for:

• Sign-ins from unfamiliar locations
• IP addresses you don’t recognize
• New or unusual devices
• Unexpected applications
• Multiple failed authentication attempts
• Successful logins after a series of failures
• Unexpected MFA activity
• Changes to authentication methods

Don’t treat the location by itself as proof that someone compromised the account.

VPNs, cellular networks, proxies, and cloud services can make sign-in locations look strange.

You need to compare the sign-in activity with what the user told you happened.

If someone says they entered their password into a phishing site at 10:15 AM and you see a sign-in from an unfamiliar device shortly afterward, that’s much more useful than location information on its own.

If credentials were entered or a suspicious MFA request was approved, start treating the account as potentially compromised.

5. Investigate the Device

If the user opened an attachment, downloaded and executed a file, enabled macros, ran a script, or installed something from the email, the workstation also needs to be investigated.

Use Microsoft Defender for Endpoint and review:

• Defender alerts
• Process activity
• Parent and child processes
• File activity
• Network activity
• Security detections
• Other indicators of compromise

Depending on what happened, you may need to:

• Run a Defender Antivirus scan
• Run a full scan
• Run Microsoft Defender Offline
• Isolate the workstation from the network
• Block malicious file hashes
• Block malicious domains or URLs
• Block malicious IP addresses where appropriate
• Escalate the incident

If the user executed malicious code, removing the original phishing email isn’t enough anymore.

The email was just how the attacker got in.

6. Remediate the Email

If the email is malicious but nobody entered credentials, executed a malicious file, or had their account compromised, remediation is fairly straightforward.

In Defender Explorer:

1. Locate and select the malicious message.
2. Select “Take Action”.
3. Submit the message to Microsoft if appropriate.
4. Confirm that the message is a threat.
5. Classify it as spam, phishing, or malware.
6. Remove or quarantine the message.
7. Block the sender or other indicators where appropriate.

If the same email went to several users, remediate the messages in bulk.

Be Careful With Domain Blocks

Blocking one malicious sender is usually easy.

Blocking an entire domain is a different story.

If a legitimate vendor has one compromised mailbox and you block their entire domain, you may also block legitimate communication with everyone else at that company.

Before blocking a domain, figure out whether:

• The domain itself is malicious
• The domain was created specifically for phishing
• One account at a legitimate company was compromised
• A domain-wide block would affect normal business communication

If it’s a company you regularly work with, blocking the specific sender may make more sense than blocking the entire domain.

7. Remediate a Compromised Account

If the user entered credentials, approved a malicious MFA request, or you find evidence that somebody accessed the account, start remediation immediately.

The exact response will depend on what you find, but the usual process includes:

1. Reset the user’s password.
2. Revoke active sessions and authentication tokens.
3. Review registered MFA methods.
4. Remove any unauthorized authentication methods.
5. Review application consent and enterprise application permissions.
6. Check mailbox forwarding settings.
7. Review inbox and mailbox rules.
8. Review recent Entra ID sign-ins.
9. Determine whether company data was accessed.
10. Determine whether files or email were downloaded or exfiltrated.
11. Check whether the account sent phishing emails.
12. Investigate devices associated with suspicious sign-ins.
13. Confirm the account is secure before returning normal access.

Check Mailbox Rules and Forwarding

Mailbox rules are easy to overlook.

Attackers sometimes create rules that:

• Delete security notifications
• Hide replies
• Move messages into other folders
• Forward email outside the organization

Those rules can still be there after you change the user’s password.

Always check.

Check Application Consent

Also review application consent.

Not every phishing attack is trying to steal a password.

Some try to get the user to authorize a malicious application with access to Microsoft 365 data.

Look for applications that were recently approved or that the user doesn’t recognize.

If an attacker has OAuth permissions, resetting the user’s password may not remove their access.

Check for Outbound Phishing

If the account was compromised, check whether the attacker used it to send additional phishing emails.

Review outbound email during the suspected compromise period and look for messages sent to:

• Internal users
• External contacts

This is especially important with compromised employee accounts because recipients are much more likely to trust an email coming from someone they know.

If you find evidence of a larger compromise or possible data breach, escalate it through your normal incident response process.

8. Recover and Close the Incident

What you need to do before closing the incident depends on what happened.

For a simple phishing email where nobody interacted with it, recovery may only involve removing the message, blocking the appropriate indicators, and letting the user know it’s been dealt with.

For a confirmed compromise, make sure:

• All malicious emails have been removed
• All recipients have been identified
• Compromised accounts have been secured
• Potentially affected devices have been investigated
• Malicious indicators have been blocked where appropriate
• Suspicious sign-ins have been investigated
• Unauthorized mailbox rules have been removed
• Unauthorized forwarding has been removed
• Unauthorized MFA methods have been removed
• Unauthorized application consent has been revoked
• Malicious outbound messages have been identified
• You understand how the attacker gained access where possible

If the incident exposed a weakness in your existing controls, this is also a good time to review them.

That could include:

• Defender policies
• Exchange Online Protection
• Safe Links
• Safe Attachments
• Anti-phishing policies
• Impersonation protection
• Conditional Access
• MFA configuration
• Authentication methods
• Security awareness training

Document the Investigation

Not every phishing email needs a formal incident report.

If someone reports an obvious phishing email, they didn’t interact with it, and there’s no evidence of compromise, documenting what you found in the support ticket may be enough.

For a confirmed compromise or larger phishing campaign, record:

• Reporting user
• Sender
• Sender domain
• Subject
• Date and time
• Number of recipients
• Affected users
• Users who interacted with the message
• What actions they took
• Messages removed
• Accounts remediated
• Devices investigated
• Indicators identified
• Indicators blocked
• Security actions performed
• Evidence of unauthorized access
• Final determination
• Any recommended security changes

You don’t need a twenty-page incident report for every phishing email, but you should have enough information that another technician can understand what happened and what was done about it.

Don’t Punish Users for Reporting Phishing

This is one of the most important parts of phishing response.

If someone clicks a phishing link and then tells IT about it, that’s still a good outcome.

You need to know what happened as quickly as possible.

If users think they’re going to get in trouble for admitting they clicked something, they’re more likely to stay quiet and hope nothing happens.

That’s when a small incident can become a much bigger problem.

Find out what happened, fix it, and explain what they can look for next time.

A user reporting a mistake five minutes after it happens is much better than discovering the compromise yourself five days later.

Conclusion

At the end of a phishing investigation, you should be able to answer four questions:

1. Was the email malicious?
2. Who received it?
3. Did anyone interact with it?
4. Was anything compromised?

From there, you know what needs to be contained, remediated, and documented.

Microsoft Defender and Entra ID give you most of what you need to investigate phishing in a Microsoft 365 environment.

The main thing is having a process and following it consistently.

The tools will change over time. The basic investigation doesn’t: figure out what was sent, who received it, what they did with it, and what happened afterward.