How to Respond to a Phishing Attack: The Step-by-Step IR Checklist
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Phishing is the starting point of the majority of data breaches: but the phishing email itself is not the breach. The breach happens in the minutes and hours after the click, when an attacker uses the stolen credential or malware foothold to establish access that survives beyond the initial compromise.
A fast, structured response interrupted most phishing-to-breach chains. This checklist is organized by time from initial report: the first 15 minutes require different actions than hour two.
Phase 1: Triage (Minutes 0-15)
The immediate question: what did the phishing email actually deliver?
Phishing attacks deliver one of three payloads, and each requires a different response:
- Credential harvesting page: The victim entered their username and password. The attacker now has the credential. Contain immediately: do not wait for 'confirmation.'
- Malware or ransomware: The victim opened an attachment or download that executed malware. The endpoint needs isolation.
- OAuth consent grant: The victim clicked 'Allow' on a malicious OAuth application. The attacker has an OAuth token that persists even after a password reset.
Gather immediately (ask the reporting user):
- What link did you click, or what attachment did you open?
- Did you enter your username and password anywhere?
- Did you see a Windows popup or browser prompt asking for permissions?
- What happened after: error page, fake success, nothing?
- Did you forward the email to anyone?
Retrieve the original email (do not ask the user to forward it: email clients sometimes strip headers):
# Microsoft 365: retrieve email headers from Exchange Online
Get-MessageTrace -RecipientAddress user@company.com -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) | Get-MessageTraceDetail
Check for active sign-ins in the last hour:
# Requires Microsoft Graph / Entra ID
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@company.com' and createdDateTime gt $(Get-Date -Format yyyy-MM-ddTHH:mm:ssZ -Date (Get-Date).AddHours(-2))" | Select-Object CreatedDateTime, IpAddress, Location, ClientAppUsed, Status
Look for sign-ins from unexpected geographies, unusual client applications, or at unusual hours immediately after the reported phishing time.
Phase 2: Contain (Minutes 15-30)
If credential compromise is suspected (entered username/password):
# 1. Force a password reset
Set-MgUserPassword -UserId user@company.com -PasswordProfile @{Password="TempP@ss12345!"; ForceChangePasswordNextSignIn=$true}
# 2. Revoke all active sessions (this invalidates all tokens)
Revoke-MgUserSignInSession -UserId user@company.com
# 3. Disable the account temporarily while you investigate
Update-MgUser -UserId user@company.com -AccountEnabled $false
Password reset alone is NOT sufficient: an attacker who has established OAuth app access or registered an additional MFA device retains access after a password reset. Revoke sessions explicitly.
If malware is suspected (attachment opened, download executed):
# Isolate the endpoint via Microsoft Defender for Endpoint
# (requires MDE P1/P2 or Defender for Business)
Invoke-MgSecurityRunHuntingQuery -Query "DeviceNetworkEvents | where DeviceName == 'WORKSTATION01' | take 100"
# Or use the MDE portal: Security.microsoft.com > Devices > select device > Actions > Isolate device
For environments without MDE, isolate by disabling the network adapter: in the MDE portal, or physically unplug the network cable / disable WiFi. Do not shut down: volatile memory may contain attacker artifacts.
If OAuth grant is suspected (consent dialog appeared):
# Review OAuth app grants for the user
Get-MgUserOauth2PermissionGrant -UserId user@company.com | Select-Object ClientId, Scope, ConsentType
# Revoke a specific grant
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId <grantId>
OAuth grants survive password resets and session revocations: they must be revoked explicitly.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Phase 3: Investigate Attacker Persistence (Hour 1-2)
Even if you contained the initial access quickly, an attacker who had even 5-10 minutes of access may have established persistence. Check all three common persistence mechanisms:
1. Email forwarding rules:
# Check inbox rules for the compromised account
Get-InboxRule -Mailbox user@company.com | Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo } | Select-Object Name, ForwardTo, RedirectTo, Enabled
Any forwarding rule created after the phishing timestamp is suspicious. Delete immediately and document the destination address.
2. MFA device registration:
# Check registered authentication methods
Get-MgUserAuthenticationMethod -UserId user@company.com | Select-Object ODataType, Id
If an authenticator app or phone number was added after the phishing timestamp, the attacker registered their own MFA device: they can re-authenticate after your password reset. Remove the suspicious MFA device and require the user to re-register from a trusted device.
3. OAuth application grants (re-check comprehensively):
# Check all OAuth grants, not just new ones
Get-MgUserOauth2PermissionGrant -UserId user@company.com | ForEach-Object {
$app = Get-MgServicePrincipal -ServicePrincipalId $_.ClientId
[PSCustomObject]@{
AppName = $app.DisplayName
Scope = $_.Scope
ConsentType = $_.ConsentType
}
}
Look for apps with access to Mail.ReadWrite, Contacts.Read, Files.ReadWrite.All, or any sensitive permission scope that was not present before the phishing incident.
4. Admin role changes:
# Check for new role assignments in the last 24 hours
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime gt $(Get-Date -Format yyyy-MM-ddTHH:mm:ssZ -Date (Get-Date).AddHours(-24)) and activityDisplayName eq 'Add member to role'" | Select-Object ActivityDateTime, InitiatedBy, TargetResources
Phase 4: Scope Assessment (Hour 2-4)
After containment, assess the blast radius: what did the attacker access during the window they had access?
Mail access audit:
# Check what emails were read, downloaded, or forwarded in the compromise window
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -UserIds user@company.com -Operations MailItemsAccessed | Select-Object -ExpandProperty AuditData | ConvertFrom-Json | Select-Object OperationProperties, ClientInfoString
File access audit (SharePoint/OneDrive):
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -UserIds user@company.com -Operations FileAccessed,FileDownloaded,FileSyncDownloadedFull | Select-Object CreationDate, Operations, AuditData
Teams and calendar access:
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -UserIds user@company.com -Operations TeamsSessionStarted,CalendarItemCreated | Select-Object CreationDate, Operations
If sensitive data was accessed: assess data classification of accessed files, determine whether the data includes PII, financial records, or intellectual property, and consult legal and compliance about notification obligations (GDPR 72-hour notification, state breach notification laws).
Phase 5: Eradicate, Recover, and Document
Eradicate:
- Delete all forwarding rules found in Phase 3
- Remove all unauthorized OAuth grants
- Remove unauthorized MFA devices
- Re-enable the user account and require MFA re-registration from a known good device
- For malware: re-image the affected endpoint rather than attempting cleanup; malware may have rootkit components that survive antivirus scans
- Search the tenant for other users who received the same phishing email:
New-ComplianceSearch -Name "PhishingSearch" -ExchangeLocation All -ContentMatchQuery "subject:'[SUBJECT]' AND received:$(Get-Date -Format MM/dd/yyyy)"and remediate the email from all inboxes
Re-enable the user:
Update-MgUser -UserId user@company.com -AccountEnabled $true
Re-register MFA on a call with the user: do not allow self-service MFA registration immediately after a compromise without IT verification.
Document for the post-incident review:
- Timeline of events (phishing email receipt time, click time, report time, containment time)
- What the attacker accessed during the window
- What persistence mechanisms were established
- What actions were taken and in what order
- Whether any notification obligations were triggered
- What controls, if present, would have detected or prevented the attack earlier
Post-incident hardening actions: Evaluate whether Conditional Access policies would have blocked the initial unauthorized sign-in (geography restriction, device compliance requirement), whether phishing-resistant MFA (hardware key or Microsoft Authenticator with number matching) would have prevented credential use, and whether the compromised user had more permissions than needed.
The bottom line
Phishing response has five phases: triage to understand what the phishing delivered (credential vs malware vs OAuth), containment with password reset + session revocation + account disable, investigation of three attacker persistence mechanisms (forwarding rules, MFA device registration, OAuth grants), scope assessment of what was accessed, and eradication plus documented recovery. The critical insight: password reset alone is insufficient: attackers establish persistence in the first minutes that survives credential changes and must be explicitly removed.
Frequently asked questions
What should I do immediately after someone clicks a phishing link?
Within 15 minutes: ask the user what they entered (credentials? consent dialog?), retrieve the original email headers, and check Microsoft 365 sign-in logs for the user. If credentials were entered: force a password reset, revoke all active sessions with Revoke-MgUserSignInSession, and temporarily disable the account. Then check for forwarding rules, new MFA device registrations, and OAuth grants before re-enabling access.
Does changing a compromised user's password stop a phishing attacker?
Not by itself. A password reset invalidates existing passwords but does not terminate active sessions or revoke OAuth tokens. You must also run Revoke-MgUserSignInSession to invalidate all active tokens, and check for forwarding rules, unauthorized MFA device registrations, and OAuth app grants that the attacker established during their access window: all of which survive a password reset.
How do I find OAuth apps that a phishing attacker authorized in Microsoft 365?
In the Entra ID admin center, navigate to Enterprise applications > All applications and filter by 'User assigned' to find third-party OAuth apps with access to your tenant. In the Microsoft 365 Defender portal, run an advanced hunting query against the CloudAppEvents table filtering on ActionType = 'OAuthAppConsentApproved' for the compromised account in your investigation window. To bulk-audit all OAuth app grants, use: Get-MgUserOAuth2PermissionGrant -UserId <upn> | Format-List. Revoke suspicious grants immediately and check if other users in the same org clicked the same phishing link.
What is a phishing-resistant MFA method and which ones qualify?
Phishing-resistant MFA is authentication that cannot be intercepted by an adversary-in-the-middle (AiTM) proxy even when a user enters their credentials on a spoofed login page. Qualifying methods: FIDO2 hardware security keys (YubiKey, etc.) and Windows Hello for Business. These methods bind the authentication to the specific legitimate domain, so an AiTM site receives no usable credential. Non-phishing-resistant methods (TOTP apps, SMS codes, push notifications) can all be intercepted by AiTM proxies, which is the technique behind most modern large-scale phishing campaigns.
How do I set up email alerts for suspicious sign-in activity after a phishing incident?
In Microsoft Entra ID: enable sign-in risk policies in Identity Protection (requires P2 license) to automatically block or MFA-challenge risky sign-ins. Configure alerts for Entra Identity Protection in the Alerts tab: set notification emails for high-risk users and high-risk sign-ins. In Microsoft 365 Defender, create custom alert policies under Policies and rules > Alert policy for events like 'Suspicious email forwarding activity' and 'Mail redirect from user'. For immediate incident notification, also configure a Conditional Access policy to require MFA step-up for sign-ins from unfamiliar locations and new devices for the compromised user for 30 days post-incident.
How do you determine the initial access vector in a phishing incident and what evidence differentiates credential theft from malware delivery?
Initial access vector determination requires correlating the phishing email with authentication logs and endpoint events. For credential theft (most common via AiTM phishing): check for an interactive sign-in event in Entra ID sign-in logs from an IP address not matching the victim's normal workstation or VPN. The authenticating IP will typically be a hosting provider or residential proxy. The sign-in timestamp will be within minutes of the victim clicking the phishing link. If Entra ID Identity Protection was enabled, there may be an 'Anonymous IP address' or 'Unfamiliar sign-in properties' risk event. For malware delivery: check Defender for Endpoint process creation events around the phishing link click time (correlate browser process start time with the link click from email logs). Look for: Office application spawning cmd.exe or PowerShell (macro execution), browser spawning unexpected child processes, wscript.exe or mshta.exe execution (script-based payloads). The key differentiator: credential theft leaves no endpoint process execution trail beyond the browser; malware delivery creates process tree events from Office or the browser. Both may coexist: AiTM kits can deliver both stolen tokens and deploy a secondary payload.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.