NoVirusThanks OSArmor: An Additional Layer of Defense

This was mentioned a few days back. I would like to mention it again. The popups I receive are so fast and pale I usually don't seen them in time to react accordingly. Can this be fixed....please?

 

In case you didn't see it, #732.

 

@novirusthanks What is OSA? Is it a Anti-Exe, SRP, or BB? Would it be overkill to use it with either Avast or Emsisoft Anti-Malware?

 

This is what shmu26 said over MT community...

 

Thanks bjm_

 

#750 @buddle

Try this very easy and basic rule for OSArmor exclusions?

Code:

// EPSON printer rule!
[%PROCESSCMDLINE%: *E_FARNCDE.EXE*]

 

Helpful..Thanks

 

It didn't work, BUT: it has definitely pointed me in the right direction. I added the following rules:
[%PROCESSCMDLINE%: *E_FARNCDE.EXE*]
[%PROCESSCMDLINE%: *E_FPRECDE.EXE*]
[%PROCESSCMDLINE%: *E_FAMTCDE.EXE*]
No more popups. Thank you very much for your help, @BlackBox Hacker

 

#758 @Rainwalker

Thank you @Rainwalker!

 

#759 @Buddel

It also looks like OSArmor Build 26 Software has some very bad bugs below!

 

@Buddel

We have drastically reduced CPU usage on build 27, will upload it in a few days.

Will be fixed on build 27, thanks for sharing.

For now I would recommend you to use these exclusion rules:

Code:

[%PROCESS%: C:\Windows\System32\spool\drivers\w32x86\3\E_FPRECDE.EXE] [%PARENTPROCESS%: C:\Windows\*]
[%PROCESS%: C:\Windows\System32\spool\drivers\w32x86\3\E_FAMTCDE.EXE] [%PARENTPROCESS%: C:\Windows\*]
[%PROCESS%: C:\Windows\System32\spool\drivers\w32x86\3\E_FARNCDE.EXE] [%PARENTPROCESS%: C:\Windows\*]

Do not use only %PROCESSCMDLINE% as it is unsafe, you should include also %PROCESS% var if you want to match process cmdline.

Here is an alternative one-line exclusion rule:

Code:

[%PROCESS%: C:\Windows\System32\spool\drivers\w32x86\3\E_????CDE.EXE] [%PARENTPROCESS%: C:\Windows\*]

@rdsu

Thanks for posting the FP, it'll be fixed on build 27.

@Djigi

We'll add a button "Select All" and "UnSelect All" on tab "Main Protections", "Anti-Exploit", "Advanced".

@Circuit

Yes, agree.

@jimb949 @Rebsat

OSA is a process-BB-like and SRP-like (hybrid).

Since OSA allows you to apply many protection options and restrictions, you may use it with Avast and EAM (make sure to exclude OSA on their HIPS).

With OSA you can easily block execution of scripts, block specific processes or processes behaviors, mitigate specific malware attacks, and much more.

It is lightweight and uses just 15 MB of memory, it would not hurt to have it aboard.

 

@novirusthanks

If I were to run Cryptoprevent (SRP) along with OSA could there possibly be any policy conflicts?

 

So, for example >
Process: [4432]C:\Windows\System32\cmd.exe
Parent: [1796]C:\Windows\System32\igfxCUIService.exe
Rule: BlockBATScripts
Rule Name: Block execution of .bat scripts
Command Line: C:\WINDOWS\system32\cmd.exe /c "C:\WINDOWS\system32\{A6D608F0-0BDE-491A-97AE-5C4B05D86E01}.bat"
Signer:
Parent Signer: Intel(R) pGFX

Use ? >
[%PROCESSFILEPATH%: C:\Windows\System32\cmd.exe] [%PROCESSCMDLINE%: C:\WINDOWS\system32\cmd.exe /c "C:\WINDOWS\system32\{A6D608F0-0BDE-491A-97AE-5C4B05D86E01}.bat"]

Or, use ? >
[%PROCESS%: C:\Windows\System32\cmd.exe] [%PROCESSCMDLINE%: C:\WINDOWS\system32\cmd.exe /c "C:\WINDOWS\system32\{A6D608F0-0BDE-491A-97AE-5C4B05D86E01}.bat"]

I've been using ... only >
[%PROCESSCMDLINE%: C:\WINDOWS\system32\cmd.exe /c "C:\WINDOWS\system32\{A6D608F0-0BDE-491A-97AE-5C4B05D86E01}.bat"]

My Logs include Process: and Parent: while the Exclusions GUI has
Process:
Process Path:
Parent Process:
Parent Process Path:
So, when to use Process vs Process Path and when to use Parent Process vs Parent Process Path?

 

Charyb- why would you want to use CryptoPrevent on purpose?

 

I won’t but I just want to know if, somehow, a program like Cryptoprevent, or any other program, can modify/remove any of OS Armor protections (SRP, etc.) or is there a mechanism in place that prevents this?

I ask this after Andreas mentioned BB-like/SRP-like hybrid.

It’s probably already been asked but often times I’m a little late to the party.

 

An interesting question. I severely doubt that any other SRP based applications would actually remove any Policy already in place; at the most there would be a duplication so as such would be inconsequential. Behavior Blockers certainly should not be an issue at all. But specifically regarding CP, in addition to the policy based protection there is the addition of Folder watch (I guess this means that one can watch as files get encrypted) as well as the HoneyPot "technology"- the latter although being effective in the past is quite easily bypassed today..

No hijack of this thread was intended.

 

Cruelsister, do you have any safe rules in mind that would allow OSArmor to block .dlls, and prevent code injection? NoVirus Thanks is very hesitant to block .dlls due to the potential problems it can cause.

 

Thank you very much, @novirusthanks . Looking forward to test build 27.

 

For loyalty reasons I do still have CP (on the same machine where I am testing OSA) without noticeable issues, but I am sure it is redundant now. They just updated to v9 ...

 

No, I personally don't and such a blanket rule(s) would be difficult to implement due to the issues (potential problems with legit applications) that may be caused.

I do think that one shouldn't attempt to make OSA into something that It is not and never should be. OSA is certainly a very clever application that can stop various types of malware simply and effectively. For instance other threads on Wilders had folks wondering on how to stop things like Powershell, VB scripts, JScripts, etc from running. OSA makes these things easy by just the checking of a box. However any attempt to be cute and stop malicious mechanistic pathways of all malware is doomed to failure. Yeah, one can stop dll malware by doing something like putting a preclusion on rundll32- but try to install a legit application with that in place! Another example is something I brought up in a post a few days ago- having a restriction on msiexec.exe will prevent a fine app like M Network Monitor from installing.

When I made the quickie on OSA last week the theme was what it does (blocking worms, PS scripts, and JScript downloaders is no small thing); the files I added in that bypassed the protection were not included as a criticism but instead to point out the need for primary protection like your (Ugh...) AV.

Far too many promising security applications have destroyed themselves by attempting to morph from their intended purpose- as a Supplement to Primary Protection- to a actual primary defense. What happens then is a plethora of FP's and blocked legit applications; and a product that will detect everything in reality detects nothing.

OSA in its present form is a very clever and elegant product and should be appreciated for what it is.

 

Paul- (once again hijacking the thread)- although I haven't played to a great extent with CP9 yet, it seems to be carrying though the same flaws from previous versions. I really do dislike the honeypot addition. In the past this would be fine against stuff like Tesla which would attack the low hanging fruit first, thus giving a security product time to react and block, but current ransomware that I personally term Fast Encryptors will attack everything simultaneously, separately but equally making a mockery of this form of protection.

 

Hi @cruelsister , what about the combo OSArmor + AppCheck?
Thanks

 

Thank you for your thoughts, and explanation! I was just wondering what your opinion was on blocking .dlls, and code injection. You have fully answered my question.

 

Not all of the DLL Code Injections use that 'rundll32.exe' process you can also do command line confusion exploits, I was thinking that process should be blocked, but then disable or use an 'install mode' for installing any other trusted software you trust only. Also that 'rundll32.exe' process can exploit screensaver exploits from binary files using other forms of DLL code injections or process injections from any unknown binary files.