Windows Defender — CraftedSignal Threat Feed

Windows Defender Disabled via Registry Modification

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

Attackers commonly disable Windows Defender to evade detection and facilitate malicious activities. This involves modifying specific registry settings to either disable the service entirely or prevent it from starting automatically. The rule specifically identifies modifications to the DisableAntiSpyware and WinDefend\\Start registry keys. The DFIR Report has documented this technique in real-world incidents, highlighting its effectiveness in bypassing built-in security measures. This allows threat actors to operate with reduced risk of detection, enabling them to deploy malware, exfiltrate data, or perform other malicious actions without immediate interference from the endpoint security solution.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing or exploiting a software vulnerability.
The attacker elevates privileges to obtain the necessary permissions to modify the registry.
The attacker modifies the HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware registry key to disable Windows Defender, setting its value to “1” or “0x00000001”.
Alternatively, the attacker modifies the HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start registry key to prevent the Windows Defender service from starting automatically. The attacker sets the value to “3” or “4” (or their hexadecimal equivalents “0x00000003”, “0x00000004”).
The attacker verifies that Windows Defender is disabled by checking the Security Center or attempting to run a scan.
With Windows Defender disabled, the attacker proceeds to deploy malware or execute malicious commands without interference from the antivirus software.
The attacker may further disable security settings and block security-related indicators.

Impact

If successful, this attack can lead to a complete compromise of the affected system. With Windows Defender disabled, the system becomes vulnerable to malware infections, data exfiltration, and other malicious activities. This can result in financial losses, data breaches, and reputational damage for the targeted organization. The lack of immediate detection allows attackers to establish persistence and expand their foothold within the network.

Recommendation

Deploy the Sigma rule “Registry Modification to Disable Windows Defender” to your SIEM and tune for your environment to detect unauthorized changes to Windows Defender registry settings.
Monitor registry events for changes to the HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware and HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start registry keys using the provided log sources.
Investigate any alerts generated by the Sigma rule, focusing on identifying the process and user account responsible for the registry modifications.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rule to function effectively.

Disabling Windows Defender Security Settings via PowerShell

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

Attackers commonly attempt to disable or weaken Windows Defender to evade detection and facilitate malicious activities. This involves using PowerShell commands like Set-MpPreference or Add-MpPreference to modify Defender’s configuration. Adversaries may also utilize base64 encoding to obfuscate these commands, bypassing simple command-line inspection. This activity typically occurs post-compromise, as part of a broader attack chain, and allows for the deployment of malware or other malicious tools without interference from the built-in antivirus. Detection of these techniques is crucial for maintaining the integrity of the system and preventing further damage. The scope of this threat includes any Windows environment where PowerShell is enabled and Windows Defender is used as the primary antivirus solution.

Attack Chain

Initial access is achieved through an existing compromise (e.g., phishing, exploit).
The attacker gains a foothold on the system and escalates privileges if necessary.
PowerShell is launched, either directly or through a parent process like cmd.exe.
The attacker uses Set-MpPreference or Add-MpPreference with parameters like -DisableRealtimeMonitoring, -DisableIOAVProtection, -DisableBehaviorMonitoring, or -DisableBlockAtFirstSeen to weaken Defender.
Alternatively, the attacker crafts a base64-encoded PowerShell command that performs the same actions.
The encoded command is executed using the -EncodedCommand or -enc parameter.
Windows Defender’s security settings are modified, reducing its effectiveness.
The attacker proceeds with deploying malware, exfiltrating data, or other malicious objectives.

Impact

Successful execution of these commands results in a weakened or disabled Windows Defender, leaving the system vulnerable to malware infections and other threats. This can lead to data breaches, system compromise, and financial loss. The impact is especially significant in environments where Windows Defender is the primary security solution. While the number of victims is unknown, the technique is widely applicable across Windows environments.

Recommendation

Monitor process creation events for PowerShell executions (powershell.exe, pwsh.exe) with command-line arguments related to disabling Windows Defender using the Sigma rule “Detect Suspicious PowerShell Encoded Commands”.
Enable PowerShell script block logging to capture the full content of executed scripts, which can reveal base64-encoded commands (reference: references - https://docs.microsoft.com/en-us/powershell/module/defender/set-mppreference?view=windowsserver2019-ps).
Deploy the Sigma rule “Disabling Windows Defender Security Settings via PowerShell” to your SIEM and tune for your environment.
Investigate any instances of Set-MpPreference or Add-MpPreference commands with arguments disabling real-time monitoring, IOAV protection, behavior monitoring, or block-at-first-seen features.

Potential RemoteMonologue Attack via Registry Modification

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

The RemoteMonologue attack technique abuses Component Object Model (COM) objects to coerce authentication from a remote system. This is achieved by modifying the RunAs registry value associated with a COM object. Setting this value to “Interactive User” forces the COM object to run under the context of the interactive user, enabling attackers to hijack sessions and potentially escalate privileges. This technique is often used as a defense evasion or persistence mechanism by adversaries after gaining initial access to a system. The attack involves modifying registry keys associated with COM objects to trigger NTLM authentication coercion. This can be used for lateral movement and gaining access to sensitive resources. This rule is designed to detect registry modifications indicative of the RemoteMonologue attack.

Attack Chain

Initial Access: An attacker gains initial access to the target system through unspecified means.
Identify COM Objects: The attacker identifies suitable COM objects for abuse.
Modify Registry: The attacker modifies the registry to set the RunAs value for the selected COM object to Interactive User. This involves modifying the registry path HKCR\AppID\{Clsid}\RunAs.
Trigger COM Object Execution: The attacker triggers the execution of the modified COM object, potentially through a remote procedure call or other inter-process communication mechanisms.
Authentication Coercion: The execution of the COM object triggers NTLM authentication to a system controlled by the attacker.
Relay Attack: The attacker relays the coerced NTLM authentication to gain access to other resources on the network.
Session Hijacking: Successful relay leads to session hijacking, allowing the attacker to impersonate the user.
Lateral Movement/Privilege Escalation: The attacker uses the hijacked session for lateral movement or privilege escalation within the network.

Impact

A successful RemoteMonologue attack can lead to unauthorized access to sensitive systems and data. By coercing authentication and hijacking sessions, attackers can bypass security controls and escalate their privileges within the network. The scope of the impact depends on the privileges of the hijacked user account and the resources accessible to that account. This attack can enable lateral movement, data exfiltration, and other malicious activities.

Recommendation

Deploy the Sigma rule Detect RemoteMonologue Registry Modification to your SIEM to identify suspicious registry modifications related to COM object hijacking.
Enable Sysmon registry event logging to capture the necessary data for the Sigma rules to function effectively.
Investigate any alerts generated by the Sigma rule by reviewing the registry event logs and identifying the user account and process responsible for the registry modification.
Implement enhanced monitoring on critical systems to detect any attempts to modify COM object registry settings.
Block the attack by ensuring “RunAs” value is not set to “Interactive User”.

Suspicious Microsoft Antimalware Service Executable Execution

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

This detection identifies suspicious execution of the Microsoft Antimalware Service Executable (MsMpEng.exe) from non-standard paths or renamed instances. Attackers may attempt to evade defenses through DLL side-loading or by masquerading as the antimalware process. This technique is used to blend in with legitimate system activity and avoid detection by security tools. This rule is designed to detect instances where MsMpEng.exe is executed from unexpected locations or has been renamed, potentially indicating malicious activity. The rule leverages process monitoring data to identify deviations from the expected execution patterns of the antimalware service. This behavior has been seen associated with ransomware attacks, such as REvil.

Attack Chain

An attacker gains initial access to the system, potentially through phishing or exploiting a vulnerability.
The attacker drops a malicious payload onto the system, placing it in a non-standard directory, such as a temporary folder or a user’s profile directory.
The attacker renames or copies the legitimate MsMpEng.exe to the malicious payload’s location.
The attacker executes the renamed or copied MsMpEng.exe from the non-standard location. This is intended to mimic legitimate activity and evade detection.
The malicious MsMpEng.exe then loads a malicious DLL through DLL side-loading, which executes arbitrary code within the context of the antimalware process.
The malicious code performs actions such as disabling security controls, escalating privileges, or establishing persistence.
The attacker leverages the compromised system to move laterally within the network, compromising additional systems.
The attacker achieves their final objective, such as data exfiltration or ransomware deployment.

Impact

Successful exploitation can lead to complete system compromise, including the disabling of security controls, data theft, and ransomware deployment. This can result in significant financial losses, reputational damage, and disruption of business operations. Identifying and responding to this type of attack is critical to prevent further damage. The Sophos article references the REvil ransomware attack which impacted hundreds of businesses.

Recommendation

Enable Sysmon process creation logging (Event ID 1) to capture process execution events, including image path and command-line arguments, which are essential for detecting this behavior.
Deploy the Sigma rules provided in this brief to your SIEM to detect suspicious MsMpEng.exe execution from unusual paths or renamed instances.
Investigate any alerts generated by these rules to determine the legitimacy of the MsMpEng.exe execution and identify any potential malicious activity.
Monitor process execution events for instances where the process name is “MsMpEng.exe” but the executable path is outside the standard Windows Defender or Microsoft Security Client directories.
Review the references provided for additional context and guidance on investigating this type of activity.

Suspicious LSASS Process Access

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

The Local Security Authority Subsystem Service (LSASS) is a critical Windows component responsible for enforcing security policies and handling user authentication. Attackers often target LSASS to extract credentials, enabling unauthorized access and privilege escalation. This detection rule identifies suspicious access attempts to LSASS memory, which may indicate credential dumping activities. It filters out common legitimate processes and access patterns to highlight anomalous behaviors associated with credential theft. The rule is designed to detect unauthorized access attempts by monitoring process access events and filtering out known benign processes that interact with LSASS. It helps defenders identify potential credential access attempts before they lead to significant compromise.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploitation of a vulnerability.
The attacker executes a malicious process or script on the compromised system.
The malicious process attempts to gain a handle to the LSASS process.
The attacker’s tool requests specific access rights to LSASS, such as ReadProcessMemory (0x0010) or PROCESS_QUERY_INFORMATION (0x0400), which are necessary for memory dumping.
The attacker’s process bypasses or disables endpoint detection and response (EDR) solutions to avoid detection.
The tool dumps the LSASS memory, extracting sensitive information like usernames, passwords, and Kerberos tickets.
The attacker uses the extracted credentials to move laterally within the network, accessing other systems and resources.
The attacker achieves their objective, such as data exfiltration or deployment of ransomware.

Impact

A successful LSASS memory dump can lead to the compromise of domain credentials, allowing attackers to move laterally within the network and gain access to sensitive data and systems. This can result in data breaches, financial loss, and reputational damage. Organizations across all sectors are vulnerable, particularly those with weak credential management practices. A single compromised account can lead to widespread damage, potentially affecting thousands of systems.

Recommendation

Enable Sysmon process access event logging (Event ID 10) as described in the setup instructions linked in the rule to collect the necessary data.
Deploy the Sigma rule “Suspicious Lsass Process Access” to your SIEM and tune the exclusions based on your environment to reduce false positives.
Review and harden privileged account management practices to limit the impact of credential compromise.
Monitor systems for unusual process creation events, especially those spawning from unexpected locations, to identify potential initial access points.
Regularly scan systems for vulnerabilities and apply patches to prevent exploitation.

MpCmdRun.exe Used for Remote File Download

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

Attackers are leveraging the built-in Windows Defender command-line utility, MpCmdRun.exe, to download files from remote locations. This technique allows attackers to bypass traditional download restrictions and blend in with legitimate system activity. The MpCmdRun.exe utility is normally used to manage Windows Defender settings and perform tasks such as signature updates and scans. However, its -DownloadFile parameter can be abused to download arbitrary files from a specified URL. This activity was first publicly reported around September 2020. Defenders should monitor for unusual usage patterns of MpCmdRun.exe, especially those involving command-line arguments related to file downloads from external sources.

Attack Chain

An attacker gains initial access to a target system through an unrelated vulnerability or existing compromise.
The attacker uses MpCmdRun.exe to download a file from a remote server. The command includes arguments like -DownloadFile, -url, and -path to specify the download location and save path.
The downloaded file is saved to a location on the compromised system.
The attacker executes the downloaded file. This could be a malicious executable, a script, or a configuration file.
The executed file performs further malicious actions on the system, such as establishing persistence, escalating privileges, or deploying additional payloads.
The attacker uses the compromised system as a foothold to move laterally within the network, compromising other systems and resources.
The attacker achieves their ultimate objective, such as data exfiltration, ransomware deployment, or disruption of services.

Impact

Successful exploitation allows attackers to introduce arbitrary malicious code into the system, potentially leading to a wide range of adverse effects, including data theft, system compromise, and disruption of operations. While individual cases may be limited in scope, widespread exploitation could impact numerous organizations, resulting in significant financial losses and reputational damage. The use of a trusted system utility makes this technique harder to detect using traditional methods.

Recommendation

Deploy the Sigma rule MpCmdRun Remote File Download to your SIEM to detect the malicious use of MpCmdRun.exe for downloading files.
Enable Sysmon process creation logging with command-line arguments to provide the necessary data for the Sigma rule to function.
Review historical process execution logs for instances of MpCmdRun.exe being used with the -DownloadFile parameter.
Implement application control policies to restrict the execution of unsigned or untrusted executables downloaded by MpCmdRun.exe.

Disabling Windows Defender Security Settings via PowerShell

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Attackers frequently attempt to disable or weaken Windows Defender to facilitate the execution of malware and other malicious activities. This is often achieved through the use of PowerShell commands like Set-MpPreference and Add-MpPreference, which can modify various Defender settings. To evade detection, adversaries may encode these commands using Base64, making it more difficult for traditional command-line inspection techniques to identify the malicious intent. This activity is a common tactic in post-exploitation scenarios, allowing attackers to operate with reduced risk of being detected by the built-in antivirus solution. Detection of this behavior is critical for identifying and responding to potential intrusions. The Elastic detection rule aims to catch both standard and encoded PowerShell commands used for this purpose.

Attack Chain

An attacker gains initial access to a Windows system through methods such as phishing or exploiting a vulnerability.
The attacker elevates privileges to gain necessary permissions to modify Windows Defender settings.
The attacker uses the powershell.exe process to execute commands.
The attacker uses Set-MpPreference or Add-MpPreference to disable real-time monitoring.
The attacker may use Base64 encoding (e.g., using the -EncodedCommand parameter) to obfuscate the PowerShell commands.
The encoded command is executed, modifying Windows Defender settings.
Windows Defender’s real-time monitoring is disabled, allowing the attacker to execute malicious payloads without immediate detection.
The attacker proceeds with their objectives, such as deploying ransomware or exfiltrating data.

Impact

Successful disabling of Windows Defender can lead to a significant increase in the risk of malware infection and data breach. With real-time protection disabled, the system becomes vulnerable to various threats, including ransomware, Trojans, and other malicious software. This can result in data loss, system compromise, and potential financial damages. The impact can be severe, especially if the compromised system handles sensitive information or is critical to business operations.

Recommendation

Deploy the Sigma rule “Disabling Windows Defender Security Settings via PowerShell” to your SIEM and tune for your environment.
Enable PowerShell Script Block Logging to gain better visibility into the commands being executed (referenced in Sysmon setup instructions).
Monitor process creation events for PowerShell processes executing commands with -EncodedCommand or containing specific Base64 encoded strings to detect obfuscated attempts to disable Windows Defender.
Investigate any instances of Set-MpPreference or Add-MpPreference being used, especially if accompanied by unusual parent processes or command-line arguments.