Detecting Spoofed VPN Downloads: a Practical Guide to VPN Client Verification
A valid digital signature on a VPN installer does not tell you where the file came from. That distinction matters a great deal right now. Storm-2561, a financially motivated threat actor active since May 2025, has been distributing trojanised VPN clients impersonating Cisco, Fortinet, Ivanti, and Check Point. The installers carry a real Authenticode signature, issued to “Taiyuan Lihua Near Information Technology Co., Ltd.”, that passed Windows verification at runtime. The certificate has since been revoked, but revocation checks at execution time are not enforced by default on Windows, so the SmartScreen warning never appears. You click through a clean-looking UAC prompt and the malware installs silently.
This is the practical failure mode of VPN client verification: the trust UI lies by omission.
What a Signature Actually Proves
Authenticode confirms that a binary was signed by the private key corresponding to a certificate issued by a trusted Certificate Authority. It says nothing about whether the signing entity is the vendor you intended to download from. The publisher name shown in the UAC prompt is the certificate subject, not a verified brand identity. A certificate issued to any company name passes that check as long as the CA trusted the application and the certificate had not yet been revoked at the time Windows cached the OCSP or CRL response.
Check the certificate subject yourself before clicking anything. Right-click the installer, open Properties, go to the Digital Signatures tab, select the signature entry, and click Details. The signer name shown should exactly match the vendor’s known signing identity. Fortinet signs as “Fortinet Technologies (Canada) ULC”. Cisco signs as “Cisco Systems, Inc.” or a named subsidiary. If the publisher name is an unfamiliar company, a transliteration of a Chinese firm name, or anything that does not map to the vendor’s published signing identity, stop and discard the file.
Cross-reference the file’s SHA-256 hash against the vendor’s official release page before running it. Generate the hash with Get-FileHash .\installer.exe -Algorithm SHA256 on Windows or sha256sum installer.exe on Linux. Vendor release pages, security advisories, and README files for most enterprise VPN products publish expected hashes alongside the download links. If the page does not publish hashes, check the vendor’s support portal or signed release notes. No matching hash means no execution, regardless of what the signature says.
How the Download Chain Gets Poisoned
Storm-2561 manipulates search rankings so that searches for terms like “Pulse Secure client download” or “Cisco AnyConnect installer” surface spoofed sites above the vendor’s own domain. The attack is not a phishing email you have to click; it is a search result that looks correct. The spoofed domain is often a minor variation of the canonical vendor URL, sometimes with an added word (“download”, “client”, “get”) or a different TLD.
Pin the expected download URL to the vendor’s canonical domain before any file transfer begins. For Cisco AnyConnect and Cisco Secure Client, the download URL resolves under software.cisco.com or your organisation’s Cisco portal. For Fortinet FortiClient, it is fortinet.com or the EMS portal. For Ivanti Pulse Secure, it is ivanti.com. Bookmark those exact paths. Use them directly rather than searching each time.
Check the TLS certificate on the download page. The certificate’s Common Name or Subject Alternative Name must match the canonical vendor domain. A certificate issued to a lookalike domain, even one with a valid chain to a trusted CA, is not the vendor’s certificate. Open the padlock in the address bar and verify the domain shown. This takes five seconds and is not optional.
Watch for GitHub-hosted MSI and EXE files presented as official packages. Vendor software does not live in random GitHub repositories. Legitimate vendors maintain verified presence on GitHub under their own named organisations, with release histories, version tags, and code-signed assets that match their published checksums. An MSI hosted in a two-week-old personal repository with no release history, no stars, and no commit trail is not an official package. Discard it.
Inspecting the Installation Directory Before First Launch
Before launching a freshly installed VPN client for the first time, check the installation directory for DLL sideloading indicators. A legitimate VPN client ships with a fixed set of signed DLLs. A trojanised package may drop an unsigned or differently signed DLL alongside a legitimate signed executable to achieve sideloading on first run. Run sigcheck -r -u C:\Program Files\VendorVPN\ from Sysinternals to list unsigned files in the directory. Any unsigned DLL sitting next to a signed executable is worth examining closely. Cross-reference the file list against a known-good installation or the vendor’s file manifest if available.
Check Process Monitor during the first launch. Filter by process name and watch for unexpected outbound connections, file writes to %APPDATA% or %TEMP%, and any spawned child processes that do not appear in a clean install. A credential-harvesting payload will typically make a network call within seconds of the login prompt appearing.
Credential Handling After a Fake Login Prompt
Storm-2561’s Hyrax infostealer renders a convincing VPN login window that mimics the vendor’s UI. You type your credentials, the window appears to authenticate, and the malware ships those credentials to an attacker-controlled server before handing off to the real VPN client or silently failing. The credentials stored by the malware include whatever you typed: username, password, and in some cases the domain or gateway address, which reveals your VPN infrastructure to the attacker.
If there is any chance a fake login prompt intercepted credentials, treat them as compromised immediately. Rotate the password, invalidate any active sessions on the VPN gateway, and check authentication logs for connections from unexpected source IPs or at unusual times. Review whether the compromised account had access to any services beyond VPN access itself. Assume the attacker now knows your VPN gateway address and will attempt to use the stolen credentials against it.
For download chain hardening on a homelab, the steps are the same as on a work machine: verify the SHA-256 hash, check the certificate subject against the vendor’s known signing identity, confirm the download domain against the vendor’s canonical URL, inspect the install directory for unsigned files, and monitor the first launch in Process Monitor. None of that is complicated. It is just four minutes of checking you skip when you trust that a search result is telling you the truth.
