RE: 1,800 files missing from system32

From: Scott Fuhriman (sfuhriman_at_networkarmor.com)
Date: 10/15/04

  • Next message: insecure: "Re: Spider with improbable IP address" 
    Date: Fri, 15 Oct 2004 12:30:26 -0500
To: "Joe Blatz" <sd_wireless@yahoo.com>, <incidents@securityfocus.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>

                    

  • Next message: insecure: "Re: Spider with improbable IP address"

    Relevant Pages