# NetSPI/MicroBurst: a PowerShell toolkit for auditing Azure security

> MicroBurst collects PowerShell functions for Azure discovery, weak configuration auditing and post-exploitation, aimed at penetration testers working against Azure tenants. It runs only on Windows and pulls in the Az, AzureAD, MSOnline and AzureRM module families.

**NetSPI/MicroBurst** — A collection of scripts for assessing Microsoft Azure security

- Repository: https://github.com/NetSPI/MicroBurst
- Stars: 2,446 · Forks: 339
- Language: PowerShell
- License: BSD-3-Clause
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/netspi-microburst

## What MicroBurst is for, and who runs it

MicroBurst is a collection of PowerShell functions and scripts for assessing Microsoft Azure security. The README states its purpose plainly: Azure Services discovery, weak configuration auditing, and post-exploitation actions such as credential dumping, intended for penetration tests where Azure is in use. That framing matters. This is not a hardening tool, a CSPM platform or a scanner you point at a subscription and leave running. It is a toolbox an operator drives by hand, function by function, during an engagement.

The audience follows from that. Someone already comfortable in PowerShell, working on a Windows host, who has been given scope over an Azure tenant and needs to enumerate what is there before deciding what to attack. The README's related blog list gives the shape of that work: anonymously enumerating Azure services and file resources, gathering Azure passwords, exporting RunAs certificates, using Automation Accounts to reach Key Vaults, extracting managed identity certificates from Azure Arc, and pulling credentials out of Azure Kubernetes Service. Those are engagement tasks, not day-two operations tasks.

If you are a defender looking for a configuration baseline, this is the wrong shelf. If you are an attacker or a tester who needs the enumeration and credential-access primitives that Azure's own tooling does not surface conveniently, it is the right one.

## How the module and its function directories fit together

The repository is organised by the Azure module generation each script depends on. At the top level you find Az/, AzureAD/, AzureRM/, MSOL/, Misc/ and REST/, alongside MicroBurst.psm1 and the licence file. That layout is the architecture: rather than one monolithic script set, MicroBurst groups functions by the PowerShell module family they call into, and MicroBurst.psm1 is the loader that ties them together.

The README explains the import behaviour: importing the module brings in all applicable functions based off of the currently installed modules in your environment. That is the mechanism to understand before anything else. MicroBurst does not declare a single hard dependency set and fail if it is missing. It adapts to what you have. Install only Az and the Az-flavoured functions load; add MSOnline and the MSOL set becomes available.

The dependency note in the README adds historical context: the toolkit was originally written with the AzureRM PS modules, and older scripts have been ported to their newer Az equivalents. The presence of both AzureRM/ and Az/ directories in the current tree reflects that migration still being visible in the layout, and the README lists Az, Azure, AzureRM, AzureAD and MSOnline as all being used in different scripts. The REST/ directory is a further signal that not every function goes through a PowerShell module at all; some work against the Azure REST surface directly.

## Installing MicroBurst on Windows and running a first enumeration

There is no package manager install for MicroBurst itself. The README's workflow is: download the repository, trust the files, import the module. The platform note is explicit that these scripts will only run on a Windows-based platform, so a Linux or macOS shell is out before you start.

After downloading, the README gives a recursive unblock command to mark the downloaded files as trusted, which avoids the per-file trust prompt when PowerShell loads them:

```bash
PS C:> dir -Recurse .\MicroBurst-master | Unblock-File
```

Next, install the supporting modules. The README recommends Az, AzureAd and MSOnline, and gives the generic install form:

```bash
PS C:> Install-Module <module-name>
```

Replace <module-name> with one of the recommended modules. You do not need all of them for every function, but the more you install, the more of MicroBurst becomes available at import time.

Then import the module from the directory you downloaded:

```bash
PS C:> Import-Module .\MicroBurst.psm1
```

The README notes this imports all applicable functions based on the modules currently installed. Functions are then invoked by name. The README's own example is a domain information gathering function:

```bash
PS C:> Get-AzDomainInfo
```

If you want to know what a specific script does before running it, the README points at PowerShell's own help system:

```bash
PS C:> Get-Help Invoke-EnumerateAzureSubDomains
```

That is the intended discovery path. The README does not enumerate every function inline; it defers to the wiki for usage details on the toolkit and its available functions.

## Where MicroBurst stops being the right tool

The Windows-only constraint is the first hard limit, and the README states it without hedging. If your assessment runs from a Linux jump box or a macOS laptop, you cannot use this toolkit as shipped. There is no documented cross-platform path.

The second limit is the module sprawl. Five module families are named as in use across different scripts: Az, Azure, AzureRM, AzureAD and MSOnline. Microsoft has been retiring the older surfaces, and the README itself describes the AzureRM scripts as the original ones with newer Az equivalents having been written since. That means the toolkit carries scripts whose dependency generation is older than the newer ones, and the README does not tell you which script uses which. You find out from the directory a function lives in, or from Get-Help.

Third, and most important for scoping: MicroBurst performs post-exploitation actions including credential dumping. The README describes the toolkit as intended for penetration tests. Running functions like these outside an authorised engagement is not a grey area, and nothing in the repository is designed to prevent it. There is no dry-run mode documented, no scope guard, no confirmation prompt described in the README. The operator is the control.

Finally, the README does not document rollback, cleanup or remediation for anything the post-exploitation functions do. If you need a tool that tells you how to undo its own changes, this is not that tool.

## MicroBurst compared with Microsoft's own Az module alone

The honest alternative is not another third-party toolkit; it is the Az PowerShell module by itself, which the README already lists as a recommended dependency. The difference in approach is one of packaging and intent.

Az gives you cmdlets that map to Azure resource management operations. You authenticate, you call Get-AzSomething, you get objects back. It is the supported, documented, versioned interface to the platform, and it is what a defender or an administrator uses to inspect and manage a tenant.

MicroBurst sits on top of that and asks different questions. Its functions are shaped by what a tester needs to find: which subdomains exist, which storage or file resources are anonymously reachable, where credentials or certificates are recoverable, which managed identities or Automation Accounts can be abused for privilege escalation or persistence. The README's blog list is effectively the task inventory, covering anonymous enumeration of Azure services and file resources, RunAs certificate export, Automation Account access to Key Vaults, managed identity privilege escalation, Desired State Configuration persistence, and credential extraction from AKS and Azure Arc.

So the trade-off is coverage against support. Az is maintained by Microsoft and follows the platform. MicroBurst is a community toolkit from NetSPI that encodes offensive patterns you would otherwise have to write yourself, at the cost of depending on several module generations and running only on Windows. If you only need to inventory resources, Az alone is sufficient and simpler. If you need the offensive primitives, you are writing them yourself or using something like MicroBurst.

## Maintenance, module churn and the BSD 3-Clause licence

The repository is not archived, and the last push was on 2026-06-29. That is recent enough that the toolkit is not abandoned, but the README gives no release history and no retrieved releases accompany it, so there is no versioned changelog to read. You are tracking the master branch.

Upgrade cost concentrates in the dependency layer rather than in MicroBurst's own code. Because import behaviour depends on which of Az, Azure, AzureRM, AzureAD and MSOnline are present, a change in your environment's module set changes which functions load. Microsoft's retirement of the older Azure PowerShell generations is the pressure point here, and the README's note that older scripts have been ported to Az equivalents shows the project has absorbed some of that already. It does not promise the port is complete.

The licence is BSD 3-Clause, and the repository carries a LICENSE.txt at the top level. BSD 3-Clause is a permissive licence that permits use and redistribution with the copyright notice and disclaimer retained, and it includes a clause restricting use of contributor names for endorsement. That is a summary of the licence text, not legal advice; read LICENSE.txt and your own counsel's position before redistributing it inside an organisation or shipping it in a product.

The practical consequence for a tester is small: you can carry the toolkit into an engagement without a copyleft obligation on your own scripts. The practical consequence for a vendor is that you can bundle it, provided you honour the notice and endorsement terms.

## Conclusion

MicroBurst fits a Windows-based penetration tester with the Az, AzureAD or MSOnline modules already installed, who needs discovery and weak-configuration auditing against an Azure tenant in scope. It does not fit Linux or macOS operators, and it is not a hardening or continuous-compliance tool: the functions are written for assessment, not for remediation. Before adopting it, verify which of the four module families your environment has, because MicroBurst.psm1 imports functions based on what is installed, and check Get-Help output for the specific script you intend to run rather than assuming the README covers it.

## FAQ

### How do I use MicroBurst?

Download the repository, run the recursive Unblock-File command the README gives, install the recommended Az, AzureAd and MSOnline modules, then import MicroBurst.psm1 and invoke functions by name such as Get-AzDomainInfo. Use Get-Help with a script name to see what it does.

### Does MicroBurst run on Linux or macOS?

No. The README's platform note states that these scripts will only run on a Windows-based platform.

### Which PowerShell modules does MicroBurst require?

The README lists Az, Azure, AzureRM, AzureAD and MSOnline as all being used in different scripts, and recommends installing Az, AzureAd and MSOnline. The module imports only the functions that match the modules installed in your environment.

### What licence is MicroBurst released under?

BSD 3-Clause. The repository carries a LICENSE.txt at the top level and the README lists the licence as BSD 3-Clause.

## Sources

- [Issues](https://github.com/NetSPI/MicroBurst/issues)
- [License: BSD-3-Clause](https://github.com/NetSPI/MicroBurst/blob/master/LICENSE)
- [NetSPI/MicroBurst on GitHub](https://github.com/NetSPI/MicroBurst)
- [README](https://github.com/NetSPI/MicroBurst/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netspi-microburst