How Script-based Malware Attacks Work: Modern Examples

Script-based malware is malicious software written in scripting languages like JavaScript, Python, PowerShell, or VBScript. Unlike traditional malware that relies on compiled executables, script-based malware leverages scripts that execute as human-readable code interpreted at runtime Scripts have become increasingly popular in recent years: they effectively evade traditional endpoint detection and are easy to modify and […] The post How Script-based Malware Attacks Work: Modern Examples appeared first on Cyber Security News.

Apr 23, 2025 - 16:19

How Script-based Malware Attacks Work: Modern Examples

Script-based malware is malicious software written in scripting languages like JavaScript, Python, PowerShell, or VBScript.

Unlike traditional malware that relies on compiled executables, script-based malware leverages scripts that execute as human-readable code interpreted at runtime

Scripts have become increasingly popular in recent years: they effectively evade traditional endpoint detection and are easy to modify and obfuscate.

Adversaries Generally Use Them In One Of Two Ways:

Add a script component that executes an attack step in compiled malware to execute a command or download a payload.

Create malware using a scripting language directly. An example is Lu0bot, which is written in Node.js.

Example Comparison

Compiled	Script-Based
A trojan compiled as an .exe is downloaded from a malicious site. It’s flagged by antivirus due to its binary signature before it can execute, but if it runs, it might install a persistent rootkit.	A PowerShell script delivered via a phishing email runs in memory, downloads ransomware, and encrypts files. It’s hard to detect because it uses legitimate system tools and leaves no executable.

Why Can Script-based Malware Be More Dangerous Compared To Compiled?

Script-based malware has distinct characteristics that can make it more dangerous or advanced compared to compiled malware in certain contexts. Its nature enhances its stealth, flexibility, and adaptability.

1. Stealth And Evasion

Fileless Execution: Script-based malware often runs entirely in memory, avoiding the creation of detectable files on disk. Compiled malware typically requires an executable file, which antivirus software can identify and scan.

Blends with Legitimate Processes: Scripts can execute within trusted environments like PowerShell, JavaScript engines, or Office macros, making them harder to distinguish from legitimate activity. Compiled malware, being a standalone binary, is more likely to trigger suspicion.

Obfuscation Ease: Scripting languages allow dynamic code generation, encoding, or encryption, enabling attackers to hide malicious intent. While compiled malware can also be obfuscated, it often requires more complex techniques.

2. Flexibility And Rapid Development

Cross-Platform Compatibility: Many scripting languages (e.g., JavaScript, Python) are platform-agnostic, allowing the same malware to target Windows, macOS, or Linux with minimal changes. Compiled malware often needs separate builds for different architectures or operating systems.

Ease of Modification: Scripts are human-readable and can be quickly edited or updated to exploit new vulnerabilities or evade detection. Compiled malware requires recompilation, which is more time-consuming and complex.

Dynamic Behavior: Scripts can adapt their behavior at runtime based on the environment (e.g., checking for antivirus or sandbox presence). Compiled malware typically has more static behavior unless specifically engineered for polymorphism.

3. Persistence And Resilience

Tricky Persistence Mechanisms: Scripts can manipulate system configurations (e.g., registry keys, scheduled tasks) in ways that are less likely to be flagged than the binary modifications often used by compiled malware.

Living-off-the-Land: Script-based malware uses legitimate system tools and processes, reducing the need for external payloads. This makes it harder to detect compared to compiled malware, which often needs additional binaries.

4. Lower Entry Barrier

Scripting languages are easier to learn and use than low-level languages like C++. Besides, script-based malware exploits tools already present in the OS (e.g., PowerShell, Windows Script Host, or browsers), without the need to install additional components.

5. Challenges For Detection And Forensics

Short-Lived Artifacts: Since script-based malware often operates in memory or leverages temporary files, it leaves fewer forensic traces.

Antivirus Evasion: Many antivirus solutions are optimized for detecting binary signatures, which are less effective against scripts that can change rapidly or use obfuscation.

However:

Which type of malware is more dangerous, depends on the attack’s goals and context.

For widespread, stealthy campaigns (e.g., data theft or ransomware), script-based malware is often more advanced.

For targeted, deep-system compromise, compiled malware may be more effective.

The latter can also be more efficient for low-level system manipulation (e.g., rootkits) or persistence in firmware.

It may also achieve faster execution and tighter control over hardware, which scripts cannot match.

Example 1: System Data Collection via JS Script

When analyzing scripts, you have two main options:

1. Review the source code statically to understand how the script works. This involves examining the codebase line by line without executing it.

2. Execute the script dynamically. You can use debuggers (x64dbg, IDA Pro) and script tracers to step through the execution, inspect variables, or run the script in ANY.RUN’s Interactive Sandbox to see what it does within the system.

Sandboxing and scripting tend to be more effective than static code review both for script-based malware and compiled malware that uses scripts somewhere in the attack chain.

Script-based malware evades detection and analysis by a number of techniques including sandbox and virtual machine detection. ANY.RUN’s Sandbox, however, knows how to counter this behavior and show malware activity in detail.

Analysis of script-based malware inside ANY.RUN’s Interactive Sandbox

Suppose a user receives an email with an attachment. The file’s name suggests an important financial document, but the extension .scr hints an executable script that could be generated by a number of programs.

The user submits the file into ANY.RUN’s Interactive Sandbox and analyzes the processes that its detonation brings to life.

ANY.RUN allows you to view the entire tree of processes spawned during execution

Among them we see Wscript.exe a legitimate Windows process that runs scripts, a part of the Windows Script Host (WSH), which allows users to automate tasks or execute scripts in the operating system.

Let’s choose this script in the list and click More Info:

The sandbox flags malicious activities, including evasion and system data collection

In the left-hand side menu there is a tool named Script tracer.

The sandbox is equipped with script tracing capabilities

It has detected a number of Javascript activities. We shall look closer at some of them:

The sandbox shows in detail how the script is used for collecting system information

The script is run via IWshShell3 an interface in the Windows Script Host (WSH) object model for interacting with Windows systems and components through scripts (VBS/JS).

The script reads a registry key and returns the name of the operation system: now the attack agent knows that it’s Windows 10 Enterprise.

The next script reads another registry key and returns the information about the endpoint processor architecture: AMD64.

Prevent script-based attacks on your company with proactive sandbox analysis

Request 14-day trial of ANY.RUN’s top plan designed for SOC teams.

Collecting this data about the affected endpoint is a critical reconnaissance phase for understanding the target environment and for executing effective malicious activities.

Hackers use this information to detect specific vulnerabilities, to customize payload, to optimize evasion and persistence mechanisms.

Knowing the OS and architecture helps confirm whether the endpoint is a high-value target (e.g., a server running Windows Server vs. a low-value desktop).

Of course it’s not enough to just get the information, so one of the scripts run further sends the HEX-encoded data to the adversary’s C2 server.

The script encodes the collected data and exfiltrates it to an attacker-controlled server

Example 2: Steganography Attack Using PowerShell

Steganography is the practice of hiding data (such as malicious code, commands, or exfiltrated information) within seemingly innocent files like images, audio, videos, or documents. Hackers use steganography to:

Evade detection (by bypassing security tools that don’t analyze file contents deeply).

Deliver payloads (embedding malicious scripts inside image files).

Exfiltrate data (hiding stolen data in a modified image or audio file).

Trigger attacks (extracting hidden commands from a downloaded file).

Let’s see how this might work on the example of a Javascript file analyzed in the Sandbox. In the list of processes, we locate powershell.exe, select it and click More Info.

Script tracer has found several PowerShell scripts: number 8 is of interest regarding steganography. It downloads an image hosted at Archive.org.

Attackers often store malicious files on external file-hosting websites like archive.org

The picture looks quite innocent:

The downloaded image contains malicious code

But the source code of this file contains a malware code encrypted in base64: one more script that we can locate in our sandbox analysis serves to find this encrypted code.

The script fetches the Base64-encoded piece of code from the image and decodes it

Yet another script decrypts it into plain text which results in an executable file code (this we understand seeing an MZ file signature, a Windows portable .exe identifier):

Decoding reveals a malicious XWorm payload

On the file’s execution by one more script, the XWorm trojan starts its infection of the system.

We can see how the PowerShell process is used for launching XWorm

ANY.RUN’s Interactive Sandbox lets us see this entire chain of attack in the Process Graph.

Conclusion

ANY.RUN’s Interactive Sandbox is a perfect environment for dissecting and analyzing malicious scripts. Such analysis equips cybersecurity teams with actionable insights to detect, neutralize, and prevent threats. For a business, it means:

Reducing Downtime: Identifies and blocks threats, minimizing system outages and ensuring business continuity.
Lowering Incident Costs: Prevents breaches, reducing recovery, legal, and reputational expenses.
Enhancing Security Posture: Uncovers vulnerabilities and TTPs, strengthening defenses and reducing risk exposure.
Improving Compliance: Demonstrates proactive threat analysis, supporting compliance with GDPR, HIPAA, or PCI-DSS.
Boosting Customer Trust: Prevents data leaks, maintaining confidence in the organization’s security.
Increasing Employee Productivity: Training based on sandbox insights reduces successful phishing, freeing staff to focus on core tasks.

ANY.RUN’s Key Benefits

Provides full visibility into the entire attack chain.
Gathers IOCs, TTPs, and other key components in one place.
Cloud-based — no need for complex setup or local resources.
Generates clear, structured reports for faster sharing and response.
Suitable for both junior and senior specialists — advanced analysis, but no advanced skills needed.

Request 14-day trial of ANY.RUN’s Enterprise plan.

The post How Script-based Malware Attacks Work: Modern Examples appeared first on Cyber Security News.