⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target: 1. Ask the user to state the exact target URL, IP, account, or resource. 2. Ask the user to confirm written authorization and the permitted scope. 3. Show the exact command(s) and explain their expected effect. 4. Wait for explicit confirmation in the current conversation.

>

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Active Directory Attack-Path Assessment

When to Use

For explicitly authorized AD security assessments or isolated training labs. Start with supplied configuration and owner evidence, then choose the smallest permitted validation. This document does not provide tools, credentials, a licensed lab or a verified exploit chain.

Mandatory confirmation gate

Before probing, authentication, collection, ticket requests, credential access, coercion, exploitation or configuration changes, obtain the exact domain/controllers/hosts/accounts, written owner authorization and permitted techniques, timing and lockout/request limits. Show the exact proposed operation and its expected effect; wait for explicit confirmation in this conversation. No confirmation means supplied-evidence analysis only. Credentials or a tool installation are not authorization.

Keep production secrets and privileged identities out of exercises. Prefer synthetic users, service accounts, tickets, certificates and canary resources in a disposable owner lab. Never default to password sprays, DCSync/krbtgt extraction, credential dumps, remote shells, machine-password resets, malicious updates, persistence or using another user's ticket. Stop on unexpected real data or cross-domain scope.

Evidence workflow

1. Record immutable scope and owner-supplied topology: domains/forests/trusts, domain-controller and client patch/configuration state, relevant privileges, service accounts and certificate services. Note missing evidence.
2. Map the candidate principal → permission → resource → possible action. Confirm effective groups/ACL inheritance, denied rights, authentication conditions, host access and actual controls; an attack-graph edge is a hypothesis.
3. Identify the specific technique's preconditions using the advanced reference. Separate credential disclosure, authentication, execution and privileged state change; one does not automatically prove the next.
4. If active validation is authorized, propose a bounded lab operation with a synthetic marker and a control case. Set stop/cleanup conditions, request/time budget and a reviewer-visible observation before execution. Do not install a historical tool or collector unreviewed.
5. Report exact evidence, limits and mitigation. Owner-approved remediation and retest are separate actions.

Core checks

BloodHound collection can contact many hosts and disclose sensitive topology. Agree collector version, collection methods and scope rather than running All by default. Do not launch browser tools with sandbox disabled as routine setup. Modern and legacy BloodHound/collector versions have different deployment and query formats. Tools named in older playbooks may be retired, renamed or incompatible; inspect official release/help in a safe environment and do not infer current flags from this document.

Controlled example