Everything is done via a stock SQUID proxy with small config changes.
The idea is pretty simple:
1. [Server] Install Squid on a linux server
3. [Cache] Set the caching time of the modified .js files as high as possible
This technique also works with https if the site loads unsafe resources (eg. jquery from a http site). Most browsers will tell you that, some might even block the content but usually nobody gives attention to the "lock" symbol.
In a presentation at DefCon Chema Alonso said he posted the IP of a modified server on the web and after a few days there were over 5000 people using his proxy. Most people used it for bad things because everyone knows you're only anonymous in the web when you've got a proxy and it looks like many people don't think that the proxy could do something bad to them.
Make your own js infecting proxy
I assume that you have a squid proxy running and also you'll need a webserver like Apache using /var/www as web root directory (which is the default)
Step 1: Create a payload
For the payload I'll use a simple script that takes all links of a webpage and rewrites the href (link) attribute to KrebsOnSecurity.
Step 3: Tell Squid to use the script above
in /etc/squid/squid.conf add
Step 4: Never let the cache expire
ExpiresDefault "access plus 3000 days"
These lines tell the apache server to give it an insanely long expiration(caching) time so it will be in the browser of the user until they're cleaning their cookies/caches
One more restart of squid and you're good to go. If you're connecting to the proxy and try to surf on any webpage, the page will be displayed as expected but all links will lead to Brian Krebs blog. The sneaky thing about this technique is that even when somebody disconnects from the proxy the cached js files will most likely be still in their caches. In my example the payload does nothing too destructive and the user will know pretty fast that something is fishy but with creative payloads all sorts of things could be implemented.