kitos/Angerona
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

RPFWD Implemented

Browse Source
This commit is contained in:
marcos.luna
2025-11-03 17:12:44 +01:00
parent 8f8a54de5c
commit c7b6bbc935
11 changed files with 1620 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+113 -2
View File
@@ -20,6 +20,7 @@
- [Installation](#installation)
- [Supported Commands](#supported-commands)
- [SOCKS Proxy Support](#socks-proxy-support)
- [Reverse Port Forwarding (RPFWD) Support](#-reverse-port-forwarding-rpfwd-support)
- [Communication Protocol](#communication-protocol)
- [Configuration](#configuration)
- [Process Browser Integration](#process-browser-integration)
@@ -222,6 +223,7 @@ For more information, see the [Mythic documentation on customizing public agents
| Command | Description | Example |
|---------|-------------|---------|
| `socks` | Start/stop SOCKS proxy | `socks {"action":"start","port":7002}` |
| `rpfwd` | Start/stop reverse port forwarding | `rpfwd {"action":"start","port":8080,"remote_host":"127.0.0.1","remote_port":80}` |
---
@@ -337,6 +339,107 @@ Agent and translator communicate SOCKS data using a custom binary block:
---
## 🔄 Reverse Port Forwarding (RPFWD) Support
Cazalla includes reverse port forwarding (RPFWD) support, allowing you to tunnel incoming connections from the agent to a remote destination through Mythic.
### How It Works
1. **Agent opens a listener** on a local port (e.g., `8080` on the agent host)
2. **External client connects** to the agent's listener port
3. **Agent sends connection data** to Mythic via RPFWD protocol
4. **Mythic connects** to the configured remote destination (`remote_host:remote_port`)
5. **Bidirectional relay** between client ↔ Agent ↔ Mythic ↔ Remote destination
This is the **reverse** of a normal forward port: instead of connecting from Mythic to a remote service through the agent, connections originate from external clients to the agent and are tunneled to a remote destination.
### Commands
```bash
# Start reverse port forward on agent port 8080, forwarding to 127.0.0.1:80
rpfwd {"action":"start","port":8080,"remote_host":"127.0.0.1","remote_port":80}
# Stop reverse port forward
rpfwd {"action":"stop","port":8080}
```
### Use Cases
- **Access internal services**: Expose internal services (e.g., database, web server) by having the agent listen on a port
- **Bypass firewall restrictions**: When you can't connect from Mythic but can connect to the agent
- **Service tunneling**: Tunnel arbitrary TCP services through the agent
### Testing RPFWD
**Important**: The agent listens on **its own host**, not on the Mythic server. To test:
```bash
# From another machine or from the agent host itself:
nc -nzv <agent_ip> 8080
# Or from the agent host:
nc -nzv 127.0.0.1 8080
```
**Port Requirements**:
- **Non-privileged ports (>=1024)**: Recommended for normal users (e.g., `8080`, `4444`, `5555`)
- **Privileged ports (<1024)**: Require administrator privileges on Windows (e.g., `80`, `443`, `445`)
- If bind fails with `WSAError=10013`, the port requires admin privileges or is already in use
### Example Scenarios
#### Scenario 1: Expose Internal Web Server
```bash
# Agent is on internal network with a web server at 192.168.1.100:80
# Start RPFWD to tunnel external connections to the internal server
rpfwd {"action":"start","port":8080,"remote_host":"192.168.1.100","remote_port":80}
# Now, connecting to agent:8080 will forward to 192.168.1.100:80
curl http://<agent_ip>:8080
```
#### Scenario 2: Tunnel Database Access
```bash
# Tunnel database connections through the agent
rpfwd {"action":"start","port":3306,"remote_host":"10.0.0.50","remote_port":3306}
# Connect to MySQL through the agent (from another machine)
mysql -h <agent_ip> -P 3306 -u user -p
```
### Technical Details
#### Binary Protocol (0xF2 RPFWD Block)
Agent and translator communicate RPFWD data using a custom binary block:
```
[0xF2] [ext_len:4] [server_id:4] [exit:1] [b64_len:4] [base64_data:N] [port:4]
```
- `0xF2`: RPFWD block marker
- `ext_len`: Total extension length (remaining bytes)
- `server_id`: Unique connection ID from Mythic
- `exit`: `1` if connection should close, `0` otherwise
- `b64_len`: Length of base64-encoded payload
- `base64_data`: Base64-encoded raw bytes (connection data)
- `port`: Local port on agent (optional, for connection tracking)
#### Agent Implementation
- **File**: `rpfwd_manager.c` / `rpfwd_manager.h`
- **Commands**: `0x62` (START_RPFWD), `0x63` (STOP_RPFWD)
- **Thread Model**: One listener thread + one reader thread per active connection
- **Socket Management**: Automatic cleanup of closed connections
#### Artifacts
- **Network Connection**: Automatically reported when RPFWD listener starts on a port
---
## 📡 Communication Protocol
Cazalla uses a custom binary protocol for efficient communication with Mythic.
@@ -369,6 +472,7 @@ Cazalla uses a custom binary protocol for efficient communication with Mythic.
| `0x80` | Agent → Mythic | GET_TASKING (request new tasks) |
| `0x81` | Agent → Mythic | POST_RESPONSE (send task output) |
| `0xF5` | Bidirectional | SOCKS data block |
| `0xF2` | Bidirectional | RPFWD data block |
### Task Structure
@@ -383,6 +487,8 @@ Example command IDs:
- `0x10`: List directory
- `0x60`: Start SOCKS
- `0x61`: Stop SOCKS
- `0x62`: Start RPFWD
- `0x63`: Stop RPFWD
### Encoding
@@ -530,6 +636,8 @@ Cazalla automatically reports artifacts created during command execution, allowi
- **API Call**: Reported for:
- `screenshot` - GDI Screen Capture (GetDC, CreateCompatibleDC, CreateCompatibleBitmap, BitBlt, GetDIBits)
- `keylog_start` - Keyboard Hook (GetAsyncKeyState, GetForegroundWindow, GetWindowTextA, GetUserNameA)
- **Network Connection**: Reported for:
- `rpfwd start` - Reverse port forward listener started on port
### How It Works
@@ -597,7 +705,7 @@ Currently supported:
- `cat` - read-only file operation (doesn't create artifacts, but may report credentials)
Future support can be added for:
- **Network Connection**: When network operations occur (e.g., for `socks` proxy connections)
- **Network Connection**: When network operations occur (e.g., for `socks` proxy connections) - **Note**: Currently implemented for `rpfwd`
- **Registry Modification**: When registry keys are modified (e.g., `reg_set`, `reg_delete`)
- **Process Inject**: When processes are injected into (e.g., `inject` command)
@@ -638,6 +746,7 @@ Example implementations:
- `download`: File Read artifact with downloaded file path
- `screenshot`: API Call artifact for screen capture APIs
- `keylog_start`: API Call artifact for keyboard hook APIs
- `rpfwd start`: Network Connection artifact for reverse port forward listener
### Best Practices for New Commands
@@ -649,7 +758,7 @@ Example implementations:
- Any command that creates, modifies, or deletes files (`cp`, `mkdir`, `rm`, `upload`, `download`)
- Any command that executes processes (`shell`, `execute`, `inject`)
- Any command that modifies registry (`reg_set`, `reg_delete`)
- Any command that creates network connections (`socks`, custom network commands)
- Any command that creates network connections (`socks`, `rpfwd`, custom network commands)
- Any command that modifies system configuration
❌ **Commands that DON'T need artifacts:**
@@ -1401,6 +1510,7 @@ Cazalla/
│ ├── paquete.c/h # Packet creation
│ ├── transporte.c/h # HTTP transport (WinHTTP)
│ ├── socks_manager.c/h # SOCKS proxy logic
│ ├── rpfwd_manager.c/h # Reverse port forwarding logic
│ ├── procesos.c/h # Process listing (with Process Browser support)
│ ├── crypto.c/h # AES-256-CBC encryption with HMAC-SHA256
│ ├── checkin.c/h # Initial check-in
@@ -1410,6 +1520,7 @@ Cazalla/
│ ├── shell.py, sleep.py # Execution control
│ ├── ps.py # Process listing (Process Browser enabled)
│ ├── socks.py # SOCKS proxy command
│ ├── rpfwd.py # Reverse port forwarding command
│ └── builder.py # Payload builder (with encryption support)
├── translator/ # Mythic ↔ Agent translation
│ ├── translator.py # Main translator (with encryption support)