Guided Workflow and Reporting Template

Guided Workflow and Reporting Template

This lesson walks you through the detailed analysis workflow for the capstone exercise and provides a professional reporting template. The workflow mirrors what you would do in a real SOC or incident response engagement, progressing from static analysis through dynamic behavioral observation, targeted reverse engineering, and into structured reporting.

Detailed Analysis Workflow

Phase 2: Static Analysis -- Understanding Structure and Capabilities

Static analysis examines the sample without executing it. Your goals are to understand the sample's structure, identify capabilities, and generate hypotheses to test during dynamic analysis.

Step 1: String extraction with FLOSS

FLOSS (FireEye Labs Obfuscated String Solver) goes beyond standard string extraction by decoding obfuscated and stack strings.

floss suspect.exe > strings_output.txt

# Review the most relevant sections
# Look for: URLs, IP addresses, file paths, registry keys,
# API function names, error messages, embedded commands

Key patterns to look for in strings output:

Step 2: Capability detection with capa

capa identifies capabilities based on pattern matching against a rule set. It maps findings to MITRE ATT&CK automatically.

capa suspect.exe

Example output structure:

+------------------------+---------------------------------------------------+
| ATT&CK Tactic         | ATT&CK Technique                                  |
|------------------------+---------------------------------------------------|
| DEFENSE EVASION        | Obfuscated Files or Information [T1027]            |
| DISCOVERY              | System Information Discovery [T1082]               |
| EXECUTION              | Shared Modules [T1129]                             |
+------------------------+---------------------------------------------------+

+------------------------+---------------------------------------------------+
| Capability             | Namespace                                         |
|------------------------+---------------------------------------------------|
| contain anti-debug     | anti-analysis/anti-debugging                      |
| encode data using XOR  | data-manipulation/encoding                        |
| access PEB             | linking/runtime-linking                           |
+------------------------+---------------------------------------------------+

Pro Tip: Run capa with the -v (verbose) flag to see which specific rules matched and at what file offsets. This gives you targets for Ghidra analysis later.

Step 3: PE structure analysis with PeStudio or CFF Explorer

Examine the PE header for anomalies:

• Sections: Look for unusual names, high entropy values, and sections with both WRITE and EXECUTE permissions
• Imports: A minimal IAT (only LoadLibraryA/GetProcAddress) strongly suggests runtime API resolution, which is common in packed or manually-loaded executables
• Resources: Check for embedded executables, scripts, or configuration data in the resource section
• Timestamps: Compilation timestamps can be forged but may provide intelligence when correlated with other samples
• DynamicBase flag: If not set, ASLR is disabled, which simplifies debugging

Phase 3: Dynamic Analysis -- Observing Runtime Behavior

Dynamic analysis executes the sample in a controlled environment to observe its actual behavior. This is where hypotheses from static analysis get tested.

Pre-execution checklist:

1. Snapshot your VM (you will revert to this state)
2. Start Procmon with the filter: Process Name is suspect.exe
3. Start Wireshark capture on the analysis network interface
4. Start FakeNet-NG to intercept and respond to network requests
5. Take a Regshot first snapshot for filesystem/registry comparison
6. Open Process Hacker to monitor process creation

Execution and monitoring:

1. Execute the sample
2. Wait 2-5 minutes for initial behaviors to complete
3. Interact with the system if the sample expects user activity
4. Take a Regshot second snapshot
5. Stop captures and begin analysis of collected data

Procmon analysis strategy:

Apply these filters progressively to focus on meaningful events:

Operation: WriteFile       -> File drops and modifications
Operation: RegSetValue     -> Registry persistence and configuration
Operation: TCP Connect     -> Network connection attempts
Operation: Process Create  -> Child process spawning
Operation: Load Image      -> DLL loading (especially from unusual paths)

Wireshark / FakeNet-NG analysis:

# Useful Wireshark display filters
dns                        # DNS queries reveal C2 domains
http.request               # HTTP requests to C2 servers
tcp.flags.syn == 1         # Connection attempts
tls.handshake.type == 1    # TLS ClientHello (check SNI field)

Phase 4: Targeted Reverse Engineering

Only escalate to reverse engineering when static and dynamic analysis leave specific unanswered questions. Common reasons to escalate include:

• The sample is packed and you need to unpack it to continue analysis
• An encrypted configuration blob needs to be decoded
• A specific capability hinted at by capa or strings needs confirmation
• Anti-analysis mechanisms are blocking dynamic analysis

Unpacking strategy using API breakpoints:

A common and effective unpacking approach involves anticipating what API calls the sample will make near the Original Entry Point (OEP). Setting breakpoints on these APIs can land you close to unpacked code:

# In x32dbg command window:
SetBPX LoadLibraryA        # Catch DLL loading near end of unpacking
SetBPX VirtualProtect      # Catch memory permission changes for code execution
SetBPX VirtualAlloc        # Catch memory allocation for unpacked code

When VirtualProtect is called with the PAGE_EXECUTE_READ flag (0x20), this often indicates the sample is preparing to execute unpacked code. Follow the first parameter to find the memory region containing the unpacked PE.

Memory dumping and reconstruction:

After reaching the unpacked code, extract it from memory:

1. In x32dbg, go to Memory Map and locate the region with the unpacked PE
2. Right-click and select "Dump Memory to File"
3. Use pe_unmapper to fix alignment: pe_unmapper /in dumped.exe /base 400000 /out fixed.exe
4. Use Scylla (Plugins > Scylla in x32dbg) to rebuild the IAT
5. Verify the reconstructed file loads cleanly in PeStudio or Ghidra

Caution: Memory breakpoints can interfere with VirtualProtect calls from the sample. If the sample makes multiple VirtualProtect calls, let it complete them before setting memory breakpoints to avoid undoing the sample's permission changes.

Professional Report Template

The following template structures your findings for maximum impact. Each section serves a specific audience need.

Section 1: Executive Summary (3-5 sentences)

Write this last. Summarize what the malware is, what it does, and what the immediate risk is. This section is for management and non-technical stakeholders.

Example structure:

• Sentence 1: What was analyzed and when
• Sentence 2: What the malware is (family, type, classification)
• Sentence 3: Primary malicious capabilities observed
• Sentence 4: Immediate risk assessment
• Sentence 5: High-level recommendation

Section 2: Key Findings (Bulleted list)

Enumerate the 5-8 most important findings, each as a single clear statement with the supporting evidence source in parentheses.

Section 3: Indicators of Compromise (IOC Table)

IOC Quality Checklist:

• Is the indicator specific enough to avoid false positives?
• Is context provided so a responder knows what it means?
• Is the source tool documented for reproducibility?
• Are network indicators defanged (e.g., evil[.]com, hxxp://)?

Section 4: Behavioral Timeline

Present events in chronological order from sample execution:

Section 5: MITRE ATT&CK Mapping

Section 6: Recommendations

Provide actionable, prioritized recommendations:

1. Immediate: Block identified IOCs (domains, IPs, hashes) at perimeter and endpoint
2. Short-term: Scan enterprise for IOCs; investigate any matches as potential compromises
3. Medium-term: Deploy detection rules (YARA for file, Sigma for behavior) to catch variants
4. Long-term: Address the initial access vector to prevent recurrence

Evidence Discipline

For every IOC or claim in your report, include:

• The source tool that produced the evidence
• The timestamp or sequence position when the event occurred
• The exact artifact location (file path, registry key, network address, memory offset)
• Reproducibility instructions so another analyst can verify your finding

This discipline separates professional analysis from guesswork and is the foundation of defensible incident response.

Deliverable Checklist

Before marking your capstone as complete, verify:

• All three hash types recorded (MD5, SHA-1, SHA-256)
• IOC table includes file, host, and network indicators with context
• Behavioral timeline has at least 8 events in chronological order
• ATT&CK techniques are mapped with specific evidence citations
• Executive summary is written for a non-technical audience
• Recommendations are actionable and prioritized
• All tool names and versions are documented
• Report has been proofread for clarity and accuracy
• Evidence screenshots or log excerpts are included where appropriate