Most small business owners think about their website like this: it sits on the internet, people visit it, maybe they fill out a contact form. If it loads, it’s working. If it doesn’t load, it’s broken.
Here’s a third state most people don’t think about: the site loads perfectly, looks completely normal, and is silently serving malware to every visitor.
I just spent three days cleaning up a website in exactly that state. The owner had no idea. Their paid security scanner said the site was clean. Visitors mostly saw nothing wrong. But behind the scenes, the site was acting as a recruiting tool for a known cybercrime group whose business is selling initial access to ransomware operators.
This post is about how that happens, how to tell if it’s happening to you, and what to do about it. If you run a WordPress site for your small business — or you know someone who does — read on.
What I found
The site was a small engineering firm’s WordPress install. Hosted on a reputable provider. Had a security scanner running. Used a popular page builder. Looked exactly like the thousands of other small business WordPress sites you’ve seen.
When I started looking, I found:
- A malicious JavaScript was loading on every page, pulled from a domain made to look like a real analytics service. The script’s job: silently profile every visitor and selectively serve a fake “your browser is out of date — click here to update” prompt to high-value targets. The fake update, of course, drops malware.
- A hidden administrator account in the WordPress database that didn’t appear in the user list. The malicious code was actively filtering it out of any query, decrementing user counts so totals matched, and re-creating the account on every page load if anything tried to remove it.
- A Linux executable and a Perl reverse-shell script sitting in the theme directory, both dated to the day the site was originally built five years earlier. These weren’t added during a recent breach — they were there from day one. The site shipped compromised.
- A Russian-language Bash dropper designed to scatter 50 small malware binaries across the hosting server’s writable directories, run them under randomized names, and exit. Forensic evidence from the host’s own monitoring logs showed those binaries had actually been running on the server for about three weeks during summer 2025.
- A PHP remote-code-execution backdoor smuggled inside a ZIP file disguised as a theme template, giving the attacker the ability to run arbitrary commands via specially-crafted web requests.
That’s not “a website with malware.” That’s a layered, professional compromise by multiple actors over a span of years.
Who’s behind this
The most recent layer was attributed via the network gateway’s intrusion detection system to a threat actor known as TA569, also called SocGholish or “FakeUpdates” depending on which security vendor you ask. Microsoft tracks them under the name “Mustard Tempest.”
TA569 doesn’t deploy ransomware themselves. Their business is more interesting than that — they’re an initial-access broker. Here’s how they make money:
- They compromise small business websites at scale, usually via plugin vulnerabilities, stolen admin credentials, or supply-chain attacks against widely-used WordPress add-ons.
- They inject a JavaScript “Traffic Distribution System” — a small piece of code that runs in every visitor’s browser, fingerprints them (IP location, browser, OS, language, time of day, prior cookies), and decides whether they’re a high-value target.
- For targets that match their profile — typically US-based Windows desktop users on corporate-looking networks during business hours — the script displays a convincing fake browser update prompt. Anyone who clicks “yes, update my browser” downloads malware to their machine.
- They sell that established foothold inside the victim’s computer to ransomware operators. Ransomware groups documented as buying access from TA569 include Evil Corp, BlackCat/ALPHV, and Clop.
The math from their perspective: compromise thousands of low-value small business websites, use them as bait, sell the catch to actual ransomware crews. From the small business owner’s perspective, your website is a recruiting tool you didn’t sign up to run.
Why typical security scanners miss this
The site I cleaned up had a paid security scanner running. It reported clean every day. Most file-based scanners work like this:
- They check the PHP files on your server against a database of known malware signatures
- They look for obvious patterns: base64-encoded payloads, eval() chains, well-known webshell filenames
- If your files don’t match anything in the database, you get a green checkmark
TA569’s approach defeats this. The malicious code on YOUR server is just a one-line script tag that says “load some JavaScript from this other domain.” To a file scanner, that one line looks like an ordinary analytics tag, indistinguishable from Google Analytics or Facebook Pixel. The actual harmful code lives somewhere else entirely — on a server the attacker controls.
To catch this, you need either:
- Network-level monitoring that watches the connections coming out of visitor browsers and flags lookups to known-malicious destination domains
- Behavioral inspection that actually executes the page in a sandbox and sees what the JavaScript does
- DNS reputation feeds that warn when your site is asking visitors to talk to a known threat-actor’s infrastructure
Most small business security tools don’t do any of these.
How to tell if your site is compromised
A few practical checks anyone can do today:
1. Use Google’s Transparency Report. Visit transparencyreport.google.com/safe-browsing/search and paste your domain in. If Google has flagged it, you’ll see a warning. If you’re not flagged, that doesn’t prove you’re clean (Google misses things too), but a flag is a strong signal.
2. Run Sucuri’s free SiteCheck. sitecheck.sucuri.net — paste your URL, get a scan. Sucuri specifically scans for the TA569 pattern and related fake-update injections. Their free tier is decent at catching what file-based scanners miss.
3. View Page Source on your homepage. Right-click any page → “View Page Source” (Ctrl+U). Look at the HTML in the <head> section near the top of the file. You should recognize most of what’s there (Google Analytics, your fonts, your theme’s CSS). If you see a <script async src="..."> pointing at a domain you don’t recognize — especially one with “analytics” or “content” in the name that you didn’t intentionally install — that’s a red flag worth investigating.
4. Check your WordPress admin user list. Log into wp-admin → Users → All Users. Note how many administrators are listed. Compare against what you remember. If there’s an extra admin account, especially one named something generic like “admin”, “root”, “support”, or “user”, investigate. (Caveat: if your site has the hidden-admin backdoor I described above, the rogue user won’t appear in this list — only a direct database query would show it.)
5. Look at your network traffic if you have a managed router. If your business has a UniFi gateway, a Fortinet firewall, or another router with intrusion prevention features, check the security logs over the past month for any blocked DNS lookups when visiting your own website. If your gateway is blocking outbound connections to suspicious destinations every time you load your site, your site is calling those destinations.
What to do if you find something
Don’t panic, but don’t ignore it either. A compromised website serving malware is a real legal and reputational exposure — not just for you, but for any visitor who clicks through a fake update prompt and gets infected.
The short version:
- Don’t try to “clean” the site by removing the visible malicious code. Modern WordPress compromises are almost always multi-layered. Removing the part you can see leaves the persistence mechanisms in place, and the malicious code comes back within hours or days. The right approach is to rebuild the site from clean, official components while preserving only the safe content (your text, images, page designs, which live in the database and uploads folder).
- Rotate every credential associated with the site: hosting account, FTP, database, WordPress administrators, WordPress secret keys. Especially the secret keys — rotating those invalidates any stolen authentication cookies the attacker is currently using.
- Audit the people who have ever had access to the site. The case I cleaned up included backdoors planted on the original site build, five years ago, by a freelance contractor hired through a popular freelance marketplace. Whether the contractor planted them intentionally or installed bundled “nulled” (pirated) plugins that came with backdoors pre-installed, the result was the same: the site shipped compromised on day one. Any credentials or access shared with past contractors should be cycled out.
- After cleanup, harden the basics: modern security headers, properly configured email authentication (SPF, DKIM, DMARC), aggressive Wordfence configuration with two-factor authentication required for admins, file-execution restrictions on the uploads directory. None of these are advanced — they’re industry-standard hygiene that most small business sites skip.
- Set up better monitoring. If you can afford the upgrade, Wordfence Premium ($119/year) adds real-time threat intelligence from their researcher network — they would have caught the TA569 destination as malicious immediately. A network-level intrusion detection system on your business router is another good investment.
The bigger lesson
The freelance contractor situation is worth a moment of reflection. The site I cleaned up was built five years ago by someone hired through Upwork. The owner never thought about that arrangement again — site was delivered, contractor moved on, site kept running. Five years later, the backdoors from that build were sitting there waiting, and eventually got exploited.
This is unfortunately a common pattern in the budget freelance market. Contractors building cheap WordPress sites often:
- Use “nulled” (pirated) versions of premium plugins and themes that come with backdoors pre-installed
- Install their own “support” backdoors so they can come back to the site later without asking
- Use the same admin credentials across every client site they build
- Don’t follow security best practices, often because the price they’re being paid doesn’t budget for that
If you’re hiring someone to build or maintain your site, ask them directly:
- Where are you sourcing the themes and plugins you’re using? (Official wordpress.org, official paid vendors, or third parties?)
- Are you using your own licenses or mine? (If theirs, you’re freeloading and you lose access if they stop paying)
- When the project ends, will you delete your access? (Or do you keep an admin account “just in case”?)
- What’s your process for security after launch? (Updates, monitoring, scanning)
If the answers make you uncomfortable, find someone else.
If you’d like a professional review
If you’re reading this and wondering whether your own site might have something similar going on, that’s a reasonable question to ask. I do website security reviews and incident response work for small to medium businesses through my company, I am Geek. We work with Bluehost, GoDaddy, SiteGround, WP Engine, and most other common hosts — and we do this kind of work for clients regularly.
A baseline external review is typically a few hours of work and tells you whether your site is currently compromised, what the email authentication situation looks like, and whether your hosting configuration has any obvious gaps. If something IS wrong, a full cleanup and hardening engagement is similar to what’s described above.
Reach out at brian@iamgeek.com if you’d like to talk.
Stay safe out there.
— Brian I am Geek
Leave a Reply