A flaw in the .NET Core library lets malicious programs to be unveiled while escaping exposure by security software.
Caused by a unique bug in Microsoft’s .NET Core library, this flaw lets malicious trash collection DLLs be loaded by users with low privileges.
This bug impacts the latest steady release (3.1.x versions) of .NET Core. A solution is not presently available and could allow hackers to carry out malicious code on a system without being willingly spotted by antivirus and EDR products.
.NET Core uses a ‘garbage collector’ to assign and make space for system memory used by a .NET Core application.
However, users are likely to create custom garbage gleaners in the form of DLLs that a .NET core application will load.
.NET Core, however, lets any user, including those with low privileges, load a custom garbage collector DLL, even those comprising malicious code.
Prior to abusing this fault, the hacker already needs to have at least some level of access to the system to set setting variables. That means this fault would convincingly be used in combination with a current exploit, such as in a susceptibility binding situation.
The key incentive for an attacker to integrate this attack in their toolkit would be to avert their malicious payload from being spotted by security software running on the compromised machine.
To take advantage of this bug, a hacker would first create a custom garbage collector comprising malicious code that they want to perform on a compromised machine.
The researchers at Pentest Laboratories further examined this susceptibility and provided added understanding.

The investigators clarify that the exploit uses what’s known as a process hollowing method.
“Paul Laîné in his proof of concept used the technique process hollowing to inject code into a legitimate process since the process is created in a suspended state, memory regions are not mapped to a file and are replaced by the actual shellcode,” explains the Pentest Laboratories blog post.
Since the malicious code implementation happens under a genuine process, this method is beneficial in dodging severe detection and defense controls employed by security software products.
Microsoft, however, does not consider it a security flaw as the misuse of this mechanism needs that the attackers to have already the capacity to set environment variables on the compromised system.
“Per MSRC, we do not consider this to be a security vulnerability. Exploiting this would require the adversary to modify the environment block, at which point they’re already in control over other aspects of the application’s execution.”, stated Microsoft’s representative in the GitHub issue.

Leave a Reply

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