@wietze

image description:

Screenshot showing a Windows desktop with a web browser open on argfuscator.net and a terminal where original command fails to execute due to lack of privileges, but an obfuscated version works fine.

@wietze After looking at the "Linux and macOS" section", my main takeaway is that apparently a lot of defensive software was written by muppets.   

For example, take option reordering, option separator insertion, and option separator deletion. All of these are about classic unix option syntax as implemented by getopt():

• Options can be reordered (foo -a -b -c is equivalent to foo -c -b -a).
• Multiple options in a row (all starting with -) can be bundled together (foo -a -b -c is equivalent to foo -abc).
• Options that take an argument do so either from the rest of the command-line parameter or (if that is an empty string) the next parameter (foo -s bar is equivalent to foo -sbar).

Why would you not take that into account in your detection tools?

Similarly, character deletion springs from the idea that long option names can be abbreviated as long as they're unique. GNU's getopt_long automatically provides this feature (as do other libraries). Again, this is not a rare or obscure feature.

Any "detection" bypassed by these tricks focuses too much on superficial syntax and not what the command-line arguments actually mean. But in cases where attackers abuse trusted tools ("lolbins", etc), we know exactly what those tools are and how they work. (After all, they're standard system tools and that's why we trust them!) So on the defenders' side, why would we not model the tools' command-line interface precisely and instead rely on crude substring matching?