[Mal Series #25] The spawn of conhost.exe

When I was playing with some red teaming toolkit, found out conhost.exe 0xffffffff -ForceV1 process is quite interesting. Therefore, this blog will explain why this happened based on my understanding.

Based on the Mandiant blog, conhost.exe is related with windows console host which is responsible in handling console input thread. For better understanding, it is encourage to read their blog.

Since most of the windows based computer now is using Windows 10 (soon might move to Windows 11 😏), the finding will be stick to Windows 10 environment only or Windows version that follows the similar architecture.

In Windows 10, conhost.exe will be spawn as a child process of any process that spawn windows shell process (e.g. powershell.exe & cmd.exe)

To see how this works on the C2 framework, I had tried on few of them:

1. Meterpreter
2. CobaltStrike
3. Havoc

For Meterpreter reverse shell, it establishes a live shell console with the client and the conhost.exe will be spawn under its injected process.

Since shell command used in the meterpreter to get the reverse shell in the client, both processes cmd.exe and conhost.exe are always active (non-greyout).

(Meterpreter) conhost.exe spawned when the server issue a full cmd reverse shell to client

The agent for CobaltStrike and Havoc works similar, which they didn’t establish a live shell console with the client (Since only shell command is used). User only can perform shell command one by one.

(Havoc) conhost.exe spawned when the server issue a cmd shell command to client

(Havoc) conhost.exe spawned when the server issue a powershell command to client

conhost.exe will keep alive under any injected process that contains the beacon payload as long as the window console still remain active. This might be not that stealthy in a sense.

Why 0xffffffffappeared as argument in conhost.exe? You may refer here. Based on my understanding on the return value section from MS doc, most of the time the session identifier will attach to a physical console (If not mistaken physical console refers to monitor, keyboard etc) and the beacon is utilizing reverse shell that might cause no physical console for the session to attach to ... maybe 🤔🤔🤔

Afterthought

Since conhost.exe will be spawn under any parent process that utilizing windows console and it is common in windows machines. Defender have to figure out any unusual parent processes that spawn conhost.exe in their environment to find out the true positive.

This not only limited to those C2 framework but also any prevalent malware that is capable of executing windows command such as Qakbot.

Fun Stuff

Actually you can execute a program by using conhost.exe <PROGRAM_PATH>. The execution of the process are handled by CreateProcessW()

Execute conhost.exe or conhost.exe cmd will spawn a cmd in with new windows. The default command line for conhost.exe is cmd.exe

Default command line

Execute conhost.exe powershell will spawn a powershell console in new window.

You can execute any command with the use of windows command shell. Example:conhost cmd /c mkdir test

Example of using conhost.exe -> cmd.exe to execute a binary file

References

Monitoring Windows Console Activity (Part 1) | Mandiant

Conhost Spawned By Suspicious Parent Process | Elastic Security Solution [8.8] | Elastic

OpenConsole.exe vs conhost.exe, questions · Issue #8101 · microsoft/terminal