img

A Voice That Shouldn’t Exist

The client, the director of a small nonprofit, contacted me with a simple but unsettling report: when they visited their own organization’s website, an audio message began playing. A robotic voice warned them that their computer was corrupted and that they needed to call a support number immediately.

They did exactly the right thing: they didn’t call the number, they didn’t click anything…they just closed the browser and reached out for help.

But they were understandably alarmed. This was their organization’s public-facing website, and if they were seeing this, their donors, their board members, and anyone Googling their name could be seeing it too.

Their first instinct was that their site had been hacked; that’s what most people would assume, and in many cases, it would be a reasonable guess. But this investigation would lead somewhere different — somewhere that reveals a quiet, systemic problem hiding in the internet’s infrastructure that most website owners have never heard of.

Starting Where It Matters: What Is the Site Actually Serving?

Before I could reassure the client, I needed to verify what was actually happening…not what the browser displayed or what the client remembered seeing, but what the server was returning at the network level. That distinction matters, because browsers add layers (cached pages, extensions, JavaScript, etc) that can distort reality. I needed the raw truth.

I started by requesting the site’s HTTP headers directly.

The response was immediate and telling: a 302 Found redirect, pointing all traffic to /cgi-sys/suspendedpage.cgi. The server identified itself as Apache.

If you’ve spent time around web hosting, that path is instantly recognizable. It’s the default cPanel suspension handler—the page a hosting provider displays when an account has been disabled, usually for nonpayment, a terms of service violation, or simple abandonment.

I also checked the HTTPS version; the SSL certificate had expired. Together, these two findings painted a clear picture: this was a suspended hosting account, sitting on infrastructure that nobody was managing anymore.

But…a suspension page shouldn’t be playing scareware audio, so I pulled the full response body to see what was actually being served.

The Iframe

What came back was not a normal cPanel suspension page. It was this:

<html>
  <head>
    <title>Contact Support</title>
  </head>
  <body>
    <iframe src="http://iyfhshsp.com/?dn=referer_detect&pid=5POL4F2O4"></iframe>
  </body>
</html>

That’s it. No hosting provider branding, no “this account has been suspended” message, just a bare HTML shell wrapping a single iframe — a window into someone else’s content, loaded silently inside the page.

The domain in the iframe, iyfhshsp.com, is the kind of URL that tells you everything you need to know at a glance. It’s not a brand or a service. Rather, it’s a randomly generated string, purpose-built to be disposable and difficult to trace, and the URL parameters — referer_detect and a tracking ID — suggested this was part of a traffic monetization pipeline, routing visitors based on where they came from and how they arrived.

I conducted the entire investigation from the command line using curl — a tool that fetches raw server responses without rendering anything in a browser. This was deliberate. The iframe was loading content from an unknown third-party domain, and opening that in a real browser would mean allowing whatever scripts, redirects, or payloads it contained to execute on my machine. That’s not a risk you take during an investigation if you can avoid it.

This also explains a key discrepancy: the client heard audio warnings in their browser, but my raw HTTP requests returned only the silent HTML and iframe markup. A browser would have loaded the iframe’s contents, executed whatever JavaScript was waiting there, and played the scareware audio. Curl just showed me the skeleton…which was exactly what I needed to understand the mechanism.

To be absolutely certain the site’s own code wasn’t involved though, I requested the suspension handler directly and even forced the request through the server’s raw IP address with custom headers. Same result every time. The WordPress installation (whatever remained of it) wasn’t executing at all. No PHP was running, no themes, no plugins, no database queries. The content was being injected at the hosting layer, upstream of anything the client had ever built or controlled.

Following the Trail

I ran a WHOIS lookup on the iframe domain. It was registered through infrastructure associated with Confluence Networks Inc., a company based in the British Virgin Islands.

Confluence Networks is a name that comes up frequently in security research, and rarely in a positive context. They operate a network historically associated with domain parking monetization—the practice of serving ads or redirect content on unused or expired domain names. In 2013, a widely reported incident saw thousands of active domains, including properties belonging to LinkedIn, Fidelity, USPS, and Craigslist, accidentally transferred to Confluence Networks’ infrastructure when Network Solutions’ automated expiration process misfired. The domains began resolving to parking pages instead of their actual content.

That incident was an accident. But the infrastructure it exposed—the pipeline that catches expired, suspended, or abandoned domain traffic and redirects it for profit—is very much by design. And in the years since, that pipeline has gotten considerably more dangerous.

The Bigger Problem: When Infrastructure Becomes an Attack Surface

To understand what happened to this nonprofit’s website, you need to understand how the modern domain parking ecosystem works, and how it’s evolved from a minor nuisance into a genuine security threat.

When a domain name expires or a hosting account is suspended, the traffic doesn’t just disappear. People still visit the URL; search engines still have it indexed; bookmarks still point to it; old emails still contain links. That residual traffic has value, and an entire industry exists to capture and monetize it.

The traditional model was relatively benign: a visitor lands on a parked or suspended domain, sees a page full of keyword-targeted ads, and maybe clicks one. The domain owner (or the parking service) earns a few cents. Annoying, but mostly harmless.

That model has been replaced by something far more aggressive.

Modern domain parking increasingly operates on what the industry calls “direct search” or “zero-click” monetization. Instead of displaying ads and waiting for a click, the system automatically redirects the visitor (often through multiple layers of traffic brokers and advertising networks) to whichever destination is paying the highest bid for that particular type of traffic. The visitor never makes a choice;they’re simply routed, like a package through a sorting facility, to wherever the money leads.

And increasingly, where the money leads is somewhere malicious.

In December 2025, security firm Infoblox published research that quantified just how bad the situation has become. A decade earlier, studies had found that fewer than five percent of visits to parked domains resulted in exposure to malicious content. Infoblox’s experiments found that figure had flipped: over ninety percent of visits to parked domains now redirect visitors to scams, scareware, phishing pages, or outright malware.

The mechanics are deliberately opaque. Traffic is sold from the parking service to an ad network, which may resell it to another network, which sells it to an affiliate, which finally delivers the payload. By the time a visitor reaches the scareware page or the fake antivirus pop-up, there are so many intermediaries that no single entity can be held accountable. The parking company points to their Know Your Customer checks. The ad network points to their terms of service. And the malicious advertiser, buried under five layers of resellers, is functionally untraceable.

Why residential visitors see different content Infoblox's research revealed something particularly insidious: parked domains actively profile their visitors. Users connecting from VPNs, data centers, or non-residential IP addresses typically see benign placeholder pages — the kind that would pass a casual security scan. But visitors on residential internet connections, especially on mobile devices, get redirected through the full monetization chain, often landing on scareware or malware. This filtering is intentional. It keeps the malicious content invisible to researchers and security tools while maximizing exposure to real people.

The implications for small organizations are sobering. A nonprofit with a lapsed hosting account, a small business that forgot to renew its domain, a church that moved to a new website but never cleaned up the old DNS records…all of these become unwitting participants in a scam delivery network. Their visitors don’t know the organization has lost control. They see a familiar URL, they click, and they’re funneled into an ecosystem designed to deceive them.

This is exactly what happened to the client’s site.

The Full Picture

With the technical investigation complete, the situation was fully mapped:

The domain was registered at GoDaddy. The client had purchased it there and still owned it. But the domain’s nameservers (the DNS records that tell the internet where to send traffic) were still pointed at HostGator, a previous hosting provider. The HostGator account had been suspended, likely due to nonpayment or abandonment. And HostGator’s suspension infrastructure was serving a page that embedded an iframe loading scam content from a third-party monetization network.

The chain looked like this:

  1. A visitor types in the organization’s URL
  2. Their browser queries DNS, which returns HostGator’s IP address
  3. HostGator’s server recognizes the account is suspended
  4. Instead of a standard suspension notice, it serves an HTML page containing an iframe
  5. The iframe loads content from a domain associated with Confluence Networks
  6. The content delivered through the iframe is scareware — a fake warning designed to frighten the visitor into calling a phony support number or downloading malicious software

None of this involved the client’s website code. WordPress wasn’t running; no files had been modified; no credentials were compromised; the site hadn’t been hacked in any conventional sense. The scam content was being injected by the hosting infrastructure itself, exploiting the gap between where the domain pointed and what was actually there.

A Word About HostGator — and the Broader Pattern

I want to be precise here: I’m not suggesting HostGator is intentionally serving scam content to visitors of suspended accounts. What’s more likely is that their suspension page infrastructure, or the default behavior of their shared hosting environment, includes some form of traffic monetization for suspended accounts, and that the downstream monetization partners are funneling traffic into malicious networks.

This isn’t a problem unique to HostGator. As Infoblox’s research documents, the entire parked and suspended domain ecosystem has been co-opted by bad actors. Any hosting provider, registrar, or DNS service that monetizes traffic from inactive domains is potentially feeding visitors into the same pipeline. The specific intermediaries and brand names change but the underlying economics stay the same.

The uncomfortable truth is that there’s a financial incentive for hosting providers not to simply display a clean, static “account suspended” page. Residual traffic to abandoned accounts has monetary value, and the infrastructure to capture it already exists. When the downstream partners were serving harmless ads, this was a victimless arrangement. Now that over ninety percent of that traffic ends up on malicious content, what was once a harmless revenue stream has become a liability, but the industry hasn’t nothered to adjust.

The Pricing Conversation

Before any remediation work began, I laid out the possibilities for the client. Best case, this was a quick fix: log into GoDaddy, change the nameservers away from HostGator, and the scareware disappears. But that best case rested on a stack of assumptions. It assumed the site had been migrated to GoDaddy properly. It assumed the GoDaddy hosting plan was actually active. It assumed the DNS records on GoDaddy’s side were already configured correctly. If all of those things were true, the fix would take minutes and the site would reappear once the nameserver change propagated.

That’s a lot of “ifs” though.

So I explained to the client that if any one of them wasn’t true…if the hosting plan had lapsed, if the migration was never completed, if the DNS records were missing or misconfigured…then what looked like a five-minute fix would become a full hosting recovery project were I’d be troubleshooting a site that may never have been properly set up in the first place, on infrastructure I’d be seeing for the first time, for a client who wasn’t sure which provider had what.

So, the client asked if I could reduce my rate.

Now, I understand the impulse. But, the diagnosis I’d already performed was the part that actually mattered. I’d verified that the site wasn’t compromised, traced the scam content to its source, mapped the DNS ownership chain and identified the exact point where the fix needed to happen. I’d saved the client from chasing the wrong problem entirely; from paying someone to scan a WordPress installation for malware that didn’t exist, or from rebuilding a site that was never hacked, or from buying security tools that would have done nothing because the CMS wasn’t even running.

That’s what the rate reflects, not the time spent changing a DNS record, but the expertise required to know which record to change, why, and what to check when the obvious fix doesn’t work. The electrician who finds the fault in ten minutes and charges you for an hour isn’t overcharging you for ten minutes of work. They’re charging you for the twenty years of experience that made the ten minutes possible.

SUffice it to say, I didn’t lower my rate. I did however offer to start with the nameserver change, let the client see exactly what we were dealing with on the other side, and go from there. And I said if they wanted to stop at that point, or hand it off to someone else, that was completely fine. I also said if they found another provider giving them the same diagnosis at a lower price, I understood. I’m not here to nickel and dime anyone; I just can’t in good faith discount the work to make it feel proportional to the size of the final click.

What This Means for Your Organization

If you’re a small business or nonprofit reading this, the practical takeaways are worth internalizing:

Know where your DNS points. Your domain name, your hosting, and your DNS are three separate things, often managed by three separate providers. If any one of them falls out of sync you have a live vulnerability that requires no hacking whatsoever to exploit.

Suspension pages are not safe. There was a time when a “this account has been suspended” page was exactly that—a neutral placeholder. That assumption is no longer safe. Research now shows that the overwhelming majority of suspended and parked domains serve visitors malicious content through opaque advertising networks. If your site is suspended, you shouldn’t think of it as just being offline. It may be actively harming your visitors and your reputation.

Don’t leave orphaned infrastructure. When you move to a new hosting provider, update your DNS. When you stop using a service, close the account and redirect the domain. When you let a hosting plan lapse, change your nameservers to point somewhere you control, even if that’s just a clean “coming soon” page. The gap between “I stopped paying for this” and “this is no longer my problem” is where scammers live.

The scary pop-up probably isn’t what you think. If you or someone in your organization encounters a scareware warning (be they audio messages about corrupted computers, pop-ups demanding you call a number, fake virus scan animations, etc) the problem is almost never what the warning claims. Your computer isn’t infected (at least not by whatever the pop-up is describing). Close the browser, clear the cache and investigate the source, not the symptom.

A fast diagnosis isn’t a simple one. If a security professional identifies your problem quickly and tells you the fix is straightforward, that’s not a sign that the work was easy. It just means you hired the right person.


This engagement is ongoing. The technical diagnosis is complete, the remediation path is clear, and no evidence of compromise was found. The scam content will disappear the moment the client’s DNS is moved away from the suspended hosting infrastructure which, in the end, is the best possible outcome.


Related Reading