This may be more of a routing question than a security one but I am asking for the reason of security.

I monitor an IPS on a remote network and there have been high alerts triggered recently that match stings within web pages that various users access throughout the day. I have looked into a few packets and seen that certain strings suggest the user is accessing sites such as Twitter and Expedia, sites which seem unlikely to contain malicious code.

I want to be able to find the original web page from which the string matched the signature to look for myself, but this is where I fall short.

When I perfom a tracert from the remote network to each of the destinations in question there are 5 hops through the same path and the final hop is the destination I specified to trace.

So my question is -

why does the packet not contain information pertaining to the true source of the information encapsulated within it?

  • I confess I'm a bit lost and confused. What packet? What do you mean by "pertaining to the true source"? What sort of answer are you expecting? I wonder if perhaps you might be making some incorrect assumptions about how tracert works (?). I also am not sure I understand completely what your tracert findings are. (Perhaps post a link to a pastebin with the tracert command line and output?) – D.W. May 10 '12 at 10:09
  • Sorry to be so ambiguous... Basically I have a packet capture from the alert the IDS has tiggered for various 'exploits' it thinks it has matched signatures to. The source IP of the alarms are what I'm trying to trace a route to so that I can view the web page (for the broswer exploits) that it's alarming. I hope I've cleared it up a little. Unfortunatly I'm not able to post any specific information about IPs etc. – XOR May 10 '12 at 10:16
  • 1
    Ok. So what's the question, then? You have the source IP of the alarms. What are you looking to learn? I don't understand how a tracert is going to help you view the web page or gain any further understanding of the nature of the exploits. I have a suggestion. Why don't you tell us what you're really trying to accomplish (the real goal), and what you've tried so far, and maybe we can give you suggestions about next steps. Are you trying to figure out whether your end machines are secure against these attacks? Identify which of your machines might have been compromised? Something else? – D.W. May 10 '12 at 10:33
  • I'm trying to figure out if these alarms are false positives or not, by taking a look at the page myself. I thought the source IP of the exploit mentioned in the packet would be the actual web page the user has viewed, but it is not. The reason I used tracert was because I was expecting the end of the route to be the actual webpage that the user visited. I'm guessing that it's not possible to use tracert in this way? I'm sorry if my answers are frustaring I just lack knowlege in this area of IT. – XOR May 10 '12 at 10:40

Packets do contain information about the source of the packet: the IP source address field contains the IP address of the source of the packet. IP source addresses can be spoofed, but for TCP connections over a wired network, this kind of spoofing is generally more effort than most attackers are likely to go to. Therefore, this IP address is generally reasonably reliable as the source of the packet, for TCP connections over wired networks.

Tracert doesn't seem to be of any obvious relevance here. If you are getting the same path to several different hosts, maybe those hosts are all hosted on the same local network. (Another possibility is that you have been infected with DNS hijacking malware, which redirects all DNS lookups to point you to a malicious proxy host. A quick-and-dirty check for this by doing some DNS lookups on your system and on another totally independent system and seeing if you get the same answer.)

It sounds like the real question is you want to visit the web page yourself in your browser, and you're asking how to do that, given a packet trace. First off, please be pretty careful about this: you could easily end up getting compromised. Run your browser in a disposable VM, and throw away the VM after you've finished your investigation.

To visit the web page, you'll want to open up the packet capture in some packet analysis tool (e.g., Wireshark), find the HTTP request, look at the destination IP address where that HTTP request was sent, and replay the request to that host and port. Note that you may need to send the exact request exactly as it is: you may need the Host: header, if the site is usual virtual hosting, and you may need other headers to be right, if the malware hosting site is using referers or other headers to determine how to respond to the request.

You could try extracting the URL from the request (the hostname can usually be extracted from the Host: header, the URL path can be extracted from the GET line of the HTTP request), then opening that URL in your browser (in a throwaway VM, please). As a quick-and-dirty check, this might suffice.

If you have a packet capture, there may be an even easier way. If you open up the packet capture in Wireshark, Wireshark will decode the entire TCP connection, reassemble all the traffic, and show you the bytes sent in both directions. You can use this to view the HTML source sent to your machines.

That said, I'd question whether any of this is a good use of your time. I'm not sure what you expect to learn. Usually, trying to trace through the HTML/Javascript code of a web exploit is a waste of time. You may have to dig through dozens of redirects and other steps, then de-obfuscate the code, and peer through pages of code to get an idea of what it's doing. And once you've done that, what have you gained? Basically, nothing much. It's usually better to leave this analysis to the security/IDS companies, and focus your energies on things that will actually protect you: e.g., focus on ensuring that your end machines are running patched up-to-date browsers and other software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.