Ntlm-Relay — CraftedSignal Threat Feed

Detecting Potential PowerShell Pass-the-Hash/Relay Scripts

hello@craftedsignal.io — Wed, 03 Jul 2024 12:00:00 +0000

This detection identifies PowerShell scripts containing artifacts indicative of NTLM relay or pass-the-hash (PtH) attacks. These techniques allow attackers to authenticate to systems without needing plaintext passwords, enabling lateral movement and privilege escalation. The rule focuses on identifying specific byte sequences and strings within PowerShell script blocks that suggest NTLM/SMB negotiation and credential access attempts. This detection helps defenders identify and respond to potential credential theft and abuse within their Windows environments. The rule is based on observed techniques used in various publicly available tools such as Invoke-TheHash, Check-LocalAdminHash, and PoshC2.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker executes a PowerShell script on the compromised system. This script could be directly executed or obfuscated to evade initial detection.
The PowerShell script attempts to perform NTLM relay or pass-the-hash attacks by utilizing specific byte sequences related to NTLM/SMB negotiation, such as NTLMSSPNegotiate or 0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50.
The script may utilize tools like Invoke-WMIExec or Invoke-SMBExec to execute commands on remote systems using the stolen credentials.
The attacker attempts to authenticate to other systems on the network using the relayed credentials or password hashes.
Successful authentication allows the attacker to move laterally, accessing sensitive data or escalating privileges on other systems.
The attacker may deploy additional payloads or establish persistence mechanisms for continued access.

Impact

A successful pass-the-hash or NTLM relay attack can grant an attacker unauthorized access to sensitive systems and data within the network. This can lead to data breaches, financial loss, or disruption of critical services. The impact could range from compromising a few systems to gaining domain administrator privileges, depending on the attacker’s goals and the network’s security posture. Organizations can experience significant financial and reputational damage due to data breaches and service disruptions.

Recommendation

Enable PowerShell Script Block Logging to capture the necessary data for this detection. Refer to the setup instructions in the rule documentation for configuration details.
Deploy the Sigma rule Detecting Potential PowerShell Pass-the-Hash/Relay Scripts to your SIEM and tune it based on your environment.
Investigate any alerts generated by this rule to determine the scope and impact of the potential attack. Refer to the triage and analysis section in the rule documentation for guidance on investigation steps.
Implement network segmentation and access controls to limit the impact of lateral movement.
Monitor authentication events (event codes 4624, 4625, 4648) for suspicious activity, such as NTLM authentication from unexpected source IPs or to unusual target systems, as described in the rule’s investigation notes.

Potential Local NTLM Relay via HTTP

hello@craftedsignal.io — Tue, 09 Jan 2024 14:00:00 +0000

This detection identifies attempts to coerce local NTLM authentication over HTTP through WebDAV named-pipe paths, focusing on Print Spooler and SRVSVC. Attackers can exploit this vulnerability, often combined with tools like NTLMRelay2Self, PetitPotam, or modified versions of krbrelayx’s printerbug.py, to relay the obtained credentials and escalate their privileges within the network. This technique allows attackers to bypass traditional security measures by leveraging legitimate Windows protocols for malicious purposes. Successful exploitation can lead to domain dominance and unauthorized access to sensitive resources. This activity is often associated with post-exploitation activity following initial access via other means.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker executes rundll32.exe to load davclnt.dll using the DavSetCookie function.
The rundll32.exe process is invoked with arguments specifying a named pipe path over HTTP, such as http*/print/pipe/*, http*/pipe/spoolss, or http*/pipe/srvsvc.
The system attempts to authenticate to the specified HTTP endpoint using NTLM.
The attacker intercepts the NTLM authentication request.
Using a relay tool like NTLMRelay2Self or ntlmrelayx, the attacker relays the captured NTLM credentials to another service or machine.
The attacker leverages the relayed credentials to escalate privileges or gain unauthorized access to network resources.
The attacker may then perform lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation allows attackers to escalate privileges within the compromised system and potentially the entire domain. This can lead to unauthorized access to sensitive data, deployment of ransomware, or other destructive activities. The impact ranges from data breaches and financial losses to complete system compromise. Depending on the targeted accounts, the attacker may be able to achieve domain administrator privileges.

Recommendation

Deploy the Sigma rule “Potential Local NTLM Relay via HTTP” to your SIEM to detect the execution of rundll32.exe with specific arguments indicative of NTLM relay attempts.
Enable Sysmon process creation logging to ensure the necessary data is available for the Sigma rule to function correctly.
Monitor network connections originating from processes that load davclnt.dll to identify potential NTLM relay traffic.
Investigate and block the usage of tools like NTLMRelay2Self, PetitPotam, and ntlmrelayx within the environment.
Implement mitigations for NTLM relay attacks, such as enabling Extended Protection for Authentication (EPA) and disabling NTLM where possible.
Review and restrict the usage of WebClient service and Print Spooler service where not required.

Potential NTLM Relay Attack against a Computer Account

hello@craftedsignal.io — Wed, 03 Jan 2024 15:00:00 +0000

This detection rule identifies potential NTLM relay attacks targeting computer accounts in Windows environments. The attack involves coercing a target server to authenticate to an attacker-controlled system and then relaying that authentication to another service. It focuses on detecting a sequence of events: initial coercion attempts against specific named pipes known to be vulnerable, followed by authentication attempts using the target server’s computer account from a different host. This activity can allow an attacker to gain unauthorized access and execute commands with the privileges of the compromised computer account. The rule leverages Windows Security Event Logs to identify these patterns, providing a mechanism for defenders to detect and respond to NTLM relay attacks. The detection is based on research from 2025/2026 on coerced authentication methods and NTLM reflection techniques.

Attack Chain

The attacker gains initial access to a machine within the network.
The attacker initiates a coercion attack against a target server, forcing it to authenticate to a malicious endpoint. This often involves leveraging vulnerabilities in services such as Spoolss, Netlogon, or other RPC services. The attacker uses methods outlined in the referenced coercion authentication research.
The target server attempts to access a named pipe on the attacker-controlled system. This is logged as a File Share event (Event ID 5145) on the target server, indicating access to a named pipe like Spoolss, netdfs, lsarpc, lsass, netlogon, samr, efsrpc, FssagentRpc, eventlog, winreg, srvsvc, dnsserver, or WinsPipe.
The attacker captures the NTLM authentication attempt from the target server.
The attacker relays the captured NTLM authentication to another service on the network, impersonating the target server. The authentication event is logged (Event ID 4624 or 4625), showing a logon attempt using the NTLM protocol and a computer account (username ending in “$”).
The authentication attempt originates from a different IP address than the target server’s IP, indicating the relay.
If successful, the attacker gains unauthorized access to the service and can execute commands or access data with the privileges of the target server’s computer account.
The attacker leverages the compromised computer account to move laterally within the network, potentially gaining access to sensitive resources or escalating privileges further.

Impact

A successful NTLM relay attack can allow attackers to gain control of critical systems and data. By compromising a computer account, attackers can move laterally within the network, access sensitive information, and potentially disrupt business operations. The number of victims and the extent of the damage can vary depending on the scope of the attacker’s activities after compromising the computer account. Organizations in any sector that rely on Windows networks and Active Directory are vulnerable. Failure to detect and prevent these attacks can lead to significant financial losses, reputational damage, and regulatory penalties.

Recommendation

Enable and monitor Windows Security Event Logs, specifically for Event IDs 5145 (File Share access), 4624 (Successful Logon), and 4625 (Failed Logon), as these are crucial for detecting NTLM relay attempts.
Deploy the Sigma rules provided in this brief to your SIEM to detect potential NTLM relay attacks based on the sequence of file access and authentication events.
Investigate any alerts generated by the Sigma rules, focusing on the source and target of the authentication events, the named pipes accessed, and any follow-on activity.
Review and harden NTLM configuration to mitigate relay attacks, and consider disabling NTLM where possible in favor of more secure authentication protocols like Kerberos.
Enable SMB signing and Extended Protection for Authentication to prevent NTLM relay attacks.
Implement network segmentation and access controls to limit the scope of potential NTLM relay attacks.
Apply the “Setup” configurations by enabling the recommended Windows audit policies to ensure the events required by the rules are generated.