Sparse ICMP/ACK Scans to Broadcast Addresses

[spb () MESHUGGENEH NET (Stephen P. Berry)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Over the past couple days, I've noticed an odd traffic pattern which
I haven't observed previously.  The pattern consists of two flavours
of traffic:

        -An ICMP_ECHO_REQUEST
        -An ACK

Both are directed at the same broadcast address.  It appears that whatever
is generating the traffic first tries sending the packets in question
to the broadcast for a 24 bit network, and then to the broadcast for
the 25 bit network which bisects it[0].

Some sample packets with the addresses stripped:

957168189.607721 a.b.c.d > x.y.z.255: icmp: echo request
   4500 001c aaed 0000 ..01 .... xxxx xxxx
   yyyy yyff 0800 .... c18f 0b04 0000 0000
   0000 0000 0000 0000 0000 0000 0000
957168189.608919 a.b.c.d.41130 > x.y.z.255.80: . ack 0 win 1024
   4500 0028 65ea 0000 ..06 .... xxxx xxxx
   yyyy yyff a0aa 0050 af68 205b 0000 0000
   5010 0400 .... 0000 0000 0000 0000
957168741.205031 a.b.c.d > x.y.z.127: icmp: echo request
   4500 001c b61e 0000 ..01 .... xxxx xxxx
   yyyy yy7f 0800 .... 802c 0b04 0000 0000
   0000 0000 0000 0000 0000 0000 0000
957168741.207747 a.b.c.d.59797 > x.y.z.127.80: . ack 0 win 1024
   4500 0028 e135 0000 ..06 .... xxxx xxxx
   yyyy yy7f e995 0050 9cc0 205b 0000 0000
   5010 0400 .... 0000 0000 0000 0000

Where xxxx xxxx and yyyy yy{ff|7f} are the appropriate hex values for
the source and destination IP addresses, respectively, and the `.'s
are the TTL and checksum(s).  The vary, and are all appropriate
values.

The ACK comes too soon after the ECHO_REQUEST to believe that whatever
is generating this traffic is waiting for a response.  The ACK, of
course, is not part of any valid TCP conversation.

The TCP destination port is 80 in the traffic above, but not in every instance
of this pattern that I've seen.

Interestingly, the TCP sequence number in the ACKs is incremented by
a multiple of 65536 in all cases.  Also worth noting is the fact
that the ICMP sequence number remains constant.

So far, a trace like the above has always been isolated.  That is, two
packets each to the .255 and .127 addresses, and nothing else in
close proximity.

The source addresses are the same throughout each instance, but are not
the same between instances.

So far I've seen a total of about a dozen packets of this sort spread out
over about a week.  I strongly suspect it is some species of reasonably
patient (but none too subtle) reconnaissance scan.  The signature is easy
enough to spot, so:  anyone else seen it?

- -Steve

Standard disclaimers:

        -The pattern described has been observed on multiple networks.  These
         networks are not related, to the best of my knowledge, in any way
         other than that I happen to observe traffic on both of them.
        -None of the traffic described originated in demon.net,
         demon.co.uk, or any of that lot.

- -----
0     Or two consecutive 25 bit networks...but it seems to consistantly
      be x.y.z.255 and then x.y.z.127, rather than x.y.z.127 then
      x.y.{z + 1}.255 .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5Ez4kG3kIaxeRZl8RAg4jAKDw4Fxc4Olcn3SVWc4dfS/gCVT3RACeK1ON
jy1RnXHCDjmpn3DP+AuWlXM=
=s1Gs
-----END PGP SIGNATURE-----