Intro

The release of the Vault7 files provides an unprecedented look into the tactics, techniques, and procedures (TTPs) of a nation-state actor. Having spent a numerous hours with Empire, a PowerShell based RAT – I was curious how Athena stacked up. I reviewed the Wikileaks dump to understand more about Athena and what the CIA came up with shortly after the release of Empire. Throughout my reading, I kept Empire in mind, comparing and contrasting how a rag-tag team of developers stacked up against a nation-state.

What is Athena

On May 19, 2017 Wikileaks released the Vault7 documentation on the “Athena” project, a CIA “implant” or beacon. The documentation describes it as such:

Athena is a beacon/loader tool. It hijacks DNSCACHE to obfuscate its persistence

In other words, Athena (and Hera) could more traditionally be called a “RAT”, or “Remote Access Tool”.

The Athena ecosystem includes all the features you’d expect out of a Command and Control (C2) infrastructure: operator tools to create and task agents or beacons (implants), a C2 server to host those taskings (Listening Post), a method for generating your beacon install (Builder.py), and of course the malware (implant) itself capable of executing code on the target computers.

Athena relies on an operator-compiled C++ binary with hard-coded initial configuration values. One of the advantages of using a pre-compiled C++ DLL is that it will run on Windows XP through Windows 10. Empire, a similar yet open source tool, requires PowerShell v2.0 at least, which is not installed by default on Windows XP. Cobalt Strike a commercial RAT, on the other hand, will run on Windows XP. Furthermore, leveraging a DLL allows the tool to be installed while the computer is offline, or even at some point in the supply chain on its way to the target.

Compared to some tools like Duqu (for a more in depth on Duqu, check out killswitch_GUI‘s recent slide deck), Athena comes across as fairly basic. You don’t necessarily need a Cadillac RAT if your target is in a developing nation or is not a nation state actor. Furthermore, having a variety of tool options allows greater flexibility to adapt with the needs of the operation and can prevent your Cadillac from getting burned on a low priority target.

Topics Covered:

Infrastructure
Capabilities
Operator Tools
Listening Post
Beacon
Delivery Methods
Main Differences Between Athena and Empire

Infrastructure

The Athena Infrastructure allows operators the ability to create payloads for their selected targets and remotely control the targets using a Command and Control (C2) server. Athena was designed to be installed through a variety of vectors such as: an “asset” (spy), windows post-exploitation, supply chain, or remote operations. All communication is encrypted with public/private keys, and numerous configuration parameters can be set to modify the beacons behavior.

The Empire infrastructure on the other hand is a bit more elegant with a single application interface for the creation of listeners, configuring implants (launchers), and tasking agents. Empire also includes modular C2, allowing for different command and control channels to be used as needed.

I can see some of the design decisions for Athena, where the operation might be tracking a single target for months or years at a time, and having a simple and straightforward tool kit takes precedent over ease of use. The default beacon interval for Athena is ~24 hours, plenty of time to build your tasks with great though and post them to your listener. Empire’s HTTP listener default beacon interval is 5 seconds, which supports an operational tempo for a normal pentest.

Capabilities

Athena runs on Windows XP through Windows 10, on x86/x64 operating systems, provides beaconing, memory loading/unloading, injection of files, exfiltration of files, beacon settings modification, public/private key cryptography for taskings and data exfiltration, registry based persistence, and offline install.

Empire runs on Windows versions which support PowerShell, Mac OS (Python), and Linux (Python). It shares the all the other features either natively, or through commonly known tricks of the trade.

Operator Tools: Builder, Tasker, Parser

Builder.py

Builder.py is the tool which creates the binaries for implant installation. The binaries can be customized by the operator during build (sample of configuration options listed in the “Beacons/Agents” section below), these values are hard coded into the binary but can be changed through a tasking. Builder.py not only creates the installable binaries, but also creates a “receipt” XML file which contains a client and server public/private key pair for each implant (aka beacon or agent) in addition to the selected configuration options.

Tasker.py

Creates the taskings or batch files the agent/beacon will run. Tasker can import existing scripts, set tasking priorities, and is capable of error handling. Taskings are encrypted and placed in a directory on the Listening Post web server with a specific directory tree for each implant.

Tasker.py can be run on the command line with CLI flags, or as a shell. The shell provides the ability to interactively build and edit a tasking list with all the necessary options.

Parser.py

All exfiltrated data is encrypted using XTEA or AES with the servers public key. Parser uses the private key stored in the receipt file for each implant to decrypt the tasking responses and exfiltrated data. It saves plaintext output to a text file. This helps to ensure the confidentiality of any implant that is discovered, and prevents incident responders from recovering task results.

vs. Empire

Empire includes analogous features as those listed above in the console applications. All implants (agents), listeners, taskings, and results are handled through the console rather than individual tools. Empire keeps a record of taskings and results in a SQLite database, and Empire can be controlled through a REST API. The API supports use with a GUI front-end or powerful automation through scripting.

Listening Post

Listening Post (LP) is the C2 server which hosts implant taskings and receives the results from those taskings. LP runs on Linux using Apache and Python 3.4.

The taskings are encrypted on disk with the client public key, and decrypted by the implant with the client private key. The LP can be configured to use a valid SSL cert, or create a self-signed certificate for itself.

Empire has a number of options to choose from for it’s listeners such as a similar HTTP GET/POST channel, Dropbox, and a Meterpreter hand-off. Each of the native Empire listeners use RSA to exchange a perfect-forward-secrecy AES key, preventing incident responders from recovering the key. Should Athena be reversed at some point (if discovered in the wild), it would be interesting to see if malware researchers can recover a private key from the implant. The private key would be used to decrypt implant taskings and settings, which could give insight into what the operators are monitoring.

Implants (aka Beacons or Agents)

Athena has the ability to run multiple taskings which are processed in a parent/child relationship. Taskings are batches of commands to be run on the target. URL requests, and request headers can be user configured and obfuscated.

Before data is exfiltrated from the target, it is first hashed, then compressed, encrypted, and signed before being sent to the Listening Post with its parent and child ID attached. The data handling ensures integrity, confidentiality, and non-repudiation.

Athena has the ability to detect and use configured proxies, as well as reporting back to the Listening Post what those proxy configurations are.

Configuration options for beacons include CPU thresholds, tasking timeouts, auto install, language headers, and the ability to point at multiple domains among many others.

According to the design specs, evading Kaspersky Antivirus (KIS) was a requirement of the production implant. KIS seems to have been a particular thorn in the side for three-letter agencies, both of them playing the cat and mouse game of discover/evade.

Empire shares some of the same agent configuration options, though nowhere near as many. This speaks to Athena’s likely purpose: stay low, go slow, and under no circumstances get caught. With those requirements, I’d probably want more configurability out of my implants as well.

Coincidentally, Empire was evading PSPs regularly at the time of its launch due to the agent’s (implant) complete reliance on PowerShell. PSP vendors had yet to catch on to malicious PowerShell (and still have problems, especially when obfuscated). I still bypass antivirus regularly with the stock Empire, and if that’s not working for you, there are plenty of obfuscation techniques.

Athena (implant)

Athena is the “primary” implant, and is compatible with most versions of Windows.

• Operating Systems: Windows XP through Windows 10
• Persistence: RemoteAccess Service
• Compression: ZLIB
• Encryption: XTEA

Hera (implant)

Hera is the “secondary” implant and retains the same management capabilities of Athena but only works on Windows 8 and Windows 10

• Operating Systems: Windows 8 through Windows 10
• Persistence: DnsCache
• Compression: BZIP2
• Encryption: AES 256
• Account: NetworkService until reboot, then netsvcs

Empire

Empire’s agents are all PowerShell, and are designed to stay in-memory, off disk, and out of the registry with as few artifacts as possible. The upside is fewer discoverable indicators of compromise (IOC), the downside is an implant (agent) that creates a new session on reboot. Handling these new sessions would be difficult to manage over time as targets reboot or shut down their computers over a large period of time.

Furthermore, it appears that Athena is largely created to run a single implant per target. Empire and Cobalt Strike were designed with full network compromise in mind, and supports multiple implants (agents/beacons) per box. The difference is compromising a target (Athena) versus compromising a network (Empire).

Delivery Methods

The on-disk installer runs the generated dll and modifies the target registry. It drops the host file (IprCache.dll) and a data file (ras.cache). It then launches the Athena Engine in a netsvcs svchost.exe process.

In-memory only installation uses something similar to rundll32 to load and execute a dll into memory.

An example was provided in the User Guide:

c:\> rundll32 installer_x64.dll,#2

The Linux installer contains a script which mounts the Windows partition and through a “wizard” drops the implant to disk. This is a pretty sneaky method, and falls in line with the classic “Evil Maid” attack.

Differences between Athena and Empire

These two tools were written for very different operational contexts and it’s still worthwhile to compare similar tools and perhaps understand where one or the other could be improved. First, Athena was written to include legacy operating systems and be capable of long-haul (months/years?) communications. Empire was written for Red Teams and Personal Security Product (PSP) evasion. Furthermore, Empire was written to leverage the power of offensive PowerShell inside a RAT as a proof of concept. It’s a testament to Empire’s flexibility and growing popularity that we can even compare the two.

Athena uses a precompiled C++ DLL that only makes use of ubiquitous Windows API calls because it needs maximum cross-compatibility. Empire requires the PowerShell subsystem, a missing component on most Windows XP machines. Empire maintains compatibility with PowerShell v2 for greatest compatibility.

Athena uses a collection of tools for its listening server, tasking creation/management, and stager/launcher creation. Empire has all of the infrastructure built into a single tool and provides a much quicker and easier way to stand-up C2 servers and generate the necessary code for implants (agents). What Empire loses in flexibility, it makes up in ease of use.

Both use cryptography for back and forth communication. Neither recycle keys for the beacons. Each implant gets its own public/private key-pair. They do use different algorithms, but this is more of a design and requirements decision.

Both can detect and use proxies configured on the host. Athena notifies the operator if a proxy is being used, and what those settings are. Empire simply uses the proxy.

Both can modify their HTTP headers, and both can modify the URLs used for the listener. They can also randomize request URLs, though Athena has more robust options for this. Athena has the ability to store multiple C2 servers, while Empire agents are capable of using only one. However, Empire has far more diversity of C2 options, such as using Dropbox and in the near future DNS and possibly Gmail.

Finally, the Athena implants are in general more robust in that they have sophisticated error handling, CPU threshold detection and throttling, and tasking timeouts among its configurable parameters.

These tools were built for different purposes with wildly different budgets, and different needs. The differences between the two can largely be explained by operational needs, and budget. What started as a proof of concept, Empire has turned into an amazing tool that in some ways rivals that of a nation-state actor. Still, there are many great features of Athena/Hera that could be implemented in Empire. For instance, a stageless Empire implant written in C# (perhaps “wevade“, but I need to test). This implant would send all PowerShell commands to System.Automation.Management directly and could allow for similar PSP evasion, installation, and persistence.

** Special thanks to @harmj0y, @wald0, and @bluescreenofjeff for their input and contributions