A fraudulent website is distributing a modified portable edition of FileZilla version 3.69.5 that contains embedded malware. The archive appears legitimate and includes the authentic open-source FTP client, but attackers inserted one additional file, a rogue dynamic-link library named version.dll, before repackaging and circulating it online.
When users download this altered ZIP file, extract it, and launch filezilla.exe, Windows follows its standard DLL loading order. The operating system checks the application’s own directory before referencing system libraries stored in C:\Windows\System32. Because the malicious version.dll is placed inside the FileZilla folder, Windows loads it first. From that moment, the malicious code executes within the legitimate FileZilla process.
This method relies on a long-established Windows behavior known as DLL search order hijacking. It does not involve a vulnerability in FileZilla itself. Instead, the compromise depends on users downloading the installer from an unofficial domain such as filezilla-project[.]live, which imitates the legitimate project site. The attack spreads through deception, including lookalike domains and search engine manipulation, rather than automated self-propagation.
Archive Examination Reveals a Single Suspicious File
The compromised archive contains 918 files. Among them, 917 entries show a last-modified date of 2025-11-12, consistent with the authentic portable release of FileZilla 3.69.5. One file differs: version.dll carries a timestamp of 2026-02-03, nearly three months newer than the rest.
A genuine portable distribution of FileZilla does not include version.dll. Legitimate libraries in the package typically include files such as libfilezilla-50.dll and libfzclient-private-3-69-5.dll. The Windows Version API library normally resides inside the operating system directory and has no reason to be bundled with FileZilla. Its inclusion forms the basis of the compromise.
The SHA-256 hash of the trojanized archive is:
665cca285680df321b63ad5106b167db9169afe30c17d349d80682837edcc755
The SHA-256 hash of the malicious version.dll is:
e4c6f8ee8c946c6bd7873274e6ed9e41dec97e05890fa99c73f4309b60fd3da4
Execution Behavior Observed on a Live System
Monitoring the application with Process Monitor confirms the sideloading sequence. When filezilla.exe starts, Windows attempts to load required libraries. For files such as IPHLPAPI.DLL and POWRPROF.dll, the application directory does not contain a copy, producing “NAME NOT FOUND.” Windows then retrieves legitimate versions from the system directory.
For version.dll, however, the malicious copy is present locally. Windows maps it into memory without consulting System32. The attacker’s code now operates inside the trusted application process.
Approximately 17 milliseconds after loading, the malicious DLL attempts to locate version_original.dll in the same directory. The lookup fails. This pattern suggests DLL proxying, where attackers forward legitimate function calls to a renamed original library to preserve application stability. In this case, the renamed library was not included, which may explain abrupt application termination during testing.
FileZilla invokes LoadLibrary using only the file name rather than a full system path. While common in Windows software design, this practice enables directory-based DLL substitution.
Anti-Analysis Checks and Network Commu
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: