Hot Take Missed script malware by signature analysis

Status
Not open for further replies.
One of the reasons; with SA you cannot properly manage some security software such as WFC.

I'll make you a suggestion. I used it with Windows XP.
It would also be interesting to check if it's still feasible.

Why not limit your browser privileges?

It's basically similar to having a Standard Account for your browser.
However, you need to be careful when performing certain operations.
For example, don't click on certain links in emails, otherwise the browser will open with full privileges.

It costs you nothing to try it out.
 
If you want to try it, I used PSExec:

PsExec - Sysinternals

In examples such as launching the browser you use with limited privileges.
Then check if it is stable, but above all with PE if the IL is correct.

I don't know if there is currently another method for lowering browser privileges.
Obviously, you should open a new thread.;)
 
I am now more concerned about protective mechanisms against deactivation by malware than missing few samples; could not find a comparative video for major AVs in this regard.
Ok
Yes GenD and K did better against that threat
1762677350758.png
 
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.
 
You really shouldn’t run unknown scripts that ask for admin access, Microsoft's Administrator Protection feature helps mitigate this threat.
I run only one; I trust its creator more than Bill Gates.
 
  • Like
Reactions: Khushal
Status
Not open for further replies.