Microsoft-Extractor-Suite: a PowerShell acquisition layer for M365 and Azure

One PowerShell surface for the many places Microsoft 365 keeps its records

The problem this module addresses is fragmentation. Evidence in a Microsoft tenant is scattered across the Unified Audit Log, the admin and mailbox audit logs, mail and transport rules, message trace logs, Entra ID sign-in and audit logs, and the Azure activity and directory activity logs. On top of that sit the configuration objects an investigator actually needs to reason about, such as registered OAuth applications, conditional access policies, MFA status, risky users, administrator directory roles, PIM assignments, mailbox delegated permissions, device registrations and security alerts.

Microsoft-Extractor-Suite is the Invictus IR answer to that scatter. The project description calls it a PowerShell module for acquisition of data from Microsoft 365 and Azure for incident response and cyber security purposes, and it was created by Joey Rentenaar and Korstiaan Stam and is maintained by the Invictus IR team. The intended user is a defender who already holds administrative access to a tenant and wants collection to be a command instead of a research project.

The value is consistency rather than new access. The module does not grant permissions the signed-in account does not already have. It wraps existing cmdlets and Graph API calls into named functions so that the same evidence can be gathered the same way across cases.

Three sign-in paths decide what each function can reach

The most important thing to understand before anything else is that this module runs on top of connections you establish yourself. The documentation states that you must sign in to Microsoft 365 or Azure depending on your use case before running the functions, and it lists the connection cmdlets the module provides:

Connect-M365
Connect-AzureAZ
Disconnect-M365
Disconnect-AzureAZ

The module also relies on connections from other tooling. Before running any of its functions, the project asks you to make sure the requirements are met, and if the Exchange Online module or the Microsoft Graph module is missing it points you to an installation guide in the online documentation. In other words, the module does not vendor its own authentication. It assumes Connect-ExchangeOnline or connect-mggraph is already available in your session.

This design has a direct consequence for case handling. Collection depth depends on which session is live and what that identity can read. A function built on Graph cannot see Exchange-only data, and an Exchange session cannot reach Entra ID sign-in logs. Deciding whether a command returns anything useful is partly a question about your sign-in, not just about the function name.

Installing the module from the PowerShell Gallery and importing it

Installation is a two step process, and the order matters because the import path in the documentation is a local path. The project publishes the module to the PowerShell Gallery, and the README gives the install command as a quoted line:

Install-Module -Name Microsoft-Extractor-Suite

The import step is then given as a relative path to the module manifest in the current directory:

Import-Module .\Microsoft-Extractor-Suite.psd1

The repository root lists Microsoft-Extractor-Suite.psd1 and Microsoft-Extractor-Suite.psm1 alongside Scripts, Templates, docs and a pyproject.toml, so that relative import is the path for a checkout of the source tree rather than a Gallery import by module name. If you install from the Gallery, importing by module name is the normal PowerShell route, but the documentation as written shows the manifest path.

The repository also carries a Templates directory, and one of the functions, Start-MESTriage, is described as performing quick triage for specific users using customizable templates. That pairing suggests the templates shipped in the repository feed into the triage command, and it is the piece of the toolkit most likely to need your own customization.

Get-AllEvidence is a bulk path with an honest caveat in its name

The module offers a catch-all function, Get-AllEvidence, described as collecting all almost available evidence types automatically. The parenthetical almost is doing real work in that description, and it is worth respecting. A single command that sweeps audit logs, mail rules, identity data and security signals will touch many object types, and each one depends on a different permission set and a different service limit.

For a first pass on a scoped case, the more granular functions are safer. Start-MESTriage performs quick triage for specific users using customizable templates, which narrows the blast radius to the accounts you actually care about. Functions such as Get-MFA, Get-RiskyUsers, Get-RiskyDetections, Get-ConditionalAccessPolicies and Get-AdminUsers return the identity posture that tends to explain an intrusion, and each is one cmdlet away from the others.

The pair works like this in practice. Triage a user to see who they are and what they hold, then widen to the tenant with the bulk collector. Running Get-AllEvidence first on a live tenant produces more output than anyone reads in one sitting, which is its own kind of triage failure.

Mailbox and transport rules each get a getter and a viewer

Two areas of the module are structured differently from the rest, and the difference is deliberate. For mailbox rules and transport rules, there are both export functions and display functions:

Show-MailboxRules
Get-MailboxRules
Get-MailboxRulesGraph
Get-TransportRules
Show-TransportRules

The Show variants print to the console, the Get variants export. There is also a third path for mailbox rules, Get-MailboxRulesGraph, which exports the same objects through the Graph API instead of the Exchange path. That gives you two ways to reach the same data, and the practical reason to care is that the two can disagree, because Exchange and Graph read rule configuration through different stacks. A rule that looks one way in one path and different in the other is worth noting in a report.

Mail handling gets similar depth elsewhere. Get-Email downloads specific or bulk emails, Show-Email shows email content, Get-Attachment downloads attachments, and Get-Sessions plus Get-MessageIDs collect session information and message identifiers from MailItemsAccessed events. Those last two exist because mass mail access is one of the most common post compromise signals, and the volume of accessed items is often the clearest indicator that an account was harvested.

Graph-backed collection widens scope past Exchange cmdlets

Several functions are explicitly labelled as working through the Graph API, and they cover areas that Exchange cmdlets do not reach. Get-GraphEntraSignInLogs and Get-GraphEntraAuditLogs cover sign-in and audit logging in Entra ID. Get-OAuthPermissionsGraph collects OAuth application permissions. Get-Devices collects device registration information, Get-MFA collects MFA status for users, and Get-MailboxPermissions collects delegated mailbox permissions.

Two entries in the function list stand out for a responder. Get-MailboxAuditStatus collects the mailbox audit configurations, which tells you what the tenant was actually recording rather than what you found in the logs. And Get-SecureScore retrieves Microsoft Secure Score recommendations along with current status, which gives a picture of control posture beyond the incident itself.

The role oriented functions are similarly broad. Get-PIMAssignments generates a report of all Privileged Identity Management role assignments in Entra ID, and Get-AllRoleActivity retrieves directory role memberships together with last login information for users. Combined with Get-AdminUsers, that covers the question that often decides an investigation, which is who held administrative access and when they last used it.

Licence checks exist because feature access follows the tenant's licence tier

The module does not ignore the commercial side of Microsoft 365. Get-Licenses collects all licenses in the tenant with retention times and premium licence indicators. Get-LicenseCompatibility checks for the presence of E5, P2, P1 and E3 licenses and informs about functionality limitations. Get-LicensesByUser collects license assignments for all users in the tenant. Get-EntraSecurityDefaults checks the status of Entra ID security defaults.

That is a design choice worth noting. A collection tool that ignores entitlement will happily return empty results where the tenant simply cannot produce the data, which is indistinguishable from a clean result if you do not check. The compatibility function turns that into an explicit signal, and for an investigation into missing logs, the difference between a source that was never enabled and a source that was enabled but empty matters.

The same reasoning applies to retention. Get-Licenses reports retention times, which tells you how far back the audit logs you are requesting can actually reach. A request for six months of Unified Audit Log data is answered differently by a tenant with a short retention window, and the module surfaces that rather than leaving you to guess.

GPL-2.0 licensing and a snapshot release cadence shape the adoption decision

The project is released under GPL-2.0. For an organisation that intends to modify the module, or wrap it in internal tooling, that licence carries obligations, and you should read it rather than take a summary from a review. For pure internal use during a case, the practical question is different, and it is about maintenance rather than permission.

The last push to the repository was on 2026-06-29. The three most recent releases are V4.1.0 on 2026-05-06, V4.0.2 on 2026-01-12 and V4.0.1 on 2025-10-21, and the V4.0.2 release note mentions accepting pull requests and small fixes while V4.1.0 is described as adding new features. That is a cadence of several releases a year with a major version bump in the middle of the range, which is a reasonable sign for a module that has to track changes in the services it queries.

The main upgrade cost is not code, it is revalidation. When a function wraps a Graph API endpoint or an Exchange cmdlet, a tenant side change can break it without any change to the module itself. Pinning to a known release and re-testing against a sandbox tenant before each engagement is the cheaper habit.

Editorial conclusion

Microsoft-Extractor-Suite fits incident responders and security engineers who already administer a tenant and need repeatable, scriptable collection of log and configuration data from Microsoft 365, Entra ID and Azure. It does not fit an analyst who needs case management, evidence hashing, timeline building or output formatting, because the module collects and prints and leaves the rest of the workflow open. Before running it against a real tenant, confirm that the account you sign in with holds the permissions each function needs, since the module does not choose an account for you, and that you understand what a given cmdlet will write to disk before you point it at a production mailbox.

Frequently asked questions

Official sources

1. invictus-ir/Microsoft-Extractor-Suite on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases