
azpt is a Go toolkit for authorized Azure assessments that consolidates reconnaissance, misconfiguration auditing, and post-compromise enumeration into one static binary.
| Tool | hac01/azure-pentesting-suite — Go toolkit (azpt) for authorized Azure security assessments from both authenticated and anonymous perspectives |
| Category | Cloud security assessment / Azure offensive security toolkit |
| Primary Use | Enumerating subscriptions, resources, and Entra ID objects; auditing storage misconfigurations; assessing public Blob exposure — all under azpt |
| Safe Use | Explicitly designed for authorized engagements: run only against tenants, subscriptions, and storage accounts covered by written permission, per the README's warning |
| Telemetry Note | Authenticated commands generate ARM and Microsoft Graph audit logs; the project ships OPSEC/detection notes per feature in docs/guides/, which doubles as a defender's detection map |
azpt, the binary produced by hac01/azure-pentesting-suite, is an ambitious attempt to collapse the entire Azure offensive tooling landscape — currently scattered across PowerShell modules, Python scripts, and one-off Go utilities — into a single static binary written in Go. The README frames the project as a toolkit for authorized assessments operating from two distinct perspectives: an authenticated view where the operator holds Azure credentials and enumerates subscriptions, resources, and misconfigurations, and an anonymous view that probes public Blob storage exactly as an external attacker with no credentials would. What makes the project notable is not any single capability but the breadth of the command reference, which spans outsider recon, password attacks, Key Vault interaction, Conditional Access analysis, and BloodHound-style graph export. The project labels itself a public beta, warning that commands, flags, and output formats may change between releases.
The licensing and hygiene around the project are solid: MIT licensed, 82 stars at time of writing, written in Go, and built as fully static binaries with CGO_ENABLED=0 so there are no runtime dependencies. Prebuilt releases target linux and darwin on amd64 and arm64; Windows binaries are deliberately not published because the Windows-specific helpers — prt extract, adconnect sync-creds, and DPAPI-related functionality — are only meaningful when run on a Windows host and must be compiled there from source. The README also publishes SHA256SUMS for release verification, a small but meaningful signal that the author treats supply-chain integrity seriously.
Installation is deliberately boring: download the release archive, verify it with sha256sum -c, and extract, or build from source with go build -o azpt . (requiring Go 1.26+). The go run . <command> shortcut works for operators who prefer not to leave a binary on disk. This simplicity matters in cloud engagements where the assessment workstation is often a locked-down jump box, and a dependency-free static binary sidesteps the usual pip and module-versioning friction that plagues Python-based Azure tooling.
Architecturally, the tool is organized around command families rather than engagement phases, though the documentation reverses that: docs/guides/ is organized by engagement phase and, unusually for offensive tooling, each guide documents the exact Azure RBAC or Microsoft Graph permission the technique requires alongside OPSEC and detection notes. That permission transparency is genuinely useful for scoping — a tester can hand the guide's permission list to the client's IAM team before the engagement and know precisely what the assessment identity can and cannot reach. The command reference in docs/reference/ is auto-generated via azpt gen-docs, ensuring the docs track the code rather than drifting.
The unauthenticated recon family is where the tool starts, and it maps the classic external footprint of an Azure tenant: recon realm checks whether a domain is backed by Entra ID and whether it is Managed or Federated, recon tenant recovers the tenant ID from the OpenID configuration, and recon outsider bundles that with DNS email-security records (MX, SPF, DMARC, DKIM, MTA-STS). recon subdomains enumerates Azure service subdomains across App Service, Storage, Vault, and SQL namespaces — a well-known source of dangling-resource and takeover findings. None of this requires authentication, which also means none of it appears in the target's audit logs; defenders should treat subdomain enumeration noise in their registrar and CDN telemetry as an early indicator.
The anonymous Blob capability is the project's headline feature and deserves careful framing. blob hunt --account <name> probes a public storage account, lists containers, enumerates blob versions, and flags secret-bearing files that the live site no longer references — the classic scenario of a static marketing site where an old config file containing a connection string was replaced but not purged, leaving it recoverable through versioning. This is a documentary description of a real and common misconfiguration class, and it is precisely the finding that storage hardening reviews exist to prevent: disabling public access, disabling or limiting versioning retention, and using Defender for Storage alerts. The README scopes its examples to a fictional acmewebsite account and explicitly warns that the anonymous blob commands touch third-party infrastructure over the internet and must be confined to the engagement scope.
Once authenticated, azpt leans on the Azure default credential chain — environment variables, workload identity, managed identity, then the Azure CLI's az login — but it also supports explicit service-principal authentication via --tenant, --client-id, and --client-secret flags (or the corresponding AZURE_TENANT_ID/AZURE_CLIENT_ID/AZURE_CLIENT_SECRET environment variables) and certificate-based auth with --certificate for PFX or PEM credentials. The --subscription flag, repeatable, scopes runs to specific subscriptions; the default is every subscription the principal can reach, which is itself a useful measurement of over-broad RBAC. For assessors who want a least-privilege assessment identity, the README points at creating a Reader-scoped service principal and documents the Graph permissions that RBAC alone will not grant — a nuance many operators discover only mid-engagement.
The authenticated command surface is where the suite becomes a genuine one-stop shop. The enum family covers whoami, subscriptions, resources, users, and critically access — which aggregates token scopes, directory roles, groups, and RBAC roles into a single post-credential posture picture. Graph-side enumeration extends to Conditional Access policies with enum ca, app-role grants with enum approles (flagging privilege-escalation paths toward Global Admin), PIM-eligible role holders with enum privroles, OAuth2 consent grants with enum grants, LAPS passwords, BitLocker recovery keys, dynamic groups, and administrative units. On the ARM side, webapp, storage, vm, automation, aks, disk, cosmos, and loot subcommands sweep App Service settings, storage keys and SAS minting, RunCommand execution, runbooks, kubeconfigs, and connection strings across a dozen Azure services.
Two commands stand out as analytically interesting even for defenders. scan --bloodhound exports the Entra-plus-ARM relationship graph as BloodHound CE OpenGraph JSON, meaning the tool doesn't just enumerate objects but models the escalation paths between them — the same data a purple team can use to validate that Conditional Access and PIM policies actually break the paths they're supposed to break. And scan --loot performs a consolidated sweep of high-value secrets: Function App keys, AKS kubeconfigs, LAPS and BitLocker material, APIM named values, database firewalls, snapshots, custom roles, and stale credentials. Reading that list is effectively a checklist of what a mature Azure hardening program must inventory and rotate.
For analysts writing reports, the tool produces structured findings with configurable output formats, and the documentation includes scenario walkthroughs in docs/guides/scenarios/ — end-to-end narratives covering token-to-Global-Admin escalation, Golden SAML, PRT theft, consent phishing into M365, managed-identity lateral movement, and device-code phishing, each with OPSEC and cleanup sections. From a defensive standpoint, those walkthroughs are arguably more valuable read backwards: every step in the chain corresponds to a log source (Entra sign-in logs, ARM activity logs, Graph audit events, Unified ILM) and a control that would have broken it. A SOC team building Azure detection content could do worse than treat the scenario list as a curriculum.
The beta designation should be taken seriously. The README marks several commands — loot appconfig among them — with a 🧪 flag indicating implemented-but-rough functionality, and the fast-moving command surface means automation built on azpt output may need rework between releases. Some capabilities, particularly the unauthenticated spray, mfa, and imds families, are strictly offensive in character and should only ever be exercised in lab tenancies or under explicit engagement rules of engagement; Microsoft's identity-protection telemetry is aggressive about password spraying and ROPG-style token issuance, so unauthorized use carries both ethical and operational-exposure consequences.
In sum, azpt earns attention for consolidation: one static binary covering what previously required ROADtools, MicroBurst, Stormspotter, and a folder of ad-hoc scripts. The permission-transparent documentation, OPSEC notes, and BloodHound export make it as useful for purple-team validation and tenant posture review as for offensive work. For authorized assessors, it reduces friction; for defenders, its command table is a free map of where Azure exposure actually lives. Either way, respect the README's own boundary: only tenants, subscriptions, and storage accounts you have explicit written permission to test.
hac01/azure-pentesting-suite.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.