Go goroutine concurrency in main payload path

The Go compiler emits go func() statements as goroutine launches, creating an anonymous closure that appears as a .func1 child symbol in the binary's .symtab. In malware, this primitive enables parallel execution paths (e.g., C2 beaconing while the main thread steals credentials) without manual thread management.

What to look for

In radare2/Ghidra analysis of stripped Go binaries, a parent function main.xxxxx with a child main.xxxxx.func1 strongly suggests a goroutine was spawned inside the parent. The .func1 suffix is a Go compiler artefact, not a naming convention chosen by the malware author. The parent typically contains:

• runtime.newproc or runtime.newproc1 calls (Go runtime goroutine scheduler)
• Channel operations (runtime.chansend1, runtime.chanrecv1) for inter-goroutine communication
• sync.WaitGroup or sync.Mutex references if coordination is required

Why it matters for analysis

• Timing attacks: Sandboxes that hook single-threaded execution may miss the .func1 goroutine entirely if it runs on a different OS thread.
• C2 heartbeat: Parallel goroutines can maintain a persistent C2 connection while the main thread performs exfiltration, reducing observable network idle time.
• Anti-debug: GDB/WinDbg may not automatically follow goroutine switches unless info goroutines / runtime.goroutine are used.

Observed in

• lummastealer sibling c25d9423 — main.xregypl + main.xregypl.func1 (first observed in cluster). See /intel/analyses/c25d942315b926dab7c1a3aff907891b0f3c7db6ff809d3399b6af6c4d389c67.html.
• Other Go malware families (e.g., stealc, redline) may use the same primitive; look for .func1 closures in the main package.

Related

• golang-stealer-build-pattern — Go malware build artefacts
• lummastealer — family where this was first observed