Another Serv-U/FTP compromise

I was reviewing JOAT's blog this morning, and saw a link to a write-up about the response to an FTP compromise. I read through it and thought I'd post a review. I know that hindsight is 20/20 and all that, but I think it would pose an excellent opportunity for questions, comments, and will give everyone a chance to learn a little something.

The initial investigation seems to stem from some unusual network traffic, and the investigation ensued from there. The investigator started by running netstat.exe, then connected to one of the ports to see the FTP service banner, and then ran fport.exe. The investigator identified various files, to include a scanner and what looks like an IRC bot.

While the investigator seems to have taken all necessary steps to solve this issue, my hope is that there are several steps missing for the sake of brevity. Yes, these measures helped him resolve this issue, but a well-planned methodology would prove more useful for a wider range of issues. Some of the things missing include any information about running processes, owners of the processes, installed services, etc., etc.

One thing that I'm curious about is, how did this thing get on the system. According to the investigator, the files he found were in a directory that only allowed the system full access (according to the cacls.exe output). The investigator stated, "...don't even give Administrator access...only the system-level account. Had to edit security permissions to grant access back to Administrator..." So my question is, if the administrator didn't have access, even to change permissions, how did the investigator handle this? This question is intended to be rhetorical, and point out a deficiency in documentation, not necessarily process.

Finally, I found the conclusions to be interesting. Yes, legit apps have been bundled together for some time, allowing attackers to bypass things like anti-virus software b/c the software they're loading (Serv-U, mIRC32, etc.) is not identified as malicious.

Another thing I would point out is the use of a rootkit...or, more specifically, the lack thereof. Take a look at the names of the files...svchost.exe, Explorer.exe, windows.dll, etc. Why bother with a rootkit when hiding in plain sight works just fine?

Finally, the investigator doesn't seem to have addressed the issue of how the compromise occurred at all. How did this stuff get on the box (the operating system was never identified, other than "Windows")? Weak password? Some other compromise, perhaps browser- or email-borne? Could other systems be affected or vulnerable, as well?

All in all, I think these kinds of things are good...posting what you did, and how you handled a situation, for others to see, review, and learn from.

Now, to the reader...what might have you done differently, and why?