[Dshield] port 1026-1031 update

Bill McCarty bmccarty at pt-net.net
Tue Dec 2 02:40:16 GMT 2003

Hi Chris, Jeff, and all,

--On Monday, December 01, 2003 8:33 PM -0500 Chris Brenton 
<cbrenton at chrisbrenton.org> wrote:

> Oh joy. Sounds like we have (yet another) RPC/DCOM/etc. exploit running
> around. It could be pop-up ad stuff, but it just does not feel that way.
> Did I hear you correctly in that the initial packets had no payload?

--On Monday, December 01, 2003 8:48 PM -0500 Jeff Kell <jeff-kell at utc.edu> 

> Could be pop-up messenger spam, although that should be a dying art given
> the ease of blocking 139 (RPC portmapper), and the previous Blaster,
> Nachi, and friends shoring up the 135-139 and 445 ranges.

I'm computing and tracking MD5s of the payloads, which are uniformly two 
bytes in length, consisting of 0x0000. I've seen 707 such datagrams in the 
last 18 hours or so, from over one hundred sources. My analysis report 
stops counting at 100 <g>. But, only a few sources transmit multiple 
datagrams during a 24-hour period. So, the number of sources I'm tracking 
is likely more than 600. Initially, .edus were slightly over-represented 
among the sources; however, that's no longer the case. They are now mostly 
.nets and other ISPs rather than .coms.

I speculate that some more interesting payload than 0x0000 will surface 
once the current, scanning phase is complete. Granted, that could be merely 
a new crop of pop-up ads. But, offhand, this traffic seems to me to be more 
likely related to a worm or other exploit. I suspect that pop-up spammers 
would more likely send a real pop-up rather than send 0x0000. But, what do 
I know about how, and whether, spammers think <g>?

Others have mentioned larger payloads, obviously crafted source ports, and 
so on. But, these are not features of the traffic I'm monitoring. I do 
sometimes see probes of UDP 135 or UDP 137 from the same hosts probing UDP 
1026-1031. But, today, I mainly see UDP 1026 and UDP 1030 traffic. The UDP 
135 traffic has the same payload, 0x0000, as the UDP 1026-1031 traffic. 
However, the UDP 137 traffic has a standard, 50-byte NetBIOS probe as its 
payload. I've seen some unfamiliar transaction IDs (e.g., 0x923f and 0xe143 
rather than the usual 0x1000) in UDP 137 probes. But, I'm uncertain whether 
these come from the same hosts generating the UDP 1026-1031 traffic. Too 
many packets, too little time....


Bill McCarty

More information about the list mailing list