NoVirusThanks OSArmor: An Additional Layer of Defense

It arrived here via internal updater two minutes ago. Thanks for the new version.

 

We've released OSArmor v1.7.4:
https://www.osarmor.com/download/

Here is the changelog:

Just a very quick update, improved an internal rule to block suspicious behaviors (thanks @plat1098).

If you find false positives or issues please let me know.

 

Wow, bi-daily OSA updates. Thanks for that.

 

@novirusthanks , I am having an issue with OSA installer/updater since I implemented PowerShell Constrained Language mode restriction via SRP as described in this article: https://4sysops.com/archives/mitigating-powershell-risks-with-constrained-language-mode/ :

It appears OSA is trying to run a .tmp file as an execuatable. Why, I have no clue since I have never seen anything like this. I have tried to add a rule for this OSA activity in SRP to no avail. The only solution I have found is to temporarily change %temp% path rule to unrestricted which allows the OSA installer/updater to run w/o issue.

 

Just viewing the thread, and Bob's your uncle.

 

Post 4255 is an uncommented quote of Post 4252 & a screenshot of Post 4254. Huh?

 

Nitpicking!!!!

 

Hi,
i have BlackFog privacy installed besides OSA and i wonder, when BlackFog privacy gets its update, will OSA ruin its update installation. How to prevent it and what to do? Will they coexist installed together?

Many thanks!

 

@itman

The SRP block should be due to a rule that is restricting access to Temp folder (should not be related to PowerShell Constrained Language mode).

The behavior you noticed is a common behavior of setup/installer/uninstaller executables, they spawn a .tmp file on Temp folder to be able to perform specific installation/uninstallation tasks.

Please note that the .tmp file spawned by OSA setup is digitally signed by our company (same as the setup/uninstaller .exe file).

A possible partial workaround would be to block only unsigned processes on Temp folder and allow signed processes.

Else you may require to temporarily change %temp% path rule to unrestricted while installing/updating OSA.

@JOHNoff

I don't have BlackFog installed here but there should be no issues with running it with OSA.

If it doesn't use powershell.exe or cmd.exe or other commonly abused system processes during the update process and if its .exe/.tmp files are digitally signed, then there should be no issues I guess.

BlackFog, Inc. is also present in the Trusted Vendors List, so they should coexist installed together also if you have the option "Block signers not present in Trusted Vendors" enabled.

In case OSA blocks something, please share it here so I can check it.

 

You probably already know this but -- just in case, here's how to easily cut-off OSA's protection...

• Right-click OSA's icon in system tray, bottom right of your screen. Doing so produces a pop-up menu.
• The second item from the top of that menu is "Protection." Move your cursor over "Protection" (NO need to click it) and another pop-up menu will appear.
• The top 3 items of that pop-up menu are "Enable Protection," " Disable Protection," & "Disable Temporarily."
• Choose whichever of the 2 "Disable" items you want to use. Then OSA will be dormant for as long as you wish.

It's easy to disable OSA for an uninterrupted install --- but is it wise to do so? Hmmmmm?

 

I've done this frequently with OSA because I can't be bothered with creating numerous Exclusion rules for installers. But this is where other security tools can be used to verify the integrity of the installer.

 

Dear Support of OSA,
is this a OSA password bug? Let me describe. I installed OSA on win 11. Icon is installed on desktop. I set the password and saved it. After all the procedure i clicked on tray icon and the password is requested. You can do nothing without the password. But if i click on the icon on the desktop it will lead you to the settings without the request for the password. I then deleted that OSA icon on the desktop and ran it from the tray icon and now the password is requested all the time as ment.
Have you or someone else ever observed this behavior? I hope you understand what i wat to tell you!
Also thanks for the reply for the BlackFog program!

Many thanks!

 

I guess you didn't read the 4sysops linked article I referenced:

The best way to do this is via AppLocker. However, since it is only available on Win Enterprise versions, your only other alternative is using SRP.

Also of note is the environment variable reg. hack many are using to enforce PowerShell Constrained Language mode can be easily bypassed. See Matt Graeber's Twitter posting: https://twitter.com/mattifestation/status/921510606422786048 on how he bypassed using a one liner.

 

@novirusthanks,
#4225
I am truly impressed with master piece and updates that you add on to NoVirus Thanks OSArmor.

You have my interest, keep doing....

 

@novirusthanks
Are we likely to see a Xmas discount(recurring) this year or have I missed the boat?

 

Here is a pre-release test 1 version of OSArmor PERSONAL v1.7.5:

Code:

https://downloads.osarmor.com/osarmor-personal-1-7-5-setup-test1.exe

Let me know if you find issues or FPs.

You can install it "over-the-top" of the installed version, reboot is not needed.

Here is the changelog so far:

@JOHNoff

Thank you for reporting it, the issue should be fixed in the above pre-release test 1 version.

If possible please confirm me if it is working fine for you.

@Moose World

Thanks!

@LittleDude

Yes there will be a discount at Xmas.

 

Got it. Thanks NVT!

2 Questions:
Q1-Is there a way easily to identify newly added rules on OSA's Configurator panel?
Q2-Are newly added rules check-marked or is it up to the user to do that?

 

@bellgamin

Not at the moment.

Generally they are not enabled by default, so it is the user that has to enable them.

But, according to this text in the changelog:

It means we added new rules internally on already present rules, so no new "user-checkable" rules were added on Configurator -> Protections tab.

In case we add new "user-checkable" rules on Configurator -> Protections tab they will be specified in the changelog.

 

Hi,
i hope this password bug is resolved, but i cannot confirm it. I have installed the latest version on top of it and it did not create no desktop icon. So, rigth now i do not know if this bug is resolved.
But i have another important question. If i have OSA installed on my pc, am i protected from any kind of attacker wich is using digitaly signed malware against my pcs? How would i know?

Best wishes!

 

@JOHNoff

To test it instead of using the desktop icon you can double-click on the OSArmorDevUI.exe located here:

C:\Program Files\NoVirusThanks\OSArmorDevSvc

It should now ask for the password.

To protect from digitally signed malware that use a not-yet-revoked certificate make sure to enable this option:

"Block signers not present in Trusted Vendors"



You can also check this video where I test OSArmor with digitally signed malware:
https://www.youtube.com/watch?v=XUStga9CX1A

It shows how important is to block unknown signers.

You may also want to enable the other 3 protection options:

"Block processes signed with a revoked certificate"
"Block processes signed with an expired certificate"
"Block processes signed with an invalid certificate"

 

I am glad to say that this problem is now fixed, many thanks for your effort! And thanks for instructions to be protected from digitaly signed malware.

 

Here is a pre-release test 5 version of OSArmor PERSONAL v1.7.5:

Code:

https://downloads.osarmor.com/osarmor-personal-1-7-5-setup-test5.exe

Let me know if you find issues or FPs.

You can install it "over-the-top" of the installed version, reboot is not needed.

Here is the changelog so far:

OSA can now apply Digital Code Signature rules to MSI installers, here is an example blocking Magniber MSI malware sample signed:



Rule triggered is "Block signers not present in Trusted Vendors".

Another good rule that should be enabled is blocking of unsigned MSI installers, it can block unsigned Magniber MSI installers:



@JOHNoff

Great, thanks for confirming!

 

Yess!!! Much appreciated.

 

When i turned on my pc this morning i encountered on what you see in that attachment. The icon in the tray was yellow indicating that protection is ok but there was a black dot on the disabled protection. I turned off the pc and after that there was everything normal. I did not change anything!

 

Here is a pre-release test 6 version of OSArmor PERSONAL v1.7.5:

Code:

https://downloads.osarmor.com/osarmor-personal-1-7-5-setup-test6.exe

Let me know if you find issues or FPs.

You can install it "over-the-top" of the installed version, reboot is not needed.

@JOHNoff

Thanks for reporting it, the issue was that the popup menu in the tray icon was not matching the protection status in some occasions.

I uploaded the above new test build that should fix the issue, you can install it "over-the-top".

Let me know if you notice again this issue after a reboot or shutdown.