Detecting spoofed VPN downloads: a practical approach

Detecting spoofed VPN downloads: a practical approach

A valid digital signature on a VPN installer does not tell you where the file came from. That matters here. Storm-2561, a financially motivated threat actor active since May 2025, has been distributing trojanised VPN clients that impersonate Cisco, Fortinet, Ivanti, and Check Point. The installers carry a real Authenticode signature issued to “Taiyuan Lihua Near Information Technology Co., Ltd.” and they passed Windows verification at runtime. The certificate has since been revoked, but Windows does not enforce revocation checks at execution time by default, so SmartScreen does not always appear. You click through a clean-looking UAC prompt and the malware installs without much fuss.

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 tied to a certificate from a trusted Certificate Authority. It says nothing about whether the signer is the vendor you meant 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 if the CA trusted it and Windows had not cached a revoked status for it.

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 should match the vendor’s known signing identity exactly. Fortinet signs as “Fortinet Technologies (Canada) ULC”. Cisco signs as “Cisco Systems, Inc.” or a named subsidiary. If the publisher name is unfamiliar, looks like a transliteration, or does not match 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 you run it.

Get-FileHash .\installer.exe -Algorithm SHA256
sha256sum installer.exe

Vendor release pages, security advisories, and README files for many 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. This is not a phishing email you have to click; it is a search result that looks right. The spoofed domain is often a small variation of the real vendor URL, sometimes with an extra word such as “download”, “client”, or “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 and 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 check the domain shown.

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 organisations, with release histories, version tags, and code-signed assets that match published checksums. An MSI 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 trigger sideloading on first run.

sigcheck -r -u C:\Program Files\VendorVPN\

Run that from Sysinternals to list unsigned files in the directory. Any unsigned DLL sitting next to a signed executable is worth a closer look. Cross-reference the file list against a known-good installation or the vendor’s file manifest if one is 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 usually 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 sends those credentials to an attacker-controlled server before handing off to the real VPN client or quietly failing. The credentials captured by the malware include whatever you typed: username, password, and sometimes the domain or gateway address, which gives the attacker your VPN infrastructure.

If there is any chance a fake login prompt intercepted credentials, treat them as compromised straight away. Rotate the password, invalidate any active sessions on the VPN gateway, and check authentication logs for connections from unexpected source IPs or at odd times. Review whether the account had access to anything beyond VPN access itself. Assume the attacker now knows the VPN gateway address and will try 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 hard. It is just four minutes of checking you skip when you trust a search result to tell the truth.

Related posts

Weekly Tech Digest | 06 Jul 2026

Stay updated with the latest in tech! This digest covers AI ethics, auto industry shifts, and the impact of politics on technology, exploring today's pressing issues.

wolfCOSE zero-allocation parsing in embedded C

wolfCOSE looks sensible only if you care about what your firmware actually has to carry. I like that, because on small targets the wrong crypto feature can cost more than the message itself, and there...

restic | v0.19.1

restic v0 19 1: safer FUSE mounts and mountpoint checks, robust backup source and exclude handling, clearer CLI JSON output, Windows SFTP deletion fixes