Golang Malware Detection and C2 Analysis

July 4, 2026

CybersecurityGoMalware AnalysisC2 FrameworksWiresharkVirusTotalGhidraCS433: Network Security

Overview

This CS433 project explored a question that felt especially relevant as I was moving further into cybersecurity: how well do common security tools understand malware written in Go?

Our team researched the rise of Golang malware, built and studied a small Go-based command-and-control framework called G0re, and evaluated how detection and analysis tools responded to it. The project focused on the differences between Go-based malware and more traditional C-based malware, especially around static compilation, larger binaries, cross-platform builds, obfuscation, network traffic, and reverse engineering.

The original source repository was owned by a former classmate and can no longer be located; it may have been deleted or made unavailable.

Context

At the time, I had recently switched toward cybersecurity and was still much less experienced than one of my classmates, who had significantly more knowledge in malware development and low-level security research. I do not want to overstate my role in this project. A lot of my contribution was not writing the core C2 implementation from scratch; it was learning the domain quickly, helping with research and writing, contributing to documentation and presentation work, supporting testing and analysis, and understanding how the technical pieces fit together.

That was still valuable work for me. This project helped me connect classroom security concepts to real tooling: antivirus detection, command-and-control traffic, network captures, obfuscation, and reverse-engineering workflows. It was one of the projects that helped me better understand what malware analysis looks like from both an attacker-modeling and defender-analysis perspective.

What We Studied

The project centered on G0re, a Golang-based C2 framework with three main components:

  • An implant that registers with the server, polls for commands, executes received instructions, and sends command output back
  • A server that tracks implants by UUID and coordinates command/output messages
  • An admin client that acts as the operator interface for sending commands

We used the project as a controlled academic example for evaluating detection and analysis. The work included Windows Defender behavior, VirusTotal results, Wireshark packet captures, Garble obfuscation, GoReSym symbol recovery, and Ghidra reverse engineering.

My Contributions

  • Helped research the rise of Golang malware and why Go creates different detection and reverse-engineering challenges than older malware development languages
  • Contributed to the written report, especially the background, motivation, related work, and explanatory framing around Go malware detection
  • Helped document how the C2 framework was structured, including the implant, server, client, gRPC communication, and protobuf messages
  • Supported testing and analysis discussions around Defender, VirusTotal, Wireshark, Ghidra, GoReSym, and Garble
  • Helped prepare the final presentation so the project could be explained clearly to classmates and instructors
  • Used the project as a learning opportunity to better understand malware analysis, command-and-control infrastructure, and defensive detection tradeoffs

Key Findings

One of the clearest findings was that Go binaries can create noisy and sometimes unreliable detection behavior. In our testing, Windows Defender flagged an unobfuscated implant, but detection changed when the binary was wrapped with Garble. The report notes that Defender classified the implant as Trojan:Win32/Wacatac.B!ml, but also that Go binaries have a history of false positives. That made the result more complicated than a simple "detected" or "not detected" outcome.

Network analysis was more direct. Because the project did not yet use TLS, Wireshark could show the gRPC/HTTP2 communication pattern between the implant and server. The report describes how consistent polling intervals and visible UUID-like identifiers could become useful signals for defenders.

Reverse engineering was also harder than I expected. Go's static compilation includes a large amount of library code in the binary, which makes tools like Ghidra more difficult to navigate. Instead of a clean separation between custom logic and imported library calls, the decompiled output can become large and noisy.

Presentation Walkthrough

These slides show the project motivation, methodology, code/demo work, evaluation, and improvement ideas from our final CS433 presentation.

Project title

Our CS433 final project focused on Golang malware detection, deobfuscation, and a small command-and-control framework called G0re.

1 / 7

These carousel images are slide previews. For a clearer view, open the PowerPoint presentation.

Project Documents

What I Learned

This project was humbling in a good way. I was not the most experienced person on the team, and there were many moments where I was catching up to concepts my classmate already understood much more deeply. Instead of trying to frame that as a weakness, I see it as one of the reasons the project mattered to me. It pushed me to read more carefully, ask better questions, and translate unfamiliar technical work into writing and presentation material that made sense.

I also learned that malware analysis is rarely a single-tool answer. A detection result from Defender or VirusTotal needs context. A packet capture can reveal behavior that static scanning misses. Reverse engineering can be slowed down by language design choices, build artifacts, and obfuscation. The project gave me a more realistic view of how defensive analysis works: you rarely get perfect evidence from one place, so you build confidence by combining signals.

Tech Stack and Tools

  • Go / Golang
  • gRPC
  • Protocol Buffers
  • Garble
  • Wireshark
  • VirusTotal
  • Windows Defender
  • Ghidra
  • GoReSym

Links

GitHub
LinkedIn