Defender — CraftedSignal Threat Feed

Windows Defender Throttle Rate Modification

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

This brief addresses the modification of the ThrottleDetectionEventsRate registry setting within Windows Defender. Attackers may alter this setting to decrease the frequency of logged detection events, effectively reducing the visibility of their malicious activities. This technique can be employed to evade detection and prolong the duration of a compromise. Disabling or reducing the throttle rate can hinder incident response efforts and forensic investigations by limiting the amount of security-related data available to defenders. Defenders should be aware of unauthorized changes to this registry setting to maintain optimal security monitoring.

Attack Chain

Initial Access: The attacker gains access to the system via various means (e.g., compromised credentials, phishing).
Privilege Escalation: The attacker escalates privileges to gain administrative access, required to modify registry settings.
Defense Evasion: The attacker attempts to disable or modify Windows Defender settings.
Registry Modification: The attacker modifies the ThrottleDetectionEventsRate registry value located at *\\Windows Defender\\NIS\\Consumers\\IPS\\ThrottleDetectionEventsRate. This is often done using command-line tools like reg.exe or PowerShell.
Persistence: The attacker may establish persistence to maintain access even after system reboots. While not directly related to the throttle rate modification, it ensures continued access for further malicious actions.
Lateral Movement: The attacker moves laterally to other systems within the network, potentially repeating the registry modification process on other endpoints.
Data Exfiltration/Ransomware Deployment: With reduced visibility due to the modified throttle rate, the attacker exfiltrates sensitive data or deploys ransomware.
Impact: The attack succeeds due to the reduced visibility, leading to data loss, financial damage, or system compromise.

Impact

Successful modification of the ThrottleDetectionEventsRate can lead to a significant reduction in the effectiveness of Windows Defender, allowing attackers to operate with reduced scrutiny. This can result in delayed detection of malicious activity, leading to increased dwell time and greater potential for damage. The number of affected systems depends on the scope of the attacker’s access and lateral movement capabilities. Targeted sectors could include any organization relying on Windows Defender as a primary endpoint security solution.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect modifications to the ThrottleDetectionEventsRate registry setting.
Monitor Sysmon Event ID 13 (registry events) for changes to Windows Defender registry keys.
Investigate any alerts generated by the Sigma rule, prioritizing those affecting critical systems or users.
Use the filter macro (windows_impair_defense_change_win_defender_throttle_rate_filter) to tune the provided search to reduce false positives in your specific environment.
Regularly review and audit Windows Defender configuration settings to ensure they align with security best practices.

Windows Defender Exclusion Registry Modification

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

Attackers frequently attempt to disable or bypass Windows Defender to execute malware undetected. This is often achieved by modifying the Windows Defender exclusion registry entries. By adding exclusions, attackers can prevent Windows Defender from scanning specific files, folders, or processes. This technique allows malware to operate freely, potentially leading to system compromise. The reported activity focuses on modifications to the registry path “\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\”, which is a common target for threat actors. This technique can be observed across various malware families, including Remcos RAT, Qakbot, and XWorm, as well as in NetSupport RMM Tool Abuse scenarios, highlighting its versatility and effectiveness in defense evasion. Detecting and preventing these modifications is crucial for maintaining endpoint security.

Attack Chain

Initial access is gained through various methods (not specified in source).
The attacker elevates privileges to gain necessary permissions (not specified in source).
The attacker modifies the registry key HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\ or similar paths.
Specifically, the attacker adds or modifies registry values within the Exclusions key to exclude specific files, folders, or processes from Windows Defender scanning.
The attacker verifies the successful creation or modification of the exclusion by querying the registry.
Malicious code is then executed in the excluded location or process, bypassing Windows Defender’s real-time scanning.
The attacker maintains persistence by ensuring the exclusion remains active across reboots.
The attacker performs further malicious activities, such as data exfiltration or lateral movement, undetected by Windows Defender.

Impact

Successful modification of Windows Defender exclusion registry entries allows attackers to bypass antivirus protection. This can lead to the execution of malicious code without detection, enabling persistence, data exfiltration, and other malicious activities. The impact can range from individual system compromise to broader network infections, depending on the attacker’s objectives. Several malware families, including Remcos RAT, Qakbot, and XWorm, use this technique, demonstrating its widespread use. A Microsoft blog post referenced destructive malware targeting Ukrainian organizations, suggesting potential for significant operational disruption.

Recommendation

Enable Sysmon Event ID 13 (RegistryEvent) to capture registry modifications, which is the data source required for the detections.
Deploy the Sigma rule Detect Windows Defender Exclusion Added to identify suspicious registry modifications related to Windows Defender exclusions.
Investigate any alerts generated by the Sigma rule, focusing on processes modifying the Windows Defender exclusion registry keys.
Review and audit existing Windows Defender exclusions to identify any unauthorized or suspicious entries.
Ensure the Sysmon TA is at least version 2.0 as mentioned in the content to properly ingest the logs from endpoints.

Windows Defender BlockAtFirstSeen Feature Disabled via Registry Modification

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

This threat brief addresses the disabling of the Windows Defender BlockAtFirstSeen feature through registry modification. The BlockAtFirstSeen feature provides initial protection against new and unknown threats. Attackers may disable this feature to bypass these initial detection mechanisms, increasing the likelihood of successful malware execution and subsequent system compromise. The analytic detects modifications to the DisableBlockAtFirstSeen registry value under the Microsoft\Windows Defender\SpyNet path. The activity is significant because it weakens the endpoint’s security posture, creating an opportunity for malware to execute undetected. Observed in attacks such as IcedID, this technique can lead to ransomware deployment and data breaches.

Attack Chain

Initial access is gained through methods such as phishing or exploitation of vulnerabilities.
The attacker executes code on the target system.
The attacker identifies the registry key associated with Windows Defender SpyNet: HKLM\SOFTWARE\Microsoft\Windows Defender\SpyNet.
The attacker modifies the DisableBlockAtFirstSeen value within the SpyNet registry key.
The DisableBlockAtFirstSeen value is set to 0x00000001 to disable the feature.
Windows Defender no longer blocks the execution of files based on reputation.
The attacker executes malicious payloads that would normally be blocked.
The attacker achieves their objective, such as deploying ransomware, exfiltrating data, or establishing persistence.

Impact

Disabling the BlockAtFirstSeen feature significantly reduces the effectiveness of Windows Defender, potentially exposing systems to new and unknown malware threats. Successful exploitation can lead to malware infection, system compromise, data breaches, and ransomware deployment. The DFIR Report has observed this technique being used in conjunction with IcedID leading to Xinglocker ransomware deployment.

Recommendation

Deploy the Sigma rule Registry Modification to Disable BlockAtFirstSeen to your SIEM to detect this specific registry modification.
Enable Sysmon Event ID 13 (Registry Event) logging to collect the necessary data for the Sigma rules.
Investigate any detected instances of DisableBlockAtFirstSeen registry value modification, prioritizing those occurring on critical systems.
Enforce strict access control policies to prevent unauthorized modification of registry settings.
Monitor systems for signs of malware infection following any detected attempts to disable the BlockAtFirstSeen feature.

Windows Defender Health Check Interval Modification

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

Attackers may attempt to disable or delay security scans by modifying the health check interval of Windows Defender. This is achieved by altering the ServiceKeepAlive registry value. The modifications can prevent the timely detection of malware or other malicious activities, thereby increasing the risk to the system. The observed registry key path is *\\Windows Defender\\ServiceKeepAlive with the specific registry value data being 0x00000001. This technique has been observed in the wild, as reported on X (formerly Twitter), and is also a focus of privacy-enhancing tools like privacy.sexy. This highlights the importance of monitoring registry modifications related to Windows Defender’s configuration.

Attack Chain

Attacker gains initial access to the system (e.g., through phishing or exploiting a vulnerability).
The attacker executes a process with elevated privileges (e.g., using sudo or exploiting a privilege escalation vulnerability).
The process modifies the Windows Registry, specifically targeting the HKLM\SOFTWARE\Microsoft\Windows Defender\ServiceKeepAlive key.
The registry_value_data is set to 0x00000001, which may disable or delay health checks.
Windows Defender health checks are impaired, reducing the frequency or effectiveness of scans.
Malware or malicious activity remains undetected due to the reduced scan frequency.
The attacker maintains persistence and further compromises the system, potentially leading to data theft or ransomware deployment.

Impact

Successful modification of Windows Defender health check intervals can lead to a significant decrease in the system’s ability to detect and respond to threats. This can result in undetected malware infections, data breaches, and system compromise. While the number of direct victims is unknown, the widespread use of Windows Defender makes this a potentially impactful technique across various sectors.

Recommendation

Deploy the Sigma rule Registry Modification of Windows Defender Health Check Interval to your SIEM to detect malicious registry changes.
Monitor Sysmon EventID 13 events for registry modifications related to Windows Defender’s ServiceKeepAlive key.
Investigate any alerts generated by the Sigma rule, paying close attention to the dest and process_guid fields.
Use the provided references to understand the context of this technique in real-world attacks.
Tune the provided filter macro windows_impair_defense_change_win_defender_health_check_intervals_filter to minimize false positives in your environment.