Ah, the much anticipated Carvdog reply on the
incidents list. I was afraid I'd get one. ;-)
I'll try to address these in the order asked.
To the best of my knowledge WFP cannot be disabled
post SP2. Googling a bit on this before posting my
question brought this up:
Setting SFCDisable to 1 will disable Windows File
Protection. Setting SFCDisable to 2 will disable
Windows File Protection for the next system restart
only (without a prompt to re-enable). But, for either
to take affect you must have a kernel debugger
attached to the system via null modem cable.
Based on that, I believe WFP to be functional. 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.
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?
All files that WFP logged were exe, tlb, dll or ocx
files.
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. 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.
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?
<Previous traffic deleted for list courtesy>
