The forest doesn't change. Your audit of it should.

One run. One file. No agent.

The collector is a single signed Windows binary. Run it from a domain-joined host with a read-only account. It enumerates the forest the way a careful operator would — LDAP, ADCS RPCs, certificate stores, GPO files, EVTX slices — and writes one self-contained .fes snapshot.

The snapshot is hashed and signed at collection. From that moment on, every finding ForestEcho ever produces about your forest can be traced back to bytes on disk that haven't changed since.

• Single signed binary · Windows Server 2016 and up
• Read-only against domain controllers · no schema changes
• Configurable scope — full forest, single domain, or one OU
• Output: signed .fes file (typical 1–4 GB)
• Air-gap friendly · no telemetry, no phone-home, ever

Every rule. Every principal. Every path.

Studio loads the snapshot into memory and runs the entire rule catalog against it — ADCS escalations, Kerberos abuse patterns, replication-right misuse, GPO permissions, schema hygiene. The slow part isn't the checks. The slow part is the path math.

ForestEcho projects the Tier 0 reachability graph for every principal in your forest. ACLs, group nesting, GPO links, certificate templates, schema rights, RBCD — all walked. When a finding has a path to Tier 0, you see the path. When it doesn't, you know why not.

• Numerous rules across ADCS, GPO, EVTX, with Kerberos, ACL, and Schema in active development
• Tier 0 reachability — ACLs, group nesting, GPO links, certificate templates, schema rights, RBCD — the edges that matter for AD security tiering
• Cross-module correlation — an ESC finding paired with a DCSync event
• Findings carry severity, evidence, mapper context, and confidence

The fix, the rollback, and a record of both.

Every finding ships with a paired pair: a closure script, and the rollback that undoes it. Both are real PowerShell. Both are reviewable. Neither runs until you sign them.

Before you commit, simulate. ForestEcho applies the change against the snapshot in memory, runs the rule catalog again, and tells you what closes, what regresses, and what side effects show up. The simulation runs in seconds and never touches production.

When you do run it, the action is recorded in a signed audit log: who ran what, when, against which snapshot, with what outcome. That log is what your auditors are actually asking for.

• Generated PowerShell — not opaque, not magic, fully reviewable
• Paired rollback for every action, valid against the originating snapshot
• Simulation against the snapshot before any production change
• Signed, append-only audit log of every action and its outcome
• Compliance-grade evidence: hash chain from snapshot → fix → next snapshot

The fix held. Or it didn't. Either way, the answer is in writing.

Take another snapshot any time after you've remediated. Studio diffs the two and produces a list: what closed, what regressed, what's new. The diff carries the same signed evidence chain as the originals.

This is what you give the audit committee. This is what proves the change worked. This is also how you catch the new finding that showed up two weeks after a service migration, before someone weaponizes it.

• Snapshot diff between any two .fes files
• Closed / regressed / new — with the action that closed each one
• Trend reports across snapshot history
• Signed evidence chain suitable for SOC 2, ISO 27001, internal audit