WooCommerce Credit-Card Skimmer Removed in 6 Hours (Magecart Case Study)

The challenge

The store owner noticed a spike in chargebacks and customer complaints of fraudulent charges within days of ordering. On inspection, a heavily obfuscated JavaScript payload was being appended to the checkout page from the theme footer, capturing card number, CVV, expiry, and billing address fields in real time and streaming them to an attacker-controlled domain. Google Search Console had already flagged the site as deceptive, browser warnings were appearing in Chrome and Firefox, and the payment processor was threatening to suspend the merchant account. The attackers had also left three PHP backdoors and modified 14 core, theme, and plugin files to survive a superficial clean.

Our approach

1. 01Took the site offline behind a branded maintenance page and captured a full forensic snapshot (files + database + web-server logs) before touching anything — nothing is modified until we have a rollback point.
2. 02Ran a byte-level diff of WordPress core, the active theme, and every plugin against clean vendor sources; identified 14 modified files and 3 unauthorised PHP uploads in wp-content/uploads and mu-plugins.
3. 03Located the Magecart skimmer entry point in the theme footer and traced its loader through an obfuscated wp-includes/js/wp-embed.min.js modification back to a compromised admin account created 11 days earlier.
4. 04Removed the skimmer payload, deleted all backdoor files, restored modified core files from clean checksums, and manually reviewed every recently-modified file in the last 30 days for secondary payloads.
5. 05Rotated every admin, editor, database, FTP/SFTP, hosting-panel, and WordPress salt credential; revoked all active WooCommerce REST API keys and re-issued only the two keys actually in use by the fulfilment integration.
6. 06Hardened wp-admin with two-factor authentication, disabled file editing (DISALLOW_FILE_EDIT), locked down XML-RPC, restricted /wp-admin to a country allow-list, and added a Content Security Policy blocking every third-party script origin except the payment gateway and analytics.
7. 07Installed and tuned Wordfence Premium with real-time IP blocklist, malware scanner on 6-hour cadence, and login rate-limiting; added a server-level ModSecurity ruleset for WooCommerce checkout endpoints.
8. 08Submitted the site for reconsideration to Google Safe Browsing and monitored server-side + client-side (CSP violation) logs for 48 hours before formal handoff to the client.
9. 09Delivered a written post-incident report covering root cause, timeline, files touched, indicators of compromise (IOCs), and a 30-day monitoring plan with weekly integrity re-scans.

The result

Checkout was fully restored the same business day the site was handed to us. The Google "deceptive site" warning was lifted within 24 hours of the reconsideration submission. In the 90+ days since delivery, integrity scans have detected zero re-infections, zero unauthorised file modifications, and zero suspicious admin login attempts that bypassed the new controls.

Business impact

Between the first customer chargeback report and the fix, the store lost an estimated $12,400 in refunded fraudulent orders and blocked purchases. Cart abandonment jumped from a normal 68% to 94% during the four days the Google warning was active. Within 72 hours of the fix, conversion rate had recovered to baseline and the merchant account suspension threat was withdrawn once the payment processor received the incident report.

Prevention checklist — how we keep this from happening again

• Enforce two-factor authentication for every user with edit-level capability or higher — no exceptions for the site owner.
• Set DISALLOW_FILE_EDIT to true in wp-config.php so a compromised admin account cannot push malicious code via the theme/plugin editor.
• Run daily malware scans (Wordfence, Sucuri, or ImunifyAV) with alerting on any change to core files or wp-content/mu-plugins.
• Deploy a strict Content Security Policy that whitelists only your payment gateway, analytics, and CDN domains — a Magecart script cannot phone home if the browser blocks the outbound request.
• Rotate WordPress salts, database, and REST API keys on any staff departure or suspected exposure — treat credentials as short-lived, not permanent.
• Keep an off-site, versioned backup with at least 30 days of retention so you can compare against a known-clean state during any incident.
• Subscribe to a WordPress security feed (Patchstack, WPScan) and patch high-severity vulnerabilities within 48 hours of disclosure.

Tools & controls used

• Wordfence Premium
• Sucuri SiteCheck
• WP-CLI
• ClamAV
• ModSecurity
• Cloudflare WAF
• Content Security Policy
• Google Search Console