How to search for malicious code without antiviruses and scanners. How to search for malicious code without antiviruses and scanners How to search for malicious code on WordPress

1. Unpack it into the site folder.
2. follow the link your_site/fscure/
3. everything

What can he do?

1. Automatic search for viruses by signatures.
2. Search for a string in files
3. Deleting files
4. Patch malicious code using regular expressions

The script will not do all the work for you and requires some minimal knowledge. It is recommended to make a backup of the site before work.

How does it work?

When first launched, it creates an index of files. The fscure.lst file is in the folder. Displays a list of files containing potentially malicious signatures. “Potentially malicious” means that you will have to decide whether it is a virus or not. The list of signatures is configured in the config.php file, constant SCAN_SIGN. With default settings, the script does not check js files and does not contain signatures for them.

Most common problems

1. does not create the fscure.lst index. Can happen if there are not enough rights. Put 777 on the fscure folder

2. 5xx error. Most often "504 Gateway Time-out". The script does not have time to process and crashes due to a timeout. In this case, there are several ways to speed up its work. Speed ​​primarily depends on the size of the index. It's in the fscure.lst file. Typically, a file up to 5MB can be processed in 90% of cases. If it doesn’t have time, you can reduce the “greed” of the script by prohibiting scanning *.jpg;*.png;*.css in the config.
In the config.php file.

// delimiter; define("FILES_EXCLUDE","*.js;*.jpg;*.png;*.css");

3. Hosting issues a warning like
(HEX)base64.inject.unclassed.6: u56565656: /var/www/u65656565/data/www/34535335353.ru/fscure/index.php

There is no virus in the script and there never was. And (HEX)base64.inject.unclassed.6 is a construction like "echo base64_decode(" , which is often encountered and in itself is quite harmless. However, in the latest version, I replaced this code.

What to do if you were unable to find the virus yourself?

You can contact me for help. My rates are modest. I guarantee my work for 6 months. The cost of the work is 800 rubles. for 1 site. If there are several sites on your account, the price is determined individually.

If you managed to do everything yourself, I would be grateful for a financial reward or a link to my site.

My requisites:
yandex
41001151597934

webmoney
Z959263622242
R356304765617
E172301357329

Must be done together. If you eliminate the original cause of the hack (for example, a vulnerability in the CMS extension), but do not remove all malicious files, the attacker will be able to gain access to the site again by using one of his scripts. If you delete all downloaded malicious scripts, but do not eliminate the cause of the hack, the attacker will be able to hack the site again and upload scripts to it again.

A specialist with the appropriate knowledge and experience should carry out work to remove malicious scripts and analyze the causes of hacking:

• To remove malicious scripts, you need knowledge of the PHP programming language, as well as knowledge of the “inside” of popular CMS (Joomla, WordPress, etc.) and extensions for them. This knowledge is required to distinguish scripts directly from the CMS and its extensions from extraneous files, and also to be able to unambiguously determine what actions they perform when encountering dubious scripts.
• To analyze the causes of hacking, server administration experience is required. This is necessary to analyze the state of the files on the account, the time they were changed, and also to compare this data with server logs to determine which actions of the attacker led to the hacking of sites.

Therefore, if your site has been hacked, it is recommended, in order to avoid repeated hacks, not to do the work yourself, but to contact a specialist who will carry out the necessary diagnostics and recommend or perform necessary actions to solve the problem, and who can guarantee the quality of the result obtained.

However, there are a number of measures that in some cases help to restore the safe operation of the site without special knowledge. The limitation of the method below is that in order to resume operation of the site, it requires a backup copy of it created before the hack. If the date of the breach is unknown, you can try this method using the oldest backup available. The second limitation, as a consequence of the first, is that after restoring the site, data added to the site after the restore backup was created (for example, new articles, images or documents). If you need to restore the site while retaining new data, you need to contact a specialist.

These measures do not allow us to determine the cause of the site hack, but each of them is aimed at eliminating one of the potential causes of penetration. Since the exact reason for the hack is unknown, it is necessary to perform all of them. The actions are arranged in such an order as to first completely eliminate the possibility of the attacker continuing his activities on the site or hosting account in currently, and then prevent an attacker from entering the site in the future.

The steps below assume that you only have one website on your hosting account. If there are several sites on the account, then they could also be hacked, and the site could be hacked through them. It is necessary to either transfer the site with which restoration work is being carried out to a separate account, or carry out restoration for all sites hosted on the account at the same time.

The order of actions is important, so it is necessary to perform them in the exact order in which they are located below.

Immediately after discovering that a site has been hacked, it is necessary to completely block visitor access to it. This, firstly, will prevent the attacker from carrying out malicious activities on the site, and secondly, will not allow him to interfere with restoration work. This step is very important, since removing malicious scripts and eliminating the cause of the hack does not happen overnight - as a rule, it takes several hours. If the site remains accessible from the outside, the attacker will be able to re-upload scripts to the section of the site that has already been cleared. In this case, an attacker can use different IP addresses to connect, so denying access only to a list of IP addresses will not work. To ensure that the site is cleaned of detected malicious scripts, it is necessary to completely block the attacker’s ability to access the site, which can only be done by completely blocking the site for any visitors. Contact the technical support service of the hosting that hosts your site to block it.

After blocking the site, you need to check the computers from which you were working with the site with a modern antivirus with updated virus databases. If the site was hacked by stealing account passwords using a virus, you must make sure that further work with the hacked site is carried out from a computer that does not have viruses, otherwise after changing the access passwords they may be stolen again.

After blocking the site and checking for viruses, you need to change all access passwords to your account: access via FTP, via SSH, as well as access to the hosting control panel. If an attacker accessed account files using one of these methods, once the passwords are changed, they will no longer be able to do so.

After changing passwords, you must destroy all server processes running under the account on which the site is maintained. Processes launched by an attacker in the background, without being destroyed, will be able to re-place malicious scripts on the site after restoration work is carried out. To prevent this from happening, all processes running before the site was blocked must be destroyed. The site should already be blocked at this moment so that the attacker cannot launch new processes by accessing one of his scripts on the site. To destroy processes running on your account, contact the technical support service of the hosting that hosts your site.

Now it is impossible to penetrate the site from the outside and you can begin to restore it.

Before further actions, delete all existing site files to ensure that there are no malicious scripts or CMS scripts in which the attacker has inserted malicious code. This step is also important because when restoring a site from a backup, files that existed before the restoration are not always deleted. If, after restoring from a backup, old malicious scripts remain on the site, the attacker will be able to re-enter the site. You can avoid this by deleting all site files before performing recovery.

After deleting all site files, restore the site from a backup created before it was hacked. Often it is enough to restore only the site files, but if, after restoring them, errors are observed in the site’s operation, it is necessary to restore the site completely: both the files and the database.

After restoring from a backup, update your content management system (CMS) and extensions to the latest versions. This is necessary to exclude the presence of known vulnerabilities on the site through which it could be hacked. As a rule, the update can be done through the CMS administration section. For getting full instructions To update the CMS, you must go to the system developer’s website. It is important to update not only the CMS itself, but also all its extensions, since hacking often occurs through a vulnerability present in one of the CMS extensions (for example, plugins, themes, widgets, etc.). At this moment, it is still impossible to unblock the site for visitors, as it may still be vulnerable. To access your site for updating, contact the technical support of the hosting hosting your site and ask to allow access to the site only from your computer's IP address. You can find out your IP address, for example, at inet.yandex.ru.

After updating the site management system and its extensions, go to the site administration section and change the administrator access password to it. Make sure that among the site users there are no other users with administrative privileges (they could have been added by an attacker), and if any are found, delete them.

Now that the site has been restored from a backup and does not contain malicious scripts, the CMS and its extensions have been updated to latest versions, in which there are no vulnerabilities, and the access passwords to the site and hosting account have been changed, you can reopen the site to visitors.

All the above actions must be performed in accordance with the specified order, without omissions or any changes. If the actions are performed inaccurately, malicious scripts or vulnerabilities may remain on the site, as a result of which it can be hacked again by an attacker after a short time. If for some reason it is not possible to perform the above steps in the form in which they are indicated, contact a specialist to carry out work to restore the site after a hack.

To protect your site from repeated hacks in the future, you must adhere to the following recommendations:

Keep track of updates to the CMS and extensions for it on the developers' websites and promptly update them to the latest versions. If an update comment states that it fixes a vulnerability, install the update as soon as possible.

Work with the site and hosting account only from computers that are protected from viruses by modern antiviruses with constantly updated virus databases.

Use complex passwords so that they cannot be guessed through a dictionary search.

Do not save FTP and SSH passwords in programs for connecting to the site, and do not save the access password to the administrative area of ​​the site and the hosting control panel in your browser.

From time to time (for example, once every three months), change the passwords for accessing the site and hosting account.

If viruses were detected on the computer from which you were working with the site, change the passwords for accessing the site and hosting account as quickly as possible. It is necessary to change all passwords: access passwords via FTP, SSH, the password from the site’s administrative panel, as well as the password from the hosting control panel.

Do not provide access to the site to third parties unless you are confident that they will also follow these guidelines.

Malicious code gets onto the site through negligence or malicious intent. The purposes of malicious code vary, but essentially it harms or interferes with the normal operation of a website. To remove malicious code on WordPress, you must first find it.

What is malicious code on a WordPress site?

By appearance, most often, malicious code is a set of letters and symbols of the Latin alphabet. In fact, this is an encrypted code by which this or that action is performed. The actions can be very different, for example, your new posts are immediately published on a third-party resource. This is essentially stealing your content. Codes also have other “tasks,” for example, placing outgoing links on site pages. The tasks can be the most sophisticated, but one thing is clear: malicious codes need to be hunted and removed.

How do malicious codes get onto a website?

There are also many loopholes for codes to get into the site.

Most often, these are themes and plugins downloaded from “left” resources. Although, such penetration is typical for so-called encrypted links. Explicit code does not end up on the site.

The penetration of a virus when a site is hacked is the most dangerous. As a rule, hacking a site allows you to place not only a “one-time code”, but also install code with elements of malware (malicious program). For example, you find a code and delete it, but it is restored after some time. There are, again, many options.

Let me note right away that fighting such viruses is difficult, and manual removal requires knowledge. There are three solutions to the problem: the first solution is to use antivirus plugins, for example, a plugin called BulletProof Security.

This solution gives good results, but takes time, albeit a little. There is a more radical solution to get rid of malicious codes, including complex viruses, this is to restore the site from pre-made ones backup copies site.

Since a good webmaster does this periodically, you can roll back to a non-infected version without any problems. The third solution is for the rich and lazy, just contact a specialized “office” or an individual specialist.

How to Look for Malicious Code on WordPress

It is important to understand that malicious code on WordPress can be in any file on the site, and not necessarily in the working theme. He can come up with a plugin, a theme, or “homemade” code taken from the Internet. There are several ways to try to find malicious code.

Method 1: Manually. You scroll through all the site files and compare them with the files of an uninfected backup. If you find someone else's code, delete it.

Method 2: Using WordPress Security Plugins. For example, . This plugin has a great feature, scanning site files for the presence of other people's code and the plugin copes with this task perfectly.

Method 3. If you have reasonable support hosting, and it seems to you that there is someone else on the site, ask them to scan your site with their antivirus. Their report will list all infected files. Next, open these files in text editor and remove malicious code.

Method 4. If you can work with SSH access to the site directory, then go ahead, it has its own kitchen.

Important! No matter how you search for malicious code, before searching and then deleting the code, close access to the site files (turn on maintenance mode). Remember about codes that themselves are restored when they are deleted.

Search for malicious codes using the eval function

There is such a function in PHP called eval. It allows you to execute any code on its line. Moreover, the code can be encrypted. It is because of the encoding that the malicious code looks like a set of letters and symbols. Two popular encodings are:

Base64;

Rot13.

Accordingly, in these encodings the eval function looks like this:

• eval(base64_decode(...))
• eval (str_rot13 (...)) //in internal quotes, long, unclear sets of letters and symbols..

The algorithm for searching for malicious code using the eval function is as follows (we work from the administrative panel):

• go to the site editor (Appearance→Editor).
• copy the functions.php file.
• open it in a text editor (for example, Notepad++) and search for the word: eval.
• If you find it, don’t rush to delete anything. You need to understand what this function “asks” to be performed. To understand this, the code needs to be decoded. For decoding there are online tools called decoders.

Decoders/Encoders

Decoders work simply. You copy the code you want to decrypt, paste it into the decoder field and decode.

At the time of writing, I did not find a single encrypted code found in WordPress. I found the code from the Joomla website. In principle, there is no difference in understanding decoding. Let's look at the photo.

As you can see in the photo, the eval function, after decoding, did not display a terrible code that threatens the security of the site, but an encrypted copyright link from the author of the template. It can also be removed, but it will come back after updating the template if you don't use .

In conclusion, I would like to note, so as not to get a virus on the site:

• Malicious code on WordPress often comes with themes and plugins. Therefore, do not install templates and plugins from “left”, unverified resources, and if you do, check them carefully for the presence of links and executive functions of PHP. After installing plugins and themes from “illegal” resources, check the site with antivirus software.
• Be sure to make periodic backups and perform others.

Malicious JavaScript

My opinion, which is that it is easier and more effective to protect against injected malicious browser scripts (stored XSS attacks) using browser tools, was stated earlier: . Browser protection against JavaScript, which consists of adding filtering code to the website's html pages, is presumably reliable; however, the presence of such protection does not eliminate the need to also use a server filter. For the same XSS attacks, you can organize an additional line of defense on the server. We must also remember about the possibility of an attacker introducing not browser-based, but server-side scripts (php) into an HTML message sent from a site, which the browser will not be able to recognize.

An attacking script, whether browser-based or server-based, is a program; one must think that the program will always have some symbolic differences from “pure” html. Let's try to find such differences and use them to build an HTML filter on the server. Below are examples of malicious JavaScript.

XSS:

Some text

Some text

Encrypted XSS:

Some text

Some text

Browsers recover text from character primitives not only located inside html containers (between the opening and closing tags), but also inside the tags themselves (between< и >). URL encoding is allowed in http addresses. This makes it difficult to recognize malicious code on the server side, since the same character sequence can be represented in different ways.

XSS worms:

"+innerHTML.slice(action= (method="post")+".php",155)))">

alert("xss");with(new XMLHttpRequest)open("POST","post.php"),send("content="+_.outerHTML)

The above XSS worms are just a few of the many submitted to Robert Hansen's (aka RSnake) January 2008 competition for the shortest malicious JavaScript worm (contest results).

Signs of XSS attacks

An XSS script is a program that accesses DOM (Document Object Model) objects and their methods. Otherwise it is unlikely to be in any way harmful. For example, JavaScript string
onckick="var a = "xss""
does not affect the document object model, so even if embedded in an html tag, such a string is harmless. Only by manipulating HTML document objects and their methods can a hacker cause significant harm to a site. For example, the line
onmousemove="document.getElementsByTagName("body").innerHTML="XSS""
already replaces the contents of the page.

A sign of access to DOM methods is parentheses, as well as dots to the left of the equal sign. Parentheses can also be used in html to set a color in the rgb() format, however, the font and background colors in html are set in at least three more ways. Therefore, parentheses can be sacrificed without compromising the expressiveness of the html text. It is necessary to accept as a rule that the parentheses are inside the tag (that is, between< и >) - this is very dangerous, if we receive a message from a user on the server, this message contains brackets inside the tags, then the most appropriate thing we should do is block such a message.

The dot can be contained in html tags: when specifying the link address (tag ); when setting the size of html elements (style="height:1.5in; width:2.5in;" ). But character sequences of the form
letter point equals
cannot be in html tags. If the specified sequence is present inside an html tag, the message from the user most likely contains a script and should be blocked.

Another obvious danger sign is the "+" symbol inside the tag. There is no such thing in scriptless html. If we find pluses inside the tags, we mercilessly block the message.

To encryption with character primitives inside html tags, a well-intentioned site user adding a comment using visual editor, will never come running. The use of symbolic primitives in tags does not provide any benefits in the form of additional expressive means; it only requires additional writing time. In most cases, one would think that a well-meaning user does not even know that there are certain character primitives in HTML. Hence the rule: an ampersand inside a tag is evidence of an attack on the site. Accordingly, if we see this, we block the message.

A similar rule should be adopted regarding the "%" symbol, which can be used in url encoding. However, percentages are also used in “pure” html to set the relative sizes of elements. Dangerous combinations are those in which the "%" sign is immediately followed by a letter or number.

Neutralizing server scripts

Unlike JavaScript interpreters in browsers, the PHP interpreter on the server does not allow liberties when writing program text. Therefore, to neutralize a possible server script, it is enough to completely replace in the user’s HTML message all the characters that are essential when writing a PHP program with their HTML primitives. The first signs to be replaced are dollar and underscore, dot, round, square and curly braces, plus and minus signs, backslash sign.

PHP filter for HTML messages

$message is the html message received from the visual editor to the server.

// remember the length of the message $lenmessage = strlen($message); // cut out the comment tag $message = preg_replace("//", "", $message); // cut out every tag in which the "src" attribute refers to an external resource $message = preg_replace("/]+?src[\w\W]+\/\/[^>]+?>/i", " ", $message); // cut out every tag that contains any character except: - a-z 0-9 / . : ; " = % # space $message = preg_replace("/]+[^->a-z0-9\/\.\:\;\"\=\%\#\s]+[^>]+?> /i", "", $message); // cut out every tag that contains the sequence ". a-z =" $message = preg_replace("/]+?\.+?\=[^>]+?>/i", "", $message); // cut out every tag that contains the sequence "% a-z" or "% 0-9" $message = preg_replace("/]+?\%+?[^>]+?>/i", "", $ message); // cut out every tag that contains the sequence "script" or "js:" $message = preg_replace("/]*?script[^>]*?>/i", "", $message); $message = preg_replace("/]*?js:[^>]*?>/i", "", $message); // cut out every tag that starts with a character other than "a-z" or "/" $message = preg_replace("/]*?>/i", "", $message); // check: if the message is shortened, then terminate the program $lenmessage2 = strlen($message); if ($lenmessage != $lenmessage2) ( print "The message cannot be added"; exit; ) // perform end-to-end replacement of dangerous characters with their corresponding primitives $message = str_replace("$", "$", $message); $message = str_replace("_", "_", $message); $message = str_replace(".", ".", $message); $message = str_replace(chr(92), "\", $message); // \ $message = str_replace("(", "(", $message); $message = str_replace()", ")", $message); $message = str_replace("[", "[", $message); $message = str_replace("]", "]", $message); $message = str_replace("(", "(", $message); $message = str_replace()", ")", $message); $message = str_replace("?", "?", $message); // now the message has been verified, the scripts in it have been neutralized

It should be noted that the filter does not remove paired tags. Let's say we got
Click here!
The filter will only cut out the , but the paired (closing) tag will remain. If you send messages that contain tags without corresponding pairs to the browser, you may experience trouble in the form of a “skew” of the site. It is not known to which opening tag the browser will match the remaining unpaired closing tag. Therefore, and also for security reasons, messages in which something has been cut out by the filter should not be sent to the browser at all. It's better to print something like "The message could not be added" and exit the program.

The message is expected to be written to a file (not to a database).

Discussion

I will be grateful for criticism. Write to the support forum, in the section