I have done the PATH variable setting and after doing this a DOS program starts as WinSCP. I'm guessing this is winscp.com. I want to run WinSCP.exe. I can do the whole C:\Program Files\WinSCP\WinSCP.exe, but I just want to type WinSCP and the GUI should pop-up. Has anybody done this before?
When you specify just filename without an extension, the .com has a precedence over .exe in Windows. And that's exactly a reason, why WinSCP command-line interface has .com extension. As it is expected, that when you run WinSCP from command-line, you want a command-line interface.
So when i backup my files on the checkpoints (running a lab on my laptop) i do not see them on the file path when logging into them from winscp, ive had this issue before as well and i remember the support guy who i was talking with (had a tac case opened a few months back with a different issue) fixed it by using the filter option on winscp (no idea what he did to make them appear though), so does anyone know how i make these backups,snapshots,etc appear in winscp? i need to transfer these to my laptop hardrive so that i can revert back to them when the 14 day trial license expires in 2 days or so for me. As you can see below in the screenshots nothing shows up on the path-
Beginning in early March 2024, Rapid7 observed the distribution of trojanized installers for the open source utilities WinSCP and PuTTy. WinSCP is a file transfer client, PuTTY a secure shell (SSH) client. The infection chain typically begins after a user searches for a phrase such as download winscp or download putty, on a search engine like Microsoft's Bing. The search results include an ad for the software the user clicks on, which ultimately redirects them to either a clone of the legitimate website, in the case of WinSCP, or a simple download page in the case of PuTTY. In both cases, a link to download a zip archive containing the trojan from a secondary domain was embedded on the web page.
The infection begins after the user has downloaded and extracted the contents of the zip archive and executed setup.exe, which is a renamed copy of pythonw.exe, the legitimate Python hidden console window executable.
Upon execution, setup.exe loads the malicious DLL python311.dll. As seen in Figure 2, the copy of the legitimate python311 DLL which setup.exe is intended to load has actually been renamed to python311x.dll. This technique is known as DLL side-loading, where a malicious DLL can be loaded into a legitimate, signed, executable by mimicking partial functionality and the name of the original library. The process of side-loading the DLL is also facilitated by hijacking the DLL search order, where attempts are made to load DLLs contained within the same directory first, before checking other directories on the system where a legitimate copy might be present. Rapid7 has also observed the Python 3.11 library being targeted in prior malware campaigns, such as the novel IDAT loader, discovered by Rapid7 during August of 2023.
The primary payload contained within python311.dll is a compressed archive encrypted and included within the DLL's resource section. During execution, this archive is unpacked to execute two child processes.
First, the malware executes the unpacked copy of the legitimate WinSCP installer, seen in Figure 3 as WinSCP-6.1.1-Setup.exe. Then, the malicious Python script systemd.py is executed via pythonw.exe after being unpacked into the staging directory %LOCALAPPDATA%\Oracle\ along with numerous Python dependencies. Following the successful execution of both processes, setup.exe then terminates.
The script systemd.py, executed via pythonw.exe, decrypts and executes a second Python script then performs decryption and reflective DLL injection of a Sliver beacon. Reflective DLL injection is the process of loading a library into a process directly from memory instead of from disk. In several cases, Rapid7 observed the threat actor take quick action upon successful contact with the Sliver beacon, downloading additional payloads, including Cobalt Strike beacons. The access is then used to establish persistence via scheduled tasks and newly created services after pivoting via SMB. In a recent incident, Rapid7 observed the threat actor attempt to exfiltrate data using the backup utility Restic, and then deploy ransomware, an attempt which was ultimately blocked during execution.
The related techniques, tactics, and procedures (TTP) observed by Rapid7 are reminiscent of past BlackCat/ALPHV campaigns as reported by Trend Micro last year. This campaign, referred to as Nitrogen by Malwarebytes, and eSentire, has previously been reported to use similar methods.
The source of the infection was a malicious ad served to the user after their search for download putty. When the user clicked on the ad, which are typically pushed to the top of the search results for visibility, they were redirected to a typo-squatted domain at the URL hxxps://puttty[.]org/osn.php. The landing page includes a download button for PuTTY, as well as two legitimate links to download a Bitvise SSH server/client. However, when the download link is clicked by the user it calls the embedded function loadlink(), which redirects the user to hxxps://puttty[.]org/dwnl.php, which then finally redirects the user to the most recent host of the malicious zip archive to serve the download. At the time of writing, puttty[.]org and the relevant URLs were still active, serving the zip archive putty-0.80-installer.zip from the likely compromised WordPress domain areauni[.]com.
Rapid7 observed the base domain, puttty[.]org was also serving a cloned version of a PuTTY help article available at BlueHost, where the download link provided is actually for the official distributor of the software. This relatively benign page is most likely conditionally served as a way to reduce suspicion as noted by Malwarebytes.
Upon extracting the zip archive putty-0.80-installer.zip, the user is once again presented with setup.exe, a renamed copy of pythonw.exe, to entice the user to initiate the infection by launching the executable.
Once executed, setup.exe will side-load the malicious DLL python311.dll. The DLL python311.dll then loads a renamed copy of the legitimate DLL, python3.dll, from the same directory after dynamically resolving the necessary functions from kernel32.dll by string match. Future requests for exported functions made by setup.exe can then be forwarded to python3.dll by python311.dll. This technique is commonly used when side-loading malware, so legitimate requests are proxied, which avoids unexpected behavior and improves stability of the payload delivery.
The resource is then decrypted in memory using an AES-256 hex key and initialization vector (IV) that are stored in the data section in plain text. The resulting file is a zip archive which contains three compressed files, including a legitimate MSI installation package for PuTTY and another compressed archive named installer_data.zip.
To execute the PuTTY installer, the malware first creates a copy of the MSI file in the hard-coded directory C:\Users\Public\Downloads\ via a call to fopen and then decompresses and writes the retrieved MSI package content with multiple successive calls to fwrite and other CRT library file io functions, followed by fclose. The full output path is assembled by concatenating the target directory with the desired file name, which is retrieved from original_installer.txt. The contents of original_installer.txt are identical to the name of the MSI package observed in the resource, for this sample: putty-64bit-0.78-installer.msi.
The same procedure is then repeated to copy the decompressed contents of the folder Oracle contained within the zip archive installer_data.zip to the staging directory created at %LOCALAPPDATA%\Oracle\. After the unpacking process is complete, another call by the malware to CreateProcessW executes the next payload with the command line %LOCALAPPDATA%\Oracle\pythonw.exe %LOCALAPPDATA%\Oracle\systemd.py. With its purpose completed, the loader then clears memory and passes back control to setup.exe, which promptly terminates, leaving the pythonw.exe process running in the background.
The Python script systemd.py contains multiple junk classes, which in turn contain numerous junk function definitions to pad out the core script. Ultimately, the script decrypts the file %LOCALAPPDATA%\Oracle\data.aes, which is a Sliver beacon DLL (original name: BALANCED_NAPKIN.dll), performs local injection of the Sliver DLL, and then calls the export StartW. The contents of main and other included functionality within the script appears to have been mostly copied from the publicly available Github repo for PythonMemoryModule.
Rapid7 recommends verifying the download source of freely available software. Check that the hash of the downloaded file(s) match those provided by the official distributor and that they contain a valid and relevant signature. The DLLs that are side-loaded by malware are often unsigned, and are often present in the same location as the legitimately signed and renamed original, to which requests are forwarded. Bookmark the official distribution domains for the download of future updates.
59fb9ae87f