Understanding the Potential of Static DLL Injection

I refer to this topic ( https://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.

 

Thanx for this info about dll injection. again an interesting read.

 

As already posted on rokop, it's a sort of bug in the ewido integrity-check (missing check-data (has been overpatched) -> no notification) and will be fixed with the upcoming 3.0 version

 

yoeeehoeeeeee, this week fish??

 

Our internal deadline is now next monday and it looks like we're in time. Btw. we are currently implementing unicode support (interface + scan)

 

So much for a technical article, it reads more like a soap opera script. How about dropping the petty personal attacks and keeping on subject?

The thread was closed because the initial question had been answered and your post was just advertising for Ewido. Why do that behind an anonymous proxy?

Static DLL injection isnt anything new and exe 'binders' have been used for years, theyre probably even more of a threat than statically injected DLLs as two EXEs aren't as restricted as 1 EXE & 1 DLL (due to reliance on each other) and because there are so many binders around.

Regards,
Wayne

 

thanx for clarifying Fish, sounds perfect.

btw, to Wayne : don't get personal involved when the other one will not reveal anything. however saying this is a business strategy, I don't believe it but I wouldn't get personal...

just my two cents

 

People are probably wondering what static and dynamic DLL loading is ...

Lets say a program simply displays a messagebox "Hello World", so it uses the MessageBox function in user32.dll. If this is statically bound, a reference to user32.dll will appear in the "import table", which is a part of the file structure. If you try to run the program and user32.dll doesn't exist, Windows will stop loading the program and alert you that a required DLL wasnt found. If the DLL is found it's loaded into the process where it remains for the duration of the life of that process.

Dynamic loading occurs when the LoadLibrary system function is called, which loads a DLL in an "on-demand" manner. It can later be released with the FreeLibrary system function, and then again re-loaded if needed.

So as you can see they're very similar and each has its own subtle advantages and disadvantages.

What this anonymous guest is talking about is modifying an existing EXE so that it loads a DLL of his choosing. So for example, he could take mirc.exe, write a trojan DLL, and patch mirc.exe so that it automatically loaded the trojan DLL when mirc.exe was run. This is nothing new and it's been happening with EXE files for many years now using tools called 'binders' - mirc.exe was bound to trojan.exe to become one exe file, so that when mirc.exe was run, trojan.exe was dropped and executed.

The fact that there are now tools to automate the patching process doesn't change anything - it's still no bigger a deal than EXE binders, and it still requires the hacker to send a file to the victim (actually two files - a patched exe and a dll), and still requires the victim to execute the patched exe.

 

Infinity, with all due respect mate I'm not the one getting personal - it's my name that's being thrown around here.

 

@Wayne

"you've spent an entire article talking about me"

I would not talk about you if you did not close the topic. I simply do not like you to cut me off. Would you like being cut off?

"yet you're hiding as an anonymous guest"

I expressly said that I consider "to update the article" which implies that I am the author of the article, right? Therefore, I thought it is pretty clear, that, for instance, you and Fish know to whom you are talking. If not please let me know. In such case I will send you an e-mail. (Believe it or not I cannot log in right now since I do not have my password at hand.) If you also like me to confirm the above statement at a later time using a registered nick ... please let me know.

However, I still recommend that people should pay attention to the content of articles, statements etc. and not the name of the author. (This is not a celebrity show. And if I constantly mentioned my name you would probably attack me by saying that my real motive is not to inform people but to become some kind of an internet celebrity ... )

"and that they should get Ewido (interesting business strategy)"

Actually, I am not affiliated to Ewido. I could even imagine that they have the same bad feelings about me which you certainly have. For instance, I have posted at another place that the rebasing vulnerability has reappeared with the release of ewido plus.

Let's get things straight: Almost every AV/AT producer has a reason to hate me. Kevin does not like the BOClean report (although people now start to understand that a "recommendation with reservations" is still a recommendation ...). Kaspersky does not like me because I told people about things like Senna Spy's AVP Offset Generator. McAfee does not want to talk about weak signatures taken from the resource section. Ewido is unhappy about the rebasing discussion. Magnus would be happy if I did not mention TH's inability to detect many DLL trojans. And DCS gets mad if I do not constantly praise TDS or PG after joining their affiliate program.

"You're trying to scare everyone into thinking static DLL injection is the end "

I did not. I clearly pointed out that static DLL injection becomes dangerous only under certain circumstances (e.g. Scenario 3). Moreover, I would like to remind you that, some time ago, you also denied the fact that dynamic DLL injection could be dangerous. Of course this changed with the release of Process Guard (although it was initially promoted as an anti-termination tool ;-) Other security software developers similarly accuse me of causing fear and "havoc". For example, I was heavily attacked after mentioning that (i) a cracked version of Armadillo was offered for download by a RAT community and (ii) that no file scanner is able to unpack Armadillo.

I have to live with such negative feedback and I am prepared to do so. I will never be the friend of AV/AT software developers but I hope that at least a few users are interested in my comments.

Let me ask you one final question: What is more desirable ... that uninformed users buy an AV/AT product and feel safe or that informed users know about a good product's limitations and develop a strategy to avoid any residual risks (after buying that product)?

 

There is one important difference between good-old "binders"/joiners/droppers and static DLL injection:

A binder is something like a self-extracting archive which may contain one or more files (including trojans). Instead of a binder you may also use a commercial installer like Wise etc. which is even better, from a hacker's point of view, since many binders are detected as malware irrespective of whether harmless or malicious applications are bundled.

If you execute the bundle including the trojan executable the trojan will be placed on the victim's harddrive and be executed by the binder. This is a very basic, low-tech strategy (although it's frequently used). Let's assume that neither the binder nor the bundled trojan is detected as malware. Moreover, let's assume that a victim who has a system or an application firewall allows the launch of the trojan by the binder (spawning). In such case, the victim is simply infected with a standard trojan which will be stopped by the firewall.

DLL trojans in general are much more dangerous because they can bypass firewalls (cf. my article). Dynamic DLL injection is prevented by Process Guard and others. Static DLL injection is not prevented by a system firewall.

 

what about ewido then. except for the vulnerability is it really good which is a little contrastic. I think I know who you are but that doesn't matter at all. have you let ewido scan on your forum as I asked to??

 

oeps, sorry it is clear now.

 

Please note:

My second posting in this thread looks a little bit strange since the cites etc. do not apply anymore. This is because Wayne has edited his postings to which my cites referred. I guess he was just a little bit upset and has now reconsidered his statements.

I cannot edit my own comments but I am also not interested in a "personal" discussion. I believe that DCS develops good and interesting security software. Otherwise, I would not even talk about it.

 

I find all of this very interesting. It helps me to choose products that overlap the others weaknesses. Right now, there is no scanner that can do it all. I personally believe that several of the "right ones" are needed.

It is funny because I read a lot of Kaspersky vs NOD32 type things in these forums. After awhile, I have come to understand a user is better off with both rather than one or the other because one covers the others weaknesses.

I use two trojan scanners that I have chosen because each one covers the weakness of the other.

Now, I got a question....If you try to unload a statically injected program with something like DCS APM would it break the program since windows could not find the DLL? Would the whole program need to be deleted or is it possible to disinfect a statically injected DLL.



Starrob

 

I think you both get frustrated too easily

It seems like the article does lump together some things that TDS-3 handles and different issues relative to different kinds of users, ie hack tools & clients (which TDS doesn't handle UNLESS you turn on that option in 'scan control') Judging by the posts in the TDS forum that report TDS finding these things in memory, and advice involving using APM to fix it, I would conclude that TDS does detect injected DLLs. Of course, as stated, what TDS-3 (or anything else) may miss PG will block.

Honestly I don't see any attacks against TDS-3 as a product, but a reiteration of virtual motto of "layered protection", I really would be interested to see a breakdown of these different kinds of threats, their relavance to the home user, and maybe whats covered by TDS-4 vs TDS-3 in this particular area.

 

@Starrob

"If you try to unload a statically injected program with something like DCS APM would it break the program since windows could not find the DLL? "

I tried this out. System Safety Monitor was not able to unload the DLL. And APM also says that it "failed to unload the DLL". In other words, nothing is broken. It simply does not work ...

I am not sure whether this applies to each & every statically injected DLL.

@Notok

I completely agree with your last (third) sentence. ;-)

 

Maybe it is a good idea to pay a bit more attention to above posted quote.

And, BTW, having a good file integrity checker (Inspector in KAV Pers Pro, ADinf32 Pro, NISFileCheck to name a few) will also help you to detect whether there is a new file on your system (or an existing one changed, etc). No, they don't tell you whether such a file is malicious or not, but at least you know such a thing.

 

hi all,
(I'm having a hard time keeping up to date these days, it's a bit much "real life" taking its toll on me, so pls excuse me if I'm ignorant of some things that have happened/shown up recently or if I'm not responding (soon) to this thread again.)

first I'd like to have something cleared up: up to now I thought to have understood that static and dynamic dll injection are something different from static/dynamic dll loading. While Wayne has described static vs. dynamic dll loading above, I understood dynamic dll injection to mean that some malware injects a module into a live process (as one can do with APM), and static dll injection to mean that the "host" process itself loads the trojanized dll by some way (and I do have a question on that below). Isn't that correct? And isn't it then in fact something different from static/dynamic dll loading - or why is it the same?

Then another thing - the binders: As far as I understood the binder would be a more or less clever way to deliver your trojan to the destination. The advantage would be that the actual trojan executable would be bound to some other, legitimate app and would only be "dropped" when that app was launched. And then Wayne is right to point to the fact that you'd still have a trojan.exe which would have to be executed and could be caught at that point by several scanners. But what anonymous is talking about - AFAIU - is that the executable trojan code is not launched itself, but rather somehow planted into another app that is launched without raising the suspicion of the scanners. Now that does mean a challenge for the scanners because the trojan code would be in a dll that would be injected in some way into the "host" process and scanners that only do scan the main process when it launches will not detect it. (AFAIU ewido has such a module scanner, while TH hasn't and TDS-3 has a module scanner, but I'm not sure whether this scans the dll files that running processes refer to on disk or their modules in memory (in fact, I am now a bit confused as to what TDS's different scanners (object memory, process memory space, etc.) cover. All of this is even more subject to correction of course.)

Now something about the scenarios: I understood the catch to be the modification of the host program (the inclusion of another dll in the resource table) that would be noticed by the checksumming protection of a good firewall. But why would our trojan author create a brandnew trojan-code dll instead of patching his (or her) code into a dll that the host application loads anyway, so that the application wouldn't need to be changed, just the dll replaced. That would get past all checksumming that would only cover the executables themselves and not the dlls they load. Wouldn't it? I know it's a lot harder and entails reverse engineering an already existing dll and modifying it without breaking it, but there are a lot of very common dlls, and probably some of them even open source, so it would surely be an attractive approach - from the trojan author's perspective.

Some other aspect of this that has me thinking for quite some time now is the actual performance impact we'd have to expect if a) a "guard-type" scanner also scanned all modules that get loaded by all processes every time such a loading happens in memory and b) if a firewall or system firewall also "real-timeishly" checked the non-modification (checksum) of all used dlls (but this actually doesn't help in scenario c) ) ... and c) what kind of initial setup we'd have to go through as users if we had to acknowledge the initial integrity (i.e. the firewall getting the checksum in the first place) of all used dlls. All quite a lot, I assume, but has anyone spent some serious thought/calculations on it and has some more exact figures than "a lot" ? I think it is an important piece of information for thinking of a reasonable security strategy...


Andreas

PS. Starrob, if I understood it correctly what you can do about a statically infected program with APM is to dynamically unload the dll (edit: if you can, i.e. if it's working - seems not to work at least in some cases, although I do not see why it shouldn't). Whether that breaks the "host" program or not depends on the way the host depends on the trojanized dll. Not a lot in the scenarios anonymous has suggested, probably more in my variation described above. Anyway, that would effectively "un-trojanize" the app for as long as it was running. As soon as it would be re-launched, the static in[jf]ection would kick in again and you would have a time window to unload the trojanized dll with APM again. To get rid of the static infection, you'd have to remove or fix the host application itself (or replace the dll with the original in my variation of the scenario).

 

Hi Jan,

While I do agree completely about the need for a file integrity checker, I wonder if we need something to adress the need for real-time scanning or checksumming dlls at the moment when they're loaded - or whether or not this is covered by the apps you've mentioned.

Andreas

 

Hi Andreas !

Always a pleasure to read your postings !

No, those file integrity checkers do not act like real-time scanners.
(please note that I've just bought an upgrade to KAV Pers Pro (my KAV Lite licence expired), so I still have to get familiar with Inspector).

There is a (old, free) file integrity that runs in real-time:
File Change Alarm from Albert, who also made NISFileCheck.
Alas both NISfileCheck and File Change Alarm are no longer maintained; it is really a pity.
I myself am still on Windows 98 SE, so I cannot run File Change Alarm (you need something like W2000 or XP).
What I understood about File Change Alarm is that, although it runs in real-time, it will not prevent a file change but only give you an alarm.

However there is another file integrity checker that runs in real-time and that might not only warn you about a file change but might also prevent it.
It is Alfa File Protector and Alfa File Monitor.
However it is a very expensive program; I am talking here about several thousands of US Dollars. I don't have it...

Cheers, Jan.

 

"first I'd like to have something cleared up: up to now I thought to have understood that static and dynamic dll injection are something different from static/dynamic dll loading. While Wayne has described static vs. dynamic dll loading above, I understood dynamic dll injection to mean that some malware injects a module into a live process (as one can do with APM), and static dll injection to mean that the "host" process itself loads the trojanized dll by some way (and I do have a question on that below). Isn't that correct? And isn't it then in fact something different from static/dynamic dll loading - or why is it the same?"

IMHO, the main difference between dynamic DLL loading (LoadLibrary) and dynamic DLL injection is indeed that dynamic DLL injection (e.g. via CreateRemoteThread) loads a DLL into the memory of another, already running process (which is a suspicious activity that can be detected and blocked by a system firewall). See: http://www.codeproject.com/dll/DLL_Injection_tutorial.asp

Static DLL injection can be achieved either with the help of dynamic DLL loading (LoadLibrary) or with the help of static DLL loading (IAT): you simply need to patch the host application in the desired way. I agree that the use of the term static DLL injection is somewhat confusing because it also refers to dynamic DLL loading. I have not invented this term ...

(Btw.: You may conclude from the fact that you are unable to unload a statically injected DLL that it was also statically loaded.)


"what anonymous is talking about - AFAIU - is that the executable trojan code is not launched itself, but rather somehow planted into another app that is launched without raising the suspicion of the scanners."

Right: If you use a binder (bundling a harmless application and a trojan) a separate trojan executable will be launched and may be detected. Even a completely unknown trojan for which no AV signatures exist will be detected by a personal firewall. By contrast, if you statically inject a trojan DLL into a trusted host application only the host application will be launched. No suspicious activities take place.

"AFAIU ewido has such a module scanner, while TH hasn't and TDS-3 has a module scanner, but I'm not sure whether this scans the dll files that running processes refer to on disk or their modules in memory"

I also believe that ewido has a module MEMORY scanner. TH may have one, too. However, it's hard to tell since it does not detect any of my trojan DLLs. Apparently, there are no signatures?! AFAIK TDS-3 has only a module FILE scanner (i.e., a simple file scan will take place in respect of any modules loaded by a process and, consequently, compressed/protected DLLs cannot be detected).

"But why would our trojan author create a brandnew trojan-code dll instead of patching his (or her) code into a dll that the host application loads anyway,"

A script kiddy may be unable to code and, therefore, will not use its own code. It will simply use a known trojan DLL (like Beast or ColdFusion), compress it or protect it with a commercial protector, and then statically inject it into a host application (with the help of an automatic tool). Thereafter, the host application is shared via a filesharing network. In other words, no coding but only mouse clicks are necessary.

The other possibility which you address is indeed nasty ;-)

 

https://www.wilderssecurity.com/archive/index.php/t-12834.html

 

what now - the thread Notok pointed to says that by using TDS's process viewer, select your process and view its modules and then press scan modules, you are in fact memory-scanning the dlls. Whereas anonymous maintains that TDS only features a file-scan for dlls (which, being a file-scanner, is architecturally vulnerable for it can be bypassed by packers/crypters etc.).
The (lack of) ease of use of the method described above aside, is it now memory scanning dlls or is it not?
(and if it is, are we having a signature discussion?)

Andreas


PS.

If I understood correctly, this applies to static injection by modifying the IAT (thus creating a static loading), not by patching some dll (that saves the host apps method of loading this dll, which can well be dynamically).

 

"If I understood correctly, this applies to static injection by modifying the IAT (thus creating a static loading), not by patching some dll (that saves the host apps method of loading this dll, which can well be dynamically)."

Yes.

"what now - the thread Notok pointed to says that by using TDS's process viewer, select your process and view its modules and then press scan modules, you are in fact memory-scanning the dlls. Whereas anonymous maintains that TDS only features a file-scan for dlls (which, being a file-scanner, is architecturally vulnerable for it can be bypassed by packers/crypters etc.)."

I continue to believe that there is no module MEMORY scanner and, AFAIK, DCS has never purported that there is one. They simply said that there is a module scanner. Moreover, in the thread cited by Notok it merely says that "TDS-3 does detect ColdFusion 1.0 and Assasin 2.0 trojan DLLs running in memory" which does not necessarily mean that TDS has a module MEMORY scanner: There is simply no distinction between module MEM scanning and module FILE scanning (i.e., you can also use a file scanner for scanning any modules running in memory).

Already at that time, I supposed that there is no module MEMORY scanner and, therefore, DCS (Gavin) was privately informed that TDS fails to detect compressed DLLs running in memory. I did not disclose this information to the public because (a) there was no alternative AV/AT with a working module memory scanner and (b) I was reluctant to talk about these issues which were rather new and did not belong to the standard knowledge of each script kiddy.

If you want to test whether TDS has a module file scanner or a (working) module memory scanner you can do the following: inject a trojan DLL with APM into notepad. Perform a module scan with TDS. The DLL should be detected. Thereafter, create a rule with Tiny Personal Firewall that disallows TDS to access the folder in which the DLL is stored. Again, perform a module scan. The DLL should still be detected if there is a (working) module MEMORY scanner. It will not be detected if there is only a module FILE scanner or a non-working module memory scanner. We have used the same method for our BOClean report. (In respect of BOClean the developer says that there is a module MEMORY scanner which is not frequently used.)