ProBackend
Threats & Attacks
4 hours ago5 min read

Inside Lazarus’s FlashHole Malware-Delivery Chain

Operation FlashHole pairs familiar Lazarus malware with ML-KEM-1024 to protect payload delivery. Here’s what the reported chain shows—and what defenders can reasonably do about it.

What Operation FlashHole changes—and what it doesn’t

Operation FlashHole is notable for a specific technical choice, not because it replaces the familiar mechanics of an intrusion. According to BleepingComputer’s report on Kaspersky’s analysis, Lazarus used the standardized post-quantum mechanism ML-KEM-1024 to help protect malware delivery. The campaign still began with phishing and a multi-step chain involving established malware and legitimate Windows components. The encryption is the unusual part; the initial access and loader activity are recognizable security problems.

The report says the operation targeted South Korean organizations and began in July 2025. Kaspersky identified at least three affected companies in software, construction, and wired communications equipment manufacturing, while suspecting that more organizations may have been affected. That distinction matters: three identified victims is not a complete count, and the reporting does not establish how many additional organizations were compromised.

BleepingComputer reports that Kaspersky named the activity FlashHole and attributed it to Lazarus. Researchers placed it within broader Cascade Hole activity and linked it to the earlier Operation SyncHole with medium-to-high confidence. Those are analyst assessments, not independently proven facts. The source does not establish that every tool or infection chain described is unique to this operation.

How the malware-delivery chain worked

The reported chain began with phishing pages that directed targets to specially crafted GitHub pages. Those pages loaded JavaScript from external domains and triggered an in-memory execution sequence involving INISAFE CrossWeb EX, described in the report as a security tool popular in South Korea.

A process associated with that tool executed the legitimate Windows binary fsquirt.exe. Attackers used it to run shellcode, which installed TechHub. TechHub then acted as a downloader, retrieving additional malware from private GitHub repositories. A legitimate binary in this context is not proof that the binary itself is malicious; the concern is how the attackers used it within the execution chain.

Another tool observed by Kaspersky was ClientHub, a loader that could communicate through Dropbox or exchange data directly with LPEClient. In the account reported by BleepingComputer, LPEClient profiled victims, received encrypted payloads through ClientHub, and evaded security monitoring. The report does not give a full account of every initial phishing lure or identify every compromised system, so defenders should avoid treating this one chain as a complete inventory of Lazarus activity.

The final payload described was Cubridge, a modular backdoor. Its reported capabilities included file management, command execution, reconnaissance, screenshot capture, and loading further payloads. Kaspersky also observed tools targeting Chromium-based browsers to collect account credentials, cookies, and browsing history. Those functions make the chain relevant beyond malware containment: a compromised endpoint may expose both system access and browser-held information.

Where ML-KEM-1024 fits

ML-KEM is a post-quantum key-encapsulation mechanism. In this operation, according to the technical details relayed by BleepingComputer, LPEClient contacted command-and-control infrastructure and received data containing four 1,568-byte blocks, each with an ML-KEM-1024 public key.

LPEClient generated four pairs of shared keys and ciphertexts from those blocks. Kaspersky’s description says the ciphertexts were encrypted using the GOST algorithm and sent to the command-and-control server via ClientHub. The resulting shared secrets provided key material for Threefish, which was used to decrypt a response containing parameters and an executable payload. LPEClient then reflectively loaded the Cubridge payload into memory.

That is a layered delivery mechanism, not evidence that the malware is powered by AI or that a quantum computer was involved. The source describes use of a post-quantum cryptographic standard to protect subsequent payloads in current operations. It does not report a successful quantum attack, nor does it say the attackers used AI. The practical point is narrower: defenders may encounter modern cryptographic components inside a conventional phishing-to-loader infection chain.

Kaspersky assessed that the technique, combined with in-memory execution, was intended to reduce detection. BleepingComputer quotes the researchers as saying the post-quantum mechanism showed an intent to hide subsequent payloads. That is an interpretation of the technique and its purpose; the report does not quantify how much it affected detection or establish that encryption alone defeated any particular security product.

Defensive priorities for this chain

Start with the entry route. The reported phishing pages, externally loaded JavaScript, and specially crafted GitHub pages make web and email telemetry useful places to investigate. Review suspicious redirects and scripts, and examine whether developer or file-sharing services are being used to retrieve unexpected executables. The report specifically mentions private GitHub repositories and Dropbox communications, but it does not say those services are inherently malicious. Context, account activity, and the process making the request matter.

Look at process relationships, not just filenames. The reported sequence includes INISAFE CrossWeb EX, fsquirt.exe, shellcode, and TechHub. A legitimate Windows executable can be abused as part of a malicious chain; allowlisting its name alone will not explain what launched it, what code it executed, or what it contacted. Correlate process creation, script execution, network requests, and memory-related alerts where those records are available.

Investigate for both on-disk traces and activity in memory. Kaspersky’s findings, as summarized in the report, say much of Lazarus’s code ran in memory, while persistence mechanisms left some files on victim systems. That makes a disk-only search inadequate. Preserve endpoint telemetry, inspect persistence locations, and collect relevant memory or forensic data when an incident warrants it. The article does not specify particular indicators of compromise, so these steps should be guided by current intelligence and local evidence rather than invented signatures.

Finally, treat browser data and credentials as potential exposure. The reported tools targeted Chromium-based browsers for credentials, cookies, and browsing history. If an endpoint is suspected to be compromised, responders should assess sessions and credentials associated with it, not merely remove the backdoor and declare the incident finished. Scope and reset actions should reflect what evidence shows and the organization’s incident procedures.

A modern cryptographic layer, a familiar intrusion

FlashHole is a useful reminder that a new cryptographic mechanism can appear inside an otherwise recognizable malware-delivery process. ML-KEM-1024 deserves attention because it changes how the payload exchange is protected; it does not make phishing, script execution, abused binaries, loaders, or backdoors disappear from the investigation.

For defenders, the durable response is to follow the chain across people, processes, and network activity, and to keep uncertainty explicit. Kaspersky’s reporting identifies at least three South Korean organizations and describes links to other activity with a stated confidence level. It does not establish a total victim count or prove every suspected campaign connection. Those limits are part of the story, not footnotes to discard.

Source: BleepingComputer’s report on Lazarus’s use of post-quantum cryptography for malware delivery.