Analysis and Consideration on traffic hijacking of an e-commerce website (1)
Preface]
When I visited the homepage of an e-commerce website at home one day, I was suddenly surprised to find that the browser suddenly jumped to a third-party website and then returned to the e-commerce website. The first response was a Trojan.
In this case, we must unload eight Trojans.
Troubleshooting]
First, capture packets in the case of reproduction. The e-commerce website does return a piece of JavaScript to redirect the browser to yiqifa.com.
Is the packet capture at the application layer.
The Code returned by the server causes a jump. The local Trojan can be basically ruled out, and it is assumed that it is a network or server problem. Based on my experience, this situation is probably caused by traffic hijacking on the link. Of course, it cannot be ruled out that the e-commerce server is hacked.
Continue troubleshooting. The application layer is no longer working. We need Wireshark to capture packets at the network layer.
From Wireshark results, we can see that there are two HTTP responses for the e-commerce website on the network. The first one is first served, so the JavaScript code in the browser is executed to yiqifa.com; the second HTTP response is ignored by the system because it is late (Wireshark recognizes it as out-of-order ).
These two HTTP response packages must be fake. It's time to reveal the truth.
Let's take a look at the two HTTP Response IP headers.
The TTL value of the first packet is 252, and the TTL value of the second packet is 56. The TTL value of the e-commerce server is 56 when the TCP three-way handshake is performed, therefore, it can be determined that the first packet is forged, and the package is ignored by the system when it comes late.
At this point, it is confirmed that the link is hijacked.
For more information about link hijacking attacks, see the article "link hijacking attack one, two, three" written by the author.