Security Incidents mailing list archives
Re: 1,800 files missing from system32
From: Joe Blatz <sd_wireless () yahoo com>
Date: Thu, 14 Oct 2004 11:46:28 -0700 (PDT)
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>
Current thread:
- 1,800 files missing from system32 Joe Blatz (Oct 14)
- Re: 1,800 files missing from system32 Harlan Carvey (Oct 14)
- Re: 1,800 files missing from system32 Joe Blatz (Oct 15)
- Re: 1,800 files missing from system32 Harlan Carvey (Oct 15)
- Re: 1,800 files missing from system32 Joe Blatz (Oct 15)
- <Possible follow-ups>
- RE: 1,800 files missing from system32 Scott Fuhriman (Oct 15)
- RE: 1,800 files missing from system32 Joe Blatz (Oct 15)
- Re: 1,800 files missing from system32 Harlan Carvey (Oct 14)