Question Potenial method for locking script files down!

Please provide comments and solutions that are helpful to the author of this topic.

Parkinsond

Level 55
Thread author
Verified
Well-known
Dec 6, 2023
4,427
11,601
5,369
I have few cmd files which were launching as admin without problems.
Tried to launch one of them, I do not have AppLocker script rules enabled this time, but it did not.
Tried another one, the same scenario.
Searched for an explanation; a post on a forum reported including "&" in the name of any folder of the cmd file path prevents it from launch.
I have renamed the folder in question (removed the &), and tried to launch the files one by one; all launched as usual.

So, does adding "&" to the folder name makes it protected against the execution of script files inside?
 
I have few cmd files which were launching as admin without problems.
Tried to launch one of them, I do not have AppLocker script rules enabled this time, but it did not.
Tried another one, the same scenario.
Searched for an explanation; a post on a forum reported including "&" in the name of any folder of the cmd file path prevents it from launch.
I have renamed the folder in question (removed the &), and tried to launch the files one by one; all launched as usual.

So, does adding "&" to the folder name makes it protected against the execution of script files inside?
Adding an ampersand (&) to a folder name does not make it a protected folder, instead, what you've encountered is a technical glitch, not a security feature. The ampersand is a special character in the Windows Command Prompt used to separate multiple commands on a single line.

When the system tries to run a file from a path containing this character, it often misinterprets the path as two distinct and invalid commands, causing the execution to fail. This behavior is an unreliable form of "security by obscurity" because it's easily bypassed by simply enclosing the path in quotation marks and breaks legitimate functionality.
 
How can the malicious cmd file do this bypass by itself?
A malicious .cmd file cannot bypass this issue by itself, as the error occurs in how the operating system's shell tries to launch the file before the script even starts.

However, an attacker can easily circumvent this by using a simple "loader" or "wrapper." They could use a second script, a Windows shortcut (.lnk) file, or a one-line PowerShell command that calls the target script. By simply enclosing the full path containing the ampersand (&) in quotation marks within this loader, the command is parsed correctly, and the malicious script runs without any problems.

Because this bypass is so trivial, using an & in a folder name provides no meaningful security and should not be relied upon as a protective measure.
 
However, an attacker can easily circumvent this by using a simple "loader" or "wrapper."
How can the attacker know in advance that one of the folders' name, in the script file path, contain "&" to make this loader or wrapper included?
Or it includes it preemptively in all the malicious scripts it create, just in case?
 
  • Wow
Reactions: Sorrento
How can the attacker know in advance that one of the folders' name, in the script file path, contain "&" to make this loader or wrapper included?
Or it includes it preemptively in all the malicious scripts it create, just in case?
An attacker doesn't actually need to know in advance that your folder name contains an ampersand. Instead, they write their malicious code preemptively using robust scripting practices to ensure it works reliably on as many systems as possible.

Quoting file paths is a standard best practice that handles not just ampersands (&), but also common spaces (like in "Program Files") and other special characters that would otherwise cause a script to fail. An attacker will often use a simple "loader" script or shortcut that calls the main malicious file.
 
Why would an attacker know that there is an ampersand sign? Script malware usually doesn’t run solely in PowerShell, CMD, Word or wherever it starts, it injects in legitimate executables. These executables have zero issues with the ampersand sign.

Fun fact: xml and ampersand sign also don’t go too well together either.
 
Why would an attacker know that there is an ampersand sign? Script malware usually doesn’t run solely in PowerShell, CMD, Word or wherever it starts, it injects in legitimate executables. These executables have zero issues with the ampersand sign.

Fun fact: xml and ampersand sign also don’t go too well together either.
You're exactly right. Attackers often use techniques like process injection to run their code inside a trusted application like explorer.exe. Once they do that, the original script's path, with or without an ampersand, becomes completely irrelevant. This is a key reason why using & in a folder name isn't a real security measure, more advanced attacks simply bypass that issue entirely.
 
You're exactly right. Attackers often use techniques like process injection to run their code inside a trusted application like explorer.exe. Once they do that, the original script's path, with or without an ampersand, becomes completely irrelevant. This is a key reason why using & in a folder name isn't a real security measure, more advanced attacks simply bypass that issue entirely.
Is there a way to interrupt the process injection after launch of malware?
 
Is there a way to interrupt the process injection after launch of malware?
Process injection happens in milliseconds, too fast for manual intervention. It can only be stopped by advanced security software (like an EDR or modern antivirus) that automatically detects the suspicious behavior of one process trying to inject code into another and terminates the attack in real-time.
 
Process injection happens in milliseconds, too fast for manual intervention. It can only be stopped by advanced security software (like an EDR or modern antivirus) that automatically detects the suspicious behavior of one process trying to inject code into another and terminates the attack in real-time.
Can using the ASR rule of "Block use of copied or impersonated system tools" block the action of injected malicious code inside legitimate Windows process?
 
Can using the ASR rule of "Block use of copied or impersonated system tools" block the action of injected malicious code inside legitimate Windows process?
Think of this ASR rule as a very specific lock on one door. It's highly effective at stopping anyone trying to break in through that one door (using copied system tools). But it offers no protection if the attacker decides to come through a window (a malicious macro) or the front door (a custom executable).

So, yes, it can be a great preventative measure, but it only works against one of the many tricks in an attacker's playbook.

While the rule is effective against a specific attacker technique, it is not without risk to legitimate applications. A phased approach using Audit Mode is essential for successful and safe implementation.
 
So, does adding "&" to the folder name makes it protected against the execution of script files inside?

Such folders are mainly user-created folders, which are rarely abused by attackers because they typically do not know of them.
The attackers use the known folders as a target for dropping & executing scripts. So, adding "&" will not help in practice.
 
  • +Reputation
Reactions: Parkinsond
Typically a script will have error handling too, so if the attacker is looking to drop a file in AppData/Roaming/ChocolateCookies and instead of ChocolateCookies &Chocolate&Cookies exists, this will return an error (folder doesn’t exist). The attacker will decide how to handle this error, it could simply display a message, it could create the folder or it could start looking for another folder. It will be difficult to just break the script, unless it was created by an amateur.
 
  • +Reputation
Reactions: Parkinsond
The attacker will decide how to handle this error, it could simply display a message, it could create the folder or it could start looking for another folder. It will be difficult to just break the script, unless it was created by an amateur
Such alternatives are automatically encoded inside the malicious script or the attacker need a RAT to carry out the required task according to what he/she may find?
 
  • Like
Reactions: Trident
Such alternatives are automatically encoded inside the malicious script or the attacker need a RAT to carry out the required task according to what he/she may find?
It’s encoded in the script, a good programmer always adde the so called graceful error handling, so in case of unforeseen (or more likely foreseen but undesirable conditions) the project, script or programme, doesn’t abruptly terminate. Only a real newbie and amateur won’t use error handling.
 
  • +Reputation
Reactions: Parkinsond