Question How to set up exclusions to paths that are dynamic not constant?

[Studynxx]

Specifically I have some scripts that place temp scripts in %USERNAME%/TEMP/scripts and then in the end that folder and all the scripts inside get deleted. I use this for imaging computers.

The problem is that it seems manually selecting this subfolder/path and then creating the master config file that Kaspersky imports on new machines, keeps the username hardcoded, it never changes to say admin1, admin2, admin3, it stays "admin".

I've tried typing in the path using the dynamic path ie %USERNAME%/TEMP/scripts but not sure if this will work. Is this even possible in Kaspersky Total Security?

 

[harlan4096]

I see You just come back requesting a new miracle by K...

 

[harlan4096]

Can You post the current exclusion created?

 

[Studynxx]

Can You post the current exclusion created?

It's "%TEMP%/scripts however in the exclusion it hardcodes the current username so when the master config imports this that username stays. This is the problem even tho I used %TEMP% which always resolves to the dynamic username variable ie admin, admin1, admin2, etc

 

[harlan4096]

Check these links, maybe can help You:

Threats and Exclusions

support.kaspersky.com

Kaspersky Knowledge Base

Get technical support for Kaspersky applications for home & business. Find instructions, video manuals and tools to solve top issues.

support.kaspersky.com

But maybe what You want to implement can't be done.

 

[ForgottenSeer 123960]

The key is to manually type the path, such as %TEMP%\scripts\, into the exclusion settings rather than using the "Browse" button, which will hardcode the path with the current username.

Using the %TEMP% variable is generally more reliable as it resolves directly to the active user's temporary folder.

For a more secure approach that aligns with the Principle of Least Privilege, consider adding your scripting engine (like PowerShell.exe) to the "Trusted Applications" list instead. This tells Kaspersky to trust the process creating the files, rather than creating a potentially risky blind spot by excluding an entire folder from scans.

This is a classic example of managing residual risk, and it's why a layered Defense-in-Depth strategy is so essential. Trusting the PowerShell process is not a perfect solution, it's a trade-off. We're trading the high risk of a static blind spot in a folder for the lower, more manageable risk of a trusted process being compromised.

Even if an attacker exploits a vulnerability in PowerShell, and even if that PowerShell process is on a "Trusted Application" list, here are the other defenses that should still catch the malicious activity, patch management, behavioral monitoring, built in powershell securities.

The imaging scripts themselves should only be run with the minimum permissions necessary to do their job. If the script only needs local administrator rights, don't run it with Domain Admin credentials. If an attacker hijacks that PowerShell process, they are trapped by the limited permissions of that process, making it much harder to move laterally across your network.

By combining these layers, you create a robust defense. While you "trust" PowerShell for a very specific function within your antivirus, you are still actively monitoring its behavior, logging its actions, limiting its power, and patching its weaknesses.

 

[Studynxx]

The key is to manually type the path, such as %TEMP%\scripts\, into the exclusion settings rather than using the "Browse" button, which will hardcode the path with the current username.

Using the %TEMP% variable is generally more reliable as it resolves directly to the active user's temporary folder.

For a more secure approach that aligns with the Principle of Least Privilege, consider adding your scripting engine (like PowerShell.exe) to the "Trusted Applications" list instead. This tells Kaspersky to trust the process creating the files, rather than creating a potentially risky blind spot by excluding an entire folder from scans.

This is a classic example of managing residual risk, and it's why a layered Defense-in-Depth strategy is so essential. Trusting the PowerShell process is not a perfect solution, it's a trade-off. We're trading the high risk of a static blind spot in a folder for the lower, more manageable risk of a trusted process being compromised.

Even if an attacker exploits a vulnerability in PowerShell, and even if that PowerShell process is on a "Trusted Application" list, here are the other defenses that should still catch the malicious activity, patch management, behavioral monitoring, built in powershell securities.

The imaging scripts themselves should only be run with the minimum permissions necessary to do their job. If the script only needs local administrator rights, don't run it with Domain Admin credentials. If an attacker hijacks that PowerShell process, they are trapped by the limited permissions of that process, making it much harder to move laterally across your network.

By combining these layers, you create a robust defense. While you "trust" PowerShell for a very specific function within your antivirus, you are still actively monitoring its behavior, logging its actions, limiting its power, and patching its weaknesses.

For a more secure approach that aligns with the Principle of Least Privilege, consider adding your scripting engine (like PowerShell.exe) to the "Trusted Applications" list instead. This tells Kaspersky to trust the process creating the files, rather than creating a potentially risky blind spot by excluding an entire folder from scans.

I'd just be contributing to a LOLBin if I put the entire engine in the Trusted Apps list. No way I'll do that

 

[Trident]

So instead of relying on Kaspersky, why don’t you configure your script to create same folders intelligently? Something like C:/Content/Scripts. Then schedule the script for deletion on reboot. Dropping scripts in the temp folders is extremely suspicious and fragile. That’s the beauty of programming/scripting, there are always so many options.

 

[ForgottenSeer 123960]

I'd just be contributing to a LOLBin if I put the entire engine in the Trusted Apps list. No way I'll do that

Creating an exclusion for a folder, especially one inside a user's temporary directory, is absolutely a security risk.

Every exclusion is a hole poked in your defenses that you, the user, must now manually compensate for.

So, to be perfectly clear, both paths carry risk.

This might be a good moment to step back and look at the bigger picture.

My intention was not to get you to trust PowerShell, but to make you think about the risk you're taking every time you poke a hole in your own security to get a script to work.

Looking at your posts, you are frequently asking for advice on how to set up, run, and use different scripts, each of which seems to require a new security exception. Frankly, it leads to a genuine concern, after all these bypasses, how many holes are in your security setup now?

 

[Studynxx]

Creating an exclusion for a folder, especially one inside a user's temporary directory, is absolutely a security risk.

Every exclusion is a hole poked in your defenses that you, the user, must now manually compensate for.

So, to be perfectly clear, both paths carry risk.

This might be a good moment to step back and look at the bigger picture.

My intention was not to get you to trust PowerShell, but to make you think about the risk you're taking every time you poke a hole in your own security to get a script to work.

Looking at your posts, you are frequently asking for advice on how to set up, run, and use different scripts, each of which seems to require a new security exception. Frankly, it leads to a genuine concern, after all these bypasses, how many holes are in your security setup now?

I do create the folder, but after they'd done, the folder and all its content is deleted permanently

 

[ForgottenSeer 123960]

I do create the folder, but after they'd done, the folder and all its content is deleted permanently

Think of it this way, locking a door doesn't help if the intruder is already inside the building. Your process of deleting the temporary folder is that final 'door locking', it's a necessary step, but it can't mitigate the damage done while the door was momentarily open. That's why the real concern isn't what's left behind, but the cumulative risk of repeatedly creating these temporary windows of vulnerability. It's a workflow that perfectly mimics common malware techniques, which is why it rightly draws suspicion.

 

[Trident]

Yes, when signed installers create files in %temp%, that’s acceptable and usually won’t trigger alerts. But if suspicious parent object like another script drops more scripts in %temp%, it becomes suspicious.

It will be much less suspicious if scripts are dropped on the desktop or something.

 

[stonjean633]

Yes, when signed installers create files in %temp%, that’s acceptable and usually won’t trigger alerts. But if suspicious parent object like another script drops more scripts in %temp%, it becomes suspicious.

It will be much less suspicious if scripts are dropped on the desktop or something.

Agree on this.
TEMP folders are one of the beehives of malware making it one of the priorities of AV scanning be it on scripts,files etc etc

 

[harlan4096]

The problem here is that I guess K. exclusion system can't manage system variables like %USERNAME% or %TEMP%...

 

[Studynxx]

The problem here is that I guess K. exclusion system can't manage system variables like %USERNAME% or %TEMP%...

exactly

 

[ForgottenSeer 114717]

I'd just be contributing to a LOLBin if I put the entire engine in the Trusted Apps list. No way I'll do that

You can always take your script source code, compile it into an executable, self-sign it, then place it into a secure whitelisted file system location such as C:\Windows\My_Executable, and then create a scheduled task., and the executable do what it is that you want or need it to do. That way you can keep the LOLBin blocked and "not contribute to a LOLBin."

 

[Trident]

You can always take your script source code, compile it into an executable, self-sign it, then place it into a secure whitelisted file system location such as C:\Windows\My_Executable, and then create a scheduled task., and the executable do what it is that you want or need it to do. That way you can keep the LOLBin blocked and "not contribute to a LOLBin."

There is this PS2Exe as well that can convert ps1 script to executable, and then even Node.js and other frameworks can be used to give the executable a nice UI. But in this case it’s quicker to just use folder where there are no variables, such ad C:\something\something… or just exclude the dropped script as well, or move it to trusted….

So many options that you wouldn’t even know what to choose.

 

[ForgottenSeer 114717]

There is this PS2Exe as well that can convert ps1 script to executable, and then even Node.js and other frameworks can be used to give the executable a nice UI. But in this case it’s quicker to just use folder where there are no variables, such ad C:\something\something… or just exclude the dropped script as well, or move it to trusted….

So many options that you wouldn’t even know what to choose.

100%.

What I suggested is what I've done many times to resolve the issues I've encountered. It takes a little bit more time and effort, but the solution is a permanent one, and I can keep all them troublesome LOLBins disabled and still get what I need from the executable. And it even works in enterprise and government. Imagine that.

It's the digital world. There's always multiple alternative ways to solve a problem. Some easy. Some not. Some convenient. Some not. Some fast. Some slow. Some ugly. Some elegant. Some low cost. Some expensive. Some low knowledge. Some require payment of technical debt. It all depends upon what one's priorities are.

 

[Studynxx]

There is this PS2Exe as well that can convert ps1 script to executable, and then even Node.js and other frameworks can be used to give the executable a nice UI. But in this case it’s quicker to just use folder where there are no variables, such ad C:\something\something… or just exclude the dropped script as well, or move it to trusted….

So many options that you wouldn’t even know what to choose.

That's what I ended up going with, yes.

 

[ForgottenSeer 114717]

That's what I ended up going with, yes.

Which one? LOL