Research

Detection Pitfalls You Might Be Sleeping On

Detection engineering isn’t just about finding bad behavior. It’s about understanding how attackers appear normal — on accident or by design.
Some of the most successful evasion techniques don’t involve zero-days or encryption — they rely on you writing rules that miss the small stuff.

In this post, we’re covering 5 common detection pitfalls that allow threats to bypass even “well-written” rules. These are bugs not in your tools, but in your assumptions.

Let’s get into it.

1. Parameter Variation: The -EncodedCommand Problem

Some of us probably tried (at least once) to detect base64 PowerShell commands with -EncodedCommand, right? Great.

But did you know that there are at least 24 different ways to invoke that same flag?

  • -EncodedCommand
  • /EncodedCommand
  • -enc, /enc, -e, /e, -en, etc.

And yes — they’re all valid.

This works due to some processes parsing only the first letter of the parameter, disregarding anything that comes after it. More information on THIS (X)Twitter post and THIS Splunk post.

Attackers (and red teamers) have known this for years.
But many detection rules only look for -EncodedCommand or -enc, completely missing the obfuscated ones or those with slashed flags.

🔍 Detection Tip:

Implement regex or wildcards in your searches. This might increase false positive rates, but will catch even the outliers.

2. Redirection & Chaining: When One Command Becomes Two

Based on the research from Kostas: https://detect.fyi/unintentional-evasion-investigating-how-cmd-fragmentation-hampers-detection-response-e5d7b465758e

Characters like |and & are deceptively dangerous in the context of detection.

Why?

They cause a single command to split into multiple process executions or event log entries — especially in Windows Event ID 4688, which captures process creation.

Example:

whoami & ipconfig

Due to the & character, this single command will be split into two distinct event log entries:

🔍 Detection Tip:

This easily can be tackled via timeframe-based correlation rules, or by writing a single rule to detect the “more” malicious part of a chained command. For example:

C:\WINDOWS\system32\cmd.exe /C cmd.exe /c echo J9kzQ2Y0qO |C:\ProgramData\anydesk.exe --set-password

Writing a rule that will detect “.exe — set-password” instead of the entire command string.

3. The Double Space Issue

Let’s say you have the following SIGMA rule:

Are you able to identify the issue with it? it’s a bit tricky!

Some binaries, like ipconfig, net.exe, and net1.exe, insert two spaces in the command line. So a detection rule that looks for a process that is affected by this issue with a single space in the parameter — will fail. I have created a thread about this issue pretty long ago, and there are some good discussion points over there. The last comment from the thread:

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)

🔍 Detection Tip:

This can easily tackled with double conditions. So instead of detecting “CommandLine=”*ipconfig /all*”, detect “CommandLine=”*ipconfig*” AND CommandLine=”*/all*”, for example.

4. Command Obfuscation

No detection article is complete without talking about obfuscation — but this isn’t just about base64.

Attackers:

  • Use backtick escape sequences
  • Encode characters in Unicode
  • Use carets (^) to break strings
  • Insert null bytes, non-breaking spaces, or quote juggling
Process name will stay the same, even though the command is obfuscated.

🔍 Detection Tip:

Layer in entropy scoring or unusual character detection to catch overly complex command lines. Further research on obfuscation by DanielBohannon and Wietze. Wietze also created https://argfuscator.net/ which is really cool to mess around with.

5. Unaudited Commands

Some internal CMD commands don’t generate process creation logs, even though they were run.

Commands like:

  • assoc
  • copy
  • ftype
  • del
  • and more

If you’re relying only on process creation telemetry, you might never see these.

🔍 Detection Tip:

This one is a bit tricky — based on activity in the wild it SEEMS like attackers will mostly use commands like this as part of “cmd.exe /c” which WILL log these in process creations. If this will not be the case, I don’t have anything smart to add to it. If you do, let me know!

Final Thoughts

These aren’t edge cases. These are intentional cracks in the surface of detection logic that attackers use every day.

And the worst part? Most of these behaviors don’t even look malicious.
They just behave differently enough to slip through lazy rules or fragile detection stacks.

As a detection engineer, your job isn’t just to match known bad.
It’s to know the intricate and hidden parts of our telemetry, and write rules that are resilient and future-proof as possible.

If you enjoyed the article, feel free to connect with me!
https://www.linkedin.com/in/daniel-koifman-61072218b/
https://x.com/KoifSec
https://koifsec.medium.com/