Listen to this Post
Introduction:
Traditional post-exploitation tools often rely on known executables or unsigned binaries that trigger immediate alarms in modern Endpoint Detection and Response (EDR) solutions. Recent advancements in tooling now allow attackers to leverage Microsoft-signed binaries like PsExecSvc through proxy chains such as ntlmrelayx, enabling the execution of system commands as NT AUTHORITY\SYSTEM while evading detection mechanisms that typically flag remote execution tools.
Learning Objectives:
- Understand the mechanics of abusing Microsoft-signed services to bypass EDR signatures.
- Learn how to chain PsExecSvc with ntlmrelayx through a SOCKS proxy for stealthy lateral movement.
- Identify detection strategies and mitigation techniques for this advanced attack vector.
You Should Know:
- The Evolution of PsExec and the Rise of PsExecSvc
The original PsExec tool from Sysinternals has long been a staple for system administrators and penetration testers alike. However, its widespread use has led EDR vendors to treat its execution pattern as suspicious, especially when invoked remotely. The innovation introduced by Giovanni A. and refined by Romain Bentz involves utilizing `psexecsvc` (https://lnkd.in/etQBPsK8) through a SOCKS proxy like ntlmrelayx. This technique capitalizes on the fact that `psexecsvc` is a legitimate, Microsoft-signed service binary. When executed via a trusted channel, EDRs that rely on simple hash or path-based detection may fail to classify the activity as malicious, mistaking it for routine administrative overhead.
Step‑by‑step guide explaining what this does and how to use it:
This method leverages the inherent trust of Microsoft binaries. Instead of deploying a custom executable to a target, the attacker uses the existing signed service. By routing the communication through a proxy (ntlmrelayx), the operator can send commands that are executed in the context of the SYSTEM account without spawning a new process that looks like a typical remote access tool.
Linux Commands (Using Impacket and proxychains):
Start ntlmrelayx with SOCKS support to relay authentication proxychains python3 ntlmrelayx.py -t smb://<TARGET_IP> -socks Once the relay is established, use the SOCKS proxy to interact with psexecsvc proxychains python3 psexec.py -service-name psexecsvc <DOMAIN>/<USER>:<PASS>@<TARGET_IP>
Windows Commands (PowerShell and CMD):
Using a pre-compiled psexecsvc binary on the attacking machine This assumes the binary is already placed and the service is installed remotely .\PsExec.exe -accepteula \<TARGET_IP> -s -d cmd.exe
2. Bypassing EDR Through Trusted Sources
Aurélien Chalot notes that the effectiveness of this technique lies in the classification of the tool. Standard remote execution tools (like remcom) are often flagged because they are unsigned or exhibit behavior patterns associated with hacking tools. In contrast, `psexecsvc` is digitally signed by Microsoft. This signature grants it a “hall pass” in many security products that prioritize application reputation over behavioral analysis.
Step‑by‑step guide explaining what this does and how to use it:
The attacker first establishes a foothold and uses ntlmrelayx to capture or relay NTLM hashes. By setting up a SOCKS proxy, they create a tunnel through which the `psexecsvc` traffic appears to originate from an internal, trusted host. When the command is executed, the service runs as NT SYSTEM, allowing the operator to perform actions like dumping credentials, adding users, or deploying further implants with minimal risk of detection.
Detection Evasion Configuration:
<!-- Example Sysmon Rule to Detect PsExecSvc (For Blue Teams) --> <Sysmon schemaversion="4.22"> <EventFiltering> <RuleGroup name="LateralMovement" groupRelation="or"> <ProcessCreate onmatch="exclude"> <Image condition="is">C:\Windows\System32\psexecsvc.exe</Image> <Company condition="is">Microsoft Corporation</Company> </ProcessCreate> </RuleGroup> </EventFiltering> </Sysmon>
3. The NTLM Relayx SOCKS Integration
The integration of `psexecsvc` with ntlmrelayx is crucial. Ntlmrelayx is typically used for relaying NTLM authentication to other protocols. By enabling the SOCKS server feature, it effectively turns the relayed authentication into a proxy tunnel. This allows tools like `psexec.py` to use the relayed credentials without ever possessing the plaintext password or hash, reducing the attacker’s forensic footprint.
Step‑by‑step guide explaining what this does and how to use it:
1. Set up the relay: Run ntlmrelayx to listen for incoming connections and relay them to the target SMB service while enabling SOCKS.
2. Trigger authentication: Force a victim machine to authenticate to the attacker (e.g., via LLMNR/NBNS spoofing or a malicious file).
3. Use the proxy: Configure your `psexec.py` or `psexecsvc` client to use the SOCKS proxy (127.0.0.1:1080) to connect to the target machine.
4. Execute commands: The commands are executed under the context of the relayed user, which is often a privileged account.
Configuration for SOCKS Proxy:
/etc/proxychains.conf [bash] socks4 127.0.0.1 1080
4. Linux Counterpart: Impacket’s PsExec Implementation
While the original `psexecsvc` is a Windows binary, the Impacket suite provides a Python equivalent (psexec.py) that replicates the same functionality. By combining this with proxychains and ntlmrelayx, Linux-based attackers can achieve the same level of stealth without ever writing a Windows binary to disk, further complicating forensic investigations.
Step‑by‑step guide explaining what this does and how to use it:
This method is entirely agentless. The attacker uses Python scripts to interact with the Windows Service Control Manager (SCM) remotely. By routing this traffic through the ntlmrelayx SOCKS proxy, the attacker hides the true origin of the connection. This is particularly effective in environments where network segmentation is weak, and EDR solutions are not monitoring for anomalous Python-based lateral movement from non-engineering workstations.
Lateral Movement Command:
Using impacket's psexec through the SOCKS proxy proxychains python3 /usr/share/doc/python3-impacket/examples/psexec.py -hashes :<NTLM_HASH> <DOMAIN>/<USER>@<TARGET_IP> 'whoami'
5. Hardening Against This Technique (Zero Trust Principles)
As highlighted in Aurélien’s blog post (https://sensepost.com/blog/2025/psexecing-the-right-way-and-why-zero-trust-is-mandatory/), the core defense against this is implementing zero-trust network access. Organizations should not rely solely on endpoint signatures but must enforce strict authentication and authorization at the network level. Service Principal Names (SPNs) and constrained delegation can limit where and how the PsExec service can be used.
Step‑by‑step guide explaining what this does and how to use it:
To defend against these attacks, blue teams should implement strict firewall rules on endpoints, restrict inbound SMB/RPC traffic, and deploy EDR solutions with behavioral analytics rather than just signature detection. Additionally, enabling Windows Defender Firewall with advanced security to block inbound remote service creation from unauthorized IPs can mitigate this vector.
Windows Firewall Command to Block Inbound Service Creation:
Block inbound SMB and RPC ports to prevent lateral movement netsh advfirewall firewall add rule name="Block SMB" dir=in action=block protocol=TCP localport=445 netsh advfirewall firewall add rule name="Block RPC" dir=in action=block protocol=TCP localport=135
What Undercode Say:
- The Trust Fallacy: EDR solutions that rely heavily on trust ratings of signed binaries are vulnerable to abuse. Attackers will increasingly leverage legitimate Microsoft tools to bypass defenses.
- Behavioral Over Signature: The shift must move towards behavioral detection. Monitoring for the creation of services by non-standard processes or unusual network connections from trusted binaries is critical.
The integration of `psexecsvc` with ntlmrelayx represents a significant evolution in attack tradecraft. By combining the inherent trust of Microsoft-signed binaries with the obfuscation provided by NTLM relay proxies, attackers can achieve lateral movement with a high degree of stealth. For defenders, this underscores the necessity of moving beyond traditional signature-based detection. A comprehensive zero-trust architecture, combined with rigorous network segmentation and advanced behavioral analytics, is no longer optional but mandatory to combat these sophisticated techniques.
Prediction:
As EDR vendors adapt to these techniques, we will likely see a surge in “living off the land” (LotL) detection frameworks that analyze the parent-child process relationships and network connections of signed binaries. Simultaneously, attackers will pivot to abusing cloud-native tools and managed identities, moving the battlefield from traditional on-premise lateral movement to hybrid identity-based attacks. The arms race between signature trust and behavioral anomaly detection is set to intensify, with the eventual outcome being a forced adoption of hardware-based attestation and zero-trust networking as the standard for enterprise security.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Aurelienchalotinc Thanks – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
