A packet forensics challenge

Take a look at the traffic below and see if you can figure out what is going on. the ip's are
of no consequence to the challenge btw.

02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11

02:07:15.196486 xxx.xxx.xxx xxx.50464 > xxx.xxx.xxx.xxx.829: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20443, len 40)
0x0000 4500 0028 4fdb 0000 2906 6ba5 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 033d 3464 7893 0000 0000 .......=4dx.....
0x0020 5002 1000 543d 0000 0233 3503 3xxx P...T=...35.11

02:07:15.196874 xxx.xxx.xxx.xxx.50464 > xxx.xxx xxx xxx.368: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20444, len 40)
0x0000 4500 0028 4fdc 0000 2906 6ba4 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 0170 3464 7893 0000 0000 .......p4dx.....
0x0020 5002 1000 560a 0000 0233 3503 3xxx P...V....35.11

02:07:15.196994 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.1506: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20445, len 40)
0x0000 4500 0028 4fdd 0000 2906 6ba3 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 05e2 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 5198 0000 0233 3503 3xxx P...Q....35.11

02:07:15.197052 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.521: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20446, len 40)
0x0000 4500 0028 4fde 0000 2906 6ba2 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 0209 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 5571 0000 0233 3503 3xxx P...Uq...35.11

02:07:15.197112 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.795: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20447, len 40)
0x0000 4500 0028 4fdf 0000 2906 6ba1 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 031b 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 545f 0000 0233 3503 3xxx P...T_...35.11

02:07:15.197166 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.192: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20448, len 40)
0x0000 4500 0028 4fe0 0000 2906 6ba0 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 00c0 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 56ba 0000 0233 3503 3xxx P...V....35.11

02:07:15.197224 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.386: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20449, len 40)
0x0000 4500 0028 4fe1 0000 2906 6b9f xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 0182 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 55f8 0000 0233 3503 3xxx P...U....35.11

02:07:15.197281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.703: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20450, len 40)
0x0000 4500 0028 4fe2 0000 2906 6b9e xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 02bf 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 54bb 0000 0233 3503 3xxx P...T....35.11



02:07:15.197338 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.1541: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20451, len 40)
0x0000 4500 0028 4fe3 0000 2906 6b9d xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 0605 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 5175 0000 0233 3503 3xxx P...Qu...35.11

02:07:15.611673 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20452, len 40)
0x0000 4500 0028 4fe4 0000 2906 6b9c xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 03a1 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 92aa 0000 0xxx 0233 3203 P........1.32.

02:07:15.611732 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.829: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20453, len 40)
0x0000 4500 0028 4fe5 0000 2906 6b9b xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 033d 56e1 1744 0000 0000 .....!.=V..D....
0x0020 5002 1000 930e 0000 0xxx 0233 3203 P........1.32.

02:07:15.611960 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.368: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20454, len 40)
0x0000 4500 0028 4fe6 0000 2906 6b9a xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 0170 56e1 1744 0000 0000 .....!.pV..D....
0x0020 5002 1000 94db 0000 0xxx 0233 3203 P........1.32.

02:07:15.612018 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.1506: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20455, len 40)
0x0000 4500 0028 4fe7 0000 2906 6b99 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 05e2 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 9069 0000 0xxx 0233 3203 P....i...1.32.

02:07:15.612074 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.521: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20456, len 40)
0x0000 4500 0028 4fe8 0000 2906 6b98 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 0209 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 9442 0000 0xxx 0233 3203 P....B...1.32.

02:07:15.612132 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.795: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20457, len 40)
0x0000 4500 0028 4fe9 0000 2906 6b97 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 031b 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 9330 0000 0xxx 0233 3203 P....0...1.32.

02:07:15.612188 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.192: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20458, len 40)
0x0000 4500 0028 4fea 0000 2906 6b96 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 00c0 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 958b 0000 0xxx 0233 3203 P........1.32.

02:07:15.612247 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.386: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20459, len 40)
0x0000 4500 0028 4feb 0000 2906 6b95 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 0182 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 94c9 0000 0xxx 0233 3203 P........1.32.



02:07:15.612304 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.703: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20460, len 40)
0x0000 4500 0028 4fec 0000 2906 6b94 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 02bf 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 938c 0000 0xxx 0233 3203 P........1.32.

02:07:15.613428 xxx.xxx.xxx.xxx.50465 > xxx.xxx.xxx.xxx.1541: S [tcp sum ok] 1457592132:1457592132(0) win 4096 (ttl 41, id 20461, len 40)
0x0000 4500 0028 4fed 0000 2906 6b93 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c521 0605 56e1 1744 0000 0000 .....!..V..D....
0x0020 5002 1000 9046 0000 0204 05b4 3203 P....F......2.

02:07:16.170859 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20462, len 40)
0x0000 4500 0028 4fee 0000 2906 6b92 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c522 03a1 3ca2 1dc2 0000 0000 ....."..<.......
0x0020 5002 1000 a66a 0000 203c 2f74 643e P....j...</td>

02:07:16.171203 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.829: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20463, len 40)
0x0000 4500 0028 4fef 0000 2906 6b91 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c522 033d 3ca2 1dc2 0000 0000 .....".=<.......
0x0020 5002 1000 a6ce 0000 203c 2f74 643e P........</td>

02:07:16.171262 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.368: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20464, len 40)
0x0000 4500 0028 4ff0 0000 2906 6b90 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c522 0170 3ca2 1dc2 0000 0000 .....".p<.......
0x0020 5002 1000 a89b 0000 203c 2f74 643e P........</td>

02:07:16.17xxx8 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.1506: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20465, len 40)
0x0000 4500 0028 4ff1 0000 2906 6b8f xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c522 05e2 3ca2 1dc2 0000 0000 ....."..<.......
0x0020 5002 1000 a429 0000 203c 2f74 643e P....)...</td>

02:07:16.171376 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.521: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20466, len 40)
0x0000 4500 0028 4ff2 0000 2906 6b8e xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c522 0209 3ca2 1dc2 0000 0000 ....."..<.......
0x0020 5002 1000 a802 0000 203c 2f74 643e P........</td>

02:07:16.171501 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.795: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20467, len 40)
0x0000 4500 0028 4ff3 0000 2906 6b8d xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c522 031b 3ca2 1dc2 0000 0000 ....."..<.......
0x0020 5002 1000 a6f0 0000 203c 2f74 643e P........</td>

02:07:16.171530 xxx.xxx.xxx.xxx.50466 > xxx.xxx.xxx.xxx.192: S [tcp sum ok] 1017257410:1017257410(0) win 4096 (ttl 41, id 20468, len 40)
0x0000 4500 0028 4ff4 0000 2906 6b8c 1872 404a E..(O...).k..r@J
0x0010 8389 fa0a c522 00c0 3ca2 1dc2 0000 0000 ....."..<.......
0x0020 5002 1000 a94b 0000 0101 080a 0002 P....K........

I'm not a specialist of this sort of question. But the repetition of the same patterns each time modified make me guess a sort of calling to a file/program/shell like in the unicode failure.
In this case the sender don't know what flaw to use and try variations of code hoping one of them will be interpreted and executed by the server.

But this thesis seems to be invalidated by the variations of ports number (for the receiver). It's more like a random search (portscanner?).

hum, I'll search, I'll search....

Don,

I can't give you a straight answer about what is happening, but I noticed a couple of things:

* SYN-packets are sent to ports on the receiving host, but there is no answer from this host (host down, or is it ignoring the other host/ these ports?)
* the packets are sent to the same 10 ports in a specific order.
* this cycle is repeated. Every new cycle, the packets are sent from another port
* The receiving ports are not used very commonly.

I would say it is some sort of portscan, but then, why is it only scanning ports that probably are closed because they are not used by commonly used services?

My guess is that this is one of the tests for an OS-detection, but it might even by some sort of complex handshake or authentication procedure (like Kerberos).

I hope you will post the answer soon.

Are we to assume that this is a complete packet trace of the event and therefore there are there simply no replies from the targetted host?

You assume correctly. The actual trace is longer then this however it just goes along in the
same vein. No other info of note was sent. There are no definitive answers to this. There are
probably 1 to 2 probable answers. Look to the metrics ie: ip id #'s, tcp seq #'s, the time hacks
and so on. These should suggest something to you. A specific tool? How was it done? By
crafting the packets? or by usage of tool which will do it for you? Is it a specific attack, and or
scan type? So on and so forth.
You need to train your mind to look for the answers in the right way. All the info is there in the
trace.

It is a tool based scan trying to determine the OS of the target, (note the timing and sequence ID's - too quick to be manual). Of the ports scanned several of them are associated with diferent OS' and devices such as firewalls, routers, VPN's etc.

In the example trace the packets sent are different on the second scan than on the first, probably trying to invoke some kind of response in a different fashion.

If I received this scan I would be concerned since it is not a simple scan done by persons of, shall we say, lesser sophistication. It appears to be looking quite specifically at the device in question. I would suggest that the operator is of a more sophisticated nature in so far as he/she is more thoroughly footprinting the host, (and probably the network), to determine it's exact make-up rather than scanning hosts for some kind of vulnerability.

First, I would like to ask where this trace was from. From the host itself or from a sniffer probe sitting on the network. Also could you possibly post an attachment of the trace in tcpdump format so it is easier to analyze. (I don't feel like manually decoding hex)

I would say this is definately a port scan of some sort (probably nmap). It is easy to tell it is a port scan with an automated tool because of the static source port from the source host and the incrementing sequence number. I would disagree however that the operator is more sophisticated because of the fact that this is a very "noisy" scan. It is fairly obvious that the intention of the scan was to get it done as fast as possible (since the beginning and the end of the trace are only less than 2 seconds apart) instead of using a more stealty technique.

Dammit Tiger Shark...I was busy typing my response when you posted....LOL. You beat me to it, but I still disagree that it was a sophisticated user based on the scan because of the technique used. It would be interesting to see what happened previously to this scan, but my guess would be that the attacker probably did a ping sweep (or another method) to find hosts that responded, and then did a port scan on those that were "alive". (Just a guess though).

These are fun!!!

I still would prefer it in TCPdump format though.

Invictus: When I referred to the operator as "more sophisticated" I didn't mean they were a L33t H4XX0r....<s> I just don't see this as one of your low level script kiddies even though the scan is automated and utterly without stealth. This person is not looking for a single vulnerability but rather they seem to be making a concerted effort to determine the OS/device type. To me that doesn't point to a skiddie as much as someone who wants information.

I agree that I would like to see more extensive logs aimed at this target over the previous few days to see how the operator came up with this address - a ping sweep would not necessarily have found this host. I would also like to know if the host is firewalled and what services the firewall allows to this host.

One more thing - how was the dump generated? IDS outside a firewall, inside a firewall, from the host itself?????

Ooops.... Inv already asked the last but I couldn't find where.....DUH....<s>

Well...is there really any eveidence that the attacker is trying to determine the OS type?

And as far as the ping sweep concept I mentioned earlier, as I said, it was merely a guess because I don't know if the host would even reply to an echo request. Once we find out a little more about where the trace was taken from (as we both mentioned ;)) it will be much clearer. If the trace was taken from the same network segment as the victim host, I would definately say that it is not firewalled (or not very well at least).

Invictus: Got to rush to a meeting so I'll make this short.....<s>

Try googling the different port numbers. Those that come back with something sensible give me the impression that the intent is to determine what the target is rather then try to exploit it - the payloads are quite similar on each port....... I would not expect the same exploit to work across so many unassociated ports.

I agree with the comment that the intention is not to exploit a the host, but as I stated earlier, I believe this was simply a port scan to determine which services may be running based on the ports that are listening. Although the attacker may have been attempting to determine the OS type based on the headers of the TCP response. The one thing that is for sure based on this trace is that the attacker would not have been able to determine the OS type because the victim host never replied back.

It's something of a toss-up whether they were trying to enumerate services or identify the OS/device. I lean towards the OS/device theory because if you googe the port numbers one seems to be associated with a checkpoint firewall/VPN, another seems to be some *nix based system etc. The services associated with the ports come from different OS'. If I was scanning for services then I would be scanning ports that would provide services on a single OS/device not multiple OS'/devices, hence I lean to OS detection rather than service enumeration.

In this case you are correct that no real info was gleaned because no reply was received, (assuming this was OS identification), - however that would depend on whether this system was firewalled or not. You can't say what services are avialable if a firewall blocks access to the machine on those ports. Furthermore, the absence of a reply from a known open port is sometimes the information you require to determine the app behind it and/or it's revision level..... though this is not true with simple SYN packets it is most certainly true with others such as a SYN/FIN - so the absence of a reply does not always mean no information was gathered.

Well...I think we are on the same page, we just have two different perspectives, and since there really is no right answer. Building on what you said, the fact that the ports don't seems to be associated with anything specific, means to me that it was trying to find an open port (any port) since a response from any port would be enough to determine the TCP stack type and therefore potentially the OS or the ability to narrow it down to a few OS's

Run an nmap scan for yourself (just a basic port scan) and you will get the same result.

By the way, when I say scanning for services, I do mean scanning for ports, because every open port would have an associated service. A service is not specific to the OS either. For example HTTP port 80 is obviously a standard web service. This can be IIS on a windows box, apache on a linux box, i-planet on a solaris box, and so on. There are very few services (relatively speaking) that are OS specific. If you run a port scan and you get back a report saying that the only open port is 21, it may not mean much because it can be any OS, but the TCP headers may give some other indication.

Now there is the situation you are talking about. If a port scan reveals that ports 21, 80, and 135 are open, you can probably guess it is a windows box. This however is not as good of a method of identifying the OS however because services can be changed to utilize different ports. TCP headers can not bea easily modified since it comes directly from the kernel level. Therefore more reliable of a guess.

I will check to see if I still have the trace archived or not? Don't think so though. The conclusion
that I came up with was that this was an nmap trace using the idle host scan technique against our network. Due to the ip of the originating scan I surmise this. It is a Win NT/2K box
which I am not sure without looking at all the metrics.
It was not stealty at all your right, however this was not a script kiddie either. As evidenced by
their usage of the tool ie: various ports done up in a file ahead of time, the speed of it...
What this was meant to stimulate was people looking at the tcp/ip headers which is why I used the -v switch.
I will post more of these if there is an interest. I came up with no definitive conclusion as to what tool was used here. It is possibly nmap or hping. It was a reconnaissance though. Also
there was no prior ping noted. Not in recent memory anyways :-)

Ok Don.... You confuse me!!!! (Not a dificult thing sometimes....<S>)

At the beginning of your last message you say "the conclusion I came up with was an NMap scan"...... Later you say "That's why _I_ used the -v switch"..... and lastly you say "I came up with no definitive conclusion"......

Did you set this up or is this a result of monitoring your network and this is by someone unknown using a tool unknown to you?

Also - don't restrict yourself to looking for ping scans as a way of determining whether or not you have been recce'd..... You could run ping scans all day on my network and find only the firewall and the external router replying..... I do not allow ICMP through the firewall from the outside..... To a ping scan it appears that I provide no public services whatsoever within the entire netblock.... You need to dig a little deeper to find all the perfectly normal services I run. But when you do that I can see you....<s> I don't even log the ping scans... I log the more "in-depth" searches otherwise my logs would be even bigger than they currently are.....

ICMP is not allowed thru the f/w. I used the -v switch on tcpdump so that all the tcp/ip fields
would show up. It appears that nmap is the tool, however that is not certain. This due to the
fact that as I alluded to earlier it may be the idle host scan being used due to the predictable
ip id #'s. Also the packets are fragmented which is done by design likely to try and get past
some liberal routers acl's no doubt.
This however could also be the work of hping. I have not checked to see how many dst ports
you can supply with hping to deny or verify this as a possibility.
This is why I am unsure as to exactly what tool it is. I can however venture a couple of educated guesses.
This trace was not set up by myself. This was done in the wild and directed at my company's
network. I most certainly don't restrict myself to ping scans as a precursor either ;-)

Don: Thanks..... Now I'm less confused....<s>

Didn't mean to imply that you limited yourself to pingscans as precursor to further activity - but sometimes it is hard to determine what level others are at from their posts. I have come across people who know a couple of things really well and still run other parts of their systems in a way that leaves me slapping my forehead wondering how they didn't know X, Y and Z..... Then again, I'm probably guilty of the same - I simply don't know what it is i don't know....... <s>

You are right it is hard to gauge peoples skill levels from their posts. It is also hard to speak
as some people interpret some computer terms differently or right out of whack. Including me
on occassion :-)
This is why I love packet forensics! > if forces you to learn how the stack works and ideally how to better defend it and lastly interpret the results of your f/w and or ids system.

How can you tell by this that these packets are fragmented? I don't see any clear evidence of that.

This does NOT show all the TCP header information, some of which may be extremely valuable. For example, it doesn't show which bits are set (SYN, ACK, DF, etc.) Nothing here is enough to make any conclusive decisions on what exactly was happening.

02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11

Look at the S after the port number 929. This denotes it is a Syn packet. If this packet was not
fragmented the (DF) field would be there. Or if it was (MF) more fragmented it would be there
as well. The person may have set a virtual mtu which was too low to purposely cause it to fragment and or the OS has "DF" off by virtue of it's stack.
What I just said above is "conclusive" evidence. Not trying to sound like a ***** here but you
may want to consult your tcp/ip book and or do some more forensics, check out SANS,...
I don't talk bullshit, I know what I know, and I admit it when I don't.

Perhaps you need to read the man pages for TCPdump...or better yet, let me post it here for you:

-----------------------------------------------------
IP Fragmentation

Fragmented Internet datagrams are printed as
(frag id:size@offset+)
(frag id:size@offset)
(The first form indicates there are more fragments. The
second indicates this is the last fragment.)
-----------------------------------------------

Nowhere in your trace does this appear. Not to metion the full TCP header would not appear in every datagram if the packet was fragmented. You would see an output like this:

arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

just because the DF bit is not set doesn't mean that the packet is automatically fragmented. It is just set when the packet is absolutely NOT fragmented.

Also, since you know alot about TCP/IP, you should know that the SYN bit is also set in the first step of the TCP three-way handshake. Therefore this would be the expected output from a user running a TCP-connect scan. (which happens to be the default for nmap), and again reinforces my position that the attacker was most likely NOT very knowledgeable.

Also, I am trying to continue to provide informative responses based on the facts at hand. I don't think it is appropriate to attemt to try to degrade me by telling me I know know what I am doing. I have LOTS of experience (none of which I need to get into specifically), you should be able to tell based on my posts. I am not perfect and I will be the first to admit it. The goal here is for everybody to learn and comments like that are very conter-productive. If I do make a mistake, I would appreciate you come forward like a man and tell me I am wrong and why, so I can learn from my mistakes.

If you find something on this, I would appreciate that you post links or something with factual evidence, instead of telling me to go read a book.

Enough Said......

just because the DF bit is not set doesn't mean that the packet is automatically fragmented. It is just set when the packet is absolutely NOT fragmented.

Yup, agreed

Also, since you know alot about TCP/IP, you should know that the SYN bit is also set in the first step of the TCP three-way handshake. Therefore this would be the expected output from a user running a TCP-connect scan. (which happens to be the default for nmap), and again reinforces my position that the attacker was most likely NOT very knowledgeable.

Here we disagree, do you think it more steatly or productive to run a syn/fin scan, a null scan
and so on? Each scan performs differing things ie: simple scan, inverse mapping,...
Does not mean your an amateur for using a syn scan.

If you find something on this, I would appreciate that you post links or something with factual evidence, instead of telling me to go read a book.

Well I am sorry you took my post to be offensive or degrading. It was not meant as such.

-----------------------------------------------------
IP Fragmentation

Fragmented Internet datagrams are printed as
(frag id:size@offset+)
(frag id:size@offset)
(The first form indicates there are more fragments. The
second indicates this is the last fragment.)
-----------------------------------------------
You are correct on the above, my mistake. A rather egregious one at that. Oh well I posted too
quickly. The rest of my post stands for itself though. As for reading a book that was simple advice. As I have been told before one should not be so thin skinned. I have re-read my post
and saw nothing offensive or degrading in it. If you did however read my comments a para or
two above.

02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11

02:07:15.196486 xxx.xxx.xxx xxx.50464 > xxx.xxx.xxx.xxx.829: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20443, len 40)
0x0000 4500 0028 4fdb 0000 2906 6ba5 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 033d 3464 7893 0000 0000 .......=4dx.....
0x0020 5002 1000 543d 0000 0233 3503 3xxx P...T=...35.11

Also check out the above, note the tcp sequence numbers. There are all the same for 10
packets in a row. Then they change. The time hacks are different as well for each packet
which again supports my theory of packet fragmentation. As well because each Ip Id number
differs as well in each packet. Do you see what I mean now. I knew there was a reason why
I claimed packet fragmentation. Now there you have my reasons why.

I apologize for the misunderstanding of the intention of your post.

So, lets get back to the fun stuff....

When I think about this, I don't think it is possible to tell of this is a SYN scan or a full TCP connect scan. A SYN scan would send a SYN packet, and wait for a SYN-ACK from the target host, and the end the session, therefore only completing two of the three steps in the handshake, a tcp-connect obviously completes all three steps. Since the target never replies back with a SYN-ACK, can we really determine conclusively?

I do understand your point that the sequence number is static for a period of time, but I don't think this means that the packet is fragmented. If it was it would have a frag offset as in the example i posted earlier.

I will do some more research on this and let you know what I find, please do the same in case you are a better googler than I am ;)

BTW...I am sure you have already done this, but in case you haven't and for the sake of others who may be interested, check out http://project.honeynet.org/scans and check out the "scan of the month" section.

I also just bought the book "Honeypots" by Lance Spitzner, so when I get done with it, I will let you know how it is (Unless you already read it)

Oh yeah, also what do you mean by "time hacks"?

I apologize for the misunderstanding of the intention of your post.

No problemo!

So, lets get back to the fun stuff....

Sounds good!

When I think about this, I don't think it is possible to tell of this is a SYN scan or a full TCP connect scan. A SYN scan would send a SYN packet, and wait for a SYN-ACK from the target host, and the end the session, therefore only completing two of the three steps in the handshake, a tcp-connect obviously completes all three steps. Since the target never replies back with a SYN-ACK, can we really determine conclusively?

I should of been more verbose in my post. I should of said that this was all the packets exchanged in the trace between the parties involved. What I infer from the lack of syn/ack's
is that the packets were just dropped by the recieving end.

I do understand your point that the sequence number is static for a period of time, but I don't think this means that the packet is fragmented. If it was it would have a frag offset as in the example i posted earlier.

This in my mind implies a tcp sequence number attack or a new? form of fragmentation. It is
possible I think that it could slip by undetected. Can't say for sure though just a theory. There
are always new ways to break the stack out there. This may be one of em.

I will do some more research on this and let you know what I find, please do the same in case you are a better googler than I am

Roger that

BTW...I am sure you have already done this, but in case you haven't and for the sake of others who may be interested, check out http://project.honeynet.org/scans and check out the "scan of the month" section.

Yup been there. Too busy right now though to get into a scan. Too much on my plate. I do
plan on doing it more religiously though in the upcoming months in preparation for my sans
track.

I also just bought the book "Honeypots" by Lance Spitzner, so when I get done with it, I will let you know how it is (Unless you already read it)

I have not read it, give me your thoughts when done.

Oh yeah, also what do you mean by "time hacks"?

My own lingo, I mean that the time is different for each packet. I just call the time itself a time
hack. That's all.

The time for each packet will be different as a timestamp is appended to each datagram as it is sent. Since they can't all be sent at once, this is normal, or is that what you meant?

That is what I meant.

My 2 cents .....

My first look at the packet capture doesn't support fragmentation. ( I performed a translation of the hex dump provided)


First, there is no fragmentation offset in any of the packets displayed. Also the fragmentation ID changes for each packet (Fragments of the same datagram have the same Frag ID to aid in reassembly). The "0" bit that is set in the DF field tells all the network devices that this packet may be fragmented if needed.

By the way this is a great thread. :)

Guys, I apologize for jumping in at the last minute, but this is an awesome post. Im just trying to learn how to get into forensics, and Im learning a great deal. I started by looking at dons post and came up with a port scan but the target is behind a firewall or has iptables set to reject or drop incoming.
You mentioned using TCPDUMP for hex translation. I know that tcpdump is a *nix based program. I may be mistaken but I thought u said that the computer was a winnt or 2k.
Obake: how did u do the hex translation?
thanx guys and I hope to start postin here more often.
10Ded

First things first... Lets take apart a single packet to see what it tells us:

Code:

---

4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
5002 1000 53d9 0000 0233 3503 3xxx      P...S....35.11

---

For those who don't know, a byte is represented by two hexadecimal number, so each block of four characters in the packet shown above represents two bytes.

*** IP HEADER ***
The very first byte is '45' which means that the packet is IPv4 and the ip headers is 5 32-bit words long (20 bytes long).

The next byte is the TOS, which is 0. No surprise there. TOS isn't used for much these days.

The next two bytes '0028' represent the length of the total packet. By doing the hexadecimal math, we see that the entire packet is 40 bytes long. That's pretty standard for a SYN packet.

The next two bytes '4fda' represent the ID field. This field is most often used to assist in the reconstruction of fragmented packets. Nothing unusual for this one, but we'll take a look later to see if the pattern of ID fields is important.

Next are the fragmentation flags and offsets '0000'. None of the fragmentation flags are set, so this packet isn't fragmented, nor does the source care whether the packets are fragmented along the way.

The next byte is '29' which means the packet has a TTL of 41. This may be useful later for OS detection since TTL values vary widely among OS's. 64 is common is used in by linux, BSD, AIX and possibly some others, but it isn't a TTL you usally see from a windows OS.

The next byte '06' corresponds to protocol 6, which is TCP.

The next two bytes '6ba6' are the IP checksum. This is calculated by looking at the header as a series of 16-bit chunks. You simply add up all of the 16-bit chunks and then take the one's complement of the number. Since we don't have the IP's, we can't determine if the checksum is correct, so we'll assume that it is.

The next blocks (xxxx xxxx xxxx xxxx) represent the source and destination IP addresses and then we're done with the IP header. If there had been any IP options, they would have been right after the addresses, but we saw earlier that the IP header was 20 bytes long, so there's no room for IP options.

By the way don, if you really want to hide the IP addresses, you should have removed the r@J and replaced them with periods before posting them, because we cans still tell what part of the source IP address was.

*** TCP HEADER ***
The first two bytes represent the source port (50464) and the next two represent the destination port (929). These are uninteresting from a single packet standpoint.

Next is the four byte sequence number, which is again, uninteresting from a single packet perspective.

Next is the four byte acknowledgement number, which is 0 because this is the first packet of the attempted connection and therefore the system doesn't have any previous packets to acknowledge.

The next four bits '5' represent the length of the TCP header, which like the IP header is 5 32-bit words long, or 20 bytes long.

The next four bits '0' don't really mean anything since the block of bits is reserved for later use by the creators of the TCP header.

The next 8 bits represent the congestion flags and the TCP flags. Since the value is '02', it represents no congestion flags set, and only the TCP SYN flag set.

The next two bytes represent the TCP windows size. The '1000' in this packet represents a window of 4096. This is unusual, since I've never seen a value of 4096 before. I went to check the OS signatures list at the honeynet project and they didn't have any OS's listed with that window size either It's possible that these packets were crafted by a tool instead of being generated by the OS, or it's also possible that someone modified their kernel or edited their registry to change the defaults for this value. At any rate, it's going to make OS detection harder.

The next two bytes '53d9' are the TCP checksum, which are calculated similarly to the IP checksum above.

The next two bytes '0000' are the urgent pointer, and since they're set to zero, they're boring.

*** Extra stuff ***
The extra bytes '0233 3503 3xxx' on the end of this packet are unusual. They could be related to the recent discovery of ethernet interfaces leaking excess info, or they could be cause by the way that tcpdump stores packet information, or if the packets are indeed crafted, they could be an artifact of poor programming.

I was also confused about the '3xxx' and the '0xxx' in later packets. Were those an artifact of the way you replaced the Ip addresses? As best I can tell, I think they should have been '3131' and '0131' to correspond to the '11' and '.1' in ascii out to the right.

*** Patterns ***
The packets can obviously be grouped into three groupd based on source port. Each group scans 10 tcp ports (929, 829, 368, 1506, 521, 795, 192, 386, 703, 1541) and then moves on.

The ID field obviously increments by 1 per packet, both within the groups and across groups.

The sequence number is identical within the group but changes radically between groups, which is another clue that points towards crafted packets.

I can't find a common link between the ports scanned, but I'll keep looking.

10dedfish

TCPdump has a brother called Windump which runs on Windows systems or you can simply move the dump to a *nix system. However, I didn't go back thru the tread to check how he got the dump.

To "translate" a packet you just need the correct RFC ( or any document which shows the packet's layout) a little knowledge of the protocols and how to convert hex into dec. and bin. numbers. I use the rfcs, but you can get a book called TCP/IP illustrated which can help you in learning how to do packet analysis. You might also want to pick up another freebie called Ethereal, which is a GUI network sniffer that runs on Linux and Windows.

Str43m3r, the r@p means nothing. It is empty ascii. It alludes to nothing vis a vis an ip addy.

The characters r@J are tcpdumps attempt to turn the corresponding bytes into ascii characters. It only displays characters that are displayable ascii, everything else gets a '.' So in other words, by leaving the r@J to the right, we can still figure out what the bytes on the left were (the one's you changed to x's). So unless you changed the r@J to throw us off, the source IP address was ??.114.64.74. Am I right?

Hmmm, crap I did not know that! Thanks for the tip. The ip addy you have is wrong though.
The first two octets are correct, the last two are not however :-)

If I recall my system was set at 4096. It has a gigabit enabled motherboard. That would maybe show that the computer is a windows based computer. Sorry if this doesn't help, just thought I would throw that out there.


- Symbolic

Str34m3r,
Let me see if I understand your post correctly. The r@j in the fields on the right hand side are tcpdumps attempt to correlate the hex information to a readable format. By converting those characters to thier ascii numbers, then to hex it gives you the ip address. Im not quite sure that I understand how you accomplished this. And thanks for the detailed breakdown of the packet. I am currently pouring over it repeatedly to make sure I understand everything.

10Ded

This is by far one of the most informative posts I have seen anywhere. Rock on dudes.

02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11

02:07:15:196281 This is the time the packet was sent right down to the microsecond
xxx.xxx.xxx.xxx This is the source ip address
50464 This is the source port (this is an ephemeral port ie: a port above 1024)
> This is a director showing who is talking to who
xxx.xxx.xxx.xxx This is the destination ip address
929 This is the destination port, this is not an ephemeral port ie: it is under 1025
S This denotes it is a syn packet ie: the first step of a tcp/ip 3 way handshake
[tcp sum ok] This means the tcp sequence number is okay
878999699:878999699 This is the tcp sequence #, used to identify the tcp datagram
(0) This show how much data was sent in bytes ie: none cause this is only a syn packet
win 4096 This shows the amount of buffered information the machine has to send
ttl 41 This is the time to live before the packet is dropped
id 20442 This is the ip datagram number, it is used to reassemble fragmented packets
len 40 This is the length of the packet itself ie: 40 is right 20 for tcp 20 for ip

You can infer a few things from some of the metrics above;
win 4096 is normally associated with a windows box

ttl 41 is normally associated with a *nix box as they are coded with a ttl of 64
and windows is 128

Beyond that the packet is showing normal behaviour in as much as there are illegal
flag combinations ie: syn/fin/psh
The tcp and ip headers are both 20 bytes which is normal.
Remember a *lot* of information can be gleaned by the packet metrics. Whether or
not a packet is spoofed and so on. Look to the packet before you all the answers
are there.

Hope this helps
Don

Yo! 10ded did you read my post in this thread. The one that precedes this one. It breaks down all the fields. Take a look.