Article Title
A Microsoft 365 incident should not start with twelve disconnected scripts
Author Name
Jeff Friedler
Affiliation: Fusion Technology Strategies
Submission Type
Draft: Full article included below
Description
Microsoft 365 investigations often scatter evidence across services, commands, permissions, and scripts. This article explains how an audit-first PowerShell console keeps collection status, guarded containment, and case evidence in one controlled workflow without pretending that partial results are complete.
Category
PowerShell for Admins
Tags
PowerShell, Microsoft 365, incident response, Microsoft Graph, Exchange Online
Summary / Pitch
I built this to reduce the fragmentation that shows up during Microsoft 365 incident response. The article focuses on audit-first operation, explicit containment controls, honest partial-collection reporting, and evidence continuity across Microsoft Graph, Exchange Online, Purview, Teams, and SharePoint. Readers can inspect the synthetic case output and run the offline validation path without authenticating to a tenant.
Article Content
When a Microsoft 365 account is compromised, the technical work spreads out quickly. Sign-ins are in one place. Mailbox rules and forwarding are somewhere else. OAuth grants, Teams, SharePoint, Purview, message tracing, risky users, and Conditional Access all have their own commands, permissions, and failure modes.
It is easy to end up with a folder full of scripts and no clean record of what actually happened.
M365 Incident Response Console is my attempt to make that process more controlled. It is a one-file PowerShell application for investigation, evidence collection, guarded containment, remediation, and reporting across the Microsoft 365 services responders commonly touch.
It starts in Audit mode. Audit mode blocks tenant changes and replaces reviewed Microsoft Graph write scopes with read-only scopes. Moving into Live mode is explicit. Every tenant-changing operation goes through one gateway with PowerShell approval handling, an operation-specific confirmation phrase, and durable case logging.
The evidence model matters just as much as the service coverage. Each case can include a chained JSONL action log, SHA-256 manifests, normalized exports, an analyst import package, and a readable HTML report. The console reports collection ceilings, repeated pages, unavailable licensed features, retention boundaries, and partial delivery instead of turning them into a false claim of completeness.
That last point is important. A polished report is not useful if it quietly hides the parts that could not be collected.
The repository includes a sanitized case report and a safe lab guide. The complete offline test suite does not authenticate to a tenant, so you can inspect the application, run its self-test, and review its preflight behavior before deciding whether to use a disposable test tenant.
The current public release is distributed as a single PowerShell file. A PowerShell Gallery package candidate has also been built and tested for modern and legacy clients, but it will not be published until the exact candidate, account, signing decision, and public package have all passed the final gates.
If you work in Microsoft 365 incident response, I would genuinely value feedback on the operating flow. I am especially interested in the places where responders still have to leave the console and assemble evidence by hand.
Repository: https://github.com/fusiontechstrategies/M365-Incident-Response-Console
Sanitized case report: https://github.com/fusiontechstrategies/M365-Incident-Response-Console/blob/main/examples/sanitized-case-report.md
Current public release: https://github.com/fusiontechstrategies/M365-Incident-Response-Console/releases/tag/v5.1.0
Author Website or Social Link
https://github.com/fusiontechstrategies
Submission Agreement
Article Title
A Microsoft 365 incident should not start with twelve disconnected scripts
Author Name
Jeff Friedler
Affiliation: Fusion Technology Strategies
Submission Type
Draft: Full article included below
Description
Microsoft 365 investigations often scatter evidence across services, commands, permissions, and scripts. This article explains how an audit-first PowerShell console keeps collection status, guarded containment, and case evidence in one controlled workflow without pretending that partial results are complete.
Category
PowerShell for Admins
Tags
PowerShell, Microsoft 365, incident response, Microsoft Graph, Exchange Online
Summary / Pitch
I built this to reduce the fragmentation that shows up during Microsoft 365 incident response. The article focuses on audit-first operation, explicit containment controls, honest partial-collection reporting, and evidence continuity across Microsoft Graph, Exchange Online, Purview, Teams, and SharePoint. Readers can inspect the synthetic case output and run the offline validation path without authenticating to a tenant.
Article Content
When a Microsoft 365 account is compromised, the technical work spreads out quickly. Sign-ins are in one place. Mailbox rules and forwarding are somewhere else. OAuth grants, Teams, SharePoint, Purview, message tracing, risky users, and Conditional Access all have their own commands, permissions, and failure modes.
It is easy to end up with a folder full of scripts and no clean record of what actually happened.
M365 Incident Response Console is my attempt to make that process more controlled. It is a one-file PowerShell application for investigation, evidence collection, guarded containment, remediation, and reporting across the Microsoft 365 services responders commonly touch.
It starts in Audit mode. Audit mode blocks tenant changes and replaces reviewed Microsoft Graph write scopes with read-only scopes. Moving into Live mode is explicit. Every tenant-changing operation goes through one gateway with PowerShell approval handling, an operation-specific confirmation phrase, and durable case logging.
The evidence model matters just as much as the service coverage. Each case can include a chained JSONL action log, SHA-256 manifests, normalized exports, an analyst import package, and a readable HTML report. The console reports collection ceilings, repeated pages, unavailable licensed features, retention boundaries, and partial delivery instead of turning them into a false claim of completeness.
That last point is important. A polished report is not useful if it quietly hides the parts that could not be collected.
The repository includes a sanitized case report and a safe lab guide. The complete offline test suite does not authenticate to a tenant, so you can inspect the application, run its self-test, and review its preflight behavior before deciding whether to use a disposable test tenant.
The current public release is distributed as a single PowerShell file. A PowerShell Gallery package candidate has also been built and tested for modern and legacy clients, but it will not be published until the exact candidate, account, signing decision, and public package have all passed the final gates.
If you work in Microsoft 365 incident response, I would genuinely value feedback on the operating flow. I am especially interested in the places where responders still have to leave the console and assemble evidence by hand.
Repository: https://github.com/fusiontechstrategies/M365-Incident-Response-Console
Sanitized case report: https://github.com/fusiontechstrategies/M365-Incident-Response-Console/blob/main/examples/sanitized-case-report.md
Current public release: https://github.com/fusiontechstrategies/M365-Incident-Response-Console/releases/tag/v5.1.0
Author Website or Social Link
https://github.com/fusiontechstrategies
Submission Agreement