How to Blue Team: Detecting WinRar Ace32 Exploits (CVE-2018-20250) Using Sysmon

Ryan Glynn/ March 26, 2019/ Security and Technology/ 0 comments

Introduction to How to Blue Team:

There’s a lot of documents on how to use pen testing tools, how to crack, hack and break into things. Not a lot is written on how to detect these things, especially at the “Enterprise” level where a lot of the blog posts seem to give use cases that do not scale well. So, I figured I would share the things that I learn and what I feel are important aspects of Blue Team Monitoring that do not have good resources currently.

One thing to note about these posts is that they are platform independent. What does that mean? It means that I am not going to be posting “Splunk syntax” or “Elastic Syntax” or any platform specific methods of detection but rather I will tell you how to detect it regardless of which platform you run within your enterprise. While there are cool projects like https://uncoder.io/ – a lot of the posts I am going to make are not supported by this project due to some platforms not having the same functions as others.

Detecting WinRar Ace32 Exploits (CVE-2018-20250) Using Sysmon

Cyber Kill Chain Category: Exploit

Fidelity: 5/5 (Very High)

Purpose and Goal

The goal is to detect any instance where Ace32 is instantiated from WinRar. According to the CVE Details, the vulnerability allows for attackers to perform full directory traversal, including but not limited to putting malicious executables hidden from the zip file into the all user’s startup folder and running as administrator even if the user is not an administrator. This exploit is currently not caught by Cylance. For additional reading please reference: https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-exploiting-winrar-unacev2-dll-vulnerability-cve-2018-20250
and also
https://nvd.nist.gov/vuln/detail/CVE-2018-20250

Data source(s) needed:

  • Sysmon or endpoint monitoring equivalent for Windows hosts (not Windows event logs)

Writing the Alert

This alert is super simple and given the amount of buzz this exploit has been generating it should be a relatively quick implementation.
1. Sysmon Event ID 1
2. Image ends with “\Ace32Loader.exe” (the backslash is to ensure the executable is purely that name)
3. [Optional] The parent image ends with “\winrar.exe”

That’s it! The third criteria is entirely optional, doesn’t change any results from tests I’ve performed however there is always the chance there is some legacy application that uses “Ace32Loader.exe” or some other odd use case. Personally, I do not think option 3 should be included unless necessary just in case malware prepackages winrar.exe and calls it something else.

Breaking the logic down:

This is a very straight forward alert. Winrar, up until the most recent version (as of March 2019) had the ability to execute Ace32 code within rar files. In order to do this however, it utilized an executable outside of winrar.exe called Ace32Loader.exe. The simple fact that WinRar calls Ace32Loader.exe means that a person opened an Ace32 embedded RAR file – something that should almost always be investigated, especially now.

If for some reason your environment has things that use Ace32Loader.exe then by all means include the optional third criteria listed above. If for some reason you have legitimate RAR files in your environment that run embedded Ace32 code — I don’t know what to tell you because outside of this one artifact, no other logs were generated to indicate this exploit.

How to Investigate

As noted above, there are no other logs generated (unless you turned on FileCreate for all files on a system which is doubtful). There is asomewhat annoying problem with this:
The file(s) that are created from the embedded code are not logged anywhere (within Sysmon)

Using the parent command line field within this event will reveal the exact RAR file that was extracted. From here it is important to pull back how the user got it and whether or not it was truly malicious. Unfortunately, without having FileCreate turned on for all files (or at least .exe) on the host will prevent most detection of what file(s) were created. Though checking the host’s PowerShell logs will also be a good indication as a lot of the current malware uses PowerShell afterwards.

Share this Post

Leave a Comment

Your email address will not be published. Required fields are marked *

*
*