June: The Moments Authentication and Access Control Broke Down
Hi there, Basestone subscriber! ๐
Looking closely at this month's incidents, an interesting pattern emerges. Each breach happened differently, but at the bottom of every one was the same question: did we actually know how far this account, this key, or this access right could reach? Today we look at June's security incidents through that lens ๐
๐ Quick summary of today's issue
- ๐ฐ๐ท TVING's internal systems were breached after a developer's access key was stolen, with early reports putting the exposure at roughly 20 million records, investigation still ongoing
- The ICARUS supply chain attack used partner company Klue's neglected dormant credentials as a foothold to steal customer OAuth tokens
- Belgium's State Security Service suffered a breach that went undetected for nearly a year
- Domestic ransomware trends: per ASEC's June statistics, Qilin led with 83 incidents, followed by Dire Wolf with 68 and World Leaks with 52, with Doosan Bobcat among the Korean victims
๐ What happened
๐ฐ๐ท TVING: internal systems breached through a single static access key
On June 1, CJ ENM's streaming service TVING disclosed a data breach. After unusual activity was detected on May 30, investigators found that a developer's access key had been stolen and used to infiltrate internal systems, exposing personal data including names, dates of birth, phone numbers, and email addresses. Early reports put the scale at roughly 20 million records, and it also came out that TVING had reported the incident to the Korea Internet & Security Agency (KISA) after the 24 hour legal deadline had already passed, drawing criticism for a slow response. The exact scope and full details are still under investigation.
What stands out here isn't the number, it's the structure. What was stolen wasn't a username and password, it was a single access key, and the fact that this one key could reach internal systems at all is the real issue. It isn't yet clear how long that key had been valid or how broad its reach was, or whether anyone was monitoring that in real time.
A partner's dormant credentials fueled the ICARUS supply chain attack
In mid June, the ICARUS supply chain attack came to light after attackers compromised the backend systems of Klue, a market intelligence platform. The attackers used dormant credentials that Klue had created for a prototype integration and then left unused, pushed a malicious update, and stole the Salesforce OAuth tokens of Klue's connected customers. For nearly 24 hours afterward, they queried the Salesforce REST API using Python scripts, pulling CRM data, sales communications, pricing information, and competitive intelligence. Once the breach was confirmed, Klue had to disable integrations across eight platforms, not just Salesforce but also HubSpot, SharePoint, and Zoom.
The core issue in this incident was credentials and tokens that were no longer actually in use. It shows that as long as a connection stays alive, so does the access it grants, whether or not anyone remembers it's there.
A breach that went undetected at Belgium's State Security Service for nearly a year
The breach disclosed on June 22 at Belgium's State Security Service is even more striking in its timing. Investigators believe the intrusion lasted from around May 2025 through spring 2026, nearly a full year. Attackers exploited a vulnerability in Ivanti's mobile device management platform (EPMM) to obtain employee names, phone numbers, email addresses, external contacts, device identifiers, and location data. Classified information itself was reportedly not exposed, and a China linked group known as UNC5221 has been named as a suspected actor, though official attribution has not been confirmed.
The fact that a breach lasting nearly a year went unnoticed also means that access to that system wasn't being continuously re-verified during normal operations.
Ransomware keeps repeating, and domestic supply chain attacks remain active
According to ASEC's (AhnLab Security Emergency response Center) June ransomware trend report, the most active groups were Qilin (83 incidents), Dire Wolf (68 incidents), and World Leaks (52 incidents) in that order. Domestically, construction equipment maker Doosan Bobcat appeared as a victim of Booba Team, believed to be a rebranding of the Frag ransomware group, and several other Korean companies also appeared on the victim list. The exact initial access vector isn't disclosed for every case, but the industry consistently points to the same recurring paths: credentials stolen through phishing, exposed remote access ports, and vulnerable VPN entry points. In other words, walking in disguised as someone else's account.
๐งญ Why this matters now
Static credentials eventually leak, without exception
Both the TVING breach and the ICARUS supply chain attack started not with a password but with a key or a token. A static credential, once issued, stays valid until it expires, and it tends to linger somewhere: in source code, in a config file, in a forgotten integration setting. Just as a person's identity gets verified at every login, system to system connections need the same standard of authentication through short lived credentials.
Access, once granted, doesn't disappear on its own
Klue's dormant credentials and the long undetected breach at Belgium's State Security Service share the same root cause: access granted at some point in the past kept quietly working without anyone noticing. What matters far more than the moment access is granted is whether it gets periodically re-verified afterward, whether it's still valid, whether it's still needed. Trusting something once doesn't mean it deserves to be trusted forever.
The real problem is how much becomes reachable once a single boundary is crossed
In the TVING breach, only one key was stolen, but the fact that this single key could reach internal systems at all reveals a structural risk. When access isn't finely scoped to exactly what a given identity should reach, a single leaked credential can turn into a full scale breach. June's incidents showed once again that access control isn't just about whether someone gets in, it's about designing how far they can go once they're inside.
โ Four things to check after this month's incidents
- Have you ever run a full scan across all source code, config files, and CI/CD pipelines for static API keys or access keys with no expiration date
- Do you have a quarterly process for cleaning up partner integrations, dormant accounts, and old OAuth permissions that have seen no traffic for 3+ months
- Picking one core system, have you ever simulated how far an attacker could actually reach (how many projects, what kind of data) if a key or account tied to that system were compromised
- Do you re-verify permissions and trust level as a session runs longer after the initial login, or is trust simply carried through unchecked once someone authenticates until the session ends
โ ๏ธ What teams often miss
The assumption that authenticating once is enough
Many systems only verify identity at login or at the moment an integration is first set up, and after that, trust continues unchecked as long as the session or token remains alive. But as the Belgian State Security Service incident shows, this kind of structure can let a breach go unnoticed for months, even close to a year.
Managing human accounts carefully while forgetting about system accounts
Organizations often pay close attention to password policy and login security, while API keys and OAuth tokens used for service to service integrations get set up once and then forgotten. Both the TVING and ICARUS incidents started not through a person, but through a system accessing another system, which is worth keeping in mind.
"Authentication shouldn't just be a check at the moment a door opens. It should be a question that keeps being asked for as long as that door stays open." โ Basestone Security Research Team
๐ How to start small
A good first step is pulling together a list of every API key, access key, and OAuth token in your organization that never expires. The length of that list alone will tell you a lot about where your access control stands today.
If you'd like a clearer standard for verifying who's actually on the other end of a connection, we'd also recommend reading An Operational Flow for Handling Exception Requests in a Zero Trust Environment.
