dingusxmcgeeMar 24
Wietze

By making minor changes to command-line arguments, it is possible to bypass EDR/AV detections.

My research, comprising ~70 Windows executables, found that all of them were vulnerable to this, to varying degrees.

Here’s what I found and why it matters 👉 https://wietze.github.io/blog/bypassing-detections-with-command-line-obfuscation

Bypassing Detections with Command-Line Obfuscation

Defensive tools like AVs and EDRs rely on command-line arguments for detecting malicious activity. This post demonstrates how command-line obfuscation, a shell-independent technique that exploits executables’ parsing “flaws”, can bypass such detections. It also introduces ArgFuscator, a new tool that documents obfuscation opportunities and generates obfuscated command lines.

Mar 24 at 9:08amWeb
Show threadArielMar 24
@wietze good grief lol
Show threadMichał "rysiek" Woźniak · 🇺🇦Mar 24

@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.

Show threadMatt OrganMar 24
@wietze after learning a few years back about how unexpectedly successful bypassing EDR was simply by recompiling for x64, I'm not surprised in hindsight hearing these techniques but still very cool.
Nice work 😎
Show threadDominik GrabiecMar 24
@wietze
Looks like they don't follow Microsoft's own algorithm for processing of command line parameters.
Show threadOriel Jutty Mar 24

@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?

Getopt Long Options (The GNU C Library)

Getopt Long Options (The GNU C Library)

Show threadWietzeMar 24
@barubary Your analysis is spot on. EDR vendors have used the same "command-line arguments are one big string, YOLO!" model for ages and it simply doesn't work well for exactly these reasons. I hope vendors take notice and do more to interpret/parse/preprocess command-line arguments going forward.
Show threadChristophe Mar 24
@wietze This is so cool! Love ArgFuscator, would be cool to allow for an OS filter to generate commands working for Linux/Windows/Mac
Show threadWietzeMar 24
@christophetd it's in the works! 👌
Show threadKotesMar 24
@wietze Very interesting and exciting text. Thank you.
Windows is such a fragile system that no matter how many letters you replace with strange shapes, it still reads them.
Show threadLes antibiotiques causent l’autisme, vaccinez-vousMar 24
@wietze Cover featuring a glossy Windows 11 command prompt in a blue-ish background #Alt4You
Show threadBert DriehuisMar 24
@wietze It's not just the response part of EDR that's a challenge. Most log data lakes are Lucene based, and apparently it can't do case independent search. Some tools (e.g. graylog) recommend to map all Windows log to lowercase at log ingestion time for this reason. It's been a while since I looked into it, but at the time all popular solutions failed here.