Skip to content Skip to bottom

848 Group - Modern IT Services For The Modern Workplace.

Contact Us

How To Identify And Block CVE-2021-41379 Using Only Endpoint

Blogs and insights Security

I have been thinking of the easiest way to deal with the InstallerFileTakeOver payload that takes advantage of CVE-2021-41379 – an active zero-day vulnerability. This blog is a limited Proof of Concept (PoC) which makes several assumptions and aims at providing insights into what can be achieved using Microsoft Defender for Endpoint.

Disclaimer

This approach assumes you are already using Defender for Endpoint in your environment, and you want to get a quick win. It could also serve as a PoC, but this is by no means a finite method of dealing with zero-days. Zero-days can only be prevented by Microsoft removing the vulnerability from their code.

The key driver of this PoC is answering the question, “If you already have Microsoft Defender for Endpoint, what’s the easiest way to mitigate this zero-day threat?”.

It might be of interest to you if you are planning on implementing Defender for Endpoint in your environment, which is something that our team at the 848 Group can assist you with.

Assumptions

In this PoC, I am making a critical and potentially fallible assumption that most threat actors do not necessarily have the technical skills to write in C++ or C, and that they would download this file from GitHub as-is, then incorporate into their techniques to gain elevated privileges.

The File Hash as a Unique Identifier

The file hash for the as-is payload under this situation is the following:

37ff2ed054e6ef0d9f792ee8d190bdb6951ce0aace044611d91d8b595c5737d7

Using the File Hash Indicator in Defender for Endpoint, we can create Custom Threat Indicators (CTIs) that recognise the hashes of the payload across all of our Defender for Endpoint-enabled devices and therefore stop the risk of attack at its source.

File Hash example

In order to replicate the attack scenario presented by Abdelhamid Naceri, I ran the payload on one of my lab devices. This resulted in the following on the user end:

Microsoft Defender for Endpoint virus and threat protection example

And on the device alerts (with the device being configured to auto-remediate threats):

Microsoft Defender for Endpoint device alerts

Here we take a closer look on what was auto remediated based on the custom TI:

Microsoft Defender for Endpoint Block and Remediate

From the file page we can see all the related .msi observed by Microsoft Defender for Endpoint:

Microsoft Defender for Endpoint .msi

From the incident view this is how it looks (the highlighted section is Defender being able to identify this is a risky file when I initially tried to download this from GitHub on my lab device). This essentially means that this pathway is already being taken care of by Microsoft who will assign the file a “malware” classification and auto remediate.

Microsoft Defender for Endpoint Block and Remediate example

#Open Parentheses

Under a proper hardened environment, the user would not even be able to download or select to bypass and keep the file as this behaviour could be blocked through an associated Endpoint Manager configuration profile:

Microsoft Defender for Endpoint #open parentheses

Since we are “talking” workarounds, until the zero-day is patched it wouldn’t be a bad idea to block access to github.com if you don’t operate in the IT services or software development industry.

#Close Parentheses

It is equally interesting that the incident page graph view which as expected, shows that the ‘system’ account was involved in this incident even though this was a standard user:

Microsoft Defender for Endpoint #close parentheses
Microsoft Defender for Endpoint example

Epilogue

As described in the introduction of this blog the intent here is to provide additional insight on the capabilities of Microsoft Defender for Endpoint, and how these can be elevated to achieve a quick win against any file-based attack.

Is this an answer to the CVE? Certainly not. The answer will come with Microsoft patching the vulnerability.

Is this the optimal answer? Not at all. It is probably though the easiest automated response if you are already onboarded in Microsoft Defender for Endpoint which would cover attempts from non-advanced threat actors.

Other more holistic answers to this attack would include as pointed by my colleague Jack Lee at 848 Group’s Cyber Security Practice:

  • Hunt for any 1033 events in the Application Event Log with a package name of ‘test pkg.msi’.
  • Using a YML file to add detection to your environment of preference:

https://github.com/SigmaHQ/sigma/blob/497a9d9e2adde6b46b8870406ced239a6752f729/rules/windows/file_event/file_event_cve_2021_41379_msi_lpe.yml

https://github.com/SigmaHQ/sigma/blob/497a9d9e2adde6b46b8870406ced239a6752f729/rules/windows/process_creation/win_exploit_lpe_cve_2021_41379.yml

https://github.com/SigmaHQ/sigma/blob/db03d08b1105f33de763187da7681725ba70accd/rules/windows/builtin/win_vul_cve_2021_41379.yml

  • Mitigating the attack using AppLocker to configure restrictions so that only signed MSIs and application packages can be run on a system.

Discover more about Microsoft Defender for Endpoint by getting in touch with 848

If you want to know more about Defender for Endpoint capabilities, or are seeking guidance on the security of your working environment, get in touch with the 848 Group. 848 has an expert team of cybersecurity specialists and a dedicated security practice.

Jump to Section: