I refer to this topic ( http://www.wilderssecurity.com/showthread.php?t=48688 ) which has been closed by Wayne because he incorrectly assumed that I try to promote Ewido in the TDS forum ("This is the TDS forum, please plug your Ewido program elsewhere, thankyou."). Since it seems that even experienced people like Wayne have difficulties to follow me I will explain my comments in more detail. 1. The screenshot's purpose is neither to promote nor to bash Ewido. It simply illustrates the potential of static DLL injection. The screenshot ( http://home.arcor.de/testbed/ewido.jpg ) shows an infected Ewido Security Suite which listens on port 4004 for incoming connections. Moreover, the screenshot shows that Ewido Security Suite detects itself as malware and, therefore, tries to delete itself. This is because a trojan DLL was "hardwired" into the ewido program. The same trick does not work with TDS-3 or Trojan Hunter because these programs apparently have a better self-checking mechanism which will prevent them from starting after they were infected with a trojan DLL. Probably, there is also a way to infect TDS or Trojan Hunter. But it is more difficult and, moreover, it is unlikely that one of the three scanners will be infected at all after it was installed on the user's harddisk (see below - Second Scenario). The screenshot is not merely a bad news scenario for ewido since it also demonstrates that ewido has a module memory scanner. AFAIK TDS-3 does not feature a module memory scanner which is not a big surprise since TDS-3 has almost reached the end of its life circle. I would be surprised if TDS-4 also lacked a module memory scanner. A module memory scanner is necessary in order to detect compressed/protected trojan DLLs which cannot be unpacked by an unpacking engine. In particular, this applies to trojans protected with the help of certain commercial protectors. (I believe that Wayne's comment "Like TDS3, which lets you scan process, modules, mutexes, drivers, and everything else in memory." is somewhat misleading since it does not distinguish between module FILE scanning, module MEMORY scanning, object memory scanning and process memory scanning.) 2. Wayne also says: "So the 'script kiddie' has to be physically sitting at the victims computer in order to use this attack." and "To patch the IAT you need to modify the file. As soon as it executes, Process Guard will alert you that the file has changed, so you can block the execution." Again, this is a misunderstanding. It is necessary to properly distinguish between different scenarios which may lead to the infection of a computer. In the following, I want to address three scenarios involving DLL trojans which have one thing in common: Let's assume that a user voluntarily executes a heavily protected malware program which cannot be detected by a file scanner (regardless of whether it has an unpacking engine or not). If such malware program is executed a system firewall or an application firewall will ask the user whether the execution of the program shall be allowed. The user who has voluntarily started the program (e.g., because s/he assumes that the program is a valid, harmless application) will, of course, allow its execution. Now, let's have a look at the three different scenarios ... a) First Scenario The malicious program tries to inject a trojan DLL into a host application with internet access (e.g. Opera browser) by way of a method called dynamic DLL injection. Basically, dynamic DLL injection means that the memory of the host application is "infected". In such case a system firewall (like Process Guard, System Safety Monitor or Tiny Personal Firewall) will alert the user since a suspicious activity (e.g. dynamic injection via CreateRemoteThread) takes place. The system firewall will also allow the user to block the dynamic injection. In other words, the user is properly protected. In principle, there is no need for an AV/AT scanner at all. The first scenario describes one of the most likely situations which may currently occur if a hacker tries to attack you with a DLL trojan. b) Second Scenario The malicious program statically injects the trojan DLL into another host application (e.g. an internet application like Opera, ICQ or Edonkey) hoping that it will be able to connect to the internet via such host application for which a firewall allow rule may have been created. Static DLL injection basically means that the file of the host application is "infected" (e.g. static DLL injection is somewhat similar to a file virus). The second scenario is identical to the situation addressed by Wayne. The situation is relatively harmless. In principle, the user does not need an AV/AT scanner nor a system firewall in order to recognize that something is wrong. An ordinary application firewall (with MD5 checking capabilities) will alert the user that the host application that tries to connect to the internet (e.g. the statically infected Opera browser) was modified/tampered with. c) Third Scenario (Background: Many users download applications from filesharing networks or anonymous websites (i.e. from non-trustworthy sources). You may, of course, disapprove such activities. However, I guess that many AV/AT software developers will consider these users valuable customers.) In light of the above, it is easily possible that an application stemming from a non-trustworthy source arrives on a user's computer where it will be voluntarily executed. The application stemming from the non-trustworthy source may be statically infected with a protected DLL trojan which cannot be detected by an AV/AT's file scanner. Moreover, a system firewall will not help since the static injection has already taken place before the file is downloaded to the user's computer. A standard internet firewall may not help if the infected application is a program requiring internet access (which also applies to AV/AT scanners having an internet update function ;-) and, therefore, the users creates a firewall allow rule. Consequently, the only thing which may currently help the user is a module MEMORY memory scanner. In the future, other protection methods may be available. The third scenario is the nasty situation which I was talking about and which Wayne disregarded. Wayne may have disregarded this situation because - up to now - it was unlikely to happen. This is because the static injection method was only available to skilled attackers who know how to patch code into another application. However, this has changed with the release of certain fully-automatic tools which allow to statically inject a trojan DLL with a few mouse clicks. In conclusion, I would be extra careful before granting internet access to an application downloaded from a non-trustworthy source. 3. Last but not least, I would like to mention that I find it a little bit disappointing that most AV/AT software producers (i.e. I am not only talking about Wayne) frequently try to prevent discussions (like the above) from happening. I believe that it is not in the best interest of the users to be kept from acquiring information which is available to the bad guys anyway.