There has been a very odd bit of traffic running aroud the Internet forthe past few weeks. Many have discounted it as "crud", but it looks a bitmore sinister. I need your help.

Starting Sept 29th, malformed dns queries began worldwide, from many sources. The rate and number of sources grew steadily until October 8th. At that point, the rate fell off dramatically, the signature changed, andit began to climb again. Graphs at: http://people.ists.dartmouth.edu/~gbakos/bindsweep .

This graph correlates well with data collected by DShield: http://www.dshield.org/port_report.php?port=53 (red and green line).

When one of these requests happenned to reach a nameserver, BIND 9.2.1 replied with a FORM ERR, as expected. Immediately afterwards, the prober sent a second, different dns message. This time, a broken "DDNS updatefailed". The BIND did not respond and the prober moved away.

I have traced hundreds of these back to their source address and verified that they are not spoofed. One site that I contacted was able to capture24 hours of outgoing scan traffic. Unfortunately, the hosts in question were behind a well configured firewall that did not allow replies back in. As the sniffer was placed behind that same firewall, we cannot see any complete fingerprinting sequences. It appears to use a similar decision-tree process to identify named versions, not unlike xprobe's icmp methods for OS version.

From that sniffed session, I have determined that the tool has been configured to only send scan traffic to certain /8 networks, none of which appeared on the cymru bogon list as of March, 2003. However, certain address blocks that have been returned to the IANA since then, are being scanned. Obviously, the scanner isn't terribly up to date with the globalrouting environment. There is a graph overlaying destination addresses to BGP-reachable /8 networks at: http://people.ists.dartmouth.edu/~gbakos/bindsweep

In short, the /8 destination nets are:
24-26, 43-44, 47-48, 51-54, 57, 80-82, 128-196, 198-200, 201-214, 216-222.

The compromised system was examined very briefly by someone at that site.Fport revealed to them that AOL Instant Messenger was bound to the fixedUDP source port of the outgoing scan traffic. As expected, we now know ofa format string error in aim.exe that allows arbitrary code execution. I expect that there is a controlling botnet, most likely using AIM groupchat as its channel.

A tcpdump filter that is effective in observing the initial probe is:

dst port 53 and (udp[8] = 1 and (udp[12:2] > 1000 or udp[14:2] > 1000 or udp[16:2] > 1000 or udp[18:2] > 1000 or udp[10:4] = 0))

Unfortunately, that filter only sees the initial probe, not the follow-onrefinement. I have only seen a few such exchanges. In each case, it was "DDNS Update Failed" message with a ID# of 1409. The filter to see this traffic is:

dst port 53 and udp[8:2] = 1409 and udp[10] >> 3 = 0x15 and udp[11] &; 0x0f != 0

If any of you see this leaving your network, please inform the owner of it that it is compromised, and (with their permission) start capturing ALL traffic to and from that box, regardless of protocol/port.

Please contact me if you have or need additional information.

---------------------------------------------------------------------------
George Bakos, ISTS -- contact: ISC _AT_ SANS.ORG