"Rob" <com> writes:
> PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
> 26750 root 976K 784K run 0 0 1:19.46 79% dd/1[/ref]
ptree 26750 # /usr/proc/bin/ptree if not in /usr/bin
ptree pid-of-grandestparent that isn't "init"
which should reveal all the processes in the group.
to get the working directory, then sniff around that part of the
filesystem and try and find out when the attack started. Look at
(parent) directory timestamps rather than files as they're generally
less consistently forged.
Then look through your logs for everything you can think of for what
happened at the time of breakin. Then search the entire filesystem
for other changes around that time.
A quick search on google reveals (./AR3):
where the script in question is helpfully padding out the new copy of
/bin/ls to be as big as the original. If I may quote the author of
the resizing code:
if test $ORIGSIZE -lt $TRSIZE; then
echo "Trojan is bigger than real file, go code better trojans, IDIOT"
Then have a root around through google looking for the particular
rootkit that you've been hit with. I saw a hint of something when
looking for "./sz /bin/ls /bin/ls"
Then marvel at how much effort people go to to cover their tracks:
login, ps, netstat etc etc.
Finally, cry and then re-install your box from CD/JumpStart taking
note of all the good advice offered on securing your system. Trust
absolutely nothing on the box as you don't know that the script
kiddie hasn't extended the freely available one.