I posted a version of this earlier in a different community and got some solid technical pushback that improved the queries. Sharing the updated version here with those fixes included.

This covers suspicious LOLBin execution and PowerShell abuse detection. All of this runs in production environments. The gaps people called out are addressed below each query.

Query 1: LOLBin abuse via unexpected parent process

____________________________________________________________

#event_simpleName=ProcessRollup2

ImageFileName=/\/(certutil|mshta|wscript|cscript|regsvr32|rundll32|msiexec)\.exe$/i

| where CommandLine!="" AND ParentBaseFileName!=/explorer|services|svchost|msiexec|taniumclient|ccmexec|devenv/i

| table u/timestamp ComputerName UserName ImageFileName CommandLine ParentBaseFileName

| "sort" u/timestamp desc

____________________________________________________________

What to flag: certutil with -urlcache downloading from external URLs, mshta calling remote URLs, wscript or cscript running from Downloads or AppData.

note: correlate the first network touch or file write after execution, not just the command line. The child behavior after execution is where real conviction comes from, especially in environments where build tooling uses these binaries legitimately.

Query 2: PowerShell spawned from Office or browser

____________________________________________________________

#event_simpleName=ProcessRollup2

ImageFileName=/\/powershell\.exe$/i

ParentBaseFileName IN ("WINWORD.EXE","EXCEL.EXE","OUTLOOK.EXE",

"chrome.exe","msedge.exe","firefox.exe","wmiprvse.exe")

| table u/timestamp ComputerName UserName CommandLine ParentBaseFileName

| "sort" u/timestamp desc

____________________________________________________________

What to flag: -EncodedCommand in the command line, IEX or Invoke-Expression, DownloadString or WebClient, Bypass -ExecutionPolicy.

Query 3: Encoded command with payload decoding

This was called out as a gap in my previous post. The original query only flagged the EncodedCommand parameter without decoding it. Here's the fix that gives you actual payload visibility:

____________________________________________________________

#event_simpleName=ProcessRollup2

ImageFileName=/\/powershell\.exe$/i

| where CommandLine contains "-EncodedCommand"

| extend decoded = base64_decode_tostring(extract("-EncodedCommand\\s+([A-Za-z0-9+/=]+)", 1, CommandLine))

| where isnotempty(decoded)

| extend payload_type = case(

decoded matches regex "(?i)(IEX|Invoke-Expression|DownloadString|WebClient)", "high",

decoded matches regex "(?i)(bypass|hidden|noprofile)", "medium",

true(), "review"

)

| table u/timestamp ComputerName UserName decoded payload_type

| "sort" u/timestamp desc

____________________________________________________________

Query 4: Reflective loading detection

Another gap flagged in the community. Byte array combined with XOR is a strong indicator of shellcode staging before reflective load.

____________________________________________________________

#event_simpleName=ProcessRollup2

ImageFileName=/\/powershell\.exe$/i

| where CommandLine matches regex "(?i)\\[byte\\[\\]\\]|\\[Byte\\[\\]\\]"

| where CommandLine matches regex "(?i)-b[Xx][Oo][Rr]|-bxor"

| where CommandLine matches regex "(?i)(ReadAllBytes|MemoryStream|Reflection\\.Assembly)"

| table u/timestamp ComputerName UserName CommandLine

| "sort" u/timestamp desc

____________________________________________________________

XOR combined with ReadAllBytes or MemoryStream is shellcode decryption before load. Reflection.Assembly catches most classic reflective PE injection patterns.

Query 5: Behavioral baseline layering

Someone in the previous thread suggested layering definetable to profile 30 days of normal behavior then alerting only on net new activity. That's the right approach for reducing false positive noise. Profile the 30 day window, set detection to last 1 day, anything that hasn't seen before in that baseline is automatically higher fidelity.

For tuning these in your environment

Run each query in detection-only mode against 30 days of historical data first. Anything that fires more than 3 times from the same parent on the same host, investigate once and either add to the exclusion list or escalate. A week of baseline work gives you a rule with almost zero false positive noise in production.

On SCCM scripts specifically, the parent process exclusion handles most of it but the cleaner architecture is enforcing script signing through SCCM itself and alerting on any unsigned execution regardless of parent. Most orgs aren't there operationally yet but it removes the allowlist dependency entirely.

Happy to share Sentinel KQL and Splunk SPL equivalents in the comments if useful.