# Microsoft-Analyzer-Suite: turning M365 and Entra exports into findings > Microsoft-Analyzer-Suite is a set of PowerShell scripts that take the output of a Microsoft 365 and Entra ID log extraction and turn it into readable reports, with a chart, a table, and a mapping to MITRE techniques. It is the analysis half of a two part pipeline, and each analyzer corresponds to one specific extracted data set, from administrator roles to risky sign-ins. **LETHAL-FORENSICS/Microsoft-Analyzer-Suite** — A collection of PowerShell scripts for analyzing data from Microsoft 365 and Microsoft Entra ID - Repository: https://github.com/LETHAL-FORENSICS/Microsoft-Analyzer-Suite - Stars: 681 · Forks: 80 - Language: PowerShell - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/lethal-forensics-microsoft-analyzer-suite ## The second half of a two part pipeline Microsoft-Analyzer-Suite is a collection of PowerShell scripts for analysing data from Microsoft 365 and Microsoft Entra ID, and the title of the repository carries the qualifier Community Edition. The short version in the readme defines the scope precisely: it is the automated processing of Microsoft 365 logs and Microsoft Entra ID logs that have already been extracted by the Microsoft-Extractor-Suite, which is a separate project by Invictus-IR. That division is the whole design. One tool collects the data from the tenant through the Microsoft Graph and the administrative interfaces, and this one takes what that tool produced and makes sense of it. The analyzers do not talk to the tenant at all, they read files. For an incident responder, that separation is a feature rather than a limitation. The extraction is the part that needs credentials and a live tenant and is done once, under control, and the analysis is the part that gets repeated, adjusted, and run against several exports while you work out what happened. Being able to re-run an analysis on an export without touching the tenant is worth a lot when the question changes. It also means the tool set is only as good as the extraction that fed it, and the readme is explicit about the version it expects, naming the output files of the extractor at version 4.1.0. ## Sixteen extractors, sixteen analyzers The supported data sources are listed as a mapping, and the mapping is the documentation. Each row names an extraction function from the extractor suite and the analyzer that consumes its output. The first is the administrator roles, taken from the function that retrieves all administrator directory roles, and it feeds the admins analyzer. The devices function feeds the devices analyzer. The Graph Entra audit logs feed the Entra audit logs analyzer, and the sign-in logs feed two different analyzers, one for the interactive and non-interactive user sign-ins and one for the service principal sign-ins, which is a split that makes sense once you know that a service principal sign-in is a different kind of event from a person signing in. Then the mail side. The mailbox audit status feeds its own analyzer, the mailbox permissions feed another, and the message trace log feeds the one with the short name. The MFA status feeds the MFA analyzer, and the OAuth permissions from Graph feed the OAuth permissions analyzer. Then the risk and identity data. The risky detections feed the risky detections analyzer, the risky users feed the risky users analyzer, and the user list feeds the users analyzer. Finally the audit trail: the unified audit log feeds the UAL analyzer, the Graph version of it feeds the UAL Graph analyzer, and the transport rules feed the transport rules analyzer. Sixteen pairs in total, and the reason to read the table rather than the list of scripts is that the extractor function names are the ones you will have in your notes from the collection stage, and the table is the index from what you collected to what you can analyse. ## What the output looks like The readme shows the risky detections analyzer through a series of screenshots, and the sequence is a good description of what these tools produce. The first is the analyzer's own summary, and the next two are the risky detections themselves, broken out. The fourth is a line chart, so the reports are not only tables. And the fifth is a mapping to MITRE techniques, which is the part that matters most for an incident responder. The MITRE mapping is what turns a list of detections into something you can act on and report. A risky detection on its own is a row in a table that the reader has to interpret. A risky detection attached to a technique is a statement about what the adversary was trying to do, and it sits in a report that someone else, working from a different framework, will understand. So the shape of the output is: a summary, the detail, a chart for the trend, and a technique mapping. That is the shape of a finding you would hand to someone who did not run the tool. And the fact that the risky detections analyzer is the one documented with screenshots says something about the priorities. A tenant that has risky detections enabled has already told the organisation that it wants to know about identity compromise, and the analyzer that surfaces them, with a timeline, is the one an analyst would open first. ## One script per question, and the directories around them The repository layout makes the structure obvious, because the top level is a list of PowerShell scripts with one name each. There is an analyzer for admins, one for devices, one for the Entra audit logs, one for the Entra sign-in logs, one for the mailbox audit status, one for mailbox permissions, one for the message trace log, one for MFA, one for OAuth permissions, one for risky detections, one for risky users, one for the service principal sign-ins, one for transport rules, one for the unified audit log, one for the Graph unified audit log, and one for users. The names match the table exactly, and that is the point. An analyst knows the data set, and the file with the same name is the tool for it, so the discovery cost is close to zero. Around those scripts are the directories that make them configurable. There is a Config.json and a Config directory, a Functions directory for the shared logic, a Helper-Scripts directory, a Queries directory, a Tools directory, and a Screenshots directory holding the images the readme uses. There is also a Wiki directory in the repository, and the readme points at the project wiki for additional documentation. Having a copy of the wiki in the tree as well as the published one is an unusual choice, and it is a useful one, because the documentation is then versioned alongside the scripts it describes rather than drifting on a wiki page. The changelog at the root and the licence file are the other two entries, and the licence is the GNU General Public License version 3. ## Blacklists, whitelists, and the noise problem Two directories in the repository are worth a paragraph each, because they tell you what the authors had to deal with in practice. A blacklist directory and a whitelist directory, both at the top level. That pairing is the shape of every detection tool that runs against a real environment, because the same signals that matter in one tenant are noise in another. In a tenant where a legitimate service signs in every few minutes, a sign-in frequency that would be alarming elsewhere is the normal rhythm of an integration. In a tenant where a user travels, an unfamiliar region is expected. An account with a direct sign-in event but no interactive use might be an application, not a person. None of that is a bug in the analysis, it is the analysis working on a tenant that has its own shape, and the lists are where the shape is written down. The queries directory sits alongside them, which tells you the other half of the story. These are not only report generators over files someone else produced. The queries are the parts of the analysis that are re-run against the exported data with different predicates, and the whitelist and blacklist entries are the predicates that decide which rows are interesting and which are expected. For a responder, that is the part of the toolkit they will actually edit, because every environment has a different set of software that signs in and a different set of users who travel. A tool that ships its lists as files in the repository, rather than hardcoding them, is a tool that is meant to be adjusted for the tenant in front of you. ## Maintenance, signing, and how the pieces are distributed The badges at the top of the readme are worth reading, because each one answers a practical question. The maintenance badge says the project is actively developed, and the release history supports it: a version in May 2026, one in June, one in July, and pushes into the repository as recently as October 2026. The digital signature badge says the release is signed, which for a script collection that an analyst will run on their own machine is a real property and not a formality, because an unsigned script downloaded from a repository is exactly the kind of thing a security team objects to. The PowerShell badge and the wiki badge are the two others that matter. The first says what the scripts are, and the second says where the documentation is, and the readme pushes the wiki twice, once in a tip box near the end of the supported list and once in the badges, which is a reasonable amount of emphasis for a project whose real documentation is not in the readme. Two social links are also in the header, one for the organisation that publishes the suite and one for the team that publishes the extractor suite it consumes. So the distribution model is: a signed release artefact, a wiki for the detail, and a companion project for the collection stage. The suite is a community edition, and the wiki is listed as the place for additional documentation, which is where a responder would look first when asking how to run a particular analyzer against a particular export. ## Conclusion Microsoft-Analyzer-Suite fits an incident responder who has already exported tenant data and wants it summarised in minutes rather than by hand, especially one who already works in PowerShell and can adjust the queries and the whitelists. It does not fit a responder with no tenant data, because the analyzers read the extractor's output files and nothing else, and it does not fit a case where the output has to be a formal report, since the result is a set of reports and screens rather than a document. Verify first that your export is from the extractor version the analyzers expect, that the token you used had the directory permissions the extraction needed, and that the blacklists and whitelists in the repository match your environment, because a noisy or silent result is usually a list that needs adjusting rather than a clean tenant. ## FAQ ### What does the Microsoft-Analyzer-Suite do? It is a collection of PowerShell scripts that analyse data from Microsoft 365 and Microsoft Entra ID. It takes the output files produced by the Microsoft-Extractor-Suite and processes them, one analyzer for each extracted data set, producing summaries, charts, and a mapping to MITRE techniques. ### Which log types can the Microsoft-Analyzer-Suite analyse? Administrator roles, devices, Entra audit logs, Entra sign-in logs for interactive users and for service principals, mailbox audit status, mailbox permissions, message trace logs, MFA status, OAuth permissions, risky detections, risky users, the unified audit log and its Graph variant, the user list, and transport rules. ### Does the Microsoft-Analyzer-Suite connect to my Microsoft 365 tenant? No. It reads the output files of the separate Microsoft-Extractor-Suite, and the readme names the extractor version it expects. The separation means the analysis can be re-run on an export without touching the tenant again. ### What are the blacklists and whitelists in the Microsoft-Analyzer-Suite for? They are the lists that decide which signals are treated as findings and which are expected in a given tenant, since a legitimate service signing in every few minutes or a user travelling abroad will otherwise produce noise. They live in the repository as files, which means they are meant to be edited for the environment in front of you. ### How is the Microsoft-Analyzer-Suite maintained and distributed? The badge row states that the project is actively developed, and the releases run from 1.7.1 in May 2026 through 1.8.0 in June to 1.9.0 in July, with pushes into October. The release artefacts carry a valid digital signature, and the detailed documentation lives in the project wiki. ## Sources - [Issues](https://github.com/LETHAL-FORENSICS/Microsoft-Analyzer-Suite/issues) - [LETHAL-FORENSICS/Microsoft-Analyzer-Suite on GitHub](https://github.com/LETHAL-FORENSICS/Microsoft-Analyzer-Suite) - [License: GPL-3.0](https://github.com/LETHAL-FORENSICS/Microsoft-Analyzer-Suite/blob/main/LICENSE) - [README](https://github.com/LETHAL-FORENSICS/Microsoft-Analyzer-Suite/blob/main/README.md) - [Releases](https://github.com/LETHAL-FORENSICS/Microsoft-Analyzer-Suite/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lethal-forensics-microsoft-analyzer-suite