Chasing Ghosts this afternoon…

Starting yesterday evening, I’ve been noticing a LOT more attempted connections to :445 (tcp).

Initially I was under the impression that the issue was isolated to the network I was on, although I’ve had confirmations from another non-related network (plus another host I have offnet) that :445 traffic is slightly higher than what is believed to be normal, but then again – what’s normal (without a good netflow collector and historical data, you probably have no idea)

A quick scan of the DSL routers I have access to, shows 314 unique IPs originating such scans to multiple destinations (this is one quick run of “show ip cache flow  | i  01BD” on each of 3 routers). I’m seeing the same thing on a VPS host I have located in Virginia.

Being a little more than curious, I’ve fired up nepenthes and within 8 minutes I had 3 SMB exploit attempts, where the affected machine tries to download “”

These exploits were hitting vulnerabilities on :139 (tcp), however, and I don’t believe are related (also they’re from the same class B network)

66.xx.xx.xx -> 66.xx.xx.xx ftp://1:1@66.xx.xx.xx:9015/

Connecting to this host in particular gives a warm welcome:

nc 66.xx.xx.xx 9015
220 fuckFtpd 0wns j0

Back to what prompted my initial interest – :445, I can’t seem to figure out whats really going on – packet captures indicate more than a normal SYN scan, but without some additional review, I have no idea why so many requests from so many hosts identical to this:

NetBIOS Session Service
Message Type: Session message
Length: 47
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
SMB Command: Negotiate Protocol (0x72)
Error Class: Success (0x00)
Reserved: 00
Error Code: No Error
Flags: 0x00
Flags2: 0x0000
Process ID High: 0
Signature: 0000000000000000
Reserved: 0000
Tree ID: 0
Process ID: 604
User ID: 0
Multiplex ID: 0
Negotiate Protocol Request (0x72)
Word Count (WCT): 0
Byte Count (BCC): 12
Requested Dialects
Dialect: NT LM 0.12
Buffer Format: Dialect (2)
Name: NT LM 0.12

I’ve only slightly glanced over other SMB sessions, and this seems like a normal request… I’m a little baffled as to why every pcap I have from an apparently compromised host uses process id “604”, but otherwise each request appears valid.

So…. it’s probably nothing (usually is), but it definitely piqued my interest for a time today. Happy Thanksgiving!

Update at 22:25

At the advice of others, I’m installing dionaea, which apparently has better SMB support, to see if I can determine exactly what these connections are. I’ll post an update when I’m finished.

Update 06:00 11/25/2009

I’ve got dionea running and collecting bitstreams. Same basic signature (process id: 604), but now with a _lot_ more information in the captures (as dionaea is a little more fluent in the SMB protocol). Tonight: Cooking and reading pcaps.

Leave a Reply

Your email address will not be published. Required fields are marked *