DNS Reconnaissance
Queried Active Directory DNS records and SRV records to identify domain controllers, Kerberos, LDAP and Global Catalog services.
Cybersecurity / Homelab
Active Directory Security Lab
A segmented attacker-and-target environment used to practise authorised Active Directory reconnaissance, enumeration and defensive investigation.
Kali LinuxWindows Server 2025NmapSMBLDAPKerberosOPNsense
Project Overview
What I set out to achieve
The objective is to understand how an Active Directory environment appears from an attacker perspective, which services expose useful information, and how that activity can be recognised and investigated defensively.
Environment
Technology and lab context
The lab separates the Kali attacker system from the Windows Server production network using OPNsense. The domain controller provides DNS, Kerberos, LDAP, SMB and Global Catalog services. Evidence is saved and reviewed as part of each testing phase.
What I Did
Implementation and investigation
SMB Enumeration
Tested anonymous SMB access, protocol support and SMB signing requirements while documenting what was and was not exposed.
LDAP / Kerberos
Queried LDAP RootDSE information and validated Kerberos services before moving into controlled username enumeration.
Evidence Collection
Stored command output and findings in a structured project repository rather than relying on transient terminal output.
Troubleshooting
Challenges encountered
Segmentation and DNS
Initial DNS and firewall rule ordering prevented expected lab traffic, requiring troubleshooting at the network layer.
Anonymous Access Limits
Several enumeration paths were correctly restricted, which helped distinguish between an exposed service and an exploitable configuration.
Learning
What this project taught me
Active Directory Protocols
Built a stronger understanding of the relationship between DNS, SMB, LDAP and Kerberos in a Windows domain.
Reconnaissance Methodology
Learned to build findings progressively instead of jumping directly to exploitation.
Defensive Thinking
Each offensive test is considered alongside the logs and network evidence a defender could use to detect it.
Evidence & Findings
Observed behaviour from the lab
Domain controller service discovery
A targeted Nmap scan confirmed the core services expected on the domain controller.
53/tcp open domain 88/tcp open kerberos-sec 389/tcp open ldap 445/tcp open microsoft-ds 3268/tcp open globalcatLDAP
The combination of DNS, Kerberos, LDAP, SMB and Global Catalog strongly supports the host's role as an Active Directory domain controller.
SMB security posture
SMB enumeration showed modern protocol support and that SMB signing was required.
445/tcp open microsoft-ds SMB2 security mode: Message signing enabled and required
This is an important defensive control because required signing reduces exposure to certain relay-style attacks.
LDAP RootDSE
Anonymous RootDSE queries returned directory metadata without exposing broader directory contents.
defaultNamingContext: DC=soundmagus,DC=local rootDomainNamingContext: DC=soundmagus,DC=local dnsHostName: WIN-N27EB14TU2H.soundmagus.local supportedLDAPVersion: 3 supportedLDAPVersion: 2
Kerberos username validation
A controlled Kerbrute user-enumeration test validated one username from a five-entry test list.
VALID USERNAME: administrator@soundmagus.local 5 usernames tested 1 valid username identified
The exercise was limited to the authorised homelab and used a small controlled wordlist.
Problem → Investigation → Resolution example
Problem
The Kali attacker system could reach the network but DNS queries through the lab gateway were failing.
Investigation
Checked OPNsense interface rules, DNS service bindings, rule ordering and direct UDP/53 reachability.
Resolution
Correcting the firewall rule order allowed DNS queries through OPNsense and restored normal name resolution.
Next Steps
Where the project goes next
Continue LDAP/Kerberos enumeration, add more defensive monitoring and eventually correlate offensive activity with SIEM alerts and Windows security events.