NoVirusThanks OSArmor

[Andy Ful]

You should add the ability to block .scr and .hta files

The .scr files are blocked everywhere except C:\Windows. This seems to be both usable and pretty secure solution, if all Windows folders that are writable (as standard user) are not executable. That is the question to @NoVirusThanks, if OSArmor protects such folders.
The .hta scripts are already blocked by default, when ran from Windows Explorer or via CMD console.

 

[CoherentCrayon]

The .scr files are blocked everywhere except C:\Windows. This seems to be both usable and pretty secure solution, if all Windows folders that are writable (as standard user) are not executable. That is the question to @NoVirusThanks, if OSArmor protects such folders.
The .hta scripts are already blocked by default, when ran from Windows Explorer or via CMD console.

Ah, didn't know that. Thanks!

 

[Andy Ful]

I found an interesting OSArmor feature. It can block js, jse, vbs, vbe, wsf, wsh, hta, com, scr files when running from Windows Explorer, IE, Edge, and CMD, but those files can be executed from Total Commander at the same settings.
This has some pros and cons. For example, one can use Total Commander as the administrative tool to run scripts without making OSArmor configuration changes. The cons can be related to the malware that in theory could use the same path to run the above files as Total Commander.
What do you think guys?
.
Edit
The same is true for bat, cmd, msc, msi, reg, files.

 

[shmu26]

I found an interesting OSArmor feature. It can block js, jse, vbs, vbe, wsf, wsh, hta, scr files when running from Windows Explorer, IE, Edge, and CMD, but those files can be executed from Total Commander at the same settings.
This has some pros and cons. For example, one can use Total Commander as the administrative tool to run scripts without making OSArmor configuration changes. The cons can be related to the malware that in theory could use the same path to run the above files as Total Commander.
What do you think guys?

Does this apply also to "Everything" and other 3rd party search tools?

 

[Evjl's Rain]

Can't figure out what could block it. I am running Windows Defender and Appguard. Neither of them are known to interfere with OSA as far as I know. I also have Avast free in passive mode (no active protection). Maybe that is the culprit?

So it turns out it was Avast free in passive mode. That was kind of unexpected. Now OSA is working again.

@NoVirusThanks I would like to report the same problem between OSA and avast
I just installed avast free and I made some exclusions of OSA in avast's settings and disabled avast' hardware-assisted virtualization. However, no matter what I tried, OSA didn't seem to work
I tested by ticking "block .reg" and "block .bat" -> executed some real bat and reg files but all of them were executed (I use windows explorer)
OSA was working normally with KIS 2018 but avast totally screwed it

EDIT: after this, I put avast into passive mode (all shields are disabled) -> immediately OSA works -> reboot -> OSA still works -> enable all shields -> OSA still works -> reboot again with all shields on -> OSA doesn't work anymore. Then, I try to turn off individual shield to find out what the culprit is -> OSA still doesn't work
I'm clueless

The only solution -> turn on passive mode, which turns off all avast's shields (ask for a reboot) -> reboot -> turn on all avast's shields -> now both can work

 

[Andy Ful]

Does this bypass apply also to "Everything" and other 3rd party search tools?

I tried XYplorer and it works as Total Commander except for msc files which are blocked by OSArmor.
Everything search tool works as Total Commander.

 

[codswollip]

I tried XYplorer and it works as Total Commander except for msc files which are blocked by OSArmor.
Everything search tool works as Total Commander.

FWIW, ERP intercepts cmd.exe from Everything and XYplorer (didn't check the others but I'd expect the same result).

 

[ichito]

I found an interesting OSArmor feature. It can block js, jse, vbs, vbe, wsf, wsh, hta, com, scr files when running from Windows Explorer, IE, Edge, and CMD, but those files can be executed from Total Commander at the same settings.
This has some pros and cons. For example, one can use Total Commander as the administrative tool to run scripts without making OSArmor configuration changes. The cons can be related to the malware that in theory could use the same path to run the above files as Total Commander.
What do you think guys?
.
Edit
The same is true for bat, cmd, msc, msi, reg, files.

Yes, if you run non-system file manager...in my case it's Free Commander...you have to conssieder to make in your HIPS/BB/AE rules about parent/children processes. Actually I never launch any file using Explorer.exe...FC is my default "hand-launcher" of each file I need to use and and I can say it can lead to some problems...I met such while using DropMyRights because only the restricted app launches restricted file but using other metod to open file...eg FC...each file is open without restriction.

 

[509322]

Does this bypass apply also to "Everything" and other 3rd party search tools?

@shmu26

It is not a bypass because the user replaces Windows Explorer with Total Commander or QDir or another replacement file system manager that is not accounted for in OSArmor.

 

[shmu26]

@shmu26

It is not a bypass because the user replaces Windows Explorer with Total Commander or QDir or another replacement file system manager that is not accounted for in OSArmor.

I corrected my post.

 

[Sunshine-boy]

Total Commander.

Same for Anvir task manager though its a bug in windows lol.

 

[Deleted member 65228]

Same for Anvir task manager though its a bug in windows lol.

It's not a bug in Windows.

@NoVirusThanks can tweak his filtering to notice process creation requests from Total Commander (and alike software) if he wants to - it doesn't "bypass" his protection mechanisms, he just ignores the requests in his filtering currently. The process start-up requests still pass through his kernel-mode software.

The severity for this is low and I am sure the developer has more important things to focus on right now. The chances of malware using software like Total Commander as a benefit is extremely low because it won't benefit malware authors trying to evade from traditional security solutions - it's traditional security solutions which malware authors care about and are constantly focused on trying to fool 99% of the time.

 

[shmu26]

It's not a bug in Windows.

I think @Sunshine-boy meant that its behavior in Windows has bugs. He should correct me if I am wrong...

 

[Deleted member 65228]

I think @Sunshine-boy meant that its behavior in Windows has bugs. He should correct me if I am wrong...

I'm not sure, I thought he was referring to the process start-up by the task manager software not being caught by NVT OSArmor. Hopefully he'll correct so there's no misunderstanding

 

[Sunshine-boy]

process start-up by the task manager

Ye

 

[Andy Ful]

Guys, I think that Andres can cover blocking those files in the way as SRP can do, but the important question is if he should. As @Opcode said the chances to use this hole by malware in the wild is very low. Furthermore, I can see some pros of not blocking those files when executed via external file commander.
It would be useful for Andreas to see what people think about it.
Of course, one can imagine the possible way of abusing OSArmor default settings using Office macro to run PowerShell commands and download legitimate portable file commander + some 0-day payloads, and next using that file commander to run those payloads (scripts, .com, .msi or .scr files). But it would be simpler to just download the .exe payload and execute it using MMC20.Application Com object or WMI object. Yet, there is some danger. Some AVs have decent .exe files protection (like Avast Hardened Aggressive mode) but an average detection of .msi files (for example).

 

[Sunshine-boy]

xe payload and execute it using MMC20.Application Com object or WMI object.

Pls keep things "simple" I'm not Microsoft Engineer

 

[Andy Ful]

Pls keep things "simple" I'm not Microsoft Engineer

Skip the fragment "using MMC20.Application Com object or WMI object."
Using the above objects to execute payloads from scripts can be blocked in OSArmor by ticking advanced options related to mmc.exe and wmiprvse.exe.

 

[shmu26]

I think that if a script interpreter is blocked, it should be blocked no matter how you execute it. Otherwise there are too many loopholes. Malware changes all the time, and there are tricks that we can't foresee. An exception should be made only for Windows installer/updater.

 

[Andy Ful]

I think that if a script interpreter is blocked, it should be blocked no matter how you execute it. Otherwise there are too many loopholes. Malware changes all the time, and there are tricks that we can't foresee. An exception should be made only for Windows installer/updater.

OSArmor can only block Windows CMD and PowerShell interpreters (cmd.exe, C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe) when ticked in Advanced options. It does not block cscript.exe and wscript.exe interpreters, you can run them from Explorer. But anyway the script files: .vbs, .vbe, .js, .jse, .wsf, .wsh, are blocked by default options when one tries to run them from Explorer.
The rules for blocking script interpreters and for blocking script files execution are different.