reverse-skills-max/vendor-new/analyst-ai-pack/skills/recovering-injected-code-and-shellcode/SKILL.md

name, description, domain, subdomain, tags, version, author, license, mitre_attack, d3fend, references

name	description	domain	subdomain	tags	version	author	license	mitre_attack	d3fend	references
recovering-injected-code-and-shellcode	Carves injected PE images and position-independent shellcode from a memory dump or carved region, identifies the payload type, and prepares it for disassembly or emulation. Activates for requests to recover injected code, carve shellcode from memory, or reconstruct a dumped payload for analysis.	cybersecurity	malware-analysis	malware-analysis shellcode memory-forensics carving dynamic-analysis	1.0.0	analyst-ai-pack	Apache-2.0	T1055 T1620 T1027	D3-SDA D3-DA	MITRE ATT&CK T1620 Reflective Code Loading — https://attack.mitre.org/techniques/T1620/ MITRE ATT&CK T1055 Process Injection — https://attack.mitre.org/techniques/T1055/

Recovering Injected Code and Shellcode

When to Use

• You have a carved memory region (from malfind/vaddump) and need to identify and extract the payload — an injected PE or raw shellcode.
• You need to locate likely shellcode entry points (egg hunters, GetPC stubs) before disassembly.

Do not use this to execute the payload — it prepares code for static disassembly/emulation in a controlled tool, not for running.

Prerequisites

• A carved binary region (raw bytes) from a memory image.

Safety & Handling

• The carved region is live malicious code; store it password-protected and never execute it.

Workflow

Step 1: Identify payload type

python scripts/analyst.py identify region.bin

Detects an embedded MZ/PE (with offset) versus raw shellcode, and reports the PE's architecture if present.

Step 2: Locate shellcode entry hints

Finds common position-independent code markers: GetPC stubs (call $+5/fldz/fnstenv), PEB access (fs:[30]/gs:[60]), and API-hashing loops.

Step 3: Extract for analysis

Carve the PE at its offset (or keep the raw shellcode) and hand it to a disassembler/emulator at the detected base/entry.

Step 4: Document

Record offsets, architecture, and entry hints for the downstream RE workflow.

Validation

• An embedded PE is confirmed by MZ + valid e_lfanew → PE\0\0.
• Shellcode entry hints reference real PIC patterns, not arbitrary bytes.
• Architecture detection matches the PE Machine field (or PIC heuristics for raw shellcode).

Pitfalls

• Assuming everything carved is a PE; much injected code is headerless shellcode.
• Wrong base address breaking relocations when loading a dumped PE — note it for rebuilding.
• Treating compressed/encrypted stages as final shellcode without a decode pass.

References

• See references/api-reference.md for the identifier.
• ATT&CK T1620 and T1055 (linked in frontmatter).