IDWolf is a pure-PowerShell, read-only hygiene auditor that snapshots Active Directory and Microsoft Entra ID for offline analysis, producing deterministic findings for authorized assessments.

IDWolf positions itself in a crowded identity-security tooling landscape with a simple architectural promise: collect once, analyze offline. The tool, written entirely in PowerShell, takes a read-only snapshot of an Active Directory environment or a Microsoft Entra ID tenant and then evaluates that snapshot locally, producing a self-contained HTML report alongside a findings CSV and optional JSON Lines output for SIEM ingestion. This split between collection and analysis is more than a convenience — it means the analysis engine, IDWolf.ps1, needs nothing but the snapshot file, runs on any machine, and can be re-run against historical snapshots without touching production again. The project is MIT-licensed, sits at around 20 stars, and carries an OpenSSF Baseline badge, suggesting early but hygiene-conscious development.

The collection layer is deliberately modest in its privilege requirements. Collect-ADSnapshot.ps1 runs on a domain-joined machine with the native ActiveDirectory module (RSAT) and an ordinary domain account, and writes an AD snapshot as JSON. Collect-EntraSnapshot.ps1 runs anywhere with the Microsoft Graph SDK and a Global Reader role. A separate Export-PasswordQuality.ps1 handles password quality from a trusted admin host, the PDC, or an offline NTDS.dit, using DSInternals and DCSync rights — and notably, the README is explicit that no password hash is ever handled or stored. The wrapper Start-IDWolf.ps1 (or Start-IDWolf.cmd) presents a menu over all of these, and Invoke-IDWolfScheduled.ps1 wraps collection plus analysis into a scheduled task for continuous monitoring with no prompts.

The analysis core runs 169 checks on the AD side, organized into ten areas that map almost one-to-one to how attackers actually abuse directories. The Kerberos block (14 checks) covers the classics — Kerberoasting via kerberoastable_user, AS-REP roasting, RC4/DES exposure, delegation configurations including unconstrained, constrained, RBCD and orphan SPN targets open to SPN-jacking, plus krbtgt age and Protected Users. Privileged access (18 checks) computes Tier 0 membership by SID through nesting and primary groups, flags dormant or foreign admins, examines DnsAdmins, RID 500, RODC password replication policy and Tier 0 credentials cached on RODCs. The breadth here reflects a tool written by someone who has read the post-incident literature.

The permissions area is where IDWolf gets genuinely granular: 17 checks in standard mode, expanding under the -Deep flag to include write access to logon scripts, profile paths, certificate mapping, account flags, the RBCD attribute, DCSync rights, GPP passwords, Shadow Credentials, gMSA and LAPS readers, and dMSA creation rights — the condition behind BadSuccessor. Certificate services get 19 checks spanning ESC1-5, 9, 10, 13, 15 and ESC17 (WSUS over HTTPS), with ESC6, 7, 8, 11 and 16 requiring admin rights on the CA host and a manual-look note for any CA that could not be read. Host hardening read from GPOs contributes 40 checks, from SMB and LDAP signing through WDigest, LSA protection, ZeroLogon patch posture, coercion interfaces live on DCs, PrintNightmare-relevant Point and Print settings, AlwaysInstallElevated, and mitm6-relevant IPv6 configuration.

The Entra ID collector is not a token afterthought: 90 checks mapped against the CIS Microsoft 365 benchmark cover MFA registration and strength, Conditional Access policy gaps including legacy auth and device code flow, PIM standing access and activation settings, guest and device posture, app consent and credential policies, Entra Connect health, look-alike application names, apps still on the retired Azure AD Graph, workload identity Conditional Access, and Intune roles capable of running code on devices. One check — Multi Admin Approval for device wipes and scripts — the README honestly flags as not yet verified on a real tenant, a level of disclosure that inspires more trust than most marketing copy in this space.

What elevates IDWolf above a checklist generator is its attack-condition mapping. A COVERAGE.md table links the vectors behind recent incidents and research from 2023-2026 to the specific checks that detect the configuration each attack needs. Coercion plus NTLM relay chains map to coercion_unfiltered_dc, adcs_esc8, adcs_esc11 and ldap_channel_binding_off; SCCM rogue management point abuse maps to sccm_system_management_writable; SyncJacking maps to entra_admin_synced_from_onprem and entra_connect_app_extra_credentials; the 2025 BadSuccessor dMSA technique maps to badsuccessor_dmsa_create. For defenders, this transforms a hygiene report into a prioritization aid: findings are not just policy deviations, they are preconditions for named intrusion chains.

The compliance layer is similarly concrete rather than decorative. Every check is mapped to controls in NIS2, ISO/IEC 27001:2022 Annex A, DORA and GDPR, and the report shows per control how many checks apply, how many could not be evaluated, and what was found. Checks that have no IDWolf coverage say so explicitly — the README's example is NIS2 Article 21(2)(j) on MFA in an AD report. Crucially, the project is candid about scope: this is evidence for the technical, directory-side portion of each control, and the README states plainly that it does not make anyone compliant, since policies, processes and other systems live outside a directory snapshot.

The report itself is a single self-contained HTML file with no external libraries, no CDN and no network loading — it opens offline and can be mailed as-is, a design decision that matters when audit artifacts travel through restricted environments. The dashboard tab presents a score and grade, an attack-path map and trust map rendered as SVG, Tier 0 membership, framework cards, categories and top risks; a details tab lists every finding with its remediation. Sample reports ship in examples/, including a lab report generated from a domain populated with Vulnerable-AD and the project's own tests/lab/ scripts — the README emphasizes testing on a real lab rather than synthetic data alone. An optional Gemini step can generate an executive summary and remediation plan, with the assurance that findings are always computed locally and directory names are tokenized before anything is sent.

Two more components round out the pipeline. Export-BloodHound.ps1 produces a BloodHound CE zip in beta, letting teams feed the same snapshot into graph-based attack-path analysis. And IDWolf.ps1 auto-detects whether a snapshot is AD or Entra, removing a small but recurring operational friction point. The comparison table in the README benchmarks IDWolf against PingCastle, Purple Knight, BloodHound CE, Locksmith, Maester and ADScan across capability and shape — readable PowerShell versus compiled binaries — based on public documentation as of October 2026, with an invitation to report inaccuracies.

In an authorized workflow, IDWolf fits naturally as a recurring internal control rather than a one-off assessment: the scheduled-task collector plus JSONL output turns it into a continuous drift detector for identity configuration, complementing tools like PingCastle on the AD side and Maester on the Microsoft 365 side. Its read-only posture, hash-free password quality analysis and offline analysis model minimize both risk and telemetry surprises, making it defensible to run in production during business hours. For security teams preparing for NIS2 or DORA evidence collection, the per-control mapping alone may justify a place in the toolchain.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Taranis AI for automated OSINT collection and analyst report production


• Inside semantic_firewall: how sfw fingerprints Go functions to catch supply-chain backdoors


• Inside cve-intel: local CVE triage in Rust with risk scoring and an MCP server