SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Community / AGENT SKILL
analyzing-dotnet-malware-internals
0
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.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# 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: ```bash 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 - See [`references/api-reference.md`](references/api-reference.md) for the CLR identifier. - ECMA-335 and ILSpy (linked in frontmatter).