In February 2018, The Los Angeles Times served Coinhive cryptomining code to visitors after an unauthorised party modified JavaScript in an AWS S3 bucket that allowed public write access, with first known evidence dating to February 9 and removal on February 22.
The reported facts point to more than a single storage misconfiguration. Because the miner was delivered through an existing site page, production web assets were not only exposed but editable in place and there was no effective integrity control ensuring deployed code matched an approved source. The malicious code also persisted for days rather than being overwritten by a normal build or release process, suggesting weak deployment discipline for a public-facing environment. Detection was also lacking: discovery came from external researcher Troy Mursch rather than internal monitoring of S3 write activity or browser-delivered script behaviour. For a publisher whose revenue depends on its front end, this reflects a clear governance and security control gap around static hosting, code promotion and production content monitoring.
| What Happened | Cause | Action |
|---|---|---|
| Public web assets were writable by unauthorised users | The Los Angeles Times’ AWS S3 bucket was misconfigured to allow write access to anyone, enabling modification of hosted JavaScript | Organisations should validate that internet-facing S3 buckets used for web delivery are not publicly writable, that ACLs and bucket policies block anonymous write actions and that public access settings are intentionally controlled. SkySiege assesses S3 bucket policy, ACL exposure, public access block posture, static website usage and whether any bucket combines public read with unauthorised write paths. |
| Production code could be changed directly in storage | The malicious outcome required existing site-delivered code or referenced JavaScript to be editable in the bucket, with no control preventing unauthorised production changes | Organisations should validate that production web assets are deployed only through controlled pipelines and that direct mutation of served code is blocked. SkySiege assists with providing full visibility of resource access and identity capabilities, showing who or what is able to control resources in the cloud including write access to buckets. |
| No integrity control ensured deployed content matched approved code | Source evidence shows malicious JavaScript remained live on the website, indicating no effective mechanism ensured what reached users matched a trusted build output | Organisations should validate artefact integrity controls for static assets, including immutable builds, trusted deployment paths, version control alignment and change approval for production content. |
| Malicious changes persisted for days without being overwritten | First known evidence was February 9 and removal was February 22, which suggests the environment was not being rebuilt or redeployed frequently enough to replace tampered assets | Organisations should validate build cadence for public-facing environments and whether routine deployments would restore known-good assets. |
| Detection failed at both the storage and browser-delivery layers | Discovery came from researcher Troy Mursch rather than internal controls and no evidence shows automated alerting on unauthorised S3 writes or malicious script behaviour on the live page | Organisations should validate logging and alerting for object writes to public web buckets, high-risk policy changes and unauthorised JavaScript execution on production pages. SkySiege analyses logging and access to provide a human friendly determination of what activity is actually going on with a cloud identity. |
| A revenue-critical front end lacked sufficient protection from unauthorised software release | The website delivered third-party cryptomining code to visitors, showing weak governance over what software could be published to the paper’s public site | Organisations should validate governance over all content injection paths, including cloud-hosted scripts and legitimate tooling that can alter front-end behaviour. |
This incident is a clear example of a cloud storage misconfiguration turning into unauthorised software distribution. The immediate issue was a publicly writable S3 bucket, but the more important lesson is architectural: production web content was mutable in place and there was no effective integrity check proving that what users received matched approved source or deployment output.
That creates a broad detection and visibility problem. If a public-facing site can be altered by changing objects in storage, then security teams need both control-plane visibility into write events and content-level monitoring of what is actually delivered to browsers. Here, neither appears to have worked. The compromise was identified externally and the miner was reportedly throttled to reduce CPU impact and avoid obvious detection, which increases the likelihood that low-noise abuse could remain live for extended periods.
The governance weakness is equally important. For a publisher, the front end is a revenue-critical asset and a trust boundary with readers. Unauthorised code on that surface creates reputational damage, visitor harm and possible legal or compliance exposure if users are subjected to unapproved processing or deceptive content delivery. Financially, the same control gap could have enabled more damaging payloads than cryptomining, including credential theft, malvertising or widespread content tampering.
From a SkySiege perspective, this is the kind of issue that our software catches early through cloud posture analysis tied to architecture context: public buckets serving web assets, write exposure, mutable production delivery paths and missing guardrails around code promotion. The incident shows why cloud governance cannot stop at public read exposure; public write, direct production editability and lack of deployment integrity are materially higher-risk conditions with enterprise impact.
