For defensive engineers

Close the paths before anyone walks them.

You can't fix 400 findings by Friday, and you shouldn't have to. Pathwarden tells you which handful of changes closes the most paths, gives you the steps, and proves each one worked.

Illustration: attack paths cross a network of users, computers and groups and converge on Tier Zero, shown as the Pathwarden crown. A red ring marks it compromised. One cut on the link they share closes them all, and the ring turns green: protected. Then a short checklist ticks off the next two fixes: three changes, not 400 findings.

Why it matters

Most domains carry years of accumulated permissions: a helpdesk group made local admin for one migration, a service account added to Domain Admins "temporarily", a Domain Admin who still signs in to the file server. Each is invisible on its own. Together they are the routes intruders follow from a phished laptop to the domain controllers.

Penetration tests find these routes once a year. Pathwarden can look for them every night, rank them by how many accounts can use them, and turn them into a short list of changes your team can make.

The goal isn't zero findings. It's zero ordinary accounts with a path to Tier Zero, and knowing the moment that changes.

Your workflow

Find, prioritize, fix, retest, schedule

  1. 1. Find: collect and analyze

    Collect with Pathwarden's built-in collector* (read-only LDAP, as any domain user), or bring SharpHound data for sessions and local admin rights. Then build the report.

    PowerShell
    pathwarden collect --domain scale.local --out .\collect
    pathwarden report  -i .\collect -c pathwarden.toml -o report.html
  2. 2. Prioritize: exposure, not volume

    Start with Tier Zero exposure, the share of users and computers with any path to Tier Zero. Attack path findings are rated by how many accounts can use them, with a floor of High for direct domain control. Check collection completeness before trusting a low number.

  3. 3. Fix: the remediation path first

    The remediation path is the fewest changes that cut every path, most effective first. Work through it, then the "fix directly" findings. Every rule has a guide with console steps, PowerShell, verification and rollback. When something can't change yet, accept the risk with a reason and a review date.

    Shell
    pathwarden plan -i .\collect
    pathwarden guide PW-004
  4. 4. Retest: prove it worked

    Click Retest on a finding in the app for a targeted retest* in seconds, or collect again and run pathwarden retest. A finding that rests on a logon or a local admin right is checked only on the computers on its path. Every finding gets Fixed, Still open (with what changed) or Can't tell (with why). A half-finished or Quick collection never marks a finding fixed.

    PowerShell
    pathwarden retest -i .\collect-after --finding PW-004-13b0863341b2e306
    if ($LASTEXITCODE -eq 0) { "Fixed: close the change ticket" }
  5. 5. Schedule: keep it closed

    Collect on a schedule and hand each collection to pathwarden run. Each run records new, fixed and back findings, writes the report, keeps ServiceNow* or Jira* tickets in sync by finding ID, feeds SARIF or DefectDojo* exports, and can fail a pipeline with --fail-on high. Run PingCastle too? Pass its report with -i and the import* adds its findings to the same backlog. The app's Schedule page writes the scripts for Task Scheduler with a gMSA, or a systemd timer.

    PowerShell
    pathwarden run -i .\collect -c pathwarden.toml --event event.json --report report.html --fail-on high

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.

↑↓ to moveEnter to openEsc to close