Re: Urgent!!! My computer seems to be hacked, pls HELP!!!

Randy Yates <yates@xxxxxxxx> writes:

Chris Mattern <syscjm@xxxxxxx> writes:

René Berber wrote:
Darren Dunham wrote:

Unless the CD nukes any unknown (read non-OS) executable on the drive or
you have some known state to compare against (a la tripwire), I don't
see how you can effectively check a drive. It's certainly possible, but
requires you've done work before the attack. Afterward is too late.
Not true, and it really makes no sense continuing to discuss this.

Yes, true. Once a hacker gains root access to your box, you cannot
trust *any* program or library on it again. I thought this would've
been almost self-evident, but I guess it isn't to some people.

Instead of both sides making empty claims, why not back the claims up
with some specific, concrete examples or possibilities? I for one
would love to see how these "rootkits" accomplish their nasty tricks,
and would like to try my mind at defeating them.

There's not really two sides to this debate.

Rene would find him or herself is in a _very_ stark minority of
security professionals (or perhaps is not a security professional but
rather a system administrator) in debating the wisdom of flattening
and rebuilding once an administrator account has been breached on a

Rootkits in general, install backdoors into a system. They can be as
simple as replacing your real sshd, for example, with one that has a
coded backdoor account into it with a fixed name account and a
password known to the attacker. More proper rootkits will replace
utilities like ls, ps, netstat, and lsof with versions that hide files
and connections the attacker wants to use, and do everything posible
to hide the presence. These sorts of application level kits can be
detected with root kit detection run on the system and potentially
clenaed up. They rely on file signatures to compare against to detect
the changes. Tripwire is a good complimentary tool for file integrity
checking, provided you run it first on a known-good system
configuration and have knowledge of what files are normal to change.

Kernel mode rootkits are nastier still. They get in at the kernel
level and intercept calls and modify results at their bidding. Since
they're interacting with the OS at the most intimate level, they can
evade detection easily since any program running on top of a corrupted
kernel has a hard time doing anything with reliable results. So, even
if the ls binary is stock and clean, the calls ls makes get
intercepted, and your file hiding is done that way for instance. Same
with process hiding from ps. Or open file hiding from lsof. The only
conceptual way to detect that is with an offline scan booting into an
alternate OS or kernel (e.g. a live CD). In a custom compiled kernel,
though, a scanner has a tough job scanning for tell-tale signatures of
such a rootkit unless it's a very well known one. A kernel mode
rootkit that's been hand modified or customized, based on the
limitations of signature based detection technologies, is damned
difficult to detect. As said previously, detectors can only detect
things they know about, and given that the more sophisticated
attackers always customize their attacks, you can see the problem.

So, the possibilities for being 0wn3d are pretty broad, and given that
you can't detect everything that's out there is why the "flatten and
rebuild from original media" recommendation is the one to go with
unless you can withstand the risk of thinking your clean, when in fact
you're still owned.

For more info and links, isn't
too bad.

Of particular note is the Removal section:

Best Regards,
Todd H.

Relevant Pages