Five Things Hosts Do That Look Like Attacks
By Eric Davis and Stephen Moore
A 2 a.m. backup looks like exfiltration. Patch Tuesday looks like an intrusion. Here are five ordinary host behaviors that light up a behavioral detector, how to tell them from the real thing, and the one case behavior cannot settle.
Three in the morning on a file server
The score arrives at 3 a.m. Outbound connections to an address the host has never contacted. Sustained transfer, still climbing. A process nobody started by hand.
That is what exfiltration looks like. It is also what last night's backup looks like.
Anything that learns a host's normal will flag things that are unusual and harmless, because unusual and harmless is most of what happens on a network. A tool that never fires on a backup window is not watching behavior. It is matching a list, and lists miss what you did not know to put on them.
So the flag is not the failure. The minutes after it are the job, and that job goes faster when the boring answers are recognizable on sight. Here are five.
1. The backup window
Around 2 a.m. a quiet host wakes up and moves data. Outbound volume goes vertical. A destination appears with no traffic history. A service that sleeps all day becomes the busiest thing on the box, and the transfer runs for an hour without pausing.
Every one of those is also an indicator of staged theft. That is not a quirk of the math. Bulk collection and bulk theft are the same physical act, performed for different reasons, and watching the host will never tell you the reason.
The tell: a backup goes to the same place, at the same hour, at a volume that barely moves week to week. And that place is inside the enterprise, often a known backup host. Exfiltration is a first visit, and it usually leaves the building. A nightly copy to a server on your own network is a different kind of outbound than a transfer to an address outside it.
2. Patch Tuesday
Once a month a few hundred hosts do all of it at once. New binaries land in directories that rarely change. Process creation spikes. Services stop and start. Listening ports vanish and come back, sometimes on different numbers. Some hosts reboot, resetting every counter you were watching.
Read that without the word "patch" in front of it and it is a competent intrusion: dropping binaries, restarting services to load them, changing what the host listens on. The behavior is right. Only the authorization differs, and authorization is not something a host's behavior records.
The tell: patching happens to a group, not a host. Fifty machines with the same shape inside two hours is a maintenance window. A campaign looks like a few hosts, then a few more.
3. Log rotation
Files vanish. Others are renamed, compressed, and written back at a fraction of their size. Permissions change on the way through. Disk usage drops. A compression job eats CPU at an hour when the host is normally idle.
The security reading of "files deleted, renamed, rewritten, timestamps changed, all at 4 a.m." is anti-forensics, and it is a reasonable reading. Clearing logs is among the first things an intruder does once they have what they came for.
The tell: rotation is bureaucratic. It runs on a schedule, touches the same paths in the same order, and keeps the rotated copies, because keeping them is the point. Someone covering their tracks removes the content. They do not carefully preserve seven compressed generations of it. Read what survived, not what disappeared.
4. The runaway process
Something leaks. A worker retries a call that will never succeed, or a memory bug that needed eleven days of uptime finally matters. Memory climbs and stays. CPU sits high. Everything else on the host slows, which shifts a dozen unrelated metrics at once.
Broad and sustained is what a coin miner looks like, and what an implant doing real work looks like. A tool that shrugged at unexplained resource consumption would be a worse tool.
The tell: a leak gets steadily worse and has nothing to say for itself on the network. Memory climbs a straight line while the outbound picture never changes. Work that is worth doing from an attacker's point of view almost always talks to someone. The absence of a network story is the story.
5. The failing disk
This one is different, which is why the list is five instead of four.
A disk starts to go. Read latency creeps up, then write latency. The controller retries, and retries cost time. I/O errors appear in ones and twos. Everything that touches storage slows, which means everything slows, and the timing signature of the machine distorts across metrics that have nothing to do with each other. Processes take longer to start. Queues back up.
That is a host that has stopped behaving like itself, over hours. A behavioral detector will score the deviation, and the metric breakdown will be accurate.
The tell: there is not one. Nothing in the process table, the connection list, or the authentication log distinguishes a machine being abused from a machine that is failing. Both look like a host in distress, because both are.
"False positive" is doing too much work
All five will raise an anomaly, once the system is actually scoring. That is not day one. Qato does not flag deviations until it has watched the host long enough to have a baseline, typically weeks: often a month or two, depending on how you set it. Until then it is collecting, not judging. The five things above are what you see after that. On a newly scoring host, several of them will be loud.
A false positive is when the tool is wrong: it reports that a metric moved and the metric did not move. None of the five are that. The backup really did move a large payload to a new destination at 3 a.m. The disk really is failing. The measurement was correct. What it did not do is say why, because the behavioral side does not deal in causes. It compares a host to its own history and reports the distance.
Right about the deviation, silent on the cause. That is a different failure from being wrong, and it has a different fix. Being wrong is fixed with better math. Being silent is fixed with more context.
What shrinks the pile
Qato is built around that comparison, and a few pieces of it exist so the first month is not a flood.
Normal includes the clock. A quiet Saturday is judged against other quiet Saturdays, not against a Tuesday afternoon, so the 2 a.m. backup is measured against other 2 a.m. backups. Ordinary wobble is not treated as evidence. It also includes where connections go: inside a group of related machines if you have defined one, elsewhere inside the enterprise, or outside it. A backup that stays in-house does not look like a first visit off the network.
Repeats get quieter. The monthly patch window stops shouting after you have seen it a few times, and nobody writes a rule. They never go all the way to zero. "This has happened before" is not the same as "this is fine."
Analysts can mark noise. One bad afternoon cannot train the system to ignore a real signal.
The one that needed something else
That leaves the failing disk. Behavior cannot settle it. A dying drive and an abused host look the same from the process table, the connection list, and the login log.
So the health picture sits on the same screen as the detection. Nobody has to suspect the disk and go hunting.
Two of the five still need a person who knows the backup schedule. Hardware context removes the hour spent on a suspected intrusion that was a dying drive.
Five tells at a glance
| What you see | Looks like | The tell |
|---|---|---|
| Big outbound transfer at 2 a.m. to a new address | Exfiltration | Same inside-the-enterprise destination, same hour, same volume, every night |
| New binaries, service restarts, ports flipping, many hosts at once | Intrusion / dropper | A wave across a group inside two hours, not a drip |
| Files deleted, renamed, compressed at 4 a.m. | Anti-forensics | The rotated copies are still there, on a schedule |
| Memory and CPU climbing, everything else slowing | Miner or implant | No outbound story. A leak does not phone home |
| I/O slowing, errors in ones and twos, timing gone strange | Abuse of the host | No behavioral tell. You need hardware health next to the alert |
The point of a short list
None of the five is a defect. Four are a behavioral tool correctly reporting behavior. The fifth is a broken machine correctly reported as broken.
What you want from a detection layer is not silence. Silence is what a tool produces when it has stopped looking, and it is what the quiet, credentialed, patient intrusion is counting on. What you want is a list short enough to work through, where the boring entries are recognizable in seconds and the one that is not boring is still on it.
Beyond signatures. Beyond rules. Detect the unknown.