DLL Trojans and NT Rootkits

1. DLL Trojans

I wonder whether it is very difficult to detect a DLL trojan in memory. TDS-3 and TrojanHunter 3.6 can reliably detect a non-modified Beast 2 DLL trojan (and TrojanHunter can also remove it). However, both scanners seem unable to detect any other DLL trojan running in the mem. (I am not talking about the loader.exe but the trojan DLL itself.) Is it not possible to simply add a signature for a DLL trojan? I assume that scanning the mem for DLL trojans works exactly the same way than scanning for normal executable trojans does (except that modules and not only processes are scanned). For example, we injected well-known DLL trojans like Assasin 2 and ColdFusion with APM into a notepad.exe process. Neither TDS-3 nor TrojanHunter detected these trojans. (BoClean did not even detect Beast 2).

2. NT Rootkits

I would like to know whether you are aware of any AV/AT reviews and/or firewall tests dealing with NT rootkits. I have searched this forum (and several others) but did not find very much. At least DiamondCS, DrWeb, KAV etc. seem to have added signatures for certain high level rootkits.


Cheers,

Nautilus (return.to/scheinsicherheit)

 

I suppose you have used TDS trial version, without the Execution Protection installed?
Dolf

 

Hello Nautilus and welcome to the forum!
I suppose you had all startup options configured and all scanoptions checked and on highest sensitivity?
And not to forget after installing the last update?
The assasin and coldfusion aer in the database in many variants and should be detected with ease.
Once detected, as you'll see in the bottom console, right-click on the file for further examination and if you want submitting as a sample or deleting. Everything there can be deleted, manually by the user's decission.

APM is a nice tool for your tests and detection, isn't it?

 

@Jooske I believe that I did everything right because the mem scanner of TDS (and TrojanHunter) detected the Beast 2 DLL in the ram.

Of course, TDS's filescanner detected non-compressed, non-modified versions of other DLL trojans like ColdFusion or Assasin 2. However, I am only talking about the mem scanner. I believe that the mem scanner is the biggest asset of AT scanners like TDS and TrojanHunter since they do not have an unpacking engine yet. That's why I am a little bit puzzled that there are apparently no mem signatures for DLL trojans. (Moreover, the heuristic detection does not seem to work with respect to DLL trojans. Therefore, it was quite easy to make a Beast trojan undetected.)

I am also bugging Magnus (TrojanHunter) in respect of this issue. I will immediately stop doing so if someone can explain to me why it is not easily possible to detect other DLL trojans in memory.



Cheers Nautilus


P.S.: APM is definitely a nice tool. Much more comfortable than using your own loader.

 

I seem to miss part of your question. You say that the scanner detected the nasties and why whouldn't they not detect them? Process Memory Scan and Object Memory scan would detect them, with those analysers you can go deeper with and edit them, etc.....
Now you have the APM you can get the nasty code out of them or change their payload and much more to play with.

TDS does have unpackers and we are told how to add more if we want.

Anyway, suppose after the weekend break the DCS technicians or others will comment and discuss this part with you, interesting as it is.


Think you will love the whole arsenal on DCS products and tools, honestly said. I can't be without them since the day i ever installed the first (TDS).

 

@Jooske

Please let me try to express myself more clearly. It believe that there are three relevant questions:

1.
Are our findings correct (i.e., is it really true that, for example, TDS-3 Process Memory Scan and Object Memory Scan do not detect a ColdFusion or Assasin 2 DLL running in memory)? Maybe I am just wrong and there is no problem at all.

2.
However, if I am right there is the question why TDS-3 cannot detect these trojans while there are running in the memory. Is it very difficult to add mem signatures for DLL trojans (like they did for Beast 2) ? I cannot imagine why this should be the case.

3.
Do our AV/AT reviews make any sense at all? Should we really examine whether AV/AT scanners use strong or weak signatures? Should we test with packed/hexedited/patched trojans (like they are used in the wild) or should we just use a standard test archive (like almost everybody else)?

Nautilus (return.to/scheinsicherheit)

 

Hi Nautilus,

Welcome to Wilders!

I think it likely that you may not get any definitive answers until the DCS Brain Trust comes online, but just so I understand correctly

The DLLs you are injecting *are* being detected in file scans before being injected just not in memscans once they are injected? I ask this as it may be that the DLLs might have been modified (not by you but by the peopole who posted them on whatever site [or hacked system] you harvested them from).

It is my (admittedly vague) understanding that some of the stealth techniques that a small number of advanced trojans use are such that would defeat any current AT implementation and in order for TDS (or any other) product to detect them in situ would require a very significant rewrite of the respective products. Something which is being done in the major push behind the to-be-released TDS4.

The best recourse to follow on the small number of these problematic trojans (as I am sure you are aware but I mention it here for other people that may come across this thread) is to scan the suspect drives either remotely across a network or as a secondary drive in a clean system. Additionally, one can use some of DCSs free tools such as APM, AutoStart Viewer or OpenPorts to do some deductive analysis within the system alongside leveraging some of the other TDS-accompanied tools such as string extractor and port listener, etc.

I am sure that Wayne, Gavin and/or Jason will give a better answer to your question as well as (I hope) correct any aggregious assumptions in my own post!

Regards,

Dan

 

I'm sure our Aussie developers will join asap as this is their specialty but they will be asleep now in their nighttime.

In the helpfile saw this part (i keep it educational for others probaly less informed then you )
Scan DLL Libraries
Scans DLL files against DLL signatures. DLL files can't typically execute on their own - they need a parent executable to call a library function from it to invoke it's "execution". This can be made possible through programs such as rundll/rundll32.exe. DLLs are typically used by trojans as plugins to support certain features such as keylogging, and as runtime libraries.

Further some tests are described like the Memory Space Scan and more. If it scans in all kinds of files regardless their form or compression, why not DLLs? Think it does.

 

@Dan

You are absolutely right. The trojan DLLs are detected by the TDS filescanner before they are injected provided (i) you do not compress/hexedit/patch the DLL and (ii) you do not use a custom loader or a compressed/hexedited/patched loader.

It is also correct that some of "our" DLLs are modified. Others are not. We did not harvest them but created them. For this purpose we relied upon the standard camouflage techniques which are discussed/recommended in several ratboards. We have posted a screenshot of the test archive on our website (see the article "Wolves in Sheep's Clothing: Malicious DLLs Injected Into Trusted Host Applications"). The filenames of the DLLs are almost self-explanatory.

It is also true that no AV/AT scanner is perfect. For example, there are at least four well-known (!!) techniques to outfox "mighty" Kaspersky AntiVirus: (1) use of an unknown packer like Armadillo, (2) use of SennaSpy's Offset Generator in order to "patch around" the signature used by KAV, (3) simple redirection of a packed trojan's entry point, (4) modification of the trojan's OEP area by inclusion of NOPs.

TDS-3 also has its weaknesses. And that's exactly the reason why I am writing here. One of the best things about TDS is its mem scanner (in conjunction with its heuristic capabilities). Therefore, TDS-3 should definitely use its mem scanner in order to detect DLL trojans. (We will figure out whether it already does -- see my question no.1).

I also agree that it is a good idea to scan a possibly infected machine remotely or by using a boot CD. In particular, this applies if your computer is infected with a rootkit (see Hacker Defender topic). Other detection techniques are explained in the above mentioned article. For example, you may use System Safety Monitor or Tiny Personal Firewall in order to stop DLL trojans from injecting themselves into trusted host applications by using the function CreateRemoteThread.

@Jooske

I agree and that's why I am puzzled for which reason "our" DLLs were only detected by the filescanner. Moreover, I would like to add that while DLLs cannot typically be executed on their own it is not a good idea to detect only the loader application. This is because it is VERY easy to create a custom loader. The DLL itself must be detected because this is the real trojan.

Nautilus

 

Hi Nautilus,

Many thanks for the detailed response, as well, of course, to the points that motivated the initial post.

I look forward to the continuance of this discussion once Wayne or Gavin have an ooportunity to review the thread.

Regards,

Dan

 

FWIW, TDS was the first anti-trojan scanner to introduce DLL scanning (most still have no capability in this area). This is quite a few years ago now, and at the time there weren't any trojans that actually used DLL/process injection (a technique that has really only been used in the last couple of years), so we essentially implemented it as an unused technology that we may need to use in the future. DLL injecting trojans are still uncommon, and often not used due to the various problems associated with injecting code and activating threads in other processes (not to mention that it still requires a trojan EXE to inject and activate the trojan DLL, although rundll32.exe can be used here but even that requires setup by a trojan EXE), so don't lose too much sleep over DLL injecting trojans.

To scan the modules of a particular process, just select that process in TDS3's Process List viewer (Ctrl+O), then press Ctrl+M to view the modules in that process. The "Scan Modules" button is just above the module list, you can't miss it.

TDS4 will improve on this even further, but I can't elaborate on that at this stage.

In regards to rootkits, once they've infected your system it is game over - the rootkit has complete control over your operating system, and will modify key functions to make it virtually impossible for any scanner to detect/disinfect, and as scanners rely on the integrity of your operating system, they essentially become useless. Scanners aren't the only programs affected though - for example you won't even be able to use a simple hex editor to look at the rootkit exe, because the rootkit will be hiding the presence of that file. Thus, first-strike is critical - not optional - against rootkits.

Regards,
Wayne

 

Luckily, for now you can scan in Safe Mode or over NetBIOS, shared drive hiding is not in most rootkits (also a telnet session if I remember correctly..) and of course if the drive is not the boot drive there is no problem

 

Wayne,

1.
I am happy to confirm that you are right and I was wrong. TDS-3 does detect ColdFusion 1.0 and Assasin 2.0 trojan DLLs running in memory. Moreover, it is certainly true that TDS introduced DLL scanning.

It is a little bit strange that Object Memory Scan does work with the Beast DLL but not with other trojan DLLs. It really seems that you need to open the Process viewer and manually scan the modules of every single process. Since there can be dozens of active processes this is not the most comfortable solution, eh? But I don't want to be too bitchy ... TDS detects them and that's fine.

I would still recommend not using a trojan's name as a signature. It's just too obvious. Moreover, I hoped that our patched/hexedited DLL trojans would be detected by the TDS heuristic (like it detects stand-alone trojan executables).

2.
It's probably a judgement decision whether DLL trojans are still uncommon or not. In most ratboards, people are talking about them and claim using them. Maybe they just don't get detected? I also found several other tools for static DLL injection, i.e., no more loaders required ...

3.
Since rootkits become increasingly popular it may be worth thinking about fighting back. I seriously doubt that there is already the perfect NT rootkit which intercepts every API function and is absolutely stealth. Most NT rootkits still have version numbers below 1.00.

Wouldn't it be possible to scan all modules and drivers running in the memory and analyze them.

I could imagine that it will not be easily possible to detect a packed/hexedited/patched rootkit with the help of a standard filescanner unless it features a generic unpacking engine (emulation).

Moreover, I have question: Would it be possible (and permissible) to create a Windows Preinstallation Environment (with Bart's PE Builder) and then install TDS-3? It would be absolutely brilliant to have a TDS boot CD ...



Best regards,

Nautilus

P.S.: Our article will be updated of course.

 

Yes, TDS4 will make DLL scanning a lot easier, TDS3 more introduced it experimentally. Trojan names aren't used as primary signatures but are sometimes included as backup signatures in some cases (ie. in resource sections that often stay the same even when compressed), but as they're not primary signatures patching those alone won't defeat detection. It's just additional detection.

No, as most rootkits modify the behaviour of file enumeration functions to ensure that they never show themselves (or any of their modules) as being one of those files.

We haven't tried it before but you're more than welcome to give it a go

Cheers,
Wayne

 

Hi Nautilus,

Please email me, gavin@diamondcs.com.au about some of these questions..

I have found out that the coder of Hacker Defender is having some problems a full stealth rootkit is a lot harder than some of the users out there may think

 

In regards to detection once a rootkit has been installed, that is somewhat more than tricky.. as far as I remember, scanning in Safe Mode is enough to detect all 'kits' currently available.

DLL's dont need to be scanned from the module list, they CAN be, but scanning C:\Windows for example will scan all files, including DLLs

 

Would we have all this problems if we would only access the net via user mode and not with admin rights?

 

Yep, or even better use SSM to SWITCH yourself to user mode on the fly and disable the special privileges Admins have

 

where to get this ssm tool?

 

Hi MEGAFREAK,

The site is a tad slow: http://kormushkin.narod.ru/
so I am also giving you a link to WebAttack: http://www.webattack.com/get/systemsafety.shtml

Regards,

Pieter

 

You can protect against the most powerful rootkit I've seen, Hacker Defender with just the full version of Process Guard really. The latest version of this trojan rootkit is invisible in safe mode, but still not in telnet sessions or netbios. The best protection is stopping it from ever patching your system.

- Ok you would want a registry watcher so you dont reboot and the service starts because then the rootkit goes active Yes this is a raw solution but it works

 

just to let you know that telnet sessions or netbios are now been worked on and work across windows shares so they files can not been seen over network


ch0pper
hacker defender team

 

Heh, you boys sound bored - surely with all this talent you can think of something a bit more constructive to program? *nudge, elbow, nudge nudge* ...

 

Process Guard is very nice program but we were able to bypass and it and run a rookit kit. runing on our vmware test pc windows xp sp 2 beta and running kaspersky anti virus (the best ant virus out there)

yes i know what your are saying bored we just like keeping AVS companys on there toes if we did not do it would be sum one else

morphine 1.4 new of new projects with dll support

i do like your products they are far better than sum of the rubbish you get out there


ch0pper

 

If this is true, would it be fair to ask that you disclose this information to DiamondCS and Kaspersky Labs in private (via email or some other way). If you are just trying to keep AV companies on their toes, i dont see how this can be too much to ask.