Add check_file_dir module and command for remote file/dir existance checks

[Hackndo]

Description

The MS-EVEN protocol (Windows Event Log RPC) exposes an ElfrOpenBELW call that accepts an arbitrary file path to open as a backup event log. The Windows kernel processes the path before the EventLog service can reject it, leaking the file's status through the returned NTSTATUS code:

• STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034): path does not exist
• STATUS_FILE_IS_A_DIRECTORY (0xC00000BA): path is a directory
• STATUS_PIPE_NOT_AVAILABLE (0xC000018E): file exists
• STATUS_ACCESS_DENIED (0xC0000022): file exists but is locked (e.g. ntds.dit on a DC)

This technique requires no administrative privilege and works with any authenticated low-privileged domain account.

Usage: nxc smb -u user -p pass -M check_file_dir -o PATH='C:\path\to\file'

Based on CVE-2025-29969, researched and disclosed by @SafeBreach (Yarin A.): https://github.com/SafeBreach-Labs/EventLogin-CVE-2025-29969. This file check issue won't be patched by MS.

The module name can be changed, I didn't find a nice way to call it.

This PR was created with the assistance of Claude Code (Sonnet 4.6) for code structure, and fixed & verified in lab env by me.

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 (list what type of assistance, tool(s)/model(s) in the description)

Setup guide for the review

No particular setup required.

Screenshots (if appropriate):

Checklist:

Insert an "x" inside the brackets for completed and relevant items (do not delete options)

• 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
• 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
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Excuse me what?? This is wild😳

Thanks for the PR!

[mpgn]

Nice !

[Mauriceter]

Super cool! :o
Do you think it would be interesting to add it in, for example, the helper directory and not just as a module?
I am sure it could be reused by a lot of other modules as a way to check if a service or product is present. For example the enum_av module could add new checks on files.

[Marshall-Hallenbeck]

@Hackndo it looks like its possible to write arbitrary files in addition to just checking their existence, is there a reason you didn't have the module do both, since the code is already in the linked repo? It could leverage an ACTION option that is read/write. The module could be named CVE-2025-29969 which is pretty clear then.

[Hackndo]

Because the write issue has been fixed. I wanted this module to use an unfixed (and "legit") feature. Moreover, the arbitrary write requires to open an SMB server with a TOCTOU exploit, leveraging a valid evtx file that is updated on the fly.
It can be added to this module but it's more complex.
If you want me to add it anyway I can do it this week-end

Edit: I'm not sure that temporary smb server is supported by netexec, plus it would require

• admin priv while executing this module
• 445 traffic to be allowed from target to attacker

And writing arbitrary files as the current user is not that much big of a deal. In rare scenario where it could be useful, I think using the https://github.com/SafeBreach-Labs/EventLogin-CVE-2025-29969 tool would be more appropriate.