Security Incidents mailing list archives
ACK scan
From: "Todd Ransom" <transom () extremelogic com>
Date: Fri, 3 Aug 2001 10:35:22 -0400
I got several nmap tcp ping events from one of my snort sensors the other
day. As I started digging into it the traffic starts to look more and more
strange. I wanted to bounce it off the list and see if anyone else had seen
anything similar or could (in)validate my thoughts on this. Here goes.
I got 20 of these (abbreviated ACID output) from 5 different addresses:
======
[2001-08-02 11:43:58]IDS28/scan_probe-nmap_tcp_ping
IPv4: attacker.com -> fw.my.org
hlen=5 TOS=0 dlen=40 ID=59958 flags=0 offset=0 TTL=55 chksum=45800
TCP: port=80 -> dport: 51723 flags=***A**** seq=193
ack=0 off=5 res=0 win=1024 urp=0 chksum=64006
Payload: none
======
I concluded that these are not normal traffic because:
1.. The ack bit is set but the ack number is 0, which makes no sense.
2.. the sequence number of all the packets is less than 1000. For a 32
bit field this is just too coincidental.
3.. The windows size of 1024 also looks suspicious to me.
So they look like crafted packets. I pull out nmap 2.54 Beta 6 and run an
ACK scan. The sequence numbers and ACK are reasonable numbers. So either
this is an old version of nmap or it's not nmap or it's generated using some
other option from nmap.
According to the nmap man page ACK scans can be used for a few different
things.
1.. Determine if a host exists. I don't think this is the purpose because
so many of them are going to the same machine. He only needs one or maybe 2
packets to determine this.
2.. Determine whether or not a host is behind a stateful firewall. A
stateful firewall will drop the packet, a non-stateful will pass it b/c of
the presence of the ACK bit and you should get a RST from the remote host.
Some things that are funny:
1.. The TTLs are all between 53 - 56 for all packets. I would expect them
to differ more than that, being from different subnets. From this I
conclude all the source addresses except 1 are spoofed.
2.. I did a traceroute to try and find out which of the networks would
come up with a TTL close to 53. Every single source address is around 10-15
hops away from me and they are all behind firewalls that rewrite the TTL
just before the destination. HUNH?!? This throws a kink in everything else
I've concluded. Either someone REALLY did their homework before scanning me
or there's something here I'm not seeing.
3.. Mixed in with the rest was this one packet:
======
[2001-08-02 16:04:29]IDS28/scan_probe-nmap_tcp_ping
IPv4: attacker.com -> fw.my.org
hlen=5 TOS=0 dlen=40 ID=7842 flags=0 offset=0 TTL=52 chksum=41042
TCP: port=80 -> dport: 53 flags=***A**** seq=55
ack=0 off=5 res=0 win=1024 urp=0 chksum=58172
Payload: none
======
Aha! A scan to port 53. There is one packet to 51723 from this address and
one to 53 from this address. Now I REALLY think the rest are spoofed and
this one address is my attacker.
TR
----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
Current thread:
- ACK scan Todd Ransom (Aug 03)
- Re: ACK scan - RESOLUTION Todd Ransom (Aug 10)
