Crypto miner injection on internet routing hops of my ISP
I forgot to publish this article 1 year ago, so I’ve published it now.
Let’s begin with a small introduction how I realised it and after that in more technical detail so you will understand it better.
We write the 17th of September 2018 and I’m sitting at home on my main computer and preparing a presentation for the next day. Of course I did some research for it and visited some other websites to gain information. During the research I noticed that partly some web pages won’t load correctly. Instead a white page was shown in the browser and I end up in a Chrome “could not load” error. That was because the actual site which I want to visit was embedded in an iframe and had the x-frame-options header set to ‘sameorigin’ (realised using Chrome DevTools). That means, that the browser will block requests when I e.g. want to embed the https variant of amazon.com onto a http page, despite that it was on the same origin.
At this point I already knew that http websites were randomly modified, so a crypto miner were injected and the actual website were displayed in a 100% high and 100% width iframe by a man-in-the-middle attack. But it wasn’t clear, if my network, my computer, routing hops or the complete ISP was causing that. Let’s create some test cases:
- watch -n 5 curl http://amazon.com
This command will fetch and display the content of the amazon.com website every 5 seconds and displays it directly in the terminal. So I detected that in summary approximately every 15th request was modified. This was really handy because amazon.com of course doesn’t allow it to visit the page directly via http in the browser. They redirect directly onto their corresponding https variant. I executed the same command on my Raspberry PI (same network), so I can exclude my own computer from an infect. And boom, same issue there:
So now let’s take a look on other web pages, if it’s also reproducible there. So I checked the content of the http variant of amazon.com. And as I feared, there were no issue with amazon.com itself. It was reproducible with every website which has used http:// like ebay.com. But amazon.com is good for testing, because it has set the header which disallows the embed into an iframe (so the actual attack vector does not work, yey).
The other possible issue was my local network. So I’ve used an external virtual server to check again via the curl command the response of the http variant of ebay and amazon. And it was not reproducible as expected.
At this point we know it only happens on my network. So after further research I did a traceroute to ebay.com and checked the internet routing hops which my request will pass.
First hop is of course my local router. The next few, in this case 3 where the hops of my local cable Internet Service Provider (ISP). After this we reach some more bigger nodes and in the end we go through a router in Frankfurt straight directly to the infrastructure of ebay in that example.
Like on the screenshot above (curl to amazon) we saw, that a Mikrotik HttpProxy was used to serve the request, we detected it via the User-Agent http header. So I just used curl in the first 3 hops directly and there I got the same result. Injected cryptominer via obfuscated JavaScript and the actual page was displayed in a 100% x 100% big iframe. This was also reproducible outside of my network, e.g. on a virtual server.
Now I ended up in analysing more detailed this issue, so I e.g. used other browsers in this case and visit the ebay.com page. In both browsers, the CPU spikes directly up and the crypto mining process was very active. You see it in this screenshot, that Edge could not load the iframe because of the header but the crypto mining were in progress.
That are the Chrome DevTools during the crypto mining process. The request order was the following:
- the actual page were loaded but compromised via a mitm attack. The following file were injected via JavaScript: hxxps://srcip.com/src.js
- This JavaScript adds another iframe to the page which loads an obfuscated JavaScript via a kind of a load balancer. I call that “kind” because hxxps://www.hostingcloud.science./bOUb.js randomly redirects to URLs for the payload: hxxps://www.hostingcloud.science./bOUb.js hxxps://www.hostingcloud.faith./bOUb.js hxxps://www.hostingcloud.bid./bOUb.js hxxps://www.jshosting.trade./bOUb.js hxxps://www.freecontent.party./bOUb.js
- That obfuscated JavaScript is the Crypto currency client which mines it. The key (6a992967a4e9da78e3671393154923f17775bd5e9d86f11bce6d30bc6309244a) is stored in the main page which was directly served.
- As far as my understanding is, the keys or stuff which has to be exchanged during the crypto mining will be served via HTTP Requests in a Service Worker.
I directly contacted my ISP (TKN Deutschland) which was a victim of this kind of attack. He fixed it directly by replacing their Mikrotik routers on their network.
For more information, check out the following resources:
- https://badpackets.net/200000-mikrotik-routers-worldwide-have-been-compromised-to-inject-cryptojacking-malware/
- https://docs.google.com/spreadsheets/d/1RdT_r4fi4wPx5rY306FftVKaXiAZeQeb5fx78DmbVx0/edit?usp=sharing
- German press article by Golem about that specific ISP case: https://www.golem.de/news/mikrotik-proxy-server-fuegen-kryptominer-ein-1810-137071.html
I’ve already sent abuse reports for the domains and can successfully say, that they’ve taken down srcip.com which has delivered out onto 106k compromised Mikrotik routers.
Update 16.10.2018: Some good hackers have patched remotely most of the affected Mikrotik routes via the CVE vulnerability (German press article).
