FalconFriday — Catching more macros— 0xFF0A

In this year’s final FalconFriday we revisit the possibly most loved and hated feature of both attackers and defenders: MS Office macros. We’ll provide 2 hunts for macros that are downloaded using the browser and are spawning child processes. As a Christmas bonus, we have some ideas for you to enhance those queries even further.

Before we kick off: FalconForce is hiring — check out our vacancy and apply if you think you match the criteria. :-)

MS Office document opened from browser

Blue: The first hunt for this week is mainly based on the parent-child relationship. As most organizations are already blocking attachments that contain macros, attackers are diverting to emails which contain a link for the file downloads. This hunt looks for an MS Office process that creates a child process, where the parent of the MS Office process is a browser. It’s a fairly straightforward query, but unfortunately gives a significant number of false positives. The naive guy in me was expecting that MS Office applications would rarely spawn any child processes, but that’s very naive. MS Office applications spawn a lot of child processes, but which and why is outside the scope of this blog post.

Most organizations can get away with filtering a number of common child processes and have a decent list of potential true positives. I’ve put the most common ones already in the query. One common file which is not in the whitelist is RunDLL32. RunDLL32 is triggered quite often from MS Office applications, mostly for printing purposes from what I’ve seen, but you don’t want to whitelist all RunDLL32 executions. Just specific ones for your printer driver, or whatever it’s used for in your environment. The same holds by the way for other LOLBINs.

You can find this query here. Also, check out all our other queries in the repo.

As always, make sure to whitelist based on full path or other properties, instead of only on file name. Moreover, this hunt is for the most commonly used MS Office applications: Word, Excel and PowerPoint. You should consider including other MS Office applications that support macros (e.g. Publisher, Visio, Access, etc.).

A final remark: we have a number of improvements at the end of this article, to further increase the accuracy.

Red: If you’re up against a decent blue team that has whitelisted the full path instead of just the filename, your main option would be to do process injection. Doing process injection from an MS Office process is always a bit of a trade-off as it’s super dodgy behavior. Spawning a child-process in that sense is less suspicious for MS Office processes than doing process injection.

Another option is to try to fit into the whitelist by abusing LOLBINs. However, again, any decent blue team will have LOLBIN abuse covered in another detection/hunt. Moreover, blue teams will likely not whitelist LOLBINs for this rule, so this is a long shot.

If you’re lucky and this rule is implemented based on file names only, instead of full paths, bypassing this hunt will be easy. Just drop a malicious .exe on disk with a file name that is whitelisted and run it.

MS Office file downloaded and opened which spawns child processes

Blue: Although this hunt seems similar to the previous one, the approach is slightly different. Instead of looking at parent-child relationships, we look at “FileCreated” events and correlate these events with network events. The advantage of this approach is that it allows us to whitelist certain hosts/domains which we trust. If you’re hunting for external threats, you can whitelist your internal network shares and SharePoint to minimize the noise.

So the query first looks for MS Office files which are created by a browser (i.e. file download), next tries to identify from which hosts these files are downloaded based on network traffic in the same time-window from the same device, and filters out all remote hosts from the whitelist. This is the list of all potentially malicious MS Office files.

Finally, it lists all MS Office processes which open the aforementioned downloaded file and have created child processes.

You can find the query here. Also, check out all our other queries in the repo.

As always, the queries require your customization: some fine-tuning is required to make sure the whitelist is accurate and doesn’t allow for easy bypasses.

Red: The exact same holds for this hunt as for the previous one.

Improvements

Both queries are fairly decent in terms of accuracy. However, there’s always room for improvement. As a small Christmas present, we’re outlining all the potential improvements we would do for our clients, to further improve the accuracy of the hunts.

You can use these improvements either on top of the whitelisting or (partially) instead of, depending on your environment and needs.

1. MS Office process which actually run VBA need to load VBE7.dll. You can improve the accuracy by only considering MS Office processes that load VBE7.dll. Especially for files in the old MS Office formats, this is a great trick to reduce the false positives.
2. If you’re not filtering mail attachments containing MS Office documents (.doc, .docm, .xls, .xlsm, etc.), you can apply the same approach but use the “EmailAttachmentInfo” table as your entry point.
3. Moreover, if you’re not filtering mail attachments, you can filter for outlook.exe as grandparent instead of a browser.
4. The current whitelist of remote hosts for the second hunt only performs full host name matching. You can extend this to perform subdomain matching using regexes or IP-range matching using ipv4_is_match()/ipv6_is_match.

So, that’s it for this year: 2020’s final FalconFriday. We had great fun creating these and learned a ton in the process. We also want to thank everyone for your valuable and positive feedback. This helped us to keep pushing the quality of our content!

Stay healthy, stay safe and we wish you great holidays. See you next year!