DEV Community

MD Pabel
MD Pabel

Posted on • Originally published at mdpabel.com on

Failed Google Blacklist Request? How to Find Hidden Database Malware

#database #security #tutorial #wordpress

Recently, a client contacted me feeling completely frustrated. Their WordPress website was flagged by Google for a security issue, and a massive red warning was scaring away all their visitors the moment they tried to access the site.

Before finding me, the client hired a developer to fix the problem. That person installed Wordfence, ran a scan, and told the client the site was clean. They submitted a reconsideration request to Google. It failed. They tried again. Failed again. In total, they suffered through a failed Google blacklist request three times.

The client was losing traffic and money, and they needed a permanent fix. Here is how I found the hidden database malware, cleaned the site, and finally got the Google red warning removed.

  • The Problem: A site blacklisted by Google Safe Browsing with 3 failed reconsideration requests.
  • Why automated scanners failed: The previous developer relied only on Wordfence, which mostly scans files. The files were perfectly clean.
  • The Real Issue: A complex database injection. The malware was hiding directly inside the WordPress database (specifically the wp_posts table).
  • The Solution: Manually identifying the obfuscated JavaScript, writing a custom SQL query to clean the database rows, and successfully passing the 4th Google review.

Finding the Database Malware When Files Look Clean

When I take over a hacked website, I never just rely on automated plugins. I’ve cleaned thousands of sites, and while plugins like Wordfence are great tools, they have blind spots.

I started by checking the core WordPress files, themes, and plugins. Just like the previous freelancer found out, the files were 100% clean. No modified dates, no weird backdoors.

But malware has to live somewhere. If it’s not in the files, the next logical place is the database. I opened up phpMyAdmin and started digging. Sure enough, hiding inside the post_content of the client’s pages was a massive block of malicious JavaScript.

Understanding the Malware: Why Was It So Hard to Spot?

The injected code looked like a giant wall of random letters and numbers. This is a common tactic called “obfuscation.” Hackers scramble the code so that security scanners (and human eyes) can’t easily tell what it’s doing.

Here is a snippet of exactly what I found in the database (defanged for safe reading):

[script type="text/javascript"]
/* Code intentionally broken to prevent execution */
;function _0xe59d ( _0x1f888c, _0x2f9035 ) { 
   _0x1f888c = _0x1f888c - 0x166; 
   var _0x978844 = _0x29f1(); 
   var _0x7369f6 = _0x978844[_0x1f888c]; 
   return _0x7369f6; 
} ...
[/script]
Enter fullscreen mode Exit fullscreen mode

To figure out what this database malware was doing to the client’s website, I decoded it. Here is a plain-English breakdown of how this specific attack works:

1. It hides from the website owner.

The code contains a specific check: if(/wordpress_logged_in_|wp-settings-/... ) return;. This means if you are logged into your WordPress admin dashboard, the malware turns itself off. The hacker does this so the site owner never sees the spam redirects while editing their site. Everything looks totally normal to you, while your normal visitors are being hijacked.

2. It hides from search engine bots.

The code also checks the user agent for words like bot, crawl, spider, googlebot, and ahrefs. If a search engine is looking at the site, the malware stays quiet to avoid immediate detection.

3. It pulls bad code from external servers.

Inside the scrambled text, the hacker hid Base64 encoded URLs. When decoded, they reveal the source of the attack:

  • https://govearali[.]org/jsrepo?rnd=
  • https://ligovera[.]shop/jsrepo?rnd=

When a normal visitor lands on the infected page, this script silently reaches out to those bad domains, downloads more malicious code, and hijacks the user’s browser.

The Fix: Cleaning the Database Injection

Because this script was inserted directly into the text editor of the pages and posts, simply reinstalling WordPress or replacing core files wouldn’t fix it.

Instead of doing it manually page by page, I wrote a custom SQL query to safely search and replace this specific string of obfuscated JavaScript across the entire wp_posts table. Once I cleared out the injected scripts, I manually reviewed the wp_options and widgets tables to ensure no other variations were hiding there.

After confirming the database was entirely clean, I hardened the WordPress security to prevent the attacker from getting back in (changing database passwords, updating salt keys, and securing admin endpoints).

Fixing the Red Warning and Passing the Google Review

With the database malware completely gone, I submitted a very detailed reconsideration request to Google Search Console on behalf of the client. I explained exactly where the malware was hidden, how it was functioning, and the specific database cleanup steps taken.

Because the site was actually clean this time, the review passed successfully. The red warning when you visit the site was finally lifted, and the client’s traffic started returning to normal.

The big takeaway: Never rely entirely on automated scans. If your site has a red warning and your Google blacklist request is rejected, but your security plugin says “100% clean,” you need a specialist to dig deeper into the database.

Top comments (0)