DNS telemetry is useful because it gives defenders context before an outbound connection occurs. A process requests a domain, DNS resolves it, and the endpoint connects to the resulting IP. Investigators can examine the domain, resolution history, reputation, and surrounding activity.
Direct-to-IP command-and-control (C2) communication removes part of that chain.
Instead of:
Process → DNS query → domain → IP → connection
the defender may see:
Process → IP → connection
That does not make C2 invisible. It removes one enrichment layer.
The real question for security leaders is whether their detection architecture can still determine that the connection is suspicious.
Mature Cybersecurity Services should be able to correlate destination context, flow behavior, protocol characteristics, encryption metadata, endpoint activity, and historical patterns without requiring a suspicious domain to start the investigation.
DNS Is Only One Part of the C2 Detection Chain
DNS is attractive to defenders because domains are easier to investigate than raw IP addresses. They can carry registration history, categorization, reputation, resolution patterns, and relationships with previously identified infrastructure.
Attackers do not have to provide that evidence.
Malware can connect directly to an IPv4 or IPv6 address, use an embedded IP configuration, receive an address through another channel, or switch infrastructure without relying on conventional DNS resolution as documented in MITRE ATT&CK's Non-Application Layer Protocol technique, which covers TCP, UDP, ICMP, and socket-based C2 communications that bypass DNS entirely.
What remains is still substantial:
- source and destination IP
- source and destination ports
- connection timing
- session duration
- bytes transferred
- protocol behavior
- TLS characteristics
- endpoint process information
- historical network activity
Consider an employee endpoint that establishes an encrypted connection to a previously unseen IP every 90 seconds. No DNS request precedes the connection, and the IP has no known malicious reputation.
None of those observations proves C2.
Together, however, they give a detection engineer something worth investigating.
That distinction matters. Direct-to-IP detection works best as evidence accumulation rather than a search for one decisive indicator.
Start With the Destination, but Don't Stop at IP Reputation
IP reputation is a useful enrichment source. It is a poor substitute for investigation.
Fresh attacker infrastructure may have no history.
An adversary can provision a virtual server, use it before threat intelligence providers classify it, and abandon it quickly as observed in recent state-sponsored campaigns where APT actors leverage virtual private servers and compromised intermediate routers that are not attributable to known botnets CISA's guidance on APT infrastructure.
Shared cloud infrastructure creates another problem because blocking an address based on hosting provider or geography can disrupt legitimate applications.
A better investigation asks several questions about the destination.
Has this organization seen the IP before? How many endpoints communicate with it? Which assets? Which ASN owns it? Is it associated with a hosting provider? Is that provider normally used by the organization? Which port is being contacted? How recently did the relationship appear?
This creates an important distinction between global reputation and local prevalence.
Imagine a production database server suddenly communicating with an external VPS address. The address has no threat intelligence hits.
"Clean IP" is the wrong conclusion.
The useful observation is that a workload with a relatively predictable communication profile has developed a new external relationship.
The same IP contacted by a developer workstation might carry substantially less risk.
For detection teams, the asset-to-destination relationship can therefore be more useful than the reputation score attached to the destination.
Flow Behavior Often Tells You More Than the Destination
Command-and-control infrastructure changes. Communication behavior can be harder to hide completely.
Network flow telemetry can reveal:
- repeated outbound connections
- unusual inter-arrival times
- persistent low-volume sessions
- consistent request and response sizes
- unexpected session duration
- unusual byte ratios
- traffic appearing during abnormal operating periods
- connections that recur across multiple days
The obvious example is beaconing.
A compromised host might contact C2 infrastructure periodically to request instructions. But periodicity by itself is weak evidence. Monitoring agents, update services, telemetry platforms, APIs, health checks, and backup software all communicate automatically.
Context separates them.
A monitoring agent connecting every 60 seconds to established vendor infrastructure from 5,000 managed endpoints has a recognizable organizational pattern.
Two employee endpoints making small connections every 73 to 91 seconds to the same low-prevalence IP deserve different scrutiny.
The variation in that second example also matters. Attackers can introduce jitter specifically to defeat simplistic beacon detection.
Detection logic therefore should not ask:
"Does this connection occur every 60 seconds?"
A better question is:
"Does this endpoint maintain an unusually persistent and semi-periodic relationship with a destination that is rare for its role?"
That combines time, destination, asset context, and prevalence into one investigation.
Inspect the Protocol, Not Just the Port
Another common weakness appears when organizations equate permitted ports with expected behavior.
TCP/443 does not automatically mean normal HTTPS traffic.
Attackers can move C2 traffic across commonly permitted ports, use custom protocols, tunnel communications, or create traffic that superficially resembles legitimate application behavior.
Defenders should compare the protocol observed with the behavior expected for that port and workload.
Useful signals can include:
- unexpected raw TCP connections
- unusual UDP communication
- protocol and port mismatches
- abnormal HTTP behavior
- unexpected WebSocket sessions
- ICMP anomalies
- non-standard port usage
- tunneling patterns
This is where aggressive rules can create operational problems.
Enterprise environments contain proprietary software, legacy applications, vendor agents, and internally developed systems that do not always follow conventional network patterns. A blanket rule for unusual protocol behavior can generate more analyst workload than security value.
The better approach is workload-aware.
A protocol anomaly originating from an Internet-facing developer sandbox does not necessarily deserve the same risk score as the identical anomaly originating from a payment-processing server.
Effective Cybersecurity Services need enough architectural context to understand that difference.
TLS Still Leaves Evidence Even When Payloads Are Encrypted
Encryption changes what defenders can inspect. It does not remove every useful network signal.
Depending on the environment and protocol implementation, defenders may still have access to characteristics such as:
- TLS version
- certificate issuer
- certificate validity period
- certificate age
- certificate reuse
- Server Name Indication (SNI), where observable
- Application-Layer Protocol Negotiation (ALPN)
- client and server fingerprinting
- JA3 or JA4-style fingerprints where supported
- handshake behavior
None should become a standalone maliciousness test.
A fingerprint may be shared by legitimate software and malware using the same underlying library. Certificate characteristics can also overlap with legitimate infrastructure. TLS 1.3 and technologies such as Encrypted Client Hello continue to reduce visibility into parts of the handshake.
The value comes from correlation.
Suppose a scripting process that rarely communicates externally begins creating repeated TLS sessions directly to an unfamiliar IP. The destination is rare internally, the connections are semi-periodic, and the TLS characteristics are unusual for that endpoint group.
The encryption did not reveal the payload.
The surrounding metadata still created a meaningful investigation path.
Endpoint Context Turns Network Anomalies Into Investigations
One of the highest-value improvements a security team can make is connecting network observations to the process responsible for them.
A firewall might tell you:
Host A → 198.51.100.25 → TCP/443
Endpoint telemetry may tell you:
powershell.exe → 198.51.100.25 → TCP/443
That additional context materially changes triage.
Useful endpoint evidence includes:
- process name
- executable path
- parent process
- command line
- file hash
- code-signing status
- logged-in user
- process tree
- recent execution activity
- persistence events
- endpoint role
Even here, defenders need judgment.
PowerShell making an external connection is not automatically malicious. Chrome communicating with an external IP is not automatically safe.
The question is whether the process, destination, timing, and surrounding endpoint behavior make sense together.
This is where disconnected security tooling creates expensive blind spots. An organization may own EDR, SIEM, NDR, firewall, and cloud security platforms while still forcing analysts to manually reconstruct a basic connection timeline across five consoles.
Telemetry volume is not the same as detection capability.
Build Detection Around Evidence Combinations
Direct-to-IP C2 becomes easier to reason about when defenders organize evidence into seven layers.
1. Destination
Is the IP rare, new, geographically unusual, or associated with unexpected infrastructure?
2. Flow
Are connections repetitive, persistent, asymmetric, or unusually small?
3. Protocol
Does the traffic behave as expected for the port and workload?
4. Encryption
What can TLS metadata, certificates, handshake behavior, or fingerprints tell us?
5. Endpoint
Which process and user initiated the connection, and what happened around it?
6. Time
Is there periodicity, persistence, jitter, or an unusual operating-time pattern?
7. Environment
Is this communication reasonable for the asset's actual business and technical role?
Think of this as a Direct-IP C2 Evidence Stack.
A single observation may carry little confidence.
But consider:
No DNS precursor + first-seen destination + unexpected process + recurring connections + unusual TLS characteristics
That combination is much harder to dismiss.
The model should still use risk scoring rather than universal rules. A developer workstation, domain controller, API gateway, Kubernetes worker, finance application server, and production database have different legitimate communication patterns.
The environment determines the meaning of the evidence.
Detection Engineering Fails Without Baselines
Every anomaly detection strategy eventually encounters the same question:
Unusual compared with what?
An organization cannot reliably detect abnormal outbound behavior without understanding normal outbound behavior.
Baselines should reflect asset roles rather than treating the enterprise as one network population.
Useful dimensions include:
- workload type
- subnet
- process
- destination
- protocol
- application
- connection frequency
- normal operating periods
A direct SSH connection from an administrator workstation might be expected.
The same connection initiated by a finance application server could require immediate investigation.
Cloud environments make this harder. Workloads appear and disappear, IP addresses change, autoscaling alters traffic volumes, and service-to-service communication can be highly dynamic.
Identity-aware context becomes more important than static IP-based baselines.
Teams also need to maintain those baselines. A model built around last year's network behavior can become an alert generator after a cloud migration, SaaS rollout, acquisition, or architecture change.
This is why mature Cybersecurity Services treat baselining as an operating process, not a one-time configuration exercise.
What Security Leaders Should Measure
CIOs, CTOs, and security leaders do not need another dashboard showing how many terabytes of network logs were collected.
They need to know whether those logs improve detection and response.
Useful questions include:
- What percentage of outbound traffic can be attributed to an initiating process?
- How many direct-IP connections can be enriched with endpoint and asset context?
- How quickly can analysts investigate anomalous outbound sessions?
- What is the false-positive rate for behavioral C2 detections?
- Are critical cloud workloads covered as well as corporate endpoints?
- Which systems should operate under stricter outbound allowlists?
- Which MITRE ATT&CK C2 techniques have meaningful detection coverage?
- Where does encryption materially reduce visibility?
These measures expose gaps that product inventories often hide.
A SOC can collect enormous amounts of network telemetry and still struggle to answer a simple question: Why did this server connect to that IP?
That is the capability leaders should test.
Test Whether Your Detection Program Can Operate Without DNS
DNS remains valuable evidence. It should not be a prerequisite for identifying command-and-control activity.
A resilient detection architecture should be able to evaluate who initiated an outbound connection, where it went, how the traffic behaved, which protocol was actually used, what encryption metadata remains, how often communication occurred, and whether the relationship makes sense for that asset.
Organizations evaluating their Cybersecurity Services can test this directly.
Take a sample of recent direct-IP connections from critical workloads and temporarily remove DNS from the investigation. Ask whether the SOC can determine the initiating process, destination context, protocol behavior, TLS characteristics, historical prevalence, and communication pattern.
Then measure how long an analyst needs to reach a defensible decision.
If several of those questions cannot be answered, the problem is not simply missing DNS visibility.
It is a correlation and detection-readiness gap.
And that is exactly the kind of gap attackers can use.
Top comments (0)