Joe,
This is about tenth time this has happened to a
customer of ours. It's happened at multiple sites
and
servers. It's ONLY happening on W2k servers (DCs and
non-DCs). They are running up to date Symantec AV
signatures.
Is real-time file protection enabled? Is the AV
process itself running? There are several worms that
attempt to disable AV and firewall products once they
get on a system, so simply having AV signatures
up-to-date may not be good enough.
We've had problems getting to the systems to perform
any meaningful analysis before they get rebuilt.
That's definitely an issue. You're going to have to
inform your customer (or have your boss do so) that
rebuilding the system prior to performing an
investigation/root cause analysis is going to leave
them in a very bad position. If you don't know what
caused the problem, how do you then protect your
systems once you've rebuilt them?
I was able to review the event logs on one system
and
while I found no smoking gun I did find a few things
that I found odd.
That's not surprising, really. I think you did find
some interesting things, but those things are logged
to the Event Log automatically on a default
installation of the system. Out of the box, the
system needs some configuration work before it can
really provide additional, meaningful information via
the Event Log.
1. At precisely 9:00:00 AM Windows File Protection
kicked in when 35 files in "common files\microsoft
shared", "common files\system\ado", and "common
files\system\msadc", as well as these three:
trialoc.dll, wb32.exe and wordpad.exe were restored
by WFP.
Besides the specific filenames you listed, what were
the types of files deleted from the other directories?
Were they also executable (.exe, .dll) files?
2.Event ID 1202 SceCli Security policies are
propagated with warning. 0x2: The system cannot find
the file specified, is being logged. This could be
caused by an irresoluble account name but we were
not able to trouble shoot before the system was
restored.
I don't know what "irresoluble" means, but I was able
to find this on EventID:
http://www.eventid.net/display.asp?eventid=1202&eventno=348&source=SceCli&phase=1
Something that must be disclosed is that these
system are only patched through MS04-004.
Good to keep in mind, but so far, there's no real
information to determine whether or not that has
anything to do with the issue.
We know that's a
huge problem but the configuraiton management these
systems are under has not yet approved more current
patches. If this is caused by malware I'll put my
money on missing MS04-011 as being the key factor in
all of this.
That could be...but what makes you say that? Are you
just guessing?
Consider this for a moment...think about how
accessible the systems are. You said that some of
these systems are DCs...therefore, they should not be
accessible via the Internet, particularly the ports
required for the LSASS exploit to work (from the
Technical Details of MS04-011, UDP ports 135, 137,
138, and 445, and TCP ports 135, 139, 445, and 593
should be blocked).
Given this...and I'm not asking you to reveal your
customer's information...but simply think about the
patch you've mentioned. Also, this does not only
apply to the LSASS portion of the patch, but the
others, as well.
An MS support rep says he thinks it's a virus, but
I'm
not familiar with any that ONLY target W2k server,
and
he can't tell us which one he thinks it is.
Of course not. You haven't given him enough solid
information to work with. In order to do that, you'd
(a) have to have the right tools to collect
information (which is really pretty trivial), and (b)
have access to a live system prior to it being
rebuilt.
Have you tried running a virus scanner yourself?
Has anyone
seen malware, or anything else, only affect W2k
servers and cause massive file deletions in
system32?
I really think that this is an
incorrect/wrong/dangerous viewpoint to take. Simply
b/c you're only seeing this on Windows 2000 systems
does not mean that the issue is specific only to
Windows 2000. By making this base assumption, your
entire approach to the issue may ultimately lead you
to look in the wrong places.
Basically, without more information, you're going to
end up with what you've already got...pure
speculation. I really do hope that you find someone
who had this same issue and was able to determine what
it was. In the absence of that, though...speculation
really doesn't do a great deal to resolve an issue
such as this.
=====
------------------------------------------
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."
------------------------------------------
