Re: 1,800 files missing from system32

[Harlan Carvey <keydet89 () yahoo com>]

> Ah, the much anticipated Carvdog reply on the
> incidents list. I was afraid I'd get one. ;-)

Well, if that's the case, you should have specified
that you didn't want to hear from me.

BTW...that's Carvdawg to you...  ;-)
  
> To the best of my knowledge WFP cannot be disabled
> post SP2. 

[snip]

> Based on that, I believe WFP to be functional. 

I would say that based on the messages you were seeing
in the Event Log, that's enough to show that WFP
is/was still working.  But your understanding is
correct, as well...except that there is reportedly
another way to disable WFP by modifying the applicable
(based on os version) DLL files w/ a hex editor.  I've
referenced this method in my book.

> If the
> information above is not true please let me know.
> Being able to dynamically enable and disable WFP
> would prove very useful to our developers.

Yes, you're correct with regards to the information
you listed...install a debugger, modify the Registry
entry appropriately, etc.

> I failed to mention that these events have occurred
> over about 5 months. I think the odds of Symantec
> missing a bug that does this kind of damage, but has
> been around for that long, are low. I think current
> AV
> sigs (with file system real time protection) should
> prevent the system from getting infected and the AV
> engine from being disabled. I'm not going to bet a
> month's salary on that, though. Unfortunately the
> tech
> on site did not re-scan the host. He attempted to
> use
> TrendMicro's HouseCall, but bandwidth was such that
> he could not get it to work. 
>
> I'm with you 100% on needing to get time to analyze
> the systems. On the last one we were able to run
> diagnostics for MS support and provided them with
> about 20MB of captured data. They just scratched
> their
> heads and said it "looks virus like". I advocated
> for
> waiting before rebuilding this one, as it was our
> best
> chance to date to get a good analysis done, but that
> was not approved. I'm trying to get the word out to
> our techs that if they should run across one of
> these
> systems again that it should not get immediately
> reloaded.
>
> Here is our auditing policy on the DCs
>
> Audit account logon events :: Success, Failure
> Audit account management :: Success, Failure
> Audit directory service access :: Failure
> Audit logon events :: Success, Failure
> Audit object access :: Failure
> Audit policy change :: Success, Failure
> Audit privilege use :: Failure
> Audit process tracking :: No Auditing
> Audit system events :: Success, Failure
>
> Except for not auditing directory service access,
> non-DCs are the same. Do you think this would
> normally
> be an adequate policy? Are there any changes you
> would recommend?

Well, since in most cases, people/admins aren't
running programs on the DC (ie, Solitaire, browsers,
etc), you shouldn't have a problem in setting both
success and failure auditing on process tracking.  You
may also want to increase the size of the logs, but
the most important thing would be to regularly review
the log entries...for that, using a syslog client such
as NTSyslog to send the entries to a system running
the Kiwi Syslog Server would be a great idea.

> All files that WFP logged were exe, tlb, dll or ocx
> files.

...could be a virus...but there's still nothing
definitive.

> We have seen problems with Sasser like activity on
> these networks in the past, and at two locations we
> applied the patch for MS04-011 and resolved those
> issues. So, yes, it was a guess but it was also
> based on past malware activity on these LANs. 

I've been looking around on a couple of AV sites, and
as yet, haven't found anything that correlates the
activity you mention to a version of a Sasser-like
worm.  That doesn't mean that it's not the case...just
that I haven't seen anything like that yet.

> They have no
> inbound access allowed from the Internet, but they
> are
> large enough that an infected laptop can still make
> its way onto the LAN and wreak havoc. It's happened
> before, though incidents on these LAN are relatively
> rare.

Yeah, that's an avenue that we see all the time.

> In the event we manage to get to one of these hosts
> before it completely dies (when they are like this a
> reboot kills them) what tools would you recommend we
> run?

Get tlist.exe from the Microsoft Debugger Tools (*NOT*
the resource kit).  Run this with the '-c' switch to
get the command lines of all the processes running on
the system.  Look for anything unusual.  

Get network connection information using a clean
version of netstat, and include openports.exe from
DiamondCS (better than fport).  If you have access to
an admin account on the running system, use portqry
v.2.0 from Microsoft.  The combination of these tools
will give you a pretty complete view of network
connections and the processes associated with each
connection.  You might also use tcpvcon.exe from
SysInternals.

If you prefer a GUI approach, use Process Explorer and
TCPView from SysInternals.

In case that doesn't provide you with enough info
(;-)) check the startup locations using AutoRuns from
SysInternals, or the Silent Runner .vbs script (from
silentrunners.org).  

You might also consider running anti-spyware tools,
and keeping a log of their findings.

Basically, what you're looking for are any unusual
processes, network connections, etc., the may at least
give you a clue as to what's happening.

Hope that helps,



=====
------------------------------------------
Harlan Carvey, CISSP
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://groups.yahoo.com/group/windowsir/

"Meddle not in the affairs of dragons, for
you are crunchy, and good with ketchup."

"The simplicity of this game amuses me. 
Bring me your finest meats and cheeses."
------------------------------------------