What is a script-based attack?¶
A script-based attack uses a scripting language or interpreter to carry out malicious activity.
Avoid the dangerous assumption¶
The dangerous assumption is that the scripting tool itself is malicious.
It may be a normal part of the operating system or application environment.
Common examples include PowerShell, command shell, JavaScript, VBScript, Python, shell scripts and application-specific scripting.
An offender may use scripts to:
- download files
- run commands
- collect information
- change configuration
- create persistence
- connect to external infrastructure
- automate activity.
Investigators should preserve:
- the script content where available
- the interpreter used
- the command line
- the account context
- the parent process
- the time of execution
- files created
- network connections
- later commands or payloads.
Scripts may be entered directly, downloaded, embedded in documents or executed in memory. The original file may not remain.
Do not assume that a suspicious command proves offender activity. Administrators, software installers and automation systems may use similar commands.
Examine timing, source, account, target system and surrounding activity.
Obfuscated scripts may conceal purpose, but obfuscation alone does not establish that the full intended action succeeded.
Specialist analysis may decode the script. That should be separated from evidence that it executed on the affected system.
Where commands are encoded or heavily obfuscated, preserve both the original and decoded versions. The decoded content explains intended behaviour, while system records are still needed to show which instructions actually ran.
Operational takeaway¶
Assess what the script instructed the system to do, who or what launched it and which actions actually occurred, rather than treating the interpreter as malicious.