The Challenge of Detecting C2 Traffic in AWS

Command-and-control traffic is one of the clearest signs that a workload may already be compromised. Once an attacker gains access to a cloud workload, they often need a way to communicate with it to send instructions, retrieve results, or move deeper into the cloud environment.

‍

In AWS, detecting that activity is not always straightforward. C2 traffic often hides inside ordinary outbound communication. It may use HTTPS, DNS, common ports, cloud-hosted infrastructure, or low-volume traffic patterns that do not immediately look malicious.

‍

That is why C2 detection in AWS should not depend only on known bad IPs or static rules. VPC Flow Logs and DNS logs can provide the raw evidence, but the real value comes from understanding what is normal for each workload and identifying behavior that deviates from that baseline.

‍

What C2 Traffic Looks Like

C2 traffic is not always obvious. In many cases, it looks like a cloud workload making routine outbound connections.

Common patterns include periodic outbound connections to the same external destination, also known as C2 beaconing.

A compromised instance may “check in” with its C2 server every few minutes to receive instructions. The traffic volume may be low, but the regularity of the connection can be suspicious.

DNS behavior can also reveal suspicious activity. A workload may begin querying random-looking domains, newly registered domains, or domains it has never resolved before. In more advanced cases, attackers may abuse DNS itself as a communication channel.

‍

‍

No single log event is enough to confirm C2 traffic. Anomalies gain significance when they form a pattern, such as repeated connections, new destinations, or unusual DNS behavior that diverges from the workload’s baseline.

‍

Two Key Data Sources in AWS: VPC Flow Logs and DNS Logs

Two AWS telemetry sources are especially useful for detecting potential C2 traffic: VPC Flow Logs and DNS logs. Each log type answers a different question when it comes to detecting C2 traffic. 

Used together, these logs provide a stronger detection picture, but surfacing C2 activity from raw data requires a deliberate sequence of steps.

‍

Step 1: Build a Baseline Before Looking for C2

Before you can confidently detect suspicious C2 traffic, you need to understand normal workload behavior.

For each workload, establish a baseline of expected outbound communication:

• Which domains does it normally contact? Which IP ranges, regions, or service providers are typical?
• What ports and protocols does it use?
• How often does it communicate externally?
• Does it normally generate DNS queries at high volume, or only occasionally?

This baseline should be workload-specific. An EC2-based build server, an internet-facing application behind an Application Load Balancer, an RDS database, or a containerized service running in ECS or EKS may all have very different communication patterns. Treating them all the same creates noise and weakens detection quality.

‍

‍A useful baseline should answer questions such as:

• What destinations are normal for this workload?
• Which destinations are new or rarely contacted?
• What ports and protocols are expected?
• What DNS behavior is typical?
• Which geographies or cloud providers are normal?

Without this context, every unusual outbound connection becomes a manual judgment call. With it, suspicious communication becomes easier to prioritize.

‍

Step 2: Look for Suspicious Outbound Deviations

Once a baseline exists, the next step is to identify deviations in outbound traffic. The goal is not to flag every new connection, but to find activity that is unusual for the specific workload and meaningful enough to investigate. Here are some examples:

‍

First-seen or rare destinations

A workload suddenly connects to an external IP, domain or geography it has never contacted before. This does not automatically mean compromise, but it deserves attention, especially if the workload normally has a narrow communication profile.

‍

Beaconing patterns

C2 traffic often involves repeated outbound connections at regular intervals. For example, an EC2 instance may connect to the same destination every five minutes with similar packet sizes or byte counts. Even when each connection looks ordinary, the timing pattern can be suspicious.

‍

Unexpected ports or protocols

A workload that normally communicates over HTTPS may suddenly begin making outbound connections over unusual ports. This may indicate misconfiguration, unauthorized software, or attacker-controlled communication.

‍

Volume or frequency changes

Watch for sudden outbound spikes, sustained low-volume trickles, or unusual connection regularity. C2 traffic does not always involve large data transfers. Sometimes the giveaway is repeated communication, not large volumes.

‍

Step 3: Use DNS to Add Context

DNS is often one of the most useful places to look when investigating possible C2 traffic.

1. Start with newly observed domains. If a workload begins resolving a domain it has never contacted before, compare that behavior against its baseline. Is this workload expected to reach arbitrary internet destinations, or should its outbound activity be limited to known services?
2. Next, look for suspicious domain characteristics. Random-looking domain names, unusually long subdomains, high-entropy strings, or repeated queries to domains that fail to resolve may all warrant review. These patterns can appear in malware activity, domain generation algorithms, or attempts to hide communication inside DNS traffic.
3. Reputation and category can also help. A domain associated with malware, phishing, anonymization, or newly observed infrastructure should receive higher scrutiny than a well-known SaaS or cloud service domain.

That being said, DNS should not be treated as a standalone piece of evidence. It is a context layer. A strange DNS query becomes more important when followed by outbound traffic to the resolved IP, repeated communication, or other deviations from normal workload behavior.

‍

Step 4: Correlate Flow Logs and DNS Before Escalating

Detections are more reliable if they come after correlation.

Consider this workflow: A DNS log shows that a production workload queried a domain it has never contacted before. The domain looks unusual, or it belongs to a category that is not expected for that workload. Shortly afterward, VPC Flow Logs show outbound HTTPS traffic from the workload to the resolved IP address. The same pattern repeats every few minutes.

‍

Any one of those signals may be weak on its own. A new domain could be legitimate. An outbound HTTPS connection could be normal. Repeated traffic could be part of an application update or integration.

Combined, however, the story becomes more meaningful:

• The domain is new for the workload.
• The destination is external.
• The connection repeats.
• The timing looks regular.
• The behavior does not match the workload’s baseline.

That is the point where an analyst can escalate the activity for investigation. The question is no longer simply “Is this IP known to be bad?” At that point, the question becomes “Why is this workload communicating this way now?”, thereby putting more weight on operational context and behavioral deviation.

‍

Example correlation pattern:

• Route 53 Resolver query logs show query_name = newly observed domain
• rcode indicates a successful response
• answers returns an external IP or CNAME
• VPC Flow Logs show the same workload connecting to that destination over dstport=443
• start and end show similar timing every ~300 seconds
• bytes and packets remain low but consistent across sessions

‍

Common Mistakes to Avoid

Several common pitfalls can weaken C2 detection efforts:

• Relying only on known bad IPs and domains. Threat intelligence is useful, but attackers can rotate infrastructure quickly, use legitimate hosting providers, or communicate through destinations that are not yet classified as malicious.
• Treating every workload the same. A destination that is normal for a developer workstation may be unusual for a production database or backend service.
• Ignoring DNS context. Flow logs can show connections, but DNS often explains what the workload was attempting to reach (e.g., a newly registered domain).
• Focusing only on ingress traffic. Many cloud security programs still focus heavily on ingress exposure while overlooking outbound behavior. As shown throughout this article, egress visibility is essential for C2 detection.

‍