One device. Forty countries. Three hundred and forty unique attackers.
All blocked. All logged. And none of it escalated — because the policy held. But what happened next is the point.
The Attack We Didn't Miss
Today we pulled the block log for a single endpoint in our fleet: marks-hp, a Windows workstation running OpenSSH. Nothing unusual about the machine. But its telemetry told a different story.
Since coming online, it has been absorbing a continuous SSH brute-force campaign — probes arriving from IPs across China, Russia, the Netherlands, the United States, Brazil, Vietnam, South Korea, and a dozen other countries. All on port 22. All blocked. Most never reported to a human, because no human needed to act on them.
We geolocated every unique attacker and plotted them on a live map:
Each circle is a cluster of attacker IPs. The size scales with the number of distinct addresses at that location. The colour marks the origin type:
- Orange — China and Hong Kong: Alibaba, Huawei, Baidu, and China Mobile cloud ranges, plus residential ISPs
- Red — Russia, Ukraine, Kazakhstan: VPS providers and residential networks with no commercial footprint in our customers' business context
- Yellow — Europe: heavy concentration in the Netherlands, specifically Eygelshoven — a datacenter hub used by bulletproof hosting providers VMHeaven, Storm Industries, and Techoff, all flagged in threat intelligence feeds
- Blue — US and Canada: a mix of cloud infrastructure and, notably, Palo Alto Networks, Shadowserver, and Censys — legitimate internet-wide security scanners, not threats
- Purple — everywhere else: Indonesia, Brazil, India, Pakistan, Sri Lanka, the Philippines, Malawi, UAE, Colombia
The US cluster is worth understanding. Palo Alto Networks (147.185.132.x, 198.235.24.x, 205.210.31.x) and Shadowserver (64.62.x.x, 65.49.x.x, 184.105.139.x) are well-known research organisations that continuously probe the public internet to map exposed services. Their presence on this list doesn't indicate malicious intent — it indicates that marks-hp has SSH visible to the public internet. That visibility is itself the finding.
What the Map Doesn't Show
The map shows where the attacks came from. It doesn't show what would have happened without the policy.
Standard network security — a firewall, a cloud WAF, an on-premise IDS — would have seen the traffic, logged it, and potentially alerted on it. An analyst might have triaged the alert. A rule might have blocked the top offending IPs.
But only the top offending IPs. And only after the alert was triaged.
What Threatmatic does differently is enforce at the identity layer before the connection ever lands. There's no "top offending IP" threshold to cross. The policy is: if you're not an enrolled identity with a valid session, you don't reach the application. The 340 IPs didn't fail authentication. They never got to attempt it.
That's not a firewall. That's a boundary that doesn't negotiate.
From One Device's Pain to Fleet-Wide Protection
Here's where the architecture changes the equation.
When marks-hp blocks 91.224.92.147 — a Lithuanian VPS known for SSH scanning — that block is a data point. One device, one IP, one moment in time.
When that same IP shows up in the block log of three other devices across two other organisations in the same fleet, it stops being a data point and becomes a signal. The Threatmatic intelligence layer correlates across every enrolled device, across every organisation, in real time. An IP that's probing one endpoint is immediately visible as a pattern when it appears on others.
The response isn't manual. When a source crosses the confidence threshold — when it's been blocked on enough devices, or matches enough threat intelligence attributes, or exhibits enough scanning behaviour — a fleet-wide suppression rule can propagate automatically. Every device in the network stops seeing that source. Not because each device independently decided to block it. Because one device's experience became everyone's protection.
Detect anywhere. Protect everywhere.
The device that first encounters the threat does the work. The rest of the fleet doesn't have to.
The Organisations That Benefit Most
A single organisation with a hundred devices generates meaningful telemetry. But the intelligence value compounds with scale.
Threatmatic operates across multiple organisations simultaneously. When an attacker pivots from targeting one customer's devices to targeting another's, the second customer doesn't experience it as a fresh attack. They experience it as a pre-blocked source — because the first customer already encountered it and the intelligence propagated.
This is the structural advantage of a shared intelligence fabric over isolated per-tenant security stacks. A boutique firm with five devices gets the same threat visibility as the enterprise with five thousand, because they're drawing from the same continuously-updated pool of signals.
The smaller you are, the more this matters. Small organisations rarely have dedicated security analysts. They rarely have threat intelligence subscriptions. They rarely have the bandwidth to correlate across data sources and push blocks proactively. With Threatmatic, they don't have to. The platform does it for them — and the signals feeding that process come from every enrolled device in the entire network, including devices in organisations they'll never know exist.
The Three Things We Already Know About Your Threat Landscape
Based on what we see across the fleet today:
SSH is universally exposed. Every device running OpenSSH with a public IP — or with any path to the public internet — is being probed. Not occasionally. Continuously. The volume is high enough that it appears as background noise on most telemetry dashboards, which is exactly why it gets ignored. It shouldn't be ignored. It's the loudest signal that your attack surface is visible.
The Netherlands and China dominate SSH brute-force sourcing. The Eygelshoven datacenter cluster and China Mobile / Alibaba Cloud ranges appear on the block lists of virtually every device we monitor. These aren't targeted attacks. They're industrialised scanning infrastructure, running continuously, looking for anything that answers on port 22 with a weak credential or a known vulnerability.
Cloud scanners see everything you expose. Palo Alto Networks, Shadowserver, and Censys appear in marks-hp's block log not because they're adversarial, but because they methodically map the internet. Their presence confirms that your exposed services are indexed — which means adversarial actors using those same indexes can find them too. If your endpoint is in Shadowserver's dataset, it's in someone else's target list.
What This Means Operationally
The marks-hp block log is a microcosm of what every exposed endpoint in your fleet is experiencing right now.
The policy held. That's good. But policy alone isn't intelligence. Intelligence is knowing the volume, the origin, the pattern, and the implication — and using that knowledge to improve posture before the next wave arrives.
Threatmatic gives you both: the policy that holds the line, and the intelligence that tells you what the line is holding against. Continuously. Across every device you enroll — and across every device enrolled by every other organisation in the network.
When one device sees something new, every device benefits from what it learned.
That's the fleet advantage. And it compounds every time a new device joins.