RE: 1,800 files missing from system32

["Scott Fuhriman" <sfuhriman () networkarmor com>]

Since you have described this as a recurring issue, it seems that it
would be appropriate to install some monitoring utilities used in
malicious code analysis.  This would include tools like inCTRL, Regmon,
Filemon, TCPView, fport, System Snapshot and others that can assist you
in logging what is happening with your system and catch the activity as
it happens.

If the issue that you are seeing is being caused by malicious code,
these tools are a great way to assist you in identifying the malicious
activity and tracking down the source. Knowing and monitoring what
processes are running, what changes are happening to the registry, what
ports are opened, what applications are launching processes and ports is
all important info you will need if you want to know what is going on
and more importantly how to stop the incident from reoccurring.

This does require access to the box, however, if you were to have some
or all of these utilities (especially Regmon and Filemon) installed,
running and logging you would be able to collect more specifics.  The
key though is that you have a system activity baseline to compare
against and familiarity of what is normal activity to allow you to
analyze the results of the incident when it occurs.

Hope this gives you an idea to assist in mitigating this issue.

Scott Fuhriman, CISSP, MCSE
Sr. Security Analyst
Integrated Computer Solutions, Inc. - NetworkArmor Division
www.networkarmor.com




-----Original Message-----
From: Joe Blatz [mailto:sd_wireless () yahoo com] 
Sent: Thursday, October 14, 2004 12:46 PM
To: Harlan Carvey; incidents () securityfocus com
Subject: Re: 1,800 files missing from system32


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>