Suspicious parent spawning autochk

Rule added on 20th February, 2024

Prerequisite:

The rule requires sysmon to be enabled for proper functioning.

Rule type:

Correlation

Rule description:

This correlation rule monitors the legitimate disk checking tool autochk.exe for suspicious activity. It focuses on situations where autochk spawns a child process (creates a new program) that's identified as malicious. This can be a sign of malware exploiting autochk to execute hidden harmful code.

Data source

Windows: Network traffic, process

Relevant MITRE ATT&CK techniques and tactics:

Tactics: TA0002 - Execution, TA0004 - Privilege Escalation, TA0005 - Defense Evasion,

Techniques: T1059 - Command and Scripting Interpreter, T1055 - Process Injection

Sub-techniques: T1059.003 - Windows Command Shell

Criteria:

The rule focuses on two key criteria:

• Process name not ends with Werfault.exe: This excludes processes ending with Werfault.exe, which is a legitimate Windows process associated with error reporting.
• Process name not ends with chkdsk.exe: This excludes the chkdsk.exe process, a legitimate disk checking tool.
• Process name not ends with doskey.exe: This excludes doskey.exe, a command-line history and macro utility.
• Parent Process name ends with autochk.exe: This is the key condition. It identifies processes that were spawned (created) by a process named autochk.exe.

If a process other than Werfault.exe, chkdsk.exe, or doskey.exe is spawned by autochk.exe, it might indicate malware or unauthorized activity trying to disguise itself under the autochk.exe process.

When to enable this rule:

Enable this rule when the user wants to detect potential malware exploiting the legitimate disk checking tool autochk.exe by spawning suspicious child processes.

Compliance mapping (NIST, CIS):

• NIST CSF: DE.AE (Detection Processes) for identifying and responding to anomalies that deviate from normal operational patterns.
• CIS Control: 8 (Malware Defense) aimed at detecting and blocking potentially harmful processes initiated by system utilities.

Next steps:

Upon triggering this alert, the following actions can be taken:

• Identification: Mark this alert as a part of an existing incident or initiate a new incident. Assign the incident to an analyst for in-depth examination.
• Analysis:Conduct an impact investigation and thoroughly analyze the degree of compromise utilizing the Incident Workbench to gain insights into the threat's severity.
• Response: Initiate automated workflow execution to swiftly terminate the identified malicious process, leveraging Workflows for prompt mitigation.