Agent Foskett Academy • Lesson 113 • Incident Response Workflow

Incident Response Workflow: Compromised User Account.

The phishing email had been traced.

The Business Email Compromise had been contained.

But one question remained: what else did the attacker do while they had access?

Agent Foskett was no longer trying to prove the account was compromised. Microsoft Defender XDR had already given him enough evidence for that. Now he needed to reconstruct the attacker timeline, identify persistence, determine blast radius and make sure the account could be safely recovered.

Agent Foskett Academy lesson investigating compromised user accounts in Microsoft Defender XDR
Lesson overview

Learn how to investigate a compromised user account by correlating Microsoft Defender XDR identity, cloud, endpoint and alert telemetry into a clear incident response workflow.

Review sign-ins and identity risk
Build an attacker activity timeline
Find persistence and privilege misuse
Contain the account and verify recovery

Why compromised user account investigations matter

A compromised account is rarely a single sign-in. It is a sequence of authentication, access, persistence and post-compromise actions that must be reconstructed before the incident can be closed.
Identity is the first crime sceneSuccessful authentication tells you someone got in. The investigation determines whether the activity belonged to the real user or an attacker.
Access does not stop at emailA compromised account can touch Exchange Online, SharePoint, OneDrive, Teams, cloud apps, endpoints and administrative services.
Containment needs evidenceBefore closing the incident, defenders must confirm sessions are revoked, persistence is removed, privileges are reviewed and affected data is understood.

The compromised account response workflow

Agent Foskett investigates compromised identities by moving from alert validation to timeline reconstruction, persistence review and containment verification.
1. Confirm the account and triggerIdentify the affected account, the alert source, first seen time, last seen time and what caused the incident to be raised.
2. Review sign-in activityLook for new locations, unfamiliar IP addresses, risky sign-ins, impossible travel, failed attempts and successful access.
3. Build the authentication timelineCompare successful and failed sign-ins, MFA behaviour, session activity and changes in authentication context.
4. Review cloud and mailbox activityCheck whether the attacker accessed email, files, SharePoint, OneDrive, Teams or other Microsoft 365 services.
5. Search for persistenceLook for inbox rules, OAuth applications, mailbox forwarding, device persistence, startup items and suspicious long-lived access.
6. Determine blast radiusIdentify affected devices, applications, files, mailboxes, recipients, external contacts and any data that may have been accessed or moved.

Step 1 — Review sign-in activity for the account

Start with the affected account and build a clear sign-in history across the investigation window.
step-1-review-account-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ UserToInvestigate
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp asc

Step 2 — Summarise IP addresses, locations and devices

Summaries help determine whether the account was used from unusual infrastructure or too many locations.
step-2-summarise-signin-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ UserToInvestigate
| summarize SignInCount = count(),
            IPAddresses = make_set(IPAddress, 50),
            Locations = make_set(Location, 20),
            Devices = make_set(DeviceName, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountUpn

Step 3 — Review Microsoft 365 cloud activity

After confirming suspicious access, review what the account did inside cloud services.
step-3-review-cloud-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
CloudAppEvents
| where Timestamp > ago(TimeFrame)
| where AccountDisplayName =~ UserToInvestigate
   or AccountId =~ UserToInvestigate
| project Timestamp,
          AccountDisplayName,
          Application,
          ActionType,
          ObjectName,
          IPAddress,
          DeviceType,
          UserAgent
| order by Timestamp asc

Step 4 — Correlate related Defender alerts

Alert evidence helps connect identity, endpoint, cloud and email activity associated with the compromised account.
step-4-correlate-alert-evidence.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
AlertEvidence
| where Timestamp > ago(TimeFrame)
| where AccountName =~ UserToInvestigate
   or AccountUpn =~ UserToInvestigate
| project Timestamp,
          AlertId,
          EntityType,
          EvidenceRole,
          AccountName,
          DeviceName,
          RemoteIP,
          FileName,
          ProcessCommandLine
| order by Timestamp asc

Step 5 — Review endpoint process activity by the account

If the compromised account was used on a device, pivot into process telemetry to identify execution, discovery or lateral movement.
step-5-review-endpoint-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
DeviceProcessEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ UserToInvestigate
   or AccountName =~ UserToInvestigate
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Step 6 — Build a combined account investigation timeline

A single timeline helps responders explain what happened and decide whether the account is safe to return to service.
step-6-build-account-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
let SignIns =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ UserToInvestigate
    | project Timestamp, Source="IdentityLogonEvents", Action=ActionType, Detail=strcat(IPAddress, " ", Location), DeviceName;
let CloudActivity =
    CloudAppEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountDisplayName =~ UserToInvestigate or AccountId =~ UserToInvestigate
    | project Timestamp, Source="CloudAppEvents", Action=ActionType, Detail=ObjectName, DeviceName="";
union SignIns, CloudActivity
| order by Timestamp asc

Compromised account investigation clues

A compromised user account usually leaves several weak signals. The strength of the case comes from correlating them together.
Unfamiliar successful sign-insA successful sign-in from a new IP address, country, device or user agent can be the first visible sign of compromise.
Success after failuresRepeated failed attempts followed by a successful sign-in can indicate password guessing or credential theft.
Mailbox or file access after loginSuspicious email reading, file downloads, SharePoint access or OneDrive activity after authentication increases impact.
Persistence creationInbox rules, forwarding, OAuth consent or new authentication methods can indicate the attacker wanted to return later.
Privilege or group changesRole assignments, group membership changes or unusual admin actions must be treated as high priority.
User denialIf the user does not recognise the activity, preserve evidence and treat the account as compromised until containment is complete.

Containment and recovery checklist

Do not return the account to service until identity, cloud and persistence checks have been completed.
Reset credentialsReset the user password and require secure re-authentication.
Revoke sessionsRevoke refresh tokens and active sessions so stolen tokens cannot continue to be used.
Review MFA methodsRemove unfamiliar MFA methods and require the user to re-register trusted methods if needed.
Remove persistenceDelete malicious inbox rules, forwarding, OAuth grants, suspicious apps and unauthorised access methods.
Check affected dataIdentify mailboxes, files, applications and resources accessed during the compromise window.
Document the timelineRecord first seen, last seen, attacker actions, containment steps, residual risk and lessons learned.

Related Agent Foskett Academy lessons

These lessons support compromised account incident response investigations.
Hunting Playbook: Credential TheftInvestigate stolen credentials, suspicious authentication and token-related compromise.
Hunting Playbook: Risky Sign-insReview risky authentication patterns, identity risk and suspicious successful access.
Hunting Playbook: Impossible TravelUse geography, locations and IP addresses to validate suspicious sign-in behaviour.
Hunting Playbook: OAuth AbuseInvestigate suspicious consent grants and persistent access through malicious applications.
Hunting Playbook: Malicious Inbox RulesFind mailbox persistence, forwarding and attacker-created message handling rules.
Incident Response Workflow: Business Email CompromiseConnect compromised mailbox activity to financial fraud and post-compromise behaviour.

Coming next

The Incident Response Workflow series continues with malware infection investigations.
Lesson 114 — Incident Response Workflow: Malware InfectionNext, Agent Foskett investigates suspicious files, process execution, endpoint alerts, network connections and containment actions during a malware infection incident.
Why this mattersCompromised account investigations focus on identity and access. Malware infection workflows extend the investigation into endpoint behaviour and execution evidence.

Final thought

A compromised account is not closed when the password is reset.
Agent Foskett mindsetResetting the password is containment. The investigation is understanding what happened before the reset, what access remains and what evidence proves the attacker is gone.
Incident Response Workflow SeriesLesson 113 brings together identity, cloud, endpoint and alert evidence into a repeatable compromised account response process.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Incident Response Workflow Compromised User Account in Microsoft Defender XDR

Agent Foskett Academy Lesson 113 teaches defenders how to investigate compromised user accounts using Microsoft Defender XDR, Microsoft Entra ID, CloudAppEvents, IdentityLogonEvents, AlertEvidence and practical KQL workflows.

Learn compromised account incident response with KQL and Microsoft Defender XDR

Compromised account investigations help Microsoft security analysts validate suspicious sign-ins, reconstruct attacker timelines, review cloud activity, identify persistence, determine blast radius and contain identity compromise.

Microsoft Entra ID compromised user account investigation tutorial

This lesson explains how to investigate user account compromise, risky sign-ins, stolen credentials, suspicious authentication, cloud activity, endpoint execution and post-compromise behaviour using Microsoft security telemetry.