Three years after disclosure, CVE-2023-33538 is still getting hammered by Mirai variants targeting TP-Link routers. Thirteen years after it shipped, an Apache ActiveMQ flaw finally got a CVE — and attackers were already on it. If you think modern threats are all AI-powered zero-days, the last 48 hours of telemetry begs to differ. The boring stuff still works, which is exactly why IPBan-style edge controls aren’t going anywhere.

The Ancient-CVE Problem Isn’t Getting Better

Unit 42’s latest writeup on CVE-2023-33538 is a depressing read if you’ve been in this business long enough. TP-Link routers with a command injection bug disclosed in 2023 are still being rolled into Mirai botnets in 2026. The payloads are textbook — wget a dropper, execute, join the swarm, start scanning for the next victim. Nothing clever. Nothing novel. It just works, because hundreds of thousands of devices will never see another firmware update in their operational lives.

Then there’s the Apache ActiveMQ flaw CISA added to the KEV catalog this week. Patched earlier in the month after sitting undetected for 13 years. Thirteen. Anyone running ActiveMQ is now in a race — and if history’s any guide, a meaningful percentage will lose it.

And over at SANS ISC, a guest diary on compromised DVRs reminded us where a lot of this botnet muscle actually lives. Not in fancy cloud infrastructure. In your neighbor’s driveway camera.

Why This All Lands on Your Firewall

Here’s the thread connecting these stories: the attackers hammering your SSH, RDP, and web admin panels right now aren’t sitting in a basement somewhere. They’re routing through thousands of compromised routers, DVRs, and IoT junk. That TP-Link router exploited via CVE-2023-33538? It’s now a proxy node brute-forcing your WordPress login. That DVR with default creds? Same story.

This is why brute-force protection has to happen at the network edge, and it has to happen fast. By the time a failed-login event reaches your SIEM, gets correlated, produces an alert, and some poor SOC analyst triages it, the botnet has moved on to a different IP from the same pool and tried another 10,000 passwords. You cannot out-human this problem. Automated IP banning is the only economically viable answer for the volume of garbage hitting internet-facing infrastructure.

The Lumma + Sectop RAT Angle

Pair the botnet-brute-force reality with the Lumma Stealer infection chain SANS documented this week — dropping Sectop RAT (ArechClient2) as a follow-on payload — and you see the full kill chain. Compromised edge device provides anonymized brute-force infrastructure. Successful credential theft leads to initial access. Infostealer harvests everything of value. RAT gets planted for persistence. Rinse, repeat.

Every one of those stages has an IP-reputation signal attached to it. C2 callbacks. Data exfiltration endpoints. The brute-force origin itself. A decent threat-intel feed plus automated enforcement will stop most of this at the door.

Don’t Forget the Patching Catch-22

Microsoft’s April updates are putting some domain controllers into reboot loops. Which is exactly the kind of thing that makes sysadmins gun-shy about pushing patches fast. And that hesitation is what attackers feed on.

This is the permanent tension in defensive security: you’re asked to patch immediately, but the patches sometimes break production. So you test. Testing takes time. During that window, every internet-exposed service is a potential entry point. Edge-level controls — IP banning, rate limiting, geofencing where it makes sense — are what buy you that time without getting popped.

If you can drop 95% of hostile traffic before it ever reaches an unpatched service, you’ve meaningfully changed the math on when you have to patch versus when you can afford to test properly.

What You Can Do

Pragmatic steps, in the order they’ll give you the biggest return:

• Inventory your edge exposure. Know what’s internet-facing. Not what you think is facing the internet — what actually is. Run an external scan from outside your network. You’ll find things.
• Automate IP banning on authentication endpoints. SSH, RDP, SMB, web admin panels, mail. If a source IP fails auth repeatedly, it should be blocked within seconds, not minutes. Manual response cannot keep up with botnet volumes.
• Subscribe to a threat-intel feed for proactive blocking. Known-bad IPs shouldn’t get to knock on your door at all. This is where a managed solution beats a homegrown script — the feed has to stay current.
• Segment your IoT and legacy gear. Those TP-Link routers and DVRs in the Unit 42 report? Some of them are on corporate networks. Put them on their own VLAN with strict egress rules so when — not if — they get compromised, they can’t pivot.
• Prioritize KEV catalog CVEs. CISA’s Known Exploited Vulnerabilities list is where patching urgency actually lives. ActiveMQ is on it now. Treat it like it’s on fire.
• Log outbound connections. Most organizations obsess over inbound and ignore outbound. Infostealers and RATs are loud on egress if you’re watching.

If you’re running Windows servers or Linux edge boxes and you don’t have automated brute-force protection in place, IPBan Pro handles this specifically. Real-time IP banning, curated threat-intel feeds, multi-server coordination, and the kind of low-friction setup that means you’ll actually deploy it instead of leaving it on your to-do list for six months.

Frequently Asked Questions

Does IP banning still work when attackers use botnets with thousands of IPs?

Yes, but with caveats. Individual source blocking is still effective because most botnet nodes are cheap — once one is burned, attackers move on. Combining local detection with shared threat-intel feeds magnifies this effect, because an IP burned against one target is blocked proactively across everyone subscribed to the feed.

How does IPBan Pro differ from a basic fail2ban setup?

Fail2ban is fine for a single Linux box. IPBan Pro handles Windows and Linux, coordinates bans across multiple servers, integrates curated threat-intel feeds for proactive blocking rather than purely reactive, and includes a management UI so you’re not living in config files. For any environment beyond one server, the operational difference is significant.

Should I patch CVE-2023-33538 on consumer TP-Link routers on my network?

If a firmware update exists for your model, install it immediately. If not — and many affected models are end-of-life — replace the device. Segmenting it on an isolated VLAN is a short-term mitigation, not a long-term fix. Compromised consumer routers are one of the most common sources of brute-force traffic globally.

Sources

• A Deep Dive Into Attempted Exploitation of CVE-2023-33538 — Unit 42
• CISA flags Apache ActiveMQ flaw as actively exploited — BleepingComputer
• Microsoft: Some Windows servers enter reboot loops after April patches — BleepingComputer
• Lumma Stealer infection with Sectop RAT (ArechClient2) — SANS ISC
• Guest Diary: Compromised DVRs and Finding Them in the Wild — SANS ISC