Add get_writable Module

[Goultarde]

Description

Adds a new LDAP module get_writable that enumerates AD objects on which the current user
has write permissions, using DC-computed operational attributes:

• allowedAttributesEffective - attributes the user can write
• allowedChildClassesEffective - child object classes the user can create
• sDRightsEffective - security descriptor rights (OWNER, DACL, SACL)

No client-side ACL parsing needed - the DC computes the effective rights directly.

Inspired by bloodyAD get writable.

Options:

• OTYPE - filter by object type: all, user, computer, group, ou, gpo, domain (default: all)
• RIGHT - filter by right: ALL, WRITE, CHILD, SD (default: ALL)
• DETAIL - show attribute/class names instead of counts (default: False)

This PR was created with the assistance of AI (Claude code, used for code
structure, output formatting, and bitmask correctness review).

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Deprecation of feature or functionality
• This change requires a documentation update
• This requires a third party update (such as Impacket, Dploot, lsassy, etc)
• This PR was created with the assistance of AI (Claude Code / claude-sonnet-4-6 - code structure, output formatting, bitmask review)

Setup guide for the review

• Exegol (Linux 6.19.14-arch1-1 x86_64)
• Tested against GOAD lab: Windows Server 2019 (WINTERFELL DC, north.sevenkingdoms.local)
• No additional software, GPO changes, or registry settings required
• Standard domain user or admin credentials sufficient

Screenshots (if appropriate):

Default mode (low-priv user, all objects):

Detail mode (admin, OTYPE=domain DETAIL=true):

Default mode (admin, OTYPE=user):

References

• bloodyAD get writable: https://github.com/CravateRouge/bloodyAD
• MS AD Schema allowedAttributesEffective: https://learn.microsoft.com/en-us/windows/win32/adschema/a-allowedattributeseffective
• MS AD Schema allowedChildClassesEffective: https://learn.microsoft.com/en-us/windows/win32/adschema/a-allowedChildClassesEffective
• MS AD Schema sDRightsEffective: https://learn.microsoft.com/en-us/windows/win32/adschema/a-sDRightsEffective

Checklist:

• I have ran Ruff against my changes (poetry: poetry run ruff check ., use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary (new modules or features are required to be added to the e2e tests)
• If reliant on changes of third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects (N/A - no new dependencies)
• I have linked relevant sources that describes the added technique (blog posts, documentation, etc)
• I have performed a self-review of my own code (not an AI review)
• I have commented my code, particularly in hard-to-understand areas (module is self-documenting via naming and options docstring)
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Hey and thanks for the PR!

This definitely looks cool, but I think at least some of it is already covered by #1176. We should probably integrate all of these ACE enumeration techniques into one module.

[Goultarde]

Thanks for the feedback!

I did look at #1176 before submitting and I thought the approaches were fundamentally different.

acl_abuse parses nTSecurityDescriptor client-side and looks for known attack patterns (WriteDACL, GenericAll, ForceChangePassword, DCSync...). get_writable uses AD operational attributes where the DC itself computes the effective rights, with no client-side ACL parsing at all. It also surfaces every writable attribute, not just known abuse paths, which can reveal non-obvious attack vectors.

I see them as complementary rather than redundant - acl_abuse gives you specific exploitable ACE chains from a target principal, while get_writable tells you everything the current user can actually write across the domain.

Happy to discuss if merging them into a single module makes more sense for the project !