RE: unidentified DOS "bad traffic" -- SOLVED

From: kyleat_private
Date: Sat Mar 15 2003 - 20:47:01 PST

  • Next message: kyleat_private: "RE: unidentified DOS "bad traffic" -- SOLVED"

    I did an analysis on the DeLoder worm a few days ago, and that worm added a
    whole section of registry entries for VNC, which included the VNC password,
    and it was totally missed by the anti-virus vendors.  Anti-Virus vendors
    seems to be focusing on the auto-startup registry keys, where they totally
    left off the critical VNC related registries...  This information may be
    important in forensics analysis.
    
    What Deloder worm/Trojan did on VNC:
    VNC server file name was renamed to “Explorer.exe,” and registry entries for
    VNC was applied to the registry key
    “HKEY_LOCAL_MACHINE\SOFTWARE\ORL\WinVNC3.”  Within the VNC registry entries,
    you will see that the VNC password was set to some non-alphanumeric
    characters.  The password in HEX was “F3 40 BB C8 07 36 DE 47.”
    
    The in-depth Deloder worm analysis is available at
    http://www.klcconsulting.net/deloder_worm.htm
    
    Regards,
    /Kyle
    
    Kyle Lai, CISSP, CISA
    KLC Consulting, Inc.
    617-921-5410
    klaiat_private
    www.klcconsulting.net
    
    -----Original Message-----
    From: DY [mailto:dybulkat_private]
    Sent: Friday, March 14, 2003 3:11 PM
    To: incidentsat_private
    Subject: Re: unidentified DOS "bad traffic" -- SOLVED
    
    
    Hi all,
    
    Many, many thanks to all of you who have responded to my post.  It appears
    that I've gotten to the bottom of the situation, largely due to several of
    your tips, and I thought I'd go ahead and post some results here for
    future benefit.  I'll leave some context information below, if you'll
    permit my top-post.
    
    The Win2K machine in question was a victim of the W32.HLLW.Deloder worm
    (W32/Deloder).  Before I say more, here are two relevant URLs:
    
    http://securityresponse.symantec.com/avcenter/venc/data/w32.hllw.deloder.htm
    l#technicaldetails
    
    http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&th=48d772
    663f98bfd3&rnum=1
    
    The second URL, which is a CERT advisory (you can get it at CERT instead
    of using the Usenet gateway from Google) was particularly helpful.  Norton
    Antivirus DID detect the virus originally, it turns out, but it merely
    quarantined the delivery agent files, more or less.  The CERT advisory
    gives what appears to be a mutation of the virus, whereby VNC is loaded
    onto the machine in addition to the IRC bot.  Sure enough, my portscans
    revealed that ports 5800 as well as 5900 were open, and I could connect
    with my own VNC, though I didn't know the correct password, of course, so
    I could actually log in.  Here's another incident, found on Usenet (there
    are more):
    
    http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&th=33e8d3
    38d94dbef2&rnum=4
    
    The worm uses the c:\winnt\fonts directory to hide its files.  I found
    basically all of the ones listed on the CERT advisory:
    
    c:\winnt\fonts\vnchooks.dll
    c:\winnt\fonts\explorer.exe (copy of winvnc.exe renamed for hiding)
    c:\winnt\fonts\omnithread_rt.dll
    c:\winnt\fonts\rundll32.exe
    c:\wint\system32\cygwin1.dll
    
    
    So, had I relied only upon Symantec's automatic AV work (in this case) I
    would not have known that this machine had nasty things *still running*,
    including the IRC bot and VNC.  Then again, I guess that means that
    basically *everything* was still running.  Anyway, surrendering complete
    remote control (unaware) is a very sobering thing.  Since this was a
    private host with no inbound connectivity, I am highly suspicious of a
    separate user's machine--a laptop that comes and goes from the particular
    office in question.  This worm is generally deployed via the weak/null
    password exploits for Win2K/XP SMB shares, from what I understand.
    
    As for the original traffic, I am quite certain that the bot received its
    usual "attack" command and, as many of you have pointed out, it was quite
    capable of choking the gateway during the DOS targeted at AOL.
    
    I *highly* recommend that, if any of you have encountered infection
    warnings for the Deloder worm on your systems, you scan for ports 5800 and
    5900 and look for the above-listed (CERT-listed) files, system-wide, of
    course, as you very well may be quite infected.
    
    I am grateful for everybody's help, again.
    
    Regards,
    DY
    
    
    
    > Segmentation fault in module Jason Falciola <falciolaat_private>
    > on Fri, 14 Mar 2003 09:15:53 -0500. Core dump follows:
    >
    > > Quick, subjective, gut-response analysis:  YMMV.  :-)
    > >
    > > I'd do some closer looking at the source machine.  I'm somewhat wary
    > > of trusting the user to just run a AV scan.  This may be a new piece
    > > of malware that doesn't have an AV def. yet.  Or the user may be doing
    > >
    [snip]
    
    
    --- original post ---
    > > DY <dybulkat_private>
    > > 03/13/2003 04:53 PM
    > >
    > >
    > >         To:     incidentsat_private
    > >         cc:
    > >         Subject:        unidentified DOS "bad traffic"
    > >
    > >
    > >
    > > Hi all,
    > >
    > > I'm quite surprised at the lack of material I'm turning up in
    > > researching this issue, so I'm resorting to this post.  Please feel
    > > free to point me somewhere.
    > >
    > > Twice in the past week I have experienced a severe DOS condition on my
    > > network.  A particular host has been completely flooding the network
    > > with some sort of traffic that chokes the whole thing.  Now, on the
    > > first incident I was unable to obtain packet trace data (I'll spare
    > > the details) and was forced to reconnect the particular segment's
    > > port.  We got by for a few days, and then wham, it happened again.
    > > This time I isolated the segment with a Snort sensor and captured a
    > > large amount of data (actually, I only sniffed for a few seconds
    > > before I'd already swallowed about 10 MB of data, all of which was
    > > identical, so I stopped).  My Snort output on this trace was filled
    > > with nothing but bizillions of these entries(payload did vary a
    > > little):
    > >
    > >
    > > 03/13-07:53:50.650383 10.1.2.3 -> 64.12.165.57
    > > PROTO255 TTL:128 TOS:0x0 ID:50456 IpLen:20 DgmLen:80
    > > 45 10 00 3C B5 F5 40 00 40 06 E8 85 CD A2 E9 48  E..<..@.@......H
    > > 40 0C A5 39 D3 A6 1A 0B BC C0 DE 3C 00 00 00 00  @..9.......<....
    > > A0 02 7D 78 D3 8E 00 00 02 04 05 B4 04 02 08 0A  ..}x............
    > > 00 CD 7F 52 52 00 00 00 01 03 03 00              ...RR.......
    > >
    > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
    > > +=+=+
    > >
    > >
    > >
    > > The source IP is from a private network that I run, which uses basic
    > > NAT, so I can certainly route and identify the host, as this capture
    > > is from the private side of the NAT router.  Now, here's the Snort
    > > alert entry(again, just thousands of this same entry):
    > >
    > >
    > > [**] [1:1627:1] BAD TRAFFIC Unassigned/Reserved IP protocol [**]
    > > [Classification: Detection of a non-standard protocol or event]
    > > [Priority: 2]
    > > 03/13-07:53:11.032136 10.1.2.3 -> 64.12.165.57
    > > PROTO255 TTL:128 TOS:0x0 ID:23977 IpLen:20 DgmLen:80
    > >
    > >
    > > Now, I've read up on the Snort signature that generates this alert
    > > (SID 1627).  It says that it's bad traffic (of course) using an
    > > unassigned protocol, which of course the alert states.  However, I'm
    > > not finding anything (Google, Usenet, etc.) that leads me toward the
    > > proper analysis of what this machine was doing.  All I know is:
    > >
    > > 1) The machine runs Win2K pro.
    > > 2) The user has no idea what's going on, of course, and has scanned
    > > his machine with the latest AV updates, with no viri found.
    > > 3) IP address 64.12.165.57, the destination for this complete flood of
    > > "bad traffic," resolves (reverse) to irc-m.icq.aol.com.
    > > 4) There was so much of this traffic that it shut my network down.  My
    > > main router (Cisco) reported no appreciable CPU consumption during the
    > > attack.  It just appears that the sheer volume of the [bad] packets
    > > choked everybody out.
    > >
    > >
    > > So, I know of no exploit, no virus, no known malicious destination
    > > (which might lead me to an exploit)...and yet I had no throughput
    > > (except for the"bad traffic").
    > >
    > > Can anybody give me a clue, or at least point me somewhere (probably
    > > obvious) that I seem to be missing?  I might post to the Snort-users
    > > list as well, I guess, in case anybody there has ideas.
    > >
    > > Many TIA,
    > > --
    > > DY
    
    
    
    ----------------------------------------------------------------------------
    
    <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>
    
    
    ---
    Incoming mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.461 / Virus Database: 260 - Release Date: 3/10/2003
    
    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.462 / Virus Database: 261 - Release Date: 3/13/2003
    
    
    ----------------------------------------------------------------------------
    
    <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>
    



    This archive was generated by hypermail 2b30 : Sun Mar 16 2003 - 13:10:24 PST