Fix impacket script path resolution order#93
Merged
Conversation
Root cause of persistent impacket errors: _get_impacket_script_path() found pip entry point wrappers at ~/.local/bin/ (installed for Python 3.13) before checking site-packages. These wrappers pass _is_python_script() but fail when run with sys.executable (runtime Python 3.12) because they can't import from 3.13's site-packages. Fix: check site-packages/impacket/examples/ FIRST — these scripts are guaranteed to work with sys.executable since they live in the same Python installation that _ensure_impacket_installed() targets. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The in-process `import impacket` can succeed via inherited PYTHONPATH or global site-packages while sys.executable subprocesses fail because they run in an isolated uv venv. Now checks importability via subprocess (matching how _build_script_command runs scripts) and also reorders script path resolution to prefer site-packages over PATH pip wrappers installed for a different Python version. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR fixes persistent ModuleNotFoundError issues when running Impacket example scripts by ensuring script discovery prefers the impacket/examples directory that matches the active sys.executable, rather than accidentally selecting PATH-installed wrappers from a different Python version.
Changes:
- Updated
_ensure_impacket_installed()to verify Impacket importability specifically via asys.executablesubprocess, and to install Impacket into that interpreter when needed. - Reordered
_get_impacket_script_path()resolution to prefersite-packages/impacket/examples/, then the apt doc examples path, and only then PATH discovery. - Refreshed docstrings/log messages to reflect subprocess-based execution and the new resolution order.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
mkultraWasHere
added a commit
that referenced
this pull request
Jul 15, 2026
… hack - Remove target_ip from impacket_atexec and impacket_dcomexec — impacket 0.13.x doesn't support -target-ip for these two scripts (wmiexec, psexec, smbexec do support it). - Remove OpenSSL legacy provider hack from install script — impacket uses pycryptodomex for MD4, not OpenSSL. The MD4 errors are caused by the same Python version mismatch (pycryptodomex installed for 3.13, runtime is 3.12), which PR #93's auto-install fix addresses. - Bump to 2.1.4. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
mkultraWasHere
added a commit
that referenced
this pull request
Jul 15, 2026
* fix(network-ops): remove target_ip from atexec/dcomexec, enable MD4 - Remove target_ip parameter from impacket_atexec and impacket_dcomexec — installed impacket 0.13.x doesn't support -target-ip for these scripts, causing unrecognized argument errors. Use the IP directly as target instead. - Enable OpenSSL legacy provider in install script for MD4 support — fixes "unsupported hash type MD4" errors in rbcd, dacledit, owneredit and any NTLM password auth path. - Bump to 2.1.4. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(network-ops): remove target_ip from atexec/dcomexec, drop OpenSSL hack - Remove target_ip from impacket_atexec and impacket_dcomexec — impacket 0.13.x doesn't support -target-ip for these two scripts (wmiexec, psexec, smbexec do support it). - Remove OpenSSL legacy provider hack from install script — impacket uses pycryptodomex for MD4, not OpenSSL. The MD4 errors are caused by the same Python version mismatch (pycryptodomex installed for 3.13, runtime is 3.12), which PR #93's auto-install fix addresses. - Bump to 2.1.4. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause of persistent impacket
ModuleNotFoundErroracross multiple agent sessions._ensure_impacket_installed()checkedimport impacketin-process, which could succeed via inherited PYTHONPATH or global site-packages, whilesys.executablesubprocesses (used by_build_script_command) run in an isolated uv venv where impacket isn't available.Additionally,
_get_impacket_script_path()checked PATH first, finding pip entry point wrappers at~/.local/bin/installed for Python 3.13. These wrappers fail when executed withsys.executable(runtime Python 3.12).Fixed
_ensure_impacket_installed()now checks importability viasys.executablesubprocess instead of in-process import — matches how scripts are actually executedsite-packages/impacket/examples/first — guaranteed to work withsys.executablesince it's the same Python installation~/.local/bin/) demoted to last resort