DEV Community: MD Pabel

How to Manually Clean a Hacked Server

MD Pabel — Sun, 22 Mar 2026 18:29:43 +0000

If you manage WordPress servers, you already know the sinking feeling of getting a frantic Slack message: "The site is redirecting to a crypto casino." In 2026, dealing with WordPress malware has moved far beyond simple script injections in the header.php file. Today’s attackers are sophisticated. They use fileless payloads, exploit cron jobs to create 1-second regeneration loops, and disguise backdoors as legitimate core processes. If you rely solely on automated scanner plugins, you are going to lose.

After manually cleaning over 4,500 infected sites, I’ve learned that the only way to permanently eradicate modern malware is through manual forensic auditing via SSH and direct database manipulation.

Here is the technical blueprint I use to surgically clean compromised WordPress environments.

Step 1: Containment & The CLI Audit

Before you touch anything, you must stop the bleeding. If the site is spewing SEO spam or malicious redirects, lock down the routing immediately.

I usually start by killing PHP execution in the /wp-content/uploads/ directory. Attackers love dropping obfuscated .php webshells in image folders.

Create a .htaccess file inside the uploads folder:

deny from all

Next, SSH into your server and run a recursive grep to hunt for common obfuscation functions. Malware in 2026 heavily relies on base64 and eval() wrappers.

grep -rnw '/var/www/html/' -e 'eval(base64_decode'
grep -rnw '/var/www/html/' -e 'gzinflate(base64_decode'

Step 2: Hunting "Ghost" Admins

Modern malware almost always establishes persistence. Even if you clean the infected files, the attacker will just log back in 10 minutes later using a hidden administrator account.

Attackers hook into WordPress core filters to physically hide their user accounts from the wp-admin dashboard list. You won't see them in the UI. You have to query the MySQL database directly.

SELECT * FROM wp_users WHERE user_registered > '2025-12-01';

Look for users with strange emails or usernames like wp_sysadmin. If you want to see exactly how attackers write the PHP code to hide these accounts from the dashboard, I wrote a deep dive on finding and removing hidden admin users in WordPress.

Step 3: Purging the Database (The `wp_options` Trap)

A massive trend I’m seeing is malware shifting away from files entirely. Attackers are injecting malicious JavaScript directly into the wp_options table—often hiding in transients or active plugin configuration rows.

When the server renders the page, it pulls the malicious script from the database and injects it into the DOM, completely bypassing file-integrity scanners.

You need to search your database for <script> tags, hex-encoded strings, or strange iframe injections.

Pro-tip: Pay special attention to the active_plugins row in wp_options. Hackers frequently use this to force-load fake, hidden plugins that reinstall the malware the moment you delete it.

For a full SQL query breakdown, you can read my guide on scanning and cleaning the WordPress database for hidden malware.

Step 4: The SEO Spam Master Firewall

If the site was hit with the Japanese Keyword Hack or Pharma spam, you likely have thousands of fake URLs indexed in Google. Serving standard 404 pages for 10,000 spam requests will crash a small server due to high PHP/Memory usage.

You must intercept these at the Apache/Nginx level and serve a 410 Gone status code. A 410 tells Googlebot to instantly and permanently drop the URL from the index, and because it’s handled by the server config, it uses zero PHP memory.

Force a lightweight 410 text response

ErrorDocument 410 "

410 Gone

Resource permanently removed.

RewriteEngine On

Block standard Japanese SEO spam query patterns

RewriteCond %{QUERY_STRING} (^|&)[a-z]=[0-9]{8,} [NC]
RewriteRule ^(.*)$ - [R=410,L]

Using this exact firewall snippet, I recently removed 10,500 SEO spam URLs from Google Search in just 12 days.

Step 5: The Final Hurdle - Blacklist Delisting

Once the server is completely scrubbed, patched, and secured, you have to fix the reputation. If Google Chrome is throwing a red "Deceptive Site Ahead" warning, your traffic is effectively zero.

Do not click "Request Review" in Google Search Console until you are 100% certain the site is clean. If Googlebot finds even a trace of the backdoor, they will reject the appeal and potentially flag you as a "Repeat Offender," disabling the review button for 30 days. You must submit a highly technical report explaining exactly which files were altered and how the vulnerability was patched.

If your IP or domain is stuck on McAfee, Norton, or Google Safe Browsing, you can check out my website blacklist removal guide for the exact dispute processes.

About the Author:
I’m MD Pabel, a web security specialist. I spend my days tracking down PHP backdoors, reverse-engineering malware, and providing professional WordPress malware removal services for compromised businesses.

3 SQL Queries to Find Hidden WordPress Backdoors (When Plugins Fail)

MD Pabel — Mon, 09 Feb 2026 10:24:22 +0000

Stop trusting the "All Green" checkmark on your security plugin.

If you manage high-value WordPress sites, you know the drill: The scanner says the site is clean, but the specialized malware is still there—hiding in the database or obfuscated in a core file.

As an agency developer managing 50+ client sites, I don't have time for a full forensic audit every morning. But I also can't afford a reinfection.

Here is the "Manual Smoke Test" I run on every suspect site. It takes 5 minutes, uses zero plugins, and catches the 90% of "Ghost Admin" hacks that automated tools miss.

⚠️ WARNING: BACKUP FIRST

Before running any raw SQL queries or terminal commands, you must take a full backup of your database.

Even a simple SELECT query is safe, but getting comfortable in phpMyAdmin or SSH without a safety net is a recipe for disaster. I recommend using WP-CLI (wp db export) or your hosting panel to grab a snapshot.

I am not responsible if you accidentally DROP TABLE instead of SELECT. Proceed with caution.

1. The "Ghost Admin" Hunter

Hackers often create a user with Administrator privileges but hide it from the WordPress Dashboard using a simple functions.php filter. The only way to see the truth is to ask the database directly.

Run this in phpMyAdmin or your terminal:

SELECT u.ID, u.user_login, u.user_email, m.meta_value 
FROM wp_users u 
JOIN wp_usermeta m ON u.ID = m.user_id 
WHERE m.meta_key = 'wp_capabilities' 
AND m.meta_value LIKE '%administrator%';

What to look for:

Users with generic names like system_admin, wp_updater, or support_user.
Emails that don't match your client's domain.

2. The "Auto-Load" Injector

Sophisticated malware (like the "Japanese Keyword Hack" or "Credit Card Skimmers") rarely lives in files anymore. It lives in the wp_options table, set to autoload=yes so it executes on every single page load.

Use this query to find the largest, most suspicious auto-loading scripts:

SELECT option_name, LENGTH(option_value) AS option_length 
FROM wp_options 
WHERE autoload = 'yes' 
ORDER BY option_length DESC 
LIMIT 20;

The Red Flag:

Look for huge options (length > 10,000) with random names like 342_sd_32 or generic names like core_updater_code.
If you see eval( or base64_decode inside these options, you are hacked.

3. The "Recently Modified" Core Check

I learned this workflow after analyzing a particularly nasty redirection hack. Plugins were useless because the malware was "waking up" via a cron job.

I verified this technique with MD Pabel, a manual malware removal specialist I follow for forensic tips. He pointed out that attackers almost always touch a file within the last 48 hours to establish persistence.

Don't scan everything. Just scan time. Run this in your terminal (SSH):

# Find PHP files modified in the last 2 days
find . -type f -name "*.php" -mtime -2

If you see wp-config.php or index.php in that list and you didn't edit them, you have a breach.

Summary

Automation is great for scaling, but manual verification is required for security.

Trust: Your git logs.
Verify: Your database wp_users table.
Never Trust: A "Clean" scan result when your client says their site is redirecting.

What is your go-to command for finding hidden malware? Drop it in the comments below—I'm always updating my snippets library.

The Manual Protocol: How to Clean a Hacked WordPress Site (Without Plugins)

MD Pabel — Thu, 04 Dec 2025 13:54:32 +0000

If you manage WordPress sites long enough, you will deal with a compromised instance.

The standard advice on the web is usually "install a security plugin and hit scan." While plugins like Wordfence are excellent for detection and firewalls, relying on them to clean a fully compromised site is risky. They often miss obfuscated backdoors hidden in valid PHP files, or they fail to detect malware that reinfects via Cron jobs.

As developers, we need a more surgical approach. I call this the Manual Core Refresh Protocol. It ensures file integrity by replacing compromised core files with sterile sources.

Here is the step-by-step workflow I use to clean infected sites.

Step 1: The Safety Net (Backup)

Before running rm -rf on anything, you need a snapshot. If the malware has infected wp-config.php or your database, a clumsy cleanup can brick the site.

The Automated Route: If you still have dashboard access, use UpdraftPlus. It’s the standard for a reason. Guide: Backing Up with UpdraftPlus (Step-by-Step).
The Migration Route: If you plan to pull the site to localhost to clean it safely (recommended), use All-in-One WP Migration. Guide: Using AI1WM for Backup & Migration.

Step 2: Verification & Diffing

Don't start deleting files based on a hunch. Verify the infection vectors.

External Scan: Use Sucuri SiteCheck to see if the payload is client-side (JS redirects, spam links).
Internal Diff: Use Wordfence (Free) to scan the filesystem. It creates a diff between your core files and the official WordPress repository checksums. This highlights exactly which system files have been tampered with.

Step 3: The Core Refresh (The Fix)

This is the most effective way to handle file-based malware (Backdoors, Shells, Trojans). Instead of patching files, we replace them.

The Protocol:

Download the latest WordPress .zip from the official source.
Connect via FTP/SFTP or SSH.
Delete these directories entirely:
- /wp-admin/
- /wp-includes/
- (Also delete root .php files like index.php, but **KEEP* wp-config.php)*
Preserve these assets:
- /wp-content/ (This contains your uploads, themes, and plugins).
- wp-config.php (Database credentials).
- .htaccess (Check this manually before keeping it).
Upload the clean /wp-admin and /wp-includes from the official zip.

This ensures 100% integrity for the WordPress core.

Step 4: Debugging Specific Vectors

The core is clean, but malware often persists in /wp-content/ or the database. Here is how to handle specific infection signatures:

1. The "Drive-By" & Registrar Suspensions

If you are managing .ch or .li domains, or if your registrar (like SWITCH) suspends the domain, it's usually due to "Drive-By" downloads targeting visitors.

The Fix: How to Remove “Drive-By” Malware & Fix SWITCH Domain Deactivation

2. JavaScript Redirects

If the site redirects to getfix.win or similar spam domains, the injection is likely in the database (targeting the siteurl option) or appended to every .js file.

3. PHP Backdoors & Shells

Look for files named logically but behaving maliciously (e.g., wp-compat.php or class-loader.php inside the uploads folder).
Signatures to look for: eval(), base64_decode(), gzinflate().

4. SEO Spam (Cloaking)

Commonly known as the "Japanese Keyword Hack." The attacker injects thousands of pages into your database to rank for spam keywords. These are often invisible to admins but visible to Googlebot.

Step 5: Persistence (Why it comes back)

If you rm the malware and it returns 10 minutes later, check your Cron Jobs.

Attackers often schedule a task (via WP-Cron or system Cron) to wget the malicious payload from a remote server if it goes missing.

Explained: The Hidden Cron Job Hack

Conclusion

Cleaning a WordPress site is less about magic and more about being thorough with file integrity. Once cleaned, update all salts, rotate database passwords, and ensure your plugins are patched.

Don't want to deal with the terminal?
If you are a dev focused on frontend and don't want to mess with the backend cleanup, I offer a fixed-price service to handle the manual protocol for you.

👉 Hire Me for Manual Malware Removal

Have you encountered any new obfuscation techniques lately? Drop them in the comments, I’d love to take a look.

Malware Detection and Removal from WooCommerce Checkout Page

MD Pabel — Mon, 28 Jul 2025 16:42:22 +0000

In the world of e-commerce, securing your online store is crucial to protect customer data and maintain trust. If you’re running a WordPress site with WooCommerce, you’re likely aware of the risks posed by malware, such as credit card skimmers. These malicious scripts can stealthily capture sensitive payment information, leading to data breaches and financial losses.

In this detailed case study, we’ll walk you through a real-world incident where a WooCommerce-based WordPress website was compromised by a fake payment form malware. We’ll cover how the malware operated, the steps for detection, and the complete removal process. Whether you’re dealing with WordPress malware removal or want to prevent such attacks, this guide provides actionable insights to enhance your site’s security.
Read More...