AD1.9 Emergency Response: Compromised Account

Step 1: Revoke all sessions (minute 0-1)

Navigate to entra.microsoft.com → Users → search for the compromised user → click the user → select “Revoke sessions” (or use the Defender portal: Incidents → affected user entity → Manage user → Revoke sessions).

This terminates every active session for the user immediately. Access tokens become invalid. Refresh tokens are revoked. The attacker’s browser or application session ends. This is the single fastest containment action — it takes 10 seconds and stops the attacker’s current access.

If you prefer PowerShell, the command is:

1

Revoke-MgUserSignInSession -UserId "user@northgateeng.com"

Step 2: Reset the password (minute 1-2)

Navigate to the same user page in Entra → select “Reset password” → generate a temporary password or set one manually. Check “Require user to change password at next sign-in.”

This prevents the attacker from re-authenticating with the old password. Combined with the session revocation, the attacker is now fully locked out — they can’t use their existing session (revoked) and they can’t sign in again (password changed).

PowerShell:

1
2
3
4
5

$newPassword = @{
    Password = "TempP@ssw0rd$(Get-Random -Minimum 1000 -Maximum 9999)!"
    ForceChangePasswordNextSignIn = $true
}
Update-MgUser -UserId "user@northgateeng.com" -PasswordProfile $newPassword

Step 3: Check and clean MFA methods (minute 2-5)

Navigate to Users → compromised user → Authentication methods. Review every registered MFA method. If you see a phone number or Authenticator registration that the user doesn’t recognise — a phone number from a different country, a device name the user hasn’t used — the attacker registered their own MFA method for persistence. Delete the attacker’s method immediately.

This is critical because if you reset the password but leave the attacker’s MFA method registered, the attacker can reset the password themselves using SSPR with their registered method and regain access. Cleaning MFA methods closes this persistence vector.

Ask the user (after containment): “Do you recognise all the phone numbers and devices listed in your authentication methods?” If anything is unfamiliar, delete it.

Step 4: Check and clean inbox rules (minute 5-8)

Navigate to the Defender portal → Email & collaboration → Explorer (or use Exchange Online PowerShell). Check the compromised user’s inbox rules for any that forward, redirect, or delete email — especially rules that forward emails containing financial keywords to external addresses.

PowerShell is faster for this check:

1
2
3
4

Connect-ExchangeOnline
Get-InboxRule -Mailbox "user@northgateeng.com" | Where-Object {
    $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage
} | Format-List Name, ForwardTo, RedirectTo, DeleteMessage, Description

Delete any rules the user doesn’t recognise:

1

Remove-InboxRule -Mailbox "user@northgateeng.com" -Identity "RuleName"

Check for mailbox delegates — other users who have been granted access to read or send from the compromised mailbox:

1
2
3

Get-MailboxPermission "user@northgateeng.com" | Where-Object {
    $_.User -notlike "NT AUTHORITY*" -and $_.User -notlike "S-1-5*"
} | Select-Object User, AccessRights

If you see an unfamiliar user with FullAccess or SendAs permissions, the attacker granted themselves persistent mailbox access through delegation. Remove the permission:

1

Remove-MailboxPermission "user@northgateeng.com" -User "attacker@external.com" -AccessRights FullAccess -Confirm:$false

Also check for email forwarding at the mailbox level (different from inbox rules):

1

Get-Mailbox "user@northgateeng.com" | Select-Object ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

If ForwardingSmtpAddress or ForwardingAddress is set to an external address, the attacker configured mailbox-level forwarding. Remove it:

1

Set-Mailbox "user@northgateeng.com" -ForwardingSmtpAddress $null -ForwardingAddress $null

Step 5: Check OAuth app consents (minute 8-12)

Navigate to entra.microsoft.com → Applications → Enterprise applications → filter by the compromised user. Check if the user granted consent to any unfamiliar applications — especially apps with Mail.Read, Mail.ReadWrite, or Files.Read permissions. Malicious OAuth apps are a persistence mechanism: even after you reset the password and revoke sessions, an OAuth app with the right permissions can continue reading the user’s email indefinitely until the consent is revoked.

To revoke consent: click the suspicious application → Properties → “Delete” (this removes the service principal from your tenant, revoking all user consents for that app).

PowerShell:

1
2

Get-MgUserOauth2PermissionGrant -UserId "user@northgateeng.com" |
    Select-Object ClientId, Scope, ConsentType

Any permission grants with scopes like “Mail.Read,” “Mail.ReadWrite,” “Files.Read.All,” or “User.Read.All” to applications you don’t recognise should be revoked.

Step 6: Verify containment (minute 12-15)

Go back to the sign-in log. Filter by the compromised user and set the time range to “Last 1 hour.” After your containment actions, there should be no new successful sign-ins from the attacker’s IP. If you see a successful sign-in after the password reset and session revocation, the attacker has another access path — check for OAuth app persistence, delegated mailbox access, or a secondary compromised account.

Check the audit log filtered to the compromised user for the last hour. No new MFA registrations, no new inbox rules, no new app consents should appear. If they do, repeat the containment steps — the attacker may have re-compromised the account through a method you haven’t cleaned yet.

After containment: document and decide

Once the attacker is locked out, you have three tasks.

Document what happened. Record: the affected account, the attacker’s IP address(es) and location, the time window of the compromise (first attacker sign-in to containment), what the attacker accessed (emails read, files downloaded, inbox rules created), what containment actions you took, and the current status.

Post-containment investigation: the four questions

After containment, you need to answer four questions. Each has a specific log source and a specific command or portal path.

Question 1 — What did the attacker access? Check the unified audit log for mailbox activity. In PowerShell:

1
2
3
4
5

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -UserIds "user@northgateeng.com" -RecordType ExchangeItem `
    -Operations MailItemsAccessed,MessageBind | 
    Select-Object CreationDate, Operations, AuditData |
    Export-Csv "MailAccess_investigation.csv" -NoTypeInformation

The MailItemsAccessed operation shows every email the attacker opened. Export this — if the attacker read emails containing personal data, contracts, or financial information, this log determines your regulatory notification obligations.

Question 2 — Did the attacker send emails from the account? Check for sent messages:

1
2
3

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -UserIds "user@northgateeng.com" -RecordType ExchangeItem `
    -Operations Send | Select-Object CreationDate, AuditData

If the attacker sent emails, you need to identify the recipients and content. BEC attacks send fraudulent invoice or payment modification emails from the compromised account — the recipients trust the email because it comes from a known internal sender.

Question 3 — Did the attacker access files? Check SharePoint and OneDrive activity:

1
2
3
4

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -UserIds "user@northgateeng.com" -RecordType SharePointFileOperation `
    -Operations FileDownloaded,FileAccessed |
    Select-Object CreationDate, Operations, AuditData

Large-volume file downloads indicate data exfiltration. If the attacker downloaded files containing intellectual property, customer data, or personnel records, this changes the incident severity and may trigger breach notification requirements.

Question 4 — Did the attacker move laterally? Check whether the compromised account was used to access other accounts or resources:

1
2
3
4

# Check if the attacker's IP accessed other accounts
Get-MgAuditLogSignIn -Filter "ipAddress eq '198.51.100.22'" -Top 100 |
    Select-Object UserPrincipalName, CreatedDateTime, Status |
    Group-Object UserPrincipalName

If the attacker’s IP shows sign-ins to multiple accounts, the compromise is broader than one user. Each additional compromised account needs the same containment procedure. This is the point where you escalate to your managed SOC partner or an incident response firm — multi-account compromise requires a coordinated response. Use a simple format that captures the timeline. Open a text file or OneNote page and write entries as you work — timestamp each action. For example: “09:02 — Revoked sessions for j.morrison@northgateeng.com. 09:03 — Reset password, temporary password set, force change on next sign-in enabled. 09:06 — Checked authentication methods, found unfamiliar phone number +44 7700 900XXX registered at 14:35 on Friday, deleted. 09:08 — Found inbox rule forwarding invoices to external address, deleted rule.” This timestamped log becomes the official incident record. If the incident triggers regulatory notification (GDPR 72-hour clock), insurance claim, or legal action, your timestamped containment log is the evidence that you responded promptly and effectively.

Notify stakeholders if needed. If the compromised account accessed sensitive data (financial, personal, intellectual property), notify your manager and legal. If the attacker sent emails from the account (BEC), notify the recipients — by phone, not email — that the messages were fraudulent. If financial transactions were redirected, contact the bank immediately.

Decide whether to escalate. If the compromise is limited to one account and you’ve contained it, you can manage the investigation yourself. If the attacker accessed multiple accounts, moved laterally, or was in the environment for more than 72 hours, consider engaging your managed SOC partner or an incident response firm. The longer the attacker had access, the more thorough the investigation needs to be.