facebookarchive/weaselDNS covert channel implant for Red Teams.
WEASEL is a small in-memory implant using Python 3 with no dependencies. The beacon client sends a small amount of identifying information about its host to a DNS zone you control. WEASEL server can task clients to execute pre-baked or arbitrary commands.
WEASEL is a stage 1 payload, meant to be difficult to detect and useful for regaining access when your noisy full-featured stages are caught.
Status
See usage in client's README and server's README for specific instructions.
To start the server or client, execute the scripts directly or pass them to the Python interpreter.
Ensure the C2 domains each have an NS record with the IP address of the host running server.py.
WEASEL requires Python 3.6+.
The client is self-contained and only uses standard libraries, therefore it can be run on macOS, Linux, etc.
The server has a few dependencies from pip, included in server's requirements.txt. The server should be run on Linux, but there is nothing preventing it from running on macOS or other *nix.
No need to obfuscate and minimize the beacon in this case. Print statements are
preserved. As with Usage above, ensure NS records for the domain(s) in
servers in beacon.py point to the IP address of server.py.
On the server host:
sudo python3 server.py
On the victim host (can be the same as server):
python3 beacon.py
You do not need to understand any of this to use WEASEL.
Beacon communicates over DNS using AAAA queries and answers. It does not use TXT records due to those being known as being used by DNS malware and tunnels. Blue teams often have DNS tunneling detections that alert on large TXT queries.
The client side does not need root to operate, does not use raw sockets, and does not create malformed DNS packets. It uses regular system and language provided interfaces to make DNS requests. The information is encoded + encrypted in the records themselves.
This beacon is meant to be low and slow, with little bandwidth. It should tell us which hosts it is on and give us a way to launch further stages as needed, and nothing more. While this does have arbitrary command support, it is not meant to be used as a regular interactive shell or communications channel.
WEASEL is a stage 1 that you leave running, ensuring ongoing access as your full featured (and therefore noisier) stages get caught.
WEASEL was initially targeted for high uptime servers where we had a reliable foothold/exploitation vector. Evading forensics was a high priority. As a result, it has no native persistence features.
You can make it persistent by adding its execution to your favorite persistence technique, which is left as an exercise to the reader :)
A request (from the client) is a single AAAA query for a name formatted like:
<preamble><data>.<stream>.<session>.domain.tld
The preamble is 2 bytes. Preamble[0] is that packet's sequence number. Preamble[1] is the total number of packets in that stream.
Data is limited to 50 bytes (configurable) and contains the payload. The payload is base32 encoded with a custom alphabet.
First, all 'w' chars are swapped for '-'.
Next, the padding character is swapped from '=' to 'w' to conform to the DNS character set: [a-z0-9] and [-].
We don't swap '=' with '-' directly because the padding will always be at the end of the string, and ending a hostname on '---' is both suspicious and against DNS RFC. This way when a string does have padding it will end on 'www', which is both less suspicious and RFC compliant.
A response (from the server) is comprised of one or more AAAA answers.
Each AAAA answer is a 16 byte encrypted payload represented as an IPv6 address
using socket.inet_ntop. Answers in a DNS response do not maintain their order in
transit, so they are sequenced and reassembled like the client requests.
The transport payload is a string of data elements separated by a ^ character.
Requests and responses follow this format:
<type>|<data>
| Type | Meaning (sender) | AKA | Data |
|---|---|---|---|
| 0 | Acknowledged | ACK | Random hex |
| 1 | Checking in (client) | PING | Random hex |
| 2 | Terminate yourself (server), terminating myself (client) | FIN | |
| 3 | Initialization message (client) | SYN | `version |
| 4 | Reconnect (server) | RST | |
| 5 | Set callback interval (server) | seconds | |
| 6 | Get network interface data | eth0 1.2.3.4/24\neth1 fe80:::/64\n... | |
| 8 | Eval arbitrary Python3 code up to 666 bytes (server), returning first 400 bytes of output (client) | EVAL | python3 oneliner script |
| 9 | Execute arbitrary command up to 666 bytes (server), returning first 400 bytes of output (client) | EXEC | bash command |
Sessions are long lived: a client initiates a session when the beacon is first executed and that session should last for the entire time the beacon is active on that client. Note that since the beacon is in-memory and not persistent the session data is stored in that Python process' memory. Any new invocation of the beacon will initiate a new session.
Initiating a session involves the client crafting a message with a uniquely identifying non-data preamble (to signal to the server that this is a new session): the concatenation of a 32 bytes Diffie-Hellman public key and a 16 byte random AES IV.
The server receives this and responds with its own 32 byte public key. At this point the client and server have established a shared session key that will be used for the lifetime of this session to encrypt data payloads using AES-128 in CTR mode. The Diffie-Hellman Ephemeral exchange ensures each client-server connection uses a unique session key with forward secrecy.
The crypto is purposefully bad for a number of reasons:
Here are some known issues with the crypto scheme:
