NetExec (nxc): The CrackMapExec Successor Explained

NetExec , invoked as nxc , is the network execution tool that internal network testers reach for first. It is the maintained successor to CrackMapExec, and if you have inherited older documentation or training material referencing crackmapexec or cme, this is what replaced it.

We use it on most internal engagements. This is what it actually does, and what its findings mean if you are on the receiving end of a report that mentions it.

Why CrackMapExec became NetExec

CrackMapExec was the standard tool for Active Directory enumeration and lateral movement for years. Development stalled, the original repository went unmaintained, and the community forked it. That fork became NetExec, now actively developed with broader protocol support and a faster release cadence.

Practically: cme commands mostly translate to nxc, the module ecosystem carried over and grew, and anything written for CrackMapExec after roughly 2023 assumes NetExec. Older blog posts and course material still say CrackMapExec , the concepts transfer directly.

What it is, in one line

NetExec automates the repetitive parts of attacking a network at scale: take a set of credentials and a range of hosts, then answer , where do these work, what can they reach, and what can I extract?

Doing that by hand across a few hundred hosts is impractical. NetExec turns it into a single command, which is exactly why it is central to internal network testing and why defenders should know its signature.

The protocols that matter

NetExec is organized by protocol, and each answers a different question:

• SMB , the workhorse. Host and share enumeration, credential validation across a range, session and user enumeration, password-policy retrieval, and file operations. Most internal engagements start here.
• LDAP , Active Directory enumeration: users, groups, computers, password policies, and the kind of misconfiguration data (Kerberoastable accounts, unconstrained delegation) that feeds the next stage of an attack.
• WinRM , validates Windows Remote Management access, which often becomes the route to command execution once a working credential is found.
• MSSQL , database server discovery, authentication, and command execution through xp_cmdshell where it is enabled.
• SSH, FTP, RDP, WMI , credential validation and, where the protocol allows, execution across the remaining common services.

The pattern is consistent: point it at a target range with a credential, pick a protocol, and it tells you where that credential works and what it unlocks.

What it is used for in a real test

Four jobs dominate:

Credential spraying and validation. Given one credential , recovered from a phishing exercise, a config file, or a prior finding , NetExec confirms every host on which it is valid. A single reused local administrator password across a subnet is one of the most common critical findings on internal engagements, and this is how it surfaces.

Enumeration at scale. Shares, users, groups, and policies across hundreds of hosts in one command, building the map an attacker uses to plan lateral movement.

Credential extraction. With sufficient privileges, dumping local SAM hashes or LSASS material, then feeding those onward , the mechanics of how one compromised machine becomes ten.

Lateral movement. Executing commands across every host where a credential works, demonstrating exactly how far an initial foothold reaches.

What its findings mean if you are on the receiving end

If a report cites NetExec, the meaning is usually one of these:

• A credential worked in more places than it should have , the fix is unique local administrator passwords (LAPS) and tighter privilege boundaries.
• SMB signing was not enforced , which enables relay attacks; enable signing.
• An account could read far more of Active Directory than its role needs , tighten directory permissions.
• Hashes were extractable from a host , which points to credential-caching and privilege problems on that machine.

None of these are exotic. They are the everyday structural weaknesses of a Windows network, which is exactly why a tool that finds them quickly is central to internal testing.

How defenders detect it

NetExec is noisy by design, and that is useful to blue teams. Its activity shows up as:

• Authentication spikes , many logons across many hosts from one source in a short window (Windows Event ID 4624/4625). This is the clearest signature.
• Service creation events on target hosts where execution modules run.
• SMB session patterns inconsistent with normal user behaviour.

Detection engineering against exactly these signatures is part of what a good internal test validates: not only “can we move laterally,” but “did anything notice.” If NetExec ran across your estate and nothing alerted, that is itself a finding.

Where it fits in an engagement

NetExec is an internal-network tool. It assumes a foothold , a credential and network access , and answers what an attacker does next. That places it squarely in internal network penetration testing and the lateral-movement phase of a red team assessment, after initial access and before objective completion.

It is not a vulnerability scanner and not a web tool. It does one thing , turn credentials plus network access into a map of everywhere those credentials reach , and it does it faster than anything else.

The short version

NetExec (nxc) is the maintained successor to CrackMapExec, and the first tool most testers reach for once inside a Windows network. It automates credential validation, enumeration, extraction, and lateral movement across many hosts at once. If it appears in a report against your environment, the underlying issues are almost always reused credentials, missing SMB signing, or excessive access , the structural problems every internal test is designed to find.

Want to know how far a single compromised credential would reach inside your network? That is exactly what an internal network penetration test measures. Scope one here.