Attackers Don't Break In. They Log In.
The quiet intrusion often starts with a real account and a clean session. No exploit. No malware. Just a login your tools were built to allow.
The door was already open
Someone signs in at 2:14 p.m. The password works. MFA, if you have it, was phished or token-stolen last week, or the account was never enrolled. The endpoint agent sees a known user and a standard remote-access tool. The network sees traffic on ports you allow. The SIEM logs a successful authentication and moves on.
Nothing on that screen says "incident."
That is the point. A large share of damaging intrusions no longer begin with a crash, a dropper, or a flashy exploit. They begin with a session your stack was designed to accept. The attacker does not break the door. They use the key.
The numbers keep saying the same thing
Stolen credentials keep showing up as a leading way in. In Verizon's 2025 Data Breach Investigations Report, credential abuse, logging in with stolen or compromised credentials, was the leading initial access vector for the second year running, at about 22 percent of breaches where the path was known. CrowdStrike's 2025 Global Threat Report put malware-free activity at 79 percent of the detections it logged in 2024. Those are industry snapshots, not a scoreboard for any product. Read them together and the shape is hard to miss: the first move often looks like ordinary work.
Those keys are increasingly cut by talking, not hacking. Phishing is the old workhorse, and voice-phishing, or vishing, is the fast-growing one: CrowdStrike reported that vishing rose 442 percent from the first half of 2024 to the second. Adversaries call the help desk, sit in the middle of an MFA prompt, or wear a user down until they approve. Stronger training and phishing-resistant auth shrink that pile of working keys. They do not empty it.
Malware-free does not mean harmless. It means the session rides tools and accounts the environment already trusts. Remote desktop. A cloud console. An admin share. The costume is legitimacy.
If your detection story still starts with "find the bad file," you are spending most of your attention on a shrinking share of how people actually get hurt.
Why "authorized" is such a good costume
Signature tools and a lot of endpoint logic ask a version of one question: is this known to be bad?
A valid login answers no. A signed binary answers no. A user who is allowed on that server answers no. Each answer can be true. The session can still be the attack.
Identity systems help when the account looks wrong: new country, impossible travel, a role that never touches finance servers. They help less when the account is right and the use is wrong. An engineer who usually works from one subnet can still open a quiet afternoon on a box that person almost never touches. The ticket says authorized. The host is not itself.
That is not a failure of EDR or IAM as categories. Those tools earn their keep. It is what you get when the only hard question you ask is "is this allowed?" and the attacker already holds something that is.
Living off the land is the sibling story
We have written about living off the land: abusing admin tools that ship with the OS so nothing looks like malware. That post is about binaries.
This one is about sessions.
Same family. Different costume. LOTL hides in tools you cannot ban. Credential-driven intrusion hides in accounts you cannot turn off. In both cases you end up staring at activity that is, piece by piece, legitimate.
CISA's public reporting on groups such as Volt Typhoon has been blunt about the pattern: long access, administration that looks normal, weak signal for tools that only hunt known-bad. You do not need a nation-state label for the lesson. A criminal with a stealer log and some patience wears the same costume.
Ask a different question
"Was this login allowed?" is necessary. It is not enough.
The harder question is narrower: for this host, at this hour, does this look like how this host normally behaves? That needs a private picture of normal per machine, not a public list of bad files. Time of day matters. A quiet maintenance box and a busy app server do not share a calendar.
When the answer is no, you may not know the full story yet. You know something worth a person looking: this machine stepped outside its own pattern under a session every other layer called fine.
Where Qato fits
Qato is built around that host-level question. It learns what normal looks like for each machine and surfaces when the machine stops looking like itself, with a breakdown you can read. It does not replace identity, EDR, or SIEM. It does not block the login. It detects after someone has already walked in looking legitimate.
Keep MFA, phishing-resistant auth, and least privilege. Those shrink the number of keys in the wild. Behavioral detection is for the keys that still work, and for the hours after the door is open.
What to take to your next stack review
You do not need a new acronym to start.
Ask whether anything you run can say, for one server on one afternoon: this account was allowed, and this machine still behaved like itself. If your only green lights are identity and known-bad, you are thick on one class of attack and thin on the class that starts with a clean login.
Attackers who can log in will keep logging in. The only open question is when you notice: when they finally get loud, or when the host first stops being itself.
Beyond signatures. Beyond rules. Detect the unknown.