When Linux antivirus lets you down: How to remove malware from a website manually

Manual-removing
PrevNext
Page 1 of 2

By Andrey Kucherov, Malware Analyst at Imunify360

The detection rates of anti-malware and antivirus scanners varies considerably. Knowing how to manually scan for and remove malware is an important and useful skill with which to confirm a scanner's effectiveness or compensate for its failings. In this article, Andrey Kucherov, Malware Analyst at Imunify360, describes some essential manual website malware detection and cleanup techniques. 

Introduction

The reality of modern security creates new challenges for web hosts every day. It is well known that there is no absolute protection that guarantees a 0% chance of your website being hacked. Even major players in online markets suffer from security breaches, and, from time to time, make users change their passwords "just in case".Usually, after getting into a victim's host, perhaps using some zero-day software vulnerability, brute-force attacks on weak passwords, or via infected "neighbor" sites, attackers will try to strengthen their positions by injecting additional malware into system folders. They may use malware such as web-shells or hidden uploaders, or they will attempt to insert 'backdoors' into a CMS's core files or into the website database. 

Different malware scanners can help you identify uploaded web shells, backdoors, phishing content, spam mailers and other types of malicious software—i.e., everything already known and encountered before. Some scanners, like ImunifyAV, have heuristic rule-sets that allow them to identify files containing suspicious code, with signatures matching those used by malicious scripts. They can also identify files with suspicious attributes that may have been uploaded by hackers. Unfortunately, even when using an antivirus scanner on your host after becoming infected, you may still be in a situation where not all malicious software has been identified. That means that intruders still have a 'back door' to your system, and can get there again any time they want. 

A modern hacker's scripts differ significantly from those that existed four or five years ago. Now, malware developers combine multiple techniques, like code obfuscation, encryption, decomposition, and external loading. They use many methods to bypass even the best antivirus software, so there is always a chance there might be something left behind on a server once they have departed. It may seem paranoid but probably you can't survive in the current security reality without some degree of healthy paranoia on your side. 

Example of a file containing malicious code

So, what you can do to effectively secure your website? A comprehensive approach must be used: initial automated malware scans must be followed by a manual check. In this article I will talk about how to identify malicious software without using malware scanners. 

Types of malware

First, let's review what we are going to be looking for: 

1. Hacker Scripts

Very often during an attack there are a number of files of a certain type uploaded onto a victim's system. These may be web shells (e.g. c99.php), backdoors, file uploaders, spam mailers, phishing pages, doorways (web pages that are created for the deliberate manipulation of search engine indexes), or defacement content (for example, the hacker's logo, obscene messages, links, etc.). In some cases you can simply search the name of the suspicious file on the web to find out what it does—script kiddies usually do not bother modifying files much so it will probably turn up in search results.

2. Code Injection

Code injection: A popular method of malware deployment onto a target system is via injections: malicious code can be injected into the .htaccess file to create SEO and mobile redirections; PHP or Perl script injections can be used to create backdoors; malvertising scripts can be injected into static .js (JavaScript) and .html files; and, very often, it can be a combination of injection into an existing file together with the uploading of a command and control script. For example, malicious code can be injected into the exif-header of a .jpg file, and the code can be triggered and executed by some other benign-looking file uploaded in another part of the website.

3. SQL Injection

Database entries are a frequent target for hacker attacks. Static HTML content injections are possible using tags such as <script>, <iframe>, <embed>, or <object>. Such unauthorized code insertions can redirect visitors to related but unaffiliated sites, embed advertisements from which the site owner does not profit, embed mining trojans (e.g. CoinHive JavaScript miner), or spy on users and infect their computers using drive-by attacks. Besides this, many modern CMSs (e.g. IPB, vBulletin, modx and others) use template processors that allow the execution of PHP code, and the templates themselves are stored in the database. This gives attackers the opportunity to add backdoors and webshells to the website template directly in the database itself.

4. Cache Injections

Due to insecure settings of a caching server, for example, when using memcached, some injections can be done on cached data on the fly. In some cases, spam can be injected into website pages without actually hacking the core functionality of a website.

If hackers are able to get privileged (root) access to a server, they can replace some web server components or caching server components with infected versions. Such a web server can then be controlled via remote commands, and it can add dynamic redirects and malicious code to different website pages. As with cache injections, a webmaster is usually not able to spot the infection because all user files and databases appear unaffected. This is the most difficult case, and in some situations it is easier to rebuild the server and migrate user data rather than try to detect all the malware.

5. System components replacement

By now, I'll assume that you've already checked the files and database dump with AV scanners and that they have not identified anything malicious. If the malicious redirect or script (embedded in the <script> tag) is still somewhere on the pages of your website, redirects will continue sending users to malicious websites.

How should you proceed? Read on to find out. 



PrevNext
A post-hack survival guide: cleaning your website ...
Imunify360 reduces hacking attempts by 90%

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Friday, 13 December 2019

Captcha Image