Re: [unisog] Re: Port 109 Mystery

From: Harlan Carvey (keydet89@yahoo.com)
Date: 03/13/03

  • Next message: Harlan Carvey: "Windows Rootkits/API Hooking" 
    Date: Thu, 13 Mar 2003 12:34:13 -0800 (PST)
From: Harlan Carvey <keydet89@yahoo.com>
To: incidents@securityfocus.com

    I've tried emailing Doug several times, with specific
    questions, and have yet to receive a response.

    I did get his post to the list stating that he feels
    that the suggestion of a "Windows kernel rootkit"
    might be correct, but he didn't present any
    information or evidence to support that assumption.

    Given that in his original email, he didn't perform
    anything like a comprehensive examination, and he
    replaced the file in question with a "known good" copy
    of Winlogon.exe, it's doubtful that at this point, any
    of our questions can be answered. Therefore, the
    assumption of a kernel rootkit is just that...an
    assumption.

    For future reference:

    1. If you think you have an unusual or suspicious
    process running, collect all of the data you can.
    Besides fport, run netstat (on XP and .NET, use the
    '-o' switch), handle.exe and listdlls.exe and
    pslist.exe (from SysInternals). ListDlls.exe will
    provide the command line used to launch the process,
    so if 'winlogon.exe' is really a copy of netcat,
    you'll see that.

    2. If you're going to tell folks that you checked
    Registry keys, tell them which ones you checked.
    Oddly enough, there are folks that still don't know
    what the Run key is used for...

    Also, in the case of the OP, Win2K (he didn't specify,
    but port 445 was open so I'm assuming...) runs WFP.
    If Winlogon.exe had been replaced, then perhaps the
    Registry key to disable WFP had been enabled, as well.
     A note on Registry keys...if you find a suspicious
    entry, BEFORE you delete that entry, get the LastWrite
    time from the key.

    3. If you find a suspicious process running, get a
    copy of pmdump.exe from NTSecurity.nu and dump the
    process memory to a file BEFORE you just kill the
    process. Also be sure to dump all information on all
    services and drivers.

    4. Before replacing/deleting any files, collect the
    MAC times on the file, and make a copy of the file.
    Run the file through strings...if it's the version of
    strings.exe from the SysInternals site, use the '-a'
    switch, and '-n 3', as well.

    The problem is that even though some information is
    being collected, it's not enough to provide conclusive
    information about the situation. And usually before
    the first response has been sent, the OP has already
    deleted or overwritten the file.

    The overall issue is much greater, actually. Let's
    assume that this issue really is a "kernel rootkit".
    Most of the folks posting on Windows issues
    ("suspicious" processes, "suspicious" open ports, etc)
    aren't collecting enough information, or properly
    analyzing it, in order to properly identify regular
    Trojans and backdoors. For the most part, adequate or
    bare minimum methodologies aren't being followed. So
    what happens when someone uses API hooking to attempt
    to actually hide or mask a file or process? If admins
    aren't finding the malware that isn't being hidden,
    how are they going to find the malware that IS being
    hidden?

    I point this out, as the first step of the root cause
    analysis is to determine whether or not you really
    have a compromise or incident on your hands.
    Misidentifying it, or incorrectly doing so based on
    assumptions, is going to skew the rest of your root
    cause analysis. If that happens, your corrective
    procedures may not even address the real issue.

    Just some thoughts...

    --- Buck Buchanan <lbuchana@csc.com> wrote:
    >
    > Hi,
    >
    > Loki <loki@fatelabs.com> writes:
    >
    > >This may have been something you tried, but looking
    > at that path, it
    > >looks like fport doesnt know how to interpret the
    > initial dir name. Is
    > >it an ascii char space ALT-255, etc? Alt-255
    > directories will not show
    > >up at all in windows. It looks like someone either
    > copied winlogin.exe
    > >to another dir and bound it to port 109, or its not
    > winlogin at all, and
    > >rather, a trojan thats been renamed to winlogin to
    > fool the admin.
    > ...
    > >>On Wed, 2003-03-12 at 11:54, Douglas Brown wrote:
    > ...
    > >> 220 winlogon -> 109 TCP
    > \??\C:\WINNT\system32\winlogon.exe
    >
    > According to "Developing Windows NT Device Drivers -
    > A Programmer's
    > Handbook", by Dekker and Newcomer: \??\ is "the
    > directory of all named
    > devices available for CreateFile". When a program
    > tries to open C:
    > \WINNT\system32\winlogon.exe, "C:" is translated to
    > "\??\C:" by the Win32
    > subsystem.
    >
    > Since fport normally does not display the "\??\"
    > prefix, I am wondering if
    > this might be a clue to how winlogon.exe was run.
    >
    > B Cing U
    >
    > Buck
    >
    >
    >
    >
    >
    ----------------------------------------------------------------------------
    >
    > <Pre>Lose another weekend managing your IDS?
    > Take back your personal time.
    > 15-day free trial of StillSecure Border Guard.</Pre>
    > <A href="http://www.securityfocus.com/stillsecure">
    > http://www.securityfocus.com/stillsecure </A>
    >
    >

    __________________________________________________
    Do you Yahoo!?
    Yahoo! Web Hosting - establish your business online
    http://webhosting.yahoo.com

    ----------------------------------------------------------------------------

    <Pre>Lose another weekend managing your IDS?
    Take back your personal time.
    15-day free trial of StillSecure Border Guard.</Pre>
    <A href="http://www.securityfocus.com/stillsecure"> http://www.securityfocus.com/stillsecure </A>

  • Next message: Harlan Carvey: "Windows Rootkits/API Hooking"
    • Quantcast