Introduction The threat: modified malware frequently remains undetected. Background Dangers resutling from run-time compression and other modifications. Example Two widely-used AV scanners are outfoxed. AV Reviews Sense and non-sense of AV reviews Scanners We examine the modes of operation and detection rates of several AV & AT scanners Forum ... and you can participate

 

Wolves In Sheep's Clothing: Malicious DLLs Injected Into Trusted Host Applications



The injection of malicious dynamic link libraries ("DLLs") into trusted host applications can be considered one of the trojan scene's most recent hypes. This article provides you with the background knowledge to understand several common injection techniques and helps you to assess the potential dangers arising from DLL injections.


1. Dynamic Link Libraries are ... ?

Just in case you don't know what we are talking about. Dynamic link libraries are a feature of the Windows OS. They can be described as code libraries (containing executable routines) that are separately saved as files with the extension .dll. Because DLLs do not constitute stand-alone programs they cannot be independently executed but have to be loaded by another application before they become active. Usually, a DLL is loaded into the memory by an application that wants to use it. By contrast, trojan DLLs are "injected" into other applications ("hosts") and try to abuse them. After the injection has been finished a trojan DLL can be considered a part ("module") of the host application ("process"). Although the trojan DLL is a mere module of the host process it can perform the same actions like a nasty stand-alone trojan executable.


2. Are there really DLL trojans "in the wild"?

Definitely. It started about two years ago with firewall leaktests like "Firehole". The aforementioned leaktest injected a harmless DLL into a trusted application with internet access in order to demonstrate the limitations of personal firewalls' outbound filtering capabilities. As far as we know, the first publicly released DLL trojans were Setiri and Optix Lite (Special Edition) Firewall Bypass. These trojans were followed by Assasin 2, Aphex FTP, Beast 2, Coldfusion, Institution FWB, Nuclear Uploader and several others. It can be taken for granted that countless second class trojan coders will try to understand the concept of DLL injection in order to create their own super-stealthy, firewall-tunneling Uebertrojans.


3. What's so special about DLL trojans?

From a trojan coder's perspective, DLL trojans offer many advantages:


(a) Stealth

DLL trojans are relatively stealth. This is because they do not show up in the Windows Task-Manager which merely lists processes but not modules (DLLs).

Fortunately, there are several advanced process monitors like "TaskInfo", "System Analyzer", "Process Explorer" (a freeware tool from Sysinternals) and "APM - Advanced Process Manipulation" (a freeware tool from DiamondCS) which allow a computer user to inspect the modules loaded by a process. It is still difficult to detect a DLL trojan though because (i) there are dozens if not hundreds of modules to inspect (unless you already know the infected process) and (ii) there is no easy way to determine whether a DLL is malicious or not (e.g., the DLL trojan may look like a harmless Microsoft DLL).

Moreover, DLL trojans cannot be easily exposed by a firewall (see below). In case that a DLL trojan fails to bypass a firewall and triggers an alert the ordinary user may not expect to have found a trojan but to have experienced a relatively harmless "phone home" originating from a trusted application.

A DLL trojan's filename may be invisible. For instance, the DLL trojan Nuclear Uploader offers basic root kit functionality: it injects itself into the Windows Explorer and hides certain filenames (e.g., the trojan files) from the user.


(b) Hard To Kill

It can be quite difficult to get rid of a DLL trojan if it is injected into a critical system process which cannot be terminated. For instance, the DLL trojan Beast 2 injects itself into the winlogon.exe process. (It is still possible to remove this trojan if you reboot the computer in "Safe Mode" or unload the DLL from the winlogon.exe process with the help of a tool like Trojan Hunter.) Other DLL trojans infect almost every process they can find in order to complicate their removal.


(c) Firewall Tunneling Capabilities

DLL trojans have the capability to tunnel not only routers and port-based firewalls but also personal firewalls (with application filtering rules). This is because DLL trojans can be injected into trusted host applications. In principle, there are two types of firewall tunneling DLL trojans: server DLLs and client DLLs.

Server DLLs are acting like a standard trojan. They open a port and passively listen for incoming connections. Server DLLs are usually injected into trusted server applications which are expressly allowed to listen. For instance, a server DLL may be injected into into a web server, ftp server or any other application for which a firewall rule has been created that allows incoming connections. A tight firewall rule set may help to prevent server DLLs from abusing trusted server applications. For example, a web server which is only permitted to listen on a single port cannot be easily infected by a DLL trojan because generally the DLL trojan will be unable to share the permitted port with the infected application. However, there are numerous server applications (like filesharing tools) for which it is not possible to create such a tight firewall rule set.

Client DLLs (so-called reverse trojans) are not listening for incoming connections but actively establish outgoing connections. Usually, client DLLs are injected into trusted client applications (like web browsers, email programs or FTP clients) which are allowed to connect to the web. For example, a client DLL may abuse the iexplore.exe process in order to connect to "www.remote-control.heaven.org". This means that an outgoing connection is established from local port 1024-5000 to remote port 80. It is not possible to create a tight firewall rule set in order to avoid outgoing connections via local port 1024-5000 since outgoing connections cannot be restricted to a single local port: the Windows OS dynamically assigns local ports to applications which want to establish outgoing connections. (It is also not feasible to disallow any connections to remote port 80 because this would make it impossible to surf the web.)

In principle, modern personal firewalls like Outpost 2 or Sygate Pro 5 have the ability to warn a user if a DLL is injected into a trusted application like Internet Explorer. However, the alert messages are usually inexpressive (and annoying because in most cases not DLL trojans but completely harmless DLLs are loaded into the trusted application). See also http://www.securityfocus.com/bid/9312/discussion/


4. Common Injection Techniques

Basically, there are two ways to inject a DLL trojan into a trusted host application. These ways are called dynamic & static DLL injection.


(a) Dynamic DLL Injection

This shady technique is the most frequently used way to activate DLL trojans: a loader application, which belongs to the DLL trojan, injects the trojan DLL into a host application which is already running or which has previously been started by the loader.

Technically speaking, the loader application allocates a memory region inside the host process, writes into this memory region and forces the host process to load the trojan DLL. The key functions used to perform the injection are VirtualAllocEx, WriteProcessMemory and CreateRemoteThread. Trojan coders Aphex and Rezmond made the VX community happy by publishing the respective source codes. Moreover, there are several injection tools (Aphex Inject, Nuclear Inject etc.) which allow even script kiddies to inject DLL trojans into trusted host applications. Fortunately, these tools are detected as malware by many AV scanners.

We have called the dynamic injection technique "shady" because we believe that there is generally no legit reason to hijack other applications and perform functions like CreateRemoteThread. In other words, standard applications should not use this technique at all. If they do, they are highly suspicious. (This does not apply to certain system level applications.) In the last part of this article, we will make you familiar with two security tools that can prevent applications from (ab)using the function CreateRemoteThread.

(Please note that it is also possible to use the function SetWindowsHookEx for injecting DLLs. However, we do not know any trojans using this technique.)


(b) Static DLL Injection

Static DLL injection is a less frequently used but highly effective and dangerous technique to inject DLL trojans into trusted host applications. Broadly speaking, static DLL injection means that the code required to load the trojan DLL is patched directly into the host application. In other words, the host application is permanently infected and will load the trojan DLL (in addition to other harmless DLLs) each time it is started.

Static DLL injection has the "advantage" that a primitive loader application (and a conspicuous autostart entry in the registry) are not required. In addition, it is not necessary to use shady functions like CreateRemoteThread in order to have the DLL loaded (i.e., the standard LoadLibrary function can be used).

Consequently, it can be very hard to determine whether an application has been infected by means of static DLL injection. Primary targets for static DLL injection are applications which are traded via filesharing networks etc. In particular, internet applications like ftp clients & servers, webcam tools, filesharing clients and instant messengers are endangered. Other potential targets for static DLL injection are standard Microsoft applications like Internet Explorer or Outlook (Express). Fortunately, those applications which are monitored by the Windows System File Protection can be less easily infected. Moreover, firewalls which perform MD5 signature checks, will alert the user if an existing application has been modified by static DLL injection.

We feel that it is difficult to say whether there are few or many statically infected host applications "in the wild". This is mainly because most static DLL injections will remain undetected. We know for sure, however, that trojan coders are trying to perfect this injection technique: the source code for an automatic static injection tool has already been revealed. Fortunately, this particular source code is buggy and uses viral code so that the patched target application will be detected by AV scanners.

(c) Final Note

This article is not meant to be a tutorial for trojan coders. Therefore, we do not publish the source codes for dynamic DLL injection. Moreover, we do not discuss the particulars of static DLL injection (like entry point redirection and redirection from jumps). However, we would like to clarify that neither dynamic nor static DLL injection require any sophisticated programming skills. It takes virtually no time to compile the source code for a dynamic DLL injector and also static DLL injection can be done within less than a minute. Therefore, we believe that these injection techniques are not merely a theoretical threat.

We have collected/prepared a modest selection of trojan samples which demonstrate both injection techniques. The samples can be sent to AV/AT software producers upon request. Anybody else is invited to try the above-mentioned APM tool from DiamondCS which allows you to dynamically inject DLLs into running processes.


5. How do AV/AT scanners detect DLL trojans?

Well ... they rarely do! Please note that users of DLL trojans are not stupid. It is common practice not to use a DLL trojan right "out of the box" since the standard distribution package (i.e., a bundle of files containing the loader application, the DLL trojan, etc.) is detected by almost every AV/AT scanner. Consequently, DLL trojans are frequently hexedited and protected with an executable compressor or crypter. An undetectable custom loader takes care for the injection.

For this reason, we believe that a good AV/AT scanner must be able to detect not only the standard distribution package or the loader application but the DLL trojan itself. We therefore compiled a sample test with a few DLL trojans stemming from our new test archive. (The new test archive which covers a reasonable selection of DLL trojans will be used for any future comparisons.)

The above mini archive contains a number of compressed/crypted DLLs. Moreover, there are DLL trojans which have been hexedited or increased in size. Finally, we modified or compressed the resource section of several trojans.


(a) AV Scanners /w Unpacking Support

Kaspersky Anti-Virus and McAfee VirusScan were chosen as representatives of a class of AV scanners with unpacking support.

Kaspersky did a relatively good job and detected 20 out of 22 DLL trojans. However, it failed to detect the malware samples packed with PKLite and Armadillo. This suffices to make any DLL trojan a gatecrasher. In addition, there are already many trojan users who employ advanced camouflage techniques (like patching and entry point obfuscation) which make an AV scanner like Kaspersky almost useless.

McAfee performed significantly worse than Kaspersky. It missed more than 50% of the malware samples. One thing that we found especially annoying is that the scanner failed to detect DLL trojans with a modified resource section (e.g., DLL trojans with a replaced icon). Although the resource section of a file can be easily modified with tools like "Resource Hacker" McAfee still uses such "weak" signatures in order to detect trojans. An excellent example of illusive security ...

__________________________________
Scan engine v4.2.40 for Win32.
Virus data file v4283 created Aug 06 2003
Scanning for 77927 viruses, trojans and variants.

Options:
TESTDIR\*.* /ALL /SECURE /L /PANALYZE /PROGRAM /REPORT ZZZ_ERGEBNIS.TXT

ORG.AphexFTP.UPX.dll ... Found the BackDoor-AHZ trojan !!!
ORG.Beast201.notpacked.dll ... Found the BackDoor-AMQ trojan !!!
ORG.Coldfusion108.NotPacked.dll ... Found the BackDoor-AOP.svr trojan !!!
PECompact150.Coldfusion108.dll ... is OK.
Petite22.AphexFTP.dll ... Found trojan or variant BackDoor-AHZ !!!
Petite22.RESCCOMPR7.Beast201.dll ... is OK.
Petite22.Weak8.Beast201.dll ... is OK.
PKLite3211.AphexFTP.dll ... is OK.
RESOURCE.ICONREPL.Assasin20.NotPacked.dll ... is OK.
RESOURCE.RESCCOMPR.Beast201.Petite22.dll ... is OK.
tELock098.Coldfusion108.dll ... is OK.
UNPACKED.AphexFTP.dll ... Found trojan or variant BackDoor-AHZ !!!
UPX190b.Coldfusion108.dll ... is OK.
ADDBYTE.10034.Coldfusion108.NotPacked.dll ... Found trojan or variant BackDoor-AOP.svr !!!
Armadillo301.Coldfusion108.Hexedited.dll ... is OK.
ASPack212.Coldfusion108.dll ... is OK.
ASProtect11.Coldfusion108.dll ... is OK.
HEX.AphexFTP.UNPACKED.dll ... Found trojan or variant BackDoor-AHZ !!!
HEX.Coldfusion108.NotPacked.dll ... Found trojan or variant BackDoor-AOP.svr !!!
HEX.SimpleRename.Beast201.notpacked.dll ... Found trojan or variant BackDoor-AMQ !!!
JDPack101.Coldfusion108.hexedited.dll ... is OK.
Netwalker.Coldfusion108.Win98.dll ... is OK.

Summary report
File(s)
Total files: ........... 22
Clean: ................. 13
Possibly Infected: ..... 9
_________________________________

(b) Memory scanners

Because even prominent AV scanners with unpacking support are not able to reliably detect DLL trojans we tried a memory scanner instead. TDS-3 from DiamondCS was our premier choice. The good thing is that TDS-3 is able to automatically detect the Beast 2.01 trojan in memory if you enable the option "Object Memory Scan".




The bad thing is that TDS-3 did not automatically detect any other DLL trojans in memory, not even the widely-spread Assasin 2.0. It is necessary to open the TDS-3 process viewer and manually scan the modules of every active process in order to detect trojan DLLs. This procedure is quite uncomfortable and time consuming.





In addition, TDS-3 failed to detect a hexedited Beast 2.01 trojan because it uses a string containing the trojan's name as a signature (i.e., TDS-3 uses the most insecure signature you can possibly imagine).








Note: According to our experience, other memory scanners like BoClean or TrojanHunter do not use "stronger" signatures than TDS-3. We believe that any of these AT products could significantly improve its performance if their makers kept an eye on signature quality. (N.B.: TDS-3 uses different signatures for file scanning. Unfortunately, it does not have an unpacking engine and, therefore, its file scanner detected only 6 out of 22 DLL trojans. )


(c) Conclusion


There is currently no reason to believe that an AV/AT scanner will reliably protect you from DLL trojans.


6. How can I protect myself?


It goes without saying that the exclusive use of software stemming from trustworthy sources (not including filesharing networks, IRC channels, Newsgroups, and e-mail attachments) will significantly reduce the risk of being infected by any trojan. In addition (or alternatively) you may consider some of the following options:


(a) Be extra careful when using filesharing networks. Reconsider twice whether it is wise to grant internet access to an application which you have downloaded from a non-trustworthy source.

(b) Surf a little bit. Thereafter, close the Internet Explorer (but do not close the internet connection). Open a process monitor like Process Explorer or APM. If you can still see a task called "iexplore.exe" (i.e., a hidden Internet Explorer window is still open) you may be infected. In such case you can inspect the modules loaded by iexplore.exe (or any other suspicious process) in order to determine the name of the malicious DLL. If you are in doubt you may ask for expert help in a computer security forum.

(c) Use a freeware tool like TCPView (from Sysinternals) and check any open ports on your computer system. Make sure that you exactly know why a port is open.

(d) Use a personal firewall and create a tight firewall rule set. Stop any applications from phoning home.

(e) Create a firewall rule set which blocks your standard browser. Use alternative browsers like Opera, Mozilla or Firebird instead.

(f) Check out a security tool called "System Safety Monitor". It will help you to block dynamic DLL injection by means of "CreateRemoteThread" and "SetWindowsHookEx".




(g) Alternatively check out "Tiny Personal Firewall". This firewall uses sandbox technology and will inform you if dynamic DLL injection takes place. (Please note that Tiny Personal Firewall is quite difficult to configure.)







(h) Use a freeware tool like Autostart Explorer (from Mischel Internet Security) and check your autostart entries. Use several AV/AT scanners. Be careful and good luck ...


ntl, 10 August 2003