Ayoi’s

Managed to look some trace files gathered by log_packet.sh. I tried to apply structured traffic analysis methodology on those trace files as my technical write-up will be based on it. I think STA enable us to examine/data mining from the trace files where basically we can extract/construct/gather information thru statistical, session, alerts and full content data. Easier to identify normal, suspicious and malicious traffics

Anyway, from one of the trace file there’re 4 session record (top 4) which I think need a lil bit check up.

records SrcAddr DstAddr Dport Type

=================================

25 192.168.2.5 192.168.2.41.1962 tcp

25 192.168.2.11 192.168.2.102.31300 tcp

25 192.168.2.41 192.168.2.5.902 tcp

23 192.168.2.5 192.168.2.41.1971 tcp

It seems that 192.168.2.41 is lil bit chatty especially towards 192.168.2.5 at port 902.

There are 76 records (TCP) for conversation between 192.168.2.41 and 192.168.2.5

[ayoi@sguil trace-04-05-07]# racount -ar honeypot_trace.argus - host 192.168.2.41 and 192.168.2.5
racount records total_pkts src_pkts dst_pkts total_bytes

tcp 76 187448 116183 71265 173692298

arp 3 9 3 6 540

sum 79 187457 116186 71271 173692838

From full content data, I can’s see a thing and I suspect this communications were conducted in secured way or encrypted.

192.168.002.041.01971-192.168.002.005.00902: …. .w;s…|P.>..d…………”XxT1….. …….zfl.4q…..a…….z..I..

192.168.002.005.00902-192.168.002.041.01962: .r{rr..?…5;….E…@…C…..P.8){n.<YG..>m.L=7).m..u`.1 …..V.)w… ..J’\)….a.~..k……x.%…f..e…f..t.
. …}.+4.f…..fs…$=…5.s….a…..N.U.q….’..:c…………Ql……”……).-..~…/1.5\N….<..B..Xd..C.
…..a..c’…xH1..n’…n……
\`H3.^;/..3h.ym.om[..-.......56%..........1......Q... .-.P...3.FE....!-..m.....<.N.....Q%.1.K.'....oa#.=^....e:.|Y)a....h..N: {%.........I/.GH...c.4_.C.....W
........f...........^...V.....d...._.]..W…”…’&.N….!…L…p..r…k.1r..A.:….L$_…@.6…w……..U…{!..HE.S?….c)..(…..”…T……….Z>c.a..B..
….,S……E..u.&…d..k…..(……..V.#………I…e….W..H..(L.E…v?…..&o.W…..a.jX..q….(2:…..>u.u….,.7a*.AS6.L6L2L.R.1.v..48[:...lH&s.,.....
........N}.:D.#...3.u.E......Uh .7.,.O..*.....r.#,.G..i...}...F.4..Z.2.........{....?..^M..]….n…!.`.r’:..[r.&.}..Y.....3....K.....t..........H.n...o..E&_
...Ad
.W..<.E..|...wV.....%...Hy.'..!.%$..l.....iW1....[..nAkn.a.1$.f?..D...u9.).....$`K...K...W..~......4L.px..t..^M@-f..C,(...........qN....)."tu.P.....O?.3.>...
"...D...<.4M_.H.?.Xu..........

Bahh... Well let see what is actually running on port 902?

Old ways;

[ayoi@sguil trace-04-05-07]# nc -vv 192.168.2.5 902
Connection to 192.168.2.5 902 port [tcp/*] succeeded!
220 VMware Authentication Daemon Version 1.10: SSL Required, MKSDisplayProtocol:VNC

Ohh okay. Now I know.

Anyway for another session

25 192.168.2.11 192.168.2.102.31300 tcp

Well I do wonder what is port 31300 meant for?

racount   records   total_pkts   src_pkts  dst_pkts  total_bytes

tcp           25            250                125         125             14200

That’s the total session records for communication between 192.168.2.11 and 192.168.2.102 where the destination port is 31300.

StartTime Type SrcAddr Sport Dir DstAddr Dport SrcPkt DstPkt SrcBytes DstBytes State
04 May 07 17:43:32 tcp 192.168.2.11.3452 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:44:31 tcp 192.168.2.11.3453 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:45:30 tcp 192.168.2.11.3454 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:46:29 tcp 192.168.2.11.3455 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:47:28 tcp 192.168.2.11.3456 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:48:27 tcp 192.168.2.11.3458 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:49:26 tcp 192.168.2.11.3459 -> 192.168.2.102.31300 5 5 290 278 RST
04 May 07 17:50:25 tcp 192.168.2.11.3460 -> 192.168.2.102.31300 5 5 290 278 RST

———————————————Edited—————————————————————-

Interesting? Well the source port is increasing by 1, where the src and dst packet are 5 with 290 and 278 bytes respectively. Also the connection state is RESET. Scanning?

192.168.002.011.03452-192.168.002.102.31300: …………
192.168.002.011.03453-192.168.002.102.31300: …………
192.168.002.011.03454-192.168.002.102.31300: …………
192.168.002.011.03455-192.168.002.102.31300: …………
192.168.002.011.03456-192.168.002.102.31300: …………
192.168.002.011.03458-192.168.002.102.31300: …………

Nothing much can be seen here. And no alerts also generated when snort were asked to trigger any alerts from reading the trace file (The ones that has been defined only between 192.168.2.11 and 192.168.2.102)

So let see the trace file itself

17:43:32.682438 IP 192.168.2.11.3452 > 192.168.2.102.31300: S 2402359895:2402359895(0) win 16384 <mss 1460,nop,nop,sackOK>
17:43:32.682566 IP 192.168.2.102.31300 > 192.168.2.11.3452: S 3239928346:3239928346(0) ack 2402359896 win 5840 <mss 1460,nop,nop,sackOK>
17:43:32.685488 IP 192.168.2.11.3452 > 192.168.2.102.31300: . ack 1 win 17520
17:43:32.685618 IP 192.168.2.102.31300 > 192.168.2.11.3452: F 1:1(0) ack 1 win 5840
17:43:32.685691 IP 192.168.2.11.3452 > 192.168.2.102.31300: P 1:13(12) ack 1 win 17520
17:43:32.685810 IP 192.168.2.102.31300 > 192.168.2.11.3452: R 3239928347:3239928347(0) win 0
17:43:32.687122 IP 192.168.2.11.3452 > 192.168.2.102.31300: . ack 2 win 17520
17:43:32.687239 IP 192.168.2.102.31300 > 192.168.2.11.3452: R 3239928348:3239928348(0) win 0
17:43:32.687308 IP 192.168.2.11.3452 > 192.168.2.102.31300: F 13:13(0) ack 2 win 17520
17:43:32.687425 IP 192.168.2.102.31300 > 192.168.2.11.3452: R 3239928348:3239928348(0) win 0
17:44:31.667868 IP 192.168.2.11.3453 > 192.168.2.102.31300: S 641441975:641441975(0) win 16384 <mss 1460,nop,nop,sackOK>
17:44:31.667997 IP 192.168.2.102.31300 > 192.168.2.11.3453: S 3307726379:3307726379(0) ack 641441976 win 5840 <mss 1460,nop,nop,sackOK>
17:44:31.670103 IP 192.168.2.11.3453 > 192.168.2.102.31300: . ack 1 win 17520
17:44:31.670218 IP 192.168.2.11.3453 > 192.168.2.102.31300: P 1:13(12) ack 1 win 17520
17:44:31.670288 IP 192.168.2.102.31300 > 192.168.2.11.3453: F 1:1(0) ack 1 win 5840
17:44:31.670355 IP 192.168.2.102.31300 > 192.168.2.11.3453: R 3307726380:3307726380(0) win 0
17:44:31.673007 IP 192.168.2.11.3453 > 192.168.2.102.31300: . ack 2 win 17520
17:44:31.673133 IP 192.168.2.102.31300 > 192.168.2.11.3453: R 3307726381:3307726381(0) win 0
17:44:31.674712 IP 192.168.2.11.3453 > 192.168.2.102.31300: F 13:13(0) ack 2 win 17520
17:44:31.674827 IP 192.168.2.102.31300 > 192.168.2.11.3453: R 3307726381:3307726381(0) win 0

It seems that 102 is sending a RST flagged packet immediately after sending FIN flagged packet. It seems it doesn’t want to wait the FIN ack from .11 tho. Anyone can give a better analysis please?

p/s: I might as well ask the owner of 192.168.2.11 and 192.168.2.102 for this

Your input/view/opinion/criticism are highly appreciated. I’m still learning maa..

Comments RSS