Adding ADWS protocol support to NetExec

[j4s0nmo0n]

Hello maintainers and community,

First, thanks for your invaluable work on NetExec , it's a gem and I use it on most of my internal penetration tests.

I'd like to propose adding Active Directory Web Services (ADWS, port 9389) to NetExec as a first-class protocol. Before opening a PR I want to validate the design and get your feedback on the integration approach.

Background

I discovered ADWS through Soaphound, the C# BloodHound ingestor by FalconForce, and I started working on the protocol to build a Linux alternative. ADWS communication is essentially MS-NMF (.NET Message Framing) frames carried over an encrypted MS-NNS (.NET NegotiateStream) session. For context, RSAT and the Active Directory PowerShell module both talk ADWS to the DCs; it's a legitimate management service that ships enabled by default on every modern domain controller.

The reference offensive tool on Linux is SOAPy by @logangoins (originally researched at IBM X-Force Red with Jackson Leverett). It's a Proof of Concept that re-implements the .NET wire formats (NNS/NMF/NBFSE) cleanly in Python and supports both reading and writing AD attributes over ADWS.

I have also been contributing back to SOAPy upstream; features I added include addcomputer, AD-integrated DNS operations, and Shadow Credentials attacks.

In parallel, I created and maintain Soaphound.py, a Python BloodHound ingestor that speaks ADWS, optionally complemented by SMB/RPC sessions to maximize compromise paths. (This is for context only: this proposal does NOT include BloodHound collection. See "Out of scope" below.)

Why ADWS belongs in NetExec

Three main reasons:

• Coverage : ADWS is enabled by default on modern DCs but is not yet reachable through NetExec. A pentester currently has to switch out of the NetExec workflow to interact with ADWS.
• Detection footprint : ADWS logging is generally less monitored than LDAP. In my own engagements, ADWS interactions rarely trigger detection controls that LDAP queries would. This makes ADWS valuable both for recon and for targeted post-exploitation operations.
• Sharing knowledge with the community : In my experience, most pentesters don't reach for ADWS unless forced to by a hardened environment. The more we use the protocol, the more exploitation paths we're likely to discover.

Proposal

Add a new nxc adws protocol exposing the same operational surface that SOAPy already covers. Specifically:

Read enumeration
--users, --computers, --groups, --admins, --spns, --asreproastable, --constrained, --unconstrained, --rbcds, free-form LDAP --query

Write operations
--rbcd, --spn, --asrep, --add-computer, --delete-computer, --disable-account

DNS operations (AD-integrated zones)
--dns-add, --dns-modify, --dns-remove, --dns-tombstone, --dns-resurrect

Shadow Credentials (msDS-KeyCredentialLink)
--shadow-creds list/add/remove/clear

Authentication
NTLM (password and NT hash) and Kerberos (ccache via $KRB5CCNAME or --use-kcache).

Compatibility shim
A small fallback for GSS_Wrap_LDAP on impacket versions older than 0.13 (faithful RFC 4121 §4.2.6.2 implementation, byte-exact validated against the native impacket API).

Integration approach - looking for your input

I have a working branch on my fork: j4s0nmo0n/NetExec:feat/adws-protocol-only. Tested against Windows Server 2025.

The current approach vendors SOAPy under nxc/protocols/adws/_soapy/ to keep the dependency surface small and to be able to apply local fixes (notably the impacket < 0.13 shim). However, I noticed that NetExec upstream does not vendor any third-party Python library, and that recent PRs (e.g. #1236) explicitly remove dependencies that overlap with impacket-native equivalents. So I'm aware that vendoring is probably not the right path here.

The way I see it, the cleanest approach for upstream is to port SOAPy into NetExec as native code, with full attribution to the original authors (Logan Goins, Jackson Leverett) in the file headers and respecting the original MIT license. SOAPy is currently distributed via pipx install from git (not on PyPI), and is described by its author as a Proof of Concept, so a native port also avoids depending on an unstable external package.

I'm open to other suggestions you might have.

Out of scope for this proposal

This proposal is only about the nxc adws protocol , the on-the-wire ADWS support and the offensive operations above. I am intentionally not proposing the BloodHound ingestor module in this issue: that's a separate, larger discussion (involves more code, has architectural questions around how ADWS-collected data should plug into NetExec's existing BloodHound workflow). I'd like to come back to you on that one once the protocol itself is settled.

AI assistance disclosure

I was partially assisted by Claude (Anthropic) for assembling and integrating the code into NetExec ; project structure, integration with the connection class, debugging the GSSAPI fallback. The protocol internals and the offensive operations I'm proposing here are based on my prior work on SOAPy and Soaphound.py , those parts of the design I know first-hand. All code was tested by me on a real lab.

Questions for the maintainers

1. Scope : are you open to adding ADWS as a first-class protocol?
2. Integration : do you confirm that a native port of SOAPy (with attribution) is preferable to vendoring, or would you suggest another approach?
3. PR sizing : how do you prefer the work to be split for review? I can do one larger PR or split it sequentially: skeleton + read + NTLM → kerberos → write operations → DNS → Shadow Credentials.
4. Naming : nxc adws as the protocol name OK?
5. Anything else I should be aware of before starting the PR?

Happy to iterate.

Thanks,
— @j4s0nmo0n

[NeffIsBack]

Hi, thanks for reaching out and also thanks for your work on Soaphound and SOAPy!

I think that is a really cool Idea!
However, my knowledge about ADWS is very limited (please keep that in mind when I am sketching ideas).
My very limited understanding so far was that ADWS was pretty much LDAP tunneled through (what I thought was) some HTTP tunnel. Is this simply wrong? Is it still LDAP, but tunneled through this (to me new) MS-NMF protocol? Is there even any LDAP logic involved at all?

If there is LDAP involved in communicating with ADWS I think it would make more sense to build some kind of adapter, so we could reuse the existing LDAP protocol/logic instead of reinventing the wheel.

Putting my LDAP assumptions aside and assuming this is an entirely new protocol, would it make sense to first integrate the protocols themselves into impacket, since most of the existing python protocols already live in impacket? (Of course with full attribution to everyone who works/worked on that project)
We could also use SOAPy directly if that is the best option (I don't have anything against adding additional dependencies per se). Just to give the full context, adding additional dependencies usually means added complexity for dependency management (they need to be uploaded to Kali, including its dependencies etc. etc.) and subsequently added maintenance work.

On the other hand, I am trying to keep "library" code separated from NetExec and not mix it up with NetExec's rather "consumer oriented" logic (e.g. we have also kept the NFS library apart from the NetExec itself). So, before we integrate SOAPys code directly into NetExec imo we should either use SOAPy directly or integrate it into impacket.

[Dfte]

Yo ma man @j4s0nmo0n! As we talked about, and Neff said, the easiest is to add your work in impacket so that we can add it as a new protocol on NXC! I also thought it was HTTP based but considering it's pure TCP with XML inside, that would be a great addition to me :)!

[logangoins]

Hey all, when Jack and I wrote SOAPy two years ago implementing the ADWS protocol stack for the first time in Python, our original goal was to get it into Impacket. After a while, we realized most PRs to impacket hadn't been merged in a pretty large amount of time. Since then, I've just been improving the library/SOAPy independent of Impacket, due to the perceived difficulty of getting it merged. I'd love to get Jack and I's protocol code into Impacket, but the best approach might be a PyPI package as @j4s0nmo0n mentioned for now.

[logangoins]

Lets get Jack cc'd here in case he has any input @jlevere

[Dfte]

I get your point, but the thing is, we are not dependent on the Impacket team. As long as you open the merge request, we can add it to our own version and switch NetExec from using the main branch to our fork. This means that if you push the ADWS components, we can integrate them into NetExec very quickly. Then, once the Impacket team merges it into the main branch, we can switch back to the upstream project ! :P

[logangoins]

Ah I see, that makes sense! I'm pretty busy with client work currently, but it wouldn't be difficult to rip the library from SOAPy and integrate it into Impacket just for this purpose.

[logangoins]

Something else I want to discuss regarding adding ADWS protocol support to NetExec: is while adding ADWS will popularize ADWS recon more (which I'm all for), I'm not sure it fits the general purposes for NetExec. NetExec is created to be a broad Pentest oriented tool for dropbox focused assessments, which doesn't focus development efforts on opsec or stealth. ADWS recon being used over LDAP recon is an inherently evasive alternative with opsec in mind, more suited for Red Team assessments when operating through SOCKS5 on an agent.

While I myself often use NetExec during pentests to get stuff done (and I love the tool greatly), I don't feel ADWS would add much value for the target audience of the (NetExec) project.

A bit more information about the SOAPy library/tooling from an engineering perspective can be found here from back when I worked at IBM

And more information from an operational perspective can be found here when I started making the tooling Red Team ready, taking it from mostly a PoC/library into something useful on ops.

I'd like to leave this open to you all, what are your thoughts on this topic.

[Dfte]

Even thought NetExec is not designed to be stealth and used for redteam assessments, having a different technique to collect LDAP information can be useful. It happened to me quite some times to audit clients with a very strong level of security, people who should be having a redteam assessment rather than an internal assessment, and having these lesser known techniques was really useful.
So yeah I don't consider "the opsec vs not opsec" thing to be relevant in our case ^^

[NeffIsBack]

Fair points. Regarding opsec in NetExec, I pretty much agree with @Dfte. My priority is not to be stealthy, but having the ability to bypass defensiv mechanisms can be very valuable.

I once ran into some software that detected the LDAP queries made by impacket/NetExec and blocked pretty much all enumeration. In these situations it can be very handy to have something that does some obfuscation/evasion (also see #1192). Once you can't query LDAP you realize how much visibility you lose, especially when missing out on bloodhound data.

That been said, I agree that this wouldn't be at the top of my priority list as long as such defensiv techniques aren't widespread. Does not hurt to have it imo either.