What Is Malicious Code? Types, Entry Points and Runtime Prevention

What Is Malicious Code?

Malicious code is any program, script, command, package, or payload deliberately created or manipulated to perform harmful or unauthorized actions. It may steal data, disrupt services, damage systems, create persistent access, hijack execution, or give an attacker control over an application.

Intent is central to the definition. An accidental software defect may create a vulnerability, but it is not malicious code unless someone deliberately creates, inserts, or uses code to cause harm.

In modern applications, malicious code does not always arrive as an obvious malware file. It may enter through a compromised open-source package, exploit a vulnerable but legitimate dependency, arrive through a valid API request, or abuse an existing application function.

This distinction matters because a malicious package is only one source of malicious execution. Attackers can also manipulate trusted libraries and functions into performing actions they were never intended to perform.

Security teams therefore need to answer more than whether suspicious code or a vulnerable package exists. They need to understand what executed, which library and function caused the behavior, what triggered it, and whether the action can be stopped before it creates damage.

That is where runtime application visibility becomes essential.

Key Takeaways

• Malicious code is intentionally created or manipulated to perform harmful or unauthorized actions.
• It is broader than malware and may include poisoned packages, injected commands, exploit payloads, and abuse of legitimate application functions.
• A package may be malicious by design, while a legitimate package may become part of a malicious execution path through a vulnerability.
• Traditional tools may see suspicious traffic, vulnerable packages, or system activity without identifying the application code responsible.
• Runtime application security connects behavior to the library, function, call chain, request, and workload, then stops dangerous actions at execution.

Malicious Code vs. Malware and Vulnerabilities

Malware is one type of malicious code, but the terms are not interchangeable.

Malware usually refers to a standalone malicious program, such as ransomware, spyware, a trojan, a worm, or a backdoor. Malicious code is broader. It may be a command passed to a vulnerable function, an injected script, a malicious install routine, or a few harmful lines hidden inside an otherwise legitimate dependency.

A software vulnerability is different from both. It is a weakness that creates the possibility of unsafe behavior. The weakness may result from a coding error, insecure configuration, design flaw, or vulnerable package.

For example, a legitimate file-processing library may contain a command injection vulnerability. The library is not malicious, but attacker-controlled input can manipulate it into running an unauthorized command.

In simple terms:

• Malware is a malicious software artifact.
• Malicious code includes deliberately harmful code and execution.
• A vulnerability is a weakness that may allow malicious code to run.

‍

Common Types of Malicious Code

Traditional categories include viruses, worms, trojans, ransomware, spyware, rootkits, backdoors, droppers, and loaders.

These threats may spread between systems, steal information, encrypt data, hide activity, maintain access, or deliver additional payloads.

Modern application attacks often look different. Malicious code may also appear as a poisoned open-source package, a malicious post-install script, dependency confusion, injected JavaScript, command injection, unsafe deserialization, or another exploit path through trusted code.

These examples show why security teams need to look beyond malware labels and focus on what code actually does when it runs.

How Malicious Code Gets Into Applications

Malicious code often moves through trusted development, deployment, and application paths before harmful behavior becomes visible.

Malicious Packages and Dependency Attacks

Modern applications rely on direct dependencies, transitive dependencies, frameworks, and SDKs. This accelerates development but expands the application’s trust boundary.

Attackers may publish malicious packages, imitate legitimate names, compromise maintainer accounts, or introduce harmful code through an update.

A malicious package may execute during installation, build, import, application startup, or only when a particular function is called. It may continue providing expected functionality to avoid detection.

Static inventory can show that a package exists. Runtime visibility shows whether it loads in production, which functions it invokes, and whether its behavior is expected or malicious.

Legitimate Packages Used for Malicious Execution

Not every dangerous path begins with a package that is malicious by design.

Attackers frequently exploit legitimate libraries containing vulnerable functions. A serialization package may process an unsafe object, a template engine may interpret injected expressions, or a file utility may pass attacker-controlled input to the operating system.

In these cases, the package is trusted. The malicious behavior appears only when attacker-controlled input reaches the vulnerable function.

Package reputation and presence alone are therefore not enough. Teams need to understand how the component behaves inside the running application.

Application Exploits

Attackers may trigger malicious execution through command injection, remote code execution, insecure deserialization, template injection, file upload abuse, SQL injection, path traversal, or server-side request forgery.

The request may reach a valid endpoint, come from an authenticated user, and avoid matching a known WAF signature. The danger only becomes clear after the application processes the input.

That is where perimeter visibility often ends and application execution begins.

Known CVEs, Zero-Days and CVE-Less Attacks

Some attacks exploit known CVEs, but patching can take days or weeks. Once a vulnerable function is reachable in production, teams need to know whether it is active and whether exploitation has begun.

Other attacks have no published CVE. Zero-days may be exploited before a fix or signature exists, while CVE-less attacks can abuse application logic, trusted features, compromised dependencies, or unexpected runtime behavior.

When there is no known identifier, the behavior of the running application becomes one of the most useful signals available.

Compromised Build and Deployment Paths

Attackers may also compromise source repositories, developer accounts, package registries, CI/CD pipelines, build tools, or container images.

Because the altered code travels through an approved release process, it may initially appear trusted. Runtime application visibility provides another layer of verification by showing what the deployed code actually does.

What Malicious Code Does After Execution

Malicious code becomes operationally significant when it runs. At that point, it may interact with data, files, processes, credentials, networks, cloud services, and connected systems.

Data and Credential Theft

Malicious code may read API keys, access tokens, environment variables, database records, customer information, configuration files, and secrets.

Applications are attractive targets because they already have legitimate access to sensitive resources. The attacker can make the application misuse its own identity and permissions.

Command and Process Execution

Malicious code may launch a shell, run an operating system command, start a child process, or invoke an external script.

EDR may detect that Java, Python, Node.js, or PHP spawned another process. Runtime application visibility can show which package, function, request, and call chain caused it.

Lateral Movement, Persistence and Disruption

A compromised application can become a path to internal APIs, databases, cloud metadata services, storage systems, or other workloads.

Attackers may create backdoors, write files, modify startup behavior, add credentials, or alter workload configurations to maintain access. They may also encrypt data, disable services, erase logs, exhaust resources, or repeatedly crash an application.

The potential impact depends on the application’s permissions, connectivity, and access to surrounding systems.

Signs Malicious Code May Be Executing

Potential indicators include unexpected child processes, unusual outbound connections, access to sensitive files or secrets, altered startup behavior, unexplained resource consumption, and functions running through abnormal call paths.

None of these signals proves malicious activity on its own. A legitimate application may spawn a process or open a connection as part of an expected workflow.

Application context determines whether the behavior was normal, vulnerable, or exploit-driven.

Why Traditional Defenses May Miss Malicious Execution

WAF, EDR, SCA, cloud security, and container tools remain essential, but each sees only part of the event.

A WAF inspects traffic before or as it reaches the application. Once the request is accepted, it generally cannot see which library processes it, which function executes, or what call chain follows.

EDR can detect processes, file activity, network connections, and operating system behavior. It may not identify the package, function, request, or application owner behind the event.

SCA identifies open-source packages and known vulnerabilities, but package presence does not prove runtime exposure. A dependency may exist in an image without loading, while another may actively process requests through a vulnerable function.

Runtime SCA adds evidence showing which components are present, loaded, reachable, and executing.

Together, traditional tools may show the request, package, and resulting process without revealing the execution path connecting them. This is the application execution gap.

How to Prevent and Stop Malicious Code

Preventing malicious code requires layered controls across development, delivery, access, and production.

Secure coding, code review, SAST, SCA, dependency governance, signed artifacts, patching, least privilege, WAF, EDR, and cloud security all reduce risk.

Runtime application security adds the final layer by observing and stopping dangerous behavior when code executes.

Runtime Application Visibility

Runtime visibility connects suspicious behavior to the application, package, library, function, call chain, request, process, container, image, node, and workload involved.

Instead of starting with a generic alert that a process launched or a connection opened, analysts can investigate the exact execution path that caused it.

Runtime Prevention

Runtime prevention evaluates what application code attempts to do while it runs. It can stop exploit-driven command execution, unauthorized process spawning, dangerous file access, unexpected network connections, malicious package behavior, and CVE-less attacks.

The goal is not only to identify a suspicious result. It is to understand which application component caused the behavior and prevent the action before it becomes compromise.

eBPF-Based Visibility and Enforcement

eBPF can observe and control low-level actions such as process creation, file access, system calls, and network connections without requiring developers to manually instrument every application.

That telemetry alone may show that Python spawned a shell without explaining which application function caused it.

When eBPF-based enforcement is combined with application-level context, security teams can connect the event to the exact package, function, call chain, and request responsible. This allows prevention to be applied more precisely without broadly blocking legitimate application behavior.

Protecting the Remediation Window

A permanent fix may require upgrading a package, changing code, testing compatibility, rebuilding the application, and deploying a new version.

Runtime prevention can reduce exposure during that period by blocking malicious behavior while engineering completes the permanent remediation.

It does not replace patching. It protects the running application while the fix moves through development and deployment.

Where Raven Fits

Raven is built for runtime application security.

Raven Runtime ADR connects suspicious application behavior to the exact library, function, call chain, process, container, image, node, and workload responsible.

Raven Runtime SCA identifies which open-source components are present, loaded, reachable, and executing in production. It helps teams distinguish package inventory from active exposure and separate malicious package behavior from exploitation of a legitimate dependency.

Raven Runtime Prevention stops dangerous execution when a malicious package, vulnerable function, zero-day, or CVE-less attack attempts to act.

Together, these capabilities help security teams understand what executed, identify the responsible application path, contain the immediate risk, and give engineering the evidence needed to complete remediation.

Conclusion: Malicious Code Is an Execution Problem

Malicious code is not only a file, malware, package, or CVE problem.

In modern applications, it is an execution problem.

A malicious package may introduce harmful code, but attackers can also exploit trusted dependencies and manipulate legitimate functions through application paths that have no published CVE.

Traditional controls provide important pieces of the picture. WAFs inspect traffic, EDR monitors workload activity, and SCA inventories packages and vulnerabilities.

Runtime application security connects those signals to what the code actually does when it executes. It helps teams determine whether behavior came from a malicious package, a vulnerable dependency, or trusted code being abused, then stop the action before execution turns into damage.

See how Raven stops malicious code at the moment of execution, with or without a CVE.

‍