The red-teaming and attack simulation tool Cobalt Strike has a long and widely observed history of abuse by threat actors targeting Windows platforms, but it has only occasionally been seen used against macOS devices. That, however, appears to be changing with the development of a Go implementation of Cobalt Strike called ‘Geacon’.

We have observed a number of Geacon payloads appearing on VirusTotal in recent months. While some of these are likely red-team operations, others bear the characteristics of genuine malicious attacks. In this post, we highlight two recent Geacon samples and describe their delivery mechanisms and main characteristics. A list of IoCs is provided to aid threat hunters and security teams identify Geacon payloads.

What is Geacon?

Geacon is a project that first appeared four years ago on Github as a Go implementation of Cobalt Strike Beacon. Despite being widely forked, it was not something that SentinelOne had observed being deployed against macOS targets until recently.

Analysis of the payloads we have observed on VirusTotal suggests that what appears to have changed is the popularity of two Geacon forks developed by an anonymous Chinese developer using the handle “z3ratu1”. In a blog post in late October 2022, z3ratu1 states that “one day I just went shopping and saw this project geacon, so this toy project and its development guide appeared”. The first Mach-O Geacon payload was submitted to VirusTotal not long after, on November 10 last year.

By April this year, the public geacon_plus and the private for-sale geacon_pro projects developed by z3ratu1 had “earned close to 1k stars” and were added to the 404 Starlink project, a public repo of open source red-team and penetration tools maintained by the Zhizhi Chuangyu Laboratory. The same month also saw two different Geacon payloads submitted to VirusTotal that drew our attention, with one in particular bearing hallmarks of a genuine malicious campaign.

Xu Yiqing’s Resume_20230320.app

Xu Yiqing’s Resume_20230320.app was submitted to VirusTotal on 5th April. This AppleScript applet uses a compiled, run-only AppleScript to call out to a remote C2 and download a Geacon payload.

The application is ad-hoc codesigned and compiled for both Apple silicon and Intel architectures. Analysis of the run-only script shows that it contains logic to determine the current architecture and download a Geacon payload specifically built for the target device.

The unsigned Geacon payload is retrieved from an IP address in China. Before it begins its beaconing activity, the user is presented with a two-page decoy document embedded in the Geacon binary. A PDF is opened displaying a resume for an individual named “Xu Yiqing”.

Below we present details of the x86 Intel payload, named simply amd (bef71ef5a454ce8b4f0cf9edab45293040fc3377).

The embedded PDF is called from the main.makewordfile function.

The compiled Geacon binary has a multitude of functions for tasks such as network communications, encryption, decryption, downloading further payloads and exfiltrating data.

The C2 in both the first and second stage is a Chinese IP address at 47.92.123.17, which is associated with other malicious samples targeting Windows machines.

The source indicates that this sample was compiled from the free geacon_plus source code.

SecureLink.app and SecureLink_Client

A second Geacon payload also appeared on VirusTotal on April 17th. In this instance, the payload, fa9b04bdc97ffe55ae84e5c47e525c295fca1241, is embedded in a trojan masquerading as SecureLink, an enterprise-level application for secure remote support.

The trojan is a barebones, unsigned application built from an Automator workflow rather than a Script Editor applet and bearing the bundle identifier com.apple.automator.makabaka. The binary only targets Intel devices.

The Info.plist reveals that the application was built on a macOS Ventura 13.1 device and targets macOS versions from OS X 10.9 Mavericks onwards. It also requires that the user grant access to the device’s camera, microphone and administrator privileges, as well as to data such as contacts, photos and reminders that would otherwise be protected by TCC.

The application’s main executable is a Geacon payload built from the private geacon_pro project.

In this sample, the C2 is a Japanese IP address at 13.230.229.15, widely recognized as a Cobalt Strike server on VirusTotal.

We have no indication that this sample is operationally connected to the Xu Yiqing resume.app, but this is not the first time we have seen threat actors trojanizing SecureLink with an open-source attack framework: a Sliver implant was being distributed as a fake SecureLink app in September of 2022, a reminder to all that enterprise Macs are now being widely targeted by a variety of threat actors.

How to Stay Safe Against Geacon Payloads

The SentinelOne platform identifies Geacon payloads as malicious and kills them on-write (in Protect mode) or on-execution (in Detect mode).

For security teams not protected by SentinelOne, a list of indicators is provided at the end of this post to aid detection and threat hunting.

Conclusion

Enterprise security teams can make good use of attack simulation tools like Cobalt Strike and its macOS Go adaptation, Geacon. It is quite likely that some of the activity we are observing around this tool is legitimate red team use, but it is also likely that genuine threat actors will make use of the public and possibly even the private forks of Geacon now available to them. The uptick in Geacon samples over the last few months suggests that security teams should be paying attention to this tool and ensuring that they have protections in place.

Indicators of Compromise

Geacon SHA1s
6831d9d76ca6d94c6f1d426c1f4de66230f46c4a
752ac32f305822b7e8e67b74563b3f3b09936f89
bef71ef5a454ce8b4f0cf9edab45293040fc3377
c5c1598882b661ab3c2c8dc5d254fa869dadfd2a
e7ff9e82e207a95d16916f99902008c7e13c049d
fa9b04bdc97ffe55ae84e5c47e525c295fca1241

Observed Geacon C2s
47.92.123.17
13.230.229.15

Fake SecureLink BundleIdentifier
com.apple.automator.makabaka

Suspicous File Paths
~/runoob.log