AnySign4PC Water-holing: Silent SIGNBT/COPPERHEDGE Installations
Anyone else tracking the latest wave of AnySign4PC exploitation? South Korean authorities and several security firms just dropped a report on a state-sponsored campaign that is essentially using water-holing to turn trusted domestic websites into malware distribution points.
The mechanism is chilling: attackers compromise these sites, and when a user with a vulnerable AnySign4PC version visits, the financial security software is triggered remotely to install payloads without any prompts or UAC warnings. The primary backdoors being dropped are SIGNBT and COPPERHEDGE.
Since AnySign4PC is often whitelisted due to its function in banking/finance, standard EDR might miss the initial compromise if the parent process is trusted. We need to look for anomalies in child process execution.
Here is a PowerShell snippet to quickly check installed versions across your fleet:
Get-CimInstance Win32_Product | Where-Object { $_.Name -match "AnySign" } | Select-Object Name, Version, InstallLocation
And a KQL hunt for suspicious child processes:
DeviceProcessEvents
| where InitiatingProcessFileName has "AnySign"
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
| where ProcessCommandLine !contains "AnySign"
The paradox here is using 'security software' to bypass security. How are you all handling the inventory and risk assessment of these trusted, yet potentially vulnerable, local agents? Do you block them if the user isn't actively banking?
This is a classic example of 'trusted software' being the biggest liability. Since AnySign runs with high privileges to handle financial transactions, the blast radius is huge. I'd suggest verifying folder permissions on the installation directory. Often these installers leave Everyone: Full Control which makes DLL side-loading trivial. You can audit with:
icacls "C:\Program Files (x86)\AnySign4PC"
We manage a few clients with heavy exposure to Korean banking sectors. We've started strictly segmenting machines that require AnySign4PC. For the rest of the fleet, we're using AppLocker to explicitly deny the execution of the specific binaries. It's aggressive, but it stops the drive-by vector cold if a user wanders onto a compromised news site.
From a SOC perspective, the SIGNBT and COPPERHEDGE payloads have pretty distinct C2 patterns. If you can't patch the AnySign software immediately, focus on network detection. These backdoors often beacon over non-standard ports or use specific user-agents. Snort/Suricata rules for the COPPERHEDGE JSP variants were updated today. Prioritize network EDR alerts over endpoint ones for this specific campaign.
Great insights. While network detection is crucial, we shouldn't overlook endpoint process lineage. Since the exploit chain abuses the trusted executable, hunting for unexpected child processes is a solid immediate control. If the financial software is spawning PowerShell or cmd, that's a definitive anomaly.
DeviceProcessEvents
| where InitiatingProcessFolderPath contains "AnySign"
| where ProcessFileName in~ ("powershell.exe", "cmd.exe", "wscript.exe")
Building on the endpoint focus, silent installs often leave file system artifacts before execution fully initializes. Since this campaign modifies the trusted toolset, I recommend monitoring for unauthorized file writes in the AnySign directories rather than just process lineage. If you don't have a full FIM solution, this quick PowerShell scan helps hunt for the specific DLL artifacts associated with COPPERHEDGE:
Get-ChildItem -Path "C:\Program Files\AnySign4PC" -Recurse -ErrorAction SilentlyContinue | Where-Object {$_.Name -match "(signdll|inject)\.dll"} | Select-Object FullName, CreationTime
Catching the file write gives you a wider window to react than waiting for the process tree to spawn.
To add to the process lineage discussion, specifically validating the execution path of the signed binary is critical. If a trusted tool like AnySign4PC is launching from outside its standard installation directory, that's a massive red flag for masquerading.
Here's a quick KQL query to hunt for path anomalies:
DeviceProcessEvents
| where ProcessName contains "AnySign"
| where FolderPath !contains "Program Files"
Catching these deviations early can stop the payload before it establishes C2.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access