https://feed.craftedsignal.io/tags/attack.t1562.002/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 09 Jan 2024 14:22:00 +0000https://feed.craftedsignal.io/briefs/2024-01-autologger-disable/Tue, 09 Jan 2024 14:22:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-autologger-disable/Adversaries may attempt to disable Windows EventLog autologger sessions via registry modification to evade detection and prevent security monitoring of early boot activities and system events.Attackers may disable Windows EventLog autologger sessions by modifying specific registry keys, thus evading detection and preventing security monitoring of early boot activities and system events. The AutoLogger event tracing session records events early in the operating system boot process, allowing applications and device drivers to capture traces before user login. Disabling these sessions can blind security monitoring tools, especially those focused on early boot activity, making it harder to detect malicious activity. This technique allows attackers to operate with less scrutiny during critical phases of system startup, potentially enabling persistence or other malicious objectives.

Attack Chain

1. The attacker gains initial access to the system, possibly through exploitation of a vulnerability or through stolen credentials.
2. The attacker uses reg.exe or PowerShell to modify the registry.
3. The attacker targets registry keys under \Control\WMI\Autologger\.
4. The attacker modifies the Start value to disable specific autologger sessions like EventLog-Application or EventLog-System.
5. Alternatively, the attacker modifies the Enabled value to disable specific providers of an autologger session.
6. The attacker executes the command, changing the registry value to disable the targeted autologger session or provider.
7. The system no longer records events for the disabled autologger session or provider.

Impact

Disabling the Windows EventLog autologger can severely impact an organization’s ability to detect and respond to threats. Security monitoring tools that rely on these logs will be unable to record early boot activities and system events, leading to a gap in visibility. This can allow attackers to establish persistence mechanisms, escalate privileges, or perform other malicious activities without being detected. The impact could range from undetected malware infections to significant data breaches, depending on the attacker’s objectives.

Recommendation

• Deploy the Sigma rule Windows EventLog Autologger Session Registry Modification Via CommandLine to your SIEM and tune for your environment to detect this behavior in your environment.
• Monitor process creation events for reg.exe, powershell.exe, or pwsh.exe with command-line arguments that contain \Control\WMI\Autologger\ and either Start or Enabled based on the Sigma rule’s detections.
• Implement Atomic Red Team simulations to validate detections and train security staff.
• Investigate any instances of registry modifications related to Autologger sessions to determine if they are legitimate or malicious.

]]>highadvisoryattack.defense-evasionattack.t1562.002https://feed.craftedsignal.io/briefs/2024-01-autologger-tampering/Wed, 03 Jan 2024 15:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-autologger-tampering/Attackers may disable AutoLogger sessions by modifying specific registry values to evade detection and prevent security monitoring of early boot activities and system events, a technique observed in intrusions involving IcedID and XingLocker ransomware.Attackers are increasingly targeting Windows Event Tracing (ETW) and AutoLogger sessions to evade detection. The AutoLogger session is crucial as it records events early in the operating system boot process, providing security solutions with essential telemetry. This technique involves tampering with registry keys associated with AutoLogger sessions, specifically disabling or stopping them by setting DWORD values to 0. This is done to blind security solutions, preventing them from monitoring early boot activities and critical system events. Disabling these sessions allows adversaries to operate with less scrutiny, making it harder to detect malicious activities during the initial phases of a system compromise. This technique has been observed in attacks involving IcedID and XingLocker ransomware.

Attack Chain

1. Initial access is achieved through an as-yet-unspecified method (e.g., exploitation, phishing).
2. The attacker gains administrative privileges on the target system.
3. The attacker identifies AutoLogger sessions to disable, focusing on those relevant to security monitoring, such as ‘\EventLog-’ or ‘\Defender’.
4. The attacker modifies the registry to disable the targeted AutoLogger sessions. This involves setting the ‘Enabled’ or ‘Start’ DWORD values under the HKLM\System\CurrentControlSet\Control\WMI\Autologger registry key to 0.
5. The attacker may use tools like wevtutil.exe or directly interact with the registry via PowerShell or cmd.exe to make these changes.
6. The security monitoring capabilities reliant on the tampered AutoLogger sessions are effectively impaired or disabled.
7. With logging impaired, the attacker proceeds with the main objectives, such as lateral movement, data exfiltration, or ransomware deployment, with a reduced risk of detection.
8. The ultimate goal is to compromise the system, steal data, or deploy ransomware, bypassing security measures that rely on early boot and system event logging.

Impact

Successful tampering with AutoLogger sessions can significantly reduce the visibility of security solutions, allowing attackers to operate undetected for extended periods. This can lead to delayed incident response, increased dwell time, and greater potential for damage, including data breaches, financial losses, and reputational damage. The sectors most at risk are those heavily reliant on Windows-based systems and proactive security monitoring. The DFIR Report documented a case where adversaries moved from IcedID infection to XingLocker ransomware deployment within 24 hours, highlighting the speed and potential impact of these attacks.

Recommendation

• Deploy the Sigma rule Potential AutoLogger Sessions Tampering to your SIEM to detect malicious registry modifications related to AutoLogger sessions.
• Investigate any registry modifications under the \Control\WMI\Autologger\ path, focusing on changes to Enabled or Start values, as identified in the Sigma rule.
• Monitor process creation events for wevtutil.exe modifying registry keys related to AutoLogger, as specified in the filter_main_wevtutil section of the Sigma rule.
• Correlate registry modification events with process execution events to identify the source of the tampering, paying close attention to processes originating from the Windows Defender platform, as outlined in the filter_main_defender section of the Sigma rule.
• Implement endpoint detection and response (EDR) solutions with robust registry monitoring capabilities to identify and block unauthorized modifications to AutoLogger settings.

]]>highthreatattack.defense-evasionattack.t1562.002