Tips to clean up symlink attack on Linux webserver

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 in the case of Wordpress, one of the most popular CMS platforms, the configuration file is in a known location, with a known name. Reading this file will expose the database name and password, allowing the malicious user to connect to the database from the compromised site. Once connected, they are able to inject an admin user into the users table of the Wordpress database which will then allow them to log in to the admin of the website and upload malicious files. These malicious files can be mailers, or they could inject code into web pages to display ads or download malware.

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

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/Aug" /usr/local/apache/domlogs/compromised_site.com-ssl_log-Aug-2022 | 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.

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/