Do we actually need so many security programs?

[509322]

Could you explain this point a little more? Are you talking just about script files, or does TAM block also scripts passed in memory to interpreters?

TAM just blocks low reputation and unknown files.

TAM will block a file and then Application Control will move it to the Low Restricted, High Restricted or Untrusted group. So, a file can be sent to Low Restricted based upon Application Control, but it is prevented from launching by TAM and the toggle switch is set to Block.

It appears to me Kaspersky is relying upon AMSI and other protection mechanisms to deal with in-memory attacks. @Andy Ful might be right about how Kaspersky's engineering optimized KIS. However, it is difficult to know for sure without knowing the signatures, heuristics, KSN, Application Control as well as the rest of the modules and how they all work together.

Anyone who gets the jist of things won't place a whole lot of trust in AMSI, ASR and other rules-based protections.

You have to disable the interpreters and sponsors to decisively protect against in-memory only stuff.

 

[Andy Ful]

I managed to block wscript.exe in KIS. I ran manually wscript.exe an then found it on running applications list in KIS - the filter view must be changed to show system files. Then I could set it to block via right click Explorer context menu. But, I do not recommend to block wscript.exe in this way, because after blocking, I could not find it to change the setting. I do not know, maybe I missed something.
Anyway, most users will have problems with blocking/unblocking wscript.exe in KIS.
There should not be problems with the setting 'High Restricted'.

Post edited twice (thanks to @shmu26 and @Lockdown ).
Follow the below link for details:
Discuss - Do we actually need so many security programs?

 

[shmu26]

I managed to block wscript.exe in KIS. I ran manually wscript.exe an then found it on running applications list in KIS - the filter view must be changed to show system files. Then I could set it to block via right click Explorer context menu. But, I do not recommend to block wscript.exe in this way, because after blocking, I could not find it to change the setting. I do not know, maybe I missed something.
Anyway, most users will have problems with blocking/unblocking wscript.exe in KIS.
There should not be problems with the setting 'High Restricted'.

1 processes will not appear on the list until they have been run at least once
2 you need to show system files, and also expand the list.
3 if you block a file, it will appear in the tab of blocked files.

 

[bribon77]

@Andy Ful..I owe you three €

 

[Andy Ful]

How to block the Windows script interpreters in KIS:

1. Open Kaspersky >> Settings >> Protection >> Application Control >> Manage Applications.
2. Right-click the 'Untrusted' group and choose the option "Add application to group"'.
3. Find and open wscript.exe from the folder c:\windows\system32.
4. You will see the new entry "Microsoft Windows Based Script Host" (Blocked).
5. For 64-bit Windows, find and open also wscript.exe from c:\Windows\SysWOW64.

How to unblock:

1. Open Kaspersky >> Settings >> Protection >> Application Control >> Manage Applications
2. Expand the 'Untrusted' group.
3. Delete all "Microsoft Windows Based Script Host" entries.
4. Do not use the toggle to change the option from Blocked to Allowed - this will not unblock the application from 'Untrusted' group.

Add in the similar way the executables cscript.exe, powershell.exe, powershell_ise.exe, and mshta.exe. The entries: "Microsoft Console Based Script Host'", "Windows PowerShell", and "Microsoft (R) HTML Application host" will be added with the 'Blocked' setting.

There are also other interpreters like hh.exe, scrcons.exe, etc. But, they are rarely used.

Post edited and optimized thank to @Lockdown suggestion.

 

[509322]

I managed to block wscript.exe in KIS. I ran manually wscript.exe an then found it on running applications list in KIS - the filter view must be changed to show system files. Then I could set it to block via right click Explorer context menu. But, I do not recommend to block wscript.exe in this way, because after blocking, I could not find it to change the setting. I do not know, maybe I missed something.
Anyway, most users will have problems with blocking/unblocking wscript.exe in KIS.
There should not be problems with the setting 'High Restricted'.

Post edited (thanks @shmu26). Follow the below link for details:
Discuss - Do we actually need so many security programs?

@Andy Ful - add PowerShell, wscript and cscript to High Restricted. Then launch them. Watch what happens with HIPS and firewall alerts. Typical user will be like "Wut ?" when the alerts appear. They will be overwhelmed. "Wut does this mean ?" "Wut should I do ?" "Huh... wut !!???"

The user is better off manually adding PoSh, wscript and cscript in both System32 and SysWOW64 to the Application Control list and setting the toggle to OFF.

A program does not need to be run manually in order for it to be added to Application Control.

To add manually you simply right-click on the Group Name header in Application Control > Add application to group > and then browse to the program to be added.

What a user will find confusing are the Application Control icons and icon color changes... LOL.

KIS is one of those security softs where the user isn't going to get the most out of it unless the user tweaks it. And the user isn't going to effectively tweak it unless they tinker\practice with it to learn and understand how it works.

 

[Andy Ful]

@Andy Ful
...
To add manually you simply right-click on the Group Name header in Application Control > Add application to group > and then browse to the program to be added.
...

Thanks. I edited and optimized the instructions from my previous post.

 

[harlan4096]

Not much to say, all exposed by @Andy Ful & @Lockdown are correct...

Some months ago I was posting malware results with KTS with TAM enabled, and it was very strong blocking unknown malware, also scripts... in some cases scripts were blocked just because unknown (TAM) and in others apart to be blocked by TAM were also detected by Heur, KSN, AMSI or signatures...

As @Lockdown said, if You move all those interpreters to Low/High Restricted and the user is in Interactive Mode, probably a ton of warnings/isues will come many due to some bugs in Application Control...

And I agree, default Mode/Settings of KIS/KTS are weak, but proper for standard users to manage/install and forget... but just enabling Interactive Mode (with those defaults settings) will improve enormously the prevention, because all those "Prompt for Action" in Low Restricted, for example, that are allowed in Auto Mode will get active in Interactive, but We found here the handicap of HIPS products, the users have to answer correctly to those warnings...

Any of the defaults rules/rights for trusted groups can be tweaked with own and strong rules, and as @Lockdown pointed, You don't need to run once an application or executable, dll, etc. to appear in the AC, You can add it manually to a specific restriction group easily before run it for the 1st time...

KIS is one of those security softs where the user isn't going to get the most out of it unless the user tweaks it. And the user isn't going to effectively tweak it unless they tinker\practice with it to learn and understand how it works.

Agree, also there is no much/proper information/features about how to use/tweak it, and the same about TAM and/or working in relation with the others protections modules: Application Control, System Watcher, etc.

 

[shmu26]

in some cases scripts were blocked just because unknown (TAM)

Does TAM block unknown command lines passed in memory to script interpeters? Or it only blocks files, such as .bat, .js, etc?

 

[harlan4096]

I don't think so TAM is not a real Default-Deny solution, also it is not so customizable than other solutions...

A bit obsolete article, still valid, but probably some things have changed since it was published:

Securelist | Computing Securely: The Trusted Environment Concept

 

[shmu26]

I don't think so TAM is not a real Default-Deny solution, also it is not so customizable than other solutions...

A bit obsolete article, still valid, but probably some things have changed since it was published:

Securelist | Computing Securely: The Trusted Environment Concept

Thanks for all the explanations, harlan. So to accomplish what @Lockdown is aiming for, it would be necessary to block selected system processes, even if TAM is enabled. Alternatively, to place those processes in a lower trust category, and enable Interactive mode.

 

[harlan4096]

Well, Interactive is not necessary probably if You set rights/rules to Block/Deny, but if You want also prompts, then Interactive

 

[509322]

Thanks for all the explanations, harlan. So to accomplish what @Lockdown is aiming for, it would be necessary to block selected system processes, even if TAM is enabled.

Yes. Disable usual suspects. This is what I do.

Alternatively, to place those processes in a lower trust category, and enable Interactive mode.

Not advisable due to the HIPS alerts. I don't use Low or High Restricted because of the alerts.

 

[Andy Ful]

I am not a fanboy of KIS (do not use it), but it is worth paying. It has a very good security design and capabilities. The Application Control module is more like Applocker than SRP. I tested KIS only one day and only against a narrow spectrum of scripts. But, it seems that even with such a good AV, a lot can to be done to improve the dynamic script detection.
For the most of home users, regardless of adopted AV, the best solution will be simply blocking Windows script execution.
The downside of doing it via something like Application Control or Applocker, is that all script execution will be blocked (the blocked script interpreters cannot work). If the user has a hardware/software that uses particular script, then more usable and flexible would be blocking the script execution via SRP solutions, which allow whitelisting of particular scripts.

 

[Moonhorse]

Its nice to know that bitdefender free has the ATP of paid product, about to install it but doesnt fit quite well with cf

Still easier to disable powershell + script hosts than rely on any avs post protection

 

[509322]

Its nice to know that bitdefender free has the ATP of paid product, about to install it but doesnt fit quite well with cf

Combining an AV with COMODO just isn't needed, but it is "fashionable" on the forums.

Still easier to disable powershell + script hosts than rely on any avs post protection

Exactly. You can disable them in COMODO if you wish with the appropriate sandbox rules.

 

[509322]

I am not a fanboy of KIS (do not use it), but it is worth paying. It has a very good security design and capabilities. The Application Control module is more like Applocker than SRP. I tested KIS only one day and only against a narrow spectrum of scripts. But, it seems that even with such a good AV, a lot can to be done to improve the dynamic script detection.
For the most of home users, regardless of adopted AV, the best solution will be simply blocking Windows script execution.
The downside of doing it via something like Application Control or Applocker, is that all script execution will be blocked (the blocked script interpreters cannot work). If the user has a hardware/software that uses particular script, then more usable and flexible would be blocking the script execution via SRP solutions, which allow whitelisting of particular scripts.

KIS does not alert the user when something they have disabled is blocked. Therefore, the user has no way of researching what has happened via alerts or a log. Application Control log does not record the blocking of user-disabled processes.

AppGuard alerts and logs when something is blocked that the user has disabled.

It is a convenience that goes a long way in troubleshooting when there is some breakage.

Anyway, KIS offers a high security for those who are willing to put in a little bit of effort to learn how it functions and to use it properly (by locking-down their system and not constantly installing new softs and not introducing new stuff to their system will-nilly as they want, despite Kaspersky saying this is OK... because it definitely isn't OK).

The one thing that has to change is user behavior. If the user behavior does not change, nothing will change.

Security softs cannot protect users from themselves.

 

[imuade]

With the approach Microsoft has been using for Windows 10, compatibility is a big concern, so I have decided to use the built-in security SWs (Windows Defender and Windows Firewall) and 3rd party SWs that use built-in features (ConfigureDefender, NVT SysHardener, Re:HIPS)

 

[509322]

With the approach Microsoft has been using for Windows 10, compatibility is a big concern, so I have decided to use the built-in security SWs (Windows Defender and Windows Firewall) and 3rd party SWs that use built-in features (ConfigureDefender, NVT SysHardener, Re:HIPS)

Because Windows 10 is now a perpetual beta, breakages and conflicts are Microsoft's doing and not anyone else's.

A soft such as ours, we rarely have any issues with Microsoft upgrades\updates. However, for other 3rd-party softs such as Sandboxie, it is an ongoing struggle.

Not to mention that Microsoft just keeps piling more and more unneeded garbage onto Windows. The more crap it packs into Windows, the more things to go wrong.

But let's not forget Microsoft's first priority... to make Windows efficient for Microsoft, and not anyone else.

 

[shmu26]

With the approach Microsoft has been using for Windows 10, compatibility is a big concern

Indeed, after running the Hard_Configurator tool to reveal autoruns, I got this result, on Windows 10 1809:
SCRIPT AUTORUNS REPORT DATE (Y:M H:M): 2018:11:05 10:35
@@@@@ Script Autoruns:
c:\windows\system32\gathernetworkinfo.vbs

It's a VBS script run by Windows, with system privileges. It will not be blocked by SRP or by ReHIPS, because it is run by SYSTEM, but it will be blocked by some other solutions.