analyzing-dotnet-malware-internals

Name: analyzing-dotnet-malware-internals
Author: meltedinhex

18stars5forks

How to install analyzing-dotnet-malware-internals?

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

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

Installs into the current project.

Summary

Reverses .NET/managed malware: decompiling MSIL back to C#, defeating common

Files · 1

View on GitHub

SKILL.md

1	# Analyzing .NET Malware Internals
2
3	## When to Use
4
5	- A sample is a managed (.NET) assembly — confirmed by a CLR header / `mscoree` import or
6	`BSJB` metadata signature.
7	- You need readable C# from MSIL and want to defeat .NET-specific obfuscation.
8	- A loader uses reflection (`Assembly.Load`) to run an in-memory payload you must recover.
9
10	Do not use native disassembly workflows (Ghidra for x86) as the primary tool — managed
11	code decompiles far more cleanly with a .NET decompiler.
12
13	## Prerequisites
14
15	- ILSpy / dnSpyEx for decompilation and (with dnSpyEx) managed debugging.
16	- de4dot or equivalent for known protectors; familiarity with common .NET obfuscators.
17
18	## Workflow
19
20	### Step 1: Confirm it is managed
21
22	Check for the CLR runtime header and the `BSJB` metadata magic:
23
24	```bash
25	python scripts/analyst.py identify sample.exe
26	```
27
28	### Step 2: Decompile
29
30	Open in ILSpy/dnSpyEx and review the entry point, `Main`, and module initializer
31	(`<Module>.cctor`), which protectors often abuse.
32
33	### Step 3: Handle obfuscation
34
35	Recognize and undo common schemes:
36
37	- String encryption — a decryptor method called everywhere; run/trace it to recover
38	plaintext (de4dot can often static-decrypt).
39	- Control-flow flattening — follow the dispatcher state machine.
40	- Proxy methods / renaming — rely on decompiler analysis rather than names.
41
42	### Step 4: Trace reflection loaders
43
44	Find `Assembly.Load(byte[])` / `Activator.CreateInstance`; dump the byte array argument at
45	runtime (managed debugger breakpoint) to recover the real second-stage assembly, then recurse.
46
47	### Step 5: Analyze the payload
48
49	Decompile the recovered stage; extract C2, configuration, and capabilities for the report.
50
51	## Validation
52
53	- Decompiled C# is coherent (named or recovered) and the entry path is traced.
54	- Encrypted strings are recovered to plaintext.
55	- The reflection-loaded stage is dumped and itself decompiles.
56
57	## Pitfalls
58
59	- Treating the loader as the payload — managed malware is frequently multi-stage.
60	- Ignoring the module initializer where protectors install hooks.
61	- Static-decrypting strings when the scheme is runtime-keyed; debug and dump instead.
62
63	## References
64
65	- See [`references/api-reference.md`](references/api-reference.md) for the CLR identifier.
66	- ECMA-335 and ILSpy (linked in frontmatter).

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

analyzing-dotnet-malware-internals

18stars5forks

View on GitHub

How to install analyzing-dotnet-malware-internals?

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

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

Installs into the current project.

Summary

Reverses .NET/managed malware: decompiling MSIL back to C#, defeating common

Files · 1

View on GitHub

SKILL.md

1	# Analyzing .NET Malware Internals
2
3	## When to Use
4
5	- A sample is a managed (.NET) assembly — confirmed by a CLR header / `mscoree` import or
6	`BSJB` metadata signature.
7	- You need readable C# from MSIL and want to defeat .NET-specific obfuscation.
8	- A loader uses reflection (`Assembly.Load`) to run an in-memory payload you must recover.
9
10	Do not use native disassembly workflows (Ghidra for x86) as the primary tool — managed
11	code decompiles far more cleanly with a .NET decompiler.
12
13	## Prerequisites
14
15	- ILSpy / dnSpyEx for decompilation and (with dnSpyEx) managed debugging.
16	- de4dot or equivalent for known protectors; familiarity with common .NET obfuscators.
17
18	## Workflow
19
20	### Step 1: Confirm it is managed
21
22	Check for the CLR runtime header and the `BSJB` metadata magic:
23
24	```bash
25	python scripts/analyst.py identify sample.exe
26	```
27
28	### Step 2: Decompile
29
30	Open in ILSpy/dnSpyEx and review the entry point, `Main`, and module initializer
31	(`<Module>.cctor`), which protectors often abuse.
32
33	### Step 3: Handle obfuscation
34
35	Recognize and undo common schemes:
36
37	- String encryption — a decryptor method called everywhere; run/trace it to recover
38	plaintext (de4dot can often static-decrypt).
39	- Control-flow flattening — follow the dispatcher state machine.
40	- Proxy methods / renaming — rely on decompiler analysis rather than names.
41
42	### Step 4: Trace reflection loaders
43
44	Find `Assembly.Load(byte[])` / `Activator.CreateInstance`; dump the byte array argument at
45	runtime (managed debugger breakpoint) to recover the real second-stage assembly, then recurse.
46
47	### Step 5: Analyze the payload
48
49	Decompile the recovered stage; extract C2, configuration, and capabilities for the report.
50
51	## Validation
52
53	- Decompiled C# is coherent (named or recovered) and the entry path is traced.
54	- Encrypted strings are recovered to plaintext.
55	- The reflection-loaded stage is dumped and itself decompiles.
56
57	## Pitfalls
58
59	- Treating the loader as the payload — managed malware is frequently multi-stage.
60	- Ignoring the module initializer where protectors install hooks.
61	- Static-decrypting strings when the scheme is runtime-keyed; debug and dump instead.
62
63	## References
64
65	- See [`references/api-reference.md`](references/api-reference.md) for the CLR identifier.
66	- ECMA-335 and ILSpy (linked in frontmatter).

People who liked this also viewed

6 picks

Type