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

Fortunately, Nigel had David's number on hand and after reiterating his opinion on the choice of operating systems, they were able to come to a consensus that the second smss.exe service was most likely the work of the lamer Duke Fame fan. First of all, smss.exe, the real one that is, is started when the system boots up. This means it's likely to have a low process ID. In this case the smss.exe with a process ID of 156 is likely legitimate and the one with a PID of 1384 needs to be burned. Another clue to this is the difference in memory utilization. Typically, similar processes will consume similar memory, but with a basic 3-fold increase between the two similarly process, it's time to fry the last smss.exe in the list!

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.

Nigel, with his superior knowledge of Linux, went to the command line and began to use his favorite tool for the job... "lsof".. To his dismay, the windows box stares him blankly in the face and declares: "'lsof' is not recognized as an internal or external command, operable program or batch file."

David hears the typing in the background and inquires about what Nigel is doing. Nigel explains that lsof doesn't appear to be a windows thing. David, not familiar with lsof, talks with Nigel and figures out that Nigel is trying to find out what ports this mysterious smss.exe is listening on. David calls upon the power ofhis Windows knowledge and suggests "netstat -an". Nigel slaps himself on the forehead realizing that he should have thought of that... At least there are some similarities to Windows and Linux. Nigel quicklytypes in the command and realizes why this wasn't the most useful course of action. Nigel tells David that he can see clearly what ports are listening, established, etc... But this still doesn't give him what he needs.. That is to know what port this specific application might be attached to. Meanwhile, David has been checking his favorite Windows 3rd party utility site, sysinternals, and comes across a useful application called "tcpview". Nigel downloads the tool and runs it. Bingo!

With the knowledge in hand of what port the application is listening on, Nigel begins a packet capture on the port from his IDS system for later analysis. Nigel inquires to David as to why he couldn't kill the process with the task manager. David informs Nigel that there are certain executables in the Windows environment that can't be killed in this way, smss.exe just happens to be one of them.

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

Since David has continued to browse around the sysinternals site, he has stumbled upon an application called "pskill" and suggests to Nigel that he use that. Nigel downloads the tool and asks David while it's downloading why he couldn't just kill the process with "tcpview". David has no answer so he gives it a shot and is successful. It turns out either of these tools could be used for the same function. Nigel makes a mental note and moves on...