Ructions at DD.com

by Diane Duane
Viruses and a computer

Some of you will already have noticed that something unusual is afoot, as the main website at DianeDuane.com is currently showing its “down for maintenance” page, and being a bit vague about when it’ll come up again.

Briefly: This is because some site visitors over the last couple of weeks have reported, on trying to access one page or another at the site, being shown “Cloudflare pages” that are trying to get them to input their user info in order to proceed to view whatever page they were trying to view.

These Cloudflare pages are fakes—the result of an injection into my site by people trying to load malware onto your computer. Apparently this is an exploit that has been in the wild for a couple of years now, and has now turned up on my own turf. (There’s a good description of the exploit here: it seems primarily to target Windows machines. I’ve cut-and-pasted it below. …And thanks also to @peregrine57 over at Bluesky for helping me get a handle on this.)

How did this nasty thing get into my site? At this point it’s tough to tell. My domain has been around for a good while, and along the line it’s not at all unlikely that one or another of its WordPress site’s security apps has aged out or been somehow compromised. The point at the moment is to make this behavior stop. (And just a note: should you manage to access a page at DianeDuane.com and be presented with what looks like a Cloudflare page, DO NOT CLICK ON ANY OF ITS LINKS OR GIVE IT ANY OF YOUR DATA, as that’s how this exploit loads malware onto your machine. My own site does not use Cloudflare, and never has. 

When a site’s as old as mine is, it wqould be possible to spend a WHOLE lot of time I would never get back trying to track down the exact spot (or spots) that had been compromised. In the shorter term, the best way to go seems to be this:

As a result, for the next week or so the DD.com site will not be operating as usual. I don’t want to get into too much detail (so as not to make matters easy for the people responsible for this attack), but in a week or so everybody should be able to access the site and find all the data that was previously there, though with a somewhat newer and shinier look-and-feel.

This blog, too, will be removed from the server where for a long time it’s been based, and will be moving to a new address. (It’s about time it had its own domain, anyway…) The new addy will feature prominently at the restored DD.com site (and have a 301 redirect installed as well), so don’t worry about missing anything going on over here. 🙂

At any rate: My apologies to everybody for the (hopefully) brief period of disruption that’s about to begin. (eyeroll) This isn’t how I imagined the rest of this week was going to go…

Never mind. Onward! (And don’t look right at the nukes…) 😅

***

From user Boring_Ocelot_3457 at the Reddit page:

Good catch backing out – that clipboard step is exactly where the attack actually triggers.

From what we’ve seen (we dealt with a similar case few days back), that redirect page usually isn’t coming from ads. In most cases, it’s because the site itself is compromised.

Attackers typically:

  • Inject malicious JS into the site (or modify existing files)
  • Hook into page load / random routes / referrers
  • Then selectively redirect users to a fake Cloudflare verification page

That “legit feel” is intentional – they mimic Cloudflare Turnstile almost perfectly to lower suspicion.

In our case, even a static HTML site was hit, which means the compromise wasn’t plugin-based but likely:

  • Hosting / FTP credentials leaked
  • cPanel or deployment access compromised
  • Or a third-party script inclusion got poisoned

Ads can be a vector (malvertising), but those usually open in new tabs or iframes.
A full-page Cloudflare-style redirect on a previously trusted site is more often:
server-side injection or client-side script compromise

The clipboard trick is the real payload delivery — it tries to get you to run a PowerShell command manually, which is why traditional security tools don’t always flag it.

You did the right thing by checking the clipboard — most users wouldn’t catch that.

You may also like

Leave a Comment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt out if you wish. Accept Read More