Browsealoud Breach Compromised Government Websites

4 minute read

Many sites (including the Information Commissioners Office) have been loading a script hosted by the assistive technology company, This script had been modified to load a Coinhive script into client’s browsers which uses the device’s processing power to mine cryptocurrency for the associated Coinhive account.

icoBajs Chrome Dev Tools showing a request for the Coinhive script

It’s possible that the attack occurred on 11th Feb 2018 at 11:14:24 GMT judging by the HTTP headers returned with the script (as seen in the picture above).

Currently, it’s unknown as to how the script came to be included inside Texthelp’s Browsealoud product. Texthelp create assistive technology solutions. The script involved in this incident is designed to add speech, reading and translation to websites, though in this instance, it has added what is most definitely, unwanted functionality.

The script was being distributed through Amazon Web Service’s CloudFront Service as seen here:

coventryGovUkBrowseAloudCompSc have now taken the site down and are returning a 404 (not found) error to all requests for the script. They responded on Twitter with this:

Scott Helme pointed out on Twitter that there were likely to have been at least 4,275 sites affected:

It appears that Texthelp have rerouted the requests to the same server which runs ( which is producing a certificate error for any requests for the script via HTTPS. Though I think we can all agree that this is much better than leaving the compromised script online.

It’s rather unfortunate that the ICO is one of the victims but it’s only one of what is worryingly large group (including Texthelp themselves). There’s no way to tell exactly how many sites use the script though there’s definitely a fair share of high profile ones that do. There are requirements for government sites to make use of assistive technologies and as such I imagine there will be a lot of government related sites affected.

The unfortunate people who happened to visit one of the many sites during the time the compromised script was in play will have mined cryptocurrency for an anonymous Coinbase account (site key: 1GdQGpY1pivrGlVHSp5P2IIr9cyTzzXq). Coinhive is blocked by several antivirus vendors and AdBlock browser extensions so it’s possible that some devices didn’t run the Coinhive script.

It’s incredibly disappointing to see such an incident was able to take place given that there are plenty of ways to prevent such a thing from happening. It’s yet another incident in a long line which would have been easily preventable. It should spark another round of reactive “we should probably fix this” and hopefully sites do implement the safeguards to prevent such an incident from happening again.


We have no idea what the attack vector was, but I’ve got a few thoughts what it might have been. The compromised script was available via HTTPS (with a reasonably old certificate) which makes me fairly certain it wasn’t a case of compromised DNS. I also feel like the attack wasn’t “that” severe.

The fact the same key was used around a week ago sort of feels like they were testing the concept but conversely, it feels simple. There’s not much they couldn’t do with the ability to inject JavaScript into a site, but they chose to inject a Coinhive script? Sure, it’s a quick way to make some cash but it just doesn’t feel that “impressive”. I wouldn’t be too surprised if it turned out to be an opportunistic attack using some leaked developer credentials for the AWS S3 bucket (I also doubt there was much else in that bucket).

Short link: