> A malicious party gained access to the at the time Windows-based archive server (archive.palemoon.org) which we've been renting from Frantech/BuyVM, and ran a script to selectively infect all archived Pale Moon .exe files stored on it (installers and portable self-extracting archives) with a variant of Win32/ClipBanker.DY (ESET designation). Running these infected executables will drop a trojan/backdoor on your system that would potentially allow further compromise to it.
> I've ruled out remote FTP access, remote RDP access and execution of insecure software on the VM as potential breach points considering this access was at all times limited to myself only and locked down by IP and with secure, unique password protection.
I'm not so sure that FTP can be so easily ruled out. (This is assuming FTP means FTP and not FTPS or SFTP).
The "unique password" is broadcast in the clear. Anyone watching a connection gets to see it. (They also get to see your username and IP in the clear.)
The IP Authentication mechanism appears to be trivially spoofable thanks to allowing IP-forwarding. Without an actual authentication mechanism for the connection (SSL, SSH in the main alternatives), you can send from one IP, whilst supplying another to the protocol that gets used for auth.
So I did try digging into this again a bit more. According to the community, TLS was not in use, and nor was SFTP. (There's some suggestions that it was the IIS FTP server, but I can't confirm it.)
As to logging, most FTP servers log the forwarded IP and not the connecting IP when you enable forwarding.
So yes, FTP may well be the point of entry.
(Worth noting that a couple minutes looking at the palemoon site still comes up with quite a few security red flags. Like unenforced SSL on download pages, archive.palemoon.org still has no SSL, etc.)
If you're not careful on FTP and you expose the FTP servers logs writeable then an attacker can wipe them. If they use FTP to generate a reverse shell it gets even easier.
I stopped using Pale Moon a couple of years ago after reading a post on the forum by the developer, saying that it's impossible to get malware through Javascript.
They truly don’t know what they are talking about. We’ll maybe ultimately discover they weren’t using FTPS (or SFTP) but FTP and their non-hashed credentials were stolen and that won’t be a surprise to me...
> I've ruled out remote FTP access, remote RDP access and execution of insecure software on the VM as potential breach points considering this access was at all times limited to myself only and locked down by IP and with secure, unique password protection.
I'm not so sure that FTP can be so easily ruled out. (This is assuming FTP means FTP and not FTPS or SFTP).
The "unique password" is broadcast in the clear. Anyone watching a connection gets to see it. (They also get to see your username and IP in the clear.)
The IP Authentication mechanism appears to be trivially spoofable thanks to allowing IP-forwarding. Without an actual authentication mechanism for the connection (SSL, SSH in the main alternatives), you can send from one IP, whilst supplying another to the protocol that gets used for auth.