Spin up a fresh cloud instance with SSH open on port 22, walk away for coffee, and come back to a log file already full of strangers. Not hours later. Minutes. The Internet Storm Center’s DShield project has tracked this phenomenon for years: a brand-new, completely unannounced IP address starts collecting login attempts almost as soon as it’s routable. Nobody told the internet this box existed. It didn’t matter. This is the quiet, unglamorous reality that most cybersecurity conversations skip past in favor of ransomware headlines and zero-days: the bulk of what hits your perimeter every single day is dumb, automated, and relentless.

SANS ISC’s Monday Stormcast roundups exist because someone has to keep narrating this background noise, day after day, so defenders don’t tune it out. That’s worth pausing on, because the instinct to tune it out is exactly the problem.

The Internet’s Background Radiation Has a Rhythm

Mass scanning isn’t targeted at you. It’s targeted at everyone, all the time, by botnets that don’t care whose server they’re knocking on. Credential lists get replayed against SSH, RDP, VPN portals, and any web login form that hasn’t bothered to rate-limit itself. The attackers running these campaigns aren’t picking your organization out of a lineup. They’re running the same script against every IP in a range and seeing what answers. It’s brute-force scanning at industrial scale, and it’s been the dominant form of internet traffic aimed at exposed services for over a decade.

What changes year to year isn’t whether this happens. It’s which usernames and passwords show up in the wordlists, which ports get probed first, and how fast a newly provisioned host gets discovered. That’s the kind of pattern ISC’s telemetry is good at surfacing, and it’s a reminder that threat detection doesn’t always mean catching something exotic. Sometimes it just means noticing that root@yourserver got 3,000 login attempts overnight and asking why nobody set up alerting for that.

Why This Is a Cybersecurity Blind Spot, Not a Non-Issue

Here’s the trap: because brute-force noise is so constant, it gets normalized. Teams see thousands of failed logins in a week and shrug, because nothing “happened.” But that framing gets it backwards. Every one of those attempts is a free test of your exposure. A weak or reused password sitting on one forgotten service is the difference between noise and an incident. The cybersecurity failures that make headlines rarely start with a sophisticated exploit chain. They start with a login that should never have succeeded, on a service nobody remembered was internet-facing.

Treating brute-force traffic as background static also means you lose a genuinely useful signal. A spike in attempts against a specific port, or a new pattern in the usernames being tried, often tells you something is about to shift, whether that’s a new botnet variant or a fresh wave of credential-stuffing lists circulating after some unrelated breach. Ignoring that signal is like ignoring a smoke detector because it’s gone off before and nothing burned down.

Hardening the Front Door Without Reinventing Your Stack

None of this requires exotic tooling. It requires actually doing the boring things consistently.

Start with what’s immediately fixable. Disable password authentication on SSH and move to key-based or certificate-based auth; brute-force attempts against a properly configured key-only server are a waste of the attacker’s time, not yours. Put RDP and management interfaces behind a VPN or bastion host instead of exposing them directly. Enforce MFA on anything that still accepts a password, especially VPNs and admin panels, since credential stuffing only works if a bare password is enough.

Then build the ongoing habits. Dynamic IP banning tools, whether that’s fail2ban, a cloud provider’s native rate limiting, or something purpose-built like IPBan or IPBan Pro, automatically lock out source addresses after a threshold of failed attempts, which turns an endless brute-force campaign into a brief nuisance instead of an open invitation. Pair that with actual log review, not just log collection. A firewall that blocks traffic but never gets its logs read is only doing half its job. Rotate exposed ports where it’s practical, not as a real security control but as noise reduction, since it filters out the laziest scanners and leaves your alerting cleaner for the attempts that matter.

This is defense in depth in its most literal form: no single control, not the firewall, not the banning tool, not MFA, is expected to catch everything alone. They’re layered specifically because brute-force campaigns are patient and will eventually find the one gap you forgot to close. Incident response planning should assume that gap exists somewhere, and that the first sign of trouble might be an unusually successful login buried in a sea of failed ones, not an alarm bell.

Reading the Noise Like Threat Intelligence

Security teams that treat their own perimeter logs as a threat intelligence feed tend to catch problems earlier than teams that only consume third-party feeds. Your own scan and brute-force data tells you, in real time, what’s actually being aimed at your infrastructure right now, not what was aimed at someone else last month. Feed that data into your detection rules. If a source IP tries fifty usernames against your VPN in an hour, that’s not just a blocked login, it’s a pattern worth correlating against every other service that IP touches.

The unglamorous truth is that most organizations are never going to be the target of a nation-state operation. They are, every single day, the target of automated brute-force campaigns that succeed exactly as often as defenders let them.

Sources

• ISC Stormcast For Monday, August 24th, 2026