Skip to main content
All C2 traffic is logged to dedicated Apache log files — separate from any default Apache logs. Each VirtualHost (HTTP and HTTPS) writes to its own access and error file, so you can monitor plain-HTTP and TLS traffic independently.

​
Log file locations

FileContent
/var/log/apache2/redirector-access.logHTTP (:80) access log — all inbound requests
/var/log/apache2/redirector-error.logHTTP (:80) error log — rewrite trace, proxy errors
/var/log/apache2/redirector-ssl-access.logHTTPS (:443) access log — all inbound requests
/var/log/apache2/redirector-ssl-error.logHTTPS (:443) error log — rewrite trace, TLS errors
In production C2 operations, agents connect over HTTPS. Monitor redirector-ssl-access.log as your primary log during active sessions. The HTTP access log is useful for debugging connectivity and testing the header validation flow.

​
Access the logs

SSH to the redirector first: 
ssh -i rs-rsa-key.pem admin@<REDIR_PUBLIC_IP>
Then tail whichever log you need: 
# Last 50 lines of HTTPS access log
sudo tail -50 /var/log/apache2/redirector-ssl-access.log

# Last 50 lines of HTTPS error log
sudo tail -50 /var/log/apache2/redirector-ssl-error.log

​
What to look for

​
Active Mythic callback traffic

Once an Apollo agent is running on a target, it beacons at regular intervals. In the HTTPS access log you will see repeated requests to the Mythic URI prefix: 
<target-ip> - - [19/Mar/2026:14:32:01 +0000] "GET /cdn/media/stream/status HTTP/1.1" 200 248
<target-ip> - - [19/Mar/2026:14:32:11 +0000] "POST /cdn/media/stream/update HTTP/1.1" 200 512
<target-ip> - - [19/Mar/2026:14:32:21 +0000] "GET /cdn/media/stream/status HTTP/1.1" 200 248
/cdn/media/stream/status is the Mythic check-in. /cdn/media/stream/update carries task results. Regular alternating GET/POST requests at your configured beacon interval confirm the agent is healthy and traffic is flowing through the redirector.
Run sudo tail -f /var/log/apache2/redirector-ssl-access.log on the redirector at the same time as you task an agent in the Mythic UI. You will see POST requests appear in the log immediately after issuing a command and again when the result is returned.

​
Decoy page requests (missing header)

Requests without a valid X-Request-ID header are served the CloudEdge CDN maintenance page and logged with a 200 status: 
<scanner-ip> - - [19/Mar/2026:09:15:44 +0000] "GET / HTTP/1.1" 200 612 "-" "Shodan"
<scanner-ip> - - [19/Mar/2026:09:15:44 +0000] "GET /cdn/ HTTP/1.1" 200 612 "-" "Shodan"
A 200 response with a small body (around 500–700 bytes, the size of the decoy HTML) and no X-Request-ID in the request is the fingerprint of a scanner or automated probe receiving the decoy page. These requests are not proxied to any C2 backend.

​
Blocked scanner traffic (redirect.rules)

Requests from known AV vendor IPs, scanner CIDRs, or TOR exit nodes are blocked at Layer 1 before header validation runs. They appear in the log with a 403 Forbidden status: 
<av-vendor-ip> - - [19/Mar/2026:11:04:22 +0000] "GET / HTTP/1.1" 403 196
<tor-exit-ip>  - - [19/Mar/2026:11:04:55 +0000] "GET / HTTP/1.1" 403 196
A high rate of 403 responses from diverse IPs indicates active scanner or AV probing of your redirector’s public IP.

​
Successful C2 proxy (header present, URI matched)

When a request passes all three layers and is proxied to a C2 backend, the response code reflects what the C2 server returned — typically 200 for a successful check-in or task delivery: 
<target-ip> - - [19/Mar/2026:14:32:01 +0000] "POST /cloud/storage/objects/session HTTP/1.1" 200 1024
A 404 from a C2 URI prefix means the request reached the backend but no listener or agent matched — this is normal before a listener is configured.

​
Error log diagnostics

The error logs capture rewrite trace output (LogLevel warn rewrite:trace3 is set in both VirtualHosts) and proxy backend errors. Use them when a request is not being routed as expected: 
sudo tail -50 /var/log/apache2/redirector-ssl-error.log
If rewrite:trace3 output shows the header condition failing, the X-Request-ID token in the request does not match the configured value. Retrieve the correct token:
terraform output deployment_info
Look for C2 Header: X-Request-ID: <token>. Ensure the agent’s HTTP profile uses this exact value.
AH01114 or connection refused in the error log means Apache could not reach the C2 backend. Common causes:
  • No listener is running on the C2 server (expected until you start one)
  • The VPC peering route was not established — check terraform output network_architecture
  • The C2 server’s security group does not allow traffic from the Redirector VPC (10.60.0.0/16)
SSL errors in redirector-ssl-error.log typically indicate a certificate mismatch between the agent’s expected host and the served certificate. After running Certbot, verify the active certificate matches your domain:
sudo apache2ctl -S
sudo openssl s_client -connect localhost:443 -servername yourdomain.tld 2>/dev/null | openssl x509 -noout -subject -dates

Build docs developers (and LLMs) love

Get started for freeTalk to us