Security Basics mailing list archives

Re: Hidden windows ports, files and services.


From: H Carvey <keydet89 () yahoo com>
Date: 16 Feb 2005 15:13:42 -0000

In-Reply-To: <D7A3023590B2B94FAFDBDCAA6735ED94120DC4 () banana-jr-6k-2k nmefdn org>

How should I say this.........................................

      NUKE IT
      FDISK IT
      DOD WIPE IT
      BEAT THE HDD WITH A HAMMER

Sorry couldn't help it.  If the system was on line unprotected and
mis-configured for six months as you say the box is 100% owned. 

First off, I'm not sure that you can say that with certainty.  Sure, it may look like that based on the information 
that Alex is feeding us, but take a good hard look at what's going on.  If you assume that Alex is a locked-on hard 
charger (which I'm sure he is) with a clue (based on some of his responses, there is some uncertainty about this - no 
disrespect intended), then sure, you can say that it's likely that the box is owned.

However, it's taken multiple posts to the lists, and I've sent emails to Alex, several of which have not had responses. 
 So we're getting a little bit of info here and there, rather than one big dump.  It's pretty evident that Alex has no 
methodology for data collection and analysis in support of IR ops.

For example, look at this:
"I did run TASKLIST before without "/SVC" The processes are invisible to this command."

Rather than dumping the output of several commands to files and zipping them up, Alex is saying, I don't see anything 
unusual.  Well, what's unusual?  Paul might be able to spot something "unusual" right away, where Alex wouldn't see it. 
 It's pretty clear to me from reading this list that lots of stuff goes unnoticed, and all the author has to do is 
change the name of the file.

Alex also said "Using "msconfig", I disabled sys.ini and win.ini...".  But we're talking about XP...XP doesn't use 
those files (it's "system.ini", not "sys.ini"), as they're legacy support for 16-bit apps.  The rest of Alex's response 
in that particular post show a random, hodge-podge, trial and error approach.  

The point of this is that the viability of the info being posted to this list about the incident is at question.  Too 
many times, someone will say, "I ran <insert tool here>, and didn't see anything suspicious", without really knowing 
what constitutes "suspicious".  

Kudos to Alex, though, for doing *something*.

And to Paul's comment...before nuking/beating/abusing the hard drive, one might want to consider 
beating/abusing/tazing/re-educating/retraining the admin who set the system up in the first place.  After all, which is 
less trustworthy?  The poor, dumb hard drive just does what you tell it to do...

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com


Current thread: