A new event id for the use of EncodedCommand parameter

[zbalkan]

Currently, the use of encoded command is the same with any other invocation and logged with Event ID 4103. However, 90% of PowerShell users, sysadmins, devops people, and other do not utilize this feature very often. We see this specific use case mostly when an attacker tries to utilize PowerShell. Therefore, I suggest adding a check in the run, and log the event not with the Informational Level Event ID 4103 (Pipeline_Detail = 0x1007) but any other ID, like 4102 or 4107. Then, the definition of i.e. Pipeline_Encoded_Detail = 0x1006 or Pipeline_Encoded_Detail = 0x100B, with the same information, yet with a separate event ID and as Warning severity, would simplify security efforts to catch the use of encoded commands. Then, it would be up to the security staff to work on false positives, instead of trying to create dozens of rules to detect it.

Even though we want to prevent malicious commands being executed, it is impossible to listen to the event log and interrupt the process. What we can do is only detection and detection requires effort, mostly with Regex. There are "over 100,000 variations" according to the analysis. Even then it is not enough, you need additional work. A separate event would help security community a lot.

While many admins asking if it is possible to disable running EncodedCommand altogether and it would be great if it would be possible to disable it via a GPO, improving detection is a giant leap.

[jborean93]

While many admins asking if it is possible to disable running EncodedCommand altogether and it would be great if it would be possible

Please no, I hate with great intensity when AVs block this. I want to be able to run a command without having to deal with dealing with quoting problems. Giving someone the option to block -EncodedCommand will just have malware writers move onto other mechanisms like piping commands over stdin breaking a very useful option for everyone else. If you are concerned about people running malicious PowerShell commands then using tools like Applocker or constrained language mode is IMO the better option.

[zbalkan]

Even though I agree that it is a usable feature, especially tools like SCCM - ccm.exe uses this very broadly, I do not suggest disabling this by default.

In sum, I have two suggestions to discuss:

1. A separate event ID when encoded command is used so that it is easier to filter by SIEMS,
2. An capability to be able to disable encoded commands

I personally believe people should be able to manage their tools. If they want to make a trade-of between security and usability, they should be able to have that option. It might be a less secure option for backward compatibility issues or a more secure option when it comes to detect suspicious actions.

Still, I do not insist on second one. My focus is on the first item. Instead of using complex regexes and stuff, catching the event ID would improve the workflow a lot.

[kilasuit]

I can definitely see the benefit of an event ID for when encoded commands are used even though they are used legitimately.