How to Identify and Clean Up Symlink Attacks on Shared Hosting

Shared hosting comes with a security risk whereby if someone gains access to the file system of one account, they are able to create symlinks to files in other accounts so their contents can be read. This is dangerous when a malicious user knows which file they want to read - and while this article focuses heavily on WordPress (one of the most popular CMS platforms), symlink attacks can target any web application on shared hosting. This can lead to the frustrating situation where your website keeps getting hacked after cleaning, requiring a more thorough approach to break the cycle.

Although symlink attacks are most commonly associated with shared hosting, they can also affect VPS (Virtual Private Server) or dedicated server environments. While a shared environment significantly escalates the scale of these attacks due to cross-site vulnerabilities (your site can be compromised even with up-to-date software if a neighboring site is breached), isolated servers aren't immune. Attackers can use similar techniques once they gain initial access to exploit file system vulnerabilities on any hosting type.

In WordPress attacks, hackers typically target the wp-config.php file which is in a known location with a predictable name. Reading this file exposes the database name and password, allowing the attacker to connect to the database from the compromised site. Once connected, they can inject an admin user into the wp_users table, allowing them to log in to the admin dashboard and upload malicious files. They can then create symlinks to the configuration file for every other website on the server, gaining your database credentials, so it isn't necessarily your server that is initially breached.

Similar attacks occur against Joomla (targeting configuration.php), Drupal (settings.php), Magento (local.xml), and custom PHP applications (looking for database connection files). The core technique remains the same: use a symlink to read sensitive configuration files, extract credentials, and escalate access. The malicious files uploaded can be mailers, backdoors, or code that injects ads or downloads malware.

Recognizing the Signs of a Symlink Attack

Before diving into cleanup, it's crucial to recognize when you're dealing with a symlink attack. Here are the telltale signs:

Unusual website behavior

• Unexpected redirects to other websites
• New administrator accounts appearing in WordPress
• Changes to website content you didn't make
• Unusual traffic patterns or server load spikes
• Search engines flagging your site as malicious

File system indicators

• Unfamiliar PHP files appearing in various directories
• Modified timestamps on core WordPress files
• Presence of symbolic links pointing to files outside the account's directory (sometimes hundreds)
• Unusual file permissions (especially executable permissions on PHP files)
• Hidden files or directories (names starting with a dot)

Common malicious file patterns

Look for files with these characteristics:

• PHP files with random or obfuscated names (e.g., a2f5d.php or wp-logns.php)
• Files containing heavily obfuscated code (often using base64_decode, eval, etc.)
• Recently added files in uncommon locations (especially in upload directories)
• Files that attempt to blend in by using names similar to legitimate WordPress files

Server log evidence

Check your server logs for:

• POST requests to wp-login.php from unusual IP addresses
• Successful logins followed by file uploads
• Requests to PHP files that don't belong to your WordPress installation
• Excessive 404 errors from scanning attempts
• File permission change requests

A symlink attack specifically will often show evidence of file read operations across different user accounts, and you may see multiple websites on the same server showing similar patterns of compromise at nearly the same time.

Cleaning up a symlink attack can be complex, as there are a myriad ways it can present. Often there is a 'site zero' which was the original compromised site where, after cleaning up, the files will re-appear or be modified again (sometimes instantly). This can be very frustrating as often you will move on after cleaning up the original site, only to find that you need to start again.

Although not a perfect set of instructions, the following steps are a start. You may find your symlink attack presents a little different, but this will help point you in the right direction.

Sometimes you might find the malicious user in the process of breaching websites - you can tell this by how recent files have been edited. If you suspect that someone is currently hacking a site and you are running a multi-site server, consider taking Apache offline until you have a handle on what is happening. This may prevent further sites from being breached. If it's just the one website, consider taking the site offline completely (a 'deny from all' in the .htaccess file will achieve this easily).

Identify the IP address of the malicious user

Check the timestamp of any malicious files of the site that has been breached, then search the Apache log files for around this time for any suspicious URLs - typically, this would be a request for the admin login page.

grep "02/Apr" /usr/local/apache/domlogs/compromised_site.com-ssl_log-Apr-2025 | grep upload | grep wp-admin

Have a look through the results - if you see an entry similar to the following which has uploaded files, the IP address is most likely the one used to compromise other sites (although this isn't always the case - check for different IPs in the results).

Once you have an IP address, head over to an IP checker such as https://www.whatismyip.com/ip-address-lookup/ to see where the IP originated from. It may be that it's an innocent IP for one of the website managers. If the IP address is from a country that you aren't expecting, then expect that it is a malicious user. If you suspect this is your malicious user, then consider adding them to the firewall to block them. Although no guarantee they are still around, or still using the same IP address, it could possibly slow them down a little.

Identify other compromised sites

Once you have the IP address, search all of the Apache log files for that IP:

grep -Rl 192.29.97.49 /usr/local/apache/domlogs/

This will return a list of log files that contain the IP address. Each of these sites may potentially be compromised and should be checked.

Finding malicious files

Now you need to locate the malicious files that have been uploaded. Common locations include:

• WordPress uploads folder
• Theme directories
• Plugin directories
• Server temp directories
• Joomla media directories
• Drupal files directory
• Generic web root locations (often disguised as common files)

Search for recently modified files across the compromised sites:

find /home/*/public_html -type f -name "*.php" -mtime -7 | xargs grep -l "eval" | less

This command finds PHP files modified in the last 7 days that contain the "eval" function, which is commonly used in malicious code.

Other patterns to search for include:

find /home/*/public_html -type f -name "*.php" -mtime -7 | xargs grep -l "base64_decode" | less

find /home/*/public_html -type f -name "*.php" -mtime -7 | xargs grep -l "gzinflate" | less

Identifying Symlinks

To find symlinks that may have been created, use:

find /home/compromised_account -type l -ls

This command lists all symbolic links in the compromised account. Look for links pointing to files outside the account's directory structure, especially those pointing to configuration files like:

• WordPress: wp-config.php
• Joomla: configuration.php
• Drupal: settings.php
• Magento: local.xml, config.xml
• Laravel: .env
• Any PHP application: Files containing database connection strings

Cleaning Up

There is no doubt that the most effective way to recover from a symlink hack is to restore a clean backup, as this type of attack can be extremely pervasive, creating multitudes of files across numerous directories while also corrupting existing files. However, you may not always have a reliable backup, so your only path of action is to clean the site. Make use of any available scanning tools to identify corrupted files or malware, such as the virus scanner within cPanel or WHM-level security tools like Imunify360. These scanners can help pinpoint malicious code that might otherwise be difficult to find manually.

General Cleanup Process

1. Quarantine affected sites

Add a temporary "deny from all" rule to the .htaccess file:

echo "deny from all" > /home/compromised_account/public_html/.htaccess

2. Remove malicious files

Once identified, remove the malicious files and symlinks:

rm /path/to/malicious/file.php

For symlinks:

unlink /path/to/symlink

Checking for backdoors

Common backdoor techniques include:

1. PHP files with unusual names or locations
2. Hidden files (starting with a dot)
3. Files with executable permissions
4. Files containing obfuscated code

Search for hidden PHP files:

find /home/*/public_html -name ".\*.php" -type f

Look for files with unusual permissions:

find /home/*/public_html -type f -perm -0100 -name "*.php"

Add a temporary "deny from all" rule to the .htaccess file:

echo "deny from all" > /home/compromised_account/public_html/.htaccess

2. Remove malicious files

Once identified, remove the malicious files and symlinks:

rm /path/to/malicious/file.php

For symlinks:

unlink /path/to/symlink

3. Deal with persistent .htaccess corruption

If you notice .htaccess files keep getting corrupted even after you fix them, this indicates a persistent backdoor is rewriting them. To find the source:

1. Check for cron jobs:

   crontab -l

   Look for any suspicious scheduled tasks.
2. Find files that write to .htaccess:

   grep -r "\.htaccess" --include="*.php" /home/*/public_html

3. Look for auto-append/prepend settings: Check php.ini files for auto_prepend_file or auto_append_file directives.
4. Identify running malicious processes: Even after removing cron jobs, processes they started may continue running. Use:

   ps aux | grep php

   Or for a comprehensive view of resource usage:

   top

   Look for unusual PHP processes, especially those running as the compromised user.

Once you've identified the malicious processes, kill them using their process ID (PID):

kill -9 [PID]

For more persistent processes that respawn, you may need to investigate further. Check for:

• Parent processes that restart killed children
• Init scripts in /etc/init.d/
• Systemd services that might have been added
• Rootkits (use tools like rkhunter or chkrootkit)

After addressing running processes, remove all backdoor scripts and consider changing file permissions on .htaccess to prevent writing:

chmod 444 /path/to/.htaccess

4. Check and reset WordPress database

After securing access to wp-config.php, check for unauthorized admin users:

SELECT * FROM wp_users WHERE user_registered > '2022-07-01';

Look for suspicious admin accounts and remove them:

DELETE FROM wp_users WHERE ID = 'suspicious_user_id';

Don't forget to also delete related entries in wp_usermeta:

DELETE FROM wp_usermeta WHERE user_id = 'suspicious_user_id';

5. Change passwords

Update all passwords, including:

• Database passwords in wp-config.php
• WordPress admin passwords
• FTP/SFTP account passwords
• Control panel passwords

6. Update all software

Ensure all WordPress installations, themes, and plugins are updated to the latest versions.

Preventing Future Attacks

Using PHP-FPM open_basedir to Prevent Symlink Attacks

One of the most effective ways to prevent symlink attacks on shared hosting environments is to configure PHP's open_basedir restriction. This setting limits which files PHP can access, effectively creating a chroot-like environment for each website.

How open_basedir Works

The open_basedir directive restricts file operations to the specified directory tree, including any subdirectories. PHP scripts cannot access files outside this directory, even through symbolic links.

Configuration Steps for PHP-FPM

Here's how to implement open_basedir restrictions on a per-pool basis in PHP-FPM:

1. Locate your PHP-FPM pool configuration:
   Typically found in /etc/php/7.4/fpm/pool.d/ (replace 7.4 with your PHP version) or /etc/php-fpm.d/, depending on your distribution.
2. Edit the pool configuration file for each website:
   Each website should have its own PHP-FPM pool configuration (e.g., www.conf, example.com.conf).
3. Add or modify the open_basedir directive:
   

    php_admin_value[open_basedir] = /home/username/public_html:/tmp:/var/tmp:/usr/share/pear:/usr/share/php 

   This restricts PHP access to only the specified directories.
4. Restart PHP-FPM to apply changes:
   

   systemctl restart php7.4-fpm # For Debian/Ubuntu
   
   			# OR
   
   			systemctl restart php-fpm # For CentOS/RHEL 

Example for cPanel/WHM Servers

On cPanel servers, you can apply open_basedir restrictions globally:

1. In WHM, navigate to "Software" > "MultiPHP INI Editor"
2. Select "All Users" or specific users
3. Set open_basedir to: "/home/%domain%/:/tmp:/var/tmp:/usr/share/pear:/usr/share/php"
4. cPanel will automatically replace %domain% with the appropriate username for each account

For Plesk Servers

In Plesk, open_basedir restrictions can be enabled through:

1. Go to "Tools & Settings" > "PHP Settings"
2. Enable the checkbox for "open_basedir restriction"
3. Apply changes to all domains or select specific domains

Conclusion

Server-level prevention

Configure the server to prevent symlink attacks:

 # Add to Apache configuration or .htaccess

	Options -FollowSymLinks

	Options +SymLinksIfOwnerMatch 

1. Install security plugins like Wordfence or Sucuri
2. Implement two-factor authentication for admin accounts
3. Use strong, unique passwords for all accounts
4. Limit login attempts
5. Consider using a Web Application Firewall (WAF)

WordPress-specific prevention

Symlink attacks on shared hosting can be devastating but following a methodical approach to identification and cleanup can minimize damage. The key is to act quickly, identify all compromised sites, remove malicious code, and implement preventative measures to stop future attacks.

Remember that cleaning up after a symlink attack is an iterative process - you may need to repeat these steps multiple times as you discover additional compromised files or sites. Patience and thoroughness are essential.

If you manage multiple sites on shared hosting, consider moving to a more secure hosting solution like a Virtual Private Server (VPS) or managed WordPress hosting where sites are better isolated from each other.