Re: 1,800 files missing from system32

From: Joe Blatz (
Date: 10/14/04

  • Next message: Ryan Barnett: "Web Attack Data - Apache"
    Date: Thu, 14 Oct 2004 11:46:28 -0700 (PDT)
    To: Harlan Carvey <>,

    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

    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

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

    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

    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

    <Previous traffic deleted for list courtesy>


  • Next message: Ryan Barnett: "Web Attack Data - Apache"

    Relevant Pages