NNCSC AD Enumeration
operator@kali:~/Desktop/adenumeration#
RECON IN PROGRESS

internal network assessment · engagement log

NNCSC RANGEpre-AD enumeration

SCOPE 4 domain controllers, NNCSC forest PHASE unauthenticated recon STATUS in progress NEXT username enum → coercion / relay
▼ scroll to begin
┌──(operator@kali)-[~/adenumeration] └─$ cat 00_tldr.md

// 00tl;dr

Before touching anything Active-Directory-specific, the first pass across the NNCSC range was plain unauthenticated reconnaissance against four domain controllers (tm03, tm04, tm06, tm08) — all Windows 11 / Server 2025 Build 26100 x64, all presenting the same NetBIOS name NNCSC but each its own forest with a distinct domain SID.

Results so far: anonymous SMB sessions are allowed on at least one DC, but anonymous RID brute-forcing and anonymous LDAP binds are both closed off — STATUS_ACCESS_DENIED on the LSA open, and a reset connection the moment certipy tries to query ADCS over LDAP. SMB signing is enabled and required everywhere, which rules out a straightforward SMB relay. Kerberos username enumeration via kerbrute is running now to get a foothold username list; a coercion-plus-relay path (PetitPotam/PrinterBug → LDAP or ADCS) is queued as the next real lead once a viable relay target is confirmed.

┌──(operator@kali)-[~/adenumeration] └─$ cat 00_targets.cfg

// 00target inventory

domain fqdnnetbioshostnameipdomain sid
nncsc.tm03.localNNCSCTM03-AD01192.168.103.10S-1-5-21-93128670-1895584093-491731091
nncsc.tm04.localNNCSCTM04-AD01192.168.104.10S-1-5-21-2142577963-2004663638-1031881382
nncsc.tm06.localNNCSCTM06-AD01192.168.106.10S-1-5-21-1315439458-301172041-357350462
nncsc.tm08.localNNCSCDCLAB-01192.168.108.10not yet pulled

[!] note — .104.10 and .105.10 both timed out under smbclient -L on one pass while answering fine under nxc on another. Treat that as transient/filtered, not confirmed-down, and re-check before writing either host off.

┌──(operator@kali)-[~/adenumeration] └─$ cat 01_recon_sweep.sh

// 01service sweep recon

An nmap service scan against .103.10 lays out the full AD stack in one pass:

$ nmap -sV -sC -p88,135,139,389,445 192.168.103.10
88/tcp  open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-10-03 14:19:20Z)
135/tcp open  msrpc         Microsoft Windows RPC
139/tcp open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: nncsc.tm03.local)
445/tcp open  microsoft-ds?
Service Info: Host: TM03-AD01; OS: Windows

smb2-security-mode:
  3.1.1:
    Message signing enabled and required
clock-skew: 5m35s
confirmed
SMB signing enabled + required on every DC checked → no bare NTLM relay onto SMB

[!] watch — 5m35s clock skew is close to the ~5-minute window Kerberos tolerates by default. If ticket requests start failing with clock-skew errors later, this is the first thing to check.

┌──(operator@kali)-[~/adenumeration] └─$ cat 02_smb_null_session.sh

// 02null session + RID brute recon

Anonymous SMB sessions are accepted on all three checked DCs:

$ smbclient -L //192.168.103.10 -N
Anonymous login successful
        Sharename       Type      Comment
        ---------       ----      -------   ← empty — no shares exposed to null session

enum4linux-ng confirms the same on .103/.104/.106: domain SID resolves fine over the anonymous pipe, but the follow-on RID brute dies at the LSA open on every single host:

[+] nncsc.tm03.local\:
[-] Error connecting: LSAD SessionError: code: 0xc0000022 - STATUS_ACCESS_DENIED
blocked
Anonymous RID cycling closed on all three DCs — null session opens, but LSA policy query is denied

Forcing SMB1 to fall back to legacy workgroup listing also fails cleanly — SMB1 is off, consistent with the SMBv1:False flag nxc reports on every host:

Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 192.168.103.10 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
┌──(operator@kali)-[~/adenumeration] └─$ cat 03_kerb_enum.sh

// 03Kerberos username enumeration recon

With RID brute closed, Kerberos pre-auth enumeration is the remaining path to a username list without touching a lockout counter. kerbrute confirmed the basic mechanic works — a single test name validated against tm03, case-insensitively, as expected:

$ kerbrute userenum -d nncsc.tm03.local --dc 192.168.103.10 test_single_name.txt
[+] VALID USERNAME: administrator@nncsc.tm03.local
[+] VALID USERNAME: Administrator@nncsc.tm03.local   ← case doesn't matter for the AS-REQ check

The first full run pointed at the 10-million-entry xato-net-10-million-usernames.txt list, which is far too large for useful turnaround time. Swapped to a tighter, higher-signal approach instead: a small curated list of common AD/CTF-style service-account names run in parallel across all three domains, with a names-only wordlist queued behind it as the broader net:

$ kerbrute userenum -d nncsc.tm03.local --dc 192.168.103.10 ad_common.txt -t 20
$ kerbrute userenum -d nncsc.tm04.local --dc 192.168.104.10 ad_common.txt -t 20 &
$ kerbrute userenum -d nncsc.tm06.local --dc 192.168.106.10 ad_common.txt -t 20 &
open — in progress
Running now. Once a valid username list lands: try AS-REP roasting (impacket-GetNPUsers) for accounts with pre-auth disabled before any password spray.
┌──(operator@kali)-[~/adenumeration] └─$ cat 04_password_spray.sh

// 04password spray attempt recon

An early nxc run against a single known account name with rockyou.txt failed before it even started — the wordlist has non-UTF-8 bytes nxc's password-file reader won't tolerate:

$ nxc smb 192.168.103.10 -u Administrator -p /usr/share/wordlists/rockyou.txt
ERROR    UnicodeDecodeError: Could not decode password file.
        You can ignore non UTF-8 characters with the option '--ignore-pw-decoding'

[!] held off deliberately — fixing the encoding error isn't the same as this being a good idea. Spraying all ~14M rockyou entries against one named account (Administrator) is a vertical brute-force against a single login and risks a lockout or a loud alert long before it finds anything. Parked this in favor of waiting on the username enumeration, then doing a horizontal spray — a short, low-and-slow list of likely passwords across many usernames — once a real username list exists.

┌──(operator@kali)-[~/adenumeration] └─$ cat 05_adcs_ldap_check.sh

// 05ADCS / anonymous LDAP check recon

Checked whether AD CS (certificate services) enumeration was reachable anonymously, as a possible path toward relay or template abuse. First hurdle was tooling, not the target: apt tried to pull the old abandoned python3-certipy package on top of the actively-maintained certipy-ad fork already installed, and the two collide on the same file paths.

$ sudo apt-get remove --purge python3-certipy -y
$ sudo dpkg --configure -a && sudo apt-get install -f

With that cleared, anonymous enumeration itself didn't go through. Passing an empty username/password got treated as "no credential supplied" rather than an actual anonymous bind, and switching to -no-pass with a placeholder identity surfaced the real signal — an SSL handshake getting reset outright:

$ certipy-ad find -u 'anonymous@nncsc.tm03.local' -no-pass \
    -dc-ip 192.168.103.10 -ns 192.168.103.10 -scheme ldap -vulnerable
[-] Got error: socket ssl wrapping error: [Errno 104] Connection reset by peer
blocked
Anonymous LDAP bind appears closed on this DC — ADCS enumeration needs a real credential to proceed, not a tooling fix
┌──(operator@kali)-[~/adenumeration] └─$ cat 06_coercion_plan.md

// 06coercion + relay plan

Everything above points at the same fork in the road: no anonymous RID list, no anonymous LDAP, SMB signing closing off a plain relay. A coercion attack is still the live option — it doesn't need a valid credential, it just needs a relay target that isn't enforcing signing the way SMB is.

candidate relay targetwhy it might work
LDAP / LDAPS on the same DCLDAP signing + channel binding is frequently left unenforced even when SMB signing is locked down
AD CS web enrollment (ESC8)HTTP enrollment endpoints don't carry SMB's signing requirement at all, if a CA host exists in scope
a different in-scope hostrelay DC-to-member-server, if signing isn't required there

Planned sequence once a relay target is confirmed: stand up ntlmrelayx pointed at that target, then trigger PetitPotam or PrinterBug against the DC to force its machine account to authenticate outward to the listener.

open — queued
Waiting on: ADCS presence check (certipy, blocked by the LDAP issue above) and an attack-box IP to point coercion at, before standing up the relay listener.
┌──(operator@kali)-[~/adenumeration] └─$ cat status.txt

status board

Service sweepnmap · complete on .103
Null session checksmb · allowed, no shares
Anonymous RID bruteaccess denied, all DCs
Kerberos user enumkerbrute · running
Password sprayparked pending usernames
Anonymous LDAP / ADCSbind reset
Coercion + relayplanned, not yet fired
tm08 / DCLAB-01found, not yet enumerated
┌──(operator@kali)-[~/adenumeration] └─$ ls -la /opt/arsenal/

tools used

-rwxr-xr-x  nmap                   service/version scan, SMB signing + clock-skew scripts
-rwxr-xr-x  smbclient              anonymous session + share listing
-rwxr-xr-x  enum4linux-ng          domain SID pull, RID brute attempt
-rwxr-xr-x  netexec (nxc)         SMB banner grab, credential/spray attempts
-rwxr-xr-x  kerbrute               Kerberos pre-auth username enumeration
-rwxr-xr-x  certipy-ad             ADCS enumeration over LDAP
-rwxr-xr-x  impacket (planned)    GetNPUsers for AS-REP roasting once usernames land
-rwxr-xr-x  PetitPotam / ntlmrelayx (planned)  coercion + NTLM relay to LDAP/ADCS
┌──(operator@kali)-[~/adenumeration] └─$ cat takeaways.md

key takeaways so far

  • A uniform OS build across DCs suggests a templated deployment. All four hosts are Windows 11 / Server 2025 Build 26100 x64 — worth assuming other hardening settings are identical too, so one DC's blocked path probably predicts the others.
  • Null session access doesn't mean enumeration access. SMB anonymous login succeeding and the LSA RID brute being denied are two separate controls — don't assume one implies the other on the next target.
  • SMB signing being required closes relay-to-SMB, not coercion itself. Coercion still works; the relay destination just has to move to LDAP, ADCS, or a less-hardened host.
  • A tooling error isn't always the real blocker. The certipy package conflict looked like the obstacle; the actual one was anonymous LDAP being closed on the target, found only after the install was fixed.
  • Horizontal beats vertical for spraying. One account against a huge wordlist risks lockout for little gain — many usernames against a handful of likely passwords is the lower-risk, higher-yield shape once a username list exists.