Assume that you are working form a company who’s domain is
iicybersecurity.com.Disclaimer: Running this assessment with written authorization, from an isolated assessment VM, against your own infrastructure.
Several tools referenced here (Responder, Mimikatz, Rubeus, PetitPotam) are dual-use — they validate exposure but can also disrupt authentication or trigger EDR/SIEM alerts. Treat every command below as something to run in a controlled, approved test window, not casually against production.
Part 1: Finding Your AD Server IPs from the Domain Name
Before any tool-based enumeration, you need to identify the Domain Controllers (DCs) for iicybersecurity.com. AD publishes itself via DNS SRV records – this is the canonical way clients (and attackers) find DCs, so it’s your starting point too.
Step 1 – Query the LDAP SRV record
nslookup -type=SRV _ldap._tcp.dc._msdcs.iicybersecurity.com
Example output:
Server: UnKnown
Address: 10.10.0.53
_ldap._tcp.dc._msdcs.iicybersecurity.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc01.iicybersecurity.com
_ldap._tcp.dc._msdcs.iicybersecurity.com SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc02.iicybersecurity.com
dc01.iicybersecurity.com internet address = 10.10.0.10
dc02.iicybersecurity.com internet address = 10.10.0.11
This tells you immediately: two DCs, dc01 and dc02, at 10.10.0.10 and 10.10.0.11.
Step 2 – Cross-check with the Kerberos SRV record
nslookup -type=SRV _kerberos._tcp.iicybersecurity.com
Kerberos and LDAP SRV records should point to the same set of hosts. If they diverge, you likely have a misconfigured or decommissioned DC still advertising itself – worth flagging early.
Step 3 – Confirm with dig (if on Linux)
dig SRV _ldap._tcp.dc._msdcs.iicybersecurity.com
dig SRV _gc._tcp.iicybersecurity.com # Global Catalog servers
The _gc._tcp record (port 3268/3269) tells you which DCs are also Global Catalog servers — relevant for multi-domain forests.
Step 4 – Validate with a network sweep
DNS tells you what AD claims exists. Confirm it’s live and see what else is on the network:
nmap -p 53,88,135,389,445,464,636,3268,3269 10.10.0.0/24 -oA ad-discovery
Example output (abridged):
Nmap scan report for 10.10.0.10 (dc01.iicybersecurity.com)
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
636/tcp open ldapssl
3268/tcp open globalcatalog
Nmap scan report for 10.10.0.11 (dc02.iicybersecurity.com)
[... same port pattern ...]
Any host answering on that full port cluster (88 + 389 + 445 + 464) is almost certainly a DC. This also surfaces rogue or forgotten DCs that DNS didn’t report – a common finding.
Step 5 – DNS zone enumeration for the fuller picture
dnsrecon -d iicybersecurity.com -t srv,axfr,std
fierce --domain iicybersecurity.com
amass enum -d iicybersecurity.com -passive
These build out your full internal host inventory (member servers, workstations, CA servers, SCCM site systems) beyond just the DCs – you’ll need this list for later phases (Certipy targets the CA, SCCMHunter targets SCCM site systems, etc.).
At the end of Part 1, you should have a table like:
| Hostname | IP | Role |
|---|---|---|
| dc01.iicybersecurity.com | 10.10.0.10 | DC, GC |
| dc02.iicybersecurity.com | 10.10.0.11 | DC, GC |
| ca01.iicybersecurity.com | 10.10.0.20 | AD CS (Enterprise CA) |
| sccm01.iicybersecurity.com | 10.10.0.30 | SCCM Primary Site |
Part 2: Understanding the Testing Process (Why Phases Are Ordered This Way)
The tool list you have maps to a logical attacker/assessor kill chain. Understanding why the order matters helps you interpret findings correctly rather than just running tools in isolation:
- Discovery → Enumeration → Relationship Mapping → Configuration Audit → Exploitation Validation → Detection Validation. Each phase’s output feeds the next. BloodHound is only as good as the SharpHound collection; Certipy only matters once you know where your CA is; Responder/mitm6 results only make sense once you know your DC/DNS topology.
- Unauthenticated before authenticated. You start with what an anonymous attacker on your network could see (enum4linux-ng, null LDAP binds) before moving to what a compromised low-privilege user account could see (PowerView, BloodHound). This mirrors real attack progression and tells you how much damage occurs before any credentials are stolen.
- Passive before active. Responder, Inveigh, and mitm6 are listened in passive mode first. Active poisoning can break live authentication traffic — you want to measure exposure, not cause an outage.
- Config audit tools (PingCastle, Purple Knight) run in parallel with relationship mapping (BloodHound). They answer different questions: PingCastle asks “is this configured according to best practice,” BloodHound asks “given the current configuration, what attack paths actually exist.” A domain can score well on PingCastle and still have a two-hop path to Domain Admin that only BloodHound surfaces.
- Detection validation is last, deliberately. Once you know what’s exploitable, you re-run key techniques (a Kerberoast, a DCSync, an ADCS ESC1 abuse) with Defender for Identity or your SIEM watching, to confirm you’d actually catch it in a real attack. Not tested at all above.
Part 3: Step-by-Step Tool Walkthrough
Below, each tool includes the command, what it targets, and what a screenshot of the output should show you.
3.1 – PingCastle (AD Health Assessment)
PingCastle.exe --healthcheck --server dc01.iicybersecurity.com
Run on a domain-joined Windows host with a domain account. Produces an HTML report scored A–F across four risk categories: Stale Objects, Privileged Accounts, Trusts, Anomalies.
What your screenshot should capture: the summary risk-score gauge at the top of the HTML report, and the “Privileged Accounts” section listing counts of Domain Admins, accounts with DONT_REQUIRE_PREAUTH, and non-expiring passwords.
3.2 – SharpHound / BloodHound CE (Relationship & Attack Path Mapping)
Collection:
SharpHound.exe -c All -d iicybersecurity.com --zipfilename iicyber_collection
Ingest the resulting zip into BloodHound CE, then run built-in Cypher queries:
- “Shortest Paths to Domain Admins”
- “Find Kerberoastable Users”
- “Find Computers with Unconstrained Delegation”
What your screenshot should capture: the graph view showing a path from a low-privilege user node through group memberships/ACLs to the Domain Admins node.
3.3 – Certipy (AD CS Assessment)
certipy find -u lowpriv@iicybersecurity.com -p 'Password123' -dc-ip 10.10.0.10 -vulnerable
What your screenshot should capture: terminal output flagging any template vulnerable to ESC1 (client authentication + enrollee-supplied subject) – this is one of the most common AD CS misconfigurations found in the wild.
3.4 – NetExec (nxc)
nxc smb 10.10.0.0/24 -u lowpriv -p 'Password123' --shares
nxc ldap dc01.iicybersecurity.com -u lowpriv -p 'Password123' --users
What your screenshot should capture: the green [+] authenticated lines confirming valid auth against each host, and the share listing showing any shares with READ/WRITE for your low-priv account.
3.5 – GetUserSPNs.py (Impacket) — Kerberoasting exposure
GetUserSPNs.py iicybersecurity.com/lowpriv:'Password123' -dc-ip 10.10.0.10 -request
What your screenshot should capture: the table of service accounts with SPNs and their Kerberos ticket hashes (redact/handle these as sensitive output — they’re crackable offline).
3.6 – GPOZaurr (GPO Health)
Import-Module GPOZaurr
Invoke-GPOZaurr -Domain iicybersecurity.com
What your screenshot should capture: the HTML report’s “GPOZaurrBroken” or permissions tab, flagging orphaned GPOs or GPOs with overly broad edit rights.
3.7 – Responder (passive mode only, to start)
responder -I eth0 -A
-A is analyze-only – no poisoning. What your screenshot should capture: any LLMNR/NBT-NS broadcast traffic captured, showing which hosts are still resolving names via legacy broadcast protocols instead of DNS (a common relay-attack entry point).
3.8 – mitm6 (IPv6/DHCPv6 exposure, passive validation first)
mitm6 -d iicybersecurity.com --no-ra
What your screenshot should capture: confirmation of whether hosts on your network accept unsolicited DHCPv6 offers – if IPv6 isn’t in use but isn’t disabled, this is a classic relay vector into AD CS (via PetitPotam/Coercer chaining).
Part 4: Reporting Structure
Consolidate findings into a single risk register:
| Finding | Tool Source | Severity | Attack Path Length (BloodHound) | Remediation |
|---|---|---|---|---|
| ESC1-vulnerable cert template | Certipy | Critical | 1 hop to Domain Admin | Remove enrollee-supplied subject |
| Kerberoastable svc account, weak password | GetUserSPNs.py | High | 2 hops | Rotate to 25+ char password, gMSA |
| Stale/orphaned GPO with broad edit rights | GPOZaurr | Medium | N/A | Remove stale GPO, tighten delegation |
| LLMNR enabled network-wide | Responder | Medium | Enables relay chain | Disable LLMNR/NBT-NS via GPO |
Cross-reference PingCastle/Purple Knight’s configuration score against BloodHound’s exploitability graph – a domain can look fine on paper and still have a two-hop path to compromise.
Cyber Security Researcher. Information security specialist, currently working as risk infrastructure specialist & investigator. He is a cyber-security researcher with over 25 years of experience. He has served with the Intelligence Agency as a Senior Intelligence Officer. He has also worked with Google and Citrix in development of cyber security solutions. He has aided the government and many federal agencies in thwarting many cyber crimes. He has been writing for us in his free time since last 5 years.
