Post Thu Apr 13, 2006 12:59 pm

Example 2: Winning Entry #4 - 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_pa ... up_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/win ... sslibrary/, 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=w ... 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/av ... ybird.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/av ... ood.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/freew ... ools.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.as ... 263/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/freew ... ools.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
CISSP, MCSE, CSTA, Security+ SME