msInvader is an adversary simulation tool that generates realistic post-compromise attack telemetry in M365 and Azure, letting blue teams validate detections against techniques like mailbox search and mail forwarding.
| Tool | mvelazc0/msInvader — adversary simulation tool for M365/Azure that produces realistic attack telemetry for detection engineering |
| Category | Adversary simulation / purple teaming (Python) |
| Primary Use | Simulating post-compromise behaviors of a compromised user account or service principal to test and improve detections in Exchange Online, Microsoft Graph, and Azure |
| Safe Use | Designed explicitly for blue teams running authorized detection validation in owned lab or production tenants with proper approval; never against tenants you do not control |
| Telemetry Note | By design it writes authentic Microsoft Graph, EWS, and Exchange Online REST audit events into Unified Audit Log and Entra ID sign-in logs — defenders can hunt these and the README links Splunk detection research for exactly that purpose |
msInvader occupies a specific niche in the cloud adversary simulation space: it is not a exploitation framework, it is a telemetry generator. Written by Mauricio Velazco (@mvelazco) and presented at BlackHat Arsenal Europe 2024, the tool is aimed squarely at detection engineers, SOC analysts, and threat hunters who need realistic post-compromise events in M365 and Azure tenants to validate that their detection content actually fires. With roughly 330 stars, an Apache-2.0 license, and an active Wiki, it sits alongside projects like ROADtools and GraphRunner — both of which the author credits as references — but with the explicit goal of blue team enablement rather than offensive convenience.
The architectural framing is what makes msInvader interesting. It models two of the most common real-world cloud compromise scenarios: a compromised user account and a compromised service principal. Rather than trying to simulate initial access itself, it picks up the story after credentials or tokens are already in adversary hands, which mirrors how the majority of M365 incidents actually unfold following phishing, password spraying, adversary-in-the-middle (AiTM) sessions, or token theft. That post-compromise focus is precisely the phase where detection gaps are most expensive and least tested.
Authentication is handled through legitimate OAuth grant flows chosen to match the simulated intrusion vector. For user scenarios, msInvader supports the resource owner password (ROPC) flow — a good proxy for straight credential compromise — and the device authorization flow, which simulates MFA bypass patterns seen in AiTM and token-theft attacks. For service principal scenarios it uses the client credentials grant, replicating what unauthorized application or workload identity access looks like in Entra ID telemetry. Each flow produces distinct, realistic sign-in log signatures, which is exactly the point: defenders can then verify whether their conditional access policies and analytics rules correctly attribute the grant type.
Once authenticated, the tool interacts with Exchange Online through three distinct programmatic surfaces: the Microsoft Graph API, Exchange Web Services (EWS), and the REST API underpinning the Exchange Online PowerShell module. This tri-channel design matters because each protocol generates its own audit and log characteristics, and adversaries in the wild demonstrably prefer different channels depending on tooling. A detection validated only against Graph activity may be blind to the same malicious behavior performed via EWS — msInvader lets you close that gap systematically.
The technique matrix in the README shows how coverage maps across channels. read_email and create_rule work over both Graph and EWS; search_mailbox and search_onedrive are Graph-only; while enable_email_forwarding, add_folder_permission, add_mailbox_delegation, run_compliance_search, and create_mailflow operate over the Exchange Online REST API. This is a sensible catalogue: mailbox enumeration, mail search, inbox rule abuse, forwarding persistence, and mailbox delegation are all well-documented post-compromise tradecraft, and simulating them across multiple APIs exercises different detection surfaces in the Unified Audit Log.
Operationally, msInvader is configuration-driven rather than command-driven. You clone the repository, edit config.yaml, and define which techniques run in the playbooks section, with each technique taking its own parameters documented on the Wiki. Execution is a single invocation: python msInvader.py -c config.yaml. This playbook pattern is well suited to repeatable purple team exercises — you define a scenario once, then replay it after tuning detections to confirm improvement, an approach that fits naturally into continuous validation pipelines.
The README's Detections section is a deliberate signal of intent. It links public detection strategies, specifically Splunk Threat Research Team's research on Office 365 collection techniques, directly aligned with the simulation catalogue. This tight coupling of offensive simulation and published defensive content is the purple team value proposition: run the technique, hunt the resulting telemetry against known detection logic, and iterate. Expect further detection references to accumulate as the project matures.
From a defensive observability standpoint, everything msInvader does is visible in the right places — that is its purpose. The OAuth flows it exercises appear in Entra ID sign-in logs with the corresponding grant types; the Exchange operations surface in the Unified Audit Log as Graph, EWS, or PowerShell-module activity; and techniques like create_rule or enable_email_forwarding map to well-known audit events that mature SIEM content already keys on. Defenders using the tool should also watch for its artifacts as a quality check: if a simulated add_mailbox_delegation produces no alert anywhere, the gap is documented and actionable.
There are governance caveats worth stating plainly. Even in an owned tenant, techniques like create_mailflow and run_compliance_search touch real mail infrastructure, so simulations should run against designated test accounts or a lab tenant, with change management and IR awareness in place so that generated telemetry is not mistaken for a genuine incident. The tool's Apache-2.0 license and Python codebase make it straightforward to audit exactly what each technique does before running it, and operators should do exactly that.
For teams building out cloud detection programs, msInvader is a strong addition to the toolkit. Its focused scope — two compromise scenarios, three Exchange access methods, a curated technique set — makes it far more tractable than sprawling attack frameworks, while its multi-API coverage addresses the channel-hopping that real adversaries exploit. Used inside authorized assessments and detection validation loops, it converts the abstract problem of are our M365 detections any good into a concrete, repeatable test, which is exactly what the README promises and what the project delivers.
mvelazc0/msInvader.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.