NoVirusThanks OSArmor: An Additional Layer of Defense

@busy @Tarnak

Thanks for the additional tests and details.

It is an interesting case because so far it has happened only with ProtonVPN_v3.2.7.exe and in some specific circumstances but found out why it is happening.

Will upload a new build tomorrow.

 

@novirusthanks

You're welcome You say an "interesting case", which just means it is beyond my ken.

 

Here is a pre-release test 4 version of OSArmor PERSONAL v1.9.0:

Code:

https://downloads.osarmor.com/osa-1-9-0-personal-test4.exe

+ Changes on verification of sign certificate
+ Improved Block execution of Remote Access Tools (E.g TeamViewer)
+ Minor improvements

If you find issues or FPs please let me know.

@busy

Let me know if you still get the alert when ProtonVPN_v3.2.7.exe is executed.

In my tests it now works fine (no alerts) but it is required an Internet connection active on the first run.

Or that ProtonVPN_v3.2.7.exe was already executed before and that Windows OS already validated the certificate (UAC showed no warnings).

 

I wish I could, but I reimaged and lost the logs. I'll post them when they occur again.

 

Running v1.9.0.0 - test 4

 

@novirusthanks

After installing osa-1-9-0-personal-test4, it no longer alerts on the host computer (Windows 10 Pro) . However, it still alerts on the virtual machine (Windows 10 Pro, Hyper-V) .

 

@busy

Is the alert always related to "Block processes signed with an invalid certificate"?

Also, if you run ProtonVPN_v3.2.7.exe in the VM, the UAC prompt is in orange saying "Publicher: Unknown" or is it in blue saying "Publisher: Proton AG"?

Asking this because if UAC shows "Publisher: Proton AG" then also OSA should recognise the program as valid signed by Proton AG.

And last question: if you enable an Internet connection on the VM and then after a few seconds you run ProtonVPN_v3.2.7.exe, does OSA show an alert (in case of yes, which one)?

 

It gives different results on two different virtual machines. I'll add some videos, maybe they will answer your questions.

Spoiler: Videos

Code:

https://drive.proton.me/urls/14SMPJ719W#B7so0WbIGeka

 

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

Code:

https://downloads.osarmor.com/osa-1-9-0-personal-test6.exe

If you find issues or FPs please let me know.

@busy

Thanks for including the videos.

Can you try this new test 6 build?

 

Um, is it possible for Export or Export All to include Exclusions and Custom Block Rules?

 

@novirusthanks

I installed Test 6 over Test 4 and got mostly the same error. I then tried changing some settings other than OSArmor, and I think I found the source of the problem...

I was logging into virtual machines using Hyper-V's Enhanced Session Mode (RDP) feature. When I ran ProtonVPN_v3.2.7.exe in these sessions, OSArmor usually returned an "invalid certificate" error. When I logged in without using Enhanced Session Mode (RDP), OSArmor did not give any certificate errors when I ran ProtonVPN_v3.2.7.exe.

 

Here is a pre-release test 7 version of OSArmor PERSONAL v1.9.0:

Code:

https://downloads.osarmor.com/osa-1-9-0-personal-test7.exe

If you find issues or FPs please let me know.

@busy

Thanks a lot for including that important details.

Should be fixed in this new test 7 build, let me know.

 

@novirusthanks
I can confirm that the problem has been fixed in the test 7 version. Thank you.

 

Just got this with Test 7 build:

Date/Time: 18/11/2023 5:40:14 AM
Process: [5988]D:\Users\KrisTwo\Desktop\InstallCyberLock761.exe
Process Size: 23.02 MB (24,138,072 bytes)
Process MD5 Hash: 5FBB52314099728197F2622A9629C9D8
Parent: [20532]C:\Windows\explorer.exe
Parent Process Size: 5.09 MB (5,340,232 bytes)
Rule: BlockSuspiciousProcesses
Rule Name: Block execution of suspicious processes
Command Line: "D:\Users\KrisTwo\Desktop\InstallCyberLock761.exe"
Signer: VoodooSoft, LLC
Parent Signer: Microsoft Windows
User/Domain: KrisTwo/DESKTOP-XXXXXXX
System File: False
Parent System File: True
Integrity Level: Medium
Parent Integrity Level: Medium
Passive Logging: False

BTW, If had blinked I don't think I would have seen the popup warning by OSA. There must be a way to increase the duration before it disappears from view.

 

It would be nice to be able to set how long notifications stay on. Until such a setting is added, you can disable the automatic closing of notifications or enable the notification sound.

NoVirusThanks OSArmor Configurator > Settings > Notifications:
[ ] Automatically close the notification window
[x] Play custom sound when notification is displayed

 

Here is a pre-release test 13 version of OSArmor PERSONAL v1.9.0:

Code:

https://downloads.osarmor.com/osa-1-9-0-personal-test13.exe

New changes:

+ Added more signers to Trusted Vendors list
+ Set for how many seconds the alert dialog stays on
+ Improved parsing of Custom Blocks and Exclusions rules
+ Added new internal rules to block suspicious behaviors
+ Minor improvements

If you find issues or FPs please let me know.

@Tarnak @busy

You can now set after how many seconds the alert dialog will be closed (default is 10 seconds).

@bjm_

Will discuss about that possibility.

 

This popped up last night, but it flashed by so quickly.

However, I captured the popup this time with the Test 13 installed over Test 7.

I chose to ignore, whereas I hadn't had time to make that choice, when I first saw it last night.



Perhaps, a better choice would have been to exclude it.

 

If you know what it is and it's harmless, then yes.

This is the only problem with this type of security software; when it blocks something, 99% of the time it is going to be a legitimate and obviously harmless process, much like what a HIPS utility does, so it's entirely up to the user to make that conclusion, and therefore exclude it either by posting the logs to the vendor as a FP so that they can add it as an Exclusion as most members are doing, or they manually add it themselves. Quite often it involves liberal use of wildcards as a means of preventing the alert from happening again with the same process. Such an example given for a Macrium Reflect product update:

Code:

[%PROCESS%: C:\Users\*\AppData\Local\Temp\*temp*\vpatch.exe] [%PROCESSCMDLINE%: "*:C:\Users\*\AppData\Local\Temp\reflectPatch.exe"] [%SIGNER%: <NULL>] [%PARENTPROCESS%: C:\Users\*\AppData\Local\Temp\reflectPatch.exe] [%PARENTSIGNER%: PARAMOUNT SOFTWARE UK LIMITED]

In all my years of using numerous security software, I've never seen anything like OSA that requires users to submit so many FP's in order to resolve their issues. Not bashing the product, i own a license myself. It's a powerful security product, just that most users seem to be at the mercy of the vendor to resolve issues when it blocks something completely harmless. In my case I just create the Exclusions when the process is blocked.

 

That’s what I’m doing too. I probably have a hundred of them…

 

They do accumulate quickly, especially for one who installs lots of different software.

 

@novirusthanks
Will there be any discounts this year?

 

We have released OSArmor v1.9.0:
https://www.osarmor.com/download/

Here is the changelog:

If you have automatic updates enabled then OSArmor should auto-update in the next hours.

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

In case you used test builds you need to install this final release "over-the-top".

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

@wat0114

OSA can show alerts for legit applications behaviors generally if:

[1] they run unsigned processes
[2] they run processes signed with an expired certificate
[3] they run some system processes such as cmd.exe, sc.exe, rundll32.exe, etc.

In your specific example related to Macrium, the signed process reflectPatch.exe executed vpatch.exe that is unsigned [%SIGNER%: <NULL>] (they have fixed it after we reported this to them so should not happen again).

OSA allows the user to exclude the blocked event for the next time with the "Exclude" button but it is up to the user to exclude the blocked event (with some events the user will need to use wildcards on parts that are known to change).

To make things easier for other users, if the event is shared with us and if we believe the event can be safely whitelisted then we can handle it internally on the next OSA build.

@busy

Yes, will provide more info asap.

 

Just added this to exclusions in OSA for an Emsisoft update, after first getting the OSA warning.

 

This link has not been added yet, has it?

 

Looks like some variable characters at the end, 9e04, that could change with every update. I'd suggest edit the rule by changing them to a single asterisk "*"

Hi Andreas,

yes I understand. I guess all that I was getting at was that FP's will never end.