Post

Custom Sliver C2-Framework

Custom Sliver C2-Framework

Sliver Terminal Screenshot

Customized Sliver C2-Framework running on a hardened VPS with Serverless Redirector

Automated & Hardened C2 Infrastructure

In modern Red Teaming, infrastructure must be disposable, reproducible, and stealthy. For this project, I engineered a fully automated Infrastructure as Code (IaC) pipeline using Ansible to deploy a highly customized Sliver C2 server.

The objective was to move away from default binaries and build a custom-compiled infrastructure optimized for cost-effective ARM64 cloud instances, protected by serverless edge redirectors to mask the backend origin and evade detection. This is a VERSION 2 of my project and the V3 will move towards Terraform and the Cloudflare worker will be replaced by tool called Ligolo-ng.

Status: Operational / Fully Hardened
Tech Stack: Ansible, Go (1.23+), Cloudflare Workers, Linux (Debian), Sliver, Systemd Sandboxing

Project Highlights

This pipeline orchestrates source code mutation before compilation and implements multi-layer network obfuscation.

  • Polymorphism: Automated source-code injection for unique binary hashes and randomized database artifacts.
  • Stealth: Serverless Edge Redirectors (Cloudflare Workers) for origin IP masking and granular traffic filtering.
  • Hardening: Static analysis resistance via -trimpath and strict Systemd process sandboxing.

Technical Deep Dive

1. Polymorphic Infrastructure (Anti-Forensics)

Standard C2 installations leave predictable artifacts like sliver.db. My Ansible playbook acts as a pre-compiler modification engine to break static signatures and forensic patterns:

  • Source Code Mutation: The playbook uses sed to inject random strings into the Go source code, renaming the core database (e.g., core_oohhukam.db) and internal structures.
  • Service Randomization: The Systemd service is deployed with randomized names (e.g., sys-yotipt.service), blending into standard background system processes.
  • Binary Stripping: All binaries are compiled with -ldflags="-s -w" and -trimpath, removing debug symbols and build-machine path metadata that could leak developer environment details.

2. Serverless Edge Redirectors (Cloudflare Workers)

To prevent direct exposure of the C2 server's IP address, I implemented a Serverless Redirector using Cloudflare Workers. This layer acts as an intelligent proxy and the primary line of defense.

  • Traffic Blending: The redirector is configured to allow only specific paths (e.g., /js/jquery.min.js), mimicking a legitimate JavaScript CDN.
  • Request Filtering: Any unauthorized access or scanning attempts are met with a 403 Forbidden or a 302 Redirect to a decoy site, preventing backend fingerprinting.
  • Origin Masking: The implant only communicates with the edge domain, making it virtually impossible for blue teams to identify the backend VPS IP without edge-level logs.

3. Operational Hardening via Systemd

The C2 server runs in a highly restricted Systemd Sandbox. Instead of root privileges, the process is managed by a low-privileged user (sliver-svc) with zero interactive login capability.

  • NoNewPrivileges=true: Enforces that the process and its children can never gain new privileges via suid bits.
  • PrivateTmp=true: Provides an isolated, non-persistent /tmp namespace.
  • ProtectHome=true: Ensures the service cannot access any user home directories, limiting the impact of a potential process compromise.

4. ARM64 Compilation & Traffic Masquerading

The server is optimized for ARM64 architecture, utilizing architecture-specific build tools and -tags "cgo_sqlite" for database stability. The C2-server is further hardened with HTTP Masquerading, where the backend server headers are spoofed to return Server: cloudflare, ensuring perfect header symmetry with the redirector layer.

MITRE ATT&CK® Mapping

TacticTechnique IDImplementation
Resource DevelopmentT1583.003Automated VPS provisioning & configuration via Ansible.
Defense EvasionT1027.002Binary stripping and -trimpath to remove build metadata.
Defense EvasionT1564.001Renaming of critical DB and service artifacts (Polymorphism).
Command and ControlT1071.001Application Layer Masquerading via jQuery CDN traffic.
Command and ControlT1090.002External Proxying through Serverless Edge Redirectors.

Technical Validation (Proof of Hardening)

To verify the efficacy of the hardening measures, I performed technical checks on the production binary. The following evidence confirms the absence of symbols, path metadata, and the successful deployment of the polymorphic database.

Terminal Verification of Binary Hardening

Figure 1: Terminal verification showing no symbols (nm), zero path leaks (strings), and custom DB artifacts.

# Manual verification commands:
$ nm sliver-server | grep "sliver" # Expected: no symbols
$ strings sliver-server | grep "/opt/" # Expected: empty
$ ls /opt/Ghost-Sliver/sliver/.sliver/*.db # Expected: core_[random].db

Conclusion

This project demonstrates that effective Red Teaming infrastructure requires a blend of offensive security research and defensive DevOps principles. By combining Infrastructure as Code, Source Mutation, and Serverless Edge Computing, I created a C2 environment that is resilient against both network-based heuristics and host-based forensic analysis.

Continue to Part II

The infrastructure is built, but now it needs a gatekeeper. In the next part, I deploy a Smart Serverless Redirector to make the backend completely invisible.

Read Part II: The Serverless C2 Redirector →

All rights reserved. Any use of my content is strictly prohibited!