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.
