NoVirusThanks OSArmor: An Additional Layer of Defense

Oh, I was under the impression that NVT wanted feedback from us users. NVT, please just say so if we are starting to overdo it...

 

Andreas will certainly satisfy everyone.
In Italy there is a proverb that reads:

"Il troppo è troppo"

which indicates the negativity of any excess.
dates back to the 19th century in a collection of Tuscan proverbs preserved by the "Accademia della Crusca" that reads like this:

TH to all.

 

So am I - for having to read such off-topic comments.

 

I don't know what was happened but at present I can't instal OSA...every installation generates system alert no matter which version and from where (folder nad disk) is launched
Some suggestion?
On Vista even with SSFW disabled

 

I have noticed that OSArmor causes MalwareBytes Anti-Exploit to uncheck the settings options for RET ROP Gadget detection (32 and 64bit) for NON-Chrome Browsers. This effect remains after OSArmor has been uninstalled. I do not remember this occurring before OSArmor was first installed when the settings options for RET ROP Gadget detection (32 and 64bit) for NON-Chrome Browsers would remain unchanged (except when MBAE was updated and they required resetting afterwards).

This hints at a need for an uninstaller tool because I suspect that something has been left behind after doing the regular uninstall and needs cleaning up.


I guess that there is no problem since it also occurs (mysteriously) on a system on which OSArmor has never been installed. I therefore consider it unconnected to OSArmor.

 

Is there any possibility that OSA (test30), on default settings, could interfere with windows updates?

I mention this because on one machine I ran KB4058258 (downloaded from MS catalog, WU did not find it) to update Win10 Pro x64 from build 16299.192 to 214, but it rolled back during the update restart.

After uninstalling OSA (to install test32), tried again and update worked. Could just be a coincidence.

 

I got an automatic windows 10 update today, but at first all I saw was block messages from Appguard, because I had powershell totally disabled.
So I removed powershell from user space (but ticked it in guarded apps), and then the update ran.
Moral of story: there was a powershell script involved with this update. Wish I knew more than that.

 

Did this problem start with test build 30? Just curious.

 

.

I see there is protection against Powershell encoded and malformed commands, but under advanced tab, Powershell is unticked by default ... wonder if an 'encoded command' was involved ...

(OT: btw on machines with AppGuard I do normally set this to install mode during Windows updates, but actually I have been through same AG settings changes back to default, mainly because some Lenovo crapware, which I should probably have removed, also uses Powershell).

 

I have most of the OSA advanced settings ticked, including the powershell ones, and the update still ran, but I had OSA disabled for the first part of the process. The automatic update seemed to take place in a few stages. Once I got past the first stage, I turned my security softs back on.

 

Truth is, Andreas says that OSA is hardcoded to allow windows update processes, even if they do stuff that would be blocked when done any other process. So if no one else writes in with sad stories about the recent Windows 10 update, I would take OSA off the list of suspects.

 

Here is a new v1.4 (pre-release) (test33):
http://downloads.novirusthanks.org/files/osarmor_setup_1.4_test33.exe

*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***

So far this is what's new compared to the previous pre-release:

+ Block execution of Java
+ Fixed cosmetic GUI issue (Anti-Exploit listbox aligned)
+ Improved detection of suspicious folders
+ Improved detection of suspicious processes
+ Improved detection of suspicious command-lines
+ Improved detection of commands used to download remote files
+ Improved detection of PowerShell encoded commands
+ Improved detection of PowerShell malformed commands
+ Improved detection of PowerShell ExecutionPolicy Bypass
+ Improved detection of PowerShell WindowStyle Hidden
+ Configurator can have only a single instance running
+ Removed "Enable Passive Logging" option from the Configurator
+ Passive Logging can be enabled\disabled via tray icon
+ Block execution of any process related to Sysinternals
+ New method to detect suspicious processes
+ Prevent cmd.exe from executing powershell.exe
+ Categorized options in Advanced tab
+ Fixed some false positives

To install it, first uninstall the previous build, then reboot (not really needed but may help), and install the new build.

Feedbacks and suggestions are always welcome

We're very near to the official v1.4 release, if you find any FP or issue please share them.

@mood

Thanks for the feedbacks!

a) b) c) f) should be fixed in build 33.

Now it is much easier to switch to Passive Logging via the tray icon.

Have saved the other suggestions.

@plat1098

I don't know, probably they use some heuristic engines that caused that FP to come up.

@rdsu @guest @shmu26 @paulderdash

Yes, we should add PotPlayer, MPC Black Edition and uTorrent (and others) on the next build.

Will need to check SMplayer, Foobar2000 and MusicBee.

@shmu26

We can change the icon to a almost total gray color.

@ichito

Looks like that you have a program or a SRP rule that blocks execution of executable files in Temp folder.

Is that happening with other installers too?

@loungehake

That's strange, OSA should not interfere with other program's settings.

Did you check OSA logs to see if something was blocked?

@paulderdash

I updated Windows 10 many times so far with OSA running and had no issues.

Should work fine as long as you have the option "Enable internal whitelist rules" enabled.

 

+ Block execution of any process related to Sysinternals.

Does this mean that any tools from Sysinternals will be blocked from running? If so, why?

 

It was requested by a company so we have added it (unchecked by default).

They asked to block execution of Sysinternals psexec.exe and other few tools.

Maybe we can change it to something like "Block execution of psexec.exe from Sysinternals".

 

ok, thanks.

 

Thanks

If Autoruns (Autoruns.exe/Autoruns64.exe - 'Sysinternals Autoruns') has been started and the user doubleclicks on "C:\Users\****\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" in the category "Logon", launching of explorer.exe is blocked:

Code:

Date/Time: 06.02.2018 23:10:20
Process: [5592]C:\Windows\explorer.exe
Parent: [11208]C:\*\Autoruns\Autoruns.exe
Rule: BlockCmdlineThatMatchesStartupFolder
Rule Name: Block command-lines that match *\Start Menu\Programs\Startup\*
Command Line: C:\WINDOWS\explorer.exe /select,C:\Users\****\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Signer: Microsoft Windows
Parent Signer: Microsoft Corporation

 

Um, is...+ Block execution of any process related to Sysinternals...literal. I can launch Sysinternals Tools ..e.g., procexp.exe, autoruns.exe, tcpview.exe.

 

I don't think it is literal. Try running psexec.exe.

Andreas suggested in #964 to changing the wording to blocking that file specifically:

 

Okay, rule specific to psexec.exe. PsTools are over-my-pay-grade. Thanks

 

@mood

Will fix that FP on the next build, thanks.

@bjm_

Yes it is blocking psexec tools (I will change the name of the rule).

The company that asked for this rule shared these links:

Psexec flagged as malware by Sophos

Analyzing the Fileless, Code-injecting SOREBRECT Ransomware

HC7 GOTYA Ransomware Installed via Remote Desktop Services. Spread with PsExec

Would anyone benefit from blocking ALL Sysinternals tools?

Else we can just update and rename the rule to "Block execution of psexec.exe from Sysinternals".

Another question to all of you guys, is anyone having the 30000 ms timeout with OSArmorDevSvc on Event Viewer?

"The timeout (30000 ms) was reached when attempting to connect to the NoVirusThanks OSArmorDevSvc service."

 

I hope that was in jest or rhetorical?

"Would anyone benefit from blocking ALL Sysinternals tools?"

Not me. I use one of their or Nirsoft tools nearly every day.

I guess keeping it an an option off by default .....

 

Re: timeout issue: Yes, I got this error a couple of times, with different builds. Also happened to notice by accident that the icon was gray with protection disabled and no notification that OSArmor was disabled.

Spoiler

 

Would anyone benefit from blocking ALL Sysinternals tools?

A lot of us use these tools quite frequently so I can't see anyone on here benefiting from it.

 

The alternative would be to only block all "PSTools" [this includes PsExec] and other "dangerous" Sysinternals tools (instead of blocking all tools)
Edit: Perhaps this can be done with "Nirsoft Utilities" too (only specific tools are blocked, not all tools)