Connect with us

Infosecurity

One Exposed AWS Key. 1,500 UK Charities. A Breach That Shouldn’t Have Happened.

Published

on

AWS access key

The Breach That Started With a Build Artifact

It started with a single mistake buried in JavaScript. A valid AWS access key was left exposed in public build artifacts — and that was all an attacker needed to walk straight into the CRM systems of roughly 1,500 UK charities.

Beacon, the software provider behind the platform, confirmed the finding in an incident update on August 12. The company admitted the key was likely exposed during routine software development. In other words, this wasn’t a sophisticated nation-state operation. It was a preventable slip-up with outsized consequences.

Once the attacker had the credentials, they didn’t need to break through layers of defense. They simply logged in and downloaded everything: the entire CRM database, including attachment files. Beacon’s assessment is blunt — the full customer base of charitable organizations was impacted.

What Kind of Data Was Taken?

The affected charities operate in some of the most sensitive corners of the sector. Healthcare. Victim support. Rape and sexual abuse services. The data held by these groups isn’t just names and emails — it’s the lifeblood of trust between a charity and its supporters.

Specifically, the breach exposed supporters’ names, email addresses, telephone numbers, and donation records. That combination is a gift for social engineering attacks. Armed with donation history, a scammer can craft a convincing phishing email referencing a past gift. It’s chillingly easy.

There’s some relief, though. Beacon says the CRM system did not hold sensitive patient information, payment card details, or bank account numbers. That limits the damage — but it doesn’t erase it.

Encryption Didn’t Save the Day

Here’s the uncomfortable part: the data was encrypted at rest in AWS. It should have been safe. But because the attacker used valid credentials, AWS decrypted the data on download. So the encryption was effectively a non-factor.

This is a critical lesson for any organization storing data in the cloud. Encryption at rest is a baseline, not a silver bullet. If an attacker has legitimate keys, they get the data in readable form. No exceptions.

Beacon’s own analysis of AWS Cost & Usage reports shows the malicious activity began on July 27 at 01:20:16 UTC and lasted about one hour and 27 minutes. That timing aligns with a sharp spike in data downloads on July 27–28. The attack was quick, targeted, and over before most people even noticed.

Charities Cleared, But Scams Loom

Beacon’s charity customers have all been advised to report the breach to the UK’s Information Commissioner’s Office (ICO). One of the confirmed victims, The Survivor’s Trust, already has. In a statement on August 13, the charity said the ICO reviewed its case and concluded the charity holds no responsibility for the breach.

That’s a small comfort. The charity, which provides specialist rape and sexual abuse support services, has urged supporters to stay alert to potential scams in the coming weeks. Expect phishing emails referencing your donations, your support, your history with the cause. That’s the playbook.

Other charities have gone public with their own disclosures: Shrewsbury and Telford Hospital Charity, the British Deaf Association, and Yorkshire’s Brain Tumour Charity. They join Sheffield Hospital Charity, Priscilla Bacon Hospice Charity, the Clock Tower Sanctuary, and Victim Support in admitting supporter data was compromised.

What Beacon Did Next

Beacon says it has not detected any attempts by the attacker to maintain persistence in its environment. That’s the one piece of good news. The attacker took the data and left — no backdoors, no lingering access.

The company has reset all credentials for services and accounts integrated with AWS to prevent repeat unauthorized access. It’s also monitoring for any signs the stolen data has been published or misused. So far, nothing has surfaced.

But the damage is done. For 1,500 charities, the trust equation has shifted. Supporters who gave their personal details now have to wonder: who’s got my information, and what will they do with it?

The Cloud Security Lesson No One Wants to Learn

This incident is a textbook example of a cloud misconfiguration leading to a data breach in the charity sector. It’s not about sophisticated malware or zero-day exploits. It’s about a developer accidentally leaving a key in a public file.

If you’re responsible for AWS security best practices, take note: credential scanning should be part of your CI/CD pipeline. Secrets should never live in build artifacts. And access keys should be rotated regularly, with least-privilege policies enforced.

Beacon’s customers are now left to deal with the aftermath — notifying supporters, managing reputational fallout, and hoping the ICO doesn’t come knocking with fines. The charities themselves were cleared of responsibility, but that doesn’t help the person whose donation history is now in the hands of a stranger.

One exposed key. 1,500 organizations. Countless individuals. That’s the cost of a single oversight.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Infosecurity

How Russian Hackers Took Down a Polish Power Plant’s Turbine — Through a Private APN

Published

on

private APN attack

The Attack That Took Three Months to Unravel

In late December 2025, a large combined heat and power (CHP) plant in Poland — one serving 50,000 residents — suddenly lost its steam turbine and water treatment system. The cause wasn’t a mechanical failure. It was a cyberattack, and it took Polish CERT (CERT.PL) investigators three months to piece together exactly how it happened.

The post-mortem, published in March 2026, reveals a chain of novel techniques that allowed Russian-linked attackers to reach the plant’s operational technology (OT) network through a private Access Point Name (APN). It’s the first documented case of threat actors using a private APN to breach an OT environment, CERT.PL claims.

This wasn’t an isolated incident. The attack came during a broader Russian campaign targeting 30 Polish renewable energy facilities and another large CHP plant, with the strikes occurring on December 29 and 30, 2025. The earlier report, released in January 2026, detailed wiper malware attacks attributed to Sandworm, a Russian state-backed APT group. This latest report adds a new chapter to that story.

The Intrusion Chain: From Wind Farm to CHP Plant

The attackers didn’t start at the CHP plant. They first compromised a FortiGate VPN and firewall at a wind farm elsewhere in the country. From there, they used a Teltonika cellular router on the same network to pivot toward a private APN managed by a distribution system operator (DSO), establishing an SSH tunnel into that network.

Once inside the APN, they scanned it repeatedly. Eventually, they found a WAGO PFC200 programmable logic controller (PLC) at the CHP plant. Its web interface was exposed via the APN and protected only by default admin credentials. A quick login later, and they were in.

From the WAGO controller, the attackers used SSH to hop into the plant’s OT network. They scanned for and found three Siemens PLCs — the devices that control the steam turbine and water treatment system.

Sabotage and Destruction

According to plant personnel, the PLCs were switched to STOP mode and password-protected, preventing any changes to their operating state or control logic. The result was a shutdown of the steam turbine and the water treatment system used to produce process water, interrupting the cogeneration process entirely.

To stall recovery efforts, the attackers went further. They sabotaged several Moxa network devices, destroyed logs, damaged the WAGO controller, reset the Teltonika router, and restored the FortiGate device to factory settings. It was a deliberate, multi-layered effort to make the investigation as difficult as possible.

Fortunately, the outage didn’t last long, and no customers lost power. But the incident exposed a glaring weakness in how private APNs are often configured.

Why Private APNs Are a Soft Target

Private APNs are supposed to be secure — a closed cellular network for industrial devices. But as this attack shows, they’re often treated as trusted environments, with little to no segmentation from OT systems.

In this case, the APN was a direct bridge from a compromised wind farm to the CHP plant’s most critical controllers. The default credentials on the WAGO PLC were the final, glaring gap.

CERT.PL’s report stresses that organizations using private APN solutions need to rethink their assumptions. The APN should be treated as an untrusted network, not a safe haven.

CERT.PL’s Recommendations for Securing Private APNs

The Polish CERT has issued a detailed list of actions for organizations relying on private APNs. Here’s what they recommend:

  • Conduct an audit of private APN configuration and enable client isolation between end devices connected to the APN
  • Treat the private APN as an untrusted network and segment it from the OT environment
  • Strictly limit communications between the OT network and the device acting as the gateway to the private APN
  • Monitor traffic between the OT network and the private APN, flagging any abnormal activity
  • Implement centralized logging and monitoring of events generated by devices serving as gateways to the private APN
  • Minimize the number of open ports accessible via interfaces reachable from the private APN
  • Change default credentials for all services available on devices connected to the private APN, especially administrative services
  • Include private APNs and the devices providing access to them within the scope of penetration tests, red team exercises, and security architecture reviews

That last point is crucial. Many organizations simply never test their APN security. A penetration test might reveal the kind of default credential issue that proved fatal here.

The Bigger Picture: Sandworm’s Campaign Against Polish Energy

This attack didn’t happen in a vacuum. It was part of a coordinated campaign by Sandworm, the Russian GRU-linked group known for destructive attacks on Ukraine’s power grid and, more recently, cyberattacks on critical national infrastructure across Europe.

The December 2025 attacks targeted renewable energy facilities and CHP plants across Poland. The wiper malware attacks documented in the January 2026 report were just one piece of the puzzle. This APN-based intrusion shows the group’s willingness to innovate and exploit overlooked attack paths.

For energy companies, the lesson is clear: the perimeter isn’t just the firewall anymore. It’s also the cellular router, the APN, and the PLC with a default password. If you’re responsible for OT security, take a hard look at your private APN configuration today — before someone else does it for you.

Continue Reading

Infosecurity

NSA revives ‘Tailored Access Operations’ name for elite hacking unit

Published

on

Tailored Access Operations

NSA Brings Back a Legendary Name

The National Security Agency has quietly resurrected a name from its past. Last week, the spy agency rebranded its elite hacking division, swapping the bureaucratic title of Office of Computer Network Operations (CNO) for something with more weight: Tailored Access Operations (TAO).

For those who follow the arc of offensive cyber operations, the name carries serious history. It dates back to the early 1990s, when a small group of operators first started crafting custom tools to break into foreign networks.

Now, under new leadership, the NSA is betting that bringing back the old brand will sharpen its edge in a world where digital threats from China, Russia, and others are growing more sophisticated by the day.

Why the Change Now?

The move is part of a broader reorganization spearheaded by NSA Deputy Director Tim Kosiba, who himself spent time inside TAO. The goal is to make the largest electronic spy agency on the planet more agile in the face of evolving threats.

It also undoes much of what was known as NSA21, an internal reshuffle launched in 2016 that folded offensive operations and intelligence collection into broader directorates. TAO, once a standalone office, was absorbed into that structure.

“NSA21 was not looked at as a useful thing,” said a former agency employee who spoke on condition of anonymity. “We were on a path to move developers and operators closer. They split them apart instead. I think they just look at that back as the heyday of the operations, so there’s a nostalgia there.”

The revamped structure was briefed to Defense Secretary Pete Hegseth during his visit to Fort Meade last week. Hegseth, who oversees both the NSA and U.S. Cyber Command, even shared a photo of a signed TAO hat on his official X account.

What TAO Actually Does

Tailored Access Operations is, as the name suggests, all about customized access. The unit designs and deploys tools that are specifically engineered to penetrate the computer networks of foreign targets for espionage purposes. That means fashioning implants and other methods coded entirely in software the agency creates.

It’s the kind of work that produced Stuxnet, the cyber weapon used to sabotage Iran’s nuclear program. That operation, revealed years later, remains one of the most audacious cyberattacks in history.

The unit was thrust into public view about a decade ago when a mysterious group calling itself the Shadow Brokers surfaced online, advertising the sale of stolen hacking techniques. U.S. officials believed Russia and North Korea capitalized on those pilfered tools to launch devastating global attacks.

Most famously, in 2017, the WannaCry ransomware used an exploit called EternalBlue to sweep across 150 countries, infecting 200,000 organizations. The fallout was massive, shutting down hospitals, factories, and government offices worldwide.

The Human Factor: A Cautionary Tale

Around the same time, federal prosecutors indicted Harold Martin, a former NSA contractor, for hoarding massive amounts of classified information at his Maryland home. Martin worked at the agency from 2012 to 2015 as a Booz Allen Hamilton employee, including a stint in TAO.

Investigators never found proof that Martin shared the stolen secrets with anyone else. In 2019, he was sentenced to nine years in prison. The case served as a stark reminder of the risks that come with handling the nation’s most sensitive cyber tools.

What the Revival Means for the Future

Former NSA personnel see the move as more than just a name change. Bringing developers and operators back together under one roof — literally, as TAO is expected to open its own building on the Fort Meade campus next month — could speed up operations and boost creativity when it comes to breaking into hard-to-access networks.

The rise of artificial intelligence is another factor. New tools and techniques are emerging rapidly, and the NSA wants to stay ahead of adversaries who are also adopting AI.

“TAO restores a powerful identity that has resonated deeply,” an NSA spokesperson said. “TAO has a strong history of mission outcomes and we are honoring it and using the weight it carries to propel us into the future.”

For those who watched the agency’s evolution over the past decade, the revival feels like a homecoming. The question now is whether the nostalgia will translate into real operational gains.

If the past is any guide, the name alone won’t be enough. But for a spy agency that thrives on secrecy and precision, having a brand that inspires both fear and respect among adversaries is a start.

Continue Reading

Infosecurity

NIST Wants to Rebuild the NVD for an AI World — Here’s What That Means

Published

on

NVD modernization

A Database Under Pressure

The US National Institute of Standards and Technology (NIST) is asking the cybersecurity community to help it drag the National Vulnerability Database (NVD) into the age of artificial intelligence. On August 12, the agency published a request for information (RFI) in the Federal Register, inviting stakeholders to weigh in on how to modernize the NVD for what it calls “an evolving cybersecurity landscape increasingly shaped by AI and machine-consumable security data.”

The NVD is the backbone of vulnerability management for countless organizations. It automatically ingests Common Vulnerabilities and Exposures (CVE) records within about an hour, then analysts enrich each record with severity scores, affected product versions, and other context. That enriched data flows out through the NVD website and automated tools used by security teams worldwide.

But the system is straining. NIST says traditional methods — periodic scanning, static prioritization, manual remediation — no longer cut it. Vulnerability volumes are exploding, technology cycles are faster, and organizations want near-real-time data and deeper automation. The RFI lays out a vision for a system that is “continuous, contextual, and automated.”

This is not just a routine update. The NVD is a critical piece of national infrastructure, and how it evolves will shape vulnerability management for years to come.

Why AI Changes the Game

The RFI doesn’t treat AI as a passing trend. NIST sees it as both an opportunity and a threat.

On the upside, AI could help automate CVE enrichment, spot patterns in vulnerability data, and even assist in discovering new vulnerabilities. The agency wants to integrate AI tools and automation workflows directly into the NVD’s operations.

On the downside, AI is also enabling attackers. AI-assisted vulnerability discovery and exploitation are real concerns, and NIST acknowledges that the same technology that helps defenders can also help adversaries find and weaponize flaws faster.

The RFI includes 30 questions covering everything from scalability and interoperability to transparency and utility. NIST is looking for “forward-looking perspectives, practical recommendations and innovative models” — not just tweaks, but a fundamental rethinking of how the NVD should work.

What Experts Say About AI in Vulnerability Management

Tyler Reguly, associate director of security R&D at Fortra, sees real promise in using AI for vulnerability discovery. “AI can be beneficial when analyzing source code,” he says. “It can identify all sorts of obscure vulnerabilities that human researchers might overlook.”

But he draws a hard line at remediation. “I would not trust the remediation of vulnerabilities in critical systems to AI just yet,” Reguly warns. “Human-in-the-loop is still so critical.”

His advice: use AI in test environments and labs, but keep humans in charge of production systems. “In production systems… not yet.”

That’s a sentiment worth keeping in mind as NIST builds out its modernization plan. Automation can speed things up, but it shouldn’t replace human judgment where the stakes are highest.

Key Questions in the RFI

The RFI is not a vague call for comments. It’s a structured set of 30 questions designed to extract specific, actionable input. Here’s a snapshot of what NIST wants to know:

  • How should the NVD prioritize vulnerability enrichment to keep pace with the growing CVE backlog?
  • What AI tools and techniques could improve the accuracy and speed of CVE analysis?
  • How can the NVD better support machine-consumable data formats for automated security tools?
  • What transparency and accountability measures should be in place for AI-assisted analysis?
  • How can the NVD balance automation with human oversight to maintain trust?

These aren’t just technical questions. They’re about governance, reliability, and the role of a national database in an era of AI-driven both defense and offense.

What’s at Stake

The NVD is more than a website. It’s the foundation for vulnerability scanners, patch management systems, and security research. If it can’t keep up with the pace of modern threats, the entire ecosystem suffers.

NIST’s move to modernize is overdue, but welcome. The agency is right to seek input early, before making major investments in AI and automation. The question is whether the final design will balance speed with accuracy, and automation with human judgment.

Stakeholders have until October 13 to submit their input. If you work in vulnerability management, this is a rare chance to shape the tools you’ll rely on for the next decade.

For more on how AI is reshaping security, check out our coverage of AI in vulnerability management and the broader shift toward automated threat intelligence. And if you’re still using manual CVE analysis, it might be time to start planning for the NVD’s AI-powered future.

Continue Reading

Trending