Your Ingress Filtering Does Not Stop Data From Leaving

Network security is measured in one direction, and it is the wrong one. Ask a team how many inbound connection attempts were blocked last month and it will produce a dashboard within a minute. Ask what left the network, and it will produce a pause. Ingress filtering is the most mature, most instrumented and best-funded control in the stack, and it is also the control that a completed breach quietly proves irrelevant — because a breach does not end when an attacker gets in. It ends when data gets out.

The asymmetry has a price, and the price is now measurable. Microsoft's Digital Defense Report 2026, released in early October 2026, found that 63 percent of the intrusions it reviewed involved data theft, that 52.2 percent of compromised accounts involved subsequent credential theft, and that exposed cloud workloads were attacked an average of 5.3 hours after they became reachable. Read the second figure slowly. The majority of successful intrusions do not begin with a novel exploit; they begin with a credential that already worked, used from a host that was already authorised, over a session that was encrypted from end to end and returned HTTP 200.

Nothing about that session is anomalous except its consequences, and consequence is not a field in a packet header. This article is about what is left to look at once TLS has taken the content away, why the detection layers most teams already own cannot separate an attacker's traffic from their own automation, and what to build instead. The argument is deliberately narrow. It is not "buy an egress firewall". It is that the signal worth building is not novelty — and almost every egress control in production is a novelty detector.

The Direction Nobody Measures

Inbound controls win attention because ingress produces events. A blocked packet generates a log line, a failed authentication generates a log line, a rejected request generates a log line, and log lines can be counted, graphed and alerted on. Egress produces flows: long-lived, low-variance, boring, and almost always legitimate. A flow record has no field for intent.

Put the two next to each other and the gap becomes obvious. An inbound port scan against your host is a sequence of connection attempts with no completed handshake, arriving from an address with no relationship to your service. It is trivially distinguishable from your real users. Now consider the outbound equivalent. A host that has been compromised opens a TCP session to port 443 on some internet address, performs a TLS handshake, sends several megabytes of application data, receives a few kilobytes in reply, and closes. That is also what your deployment pipeline does when it uploads a build artefact. It is what your log shipper does continuously. It is what every API call with a large request body does. There is no handshake-free signature, no malformed-request tell, no difference in shape at all.

This is why inbound hardening advice is so abundant and egress guidance so thin. Inbound has a natural threshold: an attempt either completed or it did not. Outbound has no natural threshold, because volume is not evidence. The problem with a volume threshold on egress is not that it produces false positives — it is that it produces the same false positive every night at the same time, and within two weeks the operator has written a filter for it and stopped looking.

There is a second reason the outbound direction gets neglected, and it is more uncomfortable. Auditing egress means enumerating every destination your fleet talks to and attaching a name to each one. That is not a tooling task; it is an ownership task. It requires asking people what they deployed, and it produces the answer that some of it has no owner. Teams avoid this because the exercise feels like archaeology rather than security. It is, and that is the point: you cannot enforce a boundary you have never described.

TLS Took the Content and Left You the Metadata

Deep packet inspection was never a general-purpose answer to the outbound problem, and it has been getting narrower for a decade. Under TLS 1.3, the server certificate is encrypted in transit, so a passive sensor no longer learns the common name of the destination. Encrypted Client Hello removes the server name indication as well, which had been the last readable label on the outside of the envelope. What survives on the wire is a set of properties that do not include any part of the conversation.

That surviving set is worth taking seriously rather than dismissing. Who a host talks to, how often, and how many bytes it sends are real signals, and they are the foundation of everything recommended later in this article. But it is important to be honest about what that metadata means for the detection products built on top of it, because the assumption underneath those products is about to break. All of them assume that ordinary traffic is ordinary and malicious traffic is strange. Encrypted traffic does not let you check whether the traffic is strange in content. It only lets you check whether it is strange in shape. And shape is the one property an attacker can now inherit for free.

Why Attack Traffic No Longer Has to Look Unusual

The foundational indicator of network compromise for the last fifteen years has been machine-like cadence. Malware beacons on a timer; humans do not. A connection that recurs at a near-constant interval to a single destination, with low jitter, was for years one of the highest-value detections available to a defender, because almost nothing legitimate behaved that way.

That indicator assumed the only machine-like traffic in an enterprise network was malicious. It stopped being true when enterprises began deploying machines on purpose.

The clearest measurement of what this did to detection comes from a 2026 paper on exactly this problem. When Agents Look Like Beacons (arXiv:2609.19091, submitted 16 September 2026, accepted at the NIPA 2026 workshop co-located with IEEE ICNP 2026) built a controlled testbed and ran eleven mathematically defined traffic profiles across three TLS visibility conditions — opaque TLS, TLS-inspected through a decrypting proxy, and cleartext as a control. The profiles included ordinary human browsing, benign background API automation, two synthetic command-and-control variants modelled on default and aggressive beacon settings, four shapes of AI agent tool-call traffic, a jitter-smoothed variant, and a large-payload variant standing in for a database dump.

Against those profiles the study ran a monitoring stack of the kind found in production networks: Suricata v8.x loaded with the complete, unmodified Emerging Threats Open ruleset of 44,236 rules; Zeek v6.x with community JA3 and JA4 fingerprinting scripts; and RITA v5.x, a behavioural beacon scorer, processing the resulting connection logs. Each profile-condition pair was repeated five times for sixty seconds.

The result is worth stating plainly, because it is not the result the tooling was designed to produce. Every one of the eleven profiles, under every one of the three visibility conditions, scored 0.0 on the behavioural beacon scale. Suricata produced near-zero actionable alerts; the authors note that no command-and-control rule and no exfiltration rule ever fired, and that the only content alerts observed at all — an average of 0.25 per run at the cleartext control condition — were traced by hand to a missing request header in the traffic generator, not to anything malicious.

The finding that deserves to be quoted is not the score. It is what happened when the authors tried to make the traffic evasive. They added twenty percent timing jitter to smooth the periodic pattern, and separately they substituted browser User-Agent strings to disguise the client. Neither produced any measurable change in any result. The reason is almost funny: the baseline traffic was already invisible, so there was nothing to hide from. Evasion has become redundant, because the ordinary, authentic, legitimate traffic of a modern fleet already occupies the space that detection was told to flag.

That is the inversion this article is about. The conventional framing of encrypted command and control is that an attacker hides inside a crowd of legitimate-looking sessions. The accurate framing in 2026 is closer to the opposite: legitimate sessions have learned to look like attacks, so an attacker no longer needs to hide. When your own background automation polls an API at machine speed with a constant payload profile, "machine speed" stops being an indicator of anything, and the detection rule that used it does not degrade gracefully — it goes to zero.

Two caveats belong here, because precision is what separates a useful finding from a headline. First, the study is an initial characterisation with five repetitions per configuration, not a precise estimate of a continuous effect; its authors say so explicitly. The binary nature of the outcome — scores sitting at exactly 0.0 or consistently far below any threshold — makes five runs sufficient to establish direction, but it is not a large sample. Second, one of the zero scores has a mechanical explanation that is not a detection failure at all. Behavioural beacon scorers need a minimum number of connections per host pair inside a measurement window before they can compute the quartiles that their score is built from. Two of the synthetic command-and-control profiles generated fewer than twelve unique connection records in their sixty-second windows, so the scorer returned 0.0 by construction rather than by missing something. That is a boundary condition of the algorithm, and any team running one of these scorers should know its floor — otherwise they will read a floor as a verdict.

The Three Layers, and the Question None of Them Asks

It is worth being precise about why a well-built stack failed, because the failure is structural rather than a misconfiguration, and it applies to more than the specific products tested.

On the fingerprint point, the study's observation is instructive in a way that is easy to miss. Zeek extracted a JA3 hash for the client stack, and cross-referencing that hash against the Abuse.ch SSLBL threat intelligence feed returned zero malicious associations. The hash was distinctive. It identified the traffic as coming from a program rather than a browser. And it meant nothing, because reputation requires history and new software has none. In the testbed the client was a well-behaved Python HTTP library; the identical situation arises for genuinely malicious tooling that is also new, which is to say for most of it at the moment it first appears.

Step back and the shared property of all three layers is obvious and slightly damning. Every one of them is a novelty detector. Signature engines look for novelty in content. Behavioural scorers look for novelty in timing. Reputation systems look for novelty in identity. All three answer the question "is this like the bad things we have seen before".

On the outbound side, that is the wrong question, and it is wrong for a reason that has nothing to do with attacker sophistication. The traffic you need to judge is generated by software you own, holding credentials you issued, exercising permissions you granted. It is authentically yours. There is no novelty to detect because there is no impersonation. The question that actually helps is the opposite one — "is this like the good things we expect" — and it has the property that most security tooling cannot cope with: answering it requires knowing what normal is, in advance, for every host.

There is a threshold detail that makes this worse in practice. Operational guidance for behavioural beacon scores places the actionable bar at 0.8 or above, meaning that a connection pattern must be regular enough to be flagged. A high threshold rewards regularity. Regularity is the cheapest property for an attacker to abandon and the most expensive one for you to give up, because your agents and your monitoring systems need it in order to function. The threshold is not wrong. It is simply optimising for a property that legitimate software also needs, which guarantees that the separation between the two narrows as automation spreads.

Five Things That Look Like Exfiltration and Are Not

Before building anything, it helps to know what will drown it. These five patterns produce outbound flows that match the shape of data theft, and each one will land in an alert queue if the detection is shape-based.

1. Container image and package pulls. The direction is inverted, which is the discriminator if you look at it carefully — a pull is inbound-dominant. But byte counts alone are identical to a large upload, and registry traffic is genuinely enormous, so a volume-based rule cannot tell them apart.
2. Cross-region snapshot and backup replication. Scheduled, large, recurring, and pointed at a destination that the person reading the alert often cannot name, because it was configured by a different team two years ago.
3. CDN and static-asset publishing. Bursty, large, and directed at a rotating set of edge addresses that changes faster than any static allow-list can track.
4. Log shipping and endpoint telemetry. Small, constant, initiated by a binary whose process name may not appear anywhere in your asset inventory.
5. Large-payload model API calls. Here the sensitive content genuinely does leave, and the transfer is not an intrusion — it is an exposure. It belongs in the same inventory even though it is not an attack, because the review question is the same: who decided this was allowed.

The reason this list matters is not that these are false positives to be suppressed. It is that they are the mechanism by which an operator becomes desensitised. An alert that fires during the backup window every night for two weeks does not produce vigilance. It produces a filter, and the filter is written by someone who has correctly concluded that the alert is noise — and who has no way to know that it will also be correct on the one night that matters.

Three Things That Do Not Look Like Exfiltration and Are

The mirror image is where the actual gaps live, because these produce flows that are quiet, small, and structurally similar to traffic you deliberately authorised.

Name resolution. The volume per query is tiny — a few hundred bytes of encoded data fits comfortably in a subdomain — so it disappears against a resolver's normal traffic. The signal is not volume. It is entropy and novelty: unusually long labels, high-entropy character distributions, and parent domains that your resolver has never answered for before. This is also the one channel that nearly every attack path needs, which makes it disproportionately valuable to instrument relative to its size.

Encrypted sessions on ports your baseline never classified. Alternate HTTPS ports exist as genuine conveniences and as holes in port-based policy, because a rule written as "allow 443 outbound" is silent about everything else and a rule written as "deny everything except 443" is never quite what gets deployed. The signal here is that a given destination-and-port pair is new to this host, which is a very different question from whether the port is unusual on the internet.

A quiet host with one new destination and a small, steady outbound volume. This is the highest-signal case and the hardest to alert on, because a small steady outbound flow is what a heartbeat looks like, and you almost certainly deployed heartbeats on purpose. Every shape-based rule will classify it as normal. The question that separates the two is not about shape at all: can you name the person who added this destination, and can they name the service behind it. If the answer is no, you have found something. It may not be malicious, but it is unidentified, and unidentified outbound traffic is the entire problem restated.

The Two Derived Metrics Worth Building

Two metrics can be computed from flow records you probably already collect. Neither is a threshold on volume, because a threshold on volume is the first thing an attacker tunes against.

New destinations per host per day. Take your flow logs, collapse each destination to a coarse identity — an autonomous system number and port, or a /24 and port — and count first-seen tuples per host per day. A healthy host shows a step at deployment and then falls to a floor near zero as its dependencies are established. A compromise shows a step you cannot attribute to a change anyone made. The metric is bounded, comparable across hosts, and does not depend on knowing what the traffic contains.

The outbound-to-inbound byte ratio, tracked as a trend per host role. A web server is heavily inbound-dominant. A database is roughly balanced. A build agent is outbound-dominant and should be. The signal is not the value; it is a step change in the value for a host whose role did not change. This is the metric that catches slow exfiltration, which no volume threshold will ever catch, because staying under the volume threshold is the entire design goal of slow exfiltration.

The reputation row deserves a note, because it is a place where the threat landscape genuinely moved. NETSCOUT's DDoS Threat Intelligence Report for the first half of 2026 observed residential proxy networks supplying source addresses that its telemetry recorded participating in attacks, and its conclusion is that defenders increasingly face the task of distinguishing malicious traffic from legitimate demand when the addresses look like ordinary subscribers. The same logic applies to destinations. A legitimate content network genuinely is reputable, and it will also proxy a request to an attacker's origin if the attacker configured it to. Destination reputation is a useful input and a bad primary control.

A Ninety-Minute Baseline Exercise

Everything above points at one deliverable that is cheap, boring, and worth more than any product in this category: a one-page document listing every destination your fleet talks to, with an owner attached to each line. Here is how to produce it without breaking production.

1. Pull thirty days of flow records. VPC flow logs, a Zeek connection log, or whatever your provider exposes. The fields that matter are timestamp, source, destination, destination port, protocol, bytes out, bytes in and duration.
2. Collapse destinations to a coarse identity. Group each host's outbound flows by autonomous system number and port, or by /24 and port if you prefer. The point is to reduce a list of tens of thousands of addresses to something a human can read.
3. Apply a frequency filter, not a volume filter. Anything that appears on twenty-five or more of the thirty days is your baseline and needs no further thought. Anything that appears on three days or fewer is a candidate. This is the whole technique, and it works because it uses recurrence rather than size.
4. Ask one question per candidate: can you name the owner? If yes and it is documented anywhere, the line is finished. If no, the line is not necessarily an incident — it is an unknown, and the job is to write it down rather than to escalate it.
5. Publish the document. Not as an alert, and not as a dashboard: as a list with names on it. That document is the egress policy. A boundary that exists only in a firewall rule set is a boundary nobody can reason about, extend, or review.

The exercise has one dependency that is worth checking before anything else, and it is the one that most often turns out to be missing. Flow logging must be enabled, and its retention window must be at least as long as the period you intend to characterise. A seven-day retention cannot support a thirty-day baseline; it can only answer questions about the last week, which is slightly shorter than the interval over which slow intrusions unfold. If retention is short, raising it is the first improvement available and it costs nothing except storage. Every day of delay is a day for which the question "what did this host talk to last month" has no answer.

Note what this exercise does not do. It does not classify anything as malicious. It does not require a threat feed. It does not require that anyone understands what is inside the encrypted sessions, because it never claims to. Its correctness criterion is narrow and checkable: every line has a name. That is a much easier standard to meet than "no line is dangerous", and it delivers most of the value, because the proportion of real intrusions that would trip over an unexplained destination is high while the proportion that require deep analysis to identify is comparatively small.

Restrict by Default, but in This Order

The instinct after building a baseline is to enforce it. Enforcement is worth doing, but the ordering matters more than the decision, because the fastest way to lose organisational support for egress control is to break a deployment on the first day.

First, instrumentation and retention. This is not optional and it goes first because every later step consumes its output. You cannot write a policy for flows you cannot list.

Second, the internal resolver. This is the highest-leverage single change available, because almost every outbound flow begins by resolving a name, and resolver logs are cheap to collect and easy to read. Run the resolver in a mode where it records what it would have denied rather than denying it, keep that running for two weeks, and treat the recorded misses as the first draft of your allow-list. The traffic that would have broken is the traffic you now know about, which is exactly the inventory you were missing.

Third, default-deny at the host's network boundary, using the enumerated allow-list rather than a template. Be explicit about the cost here, because it is real: a default-deny egress rule breaks the update path. Package repositories, operating system update endpoints, and the control-plane endpoints that any management agent depends on all have to be named as lines in the policy. Most first attempts fail at exactly this point and the failure is usually read as evidence that egress control does not work, when it is evidence that the allow-list was written from a template instead of from observation.

Fourth, and separately, the provider's control plane. This is its own item because it is a different kind of destination, and it is covered in the next section.

One framing note helps when the conversation turns into an argument about blocking things. The objective is not that less traffic leaves. The objective is that every outbound flow has a name attached to it and a person who can speak for it. A default-deny rule whose allow-list contains entries nobody can explain is worse than no rule at all, because it produces confident, wrong answers and discourages exactly the review that would have caught the problem. The most durable egress restrictions in practice are not the strictest ones; they are the ones whose failure mode is obvious enough that everyone accepts the trade without relitigating it every quarter. Blocking outbound port 25 by default is the clearest example — nobody argues about it, because the alternative, your server as a spam source, is visibly worse.

The Exfiltration Path That Produces No Outbound Bytes

There is a class of data theft that flow logs cannot see, and it is worth naming because it defeats the metric-based approach above without contradicting it.

The provider's own API is an outbound destination. A host holding an instance role is, by design, able to make authenticated calls to a control plane that manages storage, networking and access. If that role is broad enough, those calls can copy data, alter a bucket policy, or grant access to another account. In that path, the data does not traverse the host's network interface in bulk at all. It is moved by the storage layer, under an identity that was legitimately authorised to request the move. Your flow logs record a small API call to a control-plane endpoint you allow-listed months ago, and nothing else. The volume never grows, the destination never changes, and the outbound-to-inbound ratio is unremarkable.

The control that covers this is not the firewall. It is the control plane's own audit log, read on a schedule, plus the discipline of scoping instance roles so that the role a workload holds cannot perform an operation that shares or re-grants access to anything. The question to ask of every role is not "what does this workload need to do" but "what is the largest single call this credential could make", and then to check whether that call would move data out of the account. If it would, the credential is the boundary, and flow logging will not back you up. Two of the similarly-named weaknesses already covered on this blog follow the same logic — a snapshot's recovery copy lives inside the blast radius of the thing it protects, and a credential list is a security boundary regardless of how carefully the traffic around it is monitored.

The practical consequence is that an egress programme has two halves that must be run together. Flow-based review catches the traffic that looks like traffic. Control-plane review catches the actions that do not. A team that builds only the first will have an accurate picture of the network and no picture of the account.

Frequently Asked Questions

Is TLS inspection not simply the answer? It is a partial instrument with a real cost, and it should be deployed on a segment where you have both a legal basis and a maintenance budget rather than used as the whole strategy. A decrypting gateway is a man-in-the-middle you must own deliberately, it breaks clients that pin certificates, and it does nothing for traffic that never traverses the inspected path — which, in a modern multi-provider environment, is a large fraction of it.

Does this mean AI agents are a security problem? The traffic they generate is not distinguishable from command-and-control beaconing at the network layer, but that is a visibility property rather than a vulnerability in the agent. The vulnerability is elsewhere: in the scope of the tools the agent can call and the credentials it holds. The network consequence is narrower and more annoying. It is that "machine-like cadence means compromise" has stopped being usable as an indicator.

Do I need to buy a new tool for this? No. Flow logs, resolver logs and the provider's control-plane audit log already contain the data. The scarce inputs are thirty days of retention and one hour of attention from somebody who knows what was deployed.

How do I know the baseline is right? You do not, and it is worth abandoning the attempt to make it authoritative. The baseline is not a security assertion; it is an ownership inventory, and its correctness criterion is that every line has a name attached. A baseline that has been argued about and annotated is more useful than one that has been validated, because the arguments are where the missing owners get found.

What is the single fastest thing to do today? Turn on flow logging if it is off, and check the retention window if it is on. If retention is under thirty days, raise it. That change costs storage, requires no architectural decision and no change window, and it determines whether the next question anyone asks can be answered at all.

Where a Disposable Host With a Real Boundary Fits

Every step above assumes three things that are surprisingly hard to arrange together. You need a network boundary that you control and that logs, so that a flow record exists to analyse. You need a host you are willing to break while you learn what its baseline looks like, because the first thirty days of any enumerated allow-list are wrong and the cost of being wrong should not be a production incident. And you need the starting state to be documented, so that step one begins from a known configuration rather than from an assumption about which ports were open when the machine was built.

That combination is what a short-dated instance on an isolated virtual network gives you, and it is the reason the network boundary matters more than the machine's specification for this particular exercise. The trial plan for UHost on SurferCloud is built for exactly this kind of bounded, disposable use: three-day and seven-day instances with the published prices of $1.9 and $3.9 for the 2 vCPU / 2 GB tier, $4.9 and $6.9 for 2 vCPU / 4 GB, $5.9 and $10.9 for 4 vCPU / 8 GB, and $14.9 and $24.9 for 8 vCPU / 16 GB, with higher standard prices displayed alongside. The documented environment is a self-managed VPC private network with full network isolation, intrusion detection, DDoS protection and data encryption, across 17 or more global data centres, on Linux or Windows, with a 99.95 percent availability commitment and kernel hot-patching for security updates without a restart. Port 25 is blocked by default and instances use data-centre addresses with no replacement option, which are the sort of documented defaults that make a first allow-list derivation meaningful instead of guesswork.

The honest limits are worth stating alongside the terms. The trial is limited to one participation and one instance per user. Region and availability-zone changes are not supported, and configurations cannot be scaled during the trial; deletion refunds at the original price. And the most relevant limit is arithmetic: a three-day or seven-day window is shorter than the thirty-day baseline this article recommends, so the sensible use of a trial instance is to build and validate the collection pipeline — confirming that flow records arrive with the fields you need, that the collapse and frequency steps produce readable output, and that the resolver logging lands where you expect — and then to run the full thirty-day characterisation against systems that already exist. As of 21 October 2026 all four published trial tiers showed a sold-out stock state on the page, so availability is worth confirming with an account manager rather than assumed.

If the goal is simply to stand up a short-lived host with a network boundary you can describe precisely, that is the shape of the offer. If the goal is deep egress engineering across an existing estate, the trial is a sandbox for the pipeline and the estate is where the work happens.

Start With the Direction You Are Not Watching

The uncomfortable summary is that inbound filtering is a mature discipline applied to the direction an attacker does not need to win, while outbound auditing is an immature discipline applied to the direction that decides whether an intrusion becomes a breach. The tooling aimed at the outbound side is built to detect novelty, and the traffic that matters most is not novel — it is software you own, using credentials you issued, doing something nobody can name.

Two things are worth doing this week, and neither requires a purchase. Turn on flow logging and confirm the retention window covers a month. Then pick one host, ideally a disposable one with a network boundary you fully control, and spend ninety minutes producing the one-page ownership inventory of everything it talks to. The list will be wrong, incomplete and mildly embarrassing. It will also be the first document in the history of that host that describes its outbound behaviour at all, which makes it the foundation of every egress control anyone builds afterwards.

If you want a disposable instance with a documented, isolated network boundary to run that exercise on, the trial plan covers the relevant shapes:

• UHost trial plan — three-day and seven-day instances with a self-managed VPC
• What the first hour of a server's life exposes, and how to close it
• SMS pumping fraud: when the cheapest thing to attack is a verification endpoint
• A full connection tracking table: when the network fails while the link is idle