[Dshield] port 1026-1031 update
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....
More information about the list