AnySign4PC watering holes infected visitors on page view

On 30 July 2026, Korean authorities and four security companies disclosed a campaign known as Operation Double Barrel. Attackers compromised legitimate websites and then exploited locally installed financial-security software. On a system with an affected AnySign4PC release, visiting a modified page could lead to code execution and backdoor installation without a separate download or further click.

The case demonstrates inverted trust. Software installed for electronic signatures and secure financial services became a bridge between web content and the operating system. A legitimate site delivered JavaScript, a local component accepted WebSocket communication, and a memory-safety flaw enabled the transition from browser content to shellcode.

Confirmed findings

The Korea Internet & Security Agency, National Intelligence Service, National Police Agency and Financial Security Institute issued a joint notice based on work by AhnLab, S2W, ENKI Whitehat and Plainbit. Sources collected in 30 July reporting establish:

• AnySign4PC 1.1.4.4 through 1.1.4.6 are affected;
• the fixed release is 1.1.5.0;
• KISA recommends removing vulnerable installations;
• attackers used spear phishing and compromised watering-hole websites;
• malicious pages communicated with local software through WebSocket;
• the chain delivered SIGNBT or COPPERHEDGE backdoors;
• AhnLab found related evidence at 72 organisations and 15 compromised websites;
• the sources do not formally attribute the complete campaign to Lazarus;
• no public CVE is assigned specifically to the newly described AnySign4PC flaw.

The number 72 is not a straightforward count of full network compromises. The public report does not explain one uniform inclusion threshold. Observations may represent different stages, from access attempts to artifacts or confirmed malware. It should not be presented as 72 fully controlled organisations.

Watering holes instead of direct payload delivery

A watering-hole operator chooses a site regularly visited by the target population. Rather than send every person a payload, the attacker compromises a news, healthcare, education, manufacturing or smaller supplier website.

Modified sites in this campaign contained scripts that launched the chain only when the expected local component was present. Most visitors could see a normal site, reducing visible errors and making compromise harder for the site owner to notice.

Spear-phishing themes included résumés, recruitment, investment material and industry surveys. The message did not need to carry malware. Its purpose was to direct the right person to a legitimate but compromised page.

The AnySign4PC technical chain

AhnLab’s Operation Double Barrel report describes four PNG images used for key exchange, local-version checks, version-specific exploit delivery and execution-result reporting.

The sequence was:

1. a user opened a modified page;
2. JavaScript detected the local security component;
3. the site communicated with AnySign4PC through WebSocket;
4. the installed version determined which code path was selected;
5. a buffer overflow triggered shellcode execution;
6. the payload entered a legitimate Windows process;
7. SIGNBT/Struggle or COPPERHEDGE/Brandoor started;
8. the backdoor received further tasks and tools.

Plainbit reconstructed one incident in which attackers mapped internet-facing systems, compromised the website, installed a webshell and inserted JavaScript into a legitimate news page. When a target visited it, the vulnerable component produced a malicious DLL without a download prompt.

This was not a conventional drive-by download relying solely on a browser flaw. A local helper exposed to web content was the critical bridge.

SIGNBT and COPPERHEDGE after entry

The final implants supported command execution, file theft, internal reconnaissance, process injection and additional payload delivery. Different clusters used DLL side-loading, encrypted registry values and in-memory Portable Executable loading.

One variant kept command-and-control configuration in the registry and injected into svchost.exe. Another persistence chain created a RuntimeBroker task that launched task.vbs, followed by a renamed SSH client presented as SearchHost.exe to create a reverse tunnel.

System-like names are signals, not proof. Legitimate RuntimeBroker.exe and SearchHost.exe exist. Detection must include path, signature, parent process, arguments and network behaviour.

Why stable hashes lose value

ENKI described self-protection modes in which a backdoor deleted its registry configuration, loader and files after copying them into memory. On clean shutdown, it wrote a loader back with a different hash.

A single SHA-256 can find one sample, not the full class. Stronger telemetry includes:

• unexpected local WebSocket communication from web content;
• a legitimate executable loading a DLL from an unusual path;
• in-memory PE execution without a corresponding disk file;
• new services and scheduled tasks;
• encrypted service-registry values;
• injection into SyncHost.exe or svchost.exe;
• an outbound SSH tunnel from a system-named process;
• SDelete or CCleaner activity after malware execution.

Preserve process memory, command lines, DLL-load events, registry data and network records before terminating a process. Rapid cleanup can destroy the most useful evidence.

The Gunra overlap does not prove one actor

AhnLab found technical overlap between the espionage activity and a March 2026 Gunra ransomware incident. Shared elements included an initial vulnerability in one anonymously labelled product, filenames, argument formats, an SSH key fingerprint, tunnel infrastructure and a distribution domain.

That evidence permits several explanations:

• limited cooperation around initial access;
• shared tooling or infrastructure;
• a common access broker;
• access to the same operational resource;
• reuse of known components by another group.

AhnLab did not reveal the names of two other affected products, labelled software A and I. The report does not establish that the Gunra-linked product was AnySign4PC.

Does the evidence establish Lazarus?

A separate April AhnLab report attributed an earlier AnySign4PC watering-hole operation to Lazarus. Kaspersky previously described Operation SyncHole using Korean security software, SIGNBT and COPPERHEDGE.

Those similarities are relevant context. The current joint notice and Operation Double Barrel describe the espionage operator only as state-sponsored. They do not formally attribute the whole campaign to Lazarus and do not connect Lazarus to Gunra. Internal reporting should label the actor link as an unconfirmed hypothesis.

Who is exposed

The direct risk applies to endpoints running AnySign4PC 1.1.4.4 through 1.1.4.6, particularly in South Korea where certificate-based signing software is common. Organisations elsewhere should treat the event as a model for local helpers installed by banks, public administration, electronic-signature platforms and legacy B2B portals.

Inventory:

• browser extensions and localhost listeners;
• components accepting WebSocket messages from arbitrary sites;
• software installed years ago for one portal;
• automatic updaters with unclear ownership;
• signed but unsupported libraries;
• local applications running with more privilege than the browser.

Remove components with no business requirement. Updating unnecessary software still leaves additional attack surface.

Response plan

1. find AnySign4PC versions in software inventory;
2. remove 1.1.4.4–1.1.4.6 or update to 1.1.5.0 under KISA guidance;
3. review access to websites and infrastructure named in the reports;
4. collect memory, DLL, task, service, registry and tunnel telemetry;
5. isolate systems showing correlated signals;
6. inspect accounts, RDP and lateral activity after the earliest suspicious time;
7. rotate credentials used on an infected host;
8. validate the integrity of corporate websites and web-management suppliers.

If a backdoor is present, updating AnySign4PC does not remove the implant or later access. Use a complete incident-response and scoping process.

SOC detection hypotheses

Turn the research into testable sequences:

• a browser opens a local WebSocket, followed by a signature component creating a DLL;
• a signed application loads a library from a user or temporary directory;
• SyncHost.exe or svchost.exe opens a connection unrelated to the endpoint’s role;
• a system-named task launches VBS and an SSH client;
• financial-security software writes or executes unsigned code;
• Mimikatz, RDP or NLBrute appears after a visit to a known watering hole.

Our Sigma and SIEM detection-engineering guide explains how to maintain and test such correlations. Campaign context and attribution confidence belong in a structured Cyber Threat Intelligence lifecycle.

Validation after the update

Seeing version 1.1.5.0 in inventory is not sufficient closure evidence. Confirm that old executables and libraries are absent from user directories, installer caches, golden images and software-distribution packages. Validate that the local WebSocket accepts only expected origins and that a browser cannot invoke a privileged operation without an authenticated context.

SOC closure criteria should include no SIGNBT or COPPERHEDGE artifacts, no unauthorised task, service or tunnel, and no suspicious identity activity after the earliest exposure time. Website owners need a separate integrity comparison against a trusted release, plus review of administrator accounts, publishing logs and the content-management platform. The campaign crossed two trust boundaries—a compromised website and a vulnerable local component—so fixing only one gives incomplete assurance.

A safe regression test can attempt a non-destructive request to the local helper from a controlled origin and confirm rejection. A public buffer-overflow proof of concept should not be run on a user workstation.

Sources versus Breachroad conclusions

Versions, remediation, WebSocket communication, memory exploitation, malware families and observed behaviours come from KISA, AhnLab, ENKI, Plainbit and S2W reporting. The sources establish technical overlap with Gunra, not a single operator. They do not conclusively attribute Double Barrel to Lazarus.

Our recommendations on local-helper inventory, WebSocket visibility, detection priorities and response ordering are Breachroad analysis. Organisations can assess similar trust boundaries through an IT security audit and web/API penetration testing.

The universal lesson is that a trusted website and signed local component do not automatically form a safe chain. Cybersecurity training for technical and non-technical teams should cover incidents where the user downloads nothing and compromise begins through a trusted but altered service.