a Killable TDS?

hi,

I have heard there are softwares that can kill tds3 before you have a chance to scan a file, is this true?

In process list i can terminate the process so i think is not safe to use tds3?

Jez

 

Hi Jerry, welcome.
In security our worst enemy we are ourselves with our actions and reactions on alerts.
Have you tried to kill TDS from the process list and if sop, what happened?
Of course you can close any program with the X in the upper right corner, be itr that for closing windows you need the Start in the down left corner.
TDS has as many protective tools included and some suggestions about installing to the users, vital system files are backed up in another place so in case of damage these are replaced with the original.
It is the task of TDS to keep your system clean, you see the scan results and all possibilities to find out about possible alerts plus possibilities to send them to the lab for further advice.
In the registered version you can install exec protection, which blocks nasties before they can execute.
Possible nasties don't get a chance to hide or leave traces or mutexes as all that is scanned and protected.

Of course we recommend to run the whole lot with WormGurad for specific worm and scripts blockage and more and the ability to look into blocked files in the safe mode, while Port Explorer gives an immediate overview of all processes and ports they're connected to with possibility to spy inside data packets and block them, including possible hidden trojans calling home if there would be.

To know all about the autostart files and services there is the new AutostartViewer.
So any strange process left a chance to run with all this arsenal?

In case a software would be able to kill TDS ypu rename the tds3.exe into somethign else and start it with that, so you can continu scanning the nasty file.

It's safer to use TDS then not, with all the protection and detection it offers.

 

Hi Jerry
Sure you can kill TDS in the process list, as you might do anything with your computer.
What's important: can other people do that too with your computer ??
Dolf

 

Hi Jerry,
when the issue surfaced, several firewalls/AV/AT scanners took different routes to handle it. (The problem being a Windows-immanent structural one, one can't just prevent it.)
Some (TrojanHunter e.g.) launch a second process the task of which is to monitor that the first (the actual AT program) is still running and restart it when it's no more present. While there can be taken some steps to "hide" this second process, in the end it can be killed just as easily and just as quickly (more quickly than the polling interval of the monitoring in any case) as the actual AT.

TDS took the route of not even trying to prevent being killed (well, not at the cost of another process and using CPU cycles by such a polling routine), but goes some steps to make the user notice when it has been killed. Most programs (AV/AT/firewalls) just die silently and the user still sees their tray icon and is not aware of them not working any longer. But if TDS is killed, its tray icon will disappear, so the user will know (if he/she pays attention) that it has been killed.

And of course all of this is important *only if the malware gets to being executed in the first place*. Which means that it has to pass TDS's execution protection and its scanning unnoticed first. But if it can do so, why should it then kill TDS afterwards (given that the presence of a kill-another-process call will make it look more suspicious in any heuristic scan)?

IMHO, the route taken by TDS is the most reasonable one until M$ provides a better handling of process termination in Windows. (But feel free to correct me or to just give information about how still other programs handle (solve?) the problem.)

HTHH,
Andreas

 

>And of course all of this is important *only if the malware gets to being executed
>in the first place*. Which means that it has to pass TDS's execution protection
>and its scanning unnoticed first. But if it can do so, why should it then kill TDS
>afterwards (given that the presence of a kill-another-process call will make it
>look more suspicious in any heuristic scan)?

Well ... just my opinion ...

TDS-3 only notice a file execution if it is started using ShellExecute API. One example is if you start the file using the explorer TDS will scan it. If the file is executed using the console or is started by a simple wrapper (Batch script etc.) TDS won't notice anything. Just download the TrojanSimulator from www.misec.net and try to install the server using the TrojanSimulator Client. TDS-3 won't notice anything. This problem is solved in TDS-4 as far as i remember by using a driver.

But there are many ways to provide a secure protection of the process:

1. You can hide the process using a DLL injection using SetWindowHookEx.

2. If you do a Terminate Process Windows sends a last message to the process window. You can not catch this message inside the process itself. But you can catch it if an other process installs a message hook. Its compareble to the way TH uses, but is more reliable and does not waste as much cpu cylcles as the TH method does.

3. You can implement the guard as a service (only WinNT based systems).

I think there are many more possibilities. This are only examples .

 

Thanks for your good ideas, Angel

While the technical details of your suggestions are a bit beyond me (hooks and dll injecton etc. - heard of them, seen them discussed, but i'm not able - not even in theory - to code anything like it), I'm sure TDS-4 will either include one or more of the things you mention or will benefit from us discussing them here.

But one other point on which i'd like to know your views: Why should a malware program kill TDS when it's not detected (If it is detected, it won't be able to execute and so have no opportunity to kill it; if it's not detected, why should it worry about tds)?
(To prevent updates which could introduce detection, okay, but this could be had more easily, couldn't it?)

CU,
Andreas
(Glad to see some a^2 people here )

 

>But one other point on which i'd like to know your views: Why should a malware
>program kill TDS when it's not detected (If it is detected, it won't be able to
>execute and so have no opportunity to kill it; if it's not detected, why should it
>worry about tds)?

TDS-3 is not able to unpack any trojan (what will be changed in TDS-4 as we all know). So you can bypass TDS by simply use of a not so well known packer. But TDS-3 can still detect the malware inside the memory. So it is a good idea to kill it. Don't you think so?

 

good point.
Cheers,
Andreas

 

ok, thank you for clearing this up

I have heard that you can use a system wide hook and block any attempts to close the program (and in actual fact output a message, saying that something is trying to kill it) the problems come when you try and close the program when you shut down windows, i have more than a few good theories to actually keep a file running, (WM_CLOSE, and WM_ENDSESSION - are still called - so if you block them too, the window will be unkillable!)

Jez

 

Now you mention programs and functions..... i remember there have been created some functions for free d/l to prevent killing, but it's for the NT series only. So look in the DCS site and products what it exactly was...........
www.diamondcs.com.au

 

>I have heard that you can use a system wide hook and block any attempts to close the
>program (and in actual fact output a message, saying that something is trying to kill it)

Are you talking about a message queue hook? Well it is possible to prevent normal "closes" - but no TerminateProcess Calls.

>the problems come when you try and close the program when you shut down windows,

As far as i remember windows sends a message to all application windows before shutdown. Just catch the message and allow termination of the process then. But i am not a real developer. So i doesn't know it 100%.

 

There are methods to stop processes from being terminated that we have developed. I'm not sure if they will find their way into WormGuard-4 or TDS-4 (since they both offer unpacking) and process memory scanning is something you want to use as a last resort. WormGuard 4 will probably NOT have it since it does not do memory scanning of worms and hence there is no real reason why something would kill it. I can see reasons for TDS-4 having it however.
-Jason-

 

You can use a ring0 kernel32 process dispatcher (kernel level hooking for instance) and reserve PID's for your own task which you do block at kernel level for terminate / suspend events.
This is nasty to develop, cuz you have to use a lot of "dirty tricks" because you can not use API's and some other needed stuff, but it is possible. You can so also avoid "Overhooking" - this means if some other process hook's the same API from kernel32 you can be all times on the first position to allow or refuse termination of the processes.
Important is here to reserve PID's because during the boot process (kernel driver loading) you do not know which PID the Scanner becomes later and you must know this PID to prevent the unwanted termination ala

if (pidTerminate == myPrgPid)
{
// something trys to close my scanner
// check the source -> System Process Shutdow -> yes: Allow it
// taskmanger -> raise up a confirmation event with Ring 0 Select
} else {
// its a other program which should be terminated with any questions
// call function TerminateProcess with given Pid and other params
}

As i said before you can't use API functions in kernel level.
So you have to write the necessary functions by yourself and you have to patch during the boot time (live in the memory) this Adresses for kernel32.dll

 

Well ...

As far as i remember in Win9x there is a shared memory area (Memory above 0x80000000). Most system dlls are in this area. You can use an undocumented API call to make this area writeable. Then you can patch the export table of kernel32.dll and copy your own routine into the shared memory - you have just to be sure its coded in delta coding style. You should be able to prevent SuspendThread and TerminateProcess then without a driver. But this only works with Windows 9x.

 

Andreas, this one?
http://66.36.228.12/fravia/harlequin_Kernel32.htm
Its an interesting read but i'm not very fond of the actual technique...

 

>Andreas, this one?

Angelo please ... i hope one day you will learn my real name .

>Its an interesting read but i'm not very fond of the actual technique...

Its quite "dirty" ... but well ... it works (but only in Win9x).