153 Attackers Hiding in Plain Sight

In a single month, 153 unique IP addresses tried to break into one client's VPN. The attempts came from coordinated scanning campaigns, compromised cloud servers, and known threat-hunting tools. Every single one was recorded in the client's firewall logs. Nobody was reading them.

The Silent Siege

If you run a business with remote workers, you almost certainly have a VPN. And if you have a VPN, you have attackers trying to break into it — every day, from every continent, around the clock. This isn't paranoia. It's arithmetic.

We recently started ingesting Windows Event Log data from a client's RRAS server — the Windows service that handles their staff VPN connections. One specific event ID caught our attention: 4653, "An IPsec main mode negotiation failed." Each of these events represents a failed attempt to establish a VPN tunnel with the server.

We pulled 30 days of data. What we found was sobering.

Reading the Patterns

The raw data is just a list of IPs, timestamps, and failure reasons. On its own, it's noise. But when you look at it properly, patterns emerge quickly.

Pattern 1: The Coordinated Campaign

Forty-plus IPs from the 66.132.x.x range — spread across subnets .153, .172, .186, .195, and .224 — all failed to authenticate in exactly the same way. Same failure types. Same timing distribution across the day. This isn't forty separate attackers. It's one attacker using forty IPs, probably to avoid rate limits.

Pattern 2: The Automated Scanners

Twelve IPs from the 198.235.24.x range all produced the same "policy match error." Seven more from 185.247.137.x produced "error processing KE payload." These are signatures of automated scanning tools — the attacker isn't even custom-tuning the attempts. They're firing scripts at every VPN endpoint they can find.

Pattern 3: The Researchers

A handful of IPs came from known ranges used by Censys and Shodan — legitimate internet-scanning organisations that index exposed services. These aren't attackers per se, but they're cataloguing your infrastructure for anyone who wants to query it. That data is public.

Pattern 4: The Compromised Infrastructure

Over a dozen IPs from Microsoft Azure ranges (20.x.x.x) tried to negotiate tunnels. These aren't Microsoft attacking you — they're compromised cloud VMs, rented or hijacked by attackers to launder their traffic. When you see Azure IPs in your failed VPN logs, someone is using Microsoft's cloud to probe your infrastructure.

What the Firewall Saw vs What We Saw

The firewall was doing its job. Every one of these 153 attacks failed — they didn't know the preshared key, they used the wrong policy, they couldn't process the key exchange. The perimeter held. But nobody ever saw the sustained, organised interest being taken in this company's infrastructure.

Why This Matters for SMBs

If you run a small or medium business with a VPN, here's what this story should tell you:

Your VPN is being probed constantly. The 153 figure isn't exceptional. It's typical. Any internet-facing VPN endpoint — IPsec, OpenVPN, WireGuard, SonicWall SSL VPN, Fortinet SSL VPN — gets this level of automated attention.

Failed attempts are the early warning signal. When an attack eventually succeeds, the failures that preceded it were already in your logs. Reviewing them regularly means you spot trends before you spot compromises.

Compromised VPN credentials are the most common initial access vector. Phishing gets the headlines, but stolen or guessed VPN credentials are how attackers actually get in. And they don't stop at one attempt — they come back with more, from different IPs, over weeks.

From Data to Defence

Spotting the attacks is only the first step. What we did next is where the value compounds.

We built an automated pipeline that extracts failed IPsec negotiation IPs from the client's Windows event log daily, filters out known legitimate users, and feeds the result into ignixip.com — our free public threat intelligence database. Now, when anyone anywhere in the world looks up one of those attacker IPs on ignixip.com, they see it flagged as a known scanner with the context of where it was last seen attacking.

Each client we onboard becomes a source of unique threat intelligence. The more networks Ignix watches, the more valuable the resulting data becomes for everyone. A coordinated attack on one SMB becomes a warning for all of them.

What You Can Do

Whether or not you work with us, here are three concrete actions worth taking this week:

• Review your VPN logs. On Windows RRAS, look at Event ID 4653. On Linux, check your strongswan or openvpn logs. On appliances (SonicWall, Fortinet), check the VPN / authentication log section. Look for patterns — repeated failures from the same subnet, new source countries, spikes in volume.
• Audit your VPN accounts. When did former staff last log in? Are there test accounts still active? Service accounts that should have been deprecated? Each unnecessary account is a door that doesn't need to exist.
• Enable account lockout and geographic filtering. Most VPN concentrators can lock out source IPs after failed attempts and restrict by country. If all your staff are in the UK, there's no reason to accept IPsec negotiations from Russia, China, or Iran.

The Bigger Picture

Firewall logs are not a compliance checkbox. They're a source of real, current, specific threat intelligence about your business. The attackers in those logs are interested in you specifically — they've chosen your IP address for a reason, whether that's your industry, your size, your exposed services, or just the luck of the scan.

Most SMBs will never read their firewall logs. The data is too voluminous, too technical, and too unrewarding for busy people to sift through. That's exactly the gap we built Ignix to close. AI reads the logs for you. It tells you what mattered, in plain English, every morning at seven.

Your firewall is already watching. Let us read what it sees.