Beacon, a UK customer relationship management provider for charities, published its final incident report on 3 September and concluded that the intruder had likely exported everything in its customer database, attachments included1. A CRM holds a charity's donor and beneficiary records, which for many of Beacon's customers is the most sensitive list the organisation owns and the one it has no other copy of.
The intrusion began at 01:20:16 UTC on 27 July and ran for about 87 minutes, correlated with a spike in data transfer out of Amazon Web Services across 27 and 28 July2. The data was encrypted at rest, but the attacker held valid AWS credentials, so what came down the wire came down readable. Beacon traced the probable root cause to a compromised AWS access key that may have been exposed in public JavaScript build artefacts, reset every credential integrated with AWS, and said it had not engaged with the threat actor3.
A key baked into a front-end build and served to anyone who loads the site is not an exotic failure, and it defeats every control that assumes an attacker must break something. This beat has watched the same shape at a very different scale, when 86,644 Fortinet credentials sat in private hands before any advisory named the problem. Valid credentials do not trigger the alerts that exploitation does, which is how 87 minutes was enough: it is shorter than the detection and response cycle most small organisations actually run.
The customers here are charities, working on small Teams and donated infrastructure, with no security operations centre to notice a transfer spike at two in the morning. The Scottish Council for Voluntary Organisations was telling Scottish charities what to do on 4 August, the day after Beacon first notified customers4. Beacon's own report remains the only account of what happened, and no regulator has published a finding on it.
