WarFox: software-based HTTPS beaconing Windows implant

WarFox

WARFOX is a software-based HTTPS beaconing Windows implant that uses a multi-layered proxy network for C2 communications. This kit was designed to emulate covert APT offensive operations. This kit includes WARFOX (Windows implant), HIGHTOWER (Listening Post), and other tools to build configs and set up a proxy network.

Included Tools and Scripts

WARFOX: A software implant wrote in C++ designed to target Windows systems to aid in the post-exploitation phase of an offensive operation. This implant provides the operator with 12 features in the form of tasks.
CUBDROP: A C# dropper and DLL-sideloading utility, WARFOX, and a legitimate executable are stored as an embedded, compressed, and encrypted resource
HIGHTOWER: A Python HTTP server that manages and provides tasks to hosts implanted with WARFOX, network communications are encrypted using a self-signed TLS certificate.
LIGHTBEAM: A TCP traffic redirector that can be used to mask traffic between WARFOX and HIGHTOWER. This redirector can be daisy-chained to form a multi-level proxy network for WARFOX
FILEGUARD: A file compressor and crypter, FILEGUARD uses GZIP and AES-128 (CBC) to obfuscate and pack files
edit_timestamp.py: Edit the PE timestamp to include a random date going back in time 90 days
build_config.py: Generate AES encrypted configuration data for your IP:PORT pair

Network Architecture and Design

LIGHTBEAM TCP traffic redirectors can be daisy-chained together to form a multi-layered proxy node network to mask traffic between a host running WARFOX and HIGHTOWER. LIGHTBEAM relies on socat for traffic redirection, the tool can be run on Linux hosts.

Traffic between WARFOX hosts and HIGHTOWER is encrypted using self-signed certificates
WARFOX hosts periodically beacon over HTTPS to HIGHTOWERs HTTP server
When an operator issues a new task for a WARFOX host, the task command is included in the HTTP response packet, this is processed by WARFOX’s tasking/processing engine

HIGHTOWER relies on two designated HTTPS endpoints to process beaconing check-ins and task command results

Endpoint #1 (/update) receives inbound beacon requests from WARFOX hosts, host sessions are determined by the id field of the beaconing packet.
Endpoint #2 (/finish) receives the results of issued task commands, this information is displayed to the operator that issued the task

Secure Communications

To avoid network detection, WARFOX beaconing and tasking responses were designed to evade common network detection techniques.

Beaconing intervals are randomized using jitter to avoid easy-to-spot patterns. This is implemented using a sleep function call with a random value between network requests
Network traffic is encrypted using TLS to avoid the ability to write Snort or Suricata rules for traffic patterns. Additionally, the self-generated certificates use null values to avoid being easily detected or blacklisted based on their information
An additional layer of AES encryption protects the beacon and task response requests to ensure the traffic remains encrypted even if the TLS traffic is MITM’ed

WARFOX

Beaconing Engine:
- The beaconing engine is responsible for preparing periodic beaconing check-in requests with HIGHTOWER. The implant periodically checks-in with HIGHTOWER via beacon requests that include information related to the infected system. Outbound beacon requests include the systems hostname, current users’ username, system architecture, and more. The information for beacon requests is packaged into a JSON object, encoded via BASE64, and sent to the /update HIGHTOWER endpoint.
Tasking Engine:
- When an operator issues a new task for the implant, the command is set as the default HTTP response, when the implant identifies that a new task was issued, it’s parsed via the Tasking Engine to determine what functionality to execute. When a task is received, the corresponding function (get_processes for example) is executed and the task result is packaged into a task_response JSON object which is exfiltrated to the /finish HIGHTOWER endpoint.
Networking Engine:
- Beacon check-ins and task responses use the Networking Engine to send HTTPS requests to HIGHTOWER via the Windows WinInet API library. Before sending a request, HTTPs is enabled for requests.
Protected Configuration:
- The embedded HIGHTOWER IP address and port are encrypted within the implant configuration. When required, the configuration data is decrypted via AES-128 in CBC mode. New configurations can be created using the build_config.py script located in the /scripts directory.

Supported Tasks

The WARFOX implant supports 12 operator-provided tasks. The following table provides an overview of the task categories. Tasks in the Interaction category require an additional argument to carry out the relevant operation, consult the usage section for examples.

Task Command	Description	Category
get_processes	List the running processes using NtQuerySystemInformation	Information Gathering
get_drivers	List the running drivers using NtQuerySystemInformation	Information Gathering
get_users	List information about the users on the system	Information Gathering
get_clipboard	Get a copy of clipboard contents	Information Gathering
find_files	Locate files by a specific extension in a directory	Interaction
del_file	Delete a file	Interaction
kill_pid	Kill a process by its PID	Interaction
rev_shell	Spawn an interactive shell	Interaction
exec_command	Execute a system command	Execution
bsod	BSOD the system	Other
reg_persist	Persist via the Registry using the RunOnce key	Other
uninstall	Uninstall and remove traces of artifacts on the remote system	Other

Evasion Mechanisms

Sensitive strings are obfuscated using a compile-time based XOR obfuscation libary
The embedded IP:PORT configuration is encrypted using AES
API function calls are obfuscated using API hashing via the SuperFastHash algorithm
(Recommended) The binary is compiled using LLVM-Obfuscator

Install & Use

Tags: HTTPS beaconing Windows implant WarFox