Dennis
Dennis
DevOps Engineer A.I Integration Recommendation Engine Fine-tuning AI models WebRTC Development RPC Systems Chatbot Developement
Dennis

Blog

How to look for malicious code on your website without scanners

How to look for malicious code on your website without scanners

Modern malicious and hacker scripts are significantly different from those of 3-5 years ago. Now developers of malicious code mix obfuscation, encryption, decomposition, external loading of malicious code, etc. in order to cheat scanners and antiviruses. Consequently, the recognition of malicious code by scanners and antiviruses has fallen dramatically.

What should be done to more efficiently detect viruses and hacker script on the site? You need to do an automated scan first, and then do a manual analysis.

First, let's look at what exactly to look for when hacking.

1. Hacker scripts. Most often, when hacked, files are downloaded that are web shells,
backdoors, loaders, scripts for spam mailings, phishing pages + form handlers, doorways and hacking token files.

2. Injections in existing files. The second most popular type of placement of malicious and hacker code is injections. Mobile and search redirects can be injected into existing site files .htaccess, backdoors can be injected into php / perl scripts, viral javascript fragments or redirects to third-party resources can be embedded into .js and .html templates. Injections are also possible in media files, for example .jpg or. Malicious code often consists of several components: the malicious code itself is stored in the exif header of a jpg file, and is executed using a small control script, the code of which does not look suspicious to the scanner.

3.Injections in the database. The database is the third target for a hacker. Here, static inserts,,, are possible, which redirect visitors to third-party resources, "spy" on them, or infect the visitor's computer | mobile device as a result of a drive-by attack (attack using hidden download). In addition, in many modern CMS (IPB, vBulletin, modx, etc.), templating tools allow you to execute php code, and the templates themselves are stored in the database, so the php code of web shells and backdoors can be embedded directly into the database.

Injections in caching services.

4. As a result of incorrect or unsafe configuration of caching services, for example, memcached, injections into cached data are possible “on the fly”. In some cases, a hacker can inject malicious code into website pages without directly breaking the latter. Injects / incited items in server system components.

5. If a hacker gains root access to the server, he can replace the elements of the web server or caching server with infected ones. Such a web server will, on the one hand, provide control over the server using control commands, and on the other hand, from time to time, it will inject dynamic redirects and malicious code into website pages. As in the case of an injection into a caching service, the site administrator will most likely not be able to detect the fact of a hacked site, since all files and the database will be original. This option is the most difficult to treat.

So, let's say that you have already checked the files on the hosting and the database dump with scanners, but they did not find anything, and the viral redirect is still on the page or the mobile redirect continues to work when the pages are opened. How to look further?

Manual search

On unix, it's hard to find a more valuable pair of commands for finding files and fragments than find / grep.

find. -name '* .ph *' -mtime -7

will find all files that have changed in the last week. Sometimes hackers "twist" the modified date of the scripts so as not to discover new scripts. Then you can search for php / phtml files that have changed the

find attributes . -name '* .ph *' -сtime -7


find. -name '* .ph *' -newermt 2015-01-25! -newermt 2015-01-30 -ls

Grep is indispensable for searching in files. It can search recursively through files the specified snippet

grep -ril 'stummann.net/steffen/google-analytics/jquery-1.6.5.min.js' *

When hacking a server, it is useful to analyze the files that have the guid / suid flag set

find / -perm -4000 -o -perm -2000

To determine which scripts are currently running and load the hosting CPU, you can call

lsof + r 1 -p `ps axww | grep httpd | grep -v grep | awk '{if (! str) {str =} else {str = str ","}} END {print str}' `| grep vhosts | grep php

Analyze files on hosting

1. Go to the upload, cache, tmp, backup, log, images directories, into which something is written by scripts or uploaded by users, and scan the contents for new files with suspicious extensions. For example, for joomla, you can check the .php files in the images directory: find ./images -name '* .ph *' Most likely, if something is found, it will be malicious. For WordPress, it makes sense to check the wp-content / uploads directory, backup and cache directories for scripts.

2. We are looking for files with strange names For example, php, fyi.php, n2fd2.php. Files can be searched for - by non-standard combinations of characters - by the presence of numbers 3,4,5,6,7,8,9 in the file name

3. We are looking for doorways by a large number of .html or .php files If there are several thousand .php files in the directory or .html, most likely it is a doorway.

4. Logs of the web server, mail service and FTP. Correlation of the date and time the message was sent (which can be found from the mail server log or the service header of a spam message) with requests from the access_log helps to identify a method of sending spam or to find a spam mailer script. Analysis of the FTP xferlog transfer log allows you to understand which files were uploaded at the time of the hack, which ones were changed and by whom. A properly configured mail server log or the service header of a spam message, if PHP is configured correctly, will contain the name or full path to the sender script, which helps to determine the source of spam. By the logs of proactive protection of modern CMS and plugins, you can determine which attacks were carried out on the site and whether the CMS was able to resist them. The access_log and error_log can be used to analyze the actions of the hacker, if the names of the scripts that he called are known, IP address or User Agent. As a last resort, you can view POST requests on the day the site was hacked and infected. Often, the analysis allows you to find other hacker scripts that were downloaded or were already on the server at the time of the hacking.

Add Comment