Compromised Account

Know what your tenant can do

Start with Microsoft 365 Business Standard. Use the fallback in this SOP when a premium signal or response tool is not licensed, and activate only the least role needed for the action.

Least-privilege action map

Activate roles just in time where possible. For delegated Microsoft Graph work, the operator needs both the listed OAuth scope and the supported Entra role. Exchange roles can be customized, so verify the exact cmdlet and parameter assignment in the tenant.

Exchange verification: run Get-ManagementRole -Cmdlet <Cmdlet> -CmdletParameters <Parameter>, then inspect Get-ManagementRoleAssignment. This is more reliable than assuming a broad administrator role in a customized tenant.

Know when to start the SOP

Start this procedure when one credible signal suggests that another person or application may control the identity. One signal is enough to investigate. Related credible signals increase urgency; record suspected compromise until evidence supports a confirmed classification.

What to do

• Record the trigger exactlySave who reported it, when, the alert or incident ID, affected UPN and the original message or detection.
• Ask one clear questionFor example: "Did you sign in from this location at this UTC time or approve this application?"
• Check the risky-user recordCompare the detection time, risk level and risk detail with the report.

Set priority and initial scope

Triage answers three questions: Is the attack still active? How sensitive is the identity? Is the problem limited to one account?

What to do

• Profile the identityRecord directory roles, business role, group membership, licenses, managed devices, mailbox and access to sensitive applications.
• Define the first time windowStart before the earliest suspicious event and continue through the current time. Record all times in UTC.
• Look for active harmCheck continuing sign-ins, malicious email, rule changes, external forwarding, consent grants and large file access.
• Check related identitiesSearch the same IP, application, message, URL or device across other users when your tools and licenses support it.
• Assign severity and ownerBase severity on privilege, ongoing access, financial risk, data exposure, number of identities and operational impact.

Stop access and further damage

Containment interrupts new access. It does not prove that every token, application session, device or persistence mechanism is gone.

What to do

• Disable the accountDisable it in the authoritative source. For synchronized identities, follow the tenant's hybrid identity process.
• Revoke sign-in sessionsInvalidate refresh tokens from the user's Overview page or with Microsoft Graph PowerShell.
• Confirm the compromise in Identity ProtectionUse Confirm compromised for a true positive. Do not use Dismiss risk to hide a genuine compromise.
• Contain the device when indicatedEscalate to the endpoint owner when malware, token theft or an untrusted device is involved.
• Stop application accessDisable a confirmed malicious enterprise application or service principal when it can continue independently of the user session.

# Cloud member users only. Run after incident authorization and evidence capture.
$ErrorActionPreference = 'Stop'
Import-Module Microsoft.Graph.Users
Import-Module Microsoft.Graph.Users.Actions
$tenantId = [guid](Read-Host 'Tenant ID (GUID)')
if ($tenantId -eq [guid]::Empty) { throw 'A tenant ID is required.' }
$targetUpn = (Read-Host 'Exact user principal name to disable').Trim()
if (-not $targetUpn) { throw 'A target user is required.' }
$connected = $false
try {
  Connect-MgGraph -TenantId $tenantId -ContextScope Process -Scopes 'User.EnableDisableAccount.All','User.Read.All','User.RevokeSessions.All'
  $connected = $true
  if ([guid](Get-MgContext).TenantId -ne $tenantId) { throw 'Wrong tenant context.' }
  $target = Get-MgUser -UserId $targetUpn -Property Id,UserPrincipalName,UserType,OnPremisesSyncEnabled,AccountEnabled
  if (-not $target.Id -or $target.UserPrincipalName -ne $targetUpn -or $target.UserType -ne 'Member' -or $target.OnPremisesSyncEnabled) {
    throw 'Stop: target mismatch, guest or synchronized account. Use the appropriate workflow.'
  }
  $target | Select-Object Id,UserPrincipalName,AccountEnabled
  if ((Read-Host 'Confirm authorized action by typing the exact UPN again') -cne $target.UserPrincipalName) {
    throw 'Confirmation did not match.'
  }
  Update-MgUser -UserId $target.Id -AccountEnabled:$false
  $state = Get-MgUser -UserId $target.Id -Property AccountEnabled
  if ($state.AccountEnabled -ne $false) { throw 'Disable was not verified. Escalate before continuing.' }
  $revoked = Revoke-MgUserSignInSession -UserId $target.Id
  if ($revoked -ne $true) { throw 'Account disabled, but session revocation was not confirmed. Keep it blocked and verify in the portal.' }
} finally {
  if ($connected) { Disconnect-MgGraph }
}
# Record UTC time and action results in the incident. Existing app sessions may remain.

Build the timeline and blast radius

Work from the identity outward. First decide what the suspicious sign-in means, then investigate persistence, email, applications, devices and data.

What to do

• Complete the suspicious sign-in SOPRecord its Safe, Troubleshooting, Suspicious, Broader attack or Unresolved decision. Attach original interactive and non-interactive exports, or document the exact coverage gap.
• Inspect mailbox persistencePreserve hidden Inbox rules, mailbox forwarding, delegates, automatic replies and suspicious settings.
• Inspect application consentReview user and tenant application grants. Password reset and MFA cleanup do not remove OAuth permissions.
• Trace sent and accessed mailUse message trace, Sent Items, Threat Explorer when licensed and MailItemsAccessed audit events when entitled.
• Review data, roles, devices and automationCheck relevant SharePoint, OneDrive, role, device and Power Automate audit activity for downloads, sharing or malicious changes.
• Search for related activityLook for the same IP, application, device, consent grant, recipient or attacker pattern across other identities.

Get-InboxRule -Mailbox <UPN> -IncludeHidden |
  Format-List Name,Enabled,Description,RedirectTo,ForwardTo,ForwardAsAttachmentTo,DeleteMessage,MoveToFolder,Identity

Get-Mailbox -Identity <UPN> |
  Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-MailboxPermission <UPN> |
  Where-Object {$_.AccessRights -like "Full*"} |
  Format-Table User,Deny,IsInherited,AccessRights -Auto

Get-RecipientPermission -Identity <UPN>
Get-Mailbox -Identity <UPN> | Format-List GrantSendOnBehalfTo

Remove persistence and restore trust

Remediate only after preserving the relevant evidence. Replace compromised credentials, remove every confirmed persistence mechanism, repair affected content, then prove that the user can return safely.

What to do

• Reset the passwordUse a trusted administrator and a verified out-of-band channel. Follow the tenant's hybrid or federated password authority.
• Clean authentication methodsRemove unknown methods and app passwords, require MFA re-registration when needed, then revoke sessions again.
• Remove mailbox persistenceRemove confirmed malicious rules, forwarding, delegates, automatic replies and mailbox settings after evidence capture.
• Revoke malicious application accessRemove user or tenant consent grants, disable the malicious application where appropriate and monitor for renewed consent.
• Repair affected email and dataRemove attacker-sent messages, reverse confirmed file changes and validate each remediation action.
• Authorize a controlled return to serviceComplete cleanup while blocked; follow the recovery sequence below for re-enablement, the test sign-in and rollback if suspicious activity returns.

For a single missing or overwritten file, use the OneDrive file recovery guide first. Confirm the owner, available history and current damage before a broad restore; legitimate later changes may also be undone.

Reduce the chance of recurrence

Prevention is part of incident closure. Turn the confirmed entry method and control gaps into assigned changes, then validate those changes before enforcement.

What to do

• Deploy phishing-resistant MFAPrioritize administrators and high-value users. Provide at least two usable methods and test recovery.
• Use Conditional Access risk policiesKeep user-risk and sign-in-risk policies separate. Start in report-only mode and exclude tested emergency access.
• Block legacy authenticationReview non-interactive sign-ins first, pilot in report-only mode, then block legacy clients.
• Restrict application consentAllow verified publishers and selected low-risk permissions rather than broad user consent.
• Improve detectionAlert on authentication-method changes, suspicious rules, external forwarding, risky sign-ins, unusual consent and abnormal downloads.
• Assign every prevention actionCreate an owner, due date and validation test. An unassigned recommendation is not a control.

Create a defensible incident record

Evidence should let another responder reconstruct what happened, what changed and why the incident was closed. Keep original exports unchanged and perform analysis on copies.

What to preserve

• UTC timelineFirst and last suspicious activity, alert time, user report, containment, remediation and validation.
• Sign-in exportsInteractive and non-interactive CSV or JSON files with the exact filters and export time.
• Audit and mail evidencePurview results, mailbox rules, forwarding, delegates, message trace, MailItemsAccessed and action results.
• Identity and application stateRoles, devices, authentication methods, risky-user state, application consent and service-principal action.
• User statementWhat the user recognized or denied, how identity was verified and any business impact reported.
• Actions and decisionsWho performed each action, when, result, approval, residual risk and why the chosen response was proportionate.

Incident ID:
Incident owner:
Affected identity:
Reported at (UTC):
Trigger and source:
User verification method and statement:
First suspicious event (UTC):
Last suspicious event (UTC):
Suspected or confirmed entry method:
Containment actions, operator and time:
Sign-in export filenames and filters:
Audit export filenames and filters:
Mailbox persistence found:
Application consent found:
Affected users, messages, files, apps and devices:
Remediation actions and validation:
Residual risk:
Escalation and notification decision:
Prevention actions, owners and due dates:
Closed by and closed at (UTC):

Assign decisions and close deliberately

One incident commander owns the timeline and closure. Technical work can be delegated, but every decision, handoff and unresolved risk must remain visible in the incident record.

Escalate immediately when

• Privileged or critical identityAdministrator, emergency access, service, executive or finance identity.
• Fraud or business email compromisePayment diversion, payroll, supplier or executive impersonation, or external recipients targeted by the attacker.
• Broad or persistent accessMultiple users, tenant-wide consent, service principal abuse, recurring access after revocation or unresolved entry method.
• Data or device compromiseExfiltration, regulated data, mass downloads, malware, token theft or an unmanaged device.

Closure gate

• Control is restoredTrusted sign-in succeeds, sessions and persistence are remediated, risk is resolved and the monitoring window is clean.
• Scope is acceptedAffected identities, email, applications, devices and data are documented, including uncertainty.
• Evidence is completeTimeline, exports, user statement, actions, approvals and validation results are stored in the incident record.
• Follow-up is ownedEvery prevention action has an owner, due date and tracking reference.
• Closure is approvedThe incident commander records residual risk, notification decision, closure reason and UTC closure time.