Using .NET GUIDs to help hunt for malware

The disassembling counterpart to ilasm (Microsoft’s tool for converting Common Intermediate Language code to a portable executable), ildasm, is used to convert .NET assemblies back to the common intermediate language code. In addition, it extracts and displays the MVID which can be searched for specifically with the find command on Windows platforms.

> ildasm /text /all af7ce8dcb16b6344de9856e96ce83b642bcc5ee1c0d29e3a0dcd96e67c65a085 | find "MVID"

// MVID: {F2A0DA69-155E-4543-AD0A-206026E206DB}

As a heavy Linux user, it would be remiss of me not to include a more Linux-friendly solution as well. We can obtain similar results using monodis, ildasm’s counterpart in Mono (an open source implementation of Microsoft’s .NET framework), along with grep, the Linux equivalent to Microsoft's find.

> monodis af7ce8dcb16b6344de9856e96ce83b642bcc5ee1c0d29e3a0dcd96e67c65a085 | grep GUID

.module E.exe // GUID = {F2A0DA69-155E-4543-AD0A-206026E206DB}

It should come as no surprise to developers with .NET experience that there is a simple method to obtain the MVID of another .NET assembly:

var aAssemblyToAnalyze = Assembly.LoadFile(strPathToFileToAnalyse); // DO NOT DO THIS

var mvid = aAssemblyToAnalyze.ManifestModule.ModuleVersionID;

This method should not be used, and the next section will explain why.

While working on a method to extract the MVID as well as the TypeLib ID from .NET samples, I became curious about the additional attack surface created by loading a .NET assembly with no intention of executing it. I found something interesting when testing with mixed .NET assemblies. Mixed assemblies, which are built with both .NET and unmanaged code, were intended to act as a stepping stone for developers migrating projects from purely unmanaged code to .NET. Mixed assemblies are still identified as .NET assemblies, but also contain a DllMain entry point, which is executed when loaded with Assembly.Load and related functions. A full description of this issue can be found in [2]. The brief explanation is that it allows for an assembly to execute code when loaded with Assembly.LoadFile and similar methods, which could be abused to gain control of a system inspecting a malicious sample.

In order to work around this issue, any assemblies loaded purely for inspection should be loaded with Assembly.ReflectionOnlyLoadFrom instead of Assembly.LoadFile, or any of the reflection-only method alternatives. While it does protect from this specific issue, there may be other unexplored attack surfaces, so it’s best, in my opinion, to treat this method as risky but more secure than the non-reflection-only method.

var aAssemblyToAnalyze = Assembly.ReflectionOnlyLoadFrom(strPathToFileToAnalyse);

var mvid = aAssemblyToAnalyze.ManifestModule.ModuleVersionID;

Tools like ILSpy [4] and similar tools which decompile .NET assemblies for analysis can easily recover the TypeLib ID (and the MVID for that matter). No additional action is required for these tools to recover this value beyond simply opening the target assembly (Figure 2).

Figure 2. No additional action is required for tools such as ILSpy to recover the TypeLib ID value beyond simply opening the target assembly.

We can identify the value as the ‘assembly: Guid’ value.

The simplest secure programmatic method I know of for extracting the TypeLib ID is to use .NET to load the assembly (in reflection-only mode) as we did to recover the MVID. Using a reflection-only mode makes the code slightly more complicated, but the resulting code is still quite simple (and secure compared with its non-reflection-only counterparts).

var assembly = Assembly.ReflectionOnlyLoadFrom(“af7ce8dcb16b6344de9856e96ce83b642bcc5ee1c0d29e3a0dcd96e67c65a085”);
foreach(var r in assembly.GetCustomAttributesData())
{
  if (r.AttributeType.FullName == “System.Runtime.InteropServices.GuidAttribute”)
  {
    Console.WriteLine(r.ConstructorArguments[0].Value);
    break;
  }
}

The GUID itself is stored as an ASCII string in the resulting PE. While this method is not particularly recommended for accuracy, it does demonstrate that detection of TypeLib IDs can be done in tools such as YARA as long as some expectation of false positives is accepted (useful for searching via services such as VirusTotal Hunting). The following is an example of using strings, grep, cut and head on a Linux system to obtain the TypeLib ID:

> strings af7ce8dcb16b6344de9856e96ce83b642bcc5ee1c0d2
9e3a0dcd96e67c65a085 | grep -iE “\\\$[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}” | head -n 1 | cut -b 2-

35078dfe-0ce9-4a46-b6be-790d443ff486