agentsclimarketplace

Analyzing dotnet malware internals

Skill meltedinhex/analyst-ai-pack/skills/analyzing-dotnet-malware-internals

An open agent-skills library for malware analysis, reverse engineering, and threat hunting - 118 curated, runnable skills mapped to MITRE ATT&CK, D3FEND, and CAR.

Install
npx -y skills add meltedinhex/analyst-ai-pack --skill analyzing-dotnet-malware-internals

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Reverses .NET/managed malware: decompiling MSIL back to C#, defeating common .NET protectors and string encryptors, and tracing reflection-based loaders to recover the real payload. Activates for requests to analyze a .NET sample, decompile MSIL, or unpack a managed loader.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.1 KB, as published. Nobody here has run it

Analyzing .NET Malware Internals

When to Use

  • A sample is a managed (.NET) assembly — confirmed by a CLR header / mscoree import or BSJB metadata signature.
  • You need readable C# from MSIL and want to defeat .NET-specific obfuscation.
  • A loader uses reflection (Assembly.Load) to run an in-memory payload you must recover.

Do not use native disassembly workflows (Ghidra for x86) as the primary tool — managed code decompiles far more cleanly with a .NET decompiler.

Prerequisites

  • ILSpy / dnSpyEx for decompilation and (with dnSpyEx) managed debugging.
  • de4dot or equivalent for known protectors; familiarity with common .NET obfuscators.

Workflow

Step 1: Confirm it is managed

Check for the CLR runtime header and the BSJB metadata magic:

python scripts/analyst.py identify sample.exe

Step 2: Decompile

Open in ILSpy/dnSpyEx and review the entry point, Main, and module initializer (<Module>.cctor), which protectors often abuse.

Step 3: Handle obfuscation

Recognize and undo common schemes:

  • String encryption — a decryptor method called everywhere; run/trace it to recover plaintext (de4dot can often static-decrypt).
  • Control-flow flattening — follow the dispatcher state machine.
  • Proxy methods / renaming — rely on decompiler analysis rather than names.

Step 4: Trace reflection loaders

Find Assembly.Load(byte[]) / Activator.CreateInstance; dump the byte array argument at runtime (managed debugger breakpoint) to recover the real second-stage assembly, then recurse.

Step 5: Analyze the payload

Decompile the recovered stage; extract C2, configuration, and capabilities for the report.

Validation

  • Decompiled C# is coherent (named or recovered) and the entry path is traced.
  • Encrypted strings are recovered to plaintext.
  • The reflection-loaded stage is dumped and itself decompiles.

Pitfalls

  • Treating the loader as the payload — managed malware is frequently multi-stage.
  • Ignoring the module initializer where protectors install hooks.
  • Static-decrypting strings when the scheme is runtime-keyed; debug and dump instead.

References

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.