How a Fake WinSCP Installer Loads Malware
Overview
The Broomstick campaign distributes malware by impersonating WinSCP, it does the same with PuTTY. WinSCP is a legitimate and widely trusted SFTP client (a program used to securely transfer files between a local computer and a remote server). Victims typically encounter the malicious installer through typosquatted domains, malicious ads (commonly known as malvertising) and SEO poisoning campaigns served through browsers. This involves malicious actors push their fake pages to the top of the search results, by manipulating search engine optimization techniques so that their malicious websites can rank highly for popular search queries.
For example, in our current scenario when a user searches for 'WinSCP' download, one of the top results returned is the malicious website - and normally users assume because its one of the top results then its the actual domain, other times they are faced with two similar looking sites and decide to go with whichever and may end up accidentally landing on the malicious site, ending up unknowingly downloading the trojanized installer instead of the legitimate one. Sometimes attackers customise their SEO poisoning campaigns and use techniques like spear-phishing to go after specific users like in our case to go after system admins and developers, making them more challenging to identify and defend against.
Once executed, the binary drops OysterLoader, which fetches and executes the actual payload, Redcap, a backdoor/RAT giving the attacker persistent access, shell command execution, and data exfiltration capabilities. It is attributed to APT41 (also known as Double Dragon, Winnti, BARIUM) - a Chinese state-sponsored group known for being one of the few APT actors that combines espionage with financially-motivated cybercrime.
APT41 is known for supply chain attacks, stealing source code from technology and gaming companies, targeting healthcare, telecommunications, and government sectors globally. This explains the spreader and the server access, they want to get as deep into the network and across as many machines as possible. This is reminiscent to the SolarWinds supply chain hack playbook, where trusted software distribution channels were abused to gain access to downstream systems in some sensitive sectors. Their target with this sample are developers and system admins the people who actually hold the keys.
Fingerprint & Threat Intel
SHA-256
9ac7c82eba9200fb11ac047bf259f30d4e6929e1f8a472557a3a81cdd1a492db
It is a signed 64-bit executable. A digital signature is a certificate attached to a binary as a claim of authenticity, issued by a trusted Certificate Authority (CA) such as DigiCert. Windows uses these certificates to verify the binary has not been tampered with and the publisher identity shown in UAC (User Account Control) prompts. Without one, Windows SmartScreen displays an "Unknown Publisher" warning dialog.
The certificate on this binary has been revoked, meaning the CA invalidated it. Most likely because it was stolen or the private key was compromised. Revocation is checked at runtime via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol). A revoked cert still technically signs the file, but any system performing a revocation check will flag it. Attackers obtain stolen certs to bypass the initial SmartScreen warning — by the time the revocation is caught, the binary may have already executed.
The binary also exhibits sandbox and debugger detection. This shows up in the import table through functions like IsDebuggerPresent CheckRemoteDebuggerPresent, and NtQueryInformationProcess - all Windows API calls specifically designed to query the execution environment. If a debugger or sandbox is detected, the malware alters or halts its behavior entirely. It pairs this with long sleep calls — invoking Sleep() function for a period of time. Automated sandboxes typically time out after a few minutes, so the malware simply waits them out, appearing benign until analysis stops.
It also has spreading capability, meaning it contains logic to infect other hosts, copying itself to network shares or other reachable machines. Finally, it uses a PE overlay: data appended after the defined end of the PE file. Legitimate programs use it for Self-Extracting Archives. Malware might use it to hide encrypted payloads, C2 addresses, encryption keys, or shellcode. The overlay is invisible to the PE loader but fully readable on runtime by the program. Still remains visible to static analysis tools like PE Studio without executing the file.
It poses as WinSCP.exe (Windows Secure Copy), a legitimate program used to securely transfer files to and from remote servers over SFTP/SCP. Legitimate WinSCP is located at C:\Program Files (x86)\WinSCP\, if the binary exists elsewhere, that alone is a red flag. A legitimate WinSCP binary also carries a valid, unrevoked certificate from its actual publisher. This one does not, which means we are dealing with a trojan. This is dangerous, WinSCP stores server credentials and session configurations, so an attacker now has access to your remote servers through your saved credentials and sessions. They can steal data, move deeper into the network, plant more backdoors, or tamper with builds and push malicious updates to downstream systems. In short, they have the keys to the kingdom.
Static Analysis
Static analysis through DIE and PE Studio revealed the following:
The binary targets Windows Vista+ (Vista plus any Windows OS released after it) on AMD64 and was compiled from C/C++ to 64-bit assembly.The DOS stub has been customized - (Heuristic) Protection: Generic [Custom DOS], DIE can't tell what protection has been used but there is something non-standard about it, which is unusual since most binaries just carry the default "This program cannot be run in DOS mode" message. In our scenario as we can see from the image below it just contains null bytes - 00, therefore no data is being hidden there.
The overlay in this sample contains the Windows Authenticode signature, stored as a PKCS #7 blob. PKCS #7 is a standard format for cryptographic messages, in this case, it includes the certificate chain, signer information, and timestamps that allow Windows to verify the file’s authenticity. The 10,568-byte overlay observed by DIE is therefore just the binary’s certificate, not a hidden payload. It sits past the PE boundary, which is exactly where Authenticode signatures are stored, making this perfectly normal for signed PE files.
The notable imports are:
LoadLibraryA,GetProcAddress— dynamic API resolution to mask what the binary really doesVirtualAlloc,VirtualProtect— memory allocation and permission changesInternetOpenW— sets up an internet connection
From these imports we can see the binary uses dynamic API resolution to hide its real functionality from static analysis, it allocates memory and makes it executable which is a common pattern for loading and running code in memory, and it reaches out to the internet. The follow-up network calls like InternetConnectW or HttpOpenRequestW are probably resolved at runtime through GetProcAddress, which is why they don't show up in the import table.
Attack Chain
The attack chain makes total sense when you think about it: Trojanized WinSCP → targets sysadmins and developers, people who actually manage servers. Not random users, they're going after people with keys. It acts as a Spreader → once on that machine, why stop there? Lateral movement across the internal network. If one dev's machine is compromised, their colleagues' machines, shared build servers, internal tools; all reachable. Server access via stolen WinSCP credentials/sessions → now they're not just on your machine, they're on your infrastructure. On a server they are essentially root. If you control the server that ships software updates or build artifacts, you can push a malicious update to every downstream customer. One compromised developer or infrastructure server can become a distribution point for thousands of other victims. Organizations routinely trust software updates and administrative tools provided by vendors, meaning that once an attacker infiltrates that trusted channel, the malicious code is effectively delivered under the guise of legitimacy.
This strategy mirrors the approach used in the solarwinds playbook, where attackers compromised the build environment and inserted a backdoor (known as Sunburst/Solorigate) inside legitimate SolarWinds Orion software updates to make it seem legitimate. Those updates were then distributed to thousands of organizations, including several government agencies and major technology companies and depending on whether the infected organization was high value or not further payloads were dropped. By abusing trusted software distribution channels, attackers can bypass many traditional security controls and reach targets that would otherwise be difficult or impossible to access directly. Instead of attacking a well-defended government or enterprise network head-on, they compromise a trusted intermediary and let the victim’s own trust relationships deliver the malware for them. That's why APT41 specifically targets tech companies and software vendors - the blast radius is massive.
Runtime Behavior
During Dynamic analysis through tools such as Procmon, INetSim and Wireshark we got a glimpse of how the loader prepares the environment:
Persistent DLL Sideloading Attempt. The binary aggressively attempting to CreateFile for several system DLLs such as (wininet.dll, IPHLPAPI.DLL, iertutil.dll) in the Desktop folder (the execution directory). The result: NAME NOT FOUND. I believe this is a DLL Search Order Hijacking attempt. The malware is looking for a malicious version of these libraries in its own folder before falling back to C:\Windows\System32. My theory is these libraries might be part of the files or payload being dropped so the binary can use them instead of the legitimate ones. Even though its failing we can anticipate a second stage payload to use those libraries.
In INetSim and Wireshark the network logs show an intensive volume of OCSP and CRL traffic (Certificate Revocation Checks). It repeatedly reaches out to DigiCert and VeriSign endpoints. I found the volume of these requests paired with constant fetches of disallowedcertstl.cab (the Windows "Blacklist") to be quite overwhelming and considered maybe they serve a dual purpose to clutter the traffic while also trying to verify the binary. Looking closer, we observed several public IPs being queried by the loader. At first glance, these appear as network noise, but they provide more information into the malware’s infrastructure.
The queries were PTR (Pointer) records, used for reverse DNS lookups. Unlike normal DNS, which resolves a hostname to an IP address, PTR records resolve an IP address back to its associated hostname. In IPv4, reverse lookups are typically represented in the special in-addr.arpa domain, where the octets of the IP are reversed. For example: 89.18.213.194.in-addr.arpa → 194.213.18.89. Below we can see the IP addresses the loader tries to reach out to:
2026-0x-xx 10:23:17 DNS connection, type: PTR, class: IN, requested name: 89.18.213.194.in-addr.arpa2026-0x-xx 10:23:54 DNS connection, type: PTR, class: IN, requested name: 113.53.239.85.in-addr.arpa2026-0x-xx 10:24:46 DNS connection, type: PTR, class: IN, requested name: 135.119.28.185.in-addr.arpa2026-0x-xx 10:31:37 DNS connection, type: PTR, class: IN, requested name: 250.255.255.239.in-addr.arpa2026-0x-xx 10:46:47 DNS connection, type: PTR, class: IN, requested name: 89.18.213.194.in-addr.arpa2026-0x-xx 10:47:35 DNS connection, type: PTR, class: IN, requested name: 113.53.239.85.in-addr.arpa2026-0x-xx 10:48:26 DNS connection, type: PTR, class: IN, requested name: 135.119.28.185.in-addr.arpa
These IPs are likely part of the C2 infrastructure used to download the second-stage payload. Analyzing their hosting and registration information provides additional context:
| IP | Organization | Registration / Location | Notes |
|---|---|---|---|
| 85.239.53.113 | JSC "TIMEWEB" (TW-Cloud) | Saint-Petersburg, Russia | Timeweb is a large Russian hosting provider; likely leveraged by malicious actors because it is outside Western law enforcement jurisdiction |
| 194.213.18.89 | BlueVPS OU (EE-BLUEVPS) | Corporate: Tallinn, Estonia; Physical: Ashburn, VA & Los Angeles, CA, US | Offshore VPS provider renting servers globally; likely used to blend with US traffic for evasion |
| 185.28.119.135 | BlueVPS OU (EE-BLUEVPS) | Corporate: Tallinn, Estonia; Physical: Ashburn, VA & Los Angeles, CA, US | Same as above; illustrates geographic dispersion to bypass geo-restrictions |
Using hosting providers in Russia and Estonia, with some servers physically located in the United States, is a tactic commonly employed by malicious actors to mix in with normal regional traffic and evade simple geolocation-based blocking. This is the point where the loader's "mask" slips. These aren't standard Microsoft or update servers. This is the Command & Control (C2) infrastructure.
BlueVPS OU is an offshore VPS (Virtual Private Server) provider registered in Estonia that rents virtual servers to clients worldwide. You can rent a server from them while relying on Estonia's privacy laws. However, when you rent the server, you can choose to have it physically spun up in a data center in the US. Attackers do this to blend in. If a network admin at a US company sees a PC talking to Estonia or Russia, they might block it immediately via Geo-IP blocking. But if the PC is talking to an IP in Ashburn, Virginia it looks like normal, legitimate web traffic. The server in Virginia then acts as a proxy, secretly routing the stolen data back to the attackers. So it's Estonian-registered, US-hosted, Russian-controlled infrastructure.
Interestingly, other OysterLoader samples in some threat reports show an almost similar IP within the same subnet - 85.239.53.66, which resolves to the domain funkyfirmware.com, that is likely the domain holding the payload. While I couldn't resolve that domain from my sample, the close similarity of IPs across the samples likely means that these are part of the same C2 infrastructure, I am not certain of this but i have a strong hunch. It confirms that even when a loader seems "quiet" and is buried in certificate validation noise, the clues to its true destination are often hidden in plain sight within the network metadata. When I run the sample the only visual response i get is this error message box.
IOCS
85.239.53.113185.28.119.135194.213.18.899ac7c82eba9200fb11ac047bf259f30d4e6929e1f8a472557a3a81cdd1a492db
TTPs
| Tactic (ATT&CK) | Technique ID | Technique Name | Observed Behavior / Mapping |
|---|---|---|---|
| Initial Access | T1189 | Drive-by Compromise | Victims are redirected to download a trojanized WinSCP installer through SEO poisoning and malvertising campaigns. |
| Defense Evasion | T1574.001 | DLL Search Order Hijacking | The binary repeatedly attempts to load system DLLs (e.g., wininet.dll, IPHLPAPI.dll, iertutil.dll) from the execution directory before falling back to C:\Windows\System32. |
| Discovery | T1016 | System Network Configuration Discovery | The loader performs multiple DNS queries, including PTR lookups, likely to understand the host network environment. |
| Command and Control | T1071.004 | Application Layer Protocol: DNS | DNS queries are used to resolve infrastructure and perform reverse lookups against external IP addresses. |
| Command and Control | T1095 | Non-Application Layer Protocol | Repeated TCP connection attempts to external IPs suggest attempts to establish communication with attacker-controlled infrastructure. |
Conclusion
In this analysis I examined a trojanized WinSCP installer that reveals the OysterLoader malware. While the application appears legitimate at first glance, the binary contains loader functionality that attempts to contact domains and retrieve an additional payload. During dynamic analysis several behaviors stood out. The binary repeatedly attempted to resolve external IP addresses through PTR lookups and made multiple TCP connection attempts toward remote infrastructure. As we've seen malware distribution increasingly relies on SEO poisoning and fake software downloads, tricking users into clicking malicious links that appear at the top of search results. This shows that any widely used tool can be weaponized when attackers push modified installers through malicious or typosquatted websites.
The loader also showed behavior consistent with DLL search order hijacking. The executable attempted to load several Windows libraries from the current working directory before falling back to the legitimate system locations in C:\Windows\System32. This technique is commonly used by malicious loaders to execute attacker-controlled DLLs if they are present in the same directory as the executable. One server was associated with a Russian hosting provider, while the others were registered to an Estonian VPS provider with infrastructure physically located in the United States. Hosting infrastructure across multiple regions is a tactic often used by malicious actors to blend in with legitimate traffic and reduce the likelihood of simple geo-blocking defenses.
A full attack chain will be available when i investigate the payload dropped in the next blog. I’m looking into building a tool that helps users make better decisions and avoid getting side-tracked into malicious sites despite them getting top-ranked, maybe train a model of sorts and deliver it as a browser extension or a bot that is easy to use and proactive, providing real-time alerts about suspicious domains (i don't know what i will base this on but we'll see). I never thought I'd end up examining a sample attributed to an APT when I picked this sample, that was a surprise but it's been pretty interesting. Even though I haven't gotten to the payload yet, it's been fun learning something new.