 |
|
|
|||||||
|
|||||||||
|
|
|
|
|
|
||||||||
 |
|||||||||||||
Spinal Hack Challenge
**** * 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. 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) Notes: 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: ---- C:\>smss.exe
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 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: A)- Windows services:
B)- File system: C)- Google:
"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:
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:
- 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 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: * 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. ---- C:\>fport FPort v2.0 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone, Inc. http://www.foundstone.com
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 0.0.0.0:135 0.0.0.0:0 LISTENING 1256
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:641 0.0.0.0:0 LISTENING 3604
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 1792
...
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:1031 *:* 1280
UDP 0.0.0.0:1047 *:* 3744
UDP 0.0.0.0:2967 *:* 568
...
C:\> ---- 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: ---- C:\>pulist
Process PID User Idle 0
System 8 smss.exe 140 NT AUTHORITY\SYSTEM
CSRSS.EXE 164 NT AUTHORITY\SYSTEM WINLOGON.EXE 160 NT AUTHORITY\SYSTEM
SERVICES.EXE 212 NT AUTHORITY\SYSTEM LSASS.EXE 224 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
C:\> ---- 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. ---- C:\>handle
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
------------------------------------------------------------------------------ ...
C:\> ---- 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.
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:
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:
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
http://www.sysinternals.com
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.
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:
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: [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. ---- C:\>tskill.exe 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]
Description:
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
process(es).
/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.
Filters: 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
format
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.
Examples: 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 /F /FI "USERNAME eq NT AUTHORITY\SYSTEM" /IM notepad.exe 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 |
|||||||||||||
