Lazarus FlashHole: ML-KEM-1024 Malware Delivery, IOCs and Hunting

Operation FlashHole is a Lazarus espionage campaign, reported on Securelist on 21 October 2026, that hit at least three South Korean software, construction and telecom equipment makers through fake GitHub Pages sites and a Korean security plug-in. Its loader uses NIST's ML-KEM-1024 to protect payloads. Defenders should hunt the published hashes, paths and domains now.

The post-quantum part is the headline, but it is not the part that should change your week. What matters for defenders is the chain around it: a lure hosted on GitHub Pages, a trusted high-integrity security plug-in process starting a Windows binary it had no reason to start, a signed Microsoft executable loading a fake mscoree.dll, and command and control routed through private GitHub repositories, Dropbox and hijacked Korean websites. Every one of those steps leaves evidence on the host or in network logs, regardless of how the payload itself was encrypted.

This post walks through what the researchers published, the indicators in full, a timeline, what is still unknown, and step by step hunting and cleanup commands for Windows hosts and the logs around them. It also explains, plainly, where Safeguard fits and where it does not: Safeguard is not an endpoint malware detection product, and it would not have caught this intrusion.

What happened

According to the Securelist report by Sojun Ryu, the Lazarus group has run Operation FlashHole since at least July 2025 against South Korean organisations. The researchers assess with medium to high confidence that it is the same actor as Operation SyncHole, a watering hole campaign they documented in April 2025, based on the initial vector, the targets, the shape of the infection chain and the use of a malware family called LPEClient.

The confirmed victims are at least three organisations in South Korea: a software company, a construction company and a wired communication equipment manufacturer. The report says the real number is likely considerably higher. The software sector was also hit in SyncHole.

The way in was personal. Targets received spear-phishing emails pointing to websites built for them and hosted on GitHub Pages, at addresses of the form username.github.io. One site was a résumé for a "senior network appliance developer", with a portrait the researchers believe was AI-generated because it carried no EXIF data and had an unnatural texture. That site likely reached the telecom equipment maker. A second site, an interior design showcase, likely reached the construction company. According to the report, the résumé site was replaced with the interior design showcase in January.

Each lure page loaded script from an external domain: javadevhouse.co[.]kr for the résumé site and pythonapischool[.]com for the design site. The researchers could not determine the exact trigger, but they assess with medium to high confidence that visiting the page started an infection involving INISAFE CrossWeb EX, a South Korean browser security plug-in. On infected machines, the CrossWeb EX service process INISAFECrossWebEXSvc.exe, running at high integrity, started the legitimate Windows Bluetooth file transfer tool fsquirt.exe, which was then injected with shellcode carrying the first malware stage.

From there the chain moved through six named tools: TechHub, TouchHub, TouchShift, ClientHub, LPEClient and Cubridge. LPEClient is where the post-quantum cryptography lives. It receives four ML-KEM-1024 public keys from the operators, derives shared secrets, and uses them to decrypt the final payload, a modular backdoor called Cubridge, which runs only in memory.

The timeline

No source published hour or minute timestamps for this campaign. The table below lists every dated event we could confirm, with its source.

The press release adds one more historical claim: that Lazarus has used this kind of cryptography since at least September 2024. The Securelist report itself does not give that date, so treat it as the vendor's statement rather than a detail documented in the technical write-up.

Who is affected

The direct victims are South Korean organisations. The tooling, though, is shared across Lazarus operations that have reached far beyond Korea, and two of the techniques (job and portfolio lures, and GitHub as a command channel) work against any company with developers.

Outside South Korea, and without CrossWeb EX, direct risk from this campaign is low. A sweep is still cheap, because Lazarus reuses its tools.

How the chain works

This section explains each stage in plain language. It describes what the malware does so you can detect it. It does not explain how to reproduce it.

Stage 0: the lure

The researchers describe tailored sites on GitHub Pages, one per target. GitHub Pages is a legitimate static hosting service, so the domain github.io passes most reputation filters and many corporate allow lists. The lure page itself held nothing obviously malicious. It pulled JavaScript from attacker-controlled or compromised domains, which kept the dangerous part off GitHub.

The résumé lure fits a long pattern. Mandiant documented recruiter profiles on LinkedIn and tailored job documents from the North Korean cluster UNC2970 in March 2023, and ESET documented Lazarus sending trojanized "coding challenges" to aerospace staff in September 2023. FlashHole flips the direction: the attacker poses as the job seeker, so the target is someone who expects to open résumés.

Stage 1: CrossWeb EX and fsquirt.exe

INISAFE CrossWeb EX is browser security software widely used in South Korea, part of the set of programs Korean users have historically had to install for online banking and government services. The FlashHole report found the parent process came from CrossWeb EX V3 version 3.4.1.2, a 2023 build released after KrCERT's public advisory. Under it, fsquirt.exe started and was injected with shellcode containing the TechHub DLL. In this initial stage, the researchers say, the chain ran in memory only.

How the plug-in was made to do this is the biggest open question. The report says plainly that "the exact method by which CrossWeb EX was abused remains unclear." The press release goes further and describes "a likely vulnerability" in the software. Neither BleepingComputer nor Techzine reported a vulnerability. Until a vendor or KrCERT advisory names one, treat this as unconfirmed.

Lazarus has a history with this product. The report lists earlier abuse in 2021, 2022 and 2023. AhnLab's ASEC published guidance in March 2023 describing Lazarus injecting a malicious DLL named SCSKAppLink.dll into the CrossWeb EX process and downloading further malware, and told users to move to CrossWeb EX V3 3.3.2.41. Academic work backs up the wider concern: a USENIX Security 2025 paper from KAIST and partner universities found 19 vulnerabilities across the Korea Security Applications ecosystem, noted that 97% of surveyed banking users had installed such software, and cited 2023 incidents in which North Korean attackers exploited it. The authors say the 19 flaws have since been patched.

Stage 2: TechHub, the GitHub downloader

TechHub is the first downloader. It talks to a private GitHub repository through the GitHub API using a personal access token, either hard coded or read from its configuration file. Other vendors track the same family under other names: Mandiant calls it CLOUDBURST and ESET calls it NickelLoader.

The report describes three TechHub variants: one that runs in memory, one loaded by DLL side-loading, and one loaded by side-loading through a registered service. Each infected host gets a four byte hex ID between 0x1000 and 0xFFFF. The handshake runs through GitHub issues: the malware opens an issue titled with the digit 1 followed by its host ID, with a short body, and the operators change that body to signal a reply. Files in the repository are named with a prefix digit, the host ID and a 16 byte key. File contents are AES encrypted, and the per-session XOR key is wrapped with RSA. TechHub understands four five letter commands, which match what ESET described for NickelLoader in 2023: profile the host, run shellcode in memory, terminate, and beacon.

The report counts at least three primary GitHub repositories used as C2 plus one fallback, and says the operators likely used hijacked email accounts to create them.

Stage 3: TouchHub, TouchShift and persistence

TouchHub, a tool not previously documented, installs persistence. It copies the legitimate Windows binary printfilterpipelinesvc.exe to C:\Windows\System32\RasConv\ImeBroker.exe and registers it as a service. The service name is built from a random entry in the netsvcs group under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost, plus two random letters, so it looks like a real Windows service name with a small suffix. The service command line is C:\Windows\System32\RasConv\ImeBroker.exe -TimeBroker and its description is simply "Microsoft Service". It runs as SYSTEM.

Next to the executable, TouchHub drops mscoree.dll (the TouchShift loader) and ActivationStore.dat (TechHub's configuration). It then timestomps the new files to match C:\Windows\System32\drivers\monitor.sys, so a quick sort by date does not show them as new.

TouchShift is the side-loaded DLL. Because the copied executable expects to load mscoree.dll, and the Windows loader checks the application's own folder before the system folder for DLLs that are not on the Known DLLs list, the fake DLL in the RasConv folder wins. Microsoft's documentation on the DLL search order warns that an attacker who controls one of the searched folders "can place a malicious copy of the DLL in that folder." TouchShift exports LockClrVersion, the same export Mandiant described for TOUCHSHIFT in 2023. It derives an AES key from the command line argument, a hard coded string and the executable's own file name, decrypts shellcode with AES-CBC-128, and loads the third TechHub variant, which reads ActivationStore.dat.

Stage 4: ClientHub, the C2 agent

ClientHub, also newly documented, is the command and control agent that later stages talk through. The report found several versions: some use HTTP or HTTPS to compromised websites and one uses the Dropbox API. Its configuration lives in internal resources or in C:\Program Files\Common Files\System\msadc\msadc.inc, encrypted with the SNOW 1.0 stream cipher, which the researchers say is the first time they have seen SNOW in Lazarus malware. Its loader is a DLL named liblzma.dll.

ClientHub dresses its traffic up as a modern browser, sending Chromium client hint headers such as Sec-CH-UA, Sec-CH-UA-Platform and Sec-Fetch-Mode. Responses carry a type field that tells it whether to load a DLL, load and run a plugin, or unload one. Plugins seen include a file archiver, a file collector, a file cleaner that overwrites and deletes, and a drive and session monitor. The researchers assess with medium to high confidence that ClientHub is an advanced form of CookiePlus, a modular Lazarus family seen in earlier campaigns.

Stage 5: LPEClient and ML-KEM-1024

LPEClient has been part of the Lazarus toolkit since 2019 and appeared in SyncHole, Dream Job and Cascade Hole. The FlashHole version has no C2 address of its own. It talks only through a shared buffer exposed by ClientHub.

First it profiles the machine. It records the Windows build revision from the UBR value under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion, reads the WMI repository file C:\Windows\System32\wbem\Repository\OBJECTS.DATA to find installed security products, and checks whether Kernel VA Shadow and CET shadow stacks are enabled. It builds a 32 byte host ID with HighwayHash, compresses its report with XPRESS Huffman, and encrypts it with the Russian GOST block cipher (Magma). The report notes KrCERT had earlier described this layer as "a custom DES-like scheme"; the researchers confirmed it is GOST.

Then comes the key exchange. The operators send four blocks of 1,568 bytes, each an ML-KEM-1024 public key. LPEClient encapsulates against each one, producing four shared secrets and four ciphertexts. The ciphertexts go back, GOST encrypted, through ClientHub. The four shared secrets together form the key for Threefish, a large block cipher, which decrypts the final package: a parameter block followed by a Windows executable. The executable the researchers identified, Cubridge, is loaded reflectively into memory and never written to disk.

Before running the payload, LPEClient tries to blind user mode monitoring. The report describes it abusing a memory protection helper inside jscript9.dll to make a function in memory writable, overwriting it with a system call stub, and switching off a user mode syscall instrumentation hook that security tools use to watch system calls.

Stage 6: Cubridge, the backdoor

Cubridge is a modular backdoor, tracked by Mandiant as SIDESHOW and by ESET as LightlessCan. Its configuration carries version 5.1 and a hard coded C2 on a compromised Korean site. Requests use randomised three part URL paths built from word lists, browser-like headers such as X-CSRF-Token and X-Requested-With, and a static authentication token. The handshake uses RSA and RC6.

It supports 80 commands, numbered 0 to 79, split across an Action module (ActionModule.dll) and a Function module (FunctionModule.dll). As ESET described for LightlessCan in 2023, it reimplements common Windows tools such as ipconfig, net, netstat, reg, sc, schtasks, systeminfo and whoami internally, so those commands never appear as new processes. One command extracts Chrome's protected AES key from the browser's Local State file. Plugins include an Active Directory finder that runs LDAP queries and a file collector, and a separate stealer takes passwords, cookies and history from Chromium-based browsers.

Why ML-KEM-1024 matters, and why it mostly does not

ML-KEM is the Module-Lattice-Based Key-Encapsulation Mechanism standardised by NIST in FIPS 203 on 13 August 2024. It lets two parties agree on a shared secret over a public channel, and it is believed to resist attackers with large quantum computers. FIPS 203 defines three parameter sets. ML-KEM-1024 is the strongest, claimed to meet NIST security category 5.

Source: FIPS 203, Table 3 and section 8.

The sizes line up exactly with the report. Each of the four public key blocks LPEClient receives is 1,568 bytes, the size of an ML-KEM-1024 encapsulation key. Four 32 byte shared secrets concatenated give 128 bytes of key material. The report describes the Threefish key as 256 bytes built from the four shared keys; we could not reconcile that figure with the 32 byte shared secret size in FIPS 203 from the published text alone, and the report does not spell out the expansion. We flag it rather than guess.

So what does post-quantum key exchange buy an attacker? Not much against today's defenders, for three reasons.

1. Nobody was going to decrypt this traffic anyway. The payload already travels inside HTTPS to compromised sites or inside the Dropbox API, then inside GOST, then inside Threefish. Even with TLS inspection, a defender sees layers of custom encryption. Classic elliptic curve key exchange would have been just as opaque to a security team in 2026.
2. It protects against later analysis, not live detection. The value of post-quantum key exchange is against someone who records traffic now and breaks the key exchange years later with a quantum computer. That matters to researchers and governments reconstructing a campaign long after the fact. It does not stop an endpoint agent from seeing a DLL load in a strange folder today.
3. The weak points are elsewhere. The chain still needs a lure, a parent process doing something unusual, a service install, a side-loaded DLL and outbound traffic to known infrastructure. Those are the detection points, and none of them involve the cipher.

The Securelist report frames it as intent: "the group intends to hide subsequent payloads." It also observes, a little pointedly, that Lazarus seems to have adopted post-quantum cryptography faster than many legitimate products. That is the more useful takeaway for software teams. If an espionage group's loader can ship ML-KEM-1024, your own TLS endpoints, VPNs and code signing plans can too. Our post-quantum migration guide for 2026 and the explainer on how ML-KEM works and common implementation pitfalls cover that side.

Technical details

Every value below comes from the Securelist FlashHole report unless marked otherwise. Domains and URLs are defanged. The report lists MD5 hashes only; it does not publish SHA-256 values, and no certificate, signing key or code signing serial is associated with these samples in any source we read. Use these values for blocking and hunting, not as a complete picture: the researchers say the victim count is likely higher, which implies infrastructure we have not seen.

File hashes (MD5)

File paths

Network indicators

The C2 hosts are compromised legitimate websites of Korean businesses and organisations. Blocking the full URLs is safer than blocking whole domains if your users have a real reason to visit them, and the site owners themselves are victims.

Host artefacts and strings

The report also publishes a Cubridge authentication token and a hard coded archive password. We leave them out: they are useful to a responder with a memory image, who should take them from the primary report, and they add nothing to a log hunt.

Cryptography used across the chain

Affected and fixed versions

There is no CVE for FlashHole, and no vendor has published a fixed version for the abuse seen here.

AhnLab's 2023 page lists the affected range as "3.3.2.41 and earlier" while also naming 3.3.2.41 as the update target, which is internally inconsistent; Korean press coverage at the time put the affected range at 3.3.2.40 and earlier. Either way, those are older advisories, and the FlashHole parent process is newer than both.

What changed since first reports

The story is a day old and the core facts have not moved, but the framing differs between sources.

• The vulnerability question. The technical report says the CrossWeb EX abuse method is unclear. The press release calls it "a likely vulnerability" and mentions a separate advisory confirming a vulnerability in financial security software. Secondary coverage did not repeat the vulnerability claim. Treat it as unconfirmed.
• The AI angle. The press release headline mentions AI. In the technical report, the AI evidence is a portrait on the résumé site that is "likely AI-generated." There is no claim that the malware itself uses AI. Some coverage leads with AI; the technical content does not support more than the photo and, per the press release, AI-tailored site content.
• Post-quantum history. The press release says Lazarus has used this cryptography since at least September 2024. The report gives no such date.
• Naming. Several families carry names from three vendors. TechHub is CLOUDBURST and NickelLoader; Cubridge is SIDESHOW and LightlessCan; ClientHub is assessed as an evolution of CookiePlus. Search your threat intelligence under every name.

Open questions

• How exactly was CrossWeb EX made to start fsquirt.exe? No CVE, KVE or vendor advisory ties FlashHole to a specific flaw in version 3.4.1.2.
• Is a fixed CrossWeb EX build available? Not that any source says. Check with the vendor or KrCERT before assuming any version is safe.
• How many victims? At least three are confirmed. The report expects more.
• Who owns the GitHub repositories and accounts? The report suspects hijacked email accounts were used to create them. No repository names were published.
• How does COPPERHEDGE fit? The report describes a separate COPPERHEDGE cluster starting around the same time, linked by AhnLab to Gunra ransomware and a leak site, and contrasts it with FlashHole's espionage focus. The relationship is not settled.
• Were victims notified? The report does not say.

What to do now

The steps below are for Windows endpoints and the logs around them. Run them from an elevated PowerShell session or through your endpoint management tool. If you find a hit, stop and preserve evidence before cleaning anything.

1. Check whether CrossWeb EX is installed

Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*', `
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' `
  -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -match 'CrossWeb|INISAFE' } |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate

Get-Process -Name INISAFECrossWebEXSvc -ErrorAction SilentlyContinue |
  Select-Object Id, Path, StartTime

Record every host and version. If nobody on that machine needs Korean banking or government sites that still require the plug-in, plan to remove it.

2. Sweep for the published file paths

$paths = @(
  'C:\Windows\System32\RasConv\ImeBroker.exe',
  'C:\Windows\System32\RasConv\mscoree.dll',
  'C:\Windows\System32\RasConv\ActivationStore.dat',
  'C:\Windows\System32\DrvConh\mscoree.dll',
  'C:\Windows\System32\DrvConh\ActivationStore.dat',
  'C:\Program Files\Common Files\System\msadc\msadc.inc',
  'C:\ProgramData\RasConv\mscoree.dll',
  'C:\ProgramData\Apple\mscoree.dll',
  'C:\ProgramData\ssh\mscoree.dll',
  'C:\ProgramData\qorestor\mscoree.dll',
  'C:\ProgramData\Dell\mscoree.dll',
  'C:\ProgramData\Dell\Dell1.tmp',
  'C:\ProgramData\Dell\Dell3.tmp',
  'C:\ProgramData\Package.txt',
  'C:\ProgramData\desktops.ini'
)
$paths | ForEach-Object {
  if (Test-Path -LiteralPath $_) {
    Get-FileHash -LiteralPath $_ -Algorithm MD5 |
      Select-Object Path, Hash
  }
}

Some of these names may exist legitimately; the msadc folder, for example, is a real Windows data access component folder. A path hit is a lead; a hash match is a finding.

3. Match hashes across likely drop folders

$bad = @(
  'ec84d6cb2ae7974767aedac246b50a3e','a28cba214058fcae2883d8cffc883abd',
  'c105d6b16f544582772de0159f24c00a','2f8475a90a25624ed02f1d18d4e6d65d',
  '676fabe30a28b53925fba98e34b35986','b4a7eff35f048f06fb0a2d7631f23a7d',
  'ff07641dc56914dd90ee0bd7404d7ad7'
)
Get-ChildItem -Path 'C:\ProgramData','C:\Windows\System32' -Recurse `
  -Include mscoree.dll,liblzma.dll -ErrorAction SilentlyContinue |
  ForEach-Object {
    $h = (Get-FileHash -LiteralPath $_.FullName -Algorithm MD5).Hash.ToLower()
    if ($bad -contains $h) { "$($_.FullName)  $h  MATCH" }
  }

4. Find mscoree.dll where it does not belong

The legitimate mscoree.dll lives in the system folders and .NET framework directories. A copy next to an unrelated executable is the side-loading pattern used here and in Mandiant's 2023 reporting.

Get-ChildItem -Path C:\ -Recurse -Filter mscoree.dll -ErrorAction SilentlyContinue |
  Where-Object { $_.DirectoryName -notmatch
    '^C:\\Windows\\(System32|SysWOW64|WinSxS|Microsoft\.NET)' } |
  ForEach-Object {
    $sig = Get-AuthenticodeSignature -LiteralPath $_.FullName
    [pscustomobject]@{
      Path = $_.FullName
      Signer = $sig.SignerCertificate.Subject
      Status = $sig.Status
      Modified = $_.LastWriteTime
    }
  }

Review anything unsigned or signed by an unexpected party. Because the attackers timestomp, do not rely on the modified date to rule a file out.

5. Look for the service pattern

Get-CimInstance Win32_Service |
  Where-Object {
    $_.PathName -match 'RasConv|DrvConh|ImeBroker\.exe -TimeBroker' -or
    $_.Description -eq 'Microsoft Service'
  } |
  Select-Object Name, State, StartMode, PathName, Description

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 500 |
  Where-Object { $_.Message -match 'RasConv|DrvConh|ImeBroker' } |
  Select-Object TimeCreated, Message

Event 7045 records a new service install in the System log. A real Windows service that runs ImeBroker.exe from a RasConv folder with a -TimeBroker argument would be unusual; compare against a clean build of the same Windows version before you conclude.

6. Hunt the process tree

If you collect process creation events (Sysmon event 1, or Windows Security event 4688 with command line logging), search for fsquirt.exe with a parent of INISAFECrossWebEXSvc.exe. That pairing has no ordinary reason to exist: one is a Bluetooth file transfer wizard and the other is a browser security service. If your EDR exposes a query language, the shape of the query is simple. For example, in a Kusto-style process table:

DeviceProcessEvents
| where FileName =~ "fsquirt.exe"
| where InitiatingProcessFileName =~ "INISAFECrossWebEXSvc.exe"
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessCommandLine

Also look for image loads (Sysmon event 7) of mscoree.dll from any RasConv, DrvConh or ProgramData subfolder, and for printfilterpipelinesvc.exe running from anywhere other than C:\Windows\System32.

7. Search DNS and proxy logs

On a Linux or macOS log host, a quick sweep of plain text or gzip proxy and DNS logs:

zgrep -E -i 'javadevhouse\.co\.kr|pythonapischool\.com|cubedesign\.co\.kr|fp-news\.co\.kr|k-wbc\.co\.kr|rcsh\.co\.kr|ksog\.org' \
  /var/log/proxy/*.log* /var/log/dns/*.log* 2>/dev/null

On a Windows host, check the local DNS cache for recent lookups:

Get-DnsClientCache |
  Where-Object { $_.Entry -match 'javadevhouse|pythonapischool|cubedesign|fp-news|k-wbc|rcsh|ksog' }

Then widen the hunt beyond the published list:

• Hosts that call api.github.com but are not developer machines or build servers.
• Hosts that call the Dropbox API but have no sanctioned Dropbox client.
• Requests to github.io pages followed within minutes by script loads from unfamiliar Korean or .com domains.

8. If you get a hit

1. Isolate the host from the network but keep it powered on. Cubridge and the final payloads live in memory, so a reboot destroys evidence.
2. Capture memory and a disk image, or have your incident responder do it.
3. Export the System, Security and Sysmon logs and your proxy logs for the period from July 2025 onward.
4. Treat every credential used on that machine as exposed, including browser-saved passwords and session cookies, given the Chromium stealer and Chrome key extraction. Reset passwords and revoke sessions from a clean device.
5. Look for lateral movement: Cubridge has an Active Directory finder, and SyncHole used a file transfer tool for lateral movement.
6. Rebuild the host from known good media rather than cleaning it.
7. Report to KrCERT/CC if you operate in South Korea, and to your national CERT elsewhere.

9. Clean up the plug-in estate

Where CrossWeb EX or similar Korean security plug-ins are not strictly needed, uninstall them. Where they are, keep them at the vendor's current build, and restrict which users and machines run them. The report notes South Korea's own plan to phase out mandatory installation from 2026, which gives most organisations a business case to remove them from engineering and admin workstations entirely.

What would have helped

No single control in this list would have stopped a patient state actor. These are the practices that shorten the chain or make each step louder.

Practices any team can use

• Inventory the plug-ins, not just the applications. Browser security add-ons, signing agents and local helper services run with high privilege and rarely appear in software inventories. You cannot patch or remove what nobody listed.
• Remove high privilege helpers from machines that do not need them. A developer laptop that never logs in to a Korean bank does not need a Korean banking plug-in. The USENIX paper found many users had versions from 2022 or earlier installed.
• Alert on odd parent and child pairs. A security service starting a Bluetooth wizard is the kind of signal that rules on process lineage catch well.
• Watch for side-loading. System DLL names in non system folders, signed Microsoft binaries running from unusual paths, and new services whose description is a bare "Microsoft Service" are cheap to detect.
• Treat cloud APIs as egress, not as trusted traffic. Restrict api.github.com and Dropbox API access to the machines that need it, through your proxy. Lazarus has used cloud services for C2 for years, and the press release itself advises monitoring connections to cloud services that could be abused this way.
• Train hiring managers and engineers on portfolio lures. A résumé site sent by email that loads script from a third party domain is a real red flag. Ask candidates for a PDF through your applicant tracking system instead of visiting links.
• Keep logs long enough. FlashHole ran for over a year before publication. Process, service and proxy logs kept for 30 days would show nothing useful for most of it.
• Plan for memory-only payloads. Have the tooling and the runbook to capture memory before rebooting.

Because one victim was a software company, there is a supply chain angle too. A developer workstation holds source, tokens and often build or signing access. Lazarus has gone after software builds before, as our post on Lazarus software supply chain campaigns covers, and its tooling has also used kernel exploits such as the one in our CVE-2026-68820 FudModule write-up. If a developer machine is compromised, assume everything that machine could push, sign or publish needs review. Our compromised dependency playbook is a template for that review.

Where Safeguard fits

The boundary first. Safeguard does not do endpoint malware detection. It does not run on employee desktops to watch processes, it would not have seen fsquirt.exe start under CrossWeb EX, it does not inspect DLL loads or services, and it does not monitor network traffic for C2. It would not have detected or prevented FlashHole. The hunting steps above happen in your endpoint, logging and network tools.

Where Safeguard helps is the software your organisation builds and ships, which is what an attacker on a developer laptop wants to reach next:

• Know what is in your code and images. safeguard scan --dir ., --image <name> or --sbom <file> builds an inventory of components and matches it against vulnerability databases, with results as JSON under ./output. The platform shows which projects contain a given component and version, so after an incident you can answer "what did that team ship, and what is in it" quickly.
• Rank what matters. Reachability analysis shows which vulnerable code paths your application actually calls.
• Gate changes with policy. Policies and gates evaluated in the platform let you block or require approval for risky components before they ship, which matters more when a developer's machine may not be trustworthy.
• Keep a human on every action. The Safeguard CLI's assistant can edit code and run commands, but asks first in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict). The desktop and phone apps can send work to a computer running the CLI and approve each command. That is the opposite of a trusted process quietly starting another one.
• Fix with review. Autonomous remediation can open fix pull requests, off by default, so a person reviews each change.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.

Neither applies directly to FlashHole. Nothing here was a vulnerable open source package that a curated registry could have replaced. The habit these capabilities support still applies to the rest of your estate: pull components from a curated, signed source, know exactly what you ship, and rebuild fast when something changes.

Common mistakes

• Treating the post-quantum angle as the threat. The cipher is the least detectable and least important part for a defender. Spend your time on process lineage, side-loading and egress.
• Blocking github.io or api.github.com wholesale. Your developers will route around it. Restrict API access by host role through a proxy instead, and review page visits in context.
• Rebooting a suspect host. Cubridge and the final payload run in memory. A reboot loses them.
• Trusting file dates. TouchHub timestomps its files to match a system driver.
• Hunting only by hash. Seven MD5 values cover the samples the researchers saw. The paths, the service pattern and the parent and child process pair travel better to new variants.
• Assuming the CrossWeb EX version is safe because it is "the 2023 fixed build". The parent process in FlashHole was a build released after the 2023 advisory.
• Forgetting browser data. The chain includes a Chromium stealer and Chrome key extraction. Password resets alone leave session cookies valid.

FAQ

What is Operation FlashHole?

It is a Lazarus espionage campaign, published on Securelist on 21 October 2026, that has targeted South Korean software, construction and wired communication equipment companies since at least July 2025. It uses tailored GitHub Pages lures, abuse of the INISAFE CrossWeb EX plug-in, GitHub and Dropbox for command and control, and an LPEClient loader that protects payloads with ML-KEM-1024.

Is FlashHole linked to Operation SyncHole?

The researchers assess with medium to high confidence that the same actor ran both, based on the initial vector, targets, chain structure and the use of LPEClient. They describe FlashHole as part of the wider Cascade Hole activity.

Why would malware use post-quantum cryptography?

The report reads it as intent to hide later payloads. In practice, ML-KEM-1024 protects the key exchange against someone who records traffic now and breaks it with a future quantum computer. It makes no difference to detection on the endpoint today, where the behaviour, not the cipher, gives the malware away.

Was a CrossWeb EX vulnerability exploited?

Unconfirmed. The technical report says the method "remains unclear." The press release calls it a likely vulnerability. No CVE or vendor advisory ties FlashHole to a specific flaw, so watch for one from the vendor or KrCERT.

Are organisations outside South Korea at risk?

From this exact campaign, mostly not, unless they run CrossWeb EX. The tools and techniques are reused across Lazarus campaigns worldwide, though, and job or portfolio lures work against developers anywhere. Sweeping for the indicators costs little.

Which indicators should I block first?

The two lure script URLs and the six compromised site URLs, plus the seven MD5 hashes in your endpoint tooling. Then add behavioural rules for fsquirt.exe under INISAFECrossWebEXSvc.exe, mscoree.dll outside system and .NET folders, and services described as "Microsoft Service".

Are SHA-256 hashes or certificate details available?

Not in the primary report. It publishes MD5 hashes only and names no code signing certificate, serial or key for these samples. If your tooling needs SHA-256, compute it from any matching file you find and share it through your CERT.

Did Safeguard detect this?

No. Safeguard is not an endpoint malware detection product and has no visibility into desktop processes, DLL loads or C2 traffic. It helps with the software you build and ship, which is where an attacker on a developer machine would try to go next.

What should a software company take from this?

That a developer workstation is part of your supply chain. Remove high privilege plug-ins engineers do not need, restrict cloud API egress by role, keep logs for months, and have a plan to review everything a compromised developer machine could have pushed or signed.

Fix it without waiting for upstream

FlashHole is an intrusion, not a vulnerable dependency, so nothing in this section would have stopped it. It applies to the open source components and images that a compromised developer machine could touch next, and to the everyday exposure that makes such a foothold valuable.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show FlashHole, CrossWeb EX or any malware. Safeguard would not have detected this intrusion. Each demo shows a real flow built on the principle FlashHole breaks: a trusted program on your machine should not start other programs or change files without a person saying yes.

The first demo is a real CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix a lodash CVE; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. In FlashHole, a high-integrity security service started a Windows binary and nobody was asked. Here, every command waits for you, and you can run the same /scan . on the repositories a compromised developer machine could have touched.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit; it ends with the upgrade done and tests passing. After an incident like this, that is how you would review and rebuild a project on a clean machine: scoped to one folder, with each change shown to you first.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI and the command is approved on the phone with Allow once, Allow for turn or Deny. FlashHole's tools installed a service and loaded a DLL with no prompt at all. In this flow, nothing runs until a named person taps Allow, even when they are away from the desk.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For the wider month's picture, see October 2026 security incidents and what would have helped and our roundup of edge device zero-days in October 2026.

Quick check

Sources

• Securelist: Lazarus Operation FlashHole (21 Oct 2026)
• Press release: new Lazarus APT campaign utilizing AI and post-quantum encryption (21 Oct 2026)
• Securelist: Operation SyncHole, watering hole attacks by Lazarus (24 Apr 2025)
• NIST CSRC: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: FIPS 203 full text (PDF)
• AhnLab ASEC: Initech product (INISAFE CrossWEB) security update recommendation (Mar 2023)
• USENIX Security 2025: Too Much of a Good Thing, (In)Security of Mandatory Security Software for Financial Services in South Korea
• Mandiant on Google Cloud: Stealing the LIGHTSHOW, North Korea's UNC2970 (Mar 2023)
• ESET WeLiveSecurity: Lazarus luring employees with trojanized coding challenges (Sep 2023)
• Microsoft Learn: Dynamic-link library search order
• BleepingComputer: Lazarus hackers use post-quantum cryptography for malware delivery (21 Oct 2026)
• Techzine: Lazarus hides malware using post-quantum cryptography (22 Oct 2026)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.