Who am I?
Where & When
Olde Style Page
Math Puzzles
Spinal Hack Winner 3

Spinal Hack Challenge
by Ed Skoudis, November 2003


* Response by Raul Siles - Spain


The Spinal music group, England's loudest band, Web site compromised "is" located at "http://www.spinaltap.com/", and "probably" one of the substituted MP3 songs is the special, newly-ripped Internet release "Back from the Dead" (http://spinaltap.streameasy.com/backfromthedead.mp3). Just to add some real world information ;-))

The analysis has been made based on a MS Windows 2000, 5.00.2195, Service Pack 4 system, due to the fact that Nigel denied me access to his web server system ;-). Some examples showing the output from the utilities have been included and additionally some images has been provided to simplify the analysis.

1) Which process was most unusual and therefore most likely to be the backdoor planted on the machine?

First of all, let's analyze the list of processes available, although we only have a partial view of the whole system process tree, made up of a total of 41 processes:

cmd.exe           - Windows NT Command Processor. (1)

CMLUC.EXE         - Client Manager software for an Orinoco (http://www.orinocowireless.com/) wireless LAN card.

csrss.exe         - Client Server Runtime Process. (1)

evntsvc.exe       - An application Scheduler installed along with RealOne Player (http://www.reger24.de/prozesse/EVNTSVC.EXE.php).

Explorer.EXE      - Windows Explorer. Located in "C:\WINNT".

ibmpmsvc.exe      - This process is a power management driver for the IBM Thinkpad laptops and it is typically run at start-up. (2) Provides support for the use of four keys on the Thinkpad keyboard with blue key tops - Fn, F3, F4 & F12 - which have specific functions to control the standby and hibernate buttons. Not required if you don't plan to go into standy or hibernate modes.

lsass.exe         - LSA Executable and Server DLL. (1)

Invoked by services such as Net Logon, IPSEC Policy Agent, Security Accounts Manager or NT LM Security Support Provider.

mspmspsv.exe      - Process called "WMDM PMSP Service", a helper service needed and installed by Windows Media Player 7.

MSTask.exe        - Task Scheduler Engine. (1) Invoked by the Task Scheduler Service.

regsvc.exe        - Remote Registry Service. (1)

RunDll32.exe      - Run a DLL as an App. (1)

s__please_buy_.   - "Ed Skoudis (s_) asking politely all us to increase the sales of ..." (3)

s_my_new_book_.   - "... his new Malware book ;-)" (3)

services.exe      - Services and Controller app. (1)

Invoked by lots of internal Windows services, like Computer Browser, Alerter, Event Log, App. Mgmt., DHCP client, DNS client, Logical Disk Manager...

smss.exe          - Windows NT Session Manager. (1)

- Those processes marked with (1) typically reside in "C:\WINNT\system32".
- (2) Is the Spinal group running its Web server in an IBM Thinkpad laptop? Probably they have hosted the Web server in one of the Ed Skoudis's Thinkpad laptops ;-))))
- (3) It is very easy to simulate the "hidden" advertisement introduced by Ed as follows:

Create two copies of any program, for example "notepad.exe", and rename them to "s__please_buy_.exe" and "s_my_new_book_.exe" respectively. Run one instance of each and have a look to the Task Manager. You got it !! Ed used a binary that most probably reserves 1004K of memory at start-up. This could help in trying to find exactly what was the binary used.


Normally, a smart attacker will try to hide its own backdoor processes to look like system processes, so sysadmins won't figure out they are running. This is the case here.

The main clue we have is that the backdoor process cannot be stopped. Based on the detailed analysis of QUESTION 3, the process cannot be killed due to the fact that it has the name of one of the system processes/services. So this fact reduces the number of possible processes in the shown list to be selected as the backdoor because it won't be a process started by an interactive user.

It is always recommended to check if several instances of a given process can run at the same time. In this case, "cmd.exe" (3 times) and "smss.exe" (2 times). The former can for sure run several times, one per Windows command-line terminal session, but, what about the later?

If you try to run another instance of this binary once the system has been started you get the following error message:



The C:\WINNT\system32\SMSS.EXE application cannot be run in Win32 mode.


The same error is obtained when double-clicking on the binary through the Windows GUI. Suspicious, isn't it?

It will be interesting to have some kind of official reference from Microsoft explaining which system processes are unique, so only one instance of them can be running at a given time.

Generally speaking, system services and processes are started at startup, so its associated processes have smaller PID numbers. In this case, one of the "smss.exe" processes has PID 156 but the other has PID 1384, relatively high.

The process size in memory, "Mem Usage" column, can also help in determining some interesting differences: the probable real "smss.exe" is 344K in size; this is the typical size for this process in other Windows 2000 systems observed. The second instance, the one with the greater PID, has a size of 1004K. As a curiosity, it is the same size as the Ed's "propaganda" processes mentioned before.

The other field, "CPU Time", doesn't provide very useful information this time.

The Windows administrators could be confused by the usage Windows made of the processes names, using a mix of lowercase and/or uppercase letters. In some systems the same process appears in uppercase while in others it does in lowercase.

The "propaganda.JPG" image referenced before shows LSASS.EXE or SMSS.EXE in uppercase. These are associated to the test system used for the challenge (Windows 2000 + SP4 + Resource Kit), but they are both in lowercase in the Spinal's web server.

Windows associates the name of the process based on the name the binary file that is going to be executed has into the file system. It is very easy to simulate this situation: You can go to C:\WINNT\System32\ and change the name of the SMSS file from "SMSS.EXE" to "smss.exe". If the system is restarted, now the process appears in lowercase instead of in uppercase.


Why do different Windows systems show different processes names? I guess it depends on the media used to install the OS and the Service Pack level applied. Microsoft distributes its OS in lots of different CDs: just the plain OS version, plain OS plus SP level "x", individual SP CDs, and also different internationalization options. It seems that not all versions install the binary files with exactly the same name: letters can be lower or upper case depending on the case.

The most visible example in this scenario is the "Explorer.EXE" process. Typically this process is called "explorer.exe".

It seems that process names are also influenced by how/from where/who launches them. For example, an executable can be launched from several different places in Windows: the registry, a command line prompt, an HTML page, the "Start" menu, the Desktop... An example is provided using "notepad.exe": depending on the method used, the name in the file system is used, when double clicking on it, or it is "normalized" to lowercase, for example, in case of executing "notepad.exe" from the "Start" menu or from a command line prompt.


Therefore, based on all the previous analysis, it seems that the latest process showed in the Task Manager, "smss.exe", is the backdoor:

Image Name        PID   CPU   CPU Time    Mem Usage

-----------       ----  ----  ---------   ----------

smss.exe          1384  00    0:00:00     1,004K

To be able to be more confident about this statement there will be some basic steps to follow:
- Administrators should feel familiar with the processes running in their systems, so it will be easy for them to identify strange and new "specimens". They should also be familiar with the number of instances of a given process in the system.
- Having access to the system would help to get more information, such as the one requested in further questions, facilitating to collect evidences to confirm if a process belongs to the OS or not. Having as much information as possible provides the analyst additional clues about "what, who, how, why, where is the backdoor?".
For example, having the possibility of getting the binary file (QUESTION 2) associated to each of the two instances of the "smss.exe" processes will definitely confirm whether the second "smss" process is the backdoor because it won't probably point to the real "smss" binary but to a suspicious file.
Besides, knowing the user the processes are running as will determine which of them are considered system processes and which has been started by an interactive user.
- Once the file image is known, an integrity checking tool, such as "md5sum" or Tripwire, would help to confirm if the image correspond to the one provided with the OS or it is a different one.

These are some simple methods/resources followed to analyze the processes running in this Windows host:

A)- Windows services:
Open the Services management tool and verify the started/stopped services and the binaries they use. Go to "Start - Settings - Control Panel - Administrative Tools - Services". Right click on every service and select the "Properties" menu. The "Path to executable:" field provides the file used.

B)- File system:
Search through the file system for the binary name. Go to "Start - Search - For Files or Folders...". Once the binary has been found, right click on it and select the "Properties" menu. The "Description" field provides a briefing about its purposes. All four tabs provide lot of information about a file: General, Version, Security and Summary.

C)- Google:
The "Win Task Process Library" (http://www.liutilities.com/products/wintaskspro/processlibrary/) provides information about the system Windows processes and the most common programs.

"Start-Up Application" in Windows (http://www.pacs-portal.co.uk/startup_pages/startup_full.php). It contains how to identify Windows programs and how to disable them. Explained in "Windows Startup Programs": http://www.lafn.org/webconnect/mentor/startup/index.html.

For an extensive listing of Win processes, visit "Startup Programs and Executables Listing" (http://www.lafn.org/webconnect/mentor/startup/PENINDEX.HTM). There is a related Web page with the master list of names (http://www.lafn.org/webconnect/mentor/startup/MINDEX.HTM).

"Task List Programs", another extensive listing of Windows programs (http://www.answersthatwork.com/Tasklist_pages/tasklist.htm).

D)- Microsoft:
Generally speaking, it is possible to extract information about processes from Microsoft at "http://support.microsoft.com". Search into the KnowledgeBase, selecting your Windows version, and entering the process name. Click "Go" and see what Microsoft have to tell you about a specific process name.

The Microsoft KnowledgeBase article Q263201, "Default Processes in Windows 2000", explains some of those services (http://support.microsoft.com/?kbid=263201). It specifies which processes can and cannot be stopped from the Task Manager. The second group includes processes such as "csrss", "lsass", "mstask" and "smss".

The Windows 2000 Resource Kit, explained in QUESTION 2, contains a tool called "sclist" that shows the services running in a system, so it can help to determine which process is the backdoor by discarding other registered services, unless the backdoor itself has been installed as a service:


C:\>sclist -r



- Service list for Local Machine (running)


running          Browser                          Computer Browser

running          Dhcp                             DHCP Client

running          dmserver                         Logical Disk Manager

running          Dnscache                         DNS Client

running          Eventlog                         Event Log



E) Analyzing malware:
There are several resources on Internet, where different vendors/companies/organizations provide encyclopedias about viruses, worms, backdoors...:

- Symantec: http://securityresponse.symantec.com/avcenter/vinfodb.html

- TrendMicro: http://germany.trendmicro.de/vinfo/virusEncyclo/

- Viruslist.com: http://www.viruslist.com/eng/index.html - Use the "VL-Finder" on the left hand side.

- Panda Security: http://www.pandasecurity.com/virus-encyclopedia.html

- RAV: http://www.ravantivirus.com/pages/virus.php

- Online Trojan Encyclopedia: http://www.atshield.com/?r=encyclopedia

- NOD32 Virus encyclopedia: http://ve.nod32.ch/

- McAfee: http://vil.mcafee.com

- F-Secure Computer Virus Information Center: http://www.f-secure.com/v-descs/

- Antivirus encyclopedias: http://antivirus.about.com/cs/virusencyclopedia/

Searching by the suspicious name on all this databases, like for example "smss", you would get a list of specimens related with this Windows file.

There are also resources listing trojans based on used Internet ports, very useful once it has been determined which port the backdoor is listening on (see QUESTION 2):

- Onctek: http://www.onctek.com/trojanports.html

- The Trojan list: http://www.simovits.com/sve/nyhetsarkiv/1999/nyheter9902.html

- G-Lock SW: http://www.glocksoft.com/trojan_port.htm

- Trojan and RAS ports: http://www.doshelp.com/trojanports.htm

2) How could Nigel determine whether this process was listening on a TCP or UDP port, the user name it was running under, and the file that was executed to invoke the process? Please list any built-in or third-party tools you would use to answer this question.

To sum up, the recommended tools are:

                        GUI                           Command-line

                        ----                          -------------

TCP/UDP ports           Vision or TCPView             fport

User name               Process Explorer              handle or pulist

File executed           Process Explorer or Vision    handle or oh

First of all it is important to note that there are lots of tools out there that can be used for the same purpose. We are going to mention just some of them.

From a forensic point of view it is recommended to run more than one tool for the same purpose in order to validate if the information extracted is consistent or not. Some complex backdoors, like application rootkits, are capable of hiding pieces of information replacing system binary files or DLLs. If the forensic tools use different ways to extract the information, it would be possible to avoid the backdoor tricks and detect discrepancies.

By default, Windows 2000 doesn't provide OS tools to obtain the requested information. Most of the sysadmin tools provided by Microsoft are included in the Windows 2000 Resource Kit (http://www.microsoft.com/windows2000/techinfo/reskit/default.asp), from now on the W2K RK. The tools are installed by default in "C:\Program Files\Resource Kit".

Some of the W2K RK free tools can be also be downloaded from "http://www.microsoft.com/windows2000/techinfo/reskit/tools/default.asp", although there is another classification based on the Windows 2000 system type:
- W2K Server: http://www.microsoft.com/windows2000/techinfo/reskit/rktour/server/S_tools.asp
- W2K Professional: http://www.microsoft.com/windows2000/techinfo/reskit/rktour/pro/Pro_tools.asp

* TCP/UDP ports:

Some new backdoors don't use ports to communicate with the external world through the network, instead they capture the traffic crossing the wires. If the network packets are addressed to the system they reside in, they even don't have to set the network card in promiscuous mode, so it is more difficult to detect them. Other backdoors use ICMP instead of TCP or UDP, so there are no ports to look for.

"fport", by Foundstone (www.foundstone.com/knowledge/proddesc/fport.html), is a tool to identify unknown open ports and their associated applications, similar to "lsof" in the Unix world. Foundstone also released the GUI successor of "fport", called "Vision" (http://www.foundstone.com/resources/proddesc/vision.htm): its menu called "TCP/IP Port Mapper" shows the information requested.



FPort v2.0 - TCP/IP Process to Port Mapper

Copyright 2000 by Foundstone, Inc.



Pid   Process            Port  Proto Path

404   svchost        ->  135   TCP   C:\WINNT\system32\svchost.exe

8     System         ->  139   TCP

8     System         ->  445   TCP

560   MSTask         ->  1025  TCP   C:\WINNT\system32\MSTask.exe

8     System         ->  1027  TCP


404   svchost        ->  135   UDP   C:\WINNT\system32\svchost.exe

8     System         ->  137   UDP

8     System         ->  138   UDP

8     System         ->  445   UDP

224   lsass          ->  500   UDP   C:\WINNT\system32\lsass.exe

212   services       ->  1026  UDP   C:\WINNT\system32\services.exe


One of the best Windows tool repository is "http://www.sysinternals.com", by Mark Russinovich. It contains another similar tool, "TCPView" (http://www.sysinternals.com/ntw2k/source/tcpview.shtml). It displays all open TCP and UDP endpoints and the name of the process that owns each endpoint. There is a reduced command-line version of this tool, called "netstatp", whose source code is freely available, but it doesn't show the process-connection association.

Windows XP already provides a new version of the "netstat" command by default that provides the required information, you just need to correlate the PID numbers from its output with the one obtained from the Task Manager:


C:\>netstat -nao


Active Connections


  Proto  Local Address          Foreign Address        State           PID

  TCP                LISTENING       1256

  TCP                LISTENING       4

  TCP                LISTENING       3604

  TCP               LISTENING       1792


  UDP            *:*                                    4

  UDP           *:*                                    1280

  UDP           *:*                                    3744

  UDP           *:*                                    568





As will be pointed out all over this document, Windows XP has improved the default administrative tools provided with the OS compared to Windows 2000, so the administrator has more advanced built-in utilities to extract detailed information from the system.

* User name:

The Windows 2000 "Windows Task Manager" doesn't provide a "User name" field while Windows XP does. In Windows XP you just need to go to the "View - Select Columns" menu and select the "User Name" column field.

There is a tool, also referenced in the next section to show the binary image file, called "Process Explorer" (http://www.sysinternals.com/ntw2k/freeware/procexp.shtml) and displays who owns each process, apart from what files, registry keys and objects a given process has opened, including its loaded DLLs.

It is very useful because it provides a process tree view where the process parent-child relationship can be easily determined. Apart from that it is more accurate than the built-in Task Manager because there are ways to modify a process so it won't be displayed inside the MS Task Manager [10][13]. Other pieces of software also show hide processes [12].

The column used to display the user is called "User name" while the one that displays the image file is called "Image Path". Both can be selected through the menu "View - Select Columns...".

Besides, the W2K RK offers a tool called "pulist", process user list, that displays the information required, the "owner" of every process running in the system:



Process           PID  User

Idle              0

System            8

smss.exe          140  NT AUTHORITY\SYSTEM






explorer.exe      548  HOSTNAME\user

internat.exe      768  HOSTNAME\user

wuauclt.exe       792  HOSTNAME\user

CMD.EXE           752  HOSTNAME\user

PULIST.EXE        584  HOSTNAME\user




One of the tools analyzed in the next section, "handle" also shows the user associated to every process.

* File:

As mentioned previously, "Process Explorer" provides the image file associated to a given process.

The "Vision" tool mentioned previously contains three menus and each of them let visualize a field that offer information about the path to the associated executable:

MENU              FIELD NAME

-----             -----------

Applications      Executable

Processes         Full Image Path

Services          Pathname

Another useful tool is "Handle" (http://www.sysinternals.com/ntw2k/freeware/handle.shtml), a command-line utility to show what files are opened by which processes.




Handle v2.10

Copyright (C) 1997-2003 Mark Russinovich

Sysinternals - www.sysinternals.com




smss.exe pid: 140 NT AUTHORITY\SYSTEM

   14: File          C:\WINNT

   2c: File          C:\WINNT\system32




CMD.EXE pid: 884 HOSTNAME\user

   58: File          C:\TEMP






The W2K RK contains a tool called "oh.exe" (http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/oh-o.asp) that shows all the handles of open windows, processes, or objects: Microsoft Open Handle Utility. Handles include files, directories, registry keys...

You need to activate it before using it:


C:\> oh

Enabled maintaining a list of objects for each type.

Will take effect next time you boot.

Until then, OH is unable to query useful information



The tool can be used selectively, so if "smss.exe" has PID 140, and we are only interested in its opened files, just run:


C:> oh -p 140 -t file -a

0000008C smss.exe       File           0014 \WINNT

0000008C smss.exe       File           002c \WINNT\system32


These last two tools doesn't provide as much detailed information as the graphical ones, as the specific process image, but its information could be very helpful.

3) Why couldn't Nigel kill this process using the "End Process" button in the Windows Task Manager?

Nigel got the typical Windows message, "This is a critical system process. Task Manager cannot end this process." when you try to kill a system process and Windows doesn't allow you to do so in order not to damage it, because Microsoft considered it risky!! ;-)

Some examples of Windows 2000 critical system processes included in this category shown in the Task Manager output provided by Spinal are: csrss.exe, evntsvc.exe, lsass.exe, mstask.exe, regsvc.exe, services.exe and smss.exe. So it is probable one of those is the backdoor.

It seems a "Windows 2000 Task Manager Process Termination Vulnerability" was published in BugTraq, ID 3033 (http://www.securityfocus.com/bid/3033). Windows 2000 is not case sensitive when determining whether or not a process is associated with the OS or not [1]. If a file has the same name as a system process, a user will not be able to terminate it. This is the reason why the backdoor introduced in the Spinal web server when it was compromised cannot be terminated via the Windows Task Manager [2].

This situation can be easily tested: copy the "notepad.exe" and rename it to, for example, "smss.exe". Run this "new" notepad image and try to kill its associated process; you will get the same message mentioned previously.


There is a Microsoft KnowledgeBase article explaining why a process cannot be terminated, "Q155075- Cannot End Service Processes with Task Manager" (http://support.microsoft.com/?kbid=155075). Although the article is based on another Task Manager error message, it explains that stopping a process involves a call to the "TerminateProcess" function of the Win32 API. When used, the process doesn't clean up properly and save its data, neither it notifies the DLLs loaded into the process address space [3][4].

The restriction for killing a process is related with the Windows security mechanisms [4]. By default, it is not possible to kill a process that is running under a security context different than the one of the process who issued the call to "TerminateProcess". Every Windows process has an "Access Token" associated that contains its security privileges:
- A process run by an interactive user run with the following security context: Interactive/Full Control and System/Full Control.
- A system process/service or DCOM server run under the following security context: Administrators/Read and System/Full Control. This is why a process of this type cannot be stopped even by an Administrator.

These security tokens can be visualized using a tool called "pview" (http://www.alexfedotov.com/code/pview.zip). This GUI tool can list all the running processes, terminate them (see QUESTION 4) or show the security privileges: you just need to right click on a process and select the "Security..." menu.

It is possible to end any process regardless of the security descriptor assigned to it by previously enabling the debug privilege, SE_DEBUG_NAME. This privilege is assigned to Administrators by default although it is disabled. While the Task Manager does not make use of the debug privilege, the different Windows kill utilities do (see QUESTION 4).

Additionally, in Windows 2000 you may assign the debug privilege to non-Administrator users using the following steps:
1. Open the Group Policy snap-in, choose the Local Policy in this case and User Rights Assignment.
2. In the right pane, double-click Debug Programs.
3. Click the Add to add other users.
4. Click OK.

4) How could Nigel actually kill the attacker's process without rebooting the box?

There is a tool called "PSkill" (http://www.sysinternals.com/ntw2k/freeware/pskill.shtml), similar to the Unix "kill -9" command, to abort any process:


C:\>pskill 492


PsKill v1.03 - local and remote process killer

Copyright (C) 2000 Mark Russinovich



Process 492 killed.


This tool is similar to the "kill" utility included in the W2K RK. The main difference between both is that "PSkill" can be used to kill processes on remote systems.
There is an additional W2K RK utility called "rkill.exe", remote kill, that makes use of the "RemoteKill" service. The following Microsoft article explains how to install the Windows 2000 Support Tools, which includes "kill.exe": Q301423(http://support.microsoft.com/support/kb/articles/q301/4/23.ASP).

Another tool that can be used to accomplish the same goal is "pview", mentioned in QUESTION 3. It is also capable of terminating a complete process tree [4], that is, a process and all its child processes.

One of the tools already analyzed, "Process Explorer" allows to kill any process. Besides, the already mentioned "TCPView" also allows to kill those processes with an open Internet connection, client or server.

There is a Microsoft KnowledgeBase article explains how to kill processes, "Q197155" (http://support.microsoft.com/?kbid=197155). The methods recommended by Microsoft are:
A)- Use the "kill" command included in the W2K RK.
B)- Schedule the "kill" command execution through the "at" utility.
C)- Use the "pview" W2K RK utility to adjust the permissions of the process to give administrators (or the currently logged-on user) all accesses to the process, and then repeat this step for Thread security and Process Token security.

Windows XP provides two utilities to kill processes within the installation CD, "tskill.ex_" and "taskkill.ex_". These can be expanded from the CD. See Appendix I.

Finally, there is a software package called "PSTools" (http://www.sysinternals.com/ntw2k/freeware/pstools.shtml) that includes lots of useful Windows tools. The most interesting ones related to this challenge are:
- PSkill (mentioned previously).
- PSlist - list detailed information about processes.


[1] "[Am-info] Windows 2000 Task Manager Process Termination Vulnerability". Fred A. Miller.

URL: http://lists.essential.org/pipermail/am-info/Week-of-Mon-20010723/006430.html


[2] "Windows Task Manager". Labmice.

URL: http://www.labmice.net/troubleshooting/taskmgr.htm


[3] "Windows 2000 Processes and Threads". Computing Department, Lancaster University, UK.

URL: http://www.cs-ipv6.lancs.ac.uk/acsp/OS/Slides/PowerPoint%20Files%20for%20Printing/(Lec ture%205)%20Windows%202000%20Processes%20and%20Threads.ppt


[4] "Terminating Windows Processes". Alex Fedotov.

URL: http://www.alexfedotov.com/articles/killproc.asp


[5] "Enumerating Windows Processes". Alex Fedotov.

URL: http://www.alexfedotov.com/articles/enumproc.asp


[6] "Monitoring and Managing Windows Processes". Visual Basic and Visual C# Concepts.

URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vborimonit oringmanagingprocesses.asp

URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconIntro ductionToMonitoringManagingWindowsProcesses.asp


[7] "Managing Processes in Windows NT4/2000/XP".

URL: http://www.robvanderwoude.com/index.html


[8] "Steps in Windows machine compromise investigation".

URL: http://ist.uwaterloo.ca/~etbain/compromise.htm


[9] "Malware: Fighting Malicious Code". by Ed Skoudis , Lenny Zeltser. PTR. November 2003. ISBN: 0131014056.


[10] "Hide your application from the Windows Task Manager".

URL: http://www.geocities.com/coders_side/source_code/Task_Manager.htm


[11] "Trapping CtrlAltDel;Hide Application in Task List on Win2000/XP". By Jiang Sheng.

URL: http://www.codeproject.com/useritems/preventclose.asp


[12] "Security Task Manager".

URL: http://www.neuber.com/taskmanager/


[13] "remove program from task manager?".

URL: http://forums.devshed.com/t73970/s.html


* Appendix I: Windows XP built-in kill process utilities.



Invalid parameter(s)

Ends a process.


TSKILL processid | processname [/SERVER:servername] [/ID:sessionid | /A] [/V]


  processid           Process ID for the process to be terminated.

  processname         Process name to be terminated.

  /SERVER:servername  Server containing processID (default is current).

                         /ID or /A must be specified when using processname

                         and /SERVER

  /ID:sessionid       End process running under the specified session.

  /A                  End process running under ALL sessions.

  /V                  Display information about actions being performed.




C:\>taskkill.exe /?


TASKKILL [/S system [/U username [/P [password]]]]

         { [/FI filter] [/PID processid | /IM imagename] } [/F] [/T]



    This command line tool can be used to end one or more processes.

    Processes can be killed by the process id or image name.


Parameter List:

    /S    system           Specifies the remote system to connect to.


    /U    [domain\]user    Specifies the user context under which

                           the command should execute.


    /P    [password]       Specifies the password for the given

                           user context. Prompts for input if omitted.


    /F                     Specifies to forcefully terminate



    /FI   filter           Displays a set of tasks that match a

                           given criteria specified by the filter.


    /PID  process id       Specifies the PID of the process that

                           has to be terminated.


    /IM   image name       Specifies the image name of the process

                           that has to be terminated. Wildcard '*'

                           can be used to specify all image names.


    /T                     Tree kill: terminates the specified process

                           and any child processes which were started by it.


    /?                     Displays this help/usage.



    Filter Name   Valid Operators           Valid Value(s)

    -----------   ---------------           --------------

    STATUS        eq, ne                    RUNNING | NOT RESPONDING

    IMAGENAME     eq, ne                    Image name

    PID           eq, ne, gt, lt, ge, le    PID value

    SESSION       eq, ne, gt, lt, ge, le    Session number.

    CPUTIME       eq, ne, gt, lt, ge, le    CPU time in the format

                                            of hh:mm:ss.

                                            hh - hours,

                                            mm - minutes, ss - seconds

    MEMUSAGE      eq, ne, gt, lt, ge, le    Memory usage in KB

    USERNAME      eq, ne                    User name in [domain\]user


    MODULES       eq, ne                    DLL name

    SERVICES      eq, ne                    Service name

    WINDOWTITLE   eq, ne                    Window title


NOTE: Wildcard '*' for the /IM switch is accepted only with filters.


NOTE: Termination of remote processes will always be done forcefully

      irrespective of whether /F option is specified or not.



    TASKKILL /S system /F /IM notepad.exe /T

    TASKKILL /PID 1230 /PID 1241 /PID 1253 /T

    TASKKILL /F /IM notepad.exe /IM mspaint.exe

    TASKKILL /F /FI "PID ge 1000" /FI "WINDOWTITLE ne untitle*"


    TASKKILL /S system /U domain\username /FI "USERNAME ne NT*" /IM *

    TASKKILL /S system /U username /P password /FI "IMAGENAME eq note*"


* Appendix II: Other basic and useful Windows forensic tools.

Additionally, sysinternals.com provides a tool called "PMon" (http://www.sysinternals.com/ntw2k/freeware/pmon.shtml), a GUI/device driver program to monitor processes and threads.

Similarly, they distribute tools to monitor other system activities in real-time, such as TDIMon (network connections), RegMon (Registry activities) and FileMon (File monitoring). These tools can provide a whole bunch of information about the activities carried on by a given process.

It would be really funny to have a copy of the backdoor binary in order to analize this specimen [9].


Raul Siles, November 2003, 17th.

Send me some e-mail

©Copyright 2004, Ed Skoudis