Intrusion Prevention exclusions not working as expected

[trip2teea]

Hello.

When building any C++ project with pre/post build event actions, MSBuild is creating temporary cmd files to run these actions.
These cmd files have random name every build and are located at: %localappdata%\Temp\MSBuildTemp

One of my projects have pre-build event which does some stuff to prepare for the build.
Every time I build my solution and this specific project, MSBuild creates new cmd file and Kaspersky asks my permission to grant this cmd a low-level disk access.
Problem is that I cannot whitelist/trust this cmd specifically, it is different cmd file every time.

However, the run sequence looks like this:
Windows Logon Application > Windows Explorer > {My IDE processes} > MySolution.sln > {Randomly generated name}.exec.cmd
This {Randomly generated name}.exec.cmd is located at %localappdata%\Temp\MSBuildTemp

So I thought that maybe I can whitelist MySolution.sln in this case. It is recognized by Kaspersky as unique application/process, so it is displayed in Application list and I can configure Application Rules for VS solution (MySolution.sln). That's what I did so far:

• Added MySolution.sln to Trusted applications category in "Intrusion Prevention settings -> Manage applications"
• Added MySolution.sln to Trusted applications in "Advanced security settings -> Exclusions and actions on object detection -> Specify trusted applications"
• Made sure that it has permissions to "Perform low-level access to disk"
• Enabled these exclusions:
  • Do not scan files before opening
  • Do not monitor application activity
  • Do not monitor child application activity
    • Apply exclusion recursively
  • Do not inherit restrictions from the parent process (application)

From my understanding "Do not monitor child application activity" + "Apply exclusion recursively" should make Kaspresky to ignore these temporary cmd files generated by MSBuild, but it doesn't, I still get prompted every time I build my project.

Is there something I can do about it?

Would be nice if it was possible to whitelist applications located at certain paths (similar to how we can exclude folders by path mask) and do it not just globally, but also for computer resources specified in Intrusion Prevention settings.

My winver: Windows 11 23H2 22631.3737
Kaspersky ver: 21.17.7.539(b)

[trip2teea]

I know it's bad idea to do it, but I even tried to set these exclusions for Windows Logon Application, which is a root process in this run sequence, just to test whether this feature works or not. It doesn't work and prompts for permission anyway.

Adding this path to "Exclusions and actions on object detection" stops this prompt from appearing:
%localappdata%\Temp\MSBuildTemp\tmp*.exec.cmd

But this completely stops monitoring these cmd files, I would like to do it only if it's ran by trusted *.sln Visual Studio solution.

[harlan4096]

Welcome to Kaspersky Community.

 

• Quote

   

  • Do not monitor child application activity
    • Apply exclusion recursively
  • Do not inherit restrictions from the parent process (application)

   

 

Enabling those exclusions for the main app that generates the random new cmd files every time should do the trick 🤔

 

Is it Your main app placed in Trusted group or in a restriction group? Since by default trusted apps should have access

without prompts for low-level disk access, see this capture, as an example:

 

[trip2teea]

3 часа назад, harlan4096 сказал:

Welcome to Kaspersky Community.

Enabling those exclusions for the main app that generates the random new cmd files every time should do the trick 🤔

 

Is it Your main app placed in Trusted group or in a restriction group? Since by default trusted apps should have access

without prompts for low-level disk access, see this capture, as an example:

 

Hi, thank you for reply.

I tried to set it for several parent applications which show up in "Run sequence". Even the most top one, which is a system process (Windows Logon Application). I did it like this:

And, of course, all these are in trusted category and they have permissions for low-level access to disk.

I must add that this pre-build event runs .bat script which also runs another executable. Neither this bat script nor that executable show up in that prompt for access approval from Kaspersky, but just in case I also set both of them as trusted and made sure they have permissions for low-level disk access.

Really weird.

[harlan4096]

is Your K. product set to Interactive Mode?

[trip2teea]

2 часа назад, harlan4096 сказал:

is Your K. product set to Interactive Mode?

Is it this setting? I thought it's affecting only scanning.

Thing is, that in most other cases Intrusion Prevention works fine and as expected.

For example, in "Manage resources" I created my own category under "Personal data". Let's say I called it "My Data".
In "My Data" category, I set all application categories, including "Trusted" to "Ask user". And all apps by default inherits that.
Now, let's say, I want to restrict other applications and processes from accessing Telegram's appdata (portable version) and whitelist only Telegram to access it.
So I add new path like this under "My Data" category: C:\Telegram\tdata\*
And whitelist telegram apps by "developer" category like this:

Now, when I open Telegram - I still get asked if I should allow or block access.
It is expected, because Telegram is being ran not by itself, but by Windows Explorer and run sequence appears like this:
Windows Explorer -> Telegram

What's weird is that for some apps/processes it appears in the Application list with new run sequence, so it can be configured. In case with Telegram it doesn't happen. So, the only way to stop these access prompts is to go to Telegram application settings in Kaspersky and enable "Do not inherit restrictions from parent process (application)" like this:

Now it works as expected, whenever I run Telegram, even if it was started by Windows Explorer, it starts properly and doesn't ask me to allow or block it every time.

But with scenario described in my first post, where it's low-level disk access in question, it doesn't work as expected.