By Jay Swofford
Known data points:
====================================
Partial list of system processes from Task Manager
(40% of processes shown sorted by image name)
Image Name PID CPU CPU Time Mem
Usage
cmd.exe 1412 00 0:00:00 1,240K
cmd.exe 1436 00 0:00:00 1,256K
cmd.exe 1460 00 0:00:00 1,248K
CMLUC.EXE 1284 00 0:00:00 2,716K
csrss.exe 180 02 0:00:28 2,900K
evntsvc.exe 1216 00 0:00:00 128K
Explorer.exe 784 00 0:00:49 4,756K
ibmpmsvc.exe 352 00 0:00:00 1,164K
lsass.exe 240 00 0:00:00 1,020K
mspmspsv.exe 748 00 0:00:00 1,880K
MSTask.exe 612 00 0:00:00 1,316K
regsvc.exe 596 00 0:00:00 1,040K
RunDll32.exe 1164 00 0:00:00 1,832K
s__please_buy_. 948 00 0:00:00 1,004K
s_my_new_book_. 640 00 0:00:00 1,004K
services.exe 228 00 0:00:00 4,824K
smss.exe 156 00 0:00:00 334K
smss.exe 1384 00 0:00:00 1,004K
Error message that appears when trying to terminate
the suspect process
Title: Unable to Terminate Process
Message: This is a critical system process. Task
Manager cannot end this process.
Server Operation System: Windows 2000
The Web Server is not currently running (IISAdmin.exe
is not in the process list).
====================================
************************************************
1) Which process was most unusual and therefore most
likely to be the backdoor planted on the machine?
Lets identify each running process to start our
investigation:
A good site to use is
http://www.pacs-portal.co.uk/startup_pages/startup_all.php
as it lists startup programs that can appear in a
Microsoft Windows environment (maliciously or not).
Legitimate process information can be found at
http://www.liutilities.com/products/wintaskspro/processlibrary/,
however, this is only a sample set from their sold
product. If that fails, searching Google
(
http://www.google.com/) and Google Groups
(http://www.google.com/grphp?hl=en&tab=wg&ie=UTF-8&oe=UTF-8)
should give us a good idea.
cmd.exe - Standard Windows Command Prompt process
cmd.exe - Standard Windows Command Prompt process
cmd.exe - Standard Windows Command Prompt process
(comment: why are cmds running on a web
server? What processes are they launching? They are
not the problem themselves, but their presence
indicates abnormal system activity for a secured web
server.)
CMLUC.EXE - probably Client Manager software for an
Orinoco Wireless network card
(comment: why is a web server attached to a
wireless network?)
csrss.exe - Microsoft client/server runtime subsystem
evntsvc.exe - Application scheduler installed with
Real Player
(comment: more unnecessary software running on
what should be a secure server)
Explorer.exe - Windows desktop executable
(comment: note that this may be a trojan
backdoor left behind by the Backdoor.Graybird
(http://securityresponse.symantec.com/avcenter/venc/data/backdoor.graybird.html).
We cannot eliminate this as a suspect as it's
signature Svch0st.exe is below the visible processes
in task manager)
ibmpmsvc.exe - Power Management driver for IBM laptops
(comment: Suggest to host that they run their
web server on a server in the future, not a laptop)
lsass.exe - Microsoft Local Security Authority Server
Service
(comment: we can eliminate the
Backdoor.IRC.Ratsou.B as hid.exe was not in the
provided process list)
mspmspsv.exe - WMDM PMSP Service (Helper Service
needed installed by Windows Media Player 7)
MSTask.exe - The Windows Task Manager
regsvc.exe - Remote Registry Service
(comment: another service that should not be
running on a production web server)
RunDll32.exe - Windows RUNDLL32 Helper
s__please_buy_. - Unknown, very suspect
s_my_new_book_. - Unknown, very suspect
(comment: these two are suspect as they are
unknown processes. Also, many trojans and viruses
enter our system as shameless advertising. Also note
that both were the exact same memory size, 1,004K,
which is unlikely)
services.exe - Windows Service Controller
smss.exe - Windows Session Manager SubSystem
smss.exe - Windows Session Manager SubSystem
(comment: this second one is suspect. There
should only be one on the system)
The most suspect process on this box is the:
smss.exe 1384 00 0:00:00 1,004K
This is suspect for four reasons:
1. There should only be one instance of this process
per server.
2. The PID is 1384, which is higher than the csrss.exe
PID of 180. As smss.exe launches the csrss.exe
process, it would be impossible under normal
circumstances for it to have a higher PID value.
3. The size, 1,004K is identical to our other two
suspect processes (s__please_buy_. and
s_my_new_book_.). Three processes with identical
memory image sizes is unlikely and very, very suspect.
4. The size, 1,004K, is very large for such a small
process.
Therefore the second smss.exe is our suspect process
and is most likely to be the backdoor trojan. Based on
a quick search of antivirus vendors sites, the trojan
is probably Backdoor.IRC.Flood.F
(
http://securityresponse.symantec.com/avcenter/venc/data/backdoor.irc.flood.f.html).
*********************************************************
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.
First, all checks must be done using known good
versions of tools. Any tool or exe on the existing
system is suspect at this point. In our jumpkit we
will have a CD-ROM of tools that have been personally
verified as valid.
To determine the username that the process is running
under, we use Task Manager (from our CD-ROM). From
Task Manager, choose View ... Select Columns. In the
resulting dialog box, select 'User Name'. This will
then display the owning username in Task Manager.
The others are difficult as Windows 2000 does not
provide an easy method to do these. Windows XP and
2003 support the netstat -o option which displays the
PID of the listening process. The best tool for this
job, IMHO, is fport v2.0 from Foundstone
(http://www.foundstone.com/resources/freetools.htm).
However, we will cover several options that cover
several scenarios.
If it is the Backdoor.irc.flood.f trojan, netstat -an
(run from the copy on our CD) will show a connection
between our server and the evil server. The evil
server port will be 6667.
If we want to locally validate what MSTask has told us
(in case it itself has been trojaned and is hiding the
true culprit), we could run a tool such as pslist from
Sysinternals
(http://www.sysinternals.com/ntw2k/freeware/pstools.shtml).
Using the -t option, which shows the process tree, it
should show us the second smss (PID 1384 running under
Explorer not under System as a real one would be).
However, it does not show us the full path and
filename to the smss.exe that is a trojan nor does it
show which ports each process is listening on.
To remotely determine what ports are in the listening
state and what is listening on them, I would recommend
nmap 3.4.8 (http://www.nmap.org) using the new -sV
option. This new option queries listening ports and
attempts to identify what service or application is
listening on that port. However, it also does not show
which ports a process is listening on nor the path to
that process.
Using fport (as noted above) displays the PID,
Process, Port, Protocol and Path. This is exactly
what we are looking for. By using the PID we can
identify what ports and protocols our suspect
process(es) are listening on. Also, we learn the
exact Windows path to the trojan.
**********************************************************
3) Why couldn't Nigel kill this process using the "End
Process" button in the Windows Task Manager?
Microsoft Knowledge Base article Q263201
(http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q263/2/01.A SP&NoWebContent=1).
By design Windows Task Manager is prevented from
ending this process by name. Therefore, Nigel
received his error when he tried to shut it down.
*********************************************************
4) How could Nigel actually kill the attacker's
process without rebooting the box?
My preferred method is to use PSKill from Foundstone
(http://www.sysinternals.com/ntw2k/freeware/pstools.shtml).
Pskill should be used with the PID as an argument.
If you use the process name it will actually kill the
real smss.exe process (it kills all the process with
that name.) So 'pskill 1384' would kill the trojan
process without a need to reboot the box.
The incident investigation would continue utilizing
the following steps:
Document all findings to date using a digital camera
of the screen at key points and all commands run at
the terminal methodically documented.
The server would then be shut down and the hard disk
removed.
A new hard disk would be installed and the sytem
rebuilt from scratch and brought back online
The new system should have (at a minimum):
A firewall with ingress and egress filtering
rulesets
Unnecessary services turned off
Application of IISLockD and URLScan from
Microsoft
No wireless network
Malware protection in the form of Host IPS
(NAI Entercept or Cisco Okena Stormwatch) or
Anti-virus software
The original hard disk should be marked with an
indelible marker as the original.
A consultant firm should be hired to make forensic
copies of the hard disk (using industry proven tools
such as SafeBack 3.0 by New Technologies Inc. -
http://www.forensics-intl.com/safeback.html)
Your legal team/lawyer should be contacted and made
aware of the situation.
The original hard drive and two forensic copies should
be kept until such time as your lawyer states that
they are no longer necessary as evidence.
Jay Swofford
=====
Friends of the Oregon Caves
http://www.oregoncaves.org
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree |
|
