According to the IT managers, this problem is neither at the server nor at the client but is suspected to be somewhere inbetween e.g. some DNS server that has been infected. Do you recognize this situation: A user browses the web to a homepage and gets spam links at webpages that don't actually send these links, and it appears at network locations rather than spec clients (if the client changes the network then the spam goes away).

enter image description here

What is the name of this breach that inserts spam links to webpages and how can it be traced and resolved? What traffic should be sniffed to locate the source?

  • Use the browser's debugging/development tools and see if you can find the content in the network traffic it reports. If you can then you will also find out where it is coming from. If you can't then you know (to the extent that you trust the dev tools to have recorded all network traffic) that the injection was local and is a plugin or some other stored scripting. Nov 18 '13 at 17:55
  • possible duplicate of How do I deal with a compromised server?
    – tylerl
    Nov 19 '13 at 4:32
  • @tylerl This looks like a problem with intermediate infrastructure rather than the server of the content, and the question isn't how to deal with the compromised machine but how to identify it. Your proposed duplicate has nothing to do with this question. Nov 19 '13 at 13:13

This seems to be something in the browser itself (assuming that's the program used to view the webpages in, and not some embedded view). This can be a number of sources:

  1. spyware
  2. malicious browser plugin (extension, theme, searchbar, ....)
  3. JS loaded from malicious domain (either through proxy or DNS)

For 1 & 2, there's many options available since it appears to be client based. For 3, say a website (www.safe.com) includes a javascript from a 3rd party (say, google-analytics.com). A rogue DNS or proxy server/process/... can intercept all there HTTP requests, and inject JavaScript itself. This JS can be used to alter the DOM as you can see in your example.

A possible solution would be to include the HTTPS equivalents of the scripts. From a direct client point of view, plugins such as noscript and so on would work well, although they might break some functionality in JS loaded web apps.

  • Source 3 that you mention is likely from what we see.
    – Niklas R.
    Nov 18 '13 at 19:22

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.