We Publish a Blocklist. It Does Not Protect Our Own Website.
Cloudflare raised a low-severity flag on our account this week: forty-six login attempts against dugganusa.com carrying username and password pairs that appear in known breach corpora. Credential stuffing, in other words, with credentials somebody already stole from somewhere else.
We went to look, expecting either nothing or something embarrassing. We got both, and the embarrassing part is not the attack.
The attack is nothing
All forty-six requests went to one path: /wp-login.php. That is the WordPress login page. We do not run WordPress. There is no login there to stuff credentials into, and none of the requests reached our origin at all — Cloudflare answered every one of them.
This is the background radiation of the internet. Botnets spray breached credential pairs at every domain they can resolve, hoping to find a WordPress install with a reused password. If you own a domain, this is happening to you right now. It is not targeting, it is weather.
So: no incident, nothing to disclose, nobody to notify. We could have closed the tab.
The embarrassing part
We looked up the four source addresses in our own threat feed, the one we publish for anyone to download.
We already had all four. Two of them carry an AbuseIPDB confidence of 100 — about as unambiguous as a reputation score gets. They were sitting in our corpus, dated, scored, available to any subscriber who pulls our blocklist.
Our edge blocked zero of them.
Not one. Every one of those requests sailed past indicators we ourselves publish, on the domain whose name is on the feed.
It comes down to who owns DNS
That is the whole thing, and it is simpler than the security industry usually makes it.
A DNS record decides which machines answer for your name. Not your firewall, not your WAF vendor, not the rules you wrote. The record. Whoever controls it controls which infrastructure is in the request path, and therefore which of your security controls a request encounters on the way in.
Lose the record and everything downstream becomes decoration. Your blocklist is still correct. Your rules still work. They are just not on the road the traffic takes, and no amount of tuning them changes that, because the failure is one layer above the thing you are tuning.
Our website's front door is not ours.
Like a great many companies, our marketing site runs on a hosted website builder. That platform serves the site through its own CDN, using its own certificate, on our domain name. Our apex and our www hostname resolve to the platform's infrastructure, not to ours. Our security layer — the edge rules, the IP blocklist, the shield we wrote and the feed we publish — sits in front of our application origin, which lives somewhere else entirely.
So the request path for a reader visiting our blog never passes through our own controls. It cannot. Our controls are not on that road.
We knew this in the abstract. It has been written down in our own notes since the platform's setup wizard took over the apex on October 21. What we had not done was join it to the consequence: that our blocklist, the actual product, does not defend the property most people associate with us. Two things were true in separate places, and nobody put them in the same sentence until a credential-stuffing alert made us look.
This is not a hosted-platform problem
It would be easy and wrong to make this about the vendor. The platform is doing exactly what it advertises. The gap is architectural and it is extremely common:
Your corporate site is on a hosted builder. Your docs are on a documentation host. Your status page is on a status-page service. Your careers page is on an applicant tracking system. Every one of those is a subdomain or an apex record of your domain, serving your brand, and not one of them is behind the WAF you bought, the rules you wrote, or the blocklist you subscribe to.
Your security layer protects the hosts you still control. The question nobody asks is which of their hostnames those actually are.
So here is the five-minute version. It is a DNS audit, not a security audit, and it costs nothing:
Open your zone file and read every record. Certificate transparency logs will fill in the hostnames you forgot. This is the inventory, and most organizations have never actually looked at theirs.
For each record, ask who it points at. A CNAME to a vendor is a decision — it hands that hostname's request path to that vendor. Not wrong, often correct, but it is a decision somebody made, frequently years ago, frequently by clicking a setup wizard, and usually nobody wrote down what it cost.
Then verify in the logs, not the config. Pick one of those hostnames and search your WAF for its requests. If they are not there, your WAF is not inspecting that hostname, whatever your dashboard claims. That is the entire test, and it is the one we failed.
The reason to start at DNS rather than at the firewall is that DNS is upstream of every control you own. You can audit rules all day and never discover that the traffic was never routed through them.
What we are doing
We recorded the four addresses as first-party observations, which turned out to be harder than it should have been. Our own ingest API would not accept a source label that said the evidence was ours: the only accepted prefixes described records as manual batches or research imports — somebody else's work, re-filed. The read side of the same system has recognized a first-party label for weeks. The write side never did.
That is its own small lesson. We have a documented rule against laundering other people's feeds as our own observations, and we enforce it carefully. We had never noticed the rule running backwards: an API that made our own receipts the hardest thing in the system to write down. It is fixed, narrowly, so it cannot become a back door for relabeling third-party data as ours.
Two of the four we scored to block. The other two we deliberately scored below the threshold at which our default feed publishes, because each was a single request from a consumer broadband address — far more likely a compromised home machine than an attacker's own infrastructure. Blocking a victim because they were used once is how blocklists hurt people. Those records exist for hunting, with the reason written into the row, and a subscriber who wants them can lower their confidence floor and have them.
The seam itself is harder and we have not closed it. Getting our own controls into the request path for our own site is a real piece of work, not a checkbox, and we will write about it when it is done rather than when it is planned.
The uncomfortable summary
A threat intelligence company got sprayed with stolen credentials, had the attacker's addresses in its own published feed, and blocked none of them — because its own website is behind somebody else's front door.
The alert that found it was rated Low, and it was right to be. The attack was worthless. What it illuminated was not.
If you take one thing, take this: an indicator you hold and an indicator you act on are different numbers, and almost nobody measures the gap between them. Ours was four out of four, on our own name.
And if you take a second thing, take the reason, because it is the one that generalizes past us. It was not a misconfigured rule or a missed alert or a vendor failing. It was a DNS record. Who owns the record decides which infrastructure answers for your name, and therefore which of your defenses exist in the request path at all. That is upstream of every security product you have ever bought.
Check your zone file. It is the cheapest security review available, and almost nobody does it.
Our feed is at analytics dot dugganusa dot com slash api slash v1 slash stix-feed slash ips.csv, free with a registered key, and this is correction number twenty-seven we have published this year. We guarantee a twenty-eighth exists that we have not found yet — call it the five percent, and we would rather you heard it from us.
Her name was Renee Nicole Good.
His name was Alex Jeffery Pretti.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=we-publish-a-blocklist-it-does-not-protect-our-own-website
Comments