Detecting the presence of conhost spawning suspicious host

Prerequisite:

The rule requires sysmon to be enabled for proper functioning.

Rule type:

Correlation rule

Rule description:

conhost.exe is the console window host. This rule keeps an eye out for conhost spawning suspicious host processes, which could be a sign of malware trying to use the console window for hidden activity.

Data source:

Windows: User account, network traffic, process

Criteria:

Identifying the Parent Process:

The rule focuses on the parent process name, which refers to the program that spawned another program.

It checks if the parent process name ends with any of the following:

• Windows\System32\conhost.exe
• Windows\SysWow64\conhost.exe
• WINNT\system32\conhost.exe

These are all valid paths for the legitimate Windows program conhost.exe. Conhost.exe is a console window host responsible for handling text-based console applications in Windows.

Child Process Exclusion:

The rule then checks the name of the child process (the program spawned by conhost.exe)

It excludes child processes with the following names:

• mscorsvw.exe (Microsoft .NET Framework Common Language Runtime)
• wermgr.exe (Windows Error Reporting Manager)
• WerFault.exe (Windows Error Reporting Service)
• WerFaultSecure.exe (Secure Windows Error Reporting Service)

These are all legitimate Windows processes associated with error reporting and application management. Their exclusion ensures the rule focuses on less common child processes spawned by conhost.exe.

When to enable this rule:

Enable this rule when the user wants to identify potential command-and-control (C2) activity or malware installation by detecting the presence of conhost spawning suspicious host processes.

Compliance mapping (NIST, CIS):

NIST Cybersecurity Framework (CSF): DE.AE (Detection Processes) for recognizing and analyzing unusual process spawnings, indicating potential security threats.

CIS: 8 (Malware Defense) to detect and mitigate malicious activities leveraging the console host process.

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. Assigning 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.