FalconFriday — Detecting ASR Bypasses

FalconFriday — Detecting ASR Bypasses — 0xFF17

TL;DR: Today’s blog is about detection of a bypass for the ASR rule “Block Office applications from creating executable content”. FalconFriday content is now also available in the Azure Marketplace!

We’ve seen that the more mature organizations often deploy ASR (Attack Surface Reduction) to further enhance resilience against advanced attacks. ASR in “block” mode makes it significantly harder for attackers to abuse Office features for gaining code execution or persistence. Today, we want to highlight an ASR bypass which we found (and later figured out it was already documented).

Background

As the name of the ASR rule suggests, it blocks Office applications from creating files which are considered to be executable files. Obviously, these are the “normal” PE files which are being blocked (binary files), but also some unexpected files such as .js, .ps1, .vbs, .lnk, .ico, .bat, .cmd, .xll, etc.

Weirdly enough, ASR makes a distinction when the ASR rule triggers between binary and text files. We haven’t tested all extensions, but in our limited testing, the rule behaved differently when dropping a .js or .vbs file as opposed to dropping a .dll or .exe file.

Red

In our testing to find a bypass, we found a trick that worked for text files. You can drop your desired test file with a random extension that is not monitored (i.e. .txt) and then rename the file to the blocked extension and ASR will not trigger. Emeric Nasi documented this and other bypasses way before we found them.

For some unknown reason, this trick doesn’t work for binary/executable files. We tried this with .dll and .exe files, but ASR triggered when writing these binary executables files to disk with any extension. Luckily for the red side, there is also an (undocumented?) bypass for writing these files to disk. Microsoft doesn’t seem to patch ASR bypasses, as ASR is an anti-exploit technique. As far as we know, none of the anti-exploit bypasses have been patched (ASR/DEP/ASLR/…). Hence, we feel it’s irresponsible to disclose it publicly.

Blue

Once you know the trick to bypass the ASR rule, building the detection is fairly straightforward. We’re looking for Office applications that create a new file on disk, and then rename that file’s extension with an extension that is blocked by ASR. There are some weird quirks and false positives in some environments, but it should be fairly easy to filter those out based on the location where the file is written to, filename/extension, etc. As usual, you can find the rule in our FalconFriday repo. As of now, our FalconFriday content is also available in the Azure Marketplace! We will add the latest FalconFriday content to the Marketplace once every quarter.

Please note that this ASR bypass (and hence, the detection rule) only works for text files. We have chosen not to share the bypass for binary files and corresponding detection rule. That would make it very easy for real, malicious attackers to abuse this bypass. As far as we’re aware, this bypass has not been (publicly) documented. Reach out to us if you’re interested in the detection logic.