[RECON INITIATED]
Welcome, investigator. For this new assessment, you will need to know what is on the network. An Active Directory domain controller is hiding somewhere on the subnet your eth0 interface is connected to.
Why SMB first?
In an Active Directory environment, almost everything the domain controller offers to the outside world is exposed through SMB (Server Message Block) on TCP port 445. SMB is the protocol Windows uses for file sharing, but it also carries something more interesting: named pipes that host RPC services like \pipe\samr, \pipe\lsarpc, and \pipe\srvsvc. These pipes are the doorways we will knock on for the rest of this lab.
SMB is also very talkative: it will hand over the domain name, the hostname of the machine, its Windows version, and whether it is a domain controller, often before any authentication happens.
That is why we often start with SMB.
Your task:
Using ipinfo, find your local subnet. Then with netexec sweep this network and find the host that identifies itself as a domain controller. Note its IP, hostname, and domain name, you will use them for every challenge that follows.
Hint: Start with an SMB sweep: netexec smb 10.X.X.X/24. Look for a host that returns a domain name like CORP.LOCAL and the tag (domain:DEFAULT). If netexec is too slow, first do a fast port check with nmap -p 445 --open 10.X.X.X/24, then probe the live host with netexec.
[USER RECON]
You found the DC. Now we need names. Lots of them.
Why enumerate users?
Every later attack — password spraying, Kerberoasting, phishing, ACL abuse — starts with a list of valid accounts. Attackers do not need credentials to get this list in a misconfigured environment. The SMB named pipe \pipe\samr exposes the SAMR (Security Account Manager Remote) protocol, and a domain controller will happily answer “who are your users?” to an anonymous or guest session if the domain has not been hardened. This is one of the oldest and most reliable AD misconfigurations.
NetExec automates the RPC conversation for us: it connects to \pipe\samr, requests the list of domain accounts, and prints them. For a defender, seeing this succeed is a finding. For us, it is a target list.
Your task:
Enumerate all domain users via SMB/SAMR and confirm you can see the account asmith.
Hint: netexec smb samba-dc -u '' -p '' --users. The empty -u '' -p '' tells netexec to try a NULL session. If that fails on a hardened DC, you would use valid credentials — but this lab is intentionally misconfigured.
[GROUP RECON]
Users alone are not enough. In Active Directory, groups are how privilege is granted. A user is only powerful if they belong to a powerful group.
Why enumerate groups?
Two reasons. First, identifying high-value targets: Domain Admins, Enterprise Admins, Account Operators, Backup Operators, membership in these means near-total control of the domain.
Second, mapping the privilege graph: nested groups can grant unexpected rights, and enumerating them tells you who can be attacked and in what order.
Like user enumeration, groups are exposed through the same SAMR pipe. A single command returns the full picture. This is normally done with valid credentials, but with a NULL session it is a gift.
Your task:
Enumerate all domain groups and confirm you can see Domain Admins.
Hint: Same idea as the user enumeration, but with the --groups flag.
[SHARE RECON]
Now that we know who is in the domain, let's find out what is shared. SMB shares are the file-share portion of the protocol, and they are one of the most common places to find data leaks, backup files, and eventually credentials.
Why enumerate shares?
Shares are declared through the SRVSVC RPC interface (again on a named pipe, \pipe\srvsvc). A domain controller exposes administrative shares by default (NETLOGON, SYSVOL) plus whatever the admins have created. Misconfigured shares, those readable by Everyone, Anonymous, or all Domain Users — are frequently the fastest path to sensitive information.
We care about three things for each share: name, read/write permission, and who can access it. NetExec prints all three.
Your task:
List all SMB shares on the DC. Note which one is readable by Everyone or Anonymous — this is our way in.
[ANONYMOUS ACCESS]
A share named public that accepts Everyone is a goldmine. Now we stop using RPC helpers and interact with SMB the old-fashioned way: as a file client.
Why smbclient?
NetExec speaks to SMB programmatically. smbclient is the interactive client, the same protocol and the same wire format, but you get a prompt: ls, get, put. It is the tool you would use to actually walk out with data after enumerating.
The -N flag tells smbclient to skip authentication: a NULL session. If the server accepts it, we get file listing and download with no credentials at all.
Your task:
Connect to \\samba-dc\public anonymously, list the contents, and download the flag file.
Hint: smbclient //samba-dc/public -N. Once connected: ls to list, then get <filename> to download. Read the file with cat.
[POLICY RECON]
Before we start guessing passwords, we must know the rules of the game. Attacking a domain without knowing its lockout policy is how you get every account in the company locked out and get noticed.
What we need to know:
- Minimum password length: tells us the size of our search space.
- Password complexity: is Password123 even allowed?
- Lockout threshold: how many wrong attempts before an account is locked. If it is 0, there is no lockout: we can brute-force freely.
- Lockout duration and observation window: if lockout exists, these tell us how to pace our attempts.
The domain controller exposes this through the LSA (Local Security Authority) RPC interface on \pipe\lsarpc. Again, no authentication is required when the domain is misconfigured.
Your task:
Retrieve the password policy from the DC and note the lockout threshold and minimum length.
Hint: netexec smb samba-dc -u '' -p '' --pass-pol.
[WEAK CREDENTIALS]
Now we bring the earlier steps together. We have a list of users. We know the password policy. And we suspect one of the users is using something embarrassingly simple.
What we are targeting here
Two failure modes in real AD environments make this the most common initial access path:
1. Weak passwords - a surprising number of corporate accounts still use Password123, Summer2024!, or the company name.
2. No lockout - if the policy we just checked says Lockout threshold: 0, we can guess without consequence.
The technique here is a targeted brute-force: take one username we already know is valid, and try a short list of likely passwords against it. Against many users at once it would be called password spraying and is a different OPSEC calculation, spraying avoids lockouts by keeping the attempts per user low.
Your task:
Try a short list of common passwords against the user asmith and identify the correct one.
Note: A password file is available in /usr/share/passwords.txt.
Hint: Run netexec smb samba-dc -u asmith -p passwords.txt. NetExec will report the valid credential with a [+] marker.
[LDAP QUERY]
Up to this point we have been using SMB and its RPC pipes. Now we switch to the protocol Active Directory was actually built on: LDAP (Lightweight Directory Access Protocol), on TCP port 389.
Why LDAP:
Active Directory is, at its core, a tree-shaped database. Every user, group, computer, and OU is an entry with a distinguished name (DN) and a set of attributes. Common attributes include cn, mail, memberOf, userPassword, info, and description. Admins and tools frequently stash notes in these free-form text fields, unaware that any authenticated domain user can read them by default.
SAMR vs LDAP:
SAMR gave us a flat list of accounts. LDAP lets us ask structured questions like “give me every user whose description is not empty” and is available to any account with a valid logon, not just during null-session misconfigurations. This is why LDAP is the primary protocol attackers enumerate AD with.
Your task:
Using the credentials you recovered (asmith / the password you found), perform an LDAP query for the flag hidden in a user's description attribute.
Hint: netexec ldap samba-dc -u asmith -p Password123 -M get-desc-users. You can list all available modules with netexec ldap -L. If the module name differs in your version, try --query '(description=*)' as a fallback.
[AUTOMATED RECON]
You have now done, one step at a time, what a professional adversary script does in a single command. Time to see the tooling world.
Why automate?
Manual enumeration is slow and error-prone. Tools like NetExec, BloodHound, and ADScan encode years of attacker knowledge: which RPC pipes to open, which LDAP attributes matter, which group memberships imply escalation. They collapse hours of work into minutes.
But tools are not magic.
You just learned what each one of those steps means: SAMR, SRVSVC, LSA, LDAP. That knowledge is what lets you read a tool's output, verify it, and know when the tool is wrong - which happens more often than people admit. An automated scan that reports SPN found is only useful if you know that a Kerberoastable SPN means you can request a service ticket encrypted with that service account's password hash and attempt to crack it offline.
Run the automated scan with enum4linux-ng against samba-dc and see if it finds anything you missed manually.
Your task:
Run enum4linux-ng against the DC with the credentials you have, and read the output.