Removing website malware the manual way

Removing website malware the manual way

How do we manually remove website malware? As a webhoster (www.linix.eu) / website owner (schalley.eu), I daily face websites being compromised. It doesn’t matter how hard you try, it’s not really possible to reduce the chances of being hacked to 0.

So here is my 50 cent’s on how to manually remove malware when your anti-virus didn’t catch it.

Malware techniques

Malware can get into your systems in various ways. One popular way is via injections attacks. Injections happen when an attacker inserts a file, in-memory cache or database entry into a system component.

Code injection

  • Inserting code into existing PHP or Perl programs to create backdoors or automated uploaders.
  • Modify the contents of the .htaccess file to redirect visitors to other sites for the purpose of phishing or SEO hijacking.
  • Alter JavaScript (.js) and HTML files to insert unwanted advertising scripts or content (so-called malverstising).
  • Modification and usage of Exif information by an attacker (meta-data to add info to image files eg. JPG) to carry malicious payloads to other parts of the file system or other sites.

Hackers will often take full advantage of their position, and plant malicious code in multiple places.

Cache injection

Cache is a small, high-performance store of memory. If you don’t secure the server that maintains the caches, then memory can be overwritten in situ. If the affected portion of memory is a cached version of a web page, then a hacker can inject code or malicious content without changing website functionality or content on the hard disk where the website is located on the webserver.

Malware scripts

Malware scripts can take many forms, and serve many purposes. Scripts for back doors, uploaders, spammers, and phishing links can create web doorways, or site entry points to manipulate search engine indexes. Hackers can also create defacement scripts simply to cause damage, or boost their own ego.

Replacing system components

Every hacker wants root access to your server, so they can replace any web server component with their own malicious version. Attackers can control entire sites, and add or modify their behavior as they need. They can also remotely control the script to issue redirects or new portions of malicious code. If an attacker hides this component carefully, then it’s difficult to detect. Because the website appears to be working normally.

How to manually remove malware and repair your website

Use the following manual inspection techniques to make sure your system a good job and start to manually remove malware.

IMPORTANT: Before continuing, ensure you have a full and working backup of your entire system.

File scanning

Traditionally, Linux-type systems have limited facilities for detailed file scanning and inspection. So let’s use what we have, in the form of find and grep. First, by searching the file system for all modified files within the past 7 days, where the file name extension begins with ph (to cover .php and .phtml):

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

However, what if a hacker considers this first? And resets file modification dates. Then check to see if file attributes have changed. Here’s how to do that for .phtml and .php files.

find . -name '.ph' -ctime -7

We can narrow down the period we’re looking at, by using the newermt option of find. To look for a file changed between the 25th and 30th of January 2019:

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

Now we can introduce the grep command. This can recursively scan for and report patterns in files. To look for a portion of a URL in any file in the current directory, or any within it:

 grep -ril 'example.com/google-analytics/jquery-1.6.5.min.js' * 

Permissions checks

If you suspect a breach in your web server or file system, check file permissions. You can do this with the following command:

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

Check for active processes

If a file system scan shows nothing unusual, take a look at what’s running on the system. See what PHP scripts are running using:

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

Analyzing malicious code: what to look for

You now know some of the basic techniques to search for files and file content. To go deeper when you manually remove site malware, you need to know what to look for. Here’s a helpful checklist.

Check rarely visited directories

System administrators rarely look in directories like upload, cache, tmp, backup, log, and images, making them ideal locations for hackers to hide malicious files.
Note: On PHP-based CMS’es such as Joomla, check directories for .php files in the wrong places. If you’re on a WordPress site, check the wp-content/uploads, and the backup and theme cache directories.

Here’s an example of a command that checks for PHP files in an images folder:

find ./images -name '.ph'

Treat any similar files in such places suspiciously.

Files with strange names

Even though file names come in a wide variety, certain names should raise a red flag. Here are some examples:

  • php (no extension)
  • fyi.php
  • n2fd2.php

Note any unusual patterns or combinations in file names, letters, symbols and numbers. File names that are naturally unreadable are:

  • srrfwz.php
  • ath.php
  • kirill.php
  • b374k.php.php (double extension)
  • tryag.php

Hackers also exploit the habit of some programs that append numbers to copies of existing files. So lookout for files like:

  • index9.php
  • wp3-login.php

Look for unusual file name extensions

You don’t normally associate certain file name extensions with CMSes like WordPress. So if you see any of these, take note:

  • .py (Python code extension)
  • .rb (Ruby code extension)
  • .pl (Perl code extension)
  • .cgi (CGI code extension)
  • .so (Shared object extension)
  • .c (C source code extension)

Moreover, you also wouldn’t expect to find files with extensions like .phtml or .php3. If you discover any of the above on a PHP-based CMS website, then you should inspect it closely.

Look for non-standard attributes and creation dates on files

Another sign of suspicious files involves the file owner attribute. So you need to watch out for the following:

If you see a number of .php files sent to a server via ftp or sftp were transferred with the owner attribute set to myuser. But in the same directory you see files where the owner attribute is www-data.

You must also check script creation dates. If the date is earlier than website creation, then you need to be suspicious.

Look for large numbers of files

Directories containing hundreds or thousands of files are good places for a hacker to hide malicious scripts and payloads. Such large numbers of files indicate a doorway, or a form of blackhat SEO.

You can detect such directories with the find command. We recommend you start in a specific directory to limit your search and avoid overloading the system. The following example helps you find the top 25 directories with the largest number of files.

find ./ -xdev -type d -print0 | while IFS= read -d '' dir; do echo "$(find "$dir" -maxdepth 1 -print0 | grep -zc .) $dir"; done | sort -rn | head -25

Checking your server logs

You can also check any system through an inspection of the server log files. Here you can learn many things. For example:

  • Telling how spam email was sent (when and where it was sent from, the access_log file, and what script invoked the mail command).
  • Check FTP logging. Tools such as xferlog tell you what was uploaded or changed, and who did it.
  • Discover the location of any mail-sending PHP scripts with the correct configuration of your mail and PHP servers.
  • Check to see whether your CMS has additional logs to help you track down the source of an attack. This might help you determine whether an attack was external or came in via a CMS plugin.
  • Both access_log and error_log files are good sources of information. If you know which scripts are the attack vectors, you may be able to find the source IP address, or the HTTP user agent value. You may also be able to see if a POST request was made at the same time of the attack.
grep "POST" /var/www/vhost/domain/log/access_log

Checking the integrity of files

You deal with attacks more easily if you have adequate preparations in place, like recording the state of files in their pristine state. You can then compare them to the same files after an attack. You can do this in various ways:

Use source code control systems such as git, SVN or CVS. In case of git, you can simply utilize these commands:

 git status 
 git diff

Using source code control ensures you have a backup copy of server files. You can restore these easily in the event of a cyber attack.

Tools that can alert you when anything on a file system changes include:

In some cases, version control isn’t possible. For example, when using shared hosting. One workaround is to use CMS extensions or plugins to monitor file changes. Some CMS’es even have their own built-in file integrity.

Note : for WordPress, look into WP security

You can keep track of what files you have at any one time with the command to catalog all the files on a system:

ls -lahR > original_file.txt

You can compare this file later with a fresher copy using comparison tools like WinDiff, AraxisMerge Tool, BeyondCompare, the Linux diff command.


Source : www.plesk.com

Leave a Reply

Your email address will not be published.

sixteen − sixteen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.