AnsweredAssumed Answered

HTTP Response no HTTP Request same TCP session?

Question asked by KEVIN DIENST on Aug 16, 2017
Latest reply on Aug 17, 2017 by Christopher Ahearn

Like • Show 0 Likes0
Comment • 8

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?

No one else has this question

Outcomes

8 Replies

Sergio Almeida Aug 16, 2017 12:19 PM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
Guy Bruneau Aug 16, 2017 12:51 PM
Mark Correct
Correct Answer
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
Like • Show 1 Like1
Actions
- Sergio Almeida @ Guy Bruneau on Aug 16, 2017 1:38 PM
  Mark Correct
  Correct Answer
  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
  Like • Show 1 Like1
  Actions

KEVIN DIENST Aug 16, 2017 2:28 PM

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

Actions

Guy Bruneau Aug 16, 2017 4:38 PM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
Christopher Ahearn Aug 17, 2017 12:12 PM
Mark Correct
Correct Answer
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
1 person found this helpful
Like • Show 1 Like1
Actions
- KEVIN DIENST @ Christopher Ahearn on Aug 17, 2017 12:24 PM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
  - Christopher Ahearn @ KEVIN DIENST on Aug 17, 2017 1:13 PM
    Mark Correct
    Correct Answer
    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
    Attachments
    txrx_rules.nwr.zip302 bytes
    1 person found this helpful
    Like • Show 1 Like1
    Actions

HTTP Response no HTTP Request same TCP session?

Outcomes

Attachments

Related Content

Recommended Content