CSIS RESEARCH - Windows Covert Compilers I

A three-part blog series focusing on the Digital Forensics and Incident Response aspect of the compilers shipped with the Windows operating system and their usage from PowerShell.

• Part I: C#, Visual Basic and JScript – all within PowerShell
• Part II: Under the Hood
• Part III: DFIR Artifacts

Introduction

The presence of one or more compilers is anything but surprising on the workstation of a software engineer or a power user, whereas the typical office, or home setup is expected to be devoid of such applications as their users don’t need to turn source code into an executable.

Yet if Microsoft .NET Framework 2.0 or higher is installed, stand-alone compilers for three programming languages are present on the system by default. They are accessible from Windows PowerShell 2.0 or higher [1] (that of course requires the aforementioned version of the .NET Framework), and there is a cmdlet as well, to further ease creating and using .NET assemblies directly from source code.

The wide availability of this feature, and the fact that all functionality provided by the .NET Standard libraries is accessible through its interface makes it handy for automation tasks, and for making configuration changes on the system. In fact, such scripts are extensively used "behind the scenes" by applications and administrators alike for benign purposes.

Unfortunately, even though this feature and its misuse by malicious actors has been around for a long while [2], it still pops up quite frequently during our assignments. The endless amount of possibilities to obfuscate both the embedded and the PowerShell code in order to evade detection helps the adversary, also along with the fact that the prerequisites are always available on the system.

In this series, we’ll first give a short overview of these compilers and their usage from PowerShell, then present some of the artifacts that we look for in a typical DFIR case.

Executables

The executables listed below are located at %SYSTEMROOT%\Microsoft.NET\Framework*, but additional copies of them might exist elsewhere, due to multiple installations of the .NET Framework or other tools deploying them.

In addition to that, adversaries could "drop" these as well.

All of these compilers are able to create .NET assemblies from C#, JScript and VB .NET source code respectively. Their actual usage is beyond the scope of this post, but each of them lists the available options if executed with the /? parameter from the command line.

Being a part of the operating system, "known good" executables – (LOLBAS), signed by the vendor of the operating system itself, EDR and Anti-Malware systems might trust these files more, failing to recognise the malicious intent early on. Hence, having them as a part of the attack chain might help the adversary to avoid getting caught.

For examples of this tactic, see Defense Evasion T1127 Trusted Developer Utilities Proxy Execution in the MITRE ATT&CK® framework.

Usage within PowerShell - the Add-Type cmdlet

Our first example is a PowerShell script containing a C# snippet that pops up a plain message box using MessageBox from the System.Windows.Forms .NET assembly:

The example uses the Add-Type cmdlet (implemented as a part of Microsoft.PowerShell.Commands.Utility.dll) to instantiate an object of the given .NET Core class called Hello, which creates the message box.

By default, the cmdlet expects C# code; however other languages could be specified with the -Language parameter. There is a built-in CSharpVersion3 option too, but the .NET Framework version 3.5 it relies on is no longer installed by default on the current systems.

Likewise, the support of other languages (such as F#) as shown on the MSDN page depends on normally absent components.

Thanks to my colleague, Conor Kelly for his review.
"Jscript, Microsoft, PowerShell, Visual Basic, Windows are trademarks of the Microsoft group of companies."

References