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.

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

Copyright (c) 2022, FULLSHADE
All rights reserved.