> This ransomware seems to be in development phase and has some flaws as mentioned below:
> ...
> Hard code destruction time of Private Key “March 1 2018”.
Quite possibly. I'm not sure what that language means and they don't provide more analysis of the HTML page that comes from. If it's in development maybe some dude has been sitting on this idea for a few years and their virus scanner just picked it up recently.
> There's a problem with the Wayback Machine in specific which can kill your ability to access it quite silently, unless you know how to use the browser's development tools and interpret headers.
> It has to do with cookies: Somehow, the Wayback Machine sets cookies... and sets cookies... and keeps setting cookies, until it overflows its own ability to accept cookies. At that point, your browser tries to access a Wayback Machine page, handing the server all of the cookies it currently has, and the server refuses to deal. It absolutely denies everything, sending an error header and a blank page. You have to clear all web.archive.org cookies to get anything at all, at which point it works perfectly.
> I've completely solved this problem by blacklisting web.archive.org in browser cookie blacklists. I haven't had it happen since then. As far as I'm concerned, the problem is diagnosed and just needs to be solved. At their end.
One of these modules' owners should update their modules to check if they are running as part of the ransomware, and kill the program if so. That would certainly be an interesting turn of events.
Most languages, distros, large applications, etc have their own packaging system. Some are more laissez-faire than others.
Does someone know a good article from the POV of the maintainer of a packaging system ecosystem that describes the tradeoffs made by different approaches over the past ~30 years?
To be clear, as far as I can tell, the ransomware is built using nodejs. It is not a ransomware that's installed via a compromised package. Although if you happen to be a bad guy, it seems like building a quality bitcoin-related package, waiting until you have a big installed base, and then owning all your users, might be an effective way to set yourself up for life.
I'm not talking about a miner. I'm talking about a wallet or some utility module. You'd wait until you have a big installed base then change your module to silently steal coinbase credentials. Wait a few weeks until you have enough of them and then own all the accounts at once. Something like that. The Bitcoin aspect of the module is just to target effectively.
Count me in as being one who is disappointed that the code is not being made available. I know releasing it to the public is inherently dangerous, but, I can't help but to be curious as to how these programs work top to bottom.
"The sample received in our lab was vbs script which has multiple embedded js scripts. On execution, it creates a directory “GFp0JAk” at location “%userprofile%\AppData\Local\”."
If applications can't write to the Application Data folder then what's the point of an application data folder?
> Why is this even possible?
Well they said "on execution" so that's what made it possible. Now if it could install to that location without being explicitly executed (say on download or via a browser bug) then THAT would be a much bigger deal.
It's not so much the "applications can write data to application data" as it is "application data is executable by default". It's simply a design choice from before security was important. Nobody would defend that design today and Microsoft recognized this when they created appx which separates installers, executable programs, and data into separate content types treated with separate security policy.
Yes, but it's not granular per-application [i believe]. On an install script you can create folders in %localappdata% without needing elevated permissions meaning that %localappdata% and any files/folders you create are owned by the current user; unless a script does something with the file permissions, any other application can scan, access, and modify other applications (same goes for all of your user files but that's just par for the course for win32).
The article mentions the ransom message with the date March 1 2018. This probably means this malware is two years old?