The following is a detailed breakdown of a malicious VBS script discovered on an endpoint within RADICL’s customer base as a result of RADICL’s custom EDR detection logic. The script executes a multi-stage attack designed to achieve persistence, evade detection, and deploy a secondary payload. It leverages environmental path resolution and stealthy self-replication into AppData directories, performs privilege elevation via persistent UAC prompts, and disables Microsoft Defender scanning through exclusion path insertion. The malware establishes persistence via a scheduled task mimicking a legitimate Windows service. Ultimately, it downloads and executes a malicious payload, a suspiciously signed disk benchmarking utility flagged by numerous antivirus engines. The tactics observed align with known malware loader behavior and demonstrate deliberate evasion and persistence strategies.
The script begins by initializing critical Windows scripting objects to control files, processes, and the environment. It then resolves system-specific paths—like %TEMP%, %APPDATA%, and %LOCALAPPDATA%—to establish where and how it will operate. This includes identifying its own location, preparing for self-copying, tracking execution state, and targeting locations commonly used for stealth and persistence.
The next section starts by initializing the "args" variable which is used to store command-line arguments when the script is executed. A for-loop ensures that it iterates over all arguments.
Then, it normalizes the “args” value by lowercasing and trimming out white space.
After initialization, the script uses an “If” comparison to check its current running location and compares that with its intended persistence location, which is AppData\Roaming. It checks if the two values are not equal. If the statement is evaluated to false, this signals to the script that this is the first time it is being run on the system. The script then copies itself to “targetPath.” The targetPath is “AppData\Roaming\” which was defined earlier at the beginning of the script.
The next section of the script performs a pulse check to prevent re-execution. It checks for the presence of the marker file (defined at the beginning of the script via markerPath) and whether the script is being executed without the “--fromloader" parameter, which is ONLY used after persistence is established. If the marker file (adm_marker.tmp) is found and “--fromloader” isn’t being used, the script will quit immediately. This ensures that the state of the loader remains consistent and does not execute more than once, which would likely tip off a system administrator or the SOC. If the marker file doesn’t exist, the script continues to execute.
In this case, let’s assume the marker file does not exist. Therefore, the next stage of the script performs a privilege elevation. The script first defines some variables to track success. It then attempts to write/overwrite a file in system32 named “admin_check.txt.” Since system32 is a protected directory, a successful file write action here would indicate that administrator privileges are present.
The script evaluates success or failure of the write attempt. If the script hits an error, such as a “You do not have rights to access that file” it will attempt to trick the user into allowing the script to run with elevated privileges as seen here:
This will display a UAC prompt for the user. If the user selects no, the script will sleep for 2 seconds, evaluate if the marker file (adm_marker.tmp) exists in markerPath (which is AppData\Local\TEMP). If the marker file does not exist, it will subsequently display another UAC prompt for the user to interact with. This continues, persistently, until the user selects “Yes” on the UAC prompt or kills the script via Task Manager. This technique is like the techniques we see with “Push Fatigue” attacks.
Once the user accepts the UAC prompt, the script is now running as admin. It then removes all traces of the “admin_check.txt” file and then writes the “adm_marker.tmp” file to the markerPath (aka AppData\Local\Temp\adm_marker.tmp).
After the script elevates privileges, it adds two ExclusionPaths to Microsoft Defender via the Add-MpPreference PowerShell Cmdlet. The exclusion paths are:
C:\Users\UserName\AppData\Roaming
C:\Users\UserName\AppData\Local
This ensures that any files in either of the above paths will not be scanned or monitored by Defender. This is key because the script executes from “targetPath” (aka AppData\Roaming).
Now that the script is running in an elevated state, it works to establish true persistence on the target machine via a scheduled task. First, it declares some variables needed to create the scheduled task. These are username, taskName, quotedExePath, schtasksCommand. It then sets the values of those variables and then executes. Which results in a scheduled task creation named “WinSvcUpd.” The name of the scheduled task is designed to mimic a legitimate Windows service like “Windows Update Service.” The important parts are that the service is:
When the script executes via its persistence mechanism, it proceeds to clean up all traces of the initial infection. It does this by:
Checking if the script is launched with “--fromloader.”
Checks if “selfPath” and “targetPath” are not equal.
When these two conditions are true, the script deletes the file at “selfPath.” Which would be the script's original execution location. In our dataset this was C:\Users\Administrator\AppData\Local\Temp\7f5d0382593c4d0d911c7ffa79fabaaa.vbs. It also forces “True” which suppresses any prompts.
At this point the script works to download the follow-on payload. Here, it reaches out to a suspicious remote URL, downloads a zip file, and saves it locally.
In our dataset the binary was named “diskbenchmark.exe.” I reviewed the hash of the binary, and it was flagged by 39/71 security vendors as malicious.
It appears to be a Razr USA Ltd disk benchmarking utility. However, the file had an invalid signature as seen on Virus Total:
The script creates a randomly named folder in the user's Temp directory, extracts a downloaded ZIP file into it, searches for any .exe inside, and silently executes the first one it finds using the Shell.Application interface. This marks the final payload execution step and transitions the attack into whatever functionality the payload provides.
This VBScript represents a well‑structured loader that incorporates multiple tactics to achieve persistence, defense evasion, and privilege elevation on the target endpoint. Its techniques—self‑replication into user directories, repeated UAC prompts to gain elevated execution, strategic Defender exclusion path modifications, and scheduled task creation—strongly aligns with known malware loader and dropper behavior. The final stage, downloading and executing a suspiciously signed payload, confirms intent to compromise the host beyond initial access.
Security teams should treat endpoints exhibiting these behaviors as compromised, perform a full forensic review, and remediate any actions the malware performed on the endpoint. Detection logic around UAC prompt abuse, exclusion path creation, and scheduled task anomalies in user profiles strengthens defenses against similar threats.