Security Incidents mailing list archives
Re: Trojan of somesort - Update
From: Harlan Carvey <keydet89 () yahoo com>
Date: Thu, 27 May 2004 13:00:32 -0700 (PDT)
Bob,
There were no obvious suspicious connections in netstat, of course this could be because the binary had been modified, but the machine is behind a load balancer.
A couple of questions: 1. Which binary are you referring to? Netstat? If so, is there anything to suggest that WFP had been disabled? Did you compare an MD5 checksum of netstat.exe to the copy maintained in the dllcache directory? My thinking is that it's easy to make a statement such as "the binary could have been modified", and it takes very little effort to confirm this. 2. If you were able to run netstat.exe, how about fport.exe or openports.exe?
Other than the ServU files and some sort of crude looking port scanner so far I haven't been able to find anything else.
That may be the case, and it may also be the case that there isn't anything else on the box. However, I have seen boxes broken into by multiple "attackers" (either individuals or worms) all using the same vector, and all leaving their goodies behind. I've followed the thread pretty closely, and if you would like to talk about it off-line, I can definitely assist you with a methodology for taking a more comprehensive and more efficient view of the system.
Does anyone know of a program that can be used to scan for trojans offline, as I now of the machines disk loaded into my forensics system.
Interesting. It's not really clear why you're doing forensics. Either way, I'm not aware of any databases of checksums that you could refer to.
I want to find out what other ports I need to be suspicous of so that I can scan the rest of the network for them to see if anything else looks compromised.
If you've got the drive mounted in a forensics system, you're likely not going to find out what other ports you should be looking for. One way to approach that is to run openports.exe on the (live) system. However, as the ports on Trojans are configurable (as are the names of the files), one approach that I've used in the past is to write a Perl wrapper around openports/fport to automate the collection of process-to-port mapping information. Look at it this way...you may think that it's quicker to scan your entire infrastructure w/ nmap, but remember, that when you do find something you're going to have to run fport/openports anyway, in order to find out which process is using the port, so you know what files you're interested in.
I plan at some point to try and reboot the system connected to a standalone switch to see what services come back up and see if I can track them to any interesting local files.
Good luck. What you're talking about is very easy to do, if you have the right tools...which I've already mentioned.
Current thread:
- RE: Trojan of somesort - Update, (continued)
- RE: Trojan of somesort - Update James C Slora Jr (May 28)
- RE: Trojan of somesort - Update Harlan Carvey (May 28)
- RE: Trojan of somesort - Update James C Slora Jr (May 29)
- RE: Trojan of somesort - Update Harlan Carvey (May 28)
- Re: Trojan of somesort - Update Gadi Evron (May 28)
- Re: Trojan of somesort - Update Paul Schmehl (May 28)
- Re: Trojan of somesort - Update Harlan Carvey (May 28)
- Re: Trojan of somesort - Update Gadi Evron (May 28)
- Changing file times, was -> Re: Trojan of somesort - Update Harlan Carvey (May 28)
- Re: Changing file times, was -> Re: Trojan of somesort - Update Gadi Evron (May 28)
- RE: Trojan of somesort - Update David Gillett (May 28)
- Re: Trojan of somesort - Update Harlan Carvey (May 28)
- Administrivia: Trojan of somesort - Hack definition branch == dead Daniel Hanson (May 29)