WordPress problem fix
Most agencies clean a hacked site, then wait for it to break again. We feed every incident back into a shared IOC list so the next site catches the attack before it lands.
An Indicator of Compromise (IOC) is a forensic fingerprint — a filename, file hash, regex pattern, user-agent string, or outbound IP — that, if it appears on a WordPress site, almost certainly means the site is compromised. Most WordPress maintenance shops do not keep an IOC list. They clean each hack from scratch, miss the persistence layer, and the site reinfects. We run the opposite playbook: every incident across our 30+ site fleet feeds a shared IOC moat. New site joins the fleet, the integrity monitor runs the full IOC list against it within 60 minutes, and any match triggers an alert before the attacker activates the payload. The list below is the live 2025-2026 IOC set we track — filenames, paths, regex strings, malicious user-agents, and known C2 endpoints. Use it on your own site if you maintain one yourself.
If any of these match, you are on the right page.
You clean a hacked WordPress site, and 24-72 hours later the same indicators reappear
Wordfence or Sucuri scans return clean but Search Console keeps reporting injected URLs
You manage multiple WordPress sites and have no shared baseline for what 'normal' looks like
A new client site joins your fleet and you have no fast way to tell if it is already compromised
You suspect a hack but the only tooling you have is a signature scanner
Signature scanners look for known malicious code patterns from public databases. Bespoke malware, freshly-modified payloads, and host-specific persistence layers (mu-plugin loaders, trojanized core files, malicious .htaccess rules) usually have zero signature hits on day one. An IOC list catches them by filename, path, and behaviour — not by code content.
Attackers rotate filenames and paths every 60-90 days. The 0wp-security.php family from 2024 became mu-loader.php and 8-char random names by mid-2025. The August 2025 UK agency hack introduced the /wp-json/spam/* and xmlrpc.php injection pattern that did not exist in 2024 lists. A static IOC file is dead within 6 months — ours is updated after every incident.
Yes. The most effective IOC checks are a daily find + grep against a known list — no SaaS required. We use a 60-line bash script that runs nightly via cron on every site we maintain. Costs nothing, catches more than most paid scanners.
The real method, in the order it works.
Pull the current IOC list (we publish ours to clients on request — message us your domain).
Run filename checks: find wp-content/mu-plugins/ wp-content/uploads/ -type f \( -name '0wp-*' -o -name 'mu-loader*' -o -name '.cache.php' -o -name 'wso*.php' \) — any hit is high-confidence malicious.
Run content regex checks against wp-blog-header.php, wp-load.php, wp-settings.php, and every .php file modified in the last 30 days. Look for base64_decode + eval, gzinflate + str_rot13, assert + variable, or file_get_contents on a remote URL.
Run database queries: SELECT * FROM wp_users WHERE user_login REGEXP '^(wp-admin|admin[0-9]+|adminerlzp|wpsupport)$'; SELECT * FROM wp_options WHERE option_name LIKE '%fwp%' OR option_name LIKE '%spam%'; any hit is investigation-worthy.
Run outbound traffic check: tail -n 1000 server access log + reverse-DNS any IP your server initiated outbound HTTP to in the last 24 hours. Russia/China C2 hits, Tor exit nodes, or anonymous VPS IPs are all flags.
Schedule the full IOC sweep nightly via cron. Email-alert on any match. Treat zero matches as success, not as 'I forgot to run it'.
After every cleaned incident, add the new IOCs (filenames, regex, IPs, user-agents) to the master list. The moat only works if you keep widening it.
Real fix, from our work
Our IOC list started at 14 entries in early 2024. It is now at 187 entries in mid-2026, every one of them added after a real incident on a site we either manage or were called in to forensically audit. When the August 2025 UK agency network hack went live, three of the 30+ sites in our fleet caught the injection within 90 minutes — not because Wordfence flagged it, but because the IOC sweep noticed /wp-json/spam/* paths in the access log that matched a regex we had added 11 weeks earlier from an unrelated incident. We cleaned the three sites before they were indexed by Google. The other 27 sites we managed were not on the same hosting tenant and never got hit. The fleet-wide IOC moat turned a network-wide incident into a 90-minute event for us instead of a 6-week event.
Written by Ali Yasin Jatoi
Founder of WebCare Studios. Ali has worked with WordPress for more than 10 years, including managing a fleet of 150+ sites with WP-CLI automation for updates, security cleanup, and malware removal. He has hands on experience across major hosts including Cloudways, A2 Hosting, Hostinger, and Bluehost.
Site down, hacked, or broken checkout gets a senior engineer within 4 hours. No ticket queues, no bots.
Flat quote up front. If we cannot get you back online, you do not pay. Risk sits with us, not you.
We work on a snapshot first and never touch your live database until the fix is verified safe.
We run a fleet of WordPress sites every day. The errors you are seeing are ones we have closed hundreds of times.
No. Wordfence and Sucuri are signature scanners — they match file content against a database of known malicious code. An IOC moat matches filenames, paths, database rows, regex patterns, and network behaviour. They are complementary. We run both. The IOC sweep catches what signatures miss and vice versa.
Partially. The 30-40 most distinctive IOCs we keep private — publishing them would let attackers rotate filenames within hours. The general patterns (eval+base64, file_get_contents on remote URLs, suspicious admin usernames, common malicious paths) are in the fix-steps above and are safe to act on without our list.
Roughly 1 false positive per 60-90 days per site, almost always from a legitimate plugin using base64 or eval for license validation. We whitelist by file hash, not by filename, so a single false positive does not become a permanent blind spot.
Yes. The whole approach is just: keep a list of known-bad filenames and patterns, scan nightly, alert on hits. A single site running this is dramatically safer than a single site relying on signature scanning alone.
It is included in every maintenance plan we run — Reactive Care, Proactive Care, and Fleet Care all get the same nightly IOC sweep. We do not sell it standalone because the value compounds with everything else we do (file-integrity monitoring, 11-minute response, immutable backups).
Two fields. Email and your URL. A senior WordPress engineer reads it within minutes and replies on email and WhatsApp with what is wrong and what we will do next.
Real proof and field guides tied to "IOC moat: WordPress hack fingerprints we track".