Attack.defense-Evasion — CraftedSignal Threat Feed

Linux Service Stop and Disable Detection

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

Attackers may attempt to stop or disable services on a compromised Linux system to impair security tools, disrupt operations, or facilitate further malicious activities. This can involve disabling security software, logging mechanisms, or other critical services that could hinder the attacker’s objectives. This activity often forms part of a broader attack campaign aimed at maintaining persistence, evading detection, or causing system-wide disruption. The commands systemctl, service, and…

Windows EventLog Autologger Session Disabled via Registry Modification

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

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

The attacker gains initial access to the system, possibly through exploitation of a vulnerability or through stolen credentials.
The attacker uses reg.exe or PowerShell to modify the registry.
The attacker targets registry keys under \Control\WMI\Autologger\.
The attacker modifies the Start value to disable specific autologger sessions like EventLog-Application or EventLog-System.
Alternatively, the attacker modifies the Enabled value to disable specific providers of an autologger session.
The attacker executes the command, changing the registry value to disable the targeted autologger session or provider.
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.

Cisco 802.1X (dot1x) Disabled on Network Interface

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

The disabling of 802.1X authentication on a Cisco network device can bypass Network Access Control (NAC) mechanisms, potentially granting unauthorized devices access to the internal network. Attackers or malicious insiders might disable dot1x to establish persistence or facilitate lateral movement by connecting rogue devices to the network. This can be accomplished through CLI commands such as ‘access-session port-control force-authorized’ or ’no dot1x system-auth-control’, depending on the IOS version. These commands either disable 802.1X on a specific interface or globally across the device. The targeted scope is Cisco network devices utilizing 802.1X for network access control.

Attack Chain

Attacker gains privileged access to a Cisco network device via compromised credentials or exploiting a vulnerability.
Attacker executes CLI commands to disable 802.1X authentication on a specific interface or globally.
Commands used may include ‘access-session port-control force-authorized’, ‘authentication port-control force-authorized’, ‘dot1x port-control force-authorized’, ’no access-session port-control’, ’no authentication port-control’, ’no dot1x port-control’, or ’no dot1x system-auth-control’.
The network interface transitions to a force-authorized state, bypassing the normal authentication process.
An unauthorized device is connected to the compromised network interface.
The unauthorized device gains network access without proper authentication or authorization.
The attacker leverages the unauthorized access for lateral movement to other systems on the network.
The attacker exfiltrates sensitive data or deploys malicious payloads across the network.

Impact

Successful disabling of dot1x can lead to unauthorized network access, allowing attackers to bypass security controls. This can result in the compromise of sensitive data, the spread of malware, and the disruption of network services. The number of affected devices and the scope of the compromise depend on the network architecture and the attacker’s objectives. The impact could range from a single compromised workstation to a full-scale network breach affecting thousands of devices and users.

Recommendation

Deploy the Sigma rule Cisco Dot1x Disabled to your SIEM to detect the execution of commands that disable 802.1X authentication.
Monitor Cisco AAA logs for events containing keywords such as ‘access-session port-control force-authorized’ and ’no dot1x system-auth-control’ to identify potential attempts to disable dot1x.
Implement multi-factor authentication (MFA) for all administrative access to Cisco network devices to prevent unauthorized command execution.
Regularly review and audit the configuration of Cisco network devices to ensure that 802.1X is enabled and properly configured on all relevant interfaces.

Windows AutoLogger Session Tampering Detection

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

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

Initial access is achieved through an as-yet-unspecified method (e.g., exploitation, phishing).
The attacker gains administrative privileges on the target system.
The attacker identifies AutoLogger sessions to disable, focusing on those relevant to security monitoring, such as ‘\EventLog-’ or ‘\Defender’.
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.
The attacker may use tools like wevtutil.exe or directly interact with the registry via PowerShell or cmd.exe to make these changes.
The security monitoring capabilities reliant on the tampered AutoLogger sessions are effectively impaired or disabled.
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.
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.

Detection of Python One-Liners with Base64 Decoding

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

Attackers frequently leverage Python one-liners with base64 encoding to obfuscate and execute malicious code. This technique bypasses standard security measures by concealing the true nature of the payload. The abuse involves embedding base64-encoded commands within Python scripts, which are then decoded and executed at runtime. While legitimate uses of Python and base64 exist, their combination in a single command line, especially with execution flags, is a strong indicator of malicious activity. This technique has been observed in various attacks, including those originating from fake AI websites, where malicious Python code is injected to perform unauthorized actions. Defenders should monitor for such patterns to identify and neutralize potential threats.

Attack Chain

Initial Access: The attacker gains access to the system, often through social engineering or exploiting a vulnerability.
Payload Delivery: A base64-encoded payload is delivered to the victim machine via email, website, or other means.
Python Invocation: Python is invoked via the command line, often using python.exe or python3.
Import Base64 Module: The import base64 statement is used to load the necessary decoding libraries.
Decoding Execution: The base64-encoded payload is decoded using functions like base64.b64decode() within the Python one-liner using the -c flag for command execution.
Code Execution: The decoded payload is executed in memory, performing malicious actions such as installing malware or establishing persistence.
Lateral Movement: The attacker leverages the compromised system to move laterally within the network, compromising additional systems.
Data Exfiltration/System Damage: The attacker exfiltrates sensitive data or causes damage to the system, depending on their objectives.

Impact

Successful exploitation can lead to complete system compromise, data theft, and potentially, a foothold for lateral movement within the network. The use of base64 encoding significantly hinders detection efforts, allowing attackers to operate undetected for extended periods. If successful, organizations could face data breaches, financial losses, and reputational damage.

Recommendation

Deploy the provided Sigma rule targeting process_creation events on Windows systems to detect Python commands utilizing base64 decoding functions (CommandLine|contains with import base64, b64decode, and -c).
Inspect command-line arguments of Python processes for suspicious base64 decoding patterns (as seen in the detection rule).
Implement application control policies to restrict the execution of unauthorized Python scripts, mitigating potential exploitation attempts.
Enable Sysmon process creation logging to ensure adequate coverage for the provided Sigma rule.

Service Startup Type Modification via WMIC

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

Attackers may leverage WMIC, a legitimate Windows command-line utility, to modify the startup type of services. This tactic is often used to disable security products or critical system services, hindering incident response or creating system instability. By setting services to “Manual” or “Disabled”, adversaries ensure that these services do not automatically start upon system boot, achieving persistence or impeding detection. While WMIC is a built-in tool, its use for modifying service startup types is often indicative of malicious activity, especially when performed on security-related services. This activity may be part of a larger attack chain aimed at deploying ransomware, exfiltrating data, or establishing a persistent presence on the compromised system.

Attack Chain

An attacker gains initial access to the target system, potentially through phishing, exploiting a vulnerability, or compromised credentials.
The attacker executes wmic.exe with specific command-line arguments to interact with Windows services.
The service alias is invoked within WMIC to target specific services.
The ChangeStartMode method is used to modify the startup type of the targeted service.
The attacker sets the startup type to either Manual or Disabled, preventing the service from automatically starting on subsequent reboots.
If the targeted service is a security product, this action effectively disables the defense mechanism.
The attacker proceeds with further malicious activities, such as deploying malware or exfiltrating sensitive data, with reduced resistance.
The compromised system experiences degraded security posture and potential operational disruptions.

Impact

Successful modification of service startup types can severely impact system security and availability. Disabling security software can lead to undetected malware infections and data breaches. Disabling critical system services can cause system instability, data loss, or complete system failure. While the exact number of victims is unknown, this technique is broadly applicable across Windows environments, potentially affecting organizations of any size and in any sector. The impact ranges from minor operational disruptions to significant financial losses due to data breaches and ransomware attacks.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious wmic.exe process creations that attempt to change service startup types.
Investigate any instances where wmic.exe is used to modify service startup types, especially when the targeted services are related to security or critical system functions.
Implement endpoint detection and response (EDR) solutions to provide enhanced visibility into process execution and system modifications.
Regularly review and audit service configurations to identify unauthorized changes.

Suspicious CSC.exe Parent Process

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

Attackers are leveraging the legitimate Csc.exe (C# compiler) to execute malicious code, often as a part of defense evasion or payload delivery. This is achieved by spawning Csc.exe from unusual parent processes such as scripting hosts (cscript.exe, wscript.exe), Office applications (excel.exe, winword.exe), or PowerShell, especially when combined with encoded commands. Observed techniques also include launching Csc.exe from temporary or unusual directories. This activity bypasses traditional application whitelisting and can lead to the execution of arbitrary code. This activity has been associated with WarzoneRAT, DarkVNC, and the delivery of IMAPLoader malware.

Attack Chain

An attacker gains initial access, potentially through phishing or exploiting a vulnerability.
A script or Office macro executes, initiating a command-line process.
This process then invokes a scripting host (e.g., cscript.exe) or PowerShell.
The scripting host or PowerShell executes a command that downloads or creates a C# source code file.
Csc.exe is then invoked, often from a temporary directory, to compile the downloaded/created C# code.
The compiled C# code executes, performing malicious actions.
The malicious code may establish persistence, communicate with a C2 server, or perform data exfiltration.
The final objective might be to deploy ransomware, steal sensitive data, or establish a persistent backdoor.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to compromise systems, steal data, or deploy malware. Depending on the user’s permissions, the attacker could gain elevated privileges. The observed techniques have been associated with ransomware deployment, data theft, and remote access trojans (RATs).

Recommendation

Deploy the Sigma rule “Csc.EXE Execution Form Potentially Suspicious Parent” to detect suspicious parent processes of csc.exe.
Monitor process creation events for csc.exe with parent processes like scripting hosts or Office applications.
Investigate any instances of csc.exe being executed from temporary directories or user profile locations by reviewing process_creation logs.
Enable Sysmon process creation logging to capture detailed process information, including parent-child relationships, for effective detection.