DNS-Reverse-Shell

A two-stage, DNS-triggered reverse-shell framework that uses encrypted (Fernet/AES) stage-2 channels and heartbeat-based multi-target management for stealthy, on-demand command execution in lab/red-team environments.

Overview

This project implements a two-stage, beacon-driven remote control framework designed for offensive security research and red-team lab use. The goal is to minimize exposure by using a low-profile trigger channel (DNS TXT in the initial design) to instruct a target to establish a secure, bidirectional stage-2 connection only when needed. All communications are encrypted and targets send periodic heartbeats so operators can safely monitor live sessions.

Key features

1. Two-Stage Architecture: Stage-1 (stealthy beacon/trigger) + Stage-2 (robust encrypted command channel).
2. DNS-trigger capability: Stage-1 can use DNS TXT responses as a low-bandwidth trigger mechanism (lab / controlled DNS server required).
3. Encrypted communications: Uses Fernet (AES + HMAC) for authenticated symmetric encryption of triggers, commands, and outputs.
4. On-demand RCE: Commands are executed on the target only when the operator requests them; otherwise the target remains in a low-profile beaconing state.
5. Heartbeat / Liveness: Targets periodically send encrypted “alive” pings; operator UI lists active targets and last-seen times.
6. Multi-target management: Menu-driven interface to list targets, select a target, and send commands with structured output.
7. Cross-platform: Prototype works on Linux and Windows; target can be packaged to an EXE for Windows testing with PyInstaller.
8. Lab-oriented & configurable: Beacon intervals, encryption keys, and stage-2 listener settings are configurable for testing.

Why this approach

1. The two-stage model balances stealth (small, infrequent beacons) with functionality (an encrypted interactive channel for commands and data).
2. Encryption prevents passive eavesdropping and ensures integrity of commands and responses.
3. Heartbeats give visibility without requiring a permanent, noisy connection.

Intended use & ethics

This framework is a research / lab tool meant for authorized penetration testing, red-team exercises, and defensive research. Do not deploy on production systems or networks where you do not have explicit permission. Unauthorized use is illegal and unethical. Use the tool only in controlled environments and follow responsible disclosure and organizational policies.

Requirements

1. Python 3.10+ (tested)
2. cryptography, dnspython, dnslib (optional), pyinstaller (for EXE packaging)
3. Network environment that allows outbound DNS and the configured stage-2 listener port (for lab testing)

Quick start (high level)

1. Configure the attacker listener IP and stage-2 port.
2. Generate an encrypted trigger payload (IP:PORT) and serve it via your lab DNS server (or provide it directly in lab tests).
3. Deploy the target agent (Python or compiled EXE) in a controlled environment.
4. Use the attacker interface to monitor heartbeats, select targets, and execute commands on-demand.

Security & detection notes (for defenders)

Encrypted and staged frameworks can evade signature-based AV detection but create artifacts that defenders can detect (e.g., repeated DNS TXT requests, DNS→TCP correlation, suspicious process behavior). Use DNS logging, egress controls, and endpoint telemetry to detect such patterns.