Go Malware Meets IoT - Challenges, Blind Spots, and Botnets

Go Malware Meets IoT - Challenges, Blind Spots, and Botnets

Speakers: Asher Davila (Principal Security Researcher, Palaton Networks), Chris (Senior Principal Security Researcher, Palto Networks)

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=TtPicirB6G4

Overview

This talk, presented by Asher Davila and Chris from Palaton Networks, delves into the growing trend of malware written in Google's Go programming language, specifically focusing on its impact on Internet of Things (IoT) devices. The speakers illuminate the unique challenges Go presents to malware analysts and reverse engineers, from its characteristic large, statically-compiled binaries to its distinct string handling and compilation artifacts. The presentation aims to equip the security community with an understanding of Go malware’s intricacies and to highlight effective strategies and tools, including the burgeoning role of AI-assisted analysis, for dissecting these sophisticated threats.

The increasing adoption of Go by malware authors is driven by its cross-platform compatibility, ease of development, and inherent obfuscatory properties that complicate traditional analysis. As IoT devices proliferate and become more integrated into critical infrastructure, the emergence of Go-based malware targeting these systems poses a significant and evolving threat. This talk is crucial for security researchers, incident responders, and network defenders who need to understand the evolving threat landscape and adapt their methodologies to effectively combat Go-based malware, particularly in the often-under-secured IoT domain.

Background

▶ Watch: Why Go is attractive for malware development (1:30)

The Go programming language, designed by Robert Griesemer, Rob Pike, and Ken Thompson at Google in 2007 and publicly released in 2009, has rapidly gained traction among developers. Its appeal lies in its simplicity, performance, and built-in concurrency. However, these very features, coupled with others, have also made it an attractive choice for malware developers.

Malware writers favor Go for several key reasons:

• Cross-platform compatibility: Go supports over 16 operating systems, allowing a single codebase to target a wide array of environments without significant modification.
• Statically compiled binaries: By default, Go binaries are self-contained, including all necessary libraries. This leads to significantly larger file sizes but reduces external dependencies and makes static analysis more challenging for traditional tools. Dynamically linked binaries can occur when using CGO for interoperability with C libraries.
• Analysis complexity: The large file sizes and high function counts (due to static linking of runtime components) make Go binaries inherently more difficult to analyze and reverse engineer compared to malware written in C or C++. This complicates the identification of malicious logic amidst extensive legitimate Go runtime code.
• Unique string handling: Unlike C/C++'s null-terminated strings, Go strings are non-null terminated, stored as a structure containing a pointer to the byte array and its length. This difference can confuse conventional string extraction tools and analysis techniques.

The security industry has already observed a significant rise in Go-based malware. Unit 42, Palaton Networks' threat intelligence team, reported on GoBruteForcer, a Go-based botnet actively harvesting web servers. Other notable examples include Go-based malware targeting Linux routers (e.g., Goat), various Go-based Trojans, and the critical infrastructure-targeting malware Frosty, which attacked the Modbus protocol in Ukraine. Frosty notably introduced a new artifact called GoEncrypt, a secondary tool used to encrypt and decrypt JSON configuration files. Internal telemetry from Palaton Networks indicated a data peak in Go malware in February and March 2023, encompassing botnets, coin miners, and sleeper implants. Prominent Go malware families include SecCryGo (recon and exfiltration by APT24), CodeTier (wiper ransomware), Pumabot (IoT device attacks via SSH brute force), and BotanaGo (IoT scanner and exploiter).

These characteristics present substantial challenges for traditional program analysis:

• Large File Size: Go binaries can be several megabytes even for simple "Hello World" programs (e.g., 2.2 MB for Go vs. 16 KB for C), making them prone to evading security scanners with file size limitations.
• High Function Count: Static linking results in thousands of functions, making it arduous for reverse engineers to navigate and pinpoint malicious code.
• Tooling Limitations: Most existing reverse engineering tools are optimized for C/C++ binaries, struggling with Go's unique characteristics.
• String Handling: The non-null terminated string structure requires specialized handling, as conventional string search utilities often fail to correctly parse them.

Key Findings

▶ Watch: Deep dive into Frosty malware and GoEncrypt (3:50)

The talk highlights several key findings regarding the unique characteristics of Go binaries and the challenges they pose for traditional analysis:

1. Discrepancy in Binary Size: A "Hello Devcon" program compiled in C resulted in a 16 KB binary, whereas the exact same program in Go produced a massive 2.2 MB executable. This stark difference underscores Go's default static linking, which embeds the entire Go runtime into the binary, contributing to its large footprint and making it harder for security scanners to process within typical file size limits.

1. Function Count Explosion: The simple "Hello Devcon" Go program contained approximately 1,800 functions, while its C counterpart had only 10. This immense function count in Go binaries, primarily due to the statically linked Go runtime, significantly complicates reverse engineering by obscuring the actual malicious logic amidst a vast amount of legitimate, but irrelevant, code.

1. Distinct String Handling: Go strings are fundamentally different from C/C++ strings. They are not null-terminated but are instead represented by a structure containing a pointer to a byte array and its length. This makes it challenging for standard string extraction tools, which rely on null terminators, to accurately identify and extract strings from Go binaries. Often, strings appear as "chunks of garbage" when viewed with conventional tools.

1. Unique Go Binary Sections: Go binaries introduce specific sections crucial for analysis:

• go build info: Present in ELF and Mach-O files (found within data sections for PE files), this section contains valuable metadata if compiled with go.mod enabled. It includes the Go version, architecture (e.g., AMD64), operating system (e.g., Linux), and some command-line arguments used during compilation. The Go version is particularly important as it influences other binary structures.
• go PC link table (Program Counter Line Table): This acts as a map, aiding reverse engineers in reconstructing the binary. It contains pointers to memory addresses (program counters) mapped directly to assembly lines and pointers to metadata for each function. Crucially, the magic number that identifies this table changes with different Go compiler versions, a detail that can break custom parsing scripts if not accounted for. This table is vital for tools to correctly identify and rename functions, overcoming the initial obfuscation caused by high function counts.

These findings collectively emphasize that analyzing Go malware requires specialized tools and an understanding of its unique compilation and runtime characteristics, as traditional reverse engineering approaches often fall short.

Technical Deep Dive

▶ Watch: Key challenges in analyzing Go binaries (4:50)

Analyzing Go malware necessitates a specialized toolkit and methodologies that account for its unique binary structure. The speakers showcased several open-source and commercial tools, highlighting their application and the challenges they address.

Go Analysis Tooling

For disassembly and decompilation, standard tools like Radare2 (R2), Ghidra, and Binary Ninja can be used. However, their effectiveness for Go binaries is often enhanced by specific plugins or configurations. For instance, Ghidra supports a Go compiler option, though it may still struggle with complete string reconstruction.

To overcome Go's string handling complexities, specialized tools are essential:

• GoStrings: A Ghidra plugin developed by NCC Group, GoStrings provides a multi-step workflow (eight steps, some optional) to reconstruct Go strings, significantly improving readability in the decompiler output.
• GoRedTeam and Red: These additional tools offer further capabilities for dealing with complex Go binary analysis.

AI-Assisted Analysis

A significant portion of the talk focused on the emerging role of AI-assisted tools in Go malware analysis:

• R2AI: Described as a "Clippy" for Radare2, R2AI acts as an assistant, suggesting R2 commands based on user queries. This is particularly useful for R2's steep learning curve, as it operates at a low level, starting analysis from the loader rather than the main function, and uses mnemonics instead of higher-level commands. R2AI can leverage various language models (e.g., Gemini 2.5 Pro) and can assist with tasks like identifying the development language, analyzing binary information, and listing functions. It also includes a DK model for decompiling assembly or intermediate representation (like R2's EIL) into source-like code.

• Ghidra MCP (Multi-Modal Code Property Graph): This is a fully automated AI agent that can be integrated with Ghidra. It allows users to ask questions about a binary (e.g., "disassemble the binary," "tell me what the program is doing") and receive detailed analysis, including binary characteristics and expected output, without manual interaction. It can connect to local or commercial LLM providers like Claude.

• Sidekick (for Binary Ninja): A plugin for Binary Ninja, Sidekick offers a chat interface to ask specific questions about a binary. It's designed for targeted queries (e.g., "what is this string used for?", "find C2s") rather than holistic analysis. It proved effective in quickly identifying malware behaviors, C2 domains, and confirming malware families.

Case Study: BotanaGo IoT Malware

BotanaGo is a Go-based ELF 64-bit IoT malware, first discovered in 2021, targeting a wide range of IoT devices. It scans for and exploits over 30 vulnerabilities, establishes backdoors, and drops additional shells. The analyzed sample (SHA256: 911f43a2909f2b8b9cf2a5a5875d6540c777271e16f5c53b26c3677b102c0b49) was detected by 41 out of 66 VirusTotal vendors.

Analysis of BotanaGo revealed:

• Vulnerability Exploitation: Cross-referencing strings from the binary with public exploit databases identified exploits like CVE-2020-27209, targeting Sanji GPON home routers for authentication bypass and command injection.
• Infection Functions: Tools like goreasim and Ghidra revealed numerous functions explicitly named by the malware author, such as infect_alcatel, infect_dlink, infect_fiberhome, infect_gpon, and infect_huawei, clearly indicating targeted vendors and device types. Other supporting functions included reverse_shell, scanner_init, and exploit.
• Payload Reconstruction with AI: Ghidra MCP was tasked with analyzing the infect_GPON_og function to reconstruct the attack payload. The AI successfully identified red flags like network connections and payload delivery mechanisms. It pinpointed data addresses related to HTTP request components (headers, user agents, primary attack payload). While the AI provided a reconstructed payload, including elements like busybox wget, manual verification revealed inaccuracies. The AI initially suggested a "hungian payload" instead of the correct GPG payload inferred from other parts of the binary. This highlighted the necessity of validating AI outputs.
• Network IOCs: Extensive string analysis revealed numerous GET and POST requests, HTTP headers, and suspicious commands (e.g., wget), indicating command injection attempts and C2 communication.

Case Study: Pumabot IoT Malware

Pumabot is another Go-based IoT malware, known for SSH brute force attacks. Analysis showed it was dynamically linked, a less common but possible scenario for Go binaries when they invoke C libraries via CGO.

• Binary Ninja + Sidekick: Sidekick was used to analyze Pumabot. When asked "what are the most important behaviors of the malware?", Sidekick accurately identified SSH brute force attacks, C2 connections, and the presence of the string "pumatronics," linking it to the Pumabot family.
• Function Analysis: Sidekick further described the main_brute_force_root function as enumerating IPs from URLs and passing them to try_ssh_login, which performs up to five retries.
• C2 Identification: Sidekick correctly identified C2 domains, though it sometimes missed a complete list of important strings, requiring cross-referencing with other tools like Claude.
• Persistence Mechanism: Analysis of the system_service function revealed that Pumabot establishes persistence by creating a service file disguised as mySQI (instead of MySQL), using xx_start to configure it. This is a common evasion technique. The "pumatronics" string also pointed to the malware targeting Brazilian surveillance and traffic camera systems manufactured by Pumatronics.

Case Study: Goblin EXE (CTF Challenge)

The talk concluded with a reverse engineering CTF challenge, Goblin EXE, a benign Go-based packer/cryptor. This served as a test for the AI's capabilities against more complex, custom obfuscation.

• R2AI's Performance: R2AI was tasked with solving the challenge, which involved identifying encrypted packed data and custom compression algorithms. The AI successfully identified it as a Go binary and noted unusual section names like "ninjas don't cry," suggesting custom packing. It attempted to analyze sections, detect signatures, and decompress information. However, despite its efforts, including attempting emulation and debugging, R2AI failed to solve the challenge. The outcome was summarized as "R2AI zero, Goblin EXE one," demonstrating that while AI is a powerful assistant, it struggles with novel, custom obfuscation techniques that deviate from known patterns. It highlighted the AI's limitation in handling unknown compression algorithms and the lack of contextual understanding required for such a challenge.

Demo / Proof of Concept

▶ Watch: Recommended tools for Go malware analysis (6:20)

The talk effectively demonstrated the practical application of various tools, both traditional and AI-assisted, in the analysis of Go malware. While no single "exploit PoC" was presented, the following aspects served as compelling demonstrations of the analysis workflow:

1. Go Binary Comparison ("Hello Devcon"): The initial comparison of C and Go "Hello Devcon" binaries vividly demonstrated the drastic difference in file size (16KB vs. 2.2MB), function count (10 vs. 1800), and string representation. This visual and statistical comparison served as a foundational proof of Go's unique characteristics that complicate analysis. The disassembly and decompiler views in Ghidra and R2 further illustrated how the Go version immediately presented a much larger and less decipherable code base compared to the clear C output.

1. GoStrings Plugin for Ghidra: The speakers demonstrated the effectiveness of the GoStrings plugin. Before running the plugin, the Ghidra decompiler output for the Go "Hello Devcon" program was largely unreadable concerning strings. After executing the GoStrings script in the suggested order, the decompiler successfully reconstructed and displayed clear strings like "Hello Devcon," proving its utility in overcoming Go's non-null terminated string handling.

1. Ghidra MCP for BotanaGo Analysis: A key demonstration involved using Ghidra MCP with Claude to analyze the infect_GPON_og function within the BotanaGo malware. The AI agent was prompted to identify the function's purpose, red flags, and reconstruct the final attack payload.

• Function Purpose and Red Flags: Ghidra MCP provided a detailed summary, identifying network connections, payload delivery, string manipulation, and memory management as indicators of malicious intent.
• Payload Reconstruction: The AI successfully correlated data addresses with HTTP request components. It was able to construct a partial HTTP exploit request header, including a user agent (Mozilla, which was noted as suspicious for a WGET command) and a URL-decoded command injection payload. While the AI’s initial payload suggestion (hungian payload) was incorrect and required manual override to the correct GPG payload, the demonstration showed its capability to gather and synthesize disparate pieces of information to attempt payload reconstruction, significantly accelerating initial analysis.

1. Binary Ninja Sidekick for Pumabot Analysis: The talk showcased Sidekick's ability to quickly extract critical intelligence from the Pumabot malware.

• Behavioral Summary: A general query about "most important behaviors" immediately yielded insights into SSH brute force attacks, C2 connections, and the presence of the "pumatronics" string, linking it to a known malware family.
• Function Description: Specific questions about main_brute_force_root and try_ssh_login functions resulted in accurate descriptions of their roles in enumerating IPs and attempting SSH logins with retries.
• C2 Extraction: Sidekick successfully identified C2 domains, although a more comprehensive list required cross-validation with other tools.
• Persistence Mechanism: The analysis of system_service and its role in creating a disguised mySQI service for persistence was clearly demonstrated, highlighting Sidekick's ability to uncover such tactical details.

1. R2AI's Attempt on Goblin EXE CTF: The final demonstration involved R2AI attempting to solve a custom-packed Go CTF challenge. This showcased the AI's interactive nature, where it suggested commands for full analysis, section examination, and signature detection. While R2AI identified custom packing and attempted various decompression algorithms, it ultimately failed to solve the challenge, illustrating the current limitations of AI against novel, custom obfuscation. This "R2AI zero, Goblin EXE one" outcome served as a powerful reminder that AI is an assistant, not a replacement, for human expertise in complex scenarios.

These demonstrations collectively underscored the evolving landscape of malware analysis, where AI tools can significantly aid in initial triage and information gathering but still require human validation and intervention for complex, custom, or highly obfuscated threats.

Defensive Implications

▶ Watch: Stark comparison: Go vs C binary size (7:00)

The rise of Go-based malware, particularly targeting IoT devices, necessitates a proactive and adaptive defensive posture. Defenders should consider the following implications:

1. Patch and Secure IoT Devices: The primary defense remains robust security hygiene. Given that malware like BotanaGo exploits over 30 vulnerabilities, it is critical to keep all IoT devices, especially routers and critical infrastructure components (e.g., GPON routers, DVRs), fully patched. Implement strong, unique passwords for all devices, disable unnecessary services, and segment IoT networks where possible.

1. Enhance Go Malware Analysis Capabilities: Security teams need to invest in training and tools specifically designed for Go binary analysis. Relying solely on traditional C/C++ focused tools will lead to blind spots. Incorporate Go-aware disassemblers/decompilers (Ghidra with Go compiler options, Binary Ninja), string recovery tools (GoStrings), and Go-specific analysis frameworks (goreasim).

1. Leverage AI as an Assistant, Not a Sole Authority: AI-assisted tools like R2AI, Ghidra MCP, and Sidekick can significantly accelerate initial triage, identify patterns, extract C2s, and even attempt payload reconstruction. However, as demonstrated by the Goblin EXE challenge and the BotanaGo payload reconstruction, AI outputs must be rigorously validated by human analysts. Defenders should integrate AI into their workflows to automate repetitive tasks and filter out noise, allowing human experts to focus on complex, custom, or ambiguous findings.

1. Monitor for Go-Specific Artifacts: Defenders should develop detection rules and monitoring strategies that look for Go-specific binary characteristics, such as unusually large file sizes for simple executables, the presence of go build info and go PC link table sections, and specific Go runtime functions in process memory.

1. Be Aware of Persistence Mechanisms: Malware like Pumabot utilizes stealthy persistence mechanisms (e.g., disguising services like mySQI). Implement robust endpoint detection and response (EDR) solutions that can monitor for the creation of new services, unusual process execution from temporary directories, and modifications to system startup configurations, especially on Linux-based IoT devices.

1. Network-Level Detection: Monitor network traffic for indicators of compromise (IOCs) identified from Go malware analysis, such as specific HTTP headers, suspicious GET/POST requests, command injection attempts, and C2 communication patterns. Pay attention to unexpected outbound connections from IoT devices.

1. Threat Intelligence Sharing: Stay updated with the latest threat intelligence on Go-based malware families (e.g., BotanaGo, Pumabot, Frosty) and their targeted vulnerabilities. Sharing IOCs and analysis findings within the security community is crucial for collective defense.

By combining traditional reverse engineering expertise with Go-specific tools and intelligently integrating AI, defenders can build a more resilient defense against the evolving threat of Go malware targeting the increasingly vulnerable IoT landscape.

Key Takeaways

• Don't Fear Irregular File Structures: Embrace the challenge of analyzing binaries that don't conform to standard parsing expectations. Reading documentation and understanding the compiler's build process is key when tools struggle.
• Build a Hybrid Toolkit: Relying solely on traditional tools or entirely on AI is insufficient. A combination of open-source and commercial reverse engineering tools, augmented by AI assistants, provides the most comprehensive analysis capabilities.
• Validate AI Responses: AI tools are powerful assistants, but their outputs are not infallible. Always double-check and manually verify findings from AI, especially for critical details like exploit payloads or CVE identifications, as demonstrated by the BotanaGo analysis.
• Leverage AI for Automation: AI excels at automating repetitive tasks, filtering large datasets, and providing initial context, making human analysts more efficient. Use AI to triage numerous samples, allowing experts to focus on complex, unique threats.
• Tool Selection is Context-Dependent: There is no one-size-fits-all solution for malware analysis. The choice of tools and strategies should be dictated by the specific requirements of the task and the characteristics of the malware being analyzed.

About the Speaker(s)

Asher Davila is a Principal Security Researcher for Palaton Networks, specializing in IoT and OT vulnerabilities and malware research. He has presented at numerous security conferences, including DEF CON, RSA, and S4, and can be found online under the handle "Ashure Davila."

Chris is a Senior Principal Security Researcher at Palto Networks, where he focuses on detection engineering, particularly in C2 frameworks and malware. He is part of the advanced threat prevention team, with expertise in areas like Cobalt Strike. Chris has presented at conferences such as Black Hat Asia briefings and Black Hat US Arsenal.