Someone has just posted got ransomware after running script command on some YT video claimed to download a game.
This is a user problem. Not a protection problem.
NB: The malware disabled MD.
Microsoft configures Windows editions and versions for "Users that want to use stuff." If it hardens or removes PowerShell, then there will be a lot of complaints. Gamers are notorious for wanting to and actually disabling Microsoft Defender. They also expect Microsoft to provide that capability.
Microsoft states that when using its software, the user is responsible. And by extension that means they must know what not to do and what to do to be secure.
So I have two questions:
Did the exe in memory disabled MD before exectuion?
Could other AVs detect it in memory (fileless) while MD failed (although it can be detected if landing on drive according to your data)?
1. Yes. Either by script or other means - such as instructing user to disable the AV.
2. Some AVs will block the execution of known abused or malicious PowerShell cmdlets that are entered by the user (during the session) into a PowrShell or other console (e.g. cmd, cscript, wscript). Bitdefender is one of them and users complain about it because they claim "Bitdefender interferes with me, the user, doing what I want. I am a user that wants to use stuff." Plus there are false positives.
Most AV use "context" which means if the user copy-pasted a command into a console that they launched, then they know what they're doing and the AV will not interfere. The reason for this is again that when anybody tries to protect users from themselves there is an outcry "We are users that want to use stuff!" Well OK then, users have been given what they have demanded.
Amazing; the cmd file (not the exe file loaded in memory after execution of the cmd file) was not detected by any vendor.
It would be trivial to create an algorithm that can spit out cmd files by the thousands, the millions, that not a single AV will detect. This is the weakness of any system with script language capabilities.
Microsoft's own security has stated "If a user does not need it (meaning use it frequently), then it should be disabled or another solution implemented."
I don't care what anyone argues. Microsoft Windows is a "modular general purpose" operating system. It was designed as such. What that means is that users of all types, need to figure out and disable all the stuff that they do not need. Just because it ships with Windows does not mean that it should never be disabled. That kind of thinking is 100% counter to Microsoft's own security guidance.
The average home user does not know and probably can never figure all of this out...
¯\_(ツ)_/¯. The user is always responsible for what they do on a device whether they know it or understand it.
One of the reasons; with SA you cannot properly manage some security software such as WFC.
SUA is for security. Not convenience.
It is not that much trouble to log out of a SUA, log into the Admin account, do what is necessary, then log out of the Admin account and then back into the SUA. Another way that might work is to close the application, launch WFC as administrator and authenticate, then re-launch the application and do whatever steps are necessary. It depends exactly upon what is attempted in configuring WFC.
Don't blame Windows SUA. Blame the developer of WFC that refuses to change his software to make it compatible with a SUA. He has known about this issue for over a decade and said he does not want to fix it. And why? Because WFC is freeware and the fix would require a lot of work. He is using outdated, deprecated command lines that require admin privileges and he does not want to put in the time and effort to fix the problem.
Running Windows full-time in Admin account is the face of stupidity, but just about everyone does it because they prioritize immediate capability to perform actions that required elevated privileges & permissions. In other words, they are lazy and do not want to take the time to do a little bit of work.