Example 2: Winning Entry #4 – Jay Swofford

Viewing 0 reply threads
  • Author
    • #395
      Don Donzal

      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
      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
      (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

Viewing 0 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2020 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?