Itinerary to Defeat Yet Another Beacon Implementation

Itinerary to Defeat Yet Another Beacon Implementation

Speakers: Naoki Takayama, Security Researcher, Internet Initiative Japan Inc.

Conference: FIRSTCON

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

Overview

In an era where sophisticated threat actors constantly adapt their tactics, techniques, and procedures (TTPs), the security community faces a continuous challenge in developing robust detection and response mechanisms. Naoki Takayama, a seasoned security researcher at Internet Initiative Japan Inc., presented a critical talk at FIRSTCON, shedding light on the emerging threat of re-implemented Cobalt Strike beacon payloads. This session, titled "Itinerary to Defeat Yet Another Beacon Implementation," delves into how adversaries are leveraging modern programming languages like Rust and Golang to create new variants of the ubiquitous Cobalt Strike beacon, effectively bypassing traditional detection methods.

Takayama's research is particularly timely given the persistent abuse of Cobalt Strike by a diverse range of threat actors, from state-sponsored APT groups to financially motivated cybercrime organizations. The talk not only dissects the technical intricacies of these novel beacon implementations but also provides practical methodologies and tools for defenders to analyze, detect, and respond to them. By sharing insights into function signature generation, YARA rule development, and configuration extraction techniques tailored for Rust and Golang binaries, Takayama empowers security analysts to stay ahead in the ever-evolving cat-and-mouse game against advanced adversaries. This research is crucial for any organization grappling with sophisticated threats, offering a pathway to enhance their defensive posture against next-generation adversary simulation tools.

Background

▶ Watch: Introduction to Cobalt Strike and emerging threats (0:00)

Cobalt Strike has long been a cornerstone in the arsenal of both red teams and malicious actors alike, lauded for its potent combination of functionality, stability, and stealth in post-exploitation operations. Its beacon payload serves as the primary communication channel and execution engine within compromised networks, offering features ranging from file management to process injection and the loading of Beacon Object Files (BOFs). Notable threat actors, including Lucky Mouse (APT27), Earth Long Zi (APT41), and the Black Basta ransomware gang, have been observed extensively leveraging Cobalt Strike in their campaigns, highlighting its widespread appeal across the threat landscape. While originally a commercial adversary simulation tool, cracked and leaked versions are readily available on platforms like GitHub and underground forums, making it accessible to a broader range of malicious actors.

For years, defenders have developed a sophisticated array of detection rules and analysis tools to counter Cobalt Strike's prevalence. Organizations like Elastic Security have published comprehensive YARA detection rules targeting various aspects of the beacon, including internal strings and specific opcode sequences associated with its sleep obfuscation routine. These rules are widely integrated into threat intelligence platforms such as VirusTotal and GTI Google Threat Intelligence, facilitating rapid identification of Cobalt Strike artifacts. Furthermore, tools like 1768.py, developed by Didier Stevens, have become indispensable for extracting critical configuration parameters (C2 server addresses, public keys, C2 profiles) from beacon payloads, providing defenders with vital indicators of compromise (IOCs). It's worth noting that Cobalt Strike's configuration format and encoding methods can vary across framework versions, necessitating the use of multiple parsing tools if one fails.

However, threat actors are continuously evolving their techniques to evade these established defensive measures. One common approach involves deploying beacon payloads encapsulated within custom loaders, designed to execute only in specific environments (e.g., particular Active Directory domain names). This strategy effectively thwarts execution in sandboxed environments and complicates automated configuration extraction, forcing analysts to manually unpack the beacon. Custom beacon implementations, such as those observed with the China Nexus APT group Tiangong, feature unusual config decode routines and custom sleep mask implementations, further disrupting existing detection logic. Data leaks, like the one in 2025, have also revealed groups like UNC 50221 deploying custom Linux-targeting Cobalt Strike beacons. These custom implementations add obfuscation layers, break detection rules, and allow for bespoke C2 channels, particularly common among Chinese state-sponsored APT actors.

A more recent and significant development, and the primary focus of this talk, is the re-implementation of Cobalt Strike beacon payloads in modern programming languages such as Rust and Golang. This trend gained momentum around 2020, following the leakage of the original Cobalt Strike framework's source code. With access to the underlying implementation, red teamers and enthusiasts began developing variants in languages known for their unique data structures, library functions, and code execution routines, which inherently complicate traditional reverse engineering analysis. Crucially, existing detection rules and config extractors, primarily designed for the original C++-based beacon, are rendered ineffective against these new Rust and Golang variants, posing a fresh challenge for the cybersecurity community.

Key Findings

▶ Watch: Re-implemented beacons in Rust/Golang complicate analysis (8:00)

Naoki Takayama's research highlights a critical shift in the adversary landscape: the widespread adoption of re-implemented Cobalt Strike beacons in modern programming languages like Rust and Golang. This trend significantly impacts defensive strategies, as these new variants bypass established detection and analysis tools designed for the original C++-based Cobalt Strike.

The presentation dissects three prominent open-source projects:

1. Cobalt Strike Beacon Rust: A simplistic, multi-platform implementation in Rust, primarily supporting remote shell commands.
2. Rust Beacon: A more feature-rich Rust implementation, supporting various post-exploitation capabilities like file/process management and BOF loading.
3. Geacon (specifically GeaconPro): A Golang implementation, known for its extensive features and history of being both publicly available and later privatized/leaked.

A crucial initial finding is that, in their current open-source forms, these re-implemented beacons often store their configuration parameters in plain text within the compiled binary. While this initially simplifies IOC extraction using basic strings commands, it's acknowledged that this is a temporary vulnerability that threat actors can easily remediate through obfuscation.

The core contribution of Takayama's work lies in demonstrating that function signature generation (using tools like FLIRT, PCF, and Sigmake) is an effective and robust method for analyzing these Rust and Golang binaries. By compiling the open-source projects as static libraries or with debug symbols, defenders can create accurate function signatures that label library code and custom beacon routines within unknown samples. This dramatically accelerates reverse engineering efforts, even when obfuscation is applied.

Furthermore, the research revealed the presence of these re-implemented beacons in the wild. Takayama noted more than 30 samples of Rust Beacon, with a significant cluster pointing to a specific C2 IP address (95.40.21.84), suggesting a single threat actor or group's interest. For GeaconPro, over 100 samples with diverse C2 addresses were identified on VirusTotal, indicating broader adoption and modification by various adversaries. Despite this real-world abuse, these samples often exhibit low detection rates (around 20-30 detections) on VirusTotal, underscoring the urgent need for updated detection mechanisms.

To address this gap, Takayama has developed and publicly shared FLIRT function signature files and YARA detection rules for all three projects on GitHub, providing immediate actionable intelligence for the defensive community.

Technical Deep Dive

▶ Watch: Analyzing Cobalt Strike Beacon Rust: strings and signatures (9:45)

The technical core of Takayama's presentation revolves around the dissection and analysis of three distinct open-source Cobalt Strike beacon re-implementations: Cobalt Strike Beacon Rust, Rust Beacon, and GeaconPro. Each project presents unique challenges and opportunities for defenders, primarily due to their underlying programming languages – Rust and Golang.

Cobalt Strike Beacon Rust

This project, available on GitHub since 2023, is characterized by its simplicity and multi-platform support (Windows, macOS, Linux). It primarily implements remote shell commands, with other post-exploitation features commented out in the source code, suggesting it's an incomplete or abandoned project. A key observation is the presence of numerous debug print statements within the source, which can aid dynamic analysis.

Crucially, the configuration parameters for Cobalt Strike Beacon Rust are hardcoded in plain text within a file named profile.rs. This means C2 server addresses, user agent strings, and other IOCs are directly visible in the compiled binary. While a simple strings command might seem sufficient, Takayama warns that Rust string slices are not necessarily null-terminated, leading to potentially inaccurate output (e.g., x appended to a URL like fwlinkx).

To overcome this, a more robust approach involves reverse engineering analysis using function signature generation. For Rust malware, analysts typically identify the Rust library crate version from internal strings and then generate signatures. Since this project is open source, defenders can compile it as a static library for signature generation. The process involves:

1. Renaming the main source file to lib.rs and adding crate-type = ["staticlib"] to cargo.toml.
2. Compiling the project using the Rust toolchain, generating a .lib file.
3. Passing the .lib file to FLIRT tools like PCF and Sigmake (from Hex-Rays, developers of IDA Pro) to create function signatures. Ghidra and Binary Ninja offer similar capabilities.

Takayama notes that functions related to C2 communication often start with util_strike in the debug symbols. The speaker has published FLIRT signatures for Rust version 1.92.0, emphasizing that signatures might need regeneration for different Rust versions due to code variations.

Rust string slices, as shown in the presentation, are 16-byte structures (for 64-bit executables) containing a pointer to the string data and its length. This distinct structure can be parsed by specialized tools or Ghidra plugins, offering a more accurate way to extract strings than generic strings utilities.

Rust Beacon

Developed by FDX XDF and published on GitHub in 2024, Rust Beacon is a more feature-rich implementation compared to Cobalt Strike Beacon Rust. It supports a wider array of post-exploitation capabilities, including file manager, process manager, process injector, and Beacon Object File (BOF) loader, making it more akin to the original Cobalt Strike beacon. This project has significantly fewer debug statements, increasing the difficulty of analysis.

Similar to the previous project, Rust Beacon stores configuration parameters in plain text. HTTPS is the default C2 protocol, though it lacks the custom C2 profile feature of the original Cobalt Strike. While string slice hunting can reveal some IOCs, Rust Beacon dynamically formats its C2 URL during runtime using Rust's string formatting functions. This means analysts must track the local variables passed to these formatting functions to accurately identify the C2 URL.

Takayama has also published FLIRT signatures for Rust Beacon, generated using Rust version 1.87.0. In-the-wild analysis revealed over 30 samples, with a notable concentration pointing to the C2 IP address 95.40.21.84, suggesting potential use by a specific threat group.

Geacon (GeaconPro)

Geacon is a general name for Cobalt Strike beacon implementations in Golang. The presentation focuses on GeaconPro, described as the latest and most feature-rich variant. Initially public, its developer later made it private due to abuse potential, but copied repositories remain publicly accessible. Geacon is the oldest of the projects discussed, inspiring many similar custom implementations since 2020. Its author explicitly stated the project's purpose for learning protocol analysis and reverse engineering, a disclaimer often absent in other variants.

The analysis methodology for GeaconPro mirrors that of the Rust variants: function signature generation. Golang version (e.g., 1.26.1) can often be determined from plain text strings within the compiled binary. Takayama demonstrated applying FLIRT signatures to a stripped GeaconPro binary, showing how numerous unnamed functions become labeled as library functions, significantly simplifying the reverse engineering process.

Critical configuration parameters in GeaconPro, including C2 address, user agent string, and jitter, are initialized within the function named main_config_init. By examining the decompiled code of this function, analysts can observe calls to runtime_concat_strings_three or similar functions where the C2 address and other IOCs are passed.

Over 100 in-the-wild GeaconPro samples have been identified on VirusTotal, some showing modifications from the original project. Multiple security vendors, including Trellix and SentinelOne, have published reports on GeaconPro's abuse, underscoring its widespread adoption by threat actors.

For all three projects, Takayama has provided readily available YARA detection rules and FLIRT function signature files on a GitHub repository, enabling immediate defensive action against these emerging threats. The ability to determine the Rust tool chain version from commit hash strings and the Golang version from plain text strings in the executable further aids in targeted signature generation and analysis.

Demo / Proof of Concept

▶ Watch: Geacon/GeaconPro: Golang beacon variants and analysis (21:45)

While the talk did not feature a live, interactive demonstration in the traditional sense, Naoki Takayama effectively presented a proof of concept for his analysis methodology through detailed screenshots and explanations. This demonstration focused on the application of FLIRT function signatures to a stripped GeaconPro binary, illustrating the profound impact this technique has on reverse engineering efficiency.

The speaker first outlined the process: compiling the GeaconPro project with stripping options (-s -w in Golang) to simulate a real-world, obfuscated binary that lacks debug symbols. Then, he described applying the pre-generated FLIRT function signature file (based on Golang version 1.26.1) against this stripped binary within a disassembler like IDA Pro.

The visual evidence presented in the slides clearly showed the transformation:

• Before applying signatures, a significant portion of the binary's functions would appear with generic, autogenerated names (e.g., sub_XXXXX), making it incredibly difficult to discern their purpose or origin.
• After applying the FLIRT signatures, these previously unnamed functions were accurately labeled with their original names (e.g., library functions, Golang runtime functions, and specific GeaconPro routines). This dramatic improvement in code readability instantly clarifies the binary's structure and behavior.

Following the successful labeling of functions, Takayama then demonstrated how to locate the critical configuration parameters. He specifically pointed to the function named main_config_init within the GeaconPro binary. By navigating to the decompiled or disassembled code of this function, analysts can observe direct calls to runtime string concatenation functions (e.g., runtime_concat_strings_three) where the C2 address, user agent string, jitter, and other vital IOCs are passed as arguments or initialized. This process effectively demonstrates how, even with a stripped binary, the combination of function signatures and targeted analysis can quickly reveal key adversary infrastructure and operational details.

This systematic approach serves as a compelling proof of concept for the efficacy of signature-based analysis against these new beacon implementations, providing a clear pathway for defenders to extract actionable intelligence from otherwise challenging binaries.

Defensive Implications

▶ Watch: Key takeaways: emerging threat and shared detection resources (27:00)

The emergence of Cobalt Strike beacon re-implementations in Rust and Golang presents a significant paradigm shift for cybersecurity defenders. The talk underscores that traditional, signature-based detections and config extraction tools, designed for the original C++ beacon, are largely ineffective against these new variants. This necessitates a fundamental re-evaluation and upgrade of defensive strategies.

Firstly, defenders must prioritize the development and application of robust reverse engineering skills within their security teams. The ability to analyze binaries compiled in modern languages like Rust and Golang, which have unique runtime characteristics and data structures, is no longer a niche skill but a critical requirement.

A primary takeaway for defenders is the immediate utility of function signature generation. As demonstrated, tools like FLIRT (Fast Library Identification and Recognition Technology), PCF (Pattern Call Flow), and Sigmake can be leveraged to create signatures for Rust and Golang libraries and custom beacon code. By compiling the open-source projects discussed (Cobalt Strike Beacon Rust, Rust Beacon, GeaconPro) as static libraries or with debug symbols, organizations can generate their own high-fidelity signatures. These signatures, when applied in disassemblers like IDA Pro, Ghidra, or Binary Ninja, can transform a convoluted, stripped binary into a readable, labeled codebase, drastically reducing analysis time and complexity. It's crucial to note that Rust and Golang versions can impact signature accuracy, so maintaining a collection of signatures for different compiler versions may be necessary, or generating them on demand.

Secondly, while current open-source variants often store configuration parameters in plain text, defenders should anticipate and prepare for increased obfuscation layers from threat actors. The current ease of extracting C2 addresses via strings commands or by locating main_config_init is temporary. Future variants will undoubtedly employ encryption, encoding, and junk code insertion to thwart direct string extraction. In such scenarios, function signatures remain a vital starting point, allowing analysts to identify known code patterns and then focus on the custom, obfuscated routines. Binary diffing can also be a powerful technique to identify modifications between known good versions and suspicious samples.

Thirdly, the research provides actionable YARA detection rules for all three analyzed projects. Defenders should immediately integrate these rules into their threat hunting platforms, endpoint detection and response (EDR) solutions, and security information and event management (SIEM) systems. While YARA rules can be bypassed, they offer a crucial initial layer of detection for known variants and can serve as a trigger for deeper analysis.

Furthermore, monitoring for specific C2 infrastructure identified in the talk, such as the IP address 95.40.21.84 linked to Rust Beacon samples, can provide immediate intelligence for network-level blocking and threat intelligence feeds. Organizations should also be vigilant for common Golang and Rust artifacts in their network and endpoint telemetry, as these languages are not as prevalent in legitimate enterprise software as C++ or C#.

Finally, the talk implicitly advocates for a shift towards behavioral detection and anomaly analysis. As adversaries continuously modify their tools, focusing solely on static signatures becomes a losing battle. Understanding the underlying post-exploitation behaviors of these beacons (e.g., process injection, network communication patterns, file system interactions) and building detections around these TTPs will provide a more resilient defense. Collaboration within the security community, sharing of IOCs, and continuous research into new adversary tools remain paramount.

Key Takeaways

• Emerging Threat Landscape: Cobalt Strike beacon implementations in modern languages like Rust and Golang (e.g., Cobalt Strike Beacon Rust, Rust Beacon, Geacon/GeaconPro) are an active and growing threat, effectively bypassing traditional detection methods.
• Initial Configuration Vulnerability: Current open-source versions of these re-implemented beacons often store critical configuration parameters (C2 addresses, user agents) in plain text within the compiled binaries, making initial IOC extraction relatively straightforward, though this is expected to change.
• Power of Function Signature Generation: FLIRT function signatures (using tools like PCF, Sigmake) are a highly effective and robust method for analyzing these complex Rust and Golang binaries. By labeling library functions and custom code, they drastically simplify reverse engineering, even for stripped binaries.
• In-the-Wild Abuse: Samples of these Rust and Golang beacons have been observed in real intrusion campaigns on platforms like VirusTotal, with alarmingly low detection rates, indicating their successful adoption by threat actors.
• Actionable Defensive Resources: Naoki Takayama has publicly shared FLIRT function signature files and YARA detection rules for the discussed projects on GitHub, providing immediate and practical tools for defenders to detect and analyze these threats.
• Anticipate Evolving Obfuscation: While current variants might be less obfuscated, defenders must anticipate that threat actors will quickly add layers of encryption, encoding, and junk code, necessitating advanced reverse engineering techniques and potentially binary diffing for future analysis.

About the Speaker(s)

Naoki Takayama is a dedicated Security Researcher working at Internet Initiative Japan Inc. (IIJ), a prominent commercial ISP company based in Japan. His professional expertise lies in the critical domains of digital forensics, malware analysis, and threat research. Naoki's primary responsibilities involve incident response and conducting in-depth threat research specifically focused on Advanced Persistent Threat (APT) campaigns that target East Asian regions, including Japan, Taiwan, and South Korea. His work is instrumental in understanding and countering the sophisticated tactics employed by these advanced adversaries.