On 21 October 2026, Kaspersky's Global Research and Analysis Team disclosed a campaign it calls Operation FlashHole, attributed to the Lazarus group. At least three organisations in South Korea were affected, in construction, software, and wired communication equipment manufacturing. The campaign dates back to at least July 2025.
That part alone would be a routine espionage report. The detail that stopped me is the cryptography. An updated Lazarus tool called LPEClient uses ML-KEM-1024, the post-quantum key encapsulation mechanism standardised by NIST, to protect the delivery of further malware. It receives four ML-KEM-1024 public keys, generates four shared secrets, and uses the resulting key with the Threefish cipher to decrypt the next payload.
I build a small experimental messenger with post-quantum key exchange, so I follow this migration closely. I expected the first large-scale post-quantum stories to be about banks, browsers, and government systems finishing their upgrades. I did not expect one of the clearest early examples to be an attack tool using the same standard to hide its own next stage. That inversion is worth sitting with, because it tells us something plain about how this transition will actually go.
What Kaspersky actually found
The reported chain starts with spear-phishing emails linking to fabricated portfolio and CV websites tailored to the targets. Visiting a malicious site likely led to an infection involving CrossWeb EX, financial security software widely used in South Korea. Kaspersky could not establish the exact trigger or how the software was abused, and that gap matters. Honest reporting leaves gaps visible instead of filling them with a confident story.
Two previously undocumented tools, TouchHub and ClientHub, then install additional malware, run commands, and communicate with the attackers. LPEClient sits in that chain as the delivery protection: the post-quantum key exchange guards the payload, not the initial lure.
Kaspersky researcher Sojun Ryu said the group's use of post-quantum cryptography traces back to at least September 2024, more than a year before this disclosure. FlashHole is not a one-off experiment. It is a habit forming over time.
The second campaign matters more than the first
FlashHole follows another disclosure from August 2026. Check Point Research reported that malware in an Operation Dream Job campaign, also tied to Lazarus, used Kyber/ML-KEM key exchange before downloading an exploit for a Windows zero-day, CVE-2026-68820. Microsoft patched that flaw on 11 August.
Two campaigns, two different target sets, the same pattern: use a modern, standard key exchange to protect the step where the attacker fetches something valuable. In Dream Job the targets were defence and aerospace companies in Europe and India. In FlashHole they were South Korean firms. The point is not the choice of victim. The point is that the cryptographic upgrade is now part of the attacker's normal toolkit.
That should end a lazy assumption I have heard in builder circles: that post-quantum cryptography is a defensive project, something good teams adopt and bad actors ignore because they prefer old, broken tools. Attackers adopt whatever works. They do not wait for a migration roadmap, a procurement cycle, or a compliance deadline. They pick a standard, implement it, and move on.
Post-quantum is not a side
This is the part people get wrong when they react to news like this. ML-KEM is not a signal of guilt, and it is not a reason to panic about every post-quantum handshake you see. Post-quantum key exchange is already routine on legitimate networks. Cloudflare has reported that a large and growing share of human-generated web traffic on its network uses post-quantum encryption. A handshake alone tells a defender almost nothing about intent.
What changes is where detection has to happen. If the payload is protected by a strong, standard key exchange, you cannot rely on reading it in transit to know it is bad. You have to look at the behaviour around it: the unusual process launch, code executing in memory, a legitimate Windows binary being abused, a sequence of steps that does not fit the machine's normal work. Kaspersky's report documents exactly that kind of surrounding activity, including CrossWeb EX launching a legitimate binary and malicious code running in memory. Stronger encryption and detectable intrusion activity can exist at the same time.
For defenders, that is actually useful news. It means the job does not become impossible when cryptography gets stronger. It becomes more behavioural. The question shifts from "can we read this?" to "does this sequence make sense on this machine, at this time, for this user?"
What this changes for builders
I am not writing this as someone running a large security team. My messenger is a small, experimental project, not an audited product, and I will not pretend otherwise. But building with ML-KEM has taught me a few practical lessons that this news sharpens.
First, start with an inventory, not a slogan. You cannot migrate what you have not listed. Which libraries negotiate keys, which services terminate TLS, which stored messages or files depend on a classical key exchange that a future quantum computer could break retroactively? A US executive order from June 2026 directs federal high-value assets and high-impact systems, excluding national security systems, to adopt post-quantum key establishment by 31 December 2030 and digital signatures by 31 December 2031. Those dates are not the point for a small builder. The point is that the inventory comes first, and it is the step most teams skip.
Second, prefer hybrid key exchange while the standards settle. In my own project I combine ML-KEM-768 with a classical ECDH exchange, so the connection does not rest on one new algorithm alone. Lazarus used pure ML-KEM-1024 in this tool. That is their choice for their purpose. For a messenger or a service that has to stay trustworthy if one algorithm turns out weaker than expected, hybrid is the more cautious design, and it matches where TLS itself has gone with hybrid ML-KEM combinations.
Third, treat signatures as a separate, slower track. Key establishment has moved faster than signatures in real deployments. That is normal: replacing a key exchange in a live protocol is painful enough, and replacing every signature, certificate, and verification path is a larger job. Plan them as two migrations with different timelines, not one big switch you flip on a Friday.
Fourth, do not let a post-quantum label do your security thinking for you. A protocol can use ML-KEM and still leak metadata, still trust a server it should not trust, still store keys badly, still fail open when verification fails. I have seen that temptation in my own work: add the new algorithm, feel modern, and stop asking harder questions about key storage, rekeying, and what happens when a device is lost. The label is not the system.
Fifth, keep detection and migration on the same plan. Migration protects future traffic. Detection catches the intrusion that is already happening. FlashHole shows why you need both at once. A team that only migrates will still miss the spear-phishing lure and the abused legitimate software. A team that only hunts intrusions will still leave years of recorded traffic exposed to harvest-now, decrypt-later attacks.
What this does not mean
It does not mean post-quantum cryptography is compromised, or that ML-KEM is broken, or that using it marks you as suspicious. Nothing in these disclosures says that. It means a strong, public standard is now available to everyone, including people you would rather it was not available to. That was always true of AES, of TLS, and of every good cryptographic tool before it. The strength of the math does not pick a side.
It also does not mean defenders are behind in some absolute sense. Many large networks already negotiate hybrid post-quantum key exchange by default. The gap is uneven: some teams have moved, some have not started, and attackers exploit the unevenness, not just the technology. The organisations in FlashHole were not necessarily careless. They were targeted with tailored lures and abused trusted software. That is a reminder that migration alone, without phishing resistance and endpoint visibility, is an incomplete answer.
The honest takeaway
When I started adding post-quantum key exchange to my messenger, I thought of it as future-proofing: something to do before it became urgent, so old messages would not be sitting around waiting for a future machine. FlashHole gives that idea a sharper edge. The future part is already here, and it is not arriving only through standards bodies and vendor roadmaps. It is arriving through attackers who read the same standards, implement the same algorithms, and use them to protect their own work.
That does not make the work pointless. It makes it normal. Post-quantum cryptography is becoming ordinary infrastructure, used by browsers, by cloud providers, by small builders like me, and by Lazarus. The builders who treat it as ordinary, unglamorous infrastructure, inventory first, hybrid where it makes sense, signatures on their own track, detection alongside migration, will be in much better shape than the ones waiting for a dramatic moment to act.
The dramatic moment already happened. It just did not look like a breakthrough. It looked like a malware report, published on a Tuesday in October, in which the attackers had simply kept up.
Sources: Kaspersky GReAT disclosure of Operation FlashHole, 21 October 2026, as reported by eWeek (https://www.eweek.com/news/lazarus-post-quantum-malware-apac-south-korea/); Check Point Research on Operation Dream Job, August 2026.
If anything here is wrong or unclear, I would rather hear it and fix it than leave it standing. That is how a small project earns trust it has not yet been audited to claim.
Top comments (0)