Dell — CraftedSignal Threat Feed

Account Discovery Command via SYSTEM Account

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

This detection rule identifies instances where the SYSTEM account is used to execute account discovery utilities, such as whoami.exe and net1.exe. This behavior is commonly observed after an attacker has successfully achieved privilege escalation within a Windows environment, or after exploiting a web application. The rule is designed to detect post-exploitation discovery activity where an adversary attempts to gain situational awareness by enumerating accounts and system information using the elevated SYSTEM context. The rule leverages data from Elastic Defend and Sysmon Event ID 1 to identify these behaviors, helping defenders spot potential privilege escalation and lateral movement attempts. The original rule was created 2020/03/18 and updated 2026/05/04.

Attack Chain

An attacker gains initial access to a system, potentially through exploiting a vulnerability in a web application or through phishing.
The attacker escalates privileges to the SYSTEM account, possibly by exploiting a local privilege escalation vulnerability.
The attacker executes whoami.exe or net1.exe via the SYSTEM account to enumerate user accounts and gather system information.
The whoami.exe or net1.exe process is spawned by a parent process such as a web server process (e.g., w3wp.exe) or a service process.
The attacker uses the discovered account information to plan further actions, such as lateral movement or credential theft.
The attacker may use net1.exe to query domain information.
The attacker leverages the gained information to identify valuable targets within the network.
The final objective is often data exfiltration, deployment of ransomware, or further compromise of the network.

Impact

A successful attack can lead to unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration or ransomware deployment. Although this rule has low severity, the execution of discovery commands by the SYSTEM account can be a critical indicator of compromise. Early detection of such activity can prevent more severe damage.

Recommendation

Deploy the provided Sigma rules to detect account discovery commands executed via the SYSTEM account and tune for your environment.
Enable Sysmon process creation logging (Event ID 1) to ensure the necessary data is available for detection.
Investigate any alerts generated by these rules, focusing on the process execution chain to identify the source of the SYSTEM account usage.
If the process tree includes a web-application server process, investigate suspicious file creation or modification to assess for webshell backdoors.
Review and harden web application security to prevent initial access and privilege escalation.

Network Logon Provider Registry Modification

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

Attackers may modify the network logon provider registry to gain persistence or access credentials. This involves registering a rogue network logon provider module that intercepts authentication credentials in clear text during user logon. The modification of the ProviderPath key under the NetworkProvider service registry path can be indicative of this malicious activity. The registry modification is often performed by non-system accounts and the adversary will attempt to hide the malicious DLL by placing it in common directories. This technique allows adversaries to steal user credentials or maintain persistent access to the compromised system.

Attack Chain

An attacker gains initial access to a Windows system, possibly through exploiting a vulnerability or using compromised credentials.
The attacker elevates privileges to obtain the necessary permissions to modify the registry.
The attacker locates the registry key related to network logon providers: HKLM\SYSTEM\CurrentControlSet\Services\*\NetworkProvider\ProviderPath.
The attacker modifies the ProviderPath registry value to point to a malicious DLL.
The system loads the malicious DLL during the logon process.
The malicious DLL intercepts user credentials in clear text.
The attacker harvests the intercepted credentials.
The attacker uses the harvested credentials for lateral movement or further exploitation of the network.

Impact

A successful attack can lead to the compromise of user credentials, allowing attackers to gain unauthorized access to sensitive systems and data. Modification of the network logon provider registry enables attackers to maintain persistent access to the compromised system, even after a reboot. This can result in data breaches, financial losses, and reputational damage. The severity depends on the level of access granted to the compromised accounts and the sensitivity of the data they can access.

Recommendation

Monitor registry modifications to the HKLM\SYSTEM\CurrentControlSet\Services\*\NetworkProvider\ProviderPath key, using the provided Sigma rule to detect suspicious changes.
Enable Sysmon registry event logging to capture registry modifications.
Regularly audit network logon providers and verify the integrity and authenticity of the registered DLLs.
Investigate processes modifying the registry and their associated file creation events for unknown or suspicious processes.
Block execution of unsigned or untrusted DLLs in the network logon provider path.
Deploy the Sigma rule “Network Logon Provider Registry Modification” to your SIEM and tune for your environment.

LSASS Loading Suspicious DLL

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

The Local Security Authority Subsystem Service (LSASS) is a critical Windows component that manages security policies and user authentication. Attackers often target LSASS to dump credentials, using techniques like injecting malicious DLLs. This detection focuses on identifying instances where LSASS loads a DLL that is either unsigned or not signed by a trusted vendor. The rule excludes known legitimate signatures and file hashes to reduce false positives. This activity is a strong indicator of credential access attempts, potentially leading to further compromise of the system and network. The signatures identified in the rule contain well-known software vendors like Microsoft, McAfee and Citrix.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploiting a vulnerability).
The attacker elevates privileges to gain sufficient access to interact with the LSASS process.
The attacker drops a malicious DLL onto the system, often disguised as a legitimate file.
The attacker injects the malicious DLL into the LSASS process using techniques like Reflective DLL Injection.
LSASS loads the injected DLL, granting the attacker access to sensitive credentials stored in memory.
The malicious DLL dumps credentials, such as plaintext passwords or NTLM hashes.
The attacker uses the stolen credentials for lateral movement to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation leads to credential compromise, allowing attackers to move laterally within the network, access sensitive data, and potentially achieve complete domain dominance. This can result in data breaches, financial losses, and reputational damage. The impact depends on the level of access associated with the compromised credentials.

Recommendation

Deploy the LSASS Loading Untrusted DLL Sigma rule to your SIEM to detect suspicious DLLs loaded by LSASS.
Investigate any alerts generated by the Sigma rule and review the loaded DLL’s code signature and hash.
Block the identified SHA256 hashes listed in the IOC table to prevent the execution of known malicious DLLs.
Implement application whitelisting to restrict which DLLs can be loaded into LSASS.
Enable Sysmon process creation and image load logging to provide the necessary data for detection.