agentsclimarketplace
Sign in

Analyzing dotnet malware internals

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

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.From its SKILL.md

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.

2 things to look at

  • 21 stars21 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.
  • runs commandsInstructs the agent to run 1 command, including `python scripts/analyst.py identify sample.exe`.

What its file declares

Copied from the file, not written here

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, 542 tokens by cl100k_base, 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

What ships with it: 3 files

3.5 KB alongside SKILL.md, 1 of them executable

references/

scripts/

Keep looking

Skills are one crate of 325,949. 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.