.NET MALWARE THREAT: INTERNALS AND REVERSING DEF CON USA 2019

1
.NET MALWARE THREAT:
INTERNALS AND
REVERSING
DEF CON USA 2019
DEF CON USA 2019
by Alexandre Borges
ALEXANDREBORGES–MALWAREANDSECURITYRESEARCHER

DEF CON USA 2019
2
 Malware and Security Researcher.
 Speaker at DEF CON USA 2018
 Speaker at DEF CON China 2019
 Speaker at CONFidence Conference
2019 (Poland)
 Speaker at HITB 2019 Amsterdam
 Speaker at BSIDES
2019/2018/2017/2016
 Speaker at H2HC 2016/2015
 Speaker at BHACK 2018
 Consultant, Instructor and Speaker on
Malware Analysis, Memory Analysis,
Digital Forensics and Rootkits.
 Reviewer member of the The Journal
of Digital Forensics, Security and Law.
 Referee on Digital Investigation: The
International Journal of Digital
Forensics & Incident Response
Agenda:
 Introduction
 Managed executable structures
 CLR and Assembly Loader details
 .NET internals metadata
 Modules, assemblies and manifest
 .NET program structures
 Malicious code through MSIL
 .NET debugging
 Few GC and synchronous aspects
 Conclusion

DEF CON USA 2019
3
 Last talks in conferences:
 CONFidence Conference 2019:
 https://confidence-conference.org/2019/bio.html#id=37486
 slides:
http://www.blackstormsecurity.com/CONFIDENCE_2019_ALEXANDRE.pdf
 DEF CON China 2019:
 https://www.defcon.org/html/dc-china-1/dc-cn-1-speakers.html#Borges
 slides:
http://www.blackstormsecurity.com/docs/DEFCON_CHINA_ALEXANDRE.pdf
 HITB Amsterdam 2019:
https://conference.hitb.org/hitbsecconf2019ams/speakers/alexandre-borges/
 slides: http://www.blackstormsecurity.com/docs/HITB_AMS_2019.pdf
 DEF CON USA 2018:
 https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Borges
 slides: http://www.blackstormsecurity.com/docs/DEFCON2018.pdf
 Malwoverview Tool: https://github.com/alexandreborges/malwoverview

INTRODUCTION
DEF CON USA 2019
4

DEF CON USA 2019
5
 Motivations to this talk about .NET reversing and internals:
 Most of the time, professionals are interested in unpacking embedded
resources from a .NET sample.
 In another moment, the concern is dumping the unpacked binary from
memory.
 Sometimes, we have looked for any unpacking routine to dynamically unpack
the encrypted content.
 All of these actions are correct and recommended.
 However....
 Many people don’t understand .NET metadata components.
 Most people based their analysis on the decompiled code, but never on IL.
 Malware’s authors have manipulated the IL to attack the system and even the
.NET runtime.

DEF CON USA 2019 6
 There are many available methods to infect a system using .NET malware. Most of
the time, a .NET code decrypts and loads a native code (or injects a code into a
target process).
 However, there are few approaches that use indirect techniques:
 An e-mail comes from the Internet and a first dropper is downloaded.
 This dropper fetches a encrypted payload, which contains a native payload
and a managed code.
 The payload 1 executes and injects a DLL into a remote chosen process.
 This DLL loads (and sometime decrypts) the malicious managed code.
 The malicious managed code drops the payload 2 (real and advanced).
 The true infection starts.
dropper
(unmanaged)
payload 1
(unmanaged)
vector
(managed)
inject a DLL in
a remote
process
payload 2
Infection

DEF CON USA 2019
7
 It is not necessary to comment about how to inject a code because the steps are
the same ever-sequence:
 CreateToolhelp32Snapshot( )  Module32First( )  Module32Next( ) 
comparison (wcscmp( ))
 VirtualAllocEx( )  WriteProcessMemory( )  CreateRemoteThread( ) 
WaitForSingleObject  VirtualFreeEx( ).
 Find the offset of injected DLL from the base module (any testing module).
 Use this offset to invoke functions from any injected remote process through
GetProcessAddress( ) + CreateRemoteThread( ).
 Thi injected DLL can load the next stage and, eventually, decrypt it.
 Obviously, the .NET managed code can be loaded from any process or, even
worse, from an natived injected code (DLL).
 After loading it, it is easy to execute it. Our simple case above.

DEF CON USA 2019
8
 We should remember that a typical native application can also load a .NET runtime
and execute a managed code:
 CLRCreateInstance( ): provides the ICLRMetaHost interface.
 ICLRMetaHost::GetRunTime( ): gets the ICLRRuntimeInfo.
 ICLRRuntimeInfo::GetInterface( ): Loads the CLR into the current process and
returns runtime interface pointers.
 ICLRRuntimeHost::ExecuteApplication( ): specifies the application to be
activated in a new domain.
 ICLRRuntimeHost::Start( ): starts the the runtime.
 ICLRRuntimeHost::ExecuteInDefaultAppDomain( ): invokes a method in the
.NET managed assembly (this steps does not work for all .NET assembly’s
method). Thus, in this case, starts the managed assembly. 
 Finally, the real infection starts. 

DEF CON USA 2019
9
 The .NET framework is composed by:
 CLR (Common Language Runtime), which is the .NET engine.
 Libraries (System.IO, System.Reflection, System.Collections, ...).
 Basically:
 source code is written in C#, F#, VB.NET and Powershell.
 compiled to CLI (Common Language Infrastruture Code).
 executed by the CLR.
 Tools used to reverse and analyze .NET malware threats are completely different
than ones used to reverse native language:
 dnSpy (excellent)
 ILSpy (excellent)
 RedGate .NET Reflector
 De4dot (deobfuscator)
 Microsoft Visual Studio
 WinDbg (including SOS.dll extension)
 DotPeek
 IDA Pro
 Microsoft ILASM/ILDASM (Intermediate
Language Assembly/Disassembler)

DEF CON USA 2019
10
 Other interesting tools to analyze and understand .NET runtime are available:
 MemoScope.Net: https://github.com/fremag/MemoScope.Net
 Shed -- a .NET runtime inspector: https://github.com/enkomio/shed
 SuperDump, for automated crash dump analysis:
https://github.com/Dynatrace/superdump
 DumpMiner: https://github.com/dudikeleti/DumpMiner
 MemAnalyzer: https://github.com/Alois-xx/MemAnalyzer
 Sharplab: https://sharplab.io/
 ObjectLayoutInspector to analyze internal structures of the CLR types at
runtime (https://github.com/SergeyTeplyakov/ObjectLayoutInspector)
 Tools are excellent to help us, but most .NET malware threats have deployed the
same tricks from native code to make our job harder: packers, obfuscation and
anti-reversing techniques.
 .NET Reactor
 Salamander .NET Obfuscator
 Dotfuscator
 Smart Assembly
 CryptoObfuscator for .NET
 Agile
 ArmDot
 babelfor.NET
 Eazfuscator.NET
 Spice.Net
 Skater.NET
 VM Protect 3.40

DEF CON USA 2019
11
 There are many obfuscators, which perform:
 Control flow obfuscation and dead/junk code insertion.
 Renaming: methods signatures, fields, methods implementation, namespaces,
metadata and external references.
 Re-encoding: changing printable to unprintable characters
 Simple encryption of methods and strings.
 Cross reference obfuscation.
 Yes, I know... I’ve already talked about de-obfuscation in DEF CON China 2019. 
 Most time, the real and encoded malicious code (payload) is downloaded and
decrypted/loaded into the memory for execution:
 System.Reflection.Assembly.Load( )
 System.Reflection.Assembly.LoadFile()
 System.Reflection.MethodInfo.Invoke( )
 As we already know, Load( )/LoadFile( ) function are usually followed by:
 GetType ( )  GetMethod( )  Invoke( ) (this is a typical Reflection approach)

DEF CON USA 2019
12
 Another possible approach would be:
 GetAssemblyName( ) + GetType( ) + GetMethod( ) + Invoke( )
 Some “encrypted content” is loaded from as a resource, so it is usual finding the
following sequence:
 FindResource( ) + SizeOfResource( ) + LoadResource( ) + LockResource( )
 Resources.ResourceManager.GetObject( )
 Additionally, we’ve seen techniques using embedded references such as DLLs as
resources through a sequence of calls using:
 AssemblyLoader.Attach( ) + AssemblyLoader.ResolveAssembly( ).
 As you’ve guessed, AssemblyLoader.ResolveAssembly( ) is used to resolving
assemblies that are not available at the exact time of calling other methods, which
are external references to the binary itself.

DEF CON USA 2019
13

DEF CON USA 2019
14

DEF CON USA 2019 15
MemberRef Table
(check slides 24 and 29)

DEF CON USA 2019
16
Manifest

DEF CON USA 2019
17
 As every single malware code, this one is using Reflection to retrieve information in
runtime. In this case also calls the GetExecutingAssembly( ) method to get the
Assembly object, which represents the current assembly.

DEF CON USA 2019
18
 Therefore, we can extract these resources (DLLs, for example) by using either dnSpy
or ILSpy , decrypt and load them again into the managed code.
 Of course, in this case, we’ll be able to see all “hidden” references, finally. 
 To load the “decrypted” resources into the managed code, we can use ILSpy +
Reflexil plugin (http://reflexil.net/).
 Finally, it is necessary to remove the “old” references to the embedded resources
(performed by AssemblyLoader.Attach( )) from the initializer (or removing the whole
initializer) because, at this time, they are “decrypted”.
 By the way, Reflexil is able to handle different obfuscators such as Babel NET,
CodeFort, Skater NET, SmartAssembly, Spices Net, Xenocode, Eazfuscator NET,
Goliath NET, ILProtector, MaxtoCode, MPRESS, Rummage, CodeVeil,CodeWall,
CryptoObfuscator, DeepSea, Dotfuscator, dotNET Reactor, CliSecure and so on.
 At end, gaining knowledge in .NET internals and metadata can be interesting.

DEF CON USA 2019
19
 Most time, there are module/type initializers (similar to TLS in native code)
executing before classes and entry point methods.
 .NET protectors hardly change the entry point and, usually, the trick is in the
initializer.
 .cctor( ) method is a static class constructor:
 called before the Main( ) method (usually set as entry point), for example.
 when the module has a .cctor (<Module>::.cctor( )), so it is run before
executing any other class initializers or even an entry point.
 It is common finding unpackers, decrypters and hooks in the .cctor( )
method.
 Hijacking the ICorJitCompiler::compileMethod( ) is an interesting and useful way to
take the control of the JIT engine because this method is used to create a native
code, so we find managed and native code together. 
 In this case: .cctor( )  hooking compileMethod( )  hiding/encryting user code.

.NET details
DEF CON USA 2019
20

DEF CON USA 2019
21
 Metadata works as descriptors for each structure component of the application:
classes, attributes, members, and so on.
 Remember that a .NET application is composed by:
 managed executable files, which each one contains metadata
 managed code (optionally)
 .NET Assembly: managed .NET application (modules) + class libraries + resources
files (more information later)
 CLR runtime environment: loaders + JIT compiler.
 .NET source code  .NET compiler  module (IL + metadata)  CLR ( loaders +
JIT compiler)  native instruction  Execution Engine

DEF CON USA 2019
22
 Managed module is composed by:
 PE header: If the module contains only IL code, so most of information of
header is ignored. However, if the module also contains native code, so things
are different. 
 CLR header: contains the version of the CLR, token of Main( ) (natural entry
poiint), resources and so on.
 Metadata: describe types and members. Additionally, it helps the GC to track
the life time of objects. 
 IL (Intermediate Language) code: the managed code.
Managed Modules
Resource Files
Compiler (C#, VB, F#)
+ Linker
Managed Modules
Resource Files
Manifest
.NET Assembly
(.exe or .dll)

DEF CON USA 2019
23
PE Header
Native Code /
Data
CLR Header
CLR Data
(ILcode, metadata,
managed resources)
DOS Header
PE Header
Data Directories
(size and location of CLR header)
Section Headers
.text
(includes MSIL and metadata)
.idata
.data
Remaining sections
 Managed resources in contained into .text section (and not .rsrc section).

DEF CON USA 2019
24
 Metadata is composed by tables such as:
 Definition tables: ModuleDef, TypeDef, MethodDef, FieldDef, ParamDef,
PropertyDef and EventDef
 Reference tables: AssemblyRef, ModuleRef, TypeRef and MemberRef.
 Manifest tables: AssemblyDef, FileDef, ManifestResourceDef and
ExportedTypesDef.
 Most malicious .NET malware samples have:
 Used code manipulation (encryption/decryption) in .ctor( )/.cctor( )/Finalize( )
 Called unmanaged functions from DLLs using P/Invoke.
 Used COM components (very usual).

DEF CON USA 2019
25
 ILDasm  View  MetaInfo  Show! menu:

DEF CON USA 2019
26
 ILDasm.exe  View  Statistics

DEF CON USA 2019 27
 Metadata describes all declared or referenced data in a module such as classes,
members, attributes, properties and relationships.
 Metadata is organized as a relational database using cross-references and making
possible to find what class each method comes from.
 Metadata are represented by named streams, which are classified as metadata
heaps and metadata tables.
slot 1: Class A -- methods at slot 1
slot 2: Class B -- methods at slot 3
slot 3: Class C -- methods at slot 5
slot 4: Class D -- methods at slot 6
slot 5: Class E -- methods at slot 8
slot 1: Method 1 - Classe A
slot 2: Method 2 - Classe A
slot 3: Method 1 - Classe B
slot 4: Method 2 - Classe B
slot 5: Method 1 - Classe C
slot 6: Method 1 - Classe D
slot 7: Method 2 - Classe D
slot 8: Method 1 - Classe E

DEF CON USA 2019
28
 Metadata heaps:
 GUID heap: contains objects of size equal to 16 bytes.
 String heap: contains strings.
 Blog heap: contains arbitrary binary objects aligned on 4-byte boundary.
 There can be 6 named streams:
 #GUID: contains global unique identifiers.
 #Strings: contains names of classes, methods, and so on.
 #US: contains user defined strings.
 #~: contains compressed metadata stream.
 #-: contains uncompressed metadata stream.
 Blob: contains metadata from binary objects.
 An important note: compressed and uncompressed named streams are
mutually exclusive.
 Metadata tables:
 The schema defines the metadata tables by usings a descriptor.
 There are more than 40 metadata tables.

DEF CON USA 2019
29
 Tokens have 4 bytes, which the first byte determines the metadata table and the
three remaining bytes are the RID.
 RID (record identifiers) are used as row indexes in metadata tables.
 Tokens determines which metadata tables are being referred.
 Unfortunately, tokens don’t cover all tables (auxiliary tables, which are hardcoded).
0(0x0): Module
1(0x1): TypeRef
2(0x2): TypeDef
3(0x3): FieldPtr
4(0x4): Field
5(0x5): MethodPtr
6(0x6): Method
7(0x7): ParamPtr
8(0x8): Param
9(0x9): InterfaceImpl
10(0xa): MemberRef
11(0xb): Constant
12(0xc): CustomAttribute
13(0xd): FieldMarshal
14(0xe): DeclSecurity
15(0xf): ClassLayout
16(0x10): FieldLayout
17(0x11): StandAloneSig
18(0x12): EventMap
19(0x13): EventPtr
20(0x14): Event
21(0x15): PropertyMap
22(0x16): PropertyPtr
23(0x17): Property
24(0x18): MethodSemantics
25(0x19): MethodImpl
26(0x1a): ModuleRef
27(0x1b): TypeSpec
28(0x1c): ImplMap
29(0x1d): FieldRVA
30(0x1e): ENCLog
31(0x1f): ENCMap
32(0x20): Assembly
33(0x21): AssemblyProcessor
34(0x22): AssemblyOS
35(0x23): AssemblyRef
36(0x24): AssemblyRefProcessor
37(0x25): AssemblyRefOS
38(0x26): File
39(0x27): ExportedType
40(0x28): ManifestResource
41(0x29): NestedClass
42(0x2a): GenericParam
43(0x2b): MethodSpec
44(0x2c): GenericParamConstraint

DEF CON USA 2019
30
 ILDasm.exe  View  Statistics

DEF CON USA 2019
31
 IDAasm  View  MetaInfo  RawHeap
 ILDasm  View  MetaInfo  Show!

DEF CON USA 2019
32
 Check the installed .NET version:
 Subdirectories under C:WindowsMicrosoft.NET
 clrver.exe
 clrver.exe -all
 Programming directly in IL (Intermediate Language) can be interesting because:
 IL is stack based, so we don’t find any instruction related to register
manipulation. 
 Ngen.exe can be used to compile IL instructions to native code.
 Eventually, malware threats have attacked the .NET runtime to subvert the
system. 
 Assemblies can be classified as:
 private: it is specific of an application and deployed at same directory.
 shared: it is shared and used by other applications.

DEF CON USA 2019
33
 In .NET applications:
 .NET Assembly:
 In malware samples, we usually find that resources are encrypted
binaries and DLLs. 
 Remember that the application can download assembly files from a URL
(codeBase element).
 .NET malware have used multi-file assemblies, partitioning types over
different files. Unfortunately, it is only possible to create multfile
assembly in the command line. 
 Few malware authors have create .NET malware containing different
types: such as C# and VB in the same assembly.

DEF CON USA 2019
34
 Compile multi-file .NET malware is pretty easy:
 csc.exe /t:module hooking.cs
 csc.exe /t:module injection.cs
 csc.exe /out:malwarelib.dll /t:library /addmodule:hooking.netmodule
/addmodule:injection.netmodule Defcon.cs
 In this case, we have a multi-file assembly:
 includes a managed module named hooking.netmodule and
injection.netmodule. The output file is a DLL named malwarelib.dll
 a manifest file wrapping everything.
 This compiling command add the hooking.mod file to the FileDef manifest
metadata table and the its exported types to the ExportedTypeDef manifest
metadata table.
 To check: ILDasm  View  MetaInfo  Show! and look for the FileDef and
ExportedTypeDef tables.

DEF CON USA 2019 35
Native modules referred by the
assembly. The module name is
in the ModuleRef.
External assemblies that
referred by the assembly
(AssemblyRef table).
Manifest
Used when a strong
assembly is specified.

DEF CON USA 2019
36
Assembly name
Custom attributes used by the compiler
(or tools) and defined in the
CustomAttribute metadata table (0x0C).
CALG_SHA1

DEF CON USA 2019 37
Managed Resources
(ManifestResource
metadata table)
other
attributes
Globally unique
identifier.

DEF CON USA 2019
38
 Of course, we could have a “big malware module” to use in projects:
 al.exe /out: BigMalwareLib.dll /t:library hooking. netmodule injection.
netmodule
 csc.exe /t:module /r:BigMalwareLib.dll Defcon.cs
 al /out:Defcon.exe /t:exe /main:Defcon.Main Defcon.netmodule
 In this case, the __EntryPoint() global function will contain the Defcon::Main( )
function call (check the IL code to confirm it).
 It is not necessary to mention that malware’s authors usually don’t write strong
assemblies, which as signed with the private/public key pair from the publisher.
Unless that this key pair has been stolen... 
 csc.exe /out:TestProgram.exe /t:exe Program.cs
 sn.exe -k AlexandreBorges.snk
 sn.exe -p AlexandreBorges.snk AlexandreBorges.PublicKey sha256
 Sn.exe -tp AlexandreBorges.PublicKey
 csc.exe /out:TestProgram.exe /t:exe /keyfile:AlexandreBorges.snk Program.cs

DEF CON USA 2019 39
Public key generated can be viewed
by:
sn.exe -p AlexandreBorges.snk
AlexandreBorges.PublicKey sha256

DEF CON USA 2019
40
 Once the system is compromised through a native malware and we have access to
the system as administrator, so it is possible to copy our .NET assembly to the
Global Assembly Cache (GAC). The Registry is not changed.
 Once a malicious .NET assembly (first stage, as a resource library) is copied to GAC,
so it can be accessed by other assemblies.
 Thus, other malicious .NET malware samples (second stage) can access methods
and types from the first stage.
 Only strong assemblies (signed) can be copied to the GAC (located at
C:WindowsMicrosoft.NETassembly) by using GACUtil.exe /i command.
 Futhermore, including /r option integrates the assembly with the Windows install
engine.
 Unfortunately, the GACUtil.exe is not available in home-user systems, but it is
possible to use the MSI to install the malware threat into the GAC. 
 At end, it is still feasible to using delay signing, which is a partial signing only using
the public key. Therefore, private key is not used (and there isn’t real protection).

DEF CON USA 2019
41
 The delay signing allows that the malicious assembly to be installed into the GAC
and, worse, other assemblies can make reference to it. 
 csc.exe /out:malware.dll /t:exe Program.cs
 sn.exe -k AlexandreBorges.snk
 sn.exe -p AlexandreBorges.snk AlexandreBorges.PublicKey sha256
 sn.exe -tp AlexandreBorges.PublicKey
 csc.exe /out:malware.dll /t:exe /keyfile:AlexandreBorges.PublicKey /delaysign
Program.cs
 sn.exe -Vr malware.dll (CLR trust in the assembly without using the hash).
 Using csc.exe /resource makes simple to add resources (generated by resgen.exe ,
for example). It updates the the ManifestResourceDef table.
 It is not so hard to perform a supply-chain attack because, when a file is specified
as reference in the csc.exe compiler using /reference switch, it looks at:
 the working directory
 csc.exe directory
 directory specified by the /lib switch
 directory specified by the LIB environment variable.

DEF CON USA 2019
42
 Several malware samples have been modified or written directly in ILAsm to
bypass common tools.
 While ILAsm is not complicated, maybe it is still recommended to remember few
directives and instructions. 
 .assembly DefCon { }: identifies the current assembly as being DefCon.
 .assembly extern <assemblyname>: determines the external managed assembly
used by the program. For example, .assembly extern <mscorlib>
 .module malware.dll: identifies the current module.
 .namespace Conference: identities the namespace, but it does not represent a
metadata.
 .class public auto ansi Hacker entends [mscorlib]System.Object. Its keywords;
 .class: identifies the current class (Hacker)
 public: specifies the visibility. For example, it could be “private”.
 auto: determines the class layout style. It could be “explicit” and
“sequencial”.
 ansi: string encode while communicating to unmaged code. Other values are
autochar and unicode.
 extends: determines its base class

DEF CON USA 2019
43
 Other flags for .class directive are:
 private: used with private classes, which are not visible outside the current
assembly.
 sealed: the current class can’t be derived from this class.
 abstract: the current class can’t be instantiated (it holds abstract methods).
 explicit: the loader preserve the order of fields in the memory.
 sequential: the loader preserves the order of the instance fields as specified
in the class.
 nested family: the class is visible from the descendants of the current class
only.
 nested assembly: the class is visible only from the current assembly.
 nested famandassem: the class is visible from the descendants of the current
class, but residing in the same assembly only.
 windowsruntime: the class is a Windows runtime type.
 .class public enum Exam: declares a class enumeration named “Exam”.
 .ctor( ): instance constructor, which is related to instance fields.
 .cctor( ): class constructor (known as type initializer), which is related to static
fields.

DEF CON USA 2019
44
 During malware analysis, take care: there can be a global .cctor directive, which it
is related to global fields.
 call: call a method. Its possible keywords:
 return type: void, int32, and so on.
 vararg: variable number of arguments
 calli: directive used to call methods indirectly by taking arguments + function
pointer.
 ldc.i4.0
 ldc.i4.1
 ldc.i4.2
 ldftn void DefCon::Test(int32, int32, int32)
 calli void(int32, int32, int32)
 (method reference):
 call instance void DefCon::Exam(int32, int32, int32)
 call instance [.module malware.dll]::Hooking(int32, int32, native int)

DEF CON USA 2019
45
 .field: specifies a variable of any type declared directly in the class (or struct). Its
main keywords can be:
 public / assembly / family (accessed by any decending class) / private
 static (shared by all instances of the referred class).
 .method: specifies the method declaration. Its main keywords (flags) can be:
 public / static: similar meaning as especified in “field” explanation above. 
 cil managed: it means this method is represented in managed code.
 newslot: creates a new slot in the virtual table of the class to prevent that a
existing method (same name and signature) to be overriden in a derived class.
 native unmanaged: it means this method is represented in a native code.
 abstract: of course, no implementation is provided.
 final: as known, the method can’t be overridden.
 virtual: method can be “redefined” in derived classes.
 strict: this method can only be overridden whether it is accessible from the
class that is overriding it. Of course, the method must be virtual.
 noinline: it is not allowed to replace calls to this method by an inline version.
 pinvokeimpl: declares an unmanaged method from a managed code (it’s is
also known as P/Invoke mechanism).

DEF CON USA 2019
46
 .method public hidebysig static pinvokeimpl("user32.dll" winapi) int32
FindWindow(string,string) cil managed preservesig
 preservesig: return of method must be preserved.
 FindWindows(string,string): function invoked from the “user32.dll” and that
returns a int32 value.
 .class public DefCon implements InterfaceA,InterfaceB {
.method void virtual int32 IfB_Speaker(string) {
.override InterfaceB::Speaker
...
}
 .class public DefConChina extends DefCon {
.method public specialname void .ctor( ) {
ldarg.0
call instance void DefCon::.ctor( )
ret }
callvirt instance void DefCon::IfB_Speaker( )

DEF CON USA 2019
47
 .entrypoint: identifies the method as the entry point of the assembly.
 .maxstack: defines the maximum stack depth used by the function code
 .locals int: defines the local variable of the current method and the “init” keyword
is initializing the variable with “zero” (for example, a integer variable).
 .data <var_1>: defines a data segment named “var_1”.
 stloc <var>: retrieves the value returned by the call and stores into the “var”
variable.
 ldarg.0: Load argument 0 onto the stack.
 ldloc <var>: copies the value of “var” onto the stack. Variants, after optmization
and run, such as ldloc.0, ldloc.1, ldloc2 and ldloc3 (representing the first local
variables) are possible.
 ldstr: loads the reference to a string onto stack.
 ldsflda: loads the reference of a static field onto the stack.
 ldsfld: loads the value of a static field onto the stack.
 ldc.i4 8: loads the constant value 8 onto the stack.

DEF CON USA 2019 48
 br Borges: its unconditional jump similar to “jmp” in native assembly. In this case,
jumping to “Borges” label.
 brtrue DefCon: takes an item from stack and, if it is zero, so jumps to “Alex”
branch. Similar to jz instruction.
 brfalse Alex: takes an item from stack and, if it is one, so jumps to “Alex” branch.
Similar to jnz instruction.
 .this: it is a reference to the current class (not instance of the class like C++).
 .base: it is a reference to the parent of the current class.
 .typedef: creates a alias to a type.
 .try / catch: the same meaning of traditional C language.

DEF CON USA 2019
49
auto: loader defines the
“best lay out” in the
memory”
nested and sealed class!
specialname flag helps
the loader to
understand this is a
special function
(constructor)
Remember that a field is a variable of any type that is
declared directly in a class or struct.

DEF CON USA 2019
50
instance
constructor
load argument 0 onto the stack.
reserving 8 slots for arguments.
push 0 onto stack as int32.
loads a string reference onto stack.
replaces the value of a field with a value from stack.
Using a custom attribute statement to set
the value of CompilerGeneratedAttribute .

DEF CON USA 2019
51
Invoking an unmanaged methods.
Declares a private class.
Defines an initially runtime zeroed
local variable (type class) of the
current method.

DEF CON USA 2019
52
It calls a virtual method, which can
be overriden the the derived class.
It loads -1 onto the stack.
Calls a static method named GetCurrentProcess( ) from
Process class (within namespace System.Diagnostics) and
returning an instance of Process class. 
Duplicate the value of
the top of the stack.
legal instructions to way
out of a “try block.”

DEF CON USA 2019
53
It seems that someone
is interested in our
typed information. 

DEF CON USA 2019
54
family: can be accessed by any class
descending from the current one.
ldfld: loads the instance field onto the stack.
ldsfld: loads the static field onto the stack.
Event declaration. We should
remember that all events must
have a subscribing method
(.addon ) and a unsubscribing
method (.removeon), at least. 
Cleaning up

DEF CON USA 2019 55
Declaring three local class variables in
three different slots: 0, 1 and 2. We should
remember that, eventually, slots of same
type can be reused. However, it is another
talk... 

DEF CON USA 2019 56
Finally, when the publisher calls the Invoke method of the
aggregate delegate, so the event is raised. 
Delegates are references representing “type-safe”
function pointers. Thus, Combine( ) adds callback
function pointers to an aggregate, which is used to
implement the event.
Generic Delegate! Compares the second and third arguments and, if
it’s equal, replace the first argument (!!0&).

DEF CON USA 2019 57
turn off compile optimization and
not allow put this function as inline.
calling several instance contructors
calling the virtual method

DEF CON USA 2019 58
pushes a null references onto the stack
converts to int64 and pushes it onto the stack
converts to int32 and throws an exception when overflow
declares and initializes the local variable
Function used to decrypt strings
loads the local variable onto stack.

DEF CON USA 2019
59
 DLL loaded from the Global Assembly Cache can and need to be monitored to
detect strange behavior. Tools to log the DLL loading such as Fuslogvw.exe
(Assembly Bind Log Viewer) and common applications such as Process Monitor can
help us.
 Of course, .NET malware threats can try to compromise the .NET runtime class
libraries and JIT, which would cause a deep infection in the system and demand a
detailed investigation because:
 changing the runtime library (at IL code) can be lethal to many applications.
 it is feasible to change (hooking)/replace a runtime library.
 Changing JIT cause same problems, but it is harder.
 Remember about basics:
 copy DLL from GAC  dnSpy/Reflector + Reflexil  ildasm  change  ilasm
 Ngen  copy back to GAC (malware dropper can accomplish this task) 

DEF CON USA 2019
60
 Of course, nothing is so simple:
 If the malware’s target is a DLL from .NET runtime, so it is digitally signed and
it would be necessary to have the private key to sign it. Unfortunately, we
don’t have.
 Another option would be to generate a new pair of keys and re-sign all the
DLL Framework. Unfortunately, it is so much work.
 Copying a modified runtime DLL over the existing one can be difficult or
almost impossible because other programs can be using it. Thus, we should
stop programs and services to accomplish this task.
 Eventually, it is necessary to reboot the machine (urgh!) to perform this copy
from a script.
 Using the new and modified DLL can be tricky: uninstall the existing native
library (ngen uninstall <dll>) and remove it from its respective directory
under NativeImages_<version> directory.
 There are other many tricks such as dropping an assembly into C:WindowsSystem32
or Syswow64)TasksTasks.dll (hint from Casey Smith)

DEF CON USA 2019
61
 An alternative would be change the Registry. In this case, the GAC continue
being associated to the original (and untouched) assembly, while its
associated native image is changed to the modified version.
 In this case:
 HKEY_LOCAL_MACHINESOFTWAREMicrosoftFusionNativeImagesInd
exv2.0.50727_64IL key holds information (name + signature key)
about the original assembly.
 HKEY_LOCAL_MACHINESOFTWAREMicrosoftFusionNativeImagesInd
exv2.0.50727_64NI key would hold information (name + MVID) about
the modified native image.
 Using the MVID from NI key makes simple to locate the native image.
 Thus, we can either override the native image with a modified version or
change the MVID entry to point to another native image.
 GAC (old .NET assemblies) / GAC_32 (IL and x86) / GAC_64 (IL and x64) /
GAC_MSIL (IL code) directories are under C:WindowsAssembly directory.

DEF CON USA 2019
62
 Most of the time, .NET malwares attacking the .NET libraries try either to remove
some check or introduce hooking points at entry or exit of a method. In this
case, System.Reflection is commonly used.
 Additionally, there are cases of .NET malware threats attacking applications and
the service management offered by System.ServiceProcess.ServiceBase class and
their associated method such as OnStart( ), OnStop( ), Run( ), ServiceMain( ) and
so on.
 Modifying a target code for changing the execution flow demands inserting
references (.assembly extern directive) to signed libraries (version + public key)
to be able to access member and call methods.
 Of course, we should remember to increase the stack (.maxstack).
 At end, we have multiple types of attacks from a malicious managed code by
establishing a C2, intercepting communication with trusted websites, opening
shells, gathering system information, launching native second stage droppers,
intercepting filesystem communication, stealing information and so on.

DEF CON USA 2019
63
 WinDbg is always an excellent tool to understand a .NET malware in a better way
or even getting a basic understanding, at least. 
 Install SOSEX extension:
 Download it from http://www.stevestechspot.com/downloads/sosex_64.zip
or http://www.stevestechspot.com/downloads/sosex_32.zip
 Unpack it and copy to your WinDbg installation directory. For example:
C:Program Files (x86)Windows Kits10Debuggersx64|x86
 Attach the WinDbg to either a running application (the .NET malware) or a saved
dump.
 Remember that the CLR process is composed by:
 System Domain
 Shared Domain
 Default Domain
 code running at this domains can’t access resources from another
application domain.

DEF CON USA 2019 64
0x25B05A: Entry Point from dumpbin /headers malware1.exe
 Remember:
 Malware executes
 Win loaders find the PE’s entry point
 Jump to mscoree.dll
 Call to CorExeMain( )
 Return to assembly’s entry point.
Disassembling CorExeMain( ) from the start.
We could have used before this point: sxe ld mscorwks.dll ; g

DEF CON USA 2019
65
Listing domains of the CLR process.
As commented previously.

DEF CON USA 2019
66
Used assemblies tell us a
bit about the application.

DEF CON USA 2019
67
Checks managed
exception in each
thread.
switch to the thread 5
managed threads:
0, 2 , 5, 10 and 14

DEF CON USA 2019
68
Check the managed stack trace for this thread.
switch to the thread 0

DEF CON USA 2019 69
Get a list of managed threads. Of
course, we could used the -special
option to get additional information.
Checks the
unmanaged stack
trace for this thread.
COM Threading Model:
 STA: Single Thread Apartment
 MTA: Multi Thread Apartment
Threat state:
 (0x0) Newly
initialized thread.
 (0x020) It can enter
a Join.
 (0x200) background
thread.

DEF CON USA 2019
70
Check if the instruction pointer address belongs to
the JIT code and find the Method Descriptor 
Disassembling the code

DEF CON USA 2019
71
Checks the managed stack
Display information about the MethodDesc structure
Check if the instruction pointer address belongs to the JIT code.
Method definition.
Remember: Metadata token is
composed by a Table Reference (1 byte)
and a Table Index (3 byte).

DEF CON USA 2019 72
Displays information about the EEClass structure associated with a type

DEF CON USA 2019 73
dumps the object content, but in this case it is a value type. 
Class

DEF CON USA 2019 74
Dump information about the Method Table
Dump information about the Method
Table and display a list of all methods.
Code is PreJIT compiled
Type definition
EEClass data structure is similar to
the method table, but it stores
fields that are less frequently used.

DEF CON USA 2019 75
Dump information about a specific module
Dump information about the assembly (as shown previously)
Data accessed and/or updated less frequently
Data accessed and/or updated very frequently
Data used to help COM operations

DEF CON USA 2019 76
Displays the
MethodTable structure
and EEClass structure

DEF CON USA 2019
77
Bad intentions? 

DEF CON USA 2019 78
PreJIT: pre-compiled code
JIT: compiled Code
NONE: the code hasn’t been compiled by the JIT.

DEF CON USA 2019 79
Shows information about the EEClass structure
Set up a breakpoint on a code that is not JIT yet. 
Displays the MethodTable
structure and EEClass structure
of test.Client.Verbunden method.
Displays the MethodDesc
structure information

DEF CON USA 2019
80
Dumps out arrays
Performs stack walking and display
managed objects from current thread

DEF CON USA 2019 81
Value Type: 1
Reference: 0
Method Table
of the field

DEF CON USA 2019 82
As a general overview, during allocation requests:
 If the maximum expected memory for the Gen0 is
exceeded, collect non-rooted objects and promote
rooted objects to Gen 1.
 The same approach is valid when collecting objects
from Gen 1 and Gen 2.
 If Gen 2 is exceeded, so GC adds a new segment to
Gen 2.
 Objects in Gen 0 and 1 are short-lived.
Reference chain
to the object 
from stack...
from handle tables...
from the previous slide 

DEF CON USA 2019
83
 The Finalization Queue contains
objects with finalizers (Finalize( )).
 When an object in Finalization
Queue becomes rootless, so the
GC put it into the f-reachable
queue, which are considered
garbage (but alive).

DEF CON USA 2019
84
Excessive or long-time pinned handles
can cause CLR heap fragmentation.

DEF CON USA 2019 85
Dumps the process
to later analysis
Look for the string in
the managed heap.
It shows information about locks
Make easier to find deadlocked threads
Displays information
about a type or variable
It could seems unbelievable,
but some malware samples
don’t work because deadlocks

If there is some deadlock, so
use the DumpObj command to
find additional information
about the thread. 
CCW: COM Callable Wrapper
RCW: Runtime Callable Wrapper,
which intercepts, manage the
object’s lifetime and the
transition between managed
code and native code.

DEF CON USA 2019 86
 Remember that an event works as
synchronization object. 
 When an event happens (going from
non-signaled state to signaled state), the
waiting thread (WaitForSingleObject( ))
starts its execution.
 Auto reset: If the event is signaled, so
allows the thread being release and it is
automatically reset to non-signaled state.
 Manual reset: the event remains in
signaled state until being intentionally
reset.
 Other synchonization techniques could
be Semaphores, ReaderWriterLock,
Mutex and so on...
It shows specific-object handle information

DEF CON USA 2019 87
Additionally, it is always recommended
to investigate the current stack, looking
for some interesting string 
Few hints about our malware...

DEF CON USA 2019 88
Get objects (and their respective metadata) stored
in the heap. To a short output, use !DumpHeap -stat
Dumps the heap, but
limit the output to the
specified type name.
Class !

DEF CON USA 2019 89
Displays information
about the method table

DEF CON USA 2019 90
Boxing turns a value type
into an object reference
(reference type)
Unboxing turns a object
reference into a value type
!DumpIL displays the IL
instructions of a method

DEF CON USA 2019 91
!DumpHeap -strings is
always excellent to find
valuable strings. 
If you can’t recognise
these strings, they are
related to banks. 

DEF CON USA 2019
92
 Other possible WinDbg breakpoints that could be used to gather further
information:
 How to log API calls:
 bp mscorwks!MethodTable::MapMethodDeclToMethodImpl
 bp clr!MethodTable::MapMethodDeclToMethodImpl
 How to get possible strings:
 !bpmd mscorlib.dll System.String.CreateStringFromEncoding
 !bpmd mscorlib.dll System.String.Intern
 !bpmd mscorlib.dll System.Text.StringBuilder.ToString
 bp mscorwks!GlobalStringLiteralMap::GetStringLiteral
 bp clr!StringLiteralMap::GetstringLiteral
 How to examine loaded assemblies:
 bp mscorwks!CLRMapViewOfFileEx
 bp clr!AssemblyNative::LoadFromBuffer

DEF CON USA 2019
93
Surprise... is it malicious? 
 https://github.com/alexandreborges/malwoverview

DEF CON USA 2019 94

DEF CON USA 2019 95

DEF CON USA 2019 96
 Acknowledgments to:
DEF CON staff, who have been always very kind with
me.
You, who have reserved some time attend my talk.
Security is like a drunk: while walking back-and-forth, he
always proceeds halfway through the remaining distance,
but he never gets there. 
Remember: the best of this life are people. 

DEF CON USA 2019
97
 Malware and Security Researcher.
 Speaker at DEF CON USA 2018
 Speaker at DEF CON China 2019
 Speaker at CONFidence Conference
2019 (Poland)
 Speaker at HITB 2019 Amsterdam
 Speaker at BSIDES
2019/2018/2017/2016
 Speaker at H2HC 2016/2015
 Speaker at BHACK 2018
 Consultant, Instructor and Speaker on
Malware Analysis, Memory Analysis,
Digital Forensics and Rootkits.
 Reviewer member of the The Journal
of Digital Forensics, Security and Law.
 Referee on Digital Investigation: The
International Journal of Digital
Forensics & Incident Response
THANK YOU FOR
ATTENDING MY TALK. 
 Twitter:
@ale_sp_brazil
@blackstormsecbr
 Website: http://www.blackstormsecurity.com
 LinkedIn: http://www.linkedin.com/in/aleborges
 E-mail: alexandreborges@blackstormsecurity.com

.NET MALWARE THREAT: INTERNALS AND REVERSING DEF CON USA 2019

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to .NET MALWARE THREAT: INTERNALS AND REVERSING DEF CON USA 2019

Similar to .NET MALWARE THREAT: INTERNALS AND REVERSING DEF CON USA 2019 (20)

Recently uploaded

Recently uploaded (20)

.NET MALWARE THREAT: INTERNALS AND REVERSING DEF CON USA 2019