170 Million People's ID Documents Leaked; METR Discloses Two Cyber Incidents; Sality Botnet Disrupted

This story highlights the adage that if you don't gather and store data, you don't need to secure it. Organisations understandably collect identity documents to establish trust, but retaining millions of copies of passports and driving licences creates an extremely attractive target. Data minimisation should not simply ask, "Can we collect this information?" but also, "Once we have verified the person's identity, do we still need to keep it?" and if we do need to keep it, "How do we secure it properly?" As more and more countries are looking to introduce minimum age limits to access social media and other platforms, we as a society must understand the risks of gathering IDs to verify people's ages, and must demand appropriate security controls in place to secure that data.

I did a double take when my wife read me an article about this while we were driving home from our ISSA chapter meeting. Brian Krebs has a great writeup on this — it goes well with that cup of coffee you're holding. We've all spent a lot of time working on technical mechanisms for validating people consistently, breathing a sigh of relief at not having the data locally, and while we did assess the risks of the solution providers, did we think about what those repositories contained and what happens when they’re compromised? Make sure your contract with this type of service includes logging, segregation, and retention requirements as well as incident notification, evidence access when needed, and independent (regular) security validation/assurance. One more thing: Make sure that you're meeting, or exceeding, the provider's security best practices as well.

At some point, the data you are accumulating turns from an asset into a liability. I want to know if there was a business case for keeping the data online and reachable after the ID was verified. Data repositories at this scale are very difficult to secure. From a consumer and victim perspective: assume compromise. Florida recently started issuing new, partially random driver's license numbers. The reason for this change was that the old format made it possible to guess license numbers. But it may also help limit the lifetime of the data if stolen.

Driver’s licenses, health insurance cards, etc., stop being a "what you have" whenever they are scanned in. It is essentially impossible in the modern world to avoid those numbers being stored online and eventually disclosed. The ultimate line of defense for personal identity is always strong authentication, to be able to force liability to the entity that did not protect your data. This will be a very expensive incident for whoever is at fault — many times IDscan[.]net’s likely annual revenue, for example.

I gotta say — Brian Krebs is a national treasure. His scoops are fascinating and help drive us all toward better security. Also, regardless of where the FBI investigation ultimately lands, this story exposes an uncomfortable truth about identity verification: It can become identity accumulation. A driver’s license scan collected for a one-time transaction can persist as a high-value credential long after the transaction is over. Over the years, during penetration tests, my team has gained access to repositories containing scanned driver’s licenses and passports several times. Providers that perform identity proofing are becoming de facto identity vaults, and their security, retention, and deletion practices need to reflect that. We should design verification systems to prove what was needed without keeping a permanent copy of everything that was shown.

Krebs's analysis sets the benchmark for industry reporting — outstanding work. This incident underscores the urgent need for targeted regulatory oversight for verification platforms like IDscan[.]net beyond broad consumer protection and state privacy laws. Moving forward, organizations must exercise rigorous due diligence when handing over sensitive identity and financial data to third-party vendors.

IDscan[.]net offers a service that scans credentials to detect counterfeits. It advertises that its verification models are "trained on hundreds of millions" of documents. Where does one believe that they get the hundreds of millions?

There is a lot to unpack in this article. A “vibe-coded” application contained an API key, authentication failed open, the API key had no spending limit, and $600,000 worth of usage went unnoticed for three weeks. AI can make it remarkably easy to create and deploy software, but easy does not mean secure. If staff are going to develop applications using AI, organisations need policies around how those applications are deployed, how secrets are managed, and how unusual usage is detected. Vibe coding without security controls risks becoming vibe breaching.

A developer created a public application with a really nice API key, end-running security, to solve a problem. While METR has revised their policies and monitoring, did they also solve the core problem, or at least implement a well-known process for raising and resolving this sort of problem? If not, they will again be the problem the developer solves. This is not a METR-specific problem — sometimes we call it Shadow IT, and with vibe coding, creative solutions like this are easier than they used to be. The good news is that the solution isn't new: It's about squishy, soft skills — communication, understanding and relationships — needed to work together to solve problems. It's ok, if I can do that (trust me, I had a pretty nasty reputation at one point), so can you.

Private keys should be created and stored only in cryptographic modules where they can be used but never copied or seen.

Nice multi-national coordinated take down, leveraging the service to facilitate its demise — even so, it was hard work. Sality was used to deliver malicious payloads to about 33,000 systems worldwide. The long life of this botnet is a function of its architecture; as it was P2P, there were no single points of failure, and it attached itself to executable files spread over shared files, network drives, and removable media, including the mechanism to regenerate the botnet, which resulted in it perpetuating without any external interaction. At this point, get the IoCs to your hunters to make sure that you don't have any remnants in your environment.

This is technically beautiful. Sality survived for more than two decades in part because its peer-to-peer design removed the central command-and-control server defenders could seize. But the bots also trusted any peer that spoke the protocol correctly, and that became the Achilles' heel. CrowdStrike and its partners learned the protocol well enough to make the botnet trust defenders instead, progressively isolating infected machines from the operator. Sometimes the architecture that creates resilience also creates the path to disruption. My hat's off to those who executed this operation so well!

You have to give credit where it's due — Sality had an unbelievably long run. What's wild is that it took nine full years for defenders, many volunteering their personal time, to finally corner it. Huge kudos to the combined private-sector and law enforcement team that pulled off the takedown. That said, it definitely makes you pause and wonder what other persistent threats are currently flying under the radar.

Good news in the fight against cybercriminals, and well done to all involved. Twenty years is an extraordinary lifespan for malicious infrastructure on the Internet. This operation also demonstrates the value of cooperation between law enforcement and the private sector. Cybercrime is international by design, so disrupting long-running criminal infrastructure increasingly requires technical expertise, legal authority, and cooperation across multiple jurisdictions. No single organisation, company, or country can tackle that problem effectively on its own.

With all the focus on using compromised packages to distribute malicious code, the last thing you want is an unauthenticated flaw in your package manager that can be used to get admin credentials. Mind you, this only applies to self-hosted instances of JFrog Artifactory. There is a workaround, where you add an additional join key to ensure only your join keys are accepted, but this doesn't do anything for the other flaws they are addressing; your best bet is to move to 7.161.20, make sure that you're limiting network access to your Artifactory Access/router instances, and make sure that you've set up auditing and monitoring.

Authentication Bypass has been part of Authentication Failures — #7 in the OWASP Top Ten Software Vulnerabilities — for a long time. JFrog sells advanced security tools, including application security testing, and hopefully uses their own products on their own products. How did this get through?

Oh goodness. Artifactory has been in the news quite a bit lately, and not at all in a good way. And Artifactory is not just another server; it is part of the trust machinery for your software supply chain. If an unauthenticated attacker can mint administrator tokens, the danger is not limited to the repository itself. An attacker with administrative control may be able to alter artifacts, credentials, or configuration that downstream systems trust. Self-hosted customers should patch immediately, then look for evidence of unexpected token creation, account changes, and repository activity. Treat your artifact repository like the crown jewel that it is.

SonicWall SMA1000s (models 6210, 7210 and 8200v) are under attack (again). Your mission, should you decide to accept it, is to apply the hotfix immediately, as there is no workaround, and then contact SonicWall for help identifying the IoCs. If IoCs are detected, you're going to need to re-image, change all user and administrator passwords, and reset TOTP tokens. An alternative may be to move to another solution, but that is not going to happen quickly enough to remove the need to apply the update for now.

For obvious reasons, firewalls are favored targets.

CryptoPro is used in ATMs as well as automotive, banking, government, manufacturing, research, finance and healthcare systems. CryptWare released a patch to all its customers, and Diebold Nixdorf quietly released updates to their ATMs. Financial institutions need to insist on digitally signed firmware updates when servicing ATMs. While you cannot validate the application of those updates to the ATM you're about to use — and I wouldn't expect them to provide information on the security and patch level in use, ever — you can be selective in which ATMs you use, and watch your financial statements for unexpected/bogus activity. Avoid using the magnetic stripe; use the EMV chip and PIN.

Security through obscurity has never been a particularly good security strategy, and AI is likely to make it even less effective. Attackers increasingly have tools that can help them understand unfamiliar systems and identify weaknesses more quickly. Organisations operating specialised or embedded technology should therefore not assume that complexity, obscurity, or a small installed base will protect it. If something is valuable enough to attack, somebody will eventually work out how it works.

Specialized does not mean isolated. An ATM may look like a purpose-built appliance, but underneath the hood, it can depend on Windows, BitLocker, third-party encryption components, and all kinds of software also used in automotive, healthcare, government, and enterprise environments. A buried dependency can quietly connect industries that do not think of themselves as sharing a software supply chain. Software transparency matters because you cannot patch a component you do not know you inherited.

When it comes to software, there is only one supply chain. There are no distinct "secure supply chains" for specific applications, and if you believe you have one, you are wrong. Tools, libraries, and compilers are shared globally, even across operating systems. Some organizations may be more selective about which components they include, but in the end, they are all linked back to a global, not very clean, pool of open-source and commercial code.

Virtually every sector depends on open-source libraries and compilers maintained by part-time volunteers. Companies face a clear strategic choice: either systematically reduce their open-source attack surface or actively support the ecosystem by contributing engineering talent and financial resources to the projects they depend on.

Even products without software (yes, there a few) have complex supply chains, and there are often safety alerts or recalls for those products. All supply chain programs have to address how "updates" are dealt with in the name of resiliency.

ATMs were an early and successful computer application. In the beginning they were located only on bank premises, programmed and managed by the banks, and they used private networks. They were among the earliest non-defense users of cryptography. Today, they are everywhere. They use commercial and open-source software; hardly any are programmed by banks. Even those on bank premises are managed by contractors. Anyone can buy one and operate it for one's own benefit. While they still use encryption, they use the public networks. While most cards implement contactless chips, for reasons of backwards compatibility they still have the primary account number (PAN) on the magnetic stripe. The ATM in which we enter both the card and our PIN is no longer a trusted device. Use ATMs with caution. Prefer those on bank premises. Prefer ones that you have used in the past. Prefer contactless to those that require that you insert or swipe the card. Prefer digital wallets (e.g., Apple Pay, Google Pay) that use digital tokens rather than the PAN. I no longer even carry cards.

We all winced when we read about Organization A and hoped we would be Organization B in this scenario, but are we? The report from CISA is only 23 pages, and the summary hits the key issues on the head. These are not five-minute fixes; you're going to have to verify that your detection tools are tuned, that your defenders are empowered, that your cloud services are as protected and monitored as your in-house systems are, and that all is effectively feeding to your detection systems. Then the biggies: implement conditional access and remove excessive permissions (for human and non-human identities), accompanied by a regular review process. You've probably got team members who have "always" wanted to do this — time to let them come back with a proposal you can approve.

This may be my favorite CISA red-team report in a while. It's a great read… pretty spectacular and quite informative. CISA eventually demonstrated paths to full domain compromise in both organizations, but Organization B detected and isolated the initial footholds in 2, 10, and 20 minutes, forcing the red team to switch to an artificial assume-breach foothold to continue the assessment. That's a crucial lesson: Prevention can fail without the overall defense failing. Fast and accurate detection and response buy you another chance.

At one level, a great "Do Be/Don't Be" comparison of two security teams' responses to an intrusion — several key lessons learned. But, at a basic level, both organizations were compromised because embedded passwords or phishable reusable passwords were still in use and were exploited.

Both organisations were compromised. The difference was that one detected and responded to the attack while the other did not. As I often say: Today, you will not be judged for being the victim of a cyber breach, but you will be judged on how you respond to it. Your ability to detect, contain, and recover from an attack matters just as much as your ability to prevent one.

While there is no update yet for the S/MIME flaw, there are updates for the other Cisco flaws that should keep you busy until those other updates are released. They are not _yet_ being exploited in the wild, so we have some breathing room. Maybe pay attention to CVE-2026-20281, which can cause a DoS when a remote crafted set of HTTP packets is sent to your phone systems. Have you assessed the value of a VoIP firewall lately?

Most enterprises use some Cisco products. These products are part of enterprise infrastructure. Most enterprises are part of our shared cyber and economic infrastructure. Cisco products continue to deserve, not to say require, rigorous management.

These cyber breaches are a sharp reminder for organizations to audit their data retention policies. While data is often treated as the new gold, storing unnecessary information creates severe liability during a network intrusion. To limit financial penalties, regulatory fines, and class-action lawsuits, retain only what is strictly necessary for operations, and purge high-risk identifiers like driver's license numbers if they aren't essential.

Oh my, this is not a good month for healthcare. These companies don't have a lot in common, but they provide needed services in healthcare: Aesto Health provides archiving and medical records management, Nutex Health operates healthcare facilities, and Novocure is a technology company known for inventing and commercializing Tumor Treating Fields, a non-invasive electromagnetic field therapy for cancer tumors. Each was attacked by a different gang. While nobody has claimed the Aesto breach, the Gentlemen and ShinyHunters gangs have claimed the Nutex and Novocure breaches respectively. You know me, I want to find a way to help everyone in the healthcare sector, but there aren't enough of us to go around, and whatever gets done will take time, so while they look to resources like the Health-ISAC, we need to take steps to protect ourselves from what feels like a recurring string of breaches — many, but not all of which, are near misses on our data.

Healthcare is a favorite target, not only because it is soft, but because it holds the most sensitive identifying data. Yes, it also holds symptom and treatment data, but that does not seem to be the target. My healthcare portal collects for charges and co-pays; it does support Apple Pay (my choice), but not PayPal or Google Pay. Android users must enter credit card, debit card, or bank account numbers.