0

I clicked on a link (indistannews.com) and was redirected to a different website (sexiniowa.com). [Warning - the latter site is a pornography website].

I looked at the transaction in Wireshark to try and see how I was redirected. All I see is a 3-way TCP handshake initiated by my client to the original correct IP (50.63.202.1), and then immediately after a NEW TCP handshake to a totally different IP (63.163.163.134) which contains the pornography.

Why did my client choose to drop the original connection and initiate a new connection to this second IP? What information in the first 3-way handshake (if any) prompted my client to do this?

-Nick

enter image description here

NickJones
  • 1
  • 1
  • 2

2 Answers2

1

A TCP handshake does not contain any redirect information. If you check instead at the application layer you see:

$ curl -v http://indistannews.com/
...
< HTTP/1.1 301 Moved Permanently
...
< Location: http://sexiniowa.info

Since this is a 301 permanent redirect the client does not even need to visit the original site again but will instead use the new location on repeated tries. Only on the first try it will visit the original site to receive the redirect. And this is what your packet capture might show.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Follow up questions for you: 1) If my client only tries to visit the original site on the first try, then why on the second try (captured above) did it perform a TCP handshake with the original site, before moving on to communicate with the second site? 2) Do you have any idea where the permanent URL redirection info is cached on my client? – NickJones Jul 16 '17 at 21:33
  • @NickJones: I have no idea why the empty TCP handshake was done - maybe to check if the original source of the redirect is still up? And for caching I would suggest the usual browser cache, i.e. try to empty it and then retry. – Steffen Ullrich Jul 17 '17 at 07:03
1

You might want to try using Burp Suite or Fiddler to intercept application layer traffic, which will give you better sight into how the redirection happens.

You should check sequence of url loading, right before the redirection happens, that might be a malware affected url.

Kaushal Bhavsar
  • 11
  • 2
  • Thanks Kaushal. Do you mind giving a little more details about your responses? If I use those programs to examine packet information right before redirection, how will that give me more information about a malware-affected URL? -Nick – NickJones Jul 16 '17 at 21:35