System Informer incorrectly classified

Rule UUID

811e0002-b13b-4a15-9d00-a613fce66e42

Example EventLog

N/A

Description

System Informer was never released with the same capability described (for Process Hacker) in the references of the rule 811e0002-b13b-4a15-9d00-a613fce66e42.

The reason for the name change was to rebrand it away from the "hacker" nomenclature and bring it under the wing of Winsider Seminars & Solutions, Inc. (owned by Alex Ionescu and Yarden Shafir). Most importantly, the vulnerabilities described for "Process Hacker" and abused by bad actors, have been patched. System Informer is not susceptible to this type of abuse and System Informer does not have the same capability to enable bad actors to evade defenses. Notably, System Informer respects the protected process (PPL) boundaries on the system and will not permit manipulation of PPL processes. The driver, signed by Microsoft, and packaged with System Informer is only supported on Win10+ AMD64/ARM64.

The same applies to rule 67add051-9ee7-4ad3-93ba-42935615ae8d. The drivers should not be classified as the same. The System Informer driver implements hardened mitigations that prevent a bad actor from arresting control over the driver described here. The driver is completely open source for review and scrutiny. The driver was effectively completely rewritten, in collaboration with Microsoft's HVCI team, to ensure it meets their bar for security.

Overall, the "level: high" classification applied to System Informer is not warranted as there is zero indication that System Informer is actively being abused in the same manner that Process Hacker was. Furthermore, the maintainers have received no reports via the Security Policies and Procedures. This classification may also be contributing to the plethora of false positives by various vendors.

I would like the rule reversed to remove the mention of "System Informer". It should not be under the same classification as "Process Hacker". The maintainers of System Informer have been tirelessly working with various vendors to try to reverse the false positives, with various degrees of success. I fear that the sigma rule might be the root case. So, in order to address the problem, I believe we need to address it here.

Reference issues from the System Informer repository: https://github.com/winsiderss/systeminformer/issues/1668 https://github.com/winsiderss/systeminformer/issues/1715

You could argue for a separation of the rule for more clarity that's for sure. But the PUA classification is true regardless of it being Process Hacker or System Informer.

The application has functionalities that might be unwanted by some hence why it should be flagged as such :) This is no exception from other PUAs such as NSUDO, RunXCMD and others.

PUA != Malicious

Also the relation between SIGMA and AV vendor doesn't even make sense as SIGMA has no influence over what 29 engines that are currently flagging it.

I'll split the rules for more clarity but I don't agree with reducing the level .

Also as a side note even MS is flagging it as Trojan:Win32/Malgent

What justifies the classification for "PUA"?

The application has functionalities that might be unwanted by some hence why it should be flagged as such :) This is no exception from other PUAs such as NSUDO, RunXCMD and others.

So then all other task manager replacements should be classified the same. To that token, Process Explorer too?

Also the relation between SIGMA and AV vendor doesn't even make sense as SIGMA has no influence over what 29 engines that are currently flagging it.

See Process Explorer: https://www.virustotal.com/gui/file/9bc81060733baf533e0735ef2d869edf1ab7a13a0d107780517e9b9cf3289343/behavior

Compared to System Informer: https://www.virustotal.com/gui/file/6bbded754704ad1c4a84d7216a31a9ffeeac4c4f5be4e213a9ca62c0240d3602/behavior

If the reasoning is, "This is no exception from other PUAs" - then SIGMA must produce a rule for every other task manager replacement that provide identical functionality. This is fundamentally the problem with the "PUA" classification in general, it is completely subjective.

SIGMA doesn't need to provide rules for EVERYTHING let's get that clear. As of today most of the rules provided are for potentially malicious/suspicious or abusable things.

System Informer isn't you're average Task manager. Now even if the naming changed from Process Hacker and the vulns are fixed,...etc. The features it offers are "very good" in its class which makes it interesting for both good and bad parties alike hence why there's a rule for it today. It's because of it's potential "abuse".

Also let me remind you SIGMA offer the rules and don't apply them. If you or anyone find a rule useless it can be disregarded as such.

Process Hacker/System Informer are task manager that can and will be abused hence why it's interested from a detection perspective to flag them as such. They're flagged as PUA to let the admin know that this is a potentially interesting thing you might want to allow or block.

In all cases btw, the best that can happen is that the system informer version will be reduced to medium :) but It will not be removed.

Thank you for taking the time to consider this case. I respect your decision not to completely remove the rule.

Process Hacker/System Informer are task manager that can and will be abused hence why it's interested from a detection perspective to flag them as such. They're flagged as PUA to let the admin know that this is a potentially interesting thing you might want to allow or block.

That's reasonable, and I agree. Having a classification on something to spread awareness for administration is always valuable. And that administrator can make the decision themselves.

It still seems that we aren't on the same page with respect to "can and will be abused", however. But, given your previous comments I believe we're on the same page that System Informer can not be lumped into the same category as Process Hacker was.

I want to also point out that Process Explorer continues to be actively abused. While we have had zero reports for System Informer. So, a strong argument can be made that Process Explorer should have a SIGMA rule. Administrators should have visibility that Process Explorer is executing in their environment.

Also let me remind you SIGMA offer the rules and don't apply them. If you or anyone find a rule useless it can be disregarded as such.

You and I have both been in this industry long enough to know intelligence is shared across the community. An overzealous classification by one has downstream affects on others. When SIGMA rules are deployed to sandboxes and analysis engines this has the potential for vast ramifications. Considering also that some researchers do not do their due diligence. This can result in human error where OSINT is taken as gospel. With all due respect, it's easy to hide behind the, "If you or anyone find a rule useless it can be disregarded as such." but I think we're both wise enough to know that not all engines and are designed with the ability to "carefully disregarding useless information".

In all cases btw, the best that can happen is that the system informer version will be reduced to medium :) but It will not be removed.

Thank you, I think this is a reasonable compromise. I hope a "medium" classification is low enough to get the various sandboxes using this technology to chill the fuck out.

I agree with all your points and between you and me, I myself hate PUA detections as they create false narratives for non-knowledgeable people (as they take it at face value). So I completely understand where you're coming from.

I feel like separating the rule and reducing it to medium is a good compromise. So I will do that today in a PR.

For the process explorer suggestions, you're correct and I will perhaps create one for it. But it'll probably have a low level just because it's more vastly used by MS itself.

Thanks for taking the time to report this and appreciate the discussion.

I wish tools detection were not necessary and we only wrote for the malicious or suspicious behaviour when it happens. But sometimes the low hanging fruits saves the day.

Cheers man :D

Just as a side note, we also recently added rules for potential driver abuse of process explorer and procmon https://github.com/SigmaHQ/sigma/pull/4221/files (in this case is more of a suspicious rule but we're getting there)

Alright, I've split the rules and reduce the severity to medium (will be pushed later today). I hope this is a good middle ground for the discussion.

Let me know if there's anything else I can do to help.

Regards.

For the process explorer suggestions, you're correct and I will perhaps create one for it. But it'll probably have a low level just because it's more vastly used by MS itself.

There should be equal treatment. MS shouldn't be given special treatment. IMO anything classified as "PUA" should always be "low". It's completely subjective. I'm happy we agree on that.

Just as a side note, we also recently added rules for potential driver abuse of process explorer and procmon https://github.com/SigmaHQ/sigma/pull/4221/files (in this case is more of a suspicious rule but we're getting there)

👍 excellent to see the rules being more targeted toward BYOD techniques

Alright, I've split the rules and reduce the severity to medium (will be pushed later today). I hope this is a good middle ground for the discussion.

Thanks for splitting the rules and reducing the severity. Please strongly consider the procexp rule, and please uphold equal treatment. If System Informer is "PUA at medium", then procexp should receive equal treatment as "PUA at medium". Otherwise, both should be reduced to "low".

Thanks for the discussion, it's been a pleasure working with you on this. I appreciate your time and effort. Cheers, o7

PUA != Malicious I myself hate PUA detections as they create false narratives

Is it possible to use a different label like "Controlled Application", "Restricted Application" or some other name so they're not confused with adware/spyware?

Also the relation between SIGMA and AV vendor doesn't even make sense as SIGMA has no influence over what 29 engines that are currently flagging it.

VirusTotal implemented SIGMA on their platform and detections based on these rules end up being send to vendors via their feed endpoint or dumped via report. Some vendors parse the feed for strings like PUA and automatically create signatures based solely on that information in an effort to provide better response to customers - PUA is assumed adware/spyware.

A vendor that @jxy-s and I spoke with just pointed to VirusTotal so we wanted to remove the label so they don't have an excuse:

System Informer isn't you're average Task manager. The features it offers are "very good" in its class

System Informer and Process Hacker have been competing with Microsoft Sysinternals for 14 years and everything can be found in Sysinternals tools: https://learn.microsoft.com/en-us/sysinternals/downloads/

The only difference is Sysinternals tools are separate console tools while System Informer has a single UI. If you review the parameters (and some undocumented parameters) Sysinternals tools have considerably more information and functionality.

If you compare Handles, Autoruns, VMMap, RAMMap, ProcDump, Process Explorer and other tools with System Informer then you'll see they're very similar but Sysinternals tools have more functionality than what's available with System Informer.

Just as an example livekd is able to dump every process, structure, address, object, type, token, context and entire kernel at runtime by copying livekd64.exe into C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 and running commands:

https://user-images.githubusercontent.com/1306177/236846795-1083c315-ca3f-4f3c-8fd7-5c4a2215de1a.png https://user-images.githubusercontent.com/1306177/236846869-b854ac34-c9fc-4a68-b9fd-542192586c17.png https://user-images.githubusercontent.com/1306177/236846939-13a0e8d0-e13d-4ac0-808d-d6c4004fe633.png

They're dumping the entire kernel and no vendor consider Sysinternals binaries PUA. System Informer can only show information provided by the Windows API and we're labelled PUA... This is a really strange double standard and doesn't make sense.

System Informer are task manager that can and will be abused hence why it's interested from a detection perspective to flag them as such.

can and will be abused is an assumption or based on evidence?

Everyone can limit or disable System Informer functionality using the ObRegisterCallbacks function.
Security vendors can enable PPL for additional control and those polices are enforced: https://github.com/winsiderss/systeminformer/blob/master/KSystemInformer/verify.c#L396-L400

These changes and others where requested by vendors and block any potential abuse.

makes it interesting for both good and bad parties alike hence why there's a rule for it today They're flagged as PUA to let the admin know that this is a potentially interesting thing you might want to allow or block.

"interesting" would be a better label than PUA 😋

Now even if the naming changed from Process Hacker and the vulns are fixed,...etc.

Process Hacker was labelled PUA because it's vulnerable to attacks by system administrators. System Informer doesn't have this issue and was not abused and we've made changes as requested by vendors.

Is there a time limit or some criteria to remove the classification or will System Informer be permanently labelled PUA?

System Informer is a PUA for the simple reason that it has functionalities that could "undesirable" by some and not offered by default. This is also True for Process Explorer and many others but we can't write rules for everything.

Rule are written for behaviour generally and tool based rules are written for tools that are abused or "potentially" abused.

Since System Informer has an indirect link with Process Hacker when people look for tools that can "manipulate" processes they'll eventually find it hence why its "interesting" more than other tooling and why there is a rule for it.

Just to jump on your different examples about the Sysinternal Suits. I have no horse in this game. For example we have rules that look for PsLogList a tool that check logs :) and even have some for LiveKD https://github.com/SigmaHQ/sigma/blob/f3104f748fe69fc9abb655a17743cf236c50dc01/rules/windows/builtin/appmodel_runtime/win_appmodel_runtime_sysinternals_tools_appx_execution.yml

We have these because we either found some interesting way of them being used as LOLBINs or being abused previously by TAs

Now to get back to Process Explorer. One thing to note, Porcexp doesn't have the same connotation as Process Hacker/System Informer and is/wasn't nearly as abused. I agree that System Informer is a step in the right direction with the rename and re-write of the portion of code and the effort to make it safer is more than appreciated. Hence why I agreed on the separation of the rule and reduction to medium.

I understand your frustration trust me but one thing is that the severity is an indication of interest. In SIGMA low rules are usually reserved for noisy less interesting things and medium is for stuff that should be looked at. And usage of External process managers such as System Informer should investigated by any SOC analyst if it's not allowed. But if it's something that's allowed in an org then I recommend to not use the rule because it becomes and FP generator.

Taking your comment about AV vendors at face value, Understand that I can't control how this rule is used by other unfortunately. We provide a falsepositive section that indicates that this could be FP and with the future update I updated it to reflect this and updated the description as well to make it as clear as possible :)

The PUA in the title is a convention we use for similar tools not only SystemInformer

Trust me SIGMA isn't the culprit here. These are only detection rule meant to be used by professionals. It's the many AV that alert without any further information that creates the STIGMA around a tool.

Anyway hope this clarifies some things (sorry I wrote a lot). Happy to talk about any other point you have :) and thanks for your understanding.

SigmaHQ / sigma