Skip to content

Analyzing Malware Samples

.NET is a common platform for malware because it is easy to write, runs on most Windows machines, and compiles to intermediate language that can be decompiled back to readable C#. mcilspy enables static analysis of these samples without executing them.

The safest starting point uses only the metadata engine (dnfile), which parses PE headers and .NET metadata tables without invoking any .NET runtime code.

Start with get_metadata_summary to understand the binary’s structure:

"Get metadata summary of suspicious.exe"

Pay attention to:

  • Referenced assembliesSystem.Net.Http, System.Net.Sockets, or System.Net.WebClient indicate network communication. Microsoft.Win32 suggests registry manipulation. System.Diagnostics.Process means it spawns child processes.
  • Type and method counts — A legitimate utility with 5,000 methods is very different from a dropper with 12.
  • Target framework — Malware targeting .NET Framework 2.0 can run on virtually any Windows machine without additional installs.

Finding Command and Control Infrastructure

Section titled “Finding Command and Control Infrastructure”

Search for hardcoded URLs, IP addresses, and domain names:

"Search for strings matching https?://|[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ in suspicious.exe"

Then look for connection-related methods:

"Search for methods containing 'Download', 'Upload', 'Socket', 'Connect', or 'Request' in suspicious.exe"

These searches work without ilspycmd and give you a rapid triage of network behavior.

.NET malware commonly achieves persistence through registry keys, scheduled tasks, or startup folder manipulation. Search for the telltale strings and method calls:

"Search strings for 'CurrentVersion\\Run' or 'TaskScheduler' in suspicious.exe"
"Search methods for 'Registry' or 'SetValue' in suspicious.exe"

Also check list_resources for embedded payloads. Malware frequently carries secondary executables or scripts as embedded resources:

"List all embedded resources in suspicious.exe"

Resource names like payload, stage2, or obfuscated names (random characters) deserve closer inspection.

Once you have identified interesting types through metadata search, decompile them to read the actual logic:

"Decompile the Loader class from suspicious.exe"

For obfuscated samples where type and method names are garbled, list_types with all entity types reveals the full structure even when names are meaningless:

"List all classes, interfaces, and structs in suspicious.exe"

Some .NET malware includes anti-analysis techniques. Look for:

  • Environment detection — Methods checking for IsDebuggerPresent, sandbox artifacts, or VM-specific registry keys.
  • Sleep callsThread.Sleep with large values to outlast sandbox timeouts.
  • Encrypted strings — If search_strings returns mostly gibberish, the sample likely decrypts strings at runtime. Search for Decrypt, FromBase64String, or XOR methods.
  • Reflection loadingAssembly.Load or Assembly.LoadFrom calls that load additional code at runtime from embedded resources or downloaded payloads.
"Search methods for 'IsDebuggerPresent|Sleep|Decrypt|Assembly.Load' in suspicious.exe using regex"

For complex samples with many types, generate_diagrammer creates an interactive HTML view of the type hierarchy. This helps identify which classes are central to the malware’s operation versus which are support code or decoys:

"Generate a type diagram for suspicious.exe"