NoVirusThanks OSArmor: An Additional Layer of Defense

@Compu KTed From v1.5

 

Well, here is a new development in security by Microsoft. This is discussed here:

https://malwaretips.com/threads/def...-with-new-vulnerable-driver-blocklist.113007/

and concerns the Microsoft Vulnerable Driver blocklist. Clearly, this supersedes Secure Boot and Core Isolation in Windows 10 and 11. Can/will OSArmor have a parity with this new application? It seems it would only deal with the payload, then?

My question is based on the hoops you have to jump thru to get this active on a Windows Home device. Currently it seems fairly straightforward on paid Windows versions.

Thanks for any insights. Even though Home users are farther down on the threat ladder than Enterprise, it doesn't hurt to check into it, esp. nowadays.

 

If you read the Microsoft article: https://docs.microsoft.com/en-us/wi...trol/microsoft-recommended-driver-block-rules on this driver protection feature, it is already active on any Win 10/11 device where HVCI has been enabled. The Microsoft driver block list only needs to be deployed via WDAC if HVCI can't be enabled for some reason.

-EDIT- Every effort should be made in enabling HVCI. It stopped a real nasty malware I had a while back "dead in its tracks." Assumed here is it was driver based.

One thing I discovered on my PC is if you try to overclock your memory via BIOS memory clock hack; i.e. 1333 to 1600, and your MB bus speed is 1333, HVCI - memory integrity - won't enable.

 

Thanks, itman. HVCI (which is Core Isolation/Memory Integrity, correct?) is- and has been- enabled on here. I don't want to go off-topic in this thread so I'll continue the discussion in the Windows Defender thread.

 

@novirusthanks is there a way to craft a rule that would allow me to run winget.exe from the command line and have applications update itself via script? I can get the scripkit to run, but the apps themselves that winget.exe finds do not update. I'm not presented with any exclusion prompt either.

 

Correct. Also to be technically correct, HVCI is Hypervisor Code Integrity which contains two components:

1. Core isolation which is enabled by default on every Win 10/11 installation.
2. An additional mitigation setting, memory integrity.

I am assuming that MS in the above linked article is referring to full Hypervisor Code Integrity protection being enabled; which means memory integrity also being enabled.

Ref.: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-hvci-enablement

-EDIT- I will also add that Microsoft Vulnerable Driver blocklist is no substitute for Secure Boot protection. All MS is doing is blocking known malicious drivers. All major AV's these days employ the MS ELAM driver. This allows them to inspect all non-device drivers prior to their loading.

Also did a review of the Microsoft Vulnerable Driver blocklist and a lot of them appear to be device drivers. As such, it complements ELAM driver scanning since it can't scan device drivers.

 

After doing some testing seems OSArmor versions 1.5.4 and 1.5.6 will also
run on C++ 2013 Redistributable (x86)

 

i have a
false positive

Date/Time: 29-3-2022 18:55:49
Process: [17548]C:\Windows\SysWOW64\schtasks.exe
Process Size: 197,5 KB (202.240 bytes)
Process MD5 Hash: F37CBAFEF5B8D109890FED78F1D7FC4D
Parent: [8484]C:\Windows\SysWOW64\cmd.exe
Parent Process Size: 245 KB (250.880 bytes)
Rule: BlockSuspiciousCmdlines
Rule Name: Block execution of suspicious command-line strings
Command Line: schtasks /create /xml "C:\ProgramData\Adguard\config-a39611c495c24a49ad530cb5734a7556.xml" /tn a39611c495c24a49ad530cb5734a7556 /f
Signer: <NULL>
Parent Signer: <NULL>
User/Domain: Denis/DESKTOP-TP3IBRB
System File: True
Parent System File: True
Integrity Level: Medium
Parent Integrity Level: Medium

 

@denis

Thanks for reporting it, however we can't create an "universal" exclusion because the parent process is not AdGuard (how it should be, if possible) but is cmd.exe.

I guess that AdGuard spawns cmd.exe and then cmd.exe spawns schtasks.exe, would have been better if it could be AdGuard.exe -> schtasks.exe

You need to create a custom exclusion rule, just add this line in the Exclusions.db of OSArmor:

Code:

[%PROCESS%: C:\Windows\SysWOW64\schtasks.exe] [%PARENTPROCESS%: C:\Windows\SysWOW64\cmd.exe] [%PROCESSCMDLINE%: schtasks /create /xml "C:\ProgramData\Adguard\config-a39611c495c24a49ad530cb5734a7556.xml" /tn a39611c495c24a49ad530cb5734a7556 /f]

To do so, right-click on OSArmor icon in the system tray, click on Manage Exclusions, on the new window click on Open Exclusions and add the above line, save and exit notepad.

Let me know if that works.

 

Ok, Thanks.working

 

Here is a pre-release test 7 for OSArmor Personal v1.6.9:

Code:

https://downloads.osarmor.com/osa-personal-1-6-9-setup-pre7.exe

This new test version fixes the issue reported by itman.

 

@plat1098 , looks like I was wrong in my assumption that only memory intriguing needs to be enabled to activate Microsoft Vulnerable Driver blocklist. Bleepingcomputer just published an article on this topic: https://www.bleepingcomputer.com/ne...s-security-feature-blocks-vulnerable-drivers/. Although it's "not crystal clear" in that article, it appears that Application Guard needs to be enabled and then the option will appear in MS Security Center Device security section. However, you might also have to have a TPM installed on the motherboard. Since I have Win 10 Pro, I will activate App Guard and see if the option appears.

 

Thanks alot for the link, @itman. Appreciate it.

 

Can anyone tell me what they think of these blocks? I have two PreventImportantSystemModifications blocks. One on the latest update to Samsung Magician and the other when installing Avid's Pro Tools First software.

Date/Time: 31/03/2022 9:57:38 am
Process: [9356]C:\Windows\SysWOW64\icacls.exe
Process Size: 29.5 KB (30,208 bytes)
Process MD5 Hash: BFB9C0A36D14BEFA10AC1A9E8AE6C6C2
Parent: [6772]C:\Windows\SysWOW64\cmd.exe
Parent Process Size: 245 KB (250,880 bytes)
Rule: PreventImportantSystemModifications
Rule Name: Prevent important system modifications
Command Line: "C:\Windows\System32\icacls.exe" "Samsung Magician" /t /q /c /reset
Signer: <NULL>
Parent Signer: <NULL>
User/Domain:
System File: True
Parent System File: True
Integrity Level: High
Parent Integrity Level: High


Date/Time: 31/03/2022 10:14:28 am
Process: [14852]C:\Windows\System32\attrib.exe
Process Size: 40 KB (40,960 bytes)
Process MD5 Hash: 0420D87873EE523238D549AF56014C16
Parent: [7948]C:\Windows\System32\cmd.exe
Parent Process Size: 324 KB (331,776 bytes)
Rule: PreventImportantSystemModifications
Rule Name: Prevent important system modifications
Command Line: attrib.exe +H C:\AvidDownloads
Signer: <NULL>
Parent Signer: <NULL>
User/Domain: SYSTEM/NT AUTHORITY
System File: True
Parent System File: True
Integrity Level: System
Parent Integrity Level: System

 

Anyone on the above? Are these blocks serious? What do they mean?

 

@Graphite85

They are not malicious, you can exclude them.

The FPs will be fixed on the next version.

An explanation is below:

Code:

Command Line: "C:\Windows\System32\icacls.exe" "Samsung Magician" /t /q /c /reset

It uses icacls.exe to modify (reset) permissions of "Samsung Magician" folder:
https://docs.microsoft.com/en-US/windows-server/administration/windows-commands/icacls

Code:

Command Line: attrib.exe +H C:\AvidDownloads

It uses attrib.exe to change attributes (hidden) of C:\AvidDownloads folder:
https://docs.microsoft.com/en-US/windows-server/administration/windows-commands/attrib

 

@novirusthanks

Thanks for the clarification and detailed explanation.

 

@novirusthanks

To add as exclusions do I only need to add the command lines in the exclusion?

 

If my assessment and syntax for the Exclusion rules is correct, I think for the first block alert you'd end up with this:

 

Is there a way to log the changes made to the system (via registry and/or group policy) to know what aspects of the OS the program has altered? I am liking the "medium" setting as of now, but have yet to play with OSarmor any further, but I'm a bit OCD and like to know what tweaks are taking place where. Other than that, it's been very light weight and hassle free thus far

EDIT: Never mind, I found the settings log folder which reflects the alterations to the registry.

 

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

Here is the changelog:

Code:

+ Fixed all reported false positives
+ Added new internal rules to block suspicious behaviors
+ Improved the pre-filled text of exclusion rule when button "Exclude" is clicked
+ Updated NVT License Manager with latest version
+ Added more signers to Trusted Vendors list
+ Added support for a dark theme if Windows Dark Mode is enabled
+ Minor improvements

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

// Everyone

If you are running the test builds please update to this final version.

@Graphite85

The exclusion rule provided by @wat0114 is fine, just replace this [%Signer%: <NULL>] with [%SIGNER%: <NULL>]

The variable name %VAR% needs to be always in uppercase.

My personal suggestion is to always match more process fields, such as process + parent process + command-line + signer.

PS: On this latest version v1.6.9.0 the false positives you reported have been fixed.

@bberkey1

Yes in the .log reports you can find the registry value of the rule, i.e:

Rule: BlockSuspiciousProcesses
Rule Name: Block execution of suspicious processes

The registry value is BlockSuspiciousProcesses.

If a process is blocked by a custom block rule, you will see this in the .log file:

Rule: CustomBlockRule
Rule Name: Custom process-block rule via CustomBlock.db

In this case CustomBlockRule is not present as registry value.

 

Thanks for the new version. Running smoothly here, as always.

 

No problems after automatically updating here. Thanks @novirusthanks !

 

@novirusthanks,
Windows 10 21H2
Yesterday (April 6) OSA self updated to v1.6.9. Notified it updated.
I see that my firewall is blocking Licence Manager outbound to local host. It hasn't done that in the previous version. Or I didn't notice. Or perhaps it just happens around installation time.
Explorer says version is 1.0.0.0 created in January, modified March 28. Is all that correct?
I just allowed the local host job, but would like to hear your comments.

 

@act8192

That is all normal behavior by OSA and our license manager, the local connections by the license manager are generally performed at install/update time and occasionally on license checks/activation time. The product version of the service of NVT License Manager will not change (should be always v1.0.0.0), what will change is only NVTActivator.exe product version (this is done by design). Same is for OSA, product version is changed only on OSArmorDevUI.exe Hope that helps.