Every time a new extortion gang shows up or a fresh authentication push lands in the headlines, someone in a Slack channel asks whether blocking IPs even matters anymore. This week gave us a useful stress test: ShinyHunters threatening ADT, a Myanmar-based fraud ring operating at industrial scale, the NCSC urging consumers to ditch passwords for passkeys, and a new group called BlackFile running vishing campaigns against retail and hospitality. Four different attack vectors, four different headlines — and a surprisingly consistent answer to that question about ipban and edge-layer blocking. Spoiler: it still matters, but not for the reasons people usually argue about.

Hacker in dark environment representing BlackFile extortion group and vishing attacks
BlackFile’s vishing-led extortion campaign targets retail and hospitality — but the initial network access phase is where IP banning still has teeth.

The Vishing Angle Everyone Underestimates

BlackFile is the newest name in a familiar playbook: call an employee, impersonate IT, get credentials, move laterally, steal data, threaten to publish. BleepingComputer’s reporting on the group describes a wave of attacks against retail and hospitality organizations since February 2026. The entry point is social — a phone call, a convincing pretext, a panicked employee who follows instructions. That part, genuinely, no firewall stops.

But here’s where people get sloppy in their analysis. They see “vishing” and immediately write off perimeter controls as irrelevant. That’s wrong. The voice call is the initial access technique. What follows — scanning internal subnets, querying Active Directory, staging data for exfiltration — that’s where IP banning and automated edge-layer controls still have real leverage. The attacker lands inside with a user’s credentials, but they still need to do reconnaissance, pivot to other systems, and get data out. Each of those phases generates traffic patterns and connection attempts that behavioral IP blocking can flag and disrupt.

The mistake is treating IP banning as if its only job is to stop the first knock on the door. It isn’t. It’s a control that sits across the kill chain, not just at the entry point.

Passkeys Are Right, But They Don’t Replace Every Layer

The NCSC’s passkey guidance deserves credit for being blunt. “Passkeys should become consumers’ first choice for logging into digital services.” That’s a clear position, and it’s the correct one. Passkeys eliminate the entire class of credential-stuffing and brute-force attacks that make up a significant percentage of initial access attempts against consumer-facing applications. If an attacker can’t guess or replay a password, a huge category of automated attack traffic becomes irrelevant.

Passkey authentication concept representing the shift away from password-based logins
The NCSC is now actively pushing passkeys as the default — a shift that changes the threat model for brute-force attacks significantly.

Microsoft is moving in the same direction. Their Entra passkey rollout for Windows in late April pushes phishing-resistant, passwordless authentication to enterprise-managed devices. If your users are authenticating with device-bound passkeys, the attacker can’t just buy a credential dump and point a botnet at your login page.

But — and this is a real but — passkeys are not deployed everywhere yet. Not even close. The transition will take years, not months. During that window, brute-force and credential-stuffing attacks remain entirely viable against services that haven’t made the move. Automated brute force protection at the network edge isn’t a stopgap you abandon the moment passkey guidance drops; it’s a control you run until the adoption numbers actually justify retiring it.

Where Brute-Force Blocking Still Closes Real Gaps

Three specific situations where IP-layer blocking still earns its keep right now, even as passkeys gain ground:

  1. Legacy services: VPNs, RDP endpoints, legacy web apps, and administrative consoles are often the last to get passkey support. They’re also prime targets for automated credential attacks. Blocking IPs after failed login thresholds is still the fastest way to cut noise on these services.
  2. Post-compromise reconnaissance: Once an attacker is inside — via vishing or any other technique — lateral movement involves connecting to systems that have never seen that source address. Behavioral IP banning on internal segments can surface anomalies before exfiltration starts.
  3. Third-party integrations: Your environment almost certainly has systems that authenticate to external APIs, data partners, or SaaS platforms that don’t support passkeys yet. Monitoring and restricting unexpected connection sources remains a practical control.

The ADT Breach and the Outbound Traffic Problem

ADT confirming a breach after ShinyHunters threatened to leak data is a story about extortion, yes — but look past the headline. The interesting operational question is how data leaves an environment without triggering controls. In most breach scenarios, exfiltration looks like ordinary HTTPS traffic to a cloud storage endpoint. The destination IP might even be something hosted on a legitimate cloud provider, which makes blocking purely by IP address genuinely hard.

This is the honest limitation of IP banning in the exfiltration phase: a group like ShinyHunters isn’t going to be sending data to a known-malicious IP on a threat intelligence blocklist. They use clean infrastructure. So what does IP blocking actually contribute here? It contributes at the access phase — blocking scanning, blocking failed authentication attempts, blocking reconnaissance from known-bad ranges — not at the moment of exfiltration. Understanding where in the kill chain a control is effective is the only way to use it correctly.

ADT company signage after confirming data breach tied to ShinyHunters extortion group
ADT’s breach confirmation following ShinyHunters’ extortion threat illustrates how data exposure often happens well before detection.

Myanmar, Seized Domains, and the Value of Threat Intelligence Feeds

The US Department of Justice busting a Myanmar-based ring with 29 defendants, a Cambodian senator in the indictment, and more than 500 seized web domains is a significant takedown. But for defenders, the operationally interesting detail is the domain count. Five hundred fake investment sites, all generating traffic to victims, all presumably tied to IP infrastructure that was live and measurable.

That kind of infrastructure leaves footprints. Shared hosting, common registrar patterns, overlapping SSL certificates, repeated ASN blocks. Threat intelligence platforms that track fraud infrastructure can — and do — identify these networks before law enforcement acts. The window between “this domain is active” and “this domain is seized” can be months. During that window, organizations whose users are being targeted by pig-butchering or investment fraud schemes could be blocking known-bad IP ranges if their threat feeds are current and their firewall policy actually uses them.

The problem isn’t usually that the intelligence doesn’t exist. It’s that the operational pipeline from “threat feed updated” to “firewall rule applied” is broken, slow, or non-existent. Automated IP blocking tied to live threat feeds — what tools like IPBan Pro are specifically designed to handle — closes that gap. Manual blocklist management at scale is simply not viable when infrastructure turns over as fast as fraud rings cycle domains.

Practical Steps That Don’t Depend on What’s Trending

The news cycle this week covers vishing, breach extortion, and authentication upgrades. The underlying operational advice is more durable than any individual story:

  1. Audit your credential attack surface right now. Which of your externally reachable services still accept password-based auth? Those are your immediate priority for both passkey migration and automated failed-login blocking.
  2. Treat lateral movement as an IP-layer event. Internal east-west traffic should have anomaly thresholds. A newly compromised endpoint connecting to ten systems it’s never talked to before is an IP-layer signal before it’s anything else.
  3. Verify your threat feed pipeline is actually live. Pull a known-bad IP from a current threat report and confirm your firewall blocks it. If you don’t know, it probably doesn’t.
  4. Map your exfiltration exposure separately. IP blocking is not your primary exfiltration control. DLP, egress inspection, and CASB sit in that role. Don’t overload edge controls with jobs they weren’t designed to do.
  5. Plan passkey rollout with explicit timelines. Vague intentions don’t reduce attack surface. Set a date for each legacy service or accept that you’re running brute-force exposure until you do.

Frequently Asked Questions

Does the shift to passkeys mean IP banning becomes obsolete?
Not on any timeline that’s operationally relevant today. Passkey adoption is growing but far from universal. Legacy services, third-party integrations, and unmanaged devices will continue to use password authentication for years, keeping automated brute-force blocking essential for those surfaces. The two controls address overlapping but distinct threat scenarios.
Can IP banning meaningfully disrupt a vishing-based attack like BlackFile’s?
Not at the initial access phase — that’s purely a social engineering problem. Where IP banning contributes is in the post-access phase, specifically the lateral movement and reconnaissance activity that follows credential compromise. Anomalous internal connection patterns are still an IP-layer signal worth monitoring and acting on automatically.
How should organizations prioritize threat intelligence feeds for IP blocking?
Focus on feeds that cover attack infrastructure actively used in your sector and region — generic blocklists have high overlap and low signal-to-noise. Automate the update and enforcement pipeline so that new intelligence gets pushed to blocking rules within minutes, not days. The value of a threat feed degrades rapidly if your enforcement cycle runs on weekly batch jobs.

Sources

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.

Stay up to date with the latest news, releases and more.

Take Control of Your Server Security

Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.

Secure. Automated. Lightweight.