reverse-golang-malware

name

reverse-golang-malware

description

Use this skill when analyzing stripped, packed, or statically linked Go malware or suspicious Go binaries and the goal is to recover build metadata, separate user logic from runtime noise, map packages and goroutine behavior, extract high-signal evidence, and produce defensible capability and next-step assessments. Use when the workflow should combine fast CLI triage (file, sha256, binwalk, strings, go version -m) with concrete `ida-pro-mcp` steps (`decompile`, `xrefs_to`, `find_regex`, `export_funcs`) or AI-assisted structured survey before deep reversing. Trigger on Go malware behavior reconstruction, goroutine-heavy samples, dispatcher or C2 handler hunting, or when symbol recovery is already done and analyst focus shifts to capabilities.

Reverse Golang Malware

Use this skill when the sample is Go and the analyst needs a practical malware workflow rather than only symbol recovery.

Guardrails

• Separate user code from runtime, standard library, and vendor code.
• Verify version and build context before drawing layout-sensitive conclusions.
• Do not over-interpret compiler-generated wrappers or runtime helpers as attacker logic.
• Treat package names as clues, not proof of actor identity or behavior.
• Keep facts, inferences, hypotheses, and unknowns distinct.

Inputs

Prioritize:

• recovered names, package paths, and build metadata
• strings, file paths, and config material
• main.main, init chain, and goroutine launch sites
• network, crypto, filesystem, process, and persistence packages
• decompiler output, xrefs, and sandbox observations

If names and types are still poor, first use reverse-golang-symbol-recovery.

If many artifacts are available, read references/go-artifacts.md.

If concrete IDA-driven steps are needed, read references/ida-mcp-workflow.md.

If a deliverable is needed, use assets/golang-analysis-template.md.

Workflow

Phase 0: structured survey

Produce a short, structured first pass: format, hash, packer or nested payload hints, Go version or range, and a rough capability sketch (network, execution, persistence, crypto). Run Phase 1 commands immediately; if ida-pro-mcp is connected, use the "Go-biased survey" prompt from reverse-ida-mcp-driver/references/survey-prompts.md rather than ad-hoc tool calls — it already batches list_funcs, find_regex, py_eval pclntab_finder, and a cost-budgeted decompile of main.main into a single structured output.

Phase 1: establish compile context

Start with a pragmatic local pass:

file sample.bin
sha256sum sample.bin
binwalk -Me sample.bin
strings -a -n 8 sample.bin | rg -i 'http|https|grpc|dns|tls|cmd|powershell|/bin/sh|/etc/|/tmp/|go1\.|github\.com/'
go version -m sample.bin

If the disassembler’s string list looks far smaller than strings -a on disk, treat that as a coverage gap. Use references/ida-mcp-workflow.md, and if symbol or path recovery is still weak, hand off to reverse-golang-symbol-recovery.

Identify:

• Go version or version range
• binary format and architecture
• packed vs unpacked state
• module path, build path, or build ID clues
• stripped status and symbol-recovery quality

Phase 2: isolate attacker-controlled logic

Prioritize:

• main.main
• main.init and init chain
• user packages outside runtime, internal, vendor, or obvious stdlib paths
• goroutine entry points
• config loaders and command-line parsing

If ida-pro-mcp is connected, use:

• decompile on main.main, main.init, and the largest non-runtime functions
• xrefs_to on runtime.newproc, runtime.newproc1, runtime.makechan, runtime.chansend*, runtime.chanrecv*, and runtime.selectgo
• find_regex for C2 URLs, domains, shell strings, service names, paths, and mutexes
• analyze_funcs on the largest handler or dispatcher candidates

Phase 3: recover behavior from packages and types

Look for:

• network packages such as net, net/http, tls, grpc, websocket, or DNS clients
• process and shell execution paths
• filesystem traversal and staging paths
• persistence or service-install logic
• crypto, compression, or encoding helpers
• message structs, JSON tags, or protocol enums

Phase 4: map concurrency and dispatch

For Go samples, pay special attention to:

• goroutines created near main.main
• channel send and receive loops
• select-style dispatch logic
• worker pools and task queues
• timer or ticker driven beacons

If you have pseudocode or text exports, score likely goroutine-heavy functions:

python3 scripts/goroutine_hotspots.py exported-pseudocode.txt

Preferred export source:

• export_funcs from ida-pro-mcp when available
• otherwise analyst-curated pseudocode or text copied from the disassembler

Phase 5: produce next pivots

Use the recovered evidence to decide whether to hand off to:

• reverse-protocol-reconstruction
• reverse-operator-attribution
• reverse-botnet-dismantling
• reverse-reporting

Minimum artifact bundle:

• sample hash and format
• Go version or range plus BuildID if present
• user-code shortlist
• goroutine, channel, and dispatcher evidence
• network, filesystem, process, crypto, and persistence hits
• MCP exports only if they actually ran

Output format

Go Malware Analysis Summary

Executive Summary

[2-5 sentences]

Facts

Inferences

Hypotheses

Unknowns

User-Code Shortlist

Capability Notes

High-Signal Artifacts

Recommended Next Actions