Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Security Incidents: Another obvious signature

Another obvious signature

From: Stephen P. Berry <spb_at_MESHUGGENEH.NET>
Date: Thu, 31 Aug 2000 13:26:50 -0700

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

Here's another scan pattern I've seen several times. I'm basically
just looking to see if anyone knows what widget is being used to
send the traffic.

This pattern was first observed (by my sensors, at any rate) around
the middle of August. The interesting features are:

        -Source port is always 53
        -Destination port is always 111
        -IP ID is always hex f2b0 (decimal 62128)
        -TCP SYN is always hex 64 (decimal 100)

Observed scans have consistantly progressed sequentially through address
spaces, sending one packet to each destination host.

Some sample traffic, in tcpdump(8)-ish output format:

12:44:46.813636 a.b.c.d.53 > x.y.z.n.111: S 100:100(0) win 512 (ttl 241, id 62128)
                         4500 0028 f2b0 0000 f106 .... .... ....
                         .... .... 0035 006f 0000 0064 0000 0000
                         5002 0200 .... 0000 0000 0000 0000
12:44:46.813793 a.b.c.d.53 > x.y.z.{n+1}.111: S 100:100(0) win 512 (ttl 241, id 62128)
                         4500 0028 f2b0 0000 f106 .... .... ....
                         .... .... 0035 006f 0000 0064 0000 0000
                         5002 0200 .... 0000 0000 0000 0000
12:44:46.814877 a.b.c.d.53 > x.y.z.{n+2}.111: S 100:100(0) win 512 (ttl 241, id 62128)
                         4500 0028 f2b0 0000 f106 .... .... ....
                         .... .... 0035 006f 0000 0064 0000 0000
                         5002 0200 .... 0000 0000 0000 0000
12:44:46.815579 a.b.c.d.53 > x.y.z.{n+3}.111: S 100:100(0) win 512 (ttl 241, id 62128)
                         4500 0028 f2b0 0000 f106 .... .... ....
                         .... .... 0035 006f 0000 0064 0000 0000
                         5002 0200 .... 0000 0000 0000 0000

Although the scan does march sequentially through address blocks, there
appears to be some sort of more complex heuristic involved in
choosing address blocks. For example, given three sensors on
different 24 bit (or smaller) subnets in the same 16 bit network:

        sensor 1: 10.1.1.1 (sees all of 10.1.1.0/24)
        sensor 2: 10.1.2.1 (sees all of 10.1.2.0/24)
        sensor 3: 10.1.3.1 (sees all of 10.1.3.0/24)

a single `sweep'[0] of the scanning tool might be seen by sensors 1 and 3
but not by sensor 2. In the cases where this behaviour has been
observed, the skipped networks tend to be either empty (except for
the sensor(s)) or `quiet' (i.e., never send traffic to or receive
traffic from the internet at large).

Once again, I'm pretty much just looking for a name to associate with
the widget slinging the packets.

- -Steve

- -----
0 Here defining a `sweep' as involving detects on multiple networks,
      from the same source address, where the last traffic of the
      scan is seen by sensor n only a few minutes before the first
      elements of the scan seen by sensor {n + 1}.
      Another NIDS concept easier to describe algorithmically than
      conversationally.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5rr+BG3kIaxeRZl8RAqUFAJ9+A/LCCGpX751yDOuQuIf3du3YUACg2b93
5e/5vTSjtRAFKJr4m8C3WsU=
=DI9L
-----END PGP SIGNATURE-----
Received on Sep 01 2000

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos