Holiday-level traffic. A thriving WooCommerce catalog. And then, suddenly, customers couldn’t check out.
That’s how our client, a large and well-established online retailer, realized something was wrong. Their checkout page began acting unpredictably: card fields flickered, strange duplicate iframes appeared, and the form quietly stopped accepting payments. Not knowing the cause, their team took the safest step they could — they disabled credit card payments entirely.
For an e-commerce business, shutting down your own checkout is the nightmare scenario. The store was open, customers were ready to buy, and something deep inside the site was quietly interfering with the most critical part of the process.
What happened next led us into one of the most layered, evasive, and surprising security investigations we’ve worked on. The skimmer we uncovered resembled techniques that the broader WordPress security community would only begin discussing weeks later. (It’s rare to catch something this early; we only realized the scope after pulling on the first thread.)
The First Symptom: Ghost Iframes on the Checkout
The earliest clue didn’t appear in the error logs or the code. It showed up in the browser during real customer sessions.
Some shoppers began reporting:
Duplicate iframes are sitting directly on top of credit card fields
Hidden input layers intercepting keystrokes
Check out behavior that changed from session to session
But when our developers opened Chrome DevTools or Firefox Inspector to investigate, the problem disappeared completely. The checkout looked clean. No strange frames. No injected code. No errors.
This wasn’t a glitch. It was intentional.
(It took a few rounds of “Why can’t we reproduce this?” before the pattern clicked.)
A Skimmer Engineered to Hide From Developers
As we later discovered, the attack included an anti-forensics technique that allowed it to run only when no one was watching. It shut itself off anytime it detected developer tools.
The script actively monitored the browser for:
The presence of debugging tools
Side effects triggered when DevTools attach
Changes in timing or layout calculations
Other subtle signals that someone was trying to inspect the page
If any of these signals appeared, the malicious code quietly refused to run.
This meant customers saw the attack, but developers didn’t. It also meant traditional debugging techniques wouldn’t help — because the moment you looked at it, the skimmer disappeared.
This behavior aligns with trends now widely reported: attackers are increasingly designing skimmers that behave differently depending on who is viewing the page. It’s a frustratingly clever tactic, and one that forces you to rethink old debugging habits.
Why Standard Malware Scanners Didn’t Catch It
The client had an excellent security stack:
Hosting-level malware scanning
A third-party security vendor
External monitoring tools
All helpful. All necessary. But none initially flagged the compromise.
Not because they failed — but because modern malware is designed to live where scanners don’t usually look. It can:
Hide in files that resemble legitimate plugins
Slip into database values that no plugin should control
Append itself to images, like PNG files, that appear perfectly valid
Disable itself when it senses investigation
This attack took advantage of every one of those blind spots.
And the longer we looked, the more it became clear this wasn’t a “single bad file” situation.
Stage 1: A Rogue “WooCommerce Filters” Plugin
Our first breakthrough came from an unusual database entry named:
woocommerce_filters_template
It contained a very long encoded string. No legitimate plugin was used in the environment.
That led us to a plugin in the filesystem with a name resembling a well-known filtering extension. Its header metadata looked entirely legitimate:
/**
* Plugin Name: WooCommerce Advanced Filters
* Description: Adds advanced product filters to WooCommerce.
* Version: 2.5.7
* Author: BeRocket
*/
But scrolling down revealed something very different.
This plugin:
Loaded the encoded database value
Decoded it via ROT13 and Base64
Wrote the decoded contents to a temporary PHP file
Executed that file with include
Immediately deleted it
Terminated all normal plugin execution with exit()
The decoded payload was a fully interactive webshell — essentially the attacker’s control panel — complete with:
Arbitrary PHP execution (eval())
System command execution (system())
A UI to upload new PHP files via base64
A styled HTML control panel user interface
This plugin wasn’t about filtering products. It was the attacker’s command center.
It was the first moment we realized we were dealing with a coordinated system, not a one-off compromise.
Stage 2: The Logo PNG That Wasn’t Just a Logo
Next, we traced the checkout iframe issues back to something unexpected: a file in the Media Library that looked perfectly normal.
/wp-content/uploads/YYYY/MM/cropped-logo-min.png
At first glance, it was a valid PNG:
Correct header
Proper image data
Valid IEND chunk
But right after the IEND marker — which should signal the end of the file — there was more data. Data that didn’t belong in a PNG.
Hidden there was an obfuscated JavaScript credit card–skimming script.
Once decoded and run (but only when DevTools weren’t open), it:
Injected invisible overlay iframes
Captured keystrokes from the credit card fields
Sent that data to a remote attacker-controlled server
This exact “malware hidden in PNGs” technique was later identified in a broader campaign. Our client just happened to be one of the early cases.
Stage 3: A Database-Backed Backdoor in a Theme Fonts Directory
Even after we removed the fake plugin and malicious PNG, reinfections kept appearing in unexpected places:
Cached PHP files generated by performance plugins
Drop-in directories
Export folders used by legitimate extensions
Even a suspicious index.php inside an image directory
That last one was significant. Image folders should never contain PHP files.
Inside one such file, we found code that:
Bootstrapped WordPress by dynamically locating wp-load.php
Constructed function names from hex values to hide intent
Loaded and decoded attacker-controlled payloads from a database table
Wrote temporary PHP files and executed them
Used a table, such as wp_linksmeta, as an encrypted storage mechanism
The attackers weren’t just injecting files. They were hiding code inside the database, allowing reinfection even after plugins were cleaned.
Together, these pieces formed a clear multi-tier architecture:
Tier 1: Rogue plugin + encoded database payload
Tier 2: Database-backed loader hidden in a theme directory
Tier 3: JavaScript skimmer hidden inside a PNG
Tier 4: Anti-debugging logic to avoid detection
This wasn’t a simple infection. It was a system.
And every time we peeled back one layer, another one was waiting.
How We Contained and Removed the Skimmer
Because this was a live, revenue-critical WooCommerce store, our response had to be swift, precise, and disruption-free.
There wasn’t room for trial and error. Every move had to count.
1. Immediate Containment
Disable credit card payments
Capture forensic backups
Scan for active payloads
2. Eliminate All Known Backdoors
Remove the counterfeit plugin
Delete the encoded database option (and alert if it returns)
Purge suspicious cache files
Remove malicious PNGs and look-alike duplicates
Audit core files for suspicious wrappers
3. Identify and Remove Persistence
Locate disguised database tables
Remove encoded payloads
Audit directories where PHP should never appear
Remove loaders hidden inside theme assets
4. Partner With Hosting and Security Vendors
Share decoded samples for future detection
Validate clean scans
Clarify which directories were excluded from backups
5. Harden the Environment
Rotate all passwords and salts
Enforce 2FA for all admin accounts
Remove unused SFTP/SSH accounts
Add additional security headers and content policies
Tighten plugin and theme management practices
After the final persistence layer was removed, the reinfections stopped. Checkout behaved normally. No more ghost iframes. No more hidden code reviving itself.
It’s the kind of quiet relief you only get after days of chasing something that doesn’t want to be found.
Lessons for WooCommerce Stores and Enterprise WordPress Teams
1. Modern malware blends in
It often hides inside:
Fake PNGs
Innocent-looking database entries
Plugins with believable names
Theme asset folders
2. File-only scanning isn’t enough
If the malware lives in the database, scanners won’t catch it.
3. Cache files exaggerate symptoms
They often contain copies of malicious code, but aren’t the origin.
4. DevTools-aware malware is here
If your malware hides when inspected, traditional debugging falls short.
5. Hosting + security vendors + developers = real protection
Each layer protects in different ways, but only developers who know your codebase can close the gap.
And sometimes the smallest clue, like a single misplaced PNG, ends up being the key.
How Curious Minds Media Helps Secure Enterprise WooCommerce
At Curious Minds Media, security isn’t an afterthought. It’s an integral part of how we design, build, and maintain WordPress and WooCommerce platforms.
We specialize in:
Deep code and database forensics
Rapid incident response
Long-term maintenance that reduces vulnerability drift
Security-first engineering practices
Clear communication throughout the process
With roots going back to 2004, our team has helped hundreds of site owners scale their online stores securely and confidently.
If Your WooCommerce Checkout Is Behaving Strangely, Don’t Ignore It
Duplicate iframes, intermittent field behavior, unexplainable redirects, or recurring cache files aren’t harmless glitches anymore.
If your team is noticing anything unusual or if you simply want a comprehensive security audit, we’re here to help.
Let’s secure your store, protect your customers, and keep your revenue flowing safely.
Because in cases like this, the difference between a quick recovery and days of lost revenue usually starts with the very first symptom someone almost overlooks.
