HTTP Response no HTTP Request same TCP session?

[KEVINDIENST]

I ran into a problem during an investigation where one of our analysts was unable to identify the network session in NetWitness, but had a packet from the IDS supporting a SQLi attempt. 

Basically I was able to isolate the network session in NetWitness but IDS reported TCP src port as 57702, whereas I only found the HTTP request via TCP src port 57710. When I query NetWitness for 57702 I see an event where service = 80 && tcpflags = 'syn' && action !exists && result.code exists. I see the http RESPONSE only in the pcap from netwitness, not the full request/response I expect. 

Example of the pcap in wireshark. 

Has anyone seen this before?

If I run that query against all my packet flows I get millions of sessions. 

service = 80 && tcpflags = 'syn' && action !exists && result.code exists

What is this traffic? I would expect that every HTTP session has a request/response and thus the HTTP method. 

What am I missing? Is this potentially continuation traffic? Does NetWitness cut off the event after 60 sec/32MB and then if we see the response we mark it as a separate session?

[SergioAlmeida]

Hi Kevin,

Does NetWitness cut off the event after 60 sec/32MB and then if we see the response we mark it as a separate session?

Yes that seems to be the case, that is the time the event stays in memory and part the same session after that it will be like another session, you can increase that value in a special cases but you will have some performance impact.

I hope that answered your questions.

Thanks,

Sergio

[GuyBruneau]

Hi Kevin,

If you have multiple sessions (over 32 MB), you can see the multiple sessions by adding session.split to your "Events tab" to see all the sessions associated with the same traffic.

Guy

[SergioAlmeida]

That is correct 10.5 or later release there is a option for secession split, you access the details on the link below:

https://community.rsa.com/docs/DOC-63893

[KEVINDIENST]

There is no session.split metakey in this event. Examples below. 

sessionid	=	1009972394451
time	=	2017-08-08T19:45:18.0
size	=	1948
payload	=	1480
medium	=	1
eth.src	=	00:1C:7F:63:49:37
eth.dst	=	40:01:D7:D0:B4:90
eth.type	=	2048
netname	=	"other src"
netname	=	"other dst"
ip.proto	=	6
tcp.flags	=	27
tcp.flags.seen	=	"fin syn psh ack"
tcp.srcport	=	57702
tcp.dstport	=	443
service	=	80
streams	=	2
packets	=	7
lifetime	=	1
result.code	=	"404"
error	=	"404 Not Found"
content	=	"text/html"
requestpayload	=	0
responsepayload	=	1480
analysis.session	=	"ratio low transmitted"
analysis.session	=	"watchlist port"
tcpflags	=	"fin"
tcpflags	=	"syn"
tcpflags	=	"psh"
tcpflags	=	"ack"
analysis.session	=	"session size 0-5k"
country.src	=	"United States"
city.src	=	"Clifton"
latdec.src	=	40.8326
longdec.src	=	-74.1307
country.dst	=	"United States"
city.dst	=	"Minneapolis"
latdec.dst	=	44.8784
longdec.dst	=	-93.2793
org.src	=	"Digital Ocean"
org.dst	=	"U.s. Bancorp"
analysis.session	=	"not top 20 dst"
domain.dst	=	"usbank.com"
tld	=	"com"
sld	=	"usbank"
risk.info	=	"watchlist_ports"

Obviously some data was sanitized/redacted but there is no session.split key in the meta list for that top session listed as 2KB in size. 

I was under the impression that session.split is tagged to the first session that runs over the limits. 

Session Start > Limit Reached > Tag session.split 

If we have cut that session off and THEN we get the HTTP response code on the wire as part of the same TCP session, does NetWitness know that it is a fragment of the previous session? Does it reference the absolute TCP sequence numbers or how?

Thanks

[GuyBruneau]

NetWitness does track multiple sessions that are associated together.To reconstruct the file, select all the session 0 to ... and use Wireshark to extract the file that was transferred.

This is session split via List View download of an AV update from Comodo each of the session is 32MB and the last session closing the end of the file at 15MB.

This is another representation in a custom view in Events tab of the same traffic. See the left of the picture that list all the sessions starting at session 0.

Note: session.split is not indexed.

[Anonymous]

If you look at the meta for streams (2), requestpayload (0) and responsepayload (1480) this tells us that the packet decoder saw a two sided session (request and response) but there was nothing in the request side.  This does not appear to have anything to do with 32mb sessions or session.split meta.

The screenshot from wireshark seemed to indicate that when it showed ACK's to an unseen segment.  The decoder may never have seen the first half of that session payload despite seeing all the flags in the session.  

Is this decrypted SSL or something else?  Noticed the dest port was 443, but service was 80.

Chris

[KEVINDIENST]

Exactly what I was getting at Chris, it looks like there was no request, but no indication it was a continuation related event. It is indeed decrypted traffic. 

Thus why wouldn't the decoder have seen the first part of the segment? I suppose it could just be dropping data on the floor potentially and I don't have evidence to confirm/nor deny that at this point. 

[Anonymous]

Not sure we can determine that at this point.  Would possibly need to look at the decryption source to see what was going in and what was coming out.  

I had created some app rules around similar kinds of traffic.  I suspect what you are seeing is not limited to this one session.

Single sided sessions are common in networking.  UDP can do this often but TCP can also show this activity at times.  Sessions are guaranteed to have a request but not guaranteed to have a response.  Therefore, I wanted to know which side the decoder was seeing.

name=tx_no_rx rule="streams = 1 && requestpayload exists && responsepayload !exists" alert=analysis.session order=382 type=application

name=rx_no_tx rule="streams = 1 && requestpayload !exists && responsepayload exists" alert=analysis.session order=383 type=application

I also wanted to know if one of the sides had zero (0) payload.  

name=tx0 rule="streams = 2 && requestpayload exists && requestpayload = 0 && responsepayload exists && responsepayload > 0" alert=analysis.session order=384 type=application

name=rx0 rule="streams = 2 && requestpayload exists && requestpayload > 0 && responsepayload exists && responsepayload = 0" alert=analysis.session order=385 type=application

Both sets of app rules could be useful for troubleshooting as well as for analysis.

I've attached the rules as an NWR file.  Please note these rules rely on the requestpayload and responsepayload meta keys as well as analysis.session for writing meta.  These keys are part of the hunting content pack released last year and I think are part of all new 10.6.x versions (not 100% on that though).

Chris