Inside a Real-World WordPress Hack: How Attackers Hide Credit Card Skimmers in Plain Sight

*A post-mortem analysis of the SMILODON malware family, and why this attack failed despite the attackers doing everything “right”.*

When a client discovered their WordPress site had been compromised, they had no way to regain control. We went with the nuclear option: a fresh WordPress installation, a fresh theme, plugins reinstalled from trusted sources, and content imported clean. The site is now secure.

But we kept the backups.

This post is the post-mortem. A deep dive into what we found when we picked apart the malware to understand exactly what happened.

Here is the twist: this was not an e-commerce site. The attackers deployed a sophisticated credit card skimmer to a site with no checkout page, no payment processing, nothing to skim. The malware sat there doing nothing useful, occasionally redirecting traffic.

That tells us something important. This was almost certainly part of a mass exploitation campaign. The attackers found a vulnerability, sprayed their payload across every site they could compromise, and hoped some of them would be running WooCommerce. In this case, they got unlucky.

The Discovery: Five Plugins That Should Not Exist

Digging through the backup, we identified five malicious plugins installed on the WordPress site:

Plugin	Purpose
seocore	Hidden admin backdoor
boz	Web shell for file management
abixogehu	Credit card skimmer loader
aberugase	Backup skimmer loader
abezigevo	Tertiary skimmer loader

The first red flag was obvious. Three of these plugins had randomly generated names that followed a specific syllable pattern (consonant-vowel alternation). This is a classic sign of automated malware deployment.

The Backdoor: Hiding in Plain Sight

The seocore plugin appeared to be a simple SEO tool. In reality, it maintained persistent admin access through a hidden user account.

Hardcoded credentials found in the malware:

Username: johnelouter
Password: $KH3WSERDfe4yfsfg$
Email:    [email protected]

This is where it gets clever.

The plugin did not just create an admin account. It actively hid it from everyone:

User list manipulation: SQL queries were modified to exclude this user from all results
REST API filtering: The user was removed from API responses
User count adjustment: The displayed user count was decremented by one
Self-healing code: If the plugin was deactivated, it automatically reactivated on every page load

The site owner could log into WordPress, check the user list, and see nothing suspicious. The attacker retained full administrator access the entire time.

The Web Shell: A GIF That Is Not a GIF

The boz plugin contained a file named class.php that started with:

GIF89a;

Those are the magic bytes of a GIF image. Many scanners skip files that look like images.

Behind those six bytes was a fully featured web shell that allowed:

Complete directory browsing
Arbitrary file uploads
File editing and deletion
Folder creation and manipulation

This gave the attackers a second access path even if the hidden admin account was discovered.

The Main Event: Credit Card Skimming

The three loader plugins (abixogehu, aberugase, abezigevo) were the real payload. Their job was simple: inject JavaScript into WooCommerce checkout pages and steal credit card data as customers typed it.

The encoding scheme was clever. The execution had flaws.

Stage 1: The Not-So-Innocent Plugin

The plugin headers attempted to look legitimate:

/**
 * Plugin Name: Abixogehu
 * Plugin URI: https://redera.biz/abixogehu
 * Description: Including lignite prohibits post
 * Version: 3.10.2
 * Author: Willie Carey
 */

This would not fool anyone who knows what to look for.

“Abixogehu” is obviously machine-generated nonsense. The description is meaningless. The attackers were not trying to pass inspection. They were betting that nobody would ever look.

Stage 2: PHP Hidden in Text Files

Each plugin loaded a .txt file containing PHP code:

include_once __DIR__ . "/ydifi" . "x.txt";

That string concatenation is intentional. Writing "/ydifi" . "x.txt" instead of "/ydifix.txt" helps evade signature-based scanners that look for suspicious include paths.

Stage 3: Payloads Disguised as Images

The actual malware lived in files with image extensions, such as zagothu.png.

They were not images.

Hex dump of the fake image:

00000000: 504e 4751 7055 4a35 5333 3451 4d4a 4a67  PNGQpUJ5S34QMJJg

The file starts with the ASCII string PNG, followed by more than 66,000 characters of encoded PHP. A real PNG file starts with the bytes:

89 50 4E 47 0D 0A 1A 0A

The attackers used a custom encoding pipeline:

Take malicious PHP code
Base64 encode it
Apply a character substitution cipher using a 65-character key
Prepend PNG or GIF to make it look like an image

Each plugin instance used different substitution keys. This polymorphic approach makes signature-based detection extremely difficult.

The Decoded Payload: 50KB of Malice

After decoding the fake image files, we extracted a large PHP class (about 50 KB) with the following capabilities.

Credit Card Theft

Injects JavaScript on WooCommerce checkout pages
Captures card numbers, expiration dates, and CVVs in real time
Exfiltrates data to attacker-controlled servers

Command and Control

Receives commands via specially named cookies
Can update its configuration remotely
Fetches new JavaScript payloads on demand

Stealth Features

Automatically hides the skimmer from administrators
Tracks admin IP addresses in the database
Removes itself from the WordPress plugin list

Command and Control Infrastructure

The malware communicated with the following domains:

stegozaurus.cc
steg.cc
whatbeatfire.cc

Traffic was disguised as normal e-commerce activity using headers such as discount, order, price, and merchant.

Stolen data was exfiltrated to a ProtonMail address selected for privacy and encryption.

The malware also contained approximately 160 pre-hashed domain names used as a whitelist, preventing researchers from hijacking the infrastructure.

Why This Attack Was So Effective

Defense in Depth (for the attacker)
Multiple persistence mechanisms ensured that removing one component would not eliminate the threat. Hidden users, self-reactivating plugins, redundant loaders, and a web shell all worked together.

Invisibility by Design
Admins never saw the skimmer. Plugins did not appear in wp-admin. Payloads looked like image files. Code was fragmented to evade signatures.

Redundancy Through Variation
Each loader plugin used different names, variables, functions, and encryption keys. This strongly suggests automated variant generation.

Indicators of Compromise (IOCs)

File Hashes (SHA256)

Backdoor and Web Shell

a7eafad9437c6d2c6bee4156944dba6b5fd46dcfe2af08a46d4edfb94a119f46  seocore.php
32b024897fd054491ef0175c24f6029861cca55d0b947ea97f700618607e743d  boz/class.php

Loader Plugins

c4a4dbd03fd22877dd7708732e6465d052b7ced4dce61b2c8acf23b96578d04f  abixogehu.php
db79968b3471c2a1e59bd15d546c6826523941d3958a85b582805ea83e020b8a  ydifix.txt
fbab5ff33ab55ea97eb4f665e25a4895dd052c4fab069f6c968f8687ce7ae7c6  cepaxu.txt
dc220a8087f1917ec6888814a10792e170cd9622950492c0dec36eabca6c4988  nusihuh.txt

Encoded Payloads

417e2b43edc59778e6bcca780f124062b54fb991145991f0758cb3a37f62e862  zagothu.png
e26bfbfd16ffb38b974a3806b2e21bd3b8dba9e7470e1b513955811bf3c870e4  gajygyx.png
068a46ea995448d3f1f1940a278bef257865419cb619d8fa30dc18cceb0a35af  zhibejo.gif
d091241ea755be9d446309ff5e20d699910d4e61ea2d35f150358ed863f8be70  zypufa.gif
d8cb2550aa0c9ebf5357c54bbc75e2d18c4957728c8131d8087ef8f6589b422f  zatycha.png

Remediation: The Nuclear Option

For a compromise this deep, partial cleanup is unrealistic.

What we did:

Preserved evidence for analysis
Installed WordPress fresh from wordpress.org
Installed a clean theme from the vendor
Reinstalled plugins one by one from trusted sources
Imported content only (posts, pages, media)
Rotated all credentials and salts
Enabled two-factor authentication for all admins
Deployed file integrity monitoring

Because this was not an e-commerce site, no customer data was exposed. The primary impact was traffic redirection and remediation time.

Lessons Learned

What Worked	What Did Not
Multi-layer encoding	Obviously fake plugin names
Hidden admin persistence	Nonsense plugin descriptions
Self-healing plugins	Skimmer on a non-commerce site
Admin exclusion logic	Spray-and-pray deployment

The bigger picture: this was a mass exploitation campaign, not a targeted attack.

You do not need to be special to get compromised. You just need to be vulnerable.

Regular updates. Strong passwords. Two-factor authentication. Monitoring.

Not exciting. Extremely effective.

This analysis was conducted on a real-world compromise. Identifying details were changed to protect the client. The malware family is known as SMILODON, named after paths used in its command and control URLs.

Inside a Real-World WordPress Hack: How Attackers Hide Credit Card Skimmers in Plain Sight