South Korean authorities and multiple security firms disclosed a campaign in which attackers used compromised, locally trusted websites as an infection route. The goal was not just to steal data, but to place backdoors on visitors’ systems by abusing a weakness in AnySign4PC, a certificate-based electronic signature component.
What makes the case stand out is the way the infection could trigger with a simple page visit—without a user-initiated download or an obvious prompt. According to the advisory, affected users ran vulnerable versions of AnySign4PC watering-hole related components long before a fix became publicly available.
How the watering-hole infection worked
The joint reporting bodies described spear-phishing and watering-hole activity. Attackers sent messages disguised as resumes, recruitment requests, investment material, and industry surveys. In parallel, they compromised websites across several sectors—news, healthcare, education, manufacturing, and smaller, less protected sites that victims were likely to browse.
Instead of relying solely on direct downloads, a compromised page could trigger exploitation against systems with an older, vulnerable AnySign4PC watering-hole setup. The advisory states that for specific versions, the victim’s device could be infected without the victim performing a download action or receiving an explicit prompt.
In other words, browsing became part of the kill chain: the page delivered the conditions needed to exploit locally installed software.
Which AnySign4PC versions were affected
Based on the Korea Internet & Security Agency (KISA) notice, AnySign4PC versions 1.1.4.4 through 1.1.4.6 were reported as affected. KISA listed 1.1.5.0 as the fixed release.
KISA’s guidance was direct: remove the vulnerable installations. The broader set of reports also left room for continued risk, noting that public information did not clarify whether attackers kept using the technique after the fixed version became available.
From a page view to code execution
Security researchers described an exploit sequence that used multiple elements delivered through the compromised web content. One reported chain involved four PNG images to exchange keys, verify the local product version, deliver version-specific exploit code, and then confirm whether execution succeeded.
Once the malicious content decided the environment was suitable, it communicated with the local security program over WebSocket. The technique then triggered a buffer overflow to run shellcode.
After achieving execution, the next stage involved hiding the payload by injecting it into legitimate Microsoft processes. Depending on how the intrusion progressed, the reported tooling mapped to backdoor families linked to what researchers named SIGNBT and COPPERHEDGE.
What the backdoors could do
The backdoors described in the reports were not limited to “phone-home” behavior. Researchers attributed capabilities such as remote command execution, file theft, internal reconnaissance, and process injection.
They also observed that the malware could deliver additional payloads after initial compromise. That pattern matters operationally: the infection was designed to evolve after the initial exploit, increasing the impact of each victim visit.
Independent reconstructions of watering-hole incidents
While the advisory provided a high-level picture, some firms went further by reconstructing parts of specific incidents.
Plainbit’s forensic view
One reconstruction focused on an incident involving a compromised web property. Attackers mapped the victim’s internet-facing infrastructure, took over the site, installed a webshell, and injected JavaScript into a legitimate news article page.
When a target visited the page, the vulnerable security program generated an error and created a malicious DLL without requiring a download prompt or other user interaction. The payload then decrypted subsequent stages in memory, injected code into svchost.exe, and used Windows registry entries for command-and-control information.
After establishing foothold capabilities, follow-on actions included privilege escalation, credential tooling such as Mimikatz, Remote Desktop Protocol usage, and additional network movement via tools like NLBrute.
S2W’s clustering and loader behavior
S2W analyzed multiple malware clusters and highlighted recurring techniques such as DLL side-loading, encrypted registry blobs, and in-memory Portable Executable (PE) loading. Across clusters, researchers reported deployment of SIGNBT versions and a separate loader that decrypted an external payload that was not recovered.
These patterns reflect a broader operational goal: keep the attack components resilient to static detection by pushing critical steps into memory and encrypted structures.
Evidence overlap and the uncertainty of operator control
Multiple reports noted shared artifacts across operations. For example, they pointed to the same initial-access weakness, similar malware file naming, execution patterns, an SSH key fingerprint, and network infrastructure. Researchers also noted shared domains used to distribute exploit-related scripts.
However, the reporting was careful about attribution. AhnLab stated the evidence did not prove that a single actor conducted every operation. It also explained that the “72 organizations” figure should not be treated as a simple count of equally confirmed full compromises, because the reporting did not define how organizations were included in that number.
Just as importantly, the government advisory did not name the specific state-sponsored group behind the campaign.
The Gunra ransomware trail
Another thread connected the watering-hole exploitation path to ransomware activity. The reporting described a March 2026 Gunra ransomware intrusion that reused a similar compromised healthcare website and a weakness tied to a financial-security component (referred to by AhnLab as “financial-security software A”).
Researchers observed that both the state-sponsored chain and the ransomware chain injected code into SyncHost.exe. Still, AhnLab did not identify what “financial-security software A” was, so the reporting did not establish that the ransomware-linked vulnerability was the same as AnySign4PC watering-hole related AnySign4PC weakness.
Even so, there were notable overlaps in artifacts and operational steps. Both operations used filenames such as net.tmp and inet.tmp, matching or similarly structured arguments and the same SSH public-key fingerprint. The reports also cited the same reverse-tunnelling address and the same domain used to distribute exploit scripts.
Anti-forensic behavior was also described: malicious files were renamed to short random names prior to deletion, and additional evidence destruction tools were observed in at least one reconstruction.
Attribution limits: what is and is not claimed
Attribution in cybersecurity reporting often involves layers of evidence. In this case, the government advisory and the “Operation Double Barrel” report referred to the espionage operator only as a generic state-sponsored threat group. They did not formally attribute the full 2025–2026 campaign to a single named actor, nor did they connect that campaign to Lazarus.
That said, earlier research cited Lazarus in relation to other watering-hole and AnySign4PC exploitation activity. Still, those older reports did not automatically prove that the newer operations—described in the current disclosure—were conducted by the same actor.
So, the safest conclusion from the current disclosures is technical linkage at the level of access paths and tooling, not complete certainty about who controlled every incident end-to-end.
Patch and hunt: what defenders can do
KISA’s recommendations emphasized patching and removal. For organizations running AnySign4PC watering-hole sensitive versions, the advisory points to AnySign4PC 1.1.5.0 as the fixed release, and it advises deleting vulnerable installations.
Beyond patching, the reports recommend active hunting using behavioral and telemetry-based signals, including suspicious DLL loading by legitimate executables, encrypted data stored under service-related registry entries, and in-memory PE execution.
Indicators highlighted in the reports
- Unusual service creation and unexpected process injection into SyncHost.exe or svchost.exe
- Encrypted configuration artifacts in service registry locations
- Network indicators, including unexpected outbound SSH tunnels
- Process-memory preservation during incident response to capture in-memory execution evidence
ENKI also observed a backdoor behavior that reduced the usefulness of stable file indicators: after copying components into memory, it removed or altered registry configuration and files from disk during certain operational modes. As a result, defenders benefit more from behavioral telemetry than from “one fixed file hash” alone.
Plainbit described a persistence chain where a scheduled task launched a script that then started a renamed SSH client to establish a reverse tunnel. The broader guidance from S2W included preserving process memory, command lines, registry values, DLL-load events, and network records before taking disruptive containment actions.
Website compromise and supply-chain questions
AhnLab reported that multiple compromised websites connected to the same development and management entity, which it described as a potential supply-chain route. Even so, the available evidence did not prove that the provider’s source code, update process, or central management platform had been compromised.
From a defender perspective, the takeaway is that “trusted” does not necessarily mean “safe.” Organizations should validate their web exposure and ensure their content and operational dependencies are continuously monitored.
Bottom line
The disclosure describes a sophisticated compromise path where attackers leveraged compromised websites to exploit vulnerable AnySign4PC watering-hole conditions. For affected versions, exploitation could occur after a victim simply visited a page—without a user downloading anything or being prompted.
While attribution across every related operation remains uncertain, the technical lessons are clear: apply the fixed AnySign4PC release, remove vulnerable versions, and hunt for behavioral signs such as memory execution, unusual DLL loading, registry-encrypted artifacts, process injection, and unexpected SSH tunneling.
Source: https://thehackernews.com/2026/07/hackers-exploit-anysign4pc-via-hacked.html
