I have been doing a lot of reading about DLL Injection. It is more scary than I at first realized. I know many people might think they have great protection but after reading a few things it appears that it is difficult for just about all the scanners to detect DLL injection trojans that are modified. That includes the scanners that many consider top of the line like Kaspersky, TDS-3, Mcaffee, Trojan Hunter and Boclean. Until these scanners improve to truly deal with this threat, I feel that probably only Process Guard, System safety Monitor and Tiny Firewall are most likely the only reliable protections from this threat. I am sort of new to learning about security and for me Process Guard is the simplest of these programs to learn and configure. I just have one question. Does Process Guard protect against ALL methods of DLL injection? Does it protect against Static as well as dynamic injection? Does it protect it block dynamic DLL injection by means of "CreateRemoteThread" and "SetWindowsHookEx"? Thank you for your answer. Starrob
Hi Starrob, Yes it does Please visit the following link for more in depth information: http://www.diamondcs.com.au/processguard/index.php?page=attacks HTH Pilli
You can also use our Advanced Process Termination tool to test to see if a process can be terminated by using DLL injection techniques: http://www.diamondcs.com.au/index.php?page=apt Process Guard already protects against all of the termination methods that APT uses, and a new version of Process Guard and a new version of APT are just around the corner. Registered users will be able to upgrade to the new Process Guard for free.
"Does it protect against Static as well as dynamic injection? " PG does not protect against static DLL injections. (Note that this not the fault of PG: static DLL injection means that a malicious DLL is loaded because (i) a LoadLibrary has been patched into a host application or (ii) the IAT of the host application has been manipulated. Because PG is not a malware scanner it cannot detect whether a host application was patched or not.) PG does protect against the most frequently used way of dynamic DLL injection (i.e., use of CreateRemoteThread function). I am not so sure whether PG protects against each way of injecting a DLL via the registry.
Is there any application that gives protection against static DLL injection? How would a person go about defending against static DLL injection? I ask these questions because Microsoft is starting to take security more seriously and with sp2 people are becoming more aware that they should do things like run a firewall, have antivirus software, update their anti-virus software as well as automatically download the Microsoft updates each month. The targets are becoming hardened and I have a feeling as more people take beginning steps toward having a secure computer that the "bad guys" will begin using more advanced techniques to bypass the "new" security awareness that microsoft is projecting. I have a feeling we will see more, not less use of such things as rootkits and very sophisticated DLL trojans. I want to get ahead of where the "bad" guys are headed. I don't hear much about Static DLL trojans so this may be one area where the bad guys may use to implement new nasties. Does anyone know how to protect against this technique? Starrob
I am no expert on static .dll injection so I await DCS reply. There are a couple of things that may help stop this type of injection though DCS will have to verify my statements. If PG is installed on a clean machine it will build a checksum list of all run applications / processes if these were to be changed by malware then the user would be alerted (patched program?), agreed the user would have to make a decision about the authenticity of the change which could have serious implications if a wrong decision were made. If such an injection required that a driver / service is created & installed then, providing the General options 2 & 3 are enabled, Process Guard should stop it. I am sure others will correct me if I am wrong - Pilli
"Guest", seeing as you're talking like you're an authority on what PG is capable of why not reveal yourself to the public to add some credibility to your statements?
@Wayne Did I say anything wrong? If yes: what? (I believe that my statements will be quite creditable after you have confirmed them ;-) Btw.: Noone disputes that you and Jason are the authority on PG. But you did not answer the question relating to DLL injections. Instead you commented on process termination. (I did answer the question because Starrob is talking about my paper.) @Pilli I would not say that your last statement is wrong. PG (and also a personal firewall with MD5 check) will inform the user if an existing application is suddenly patched. However, it is more likely that a victim gets infected with a host application which was patched before the victim receives it (e.g., a manipulated file downloaded from a file sharing network). In such case, PG (or a personal firewall) cannot help. @Starrob Sometimes, a scanner with good heuristics will detect manipulated files. For example, NOD32 /ah may help a bit. In addition, an AT with a module MEMORY scanner and strong signatures may help. It will not detect the manipulated host file but it may detect the trojan DLL which is statically injected into the host file. However, I do not believe that one of the above detection methods will *reliably* work. If a person is able to statically inject a DLL s/he may also be able to outfox a signature-based module mem scanner. (This applies in particular to ATs with a mem scanner using the same signatures that are used by the ATs file scanner ...) I conclude from my discussions with AT software developers that the best way to detect static DLL injections should be a behaviour-based analysis. I cannot talk about the details of a behaviour-based detection concept because the underlying ideas must be considered a business secret. (I hope that the concept will be implemented soon.)
Hi all, (almost missed this, I'm happy to have found you all again One more thing to note more explicitly is that PG (most probably) prevents the host application from being patched on the victim's host. You have mentioned PG's checksum protection which will prevent the host application from being patched on disk and then launch with the modified load. If the host application is on PG's protection list, it can neither be patched in memory - because it is protected against modification. (And I would like to argue that it's most likely that the host applications in question are in PG's protection list, because the dll running under the hood will want to take advantage of having a host that is allowed to pass through the firewall, install a driver or terminate/modify other programs etc.) Thus, while it depends a good deal on a good configuration of PG, "on-site" patching of the host application will be a no-go. Which leaves...: That's true (AFAIU), but would it be still appropriately called a case of DLL injection? Or rather a download of a trojaned application. ...Or am I having the wrong examples in mind? CU,
Hello Guest...I think I know who you are now. That was a interesting paper indeed. It is very rare to find serious discussions about things like DLL trojans and rootkits on the internet, mostly because I think the people that truly know this stuff don't really want this discussed too much for a variety of reasons. I can understand why many AV/AT companies are reluctant to get into the meat of the details about how, why, where a product works. For one, most companies don't want competitors reading about their best ideas and implementing them in a competing product. Another reason is that more likely than not the "bad guys" are avid readers of forums looking to see if they can find out as much as they can about a product in order to defeat it....so I understand certain conversations can only go so far. As for me...I am just a simple computer user that has been on the internet for around 8 years. I have been reading different security forums for maybe the past 4 years and I have read posts from everyone who has posted so far. I can truly say that all of you know much more about this stuff than I do. My only concern is that I want the very best products possible. When I roll out on the internet, I want to roll out in the equivalent of a tank crushing any attempt to get past my defenses. I don't just want to "feel" safe on the internet. I want to "BE" safe. Over the course of 4 years of reading security forums, I am starting to learn which are the "feel good" products and which ones actually have some value. Back to PG now...I believe PG has very good value. Right now, it is one of the programs that I consider my last line of defense. That is why I am trying to find out it's capabilities. If it can't accomplish something then I want to know so I can use other measures to close down the threats it can't protect as well against.. As for Dynamic DLL injection. I have tried to use APM against PG. It was unable to inject the test DLL into any process I chose. What I want to know is APM a true test of PG's ability to block Dynamic DLL trojan's? Has anyone ever did something like take 1000 DLL injection trojans like Beast and optix and fired them off and see if it could block 1000 out of 1000? I am hoping PG can block Dynamic DLL trojans perfectly because I am relying on it big time to protect me from that. As for Static DLL Trojans....I thank you for all your comments. It will help me decide on best how to defend against that until solutions more formidable come along. I guess I would put on my wish list some product that would do a checksum of every program and when the program has detected a change then it would automatically begin to be monitored for certain behaviors. If it was found to contain certain trojan like activities then it would get flagged as a possible trojan. Anyone gives me a program like that, I would buy it immediately. This type of program would probably be able to flag Static and rootkits. Don't you think? Any opinions? I have limited knowledge on how these things work. Starrob
Sorry fellas we've got too much work to do to get involved in this thread albeit as interesting as it is, but one thing to keep in mind is that Process Guard has checksum-based execution protection against not only normal executables but also drivers, so if a program tries to execute or driver tries to install it will be temporarily blocked until you specifically allow it, so if a rootkit or trojan is able to run/install itself it's only because you specifically allowed it. Then and only then when it's running can it start attempting things like DLL injection but even then it will fail because of Process Guard's kernel protections. Jason will elaborate on DLL injection shortly. Anyway, back to work.
Process Guard blocks all static DLL injections except for these :- 1) An existing DLL is overwritten that is used by a commonly run program 2) A DLL is placed on the system that the host program enumerates and loads. ie a plugin based program As Andreas pointed out, you can't modify Process Guard protected applications at all, if you modify it on disk and run it, Process Guard will alert you, if you try and do it whilst it is running, Process Guard will alert you. For a DLL file to be put on your system an EXECUTABLE needs to be running, which Process Guard will also catch. Overwriting DLL files isn't as easy as it sounds aswell, since you need to include the original functionality in your new DLL, otherwise the host program may experience problems and crash/hang/not load the DLL.
Without knowing how APM is working internally, I suppose APM is just using one of several methods to inject or remove dlls. Obviously this is blocked for good by PG. But PG protects against more than this one method of injection, so the question is how many methods are there to inject dlls? To be more exact: a) How many methods are there already being used in the wild; b) and how many methods are theoretically possible? Then, c) which methods are blocked by PG (and I am supposing that those that are handled by PG, are handled well). The problem of course is to answer question a) you'd have to have a vast collection of trojans which are using different approaches (and I suppose few people, if there are some at all that is, have a larger collection than DCS (knowing also that Gavin is doing very active research in the VX scene) - now you have to trust them to research these well and to include protection of all the methods found in that research in PG). At least I don't know of any independent test which examines this. To answer b) is probably straightforward impossible, not even MS will be able to answer that (and during PG development there has turned out a couple of innovative ways to perform this - mostly found not in trojans, but in the DCS coding labs themselves - at least that was my impression). Which in part provides an answer to c): I know that PG also handles methods not even implemented in any trojan, but simply discovered during PG development. OTOH, I don't think you will get a list of which methods exactly are handled in PG - for once, because of the reasons you've mentioned, but also, because PG often does use a rather generic approach to reach its goals, so you can't actually tell how many and which methods of dll injection are covered. ...just a few points to consider as well, although they don't help clearing up the picture very much, I admit. But why would you want to restrict that monitoring to programs that happen to change? IIUC, you're talking of a memory scanner using behavioural patterns to assess "trojanic probabilities". Something that's on the wishlist of many a guest, too. And I am looking forward to seeing if TDS-4 will offer something in that direction. If you insist on starting the monitoring when a program has been changed, you will not catch the patched host application that comes into your computer in an already patched form... Andreas
Is there any way that either you or Guest could perhaps provide a link to the paper you are discussing? I would be interested to read it as well. I also am not an expert in this area, but I am definitely interested in knowing as much as I can about the various threats. I think I understand the CreateRemoteThread method of dynamic injection, as well as the threat posed by static injection... but, there is one method that Guest touched upon briefly that I saw no response to: registry injection. For example, does PG protect against AppInit_DLLs entries/modifications? What was Microsoft thinking when they included such a key? Is it used in any legitimate fashion, or is it primarily just a tool for trojans/malware?
This is one of the protection options (and is the only Registry monitoring that PG does). Microsoft have always seemed to be interested in adding features because they seemed "cool" rather than considering security implications. It was Microsoft applications that led to the rise of macro viruses in the 90's (by including macros within documents rather than as separate files), it was Microsoft that bundled insecure file-sharing systems in Windows 3.x/9x and Microsoft that included open doors like RPC/DCOM and Windows Messenger in Windows 2K/XP. While we can hope that XP SP2 signals a sea-change in their attitude, we do also need to bear some responsibility for rewarding MS's past incompetence by not switching to alternatives sooner. Getting back on-topic, a useful discussion of DLL injection (and ways to counter it) can be found at http://home.arcor.de/scheinsicherheit/dll.htm and this has also been raised in the thread A topic for gamers: Cracked EXE's.
@Alec You can go read some interesting things at these links: http://scheinsicherheit.funpic.de/dll.htm and http://scheinsicherheit.funpic.de/procedure2.htm As far as I am concerned it is just the beginning of my education on these threats. I am hungry for more knowledge and hope more people start investigating this area futher. Starrob
Thanks for the links guys, I haven't read them yet... but plan on doing so after this post. @Paranoid2000 I certainly have no problem with you reminding everyone about Microsoft's past screw-ups. Goodness knows, they've had 'em. In general, I also agree with the sentiment behind your comments. Until recently (hopefully it's changed, that is) they have not cared a whole lot about security issues. But, to be fair, until recently the vast majority of their customers (including most of us end-users as well as corporate CIO's) have in general not held security as a high priority either. That is, I view Microsoft as primarily a mirror of our own collective priorities. But, I don't necessarily agree with your RPC comments. Perhaps they should have been a little more cognizant of the security implications of RPC; although, after all, RPC was and is sort of open standard (albeit one that Sun and Microsoft both have sort of shaped into their versions). I believe Sun RPC has had security issues as well. Maybe there is a little blame to be spread around. That's my only issue. I sometimes hate to single Microsoft out, when I am aware that others have often had similar issues that just went by less noticed. I don't like being a hypocrit, or applying double standards even if Microsoft has the largest marketshare. Back on topic... AppInit_DLLs. I'm still not aware of any program that legitimately requires it. It probably was for internal testing or something. Perhaps one of the links explains further so I guess I better go read...
__________________ So this basically means that the end user must educate themselves about what to allow and what not to allow. Is there some place that gives broad or narrow instructions on what situations it is ok to allow something and in which situations it is not? Right now, the average user probably does not know what to allow and what not to allow. I guess for right now, everything is a matter of expirementation. Starrob
I was just reading this in the Privacy General forum: https://www.wilderssecurity.com/showthread.php?t=45933 It is a question about DLL injection that relates to what I am trying out. In short the question that was posted in the link is: Is there a program that will show the exact DLL that is attempted at being added so that maybe something could be done like quaritine it for later analysis ? Starrob
AppInit_DLLs has been in all public versions of Windows NT, going back to the first public release in 1993 (NT 3.1). Like a lot of "legacy functionality" that isn't broadly used anymore, it is being rediscovered in the "malware arms race" that is going on. For the bad guys, it's expedient, but it's not crucial. As the mantra goes, "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore." http://www.microsoft.com/technet/ar.../essays/10imlaws.mspx#XSLTsection123121120120 Philip Sloss
