Smart Serverless C2 Redirector

Figure 1: Unauthorized traffic gets redirected to Google (302), while whitelisted paths receive a masqueraded response.

The Invisible Gatekeeper: Serverless Edge C2

In Part I of this project, I focused on hardening the C2 binary and host. However, a hardened server is useless if its IP address is flagged by Blue Teams within minutes. For Part II, I engineered a Smart Serverless Redirector using Cloudflare Workers.

Instead of a traditional dumb TCP-pipe (like socat or iptables), this redirector acts as an intelligent programmable gatekeeper at the network edge. It inspects HTTP traffic before it ever reaches the backend infrastructure, effectively making the C2 server invisible to scanners.

Status: Operational / Stealthy
Tech Stack: Cloudflare Workers (JavaScript), HTTP/2, TLS 1.3

Capabilities Implemented

The logic is deployed on the network edge, providing global coverage and zero-trust filtering for the C2 backend.

• Smart Whitelisting: Only specific, pre-defined paths (e.g., /js/jquery.min.js) are forwarded. Everything else is dropped.
• Active Deception (Decoy): Unauthorized IPs or scanners are immediately redirected (HTTP 302) to legitimate sites like Google.
• Heuristic Evasion: The worker rewrites error codes to mimic broken JavaScript libraries (503) instead of revealing standard C2 access-denied errors (403).

Technical Deep Dive

1. The Logic: "Whitelisting" vs "Blacklisting"

Most simple redirectors try to blacklist known scanners. This is a losing battle. My implementation uses a strict Allow-List approach. The Worker script validates the request.url against a hardcoded array of allowed paths.

// Simplified Logic from the Worker
const ALLOWED_PATHS = ["/js/jquery.min.js", "/api/v1/update"];

if (!ALLOWED_PATHS.includes(url.pathname)) {
  // If you are not on the list, you go to Google.
  return Response.redirect("https://www.google.com", 302);
}

2. OpSec: Header Sanitization & Masquerading

Even if a request is allowed, the backend C2 server might leak identifying headers (e.g., X-Sliver-Version). The Cloudflare Worker acts as a sanitization proxy:

• Strip Headers: Removes all C2-specific headers before sending the response to the client.
• Inject Camouflage: Adds standard CDN headers like CF-Cache-Status: HIT and Server: cloudflare.
• Symmetry: To the network analyst, the traffic looks indistinguishable from a user downloading a jQuery library from a CDN.

3. The "503" Deception

A common mistake in C2 setups is returning a 403 Forbidden or 404 Not Found when a session is invalid. This creates a pattern. I programmed the Worker to intercept backend rejections and rewrite them as believable application errors.

If a request hits a valid path but lacks a valid session ID, the Worker returns a custom 503 Service Unavailable with a body containing jQuery comments. This tricks automated analysis tools into thinking the target is just a broken script file, not a secure C2 interface.

MITRE ATT&CK® Mapping

Tactic	Technique ID	Implementation
Command and Control	T1090.002	External Proxy: Using Cloudflare Workers to hide origin.
Defense Evasion	T1071.001	Web Protocols: Masquerading traffic as jQuery/CDN downloads.
Resource Development	T1583.006	Web Services: Leveraging Serverless infrastructure for redirection.

Technical Verification

To verify the logic, I performed manual curl requests against the infrastructure. The screenshot below (Figure 1) demonstrates the dual-nature of the redirector:

• Test A (Top): Accessing /admin_login triggers the default rule -> Redirect to Google.
• Test B (Bottom): Accessing /js/jquery.min.js (without a valid implant session) triggers the deception rule -> 503 Service Unavailable (Cloudflare).

Conclusion

By moving the redirection logic to the network edge, I have effectively decoupled the C2 infrastructure from its public footprint. The backend IP remains hidden, and the traffic profile blends seamlessly with normal web browsing activity. This architecture forces defenders to analyze headers and payload content rather than relying on simple IP or domain reputation blocklists.

Working on the Part III

In the rapidly shifting landscape of cybersecurity, continuous adaptation is key. I am currently engineering Version 3 of this whole infrastructure, transitioning to Terraform for advanced orchestration and implementing Ligolo-ng(Layer 3) to replace the previous serverless redirector layer(Layer 7). Stay tuned!