On August 3, 2026, the ransomware group DragonForce claimed it had breached TUI China (tui.cn), a joint venture that's been operating in China's travel and tourism market since 2003. DragonForce says it has passports, visas, internal documentation, and legal and financial records, and it's threatening to leak that data if its demands aren't met. If you work in travel, hospitality, or any industry that stockpiles government-issued identity documents, this DragonForce ransomware attack isn't just another breach headline — it's a preview of what happens when a RaaS operation with a diversified toolkit decides your customer database is worth more than your uptime.
What happened, and why passports change the math
The basic shape of the incident is a standard double-extortion play: get in, encrypt what you can, exfiltrate what's valuable, and threaten public disclosure as leverage to extract payment even if backups make the encryption itself recoverable. What makes the TUI China data breach worth a closer look isn't the mechanics — it's the data category.
Passport and visa records aren't like a leaked email list or a batch of hashed passwords. A passport number tied to a name, date of birth, and travel history is a durable identity credential that doesn't expire on a normal breach-response timeline. Credit card numbers get canceled in days. Passwords get rotated in an afternoon. Passport data stays valid for years, and visa records often reveal exactly where someone has traveled, for what purpose, and under what sponsorship — information that's directly useful for identity theft, visa fraud, and social engineering against the actual travelers whose documents were on file, not just against TUI China as a corporate entity.
That last point matters for how you scope your own risk. A breach of financial or legal documentation hurts the company. A breach of passport and visa data hurts the company's customers, potentially for years after the headline fades, through fraudulent visa applications, identity-based account takeovers, or targeted phishing that references real travel history to look legitimate. Any organization sitting on a large repository of travel-document PII — airlines, travel agencies, visa processing centers, hotel chains, corporate travel desks — should read this incident as confirmation that this data class draws attacker interest precisely because it's hard for victims to remediate after the fact.
Ransomware-as-a-service: why this isn't a one-off crew
DragonForce operates as a Ransomware-as-a-Service outfit, which is a distinction worth being precise about because it changes how you think about the threat. A RaaS operation doesn't function like a single hacking crew executing its own campaigns end to end. Instead, a core group builds and maintains the ransomware payloads, the negotiation and leak infrastructure, and the operational playbooks, then licenses or partners that toolkit out to affiliates who actually run the intrusions against specific targets. The core operation takes a cut of ransom payments; affiliates bring their own access, whether through phishing, exposed remote services, purchased credentials, or whatever initial-access technique they're skilled at.
This division of labor is the entire reason RaaS has scaled ransomware into a persistent, high-volume threat rather than a sporadic one. Building competent ransomware — encryption that can't be trivially reversed, evasion against modern EDR, reliable persistence, negotiation tooling — takes real engineering effort. RaaS lets that engineering investment get made once and reused across dozens or hundreds of intrusions run by affiliates with wildly varying skill levels. The barrier to running a large-scale ransomware campaign drops from "build sophisticated malware" to "get initial access and rent the rest," which is a much lower bar and one a much larger population of threat actors can clear.
For defenders, the practical implication is that you should not assume the group named in an incident report tells you much about the specific techniques that got used against you. DragonForce affiliates aren't a monolith running one playbook — they're independent operators using a shared toolkit, which is part of why the group maintains more than one ransomware variant in active use.
Two ransomware families, one operation: the DragonForce toolkit
DragonForce runs at least two distinct Windows ransomware variants, and that alone is a notable operational choice. One is built on the leaked LockBit 3.0 builder — when LockBit's builder tooling leaked, it gave a wide range of groups a functional, battle-tested encryption payload to repurpose without having to develop one from scratch, and DragonForce is one of several operations that adopted it. The other is a build that security researchers have analyzed as based on ContiV3, carrying additional capabilities: BYOVD for disabling security tooling, scheduled-task-based persistence to survive reboots and maintain access, and expanded options for customizing how encryption gets applied to a target environment.
Running two unrelated malware lineages in parallel isn't redundancy for its own sake. It gives affiliates flexibility to match the payload to the target environment, the access they've already achieved, or which variant is less likely to trip a given organization's detection signatures at that moment. It also means that threat intelligence built around one variant's indicators — file extensions, ransom note wording, specific encryption routines — won't necessarily catch an intrusion using the other. If your detection strategy is keyed to signatures from a single known DragonForce sample, you have a gap the moment an affiliate reaches for the other build.
DragonForce has also been documented by security researchers using Microsoft Teams as part of how it facilitates or hides attack activity. The specific mechanics haven't been fully detailed in public reporting, but the broader pattern is consistent with what a lot of ransomware and initial-access groups have converged on: collaboration platforms that are core to normal business communication and easy to abuse because traffic through them doesn't look inherently malicious. Treat this as a reason to include Teams (and similar platforms) explicitly in phishing-awareness training and log review, not just email.
BYOVD: the hard-to-patch category hiding in your driver store
The BYOVD capability in DragonForce's ContiV3-based build deserves its own attention because it's a fundamentally different problem from a normal software vulnerability. Bring Your Own Vulnerable Driver works by having the attacker load a driver that is legitimately signed — often by a real hardware or software vendor, sometimes for a product that's old, obscure, or no longer supported — but that contains a flaw letting arbitrary code run with kernel-level privileges. Because the driver carries a valid signature, Windows will load it even though the vendor's own product is unrelated to the attack. Once loaded, the attacker uses the driver's kernel access to disable or blind EDR and antivirus tooling, clearing the path for the ransomware payload to run without interference.
The reason BYOVD is a persistent, hard-to-fully-patch category rather than a one-time fix is that the vulnerability isn't in your environment — it's in a driver you never installed on purpose, and the universe of signed-but-vulnerable drivers is large and keeps growing as researchers find new ones. Patching your own systems doesn't help if the attacker brings the vulnerable driver with them. Revoking every vulnerable certificate isn't practical at the scale Windows code-signing operates at, and vendors are often slow to get old drivers revoked even after a flaw is public.
The defense that actually works is driver allow-listing, specifically Microsoft's vulnerable driver blocklist (enabled by default on current Windows versions with HVCI, but worth explicitly verifying rather than assuming) combined with your own application and driver control policy that blocks anything not explicitly approved for your environment. If your EDR vendor publishes guidance on hardening against BYOVD techniques targeting their specific product, implement it — attackers doing BYOVD are often trying to blind one specific security product, and vendor-specific hardening closes gaps generic Windows policy won't catch.
What to actually do if you hold travel-document PII
If your organization stores passports, visas, or equivalent identity documents at any real volume, the DragonForce/TUI China incident is a reasonable trigger to check a few specific things rather than a general reminder to "take security seriously."
Segment the systems that store this data specifically, separate from general corporate file shares and separate from the systems handling day-to-day booking transactions. Passport and visa scans frequently end up in shared drives or ticketing-system attachments because that's operationally convenient, not because anyone decided that's where sensitive PII should live. Map where these documents actually sit today — you may be surprised — and put access controls and monitoring around that data specifically, not just around "the network."
Build your backup and recovery plan assuming encryption is in play, not just exfiltration. Double-extortion ransomware means you need to survive both halves of the attack: the leak threat, which backups don't solve, and the encryption, which they do. Test restoration of the systems holding travel-document PII specifically, on a realistic timeline, and make sure backups are isolated enough that the same intrusion that encrypts production can't also reach the backup copies.
Write incident-response runbooks that account for the leak-threat half of double extortion, not just the technical recovery half. Decide in advance who makes the call on public disclosure timing, what your notification obligations are for exposed passport and visa data across every jurisdiction where affected customers live, and who talks to media and regulators before you're doing it under pressure with a countdown clock from the extortion group.
None of this prevents a determined RaaS affiliate from getting initial access — that's an unsolved problem for the entire industry. What it does is shrink the blast radius when they do, which is the only realistic goal against an attacker model built specifically to route around single points of failure.