How to find a backdoor on a hacked site and trace the source

Question

Information Security

The situation is as follows:

On one of the sites with self-written code in PHP, a web-shell was loaded, in addition to the web-shell, backdoors were left.

It was not possible to restore the archived copy of the site, so we tried to clean up the traces of hacking, however, apparently this could not be done completely, because backdoors reappeared one way or another. Thus, the hacker has full access to the site with the ability to upload arbitrary files to it.

The questions are:

1. What are the known backdoor detection mechanisms?
2. What tools can be used to track changes in site scripts (existing scripts, new ones, etc.). Variant of answer: constant integrity check reveals only the fact of modification. It is necessary to track exactly where the changes originated from, i.e. who initiated them. Maybe there are suitable implementations of honey-pots…

Thank you!

Answer 1

Literally yesterday I dealt with a similar problem on a site familiar with Joomla.
1. Log in via ssh and make an archive of the entire site, download it to your machine.
2. Set Kaspersky or Sophos on the archive (experience has shown that they are excellent at detecting malware, although not all)
Clean up all detected vulnerabilities directly on the site using vi. If it turns out that eval was stuffed into EXIF ​​pictures, then they just need to be re-saved and uploaded back to the site.
While the antivirus does its job, do the following:
1. Check .htaccess for left redirects. In my case, all users were sent to the phpinfo.php page with some porn.
2. Look for code that antiviruses cannot find:
2.1 Some files have a built-in structure that allows you to save the file to an arbitrary location on the site. In my case, this was done using the command

find. -type file | grep php | xargs grep -l "<?php if (@"

2.2 Search and analyze files that access exif

find. -type file | grep php | xargs grep -l exif_read_data

2.3 Find pictures with Trojans

find. -type file | grep jpg | xargs grep -l eval

2.4 Look for preg_replace which then executes the code

find. -type file | grep php | xargs grep -l preg_replace.*\/e

3. Antiviruses will surely find some files. Take a look at them on the hosting, as a rule, there is coded crap and verification of some passwords. These very checks can give additional clues for the search. In my case, I found a number of files using the commands

find. -type file | grep php | xargs grep -l 2970d43d7bf4115cdc60e2453bf48b52
find. -type file | grep php | xargs grep -l security_code

4. Carefully analyze the files that are located next to the backdoor files, most likely they are where the vulnerability is located.
5. Dump the base dump and look for eval, preg_replace and other goodies in it
6. After cleaning up all the rubbish, make a backup archive of the site again
These were all steps to bring the site to a working state. Unfortunately, they cannot give an answer to the question, how did they trick us. Let's move on to active actions to identify entry points.
On the server where my friends are hosted, there is only cvs, and we will use it. Similar actions can be done with git or svn.
1. Exited to the home directory

cd

2. Created an empty directory for our repository

mkdir cvsroot

3. Initialized the repository

cvs -d ~/cvsroot init

4. Moved to the directory where the site root is located. Let's say you have the following structure /home/myusername/mysite/htdocs. Then

cd ~/mysite/htdocs

5. Doing the initial import into the repository

cvs -d ~/cvsroot import htdocs initial_import initial

6. Now we will delete the old site and take it from the repository

cd ~/mysite
mv htdocs htdocs.bak
cvs -d ~/cvsroot checkout www

7. Add a rule to .htaccess that protects service files

RedirectMatch 404 /CVS(/|$)

8. What does this give us? Possibility of quick check of changed files

cd ~/mysite/htdocs
cvs -qn update

If everything was done correctly, then the answer will be

m.htaccess

9. We write our changes to the repository

cvs -q commit -m update

Next, we include the cvs -q commit -m update command in cron, and at least once a minute (if the site is heavily visited), we include log files and catch the changes that occur in the system. Having determined the time and the changed files, we look at the logs what, who, where and how they did it.

Answer 2

Remotshells are usually uploaded to the site, in the scripts of which there is a vulnerability. How to look for them - there is a good article on this topic on Habré: habrahabr.ru/post/188878/

Answer 3

php - look in the code: eval, base64

Answer 4

Enable/look at web server access logs

Answer 5

Perhaps the virus climbs from the computer via ftp?

Answer 6

In this case, either a vulnerability in your engine, or a compromise of the entire server on the hosting.

Answer 7

1. You need to look at the list of files that differ from the stable build from the version control system.
2. httpd/sshd logs.

Answer 8

It is possible to reveal how the changes occurred only by comparing the file modification time with access.log - in case they are hacked through a vulnerability in scripts or using previously uploaded malicious scripts.

Answer 9

First, we check the local machine for viruses :--) Then, we change all the passwords that we have: on ftp, hosting admin panel, site admin panel, phpmyadmin, etc. In short, all-all-all passwords. <urgant-mode>You can even change the locks in your apartment :--)</urgant-mode> If you use an s/ftp client, it's better not to save passwords in it at all.
After that, look in php scripts for non-your own or unfamiliar javascripts. You can, for example, search for "<script" or think of something else, in the same way, search for the word "eval". It does not hurt to see what is happening in .htaccess, and if it is not one, then in all. There, too, sometimes different suspicious shnyaga is stored. Pay attention to the dates when files were edited - this will facilitate the search. Also, if possible, prohibit editing files that should not be edited. You can also ask hosters to provide information on suspicious file activity. Some hosters immediately provide a list of infected files :--)
Of course, this is offhand, but usually enough.

Answer 10

1. we check the "engine" files, comparing them with the original version of the engine files of the same version, when installing, if it is a well-known engine, like wordpress / bitrix. If the engine itself was hacked, comparing the files will show it.
2. the same with plugins/themes/scripts files, if there are differences between yours and files from distributions, it will be visible.
3. deep scan of your hosts for viruses.
4. global change of passwords for admin panels - site, ftp, account webmords in the hoster's control panel.

Answer 11

2. What tools can be used to track changes in site scripts (existing scripts, new ones, etc.). Variant of answer: constant integrity check reveals only the fact of modification. It is necessary to track exactly where the changes originated from, i.e. who initiated them.

nothing will help in user-mode, except for analyzing web server logs, only auditing
Penguin under the hood: Auditing system events in Linux
Auditing in Linux, part one
Understanding Linux Audit