Certain Windows commands include two spaces between the process and the parameters which is NOT reflected in related SIGMA rules

[Koifman]

Rule UUID

a29c1813-ab1f-4dde-b489-330b952e91ae

Example EventLog

OriginalFileName: ipconfig.exe
CommandLine: ipconfig /all

Description

Something pretty odd I noticed. On Windows EID 4688 AND also Sysmon EID 1, some commands are logging two spaces instead of one, which is not reflected in sigma rules. For example, the rule "a29c1813-ab1f-4dde-b489-330b952e91ae" lists the following command:
"ipconfig /all", which clearly shows one space. However, when I tested this command (multiple machines, asked other people as well, all give the same result), it logs as two spaces:
OriginalFileName: ipconfig.exe
CommandLine: ipconfig /all

This is relevant (so far) to "ipconfig", "net", "arp" and "ping"
Another example, typing "ping 1.1.1.1" (one space) would log it as "ping 1.1.1.1" (two spaces)

I could not find ANY information about this online, any there are a lot of rules that utilize those commands and only include one space in the detection logic, instead of two, which can cause serious misses.

Would be great to get some more information about this if you know. Thanks!

[github-actions]

Welcome @Koifman 👋

It looks like this is your first issue on the Sigma rules repository!

The following repository accepts issues related to false positives or 'rule ideas'.

If you're reporting an issue related to the pySigma library please consider submitting it here

If you're reporting an issue related to the deprecated sigmac library please consider submitting it here

Thanks for taking the time to open this issue, and welcome to the Sigma community! 😃

[VadimV1]

+1 I have also come across this problem

[nasbench]

Hi @Koifman and thanks for opening the issue.

I doubled checked and this seems to be a visual bug when showing the data in the "General" view. If you look at the actual data via the XML view you'll see that both 4688 and Sysmon EID 1 show the CLI without space.

Here are some screenshots below.

The data collected by tools in general is not the one shown in the general view but the XML view.

Double check on your end and let me know :)

[Koifman]

Hi @nasbench , really appreciate your feedback. I tested this as well, and I do indeed see that the XML payload contains one space. However, in both Splunk and QRadar, the events still show with two spaces.

Splunk (two spaces):

QRadar (two spaces):

I know that this is not something directly about SIGMA, but it is somehow related, at least.
I imagine there are quite a log of people/companies who use the ruleset and a SIEM, and if they just copy the rules affected by those two spaces thingy, they will miss things.

I imagine that if you configure the SIEM agent to collect the XML payload directly, the command will show one space, but based on my experience with multiple SIEMs, the default agent collection is via Syslog, which does not copy the XML payload directly, and therefore, will show two spaces in the SIEM.

[nasbench]

Thanks for the fast response. I understand the use case where people collect via syslog or other means. For now, I will try to dig deeper to try and find out the cause and if its something that happens on other windows versions and which commands are affected (and why).

I'll post updates to this issue once i have any :)

Could you please tell me the version of Windows you're testing on, thanks in advance.

Also i could've sworn I've encountered this issue before either on twitter or somewhere else. We'll check past discussions :)

[Koifman]

My exact version right now is Windows 10, 22H2, 19045.4651
But any other version, both normal Windows and Server, whether I tried it myself or asked other people to test, all show the same results for the same commands.

Thank you so much for checking this, I'm feeling this is something important, but I wanted to consult the experts.

[nasbench]

Some additional testing. It seems the CLI is actually being sent like that (not an event log issue).

Tested with Procmon, System Informer and process explorer and they all capture the CLI of some commands launched with **cmd.exe" with additional spaces. This doesn't seem to affect the process launched from PowerShell for example.

It's looking like a duck up from MS side related to cmd.exe launching processes, investigating more.... (keep you updated)