Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Koifman opened this issue Jul 13, 2024 · 7 comments
Assignees
Labels
False-Positive Issue reporting a false positive with one of the rules

Comments

@Koifman
Copy link
Contributor

Koifman commented Jul 13, 2024

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!

@Koifman Koifman added the False-Positive Issue reporting a false positive with one of the rules label Jul 13, 2024
Copy link
Contributor

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
Copy link

VadimV1 commented Jul 13, 2024

+1 I have also come across this problem

@nasbench
Copy link
Member

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.

image

image

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
Copy link
Contributor Author

Koifman commented Jul 13, 2024

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):
image

QRadar (two spaces):
image

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
Copy link
Member

nasbench commented Jul 13, 2024

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
Copy link
Contributor Author

Koifman commented Jul 13, 2024

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
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
False-Positive Issue reporting a false positive with one of the rules
Projects
None yet
Development

No branches or pull requests

3 participants