Windows Security Event Logs — CraftedSignal Threat Feed

Suspicious Execution via Windows Command Debugging Utility

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. This can be achieved by running cdb.exe from non-standard installation paths and using specific command-line arguments to execute malicious commands. The LOLBAS project documents this technique, highlighting its potential for defense evasion. This activity has been observed across various environments, necessitating detection strategies that focus on identifying anomalous executions of cdb.exe.

Attack Chain

An attacker gains initial access to a Windows system.
The attacker copies cdb.exe to a non-standard location (outside “Program Files” and “Program Files (x86)”).
The attacker executes cdb.exe with the -cf, -c, or -pd command-line arguments.
These arguments are used to specify a command file or execute a direct command.
The command file or command directly executes malicious code, such as shellcode.
The malicious code performs actions such as creating new processes, modifying files, or establishing network connections.
These actions allow the attacker to maintain persistence or escalate privileges.
The ultimate goal is to evade defenses and execute arbitrary code on the system.

Impact

Successful exploitation allows adversaries to execute arbitrary commands and shellcode on the affected system, potentially leading to complete system compromise. This can result in data theft, installation of malware, or further propagation within the network. The technique is effective at bypassing application whitelisting and other security controls that rely on standard execution paths.

Recommendation

Deploy the Sigma rule “Execution via Windows Command Debugging Utility” to your SIEM to detect suspicious cdb.exe executions (see rules section).
Enable process creation logging via Sysmon or Windows Security Event Logs to provide the necessary data for the Sigma rule.
Implement application whitelisting to prevent execution of cdb.exe from non-standard paths.
Monitor process command lines for the -cf, -c, and -pd flags when cdb.exe is executed.
Investigate any instances of cdb.exe running from unusual directories to determine legitimacy.

Credential Acquisition via Registry Hive Dumping

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

This detection identifies attempts to export registry hives containing sensitive credential information using the Windows reg.exe utility. Attackers may target the HKLM\SAM and HKLM\SECURITY hives to extract stored credentials, including password hashes and LSA secrets. The activity is often part of a broader credential access campaign. The rule focuses on detecting the execution of reg.exe with specific arguments indicating an attempt to save or export these critical registry hives. The use of reg.exe makes this technique accessible to various threat actors, including ransomware groups and nation-state actors. Defenders need to monitor for this activity to prevent unauthorized credential access and potential lateral movement within the network. This rule specifically looks for “save” and “export” arguments targeting SAM and SECURITY hives.

Attack Chain

An attacker gains initial access to a Windows system, potentially through phishing or exploiting a vulnerability.
The attacker executes reg.exe from the command line or through a script.
The reg.exe command includes arguments to save or export registry hives.
The target registry hives are HKLM\SAM and HKLM\SECURITY, containing sensitive credential information.
The exported registry hive is saved to a file on disk or a network share.
The attacker may compress or encrypt the exported registry hive to evade detection.
The attacker retrieves the exported registry hive for offline analysis.
The attacker extracts credential information from the registry hive, such as password hashes and LSA secrets, to use in lateral movement or privilege escalation.

Impact

Successful exploitation allows attackers to acquire sensitive credentials stored within the registry. This can lead to lateral movement within the network, privilege escalation, and ultimately, data exfiltration or system compromise. Compromised credentials can be used to access critical systems and data, causing significant damage to the organization. The impact is considered high due to the potential for widespread access and control over the compromised environment.

Recommendation

Enable process creation auditing with command line arguments to capture the execution of reg.exe with relevant arguments. (Data Source: Windows Security Event Logs, Sysmon)
Deploy the Sigma rule Detect Registry Hive Export via Reg.exe to your SIEM to detect the execution of reg.exe with arguments indicative of registry hive dumping.
Implement access controls and monitor file system activity to detect unauthorized access or modification of registry hive files.
Review and restrict the use of reg.exe to authorized personnel and processes.
Monitor for parent processes of reg.exe that are unusual or unexpected, which might indicate malicious activity.
Investigate any alerts generated by the Sigma rule by reviewing the process command line, parent process, and destination of the exported registry hive.

Detection of Sensitive LDAP Attribute Access

hello@craftedsignal.io — Fri, 19 Jan 2024 16:23:00 +0000

This detection rule identifies attempts to access sensitive attributes within Active Directory via the Lightweight Directory Access Protocol (LDAP). These attributes, including unixUserPassword, ms-PKI-AccountCredentials, and msPKI-CredentialRoamingTokens, are valuable targets for adversaries aiming to steal credentials or escalate privileges. The rule focuses on Windows Security Event Logs, specifically monitoring event code 4662 which indicates an attempt to access an object. By filtering out common benign access patterns, such as those originating from the SYSTEM account or using specific access masks, the rule aims to highlight potentially malicious activity that warrants further investigation. The original rule was created in November 2022 and updated in May 2026.

Attack Chain

An attacker gains initial access to a system within the target domain (e.g., through phishing or exploiting a public-facing application).
The attacker uses valid credentials or exploits a vulnerability to authenticate to the domain.
The attacker uses LDAP queries to enumerate Active Directory objects.
The attacker crafts specific LDAP queries to target sensitive attributes like unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
Windows Security Event 4662 is generated, logging the access attempt with details about the user, accessed object, and properties.
The attacker exfiltrates the accessed attribute data, potentially containing password hashes, certificates, or other sensitive information.
The attacker uses the stolen credentials or certificates to impersonate other users or gain elevated privileges within the domain.

Impact

Successful exploitation can lead to the compromise of domain accounts, including privileged accounts. Attackers can use stolen credentials to move laterally within the network, access sensitive data, and disrupt business operations. Depending on the attributes accessed, this could also expose private keys and authentication certificates leading to further attacks.

Recommendation

Deploy the Sigma rule “Access to Sensitive LDAP Attributes” to your SIEM to detect access attempts to critical AD attributes (rule.name).
Enable “Audit Directory Service Access” to ensure that necessary Windows Security Event Logs (event code 4662) are generated for the Sigma rule to function (setup).
Review and tune the “Access to Sensitive LDAP Attributes” Sigma rule, creating exceptions for legitimate administrative accounts and scheduled system processes to minimize false positives (rule.note).
Implement stricter access controls and permissions for sensitive LDAP attributes within Active Directory to restrict access to only necessary personnel (rule.note).
Investigate any triggered alerts from the Sigma rule, focusing on identifying the user/process attempting access (winlog.event_data.SubjectUserSid) and the specific sensitive attribute accessed (winlog.event_data.Properties) (rule.note).

Multiple Logon Failure Followed by Logon Success

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

This detection rule focuses on identifying brute-force or password guessing attacks against Windows systems. It detects multiple failed logon attempts originating from the same source IP address, followed by a successful logon. This pattern suggests an attacker attempting to guess credentials to gain unauthorized access to an account. The rule leverages Windows Security Event Logs to monitor authentication events. This activity is important for defenders because successful brute-force attacks can lead to account compromise, data breaches, and further malicious activities within the network. The rule uses EQL and analyzes logs-system.security*, logs-windows.forwarded*, and winlogbeat-* indices.

Attack Chain

The attacker initiates multiple failed logon attempts to a Windows system using various username and password combinations. These attempts originate from a single source IP address and target network logon types.
The system records each failed logon attempt as a Windows Security Event Log event (Event ID 4625). The event includes information about the source IP address, target username, and failure reason.
After several failed attempts, the attacker guesses the correct password for a valid user account.
The system records a successful logon event (Event ID 4624) for the compromised account, originating from the same source IP address as the previous failed attempts, also via a network logon type.
The attacker gains initial access to the target system using the compromised account.
The attacker may then attempt to escalate privileges or move laterally within the network, using the compromised account to access additional resources or systems.

Impact

A successful brute-force attack can lead to unauthorized access to sensitive data, system compromise, and further malicious activities within the network. Compromised accounts can be used to escalate privileges, move laterally, and deploy ransomware. The severity depends on the privileges of the compromised account and the sensitivity of the data it can access.

Recommendation

Enable Audit Logon to generate the necessary events (4624, 4625) in the Windows Security Event Logs for the detection rule to function. Reference: https://ela.st/audit-logon.
Deploy the provided Sigma rule to your SIEM to detect multiple logon failures followed by a successful logon. Tune the rule based on your environment and baseline activity.
Investigate any triggered alerts to determine the scope of the compromise and take appropriate remediation steps.
Consider implementing multi-factor authentication (MFA) to mitigate the risk of brute-force attacks.
Monitor network traffic for suspicious activity originating from the source IP address associated with the brute-force attempts.
Review and enforce strong password policies to reduce the likelihood of successful password guessing.

MSBuild запускает необычные процессы

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

The Microsoft Build Engine (MSBuild) is a legitimate tool used for building applications. However, adversaries may abuse MSBuild to execute malicious scripts or compile code, effectively bypassing security controls. This technique is often employed to deploy malicious payloads. This detection focuses on identifying instances where MSBuild initiates unusual processes such as PowerShell, Internet Explorer, or the Visual C# Command Line Compiler (csc.exe). This activity is considered suspicious because legitimate software development workflows do not typically involve MSBuild directly spawning these processes. The original Elastic detection rule was created on 2020-03-25 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a system (e.g., through phishing or exploiting a vulnerability).
The attacker modifies or creates an MSBuild project file (.csproj or .sln) containing malicious commands.
The malicious MSBuild project file is crafted to execute a script or compile code.
The attacker uses the MSBuild.exe or msbuild.exe utility to execute the malicious project file.
MSBuild spawns an unusual process such as powershell.exe, csc.exe, or iexplore.exe based on the malicious project file configuration.
PowerShell executes arbitrary commands, downloads further payloads, or performs other malicious actions.
The C# compiler (csc.exe) compiles malicious code into an executable or library.
The compiled malware or downloaded payloads execute, leading to further compromise, such as data exfiltration or lateral movement.

Impact

Successful exploitation can lead to arbitrary code execution, allowing attackers to deploy malware, compromise sensitive data, and establish persistence on the targeted system. The use of MSBuild for malicious purposes allows attackers to bypass application whitelisting and other security controls that trust signed Microsoft binaries. While the precise number of victims is unknown, this technique can be employed against a wide range of organizations, particularly those with vulnerable systems or inadequate endpoint protection.

Recommendation

Enable process creation logging, specifically including parent-child relationships, to detect unusual process spawning by MSBuild (logs-endpoint.events.process-*, logs-system.security*, logs-windows.forwarded*, logs-windows.sysmon_operational-*, winlogbeat-*).
Deploy the Sigma rule “Microsoft Build Engine Started an Unusual Process” to your SIEM to identify instances of MSBuild spawning suspicious processes, and tune for your environment.
Investigate any instances of MSBuild spawning PowerShell, csc.exe, or iexplore.exe to determine if the activity is legitimate or malicious (process.name:(“csc.exe” or “iexplore.exe” or “powershell.exe”)).
Monitor for modifications to MSBuild project files (.proj or .sln) for signs of tampering.

Potential NTLM Relay Attack against a Computer Account

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

This detection rule identifies potential NTLM relay attacks targeting computer accounts in Windows environments. The attack involves coercing a target server to authenticate to an attacker-controlled system and then relaying that authentication to another service. It focuses on detecting a sequence of events: initial coercion attempts against specific named pipes known to be vulnerable, followed by authentication attempts using the target server’s computer account from a different host. This activity can allow an attacker to gain unauthorized access and execute commands with the privileges of the compromised computer account. The rule leverages Windows Security Event Logs to identify these patterns, providing a mechanism for defenders to detect and respond to NTLM relay attacks. The detection is based on research from 2025/2026 on coerced authentication methods and NTLM reflection techniques.

Attack Chain

The attacker gains initial access to a machine within the network.
The attacker initiates a coercion attack against a target server, forcing it to authenticate to a malicious endpoint. This often involves leveraging vulnerabilities in services such as Spoolss, Netlogon, or other RPC services. The attacker uses methods outlined in the referenced coercion authentication research.
The target server attempts to access a named pipe on the attacker-controlled system. This is logged as a File Share event (Event ID 5145) on the target server, indicating access to a named pipe like Spoolss, netdfs, lsarpc, lsass, netlogon, samr, efsrpc, FssagentRpc, eventlog, winreg, srvsvc, dnsserver, or WinsPipe.
The attacker captures the NTLM authentication attempt from the target server.
The attacker relays the captured NTLM authentication to another service on the network, impersonating the target server. The authentication event is logged (Event ID 4624 or 4625), showing a logon attempt using the NTLM protocol and a computer account (username ending in “$”).
The authentication attempt originates from a different IP address than the target server’s IP, indicating the relay.
If successful, the attacker gains unauthorized access to the service and can execute commands or access data with the privileges of the target server’s computer account.
The attacker leverages the compromised computer account to move laterally within the network, potentially gaining access to sensitive resources or escalating privileges further.

Impact

A successful NTLM relay attack can allow attackers to gain control of critical systems and data. By compromising a computer account, attackers can move laterally within the network, access sensitive information, and potentially disrupt business operations. The number of victims and the extent of the damage can vary depending on the scope of the attacker’s activities after compromising the computer account. Organizations in any sector that rely on Windows networks and Active Directory are vulnerable. Failure to detect and prevent these attacks can lead to significant financial losses, reputational damage, and regulatory penalties.

Recommendation

Enable and monitor Windows Security Event Logs, specifically for Event IDs 5145 (File Share access), 4624 (Successful Logon), and 4625 (Failed Logon), as these are crucial for detecting NTLM relay attempts.
Deploy the Sigma rules provided in this brief to your SIEM to detect potential NTLM relay attacks based on the sequence of file access and authentication events.
Investigate any alerts generated by the Sigma rules, focusing on the source and target of the authentication events, the named pipes accessed, and any follow-on activity.
Review and harden NTLM configuration to mitigate relay attacks, and consider disabling NTLM where possible in favor of more secure authentication protocols like Kerberos.
Enable SMB signing and Extended Protection for Authentication to prevent NTLM relay attacks.
Implement network segmentation and access controls to limit the scope of potential NTLM relay attacks.
Apply the “Setup” configurations by enabling the recommended Windows audit policies to ensure the events required by the rules are generated.

Execution from Unusual Directory - Command Line

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

This detection rule identifies instances of process execution originating from suspicious default Windows directories. Attackers often exploit these locations to conceal malware, leveraging the implicit trust associated with system or application paths to evade security measures. This tactic is employed to make malicious executions appear less conspicuous. The rule focuses on detecting specific processes, including wscript.exe, cscript.exe, rundll32.exe, regsvr32.exe, and others, when they are executed from unusual directories, such as C:\\PerfLogs\\, C:\\Users\\Public\\, and C:\\Windows\\Tasks\\. The intent is to highlight anomalous process behaviors that deviate from expected norms, providing early warning of potential malicious activity. The detection logic also includes filters to reduce false positives by excluding known legitimate executables and command line arguments from the specified directories.

Attack Chain

An attacker gains initial access to a Windows system through various means such as phishing or exploiting a vulnerability.
The attacker uploads or drops a malicious payload into a suspicious directory like C:\\Users\\Public\\ or C:\\Windows\\Tasks\\.
The attacker uses a legitimate Windows utility such as cmd.exe, powershell.exe, or wscript.exe to execute the malicious payload.
The executed script or binary performs malicious actions, such as establishing persistence.
The attacker attempts to evade detection by masquerading the malicious activity as legitimate system processes.
The malware may attempt to communicate with a command-and-control server.
The malware may perform lateral movement within the network.
The final objective of the attacker is to exfiltrate sensitive data or cause damage to the system.

Impact

Successful exploitation can lead to malware infection, data compromise, and system instability. Attackers can establish persistent access, escalate privileges, and perform lateral movement within the network. The impact ranges from minor disruptions to significant data breaches depending on the attacker’s objectives and the compromised system’s role within the organization. The targeted sectors are broad, as this technique is applicable across various industries and organizational sizes.

Recommendation

Deploy the Sigma rule “Execution from Unusual Directory - Command Line” to your SIEM and tune for your environment to detect suspicious process executions from unusual directories.
Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and command-line arguments.
Enable process creation logging with command line arguments to provide the necessary data for the Sigma rule (reference log source in rule).
Regularly review and update the list of suspicious directories in the Sigma rule to reflect changes in your environment.
Implement application whitelisting to restrict the execution of unauthorized applications from unusual directories.

Suspicious Mofcomp Activity

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

The rule detects suspicious usage of mofcomp.exe, a command-line tool used to compile Managed Object Format (MOF) files. Attackers can abuse MOF files to manipulate the Windows Management Instrumentation (WMI) repository by building malicious WMI scripts for persistence or execution. This can be achieved by creating their own namespaces and classes within WMI or establishing persistence through WMI Event Subscriptions. The rule identifies unusual mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes like ScenarioEngine.exe and system accounts (S-1-5-18). This detection is designed to work with data from Elastic Defend, Microsoft Defender XDR, Crowdstrike, and Windows Security Event Logs. The rule aims to detect potential misuse of WMI for malicious purposes, enhancing the visibility of attacker techniques for execution and persistence.

Attack Chain

An attacker gains initial access to the system (e.g., through phishing or exploitation of a vulnerability).
The attacker uploads a malicious MOF file to the compromised system.
The attacker executes mofcomp.exe to compile the malicious MOF file.
mofcomp.exe processes the MOF file, creating new namespaces and classes or modifying existing ones in the WMI repository.
If the MOF file creates a WMI Event Subscription, it triggers the execution of a malicious script or binary when a specific event occurs.
The malicious script or binary executes, performing actions such as installing malware, creating backdoors, or exfiltrating data.
The attacker maintains persistence through the WMI Event Subscription, ensuring continued access even after system reboots.

Impact

Successful exploitation via malicious MOF files can lead to persistent access, code execution, and system compromise. Attackers can use this technique to install malware, create backdoors, or steal sensitive data. The rule aims to detect early stages of such attacks, preventing significant damage. By establishing persistence, attackers can maintain long-term control over the compromised system, evading traditional detection methods.

Recommendation

Deploy the provided Sigma rules to your SIEM to detect suspicious mofcomp.exe activity and tune for your environment.
Enable process creation logging and command-line auditing on Windows systems to capture necessary events for the provided Sigma rules.
Investigate any alerts generated by the Sigma rules, focusing on unusual MOF file paths, parent processes, and user accounts.
Review and monitor WMI namespaces and classes for unauthorized modifications or additions following any detected suspicious mofcomp.exe activity.

Persistence via WMI Event Subscription

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

Windows Management Instrumentation (WMI) provides a powerful framework for managing Windows systems, but adversaries can abuse its capabilities to establish persistence. By creating WMI event subscriptions, attackers can execute arbitrary code in response to defined system events. This technique involves creating event filters, providers, consumers, and bindings that automatically run malicious code. This can be achieved through tools like wmic.exe, which allows the creation of event consumers such as ActiveScriptEventConsumer or CommandLineEventConsumer. Successful exploitation of WMI for persistence allows attackers to maintain unauthorized access to a compromised system, even after reboots or other system changes. This activity has been observed across various environments, highlighting the need for robust detection mechanisms to identify and prevent WMI-based persistence.

Attack Chain

An attacker gains initial access to a Windows system through unspecified means.
The attacker uses wmic.exe to create a WMI event filter that defines a specific event to monitor.
A WMI event consumer, such as ActiveScriptEventConsumer or CommandLineEventConsumer, is created using wmic.exe specifying the malicious code or script to execute when the event occurs.
A WMI binding is established between the event filter and the event consumer using wmic.exe, linking the event to the action.
The malicious WMI event subscription is activated, monitoring for the defined event.
When the specified event occurs, the WMI service triggers the execution of the associated malicious code or script through the event consumer.
The attacker gains persistent access to the system, as the WMI event subscription will re-activate after reboots.
The attacker can then perform additional malicious activities, such as lateral movement or data exfiltration.

Impact

Successful exploitation of WMI for persistence can allow an attacker to maintain long-term, unauthorized access to a compromised system. This can result in data theft, system compromise, and further malicious activities. While the exact number of victims is not specified in the source, the broad applicability of this technique means that many Windows systems are potentially at risk. If the attack succeeds, the attacker gains a foothold on the system that is difficult to detect and remove, which can lead to significant operational disruption and financial loss.

Recommendation

Enable process creation logging and monitor for wmic.exe with command-line arguments related to creating event consumers, specifically ActiveScriptEventConsumer or CommandLineEventConsumer, to trigger the Sigma rule “Detect Suspicious WMIC Process”.
Deploy the provided Sigma rule to your SIEM to detect suspicious WMI event subscription creation.
Review the investigation steps outlined in the provided documentation to triage and analyze potential WMI persistence attempts.
Monitor Windows Security Event Logs and Sysmon for events related to WMI activity for broader coverage.

Windows Audit Policy Sub-Category Disabled

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

Attackers may disable auditing on a system in order to evade detection and forensic analysis. This is often done after initial compromise, to prevent security tools from logging their actions. This rule identifies attempts to disable auditing for specific security-sensitive audit policy sub-categories, providing defenders with insight into potential malicious activity. The rule leverages Windows Security Event Logs and specifically focuses on Event ID 4719, which indicates changes to the audit policy. It aggregates policy changes within 5-minute windows to identify removals of audit policies that are not re-enabled within the same timeframe, reducing false positives from temporary or legitimate policy changes. This detection logic is implemented using ES|QL in Elastic Stack version 9.3.0 and later.

Attack Chain

Initial Access: The attacker gains initial access to the system through various means (e.g., phishing, exploitation of vulnerabilities).
Privilege Escalation: The attacker escalates their privileges to gain administrative or system-level access.
Discovery: The attacker performs reconnaissance to identify the current audit policy settings and determine which sub-categories are enabled.
Defense Evasion: The attacker executes commands or scripts to disable specific audit policy sub-categories, such as Logon, Audit Policy Change, Process Creation, Other System Events, Security Group Management, and User Account Management, using tools like auditpol.exe or modifying Group Policy Objects.
Activity Execution: With auditing disabled, the attacker performs malicious activities without generating relevant security logs.
Persistence: The attacker establishes persistence mechanisms to maintain access to the system, such as creating scheduled tasks or modifying registry keys.
Lateral Movement: The attacker moves laterally to other systems on the network, potentially disabling auditing on those systems as well.
Objective Completion: The attacker achieves their objective, which could include data theft, system disruption, or ransomware deployment.

Impact

Successful disabling of audit policies can severely impair an organization’s ability to detect and respond to security incidents. Without proper logging, malicious activities can go unnoticed, leading to prolonged compromises and increased damage. Disabling auditing can impact incident response efforts, making it difficult to determine the scope and impact of an attack. The risk score associated with this activity is 47, indicating a significant potential impact on security posture.

Recommendation

Enable Audit Policy Change auditing to generate the necessary events for this rule as described in the setup instructions.
Deploy the provided Sigma rule to your SIEM to detect attempts to disable sensitive audit policy sub-categories. Tune the rule as necessary based on your environment and baseline activity.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the audit policy changes and identify potential malicious activity.
Review the references to understand the significance of Event ID 4719 and its implications for security monitoring.
Consider enabling Sysmon process creation logging with command line auditing to detect the use of tools such as auditpol.exe to modify audit policies.

Windows Admin Account Brute Force Detection

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

This detection rule, originally created on 2020-08-29 and last updated on 2026-05-04, identifies potential brute-force attempts against Windows systems. It focuses on scenarios where an attacker attempts to guess passwords for multiple accounts containing the term “admin” in their usernames, suggesting an attempt to compromise privileged accounts. The rule aggregates failed logon events to detect this activity. This is important for defenders as successful brute-force attacks can lead to unauthorized access, data breaches, and other malicious activities. The rule leverages Windows Security Event Logs and requires Audit Logon to be enabled.

Attack Chain

The attacker attempts to gain initial access to the target network.
The attacker identifies potential target accounts with “admin” in their username.
The attacker initiates a series of network logon attempts using various password combinations (T1110.001, T1110.003).
The Windows system records failed logon events (Event ID 4625) in the Security Event Logs.
The detection rule aggregates these failed logon events, filtering out known noisy failure codes.
If the number of failed attempts against distinct “admin” accounts from the same source IP within a 60-second window exceeds a threshold (50 attempts against 2 distinct usernames), the rule triggers an alert.
The attacker, if successful, gains unauthorized access to the targeted admin account.
With access to an admin account, the attacker can perform a wide range of malicious activities, including privilege escalation, data exfiltration, and system compromise.

Impact

Successful brute-force attacks on administrator accounts can lead to significant damage. Attackers gaining access can escalate privileges, install malware, access sensitive data, or disrupt critical systems. This can result in data breaches, financial losses, and reputational damage. While specific victim counts are not provided, the rule’s focus on privileged accounts indicates a high potential for severe impact on organizations.

Recommendation

Enable Audit Logon to generate the necessary Windows Security Event Logs. Refer to the setup instructions at https://ela.st/audit-logon.
Deploy the Sigma rule “Detect Windows Admin Account Brute Force” to your SIEM and tune the threshold parameters (failed_auth_count, count_distinct_user_name) for your environment.
Investigate alerts triggered by the Sigma rule, focusing on the source IP address, targeted usernames, and logon failure reason codes.
Review and strengthen password policies to prevent password guessing attacks (T1110).
Monitor network traffic for suspicious logon attempts from external IP addresses to internal systems.

Service Control Executed from Script Interpreters

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

This detection identifies instances where the Service Control utility (sc.exe) is executed from within a script interpreter, such as cmd.exe, PowerShell, or wscript.exe. Attackers may leverage this behavior to create, modify, or start Windows services, often with the intent to elevate privileges or establish persistence on a compromised system. The sc.exe is a legitimate Windows command-line tool used for managing services. Abusing this tool allows attackers to perform malicious actions under the guise of legitimate system administration. This detection is designed to identify anomalous use of sc.exe that deviates from typical administrative tasks, focusing on instances where it’s spawned from scripting environments often used for malicious activities. The rule specifically excludes service creations performed by the SYSTEM user.

Attack Chain

An attacker gains initial access to a Windows system via an exploit or compromised credentials.
The attacker executes a script interpreter (e.g., cmd.exe, powershell.exe).
Within the script interpreter, the attacker uses sc.exe to manage Windows services.
The sc.exe command is used with arguments such as “create”, “start”, “stop”, “delete”, or “config” to manipulate service configurations.
A new service is created or an existing service is modified to execute a malicious payload.
The malicious service is started, allowing the attacker to execute code with elevated privileges (SYSTEM).
The attacker achieves persistence by ensuring the malicious service automatically starts upon system reboot.
The attacker may use the created service to execute additional malicious commands or maintain remote access.

Impact

A successful attack could lead to complete system compromise with the attacker gaining SYSTEM level privileges. This can allow for lateral movement within the network, data exfiltration, or installation of persistent backdoors. While the frequency of this specific technique may be low, the potential impact is high due to the elevated privileges gained.

Recommendation

Deploy the Sigma rule Service Control Spawning via Script Interpreter to your SIEM to detect this specific behavior and tune it to your environment.
Monitor process creation events for sc.exe being executed by script interpreters like PowerShell or cmd.exe (as covered in the rule description).
Investigate any instances of sc.exe being used with the arguments “create”, “start”, “stop”, “delete”, or “config” from scripting environments to identify potentially malicious activity.
Ensure proper access controls are in place to limit the ability of users to create or modify services.

Detecting Suspicious Scheduled Task Creation in Windows

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

Adversaries frequently abuse Windows scheduled tasks to establish persistence, move laterally within a network, and escalate privileges. This technique involves creating or modifying scheduled tasks to execute malicious code at specific times or in response to certain events. This detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. The rule relies on Windows Security Event Logs, offering a valuable method for identifying unauthorized task creation indicative of malicious activity. The detection logic specifically excludes common tasks associated with software updates from vendors like Hewlett-Packard, Microsoft, Google, and Mozilla, as well as tasks run by system accounts.

Attack Chain

An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker uses their initial access to execute commands, potentially leveraging PowerShell or cmd.exe.
The attacker uses the schtasks command-line utility or the COM interface to create a new scheduled task.
The scheduled task is configured to execute a malicious payload, such as a reverse shell or a data exfiltration script.
The task is set to trigger based on a specific schedule, such as at system startup, at a specific time, or upon a specific event.
When the trigger occurs, the scheduled task executes the malicious payload.
The malicious payload establishes persistence, allowing the attacker to maintain access to the compromised system.
The attacker can then use the persistent access to move laterally to other systems or to exfiltrate sensitive data.

Impact

Successful exploitation allows adversaries to maintain persistent access to compromised systems, potentially leading to data theft, system disruption, or further lateral movement within the network. By creating malicious scheduled tasks, attackers can ensure their code is executed even after a system reboot or user logoff. This can result in long-term compromise and significant damage to affected organizations. While the number of victims and specific sectors targeted are not detailed, the potential impact is broad due to the widespread use of Windows systems in enterprise environments.

Recommendation

Enable Windows Security Event Logging and ensure that event ID 4698 (A scheduled task was created) is collected.
Deploy the Sigma rule “Suspicious Scheduled Task Creation via Winlog” to your SIEM to detect potentially malicious scheduled task creation events.
Regularly review and update the exclusion list in the Sigma rule to account for new benign scheduled tasks in your environment.
Investigate any alerts generated by the Sigma rule by examining the task’s name, path, actions, and triggers to determine if they are suspicious.
Monitor for related suspicious activity, such as unusual process executions or network connections originating from the compromised system.