Malware

Malware as an availability risk

Malware is software or code used to perform unwanted actions on a system. It may steal credentials, encrypt files, spy on users, alter application behaviour, open remote access, mine cryptocurrency, send spam, or place a device under an attacker's control. In DDoS and availability discussions, malware matters because compromised devices can become part of a botnet, compromised servers can attack others, and infected business systems can degrade or interrupt the services users depend on.

The word covers many families and behaviours: viruses, worms, trojans, ransomware, spyware, loaders, backdoors, droppers, bot agents, web shells, malicious browser extensions, and scripts inserted into websites. Defenders do not need to memorise every label before responding. They need to understand what the malware can do, how it persists, what data or systems are at risk, and whether the affected asset is now contributing to broader abuse.

Malware is not limited to laptops and servers. Routers, cameras, storage devices, industrial systems, phones, browser sessions, build systems, cloud workloads, containers, and website plugins can all be abused when they are exposed, outdated, misconfigured, or protected by weak credentials.

How malware connects to DDoS

Many DDoS events are powered by devices that have been compromised with malware. The owner of the device may notice nothing beyond slow performance or unusual network use, while the attacker uses the device as one source in a larger flood. Internet-of-things devices are common candidates because they are numerous, often left online for years, and may receive inconsistent patching. Cloud servers and compromised web applications can also be abused because they have better bandwidth than home devices.

Malware can also create denial of service inside the victim organisation. Ransomware can make critical files unavailable. A worm can saturate internal networks. A cryptominer can consume CPU and memory. A backdoor can allow an attacker to disable services or alter configuration. A web shell can turn a server into a launch point for outbound abuse, which may cause hosting providers, mail providers, or upstream networks to restrict the organisation's traffic.

This is why malware response should consider availability, confidentiality, and integrity together. A device might not contain sensitive data, but if it can send attack traffic, overload the network, or provide a path deeper into the environment, it is still a security risk.

Defender-relevant signs

Malware indicators vary by environment. Endpoint teams may see suspicious processes, unexpected scheduled tasks, new services, disabled security tools, unusual file changes, high CPU usage, browser redirects, unauthorised remote access, or alerts from endpoint detection tools. Network teams may see outbound connections to unfamiliar infrastructure, sudden traffic spikes, repeated failed connection attempts, unusual DNS queries, scanning behaviour, or traffic from devices that should be quiet.

Web and application teams should watch for modified files, unexpected administrator accounts, unfamiliar plugins, changed payment or form scripts, outbound spam, new cron jobs, suspicious uploads, or logins from unusual locations. In cloud environments, indicators may include new access keys, unexpected instances, altered security groups, unusual storage access, or workloads sending traffic that does not match their purpose.

No single indicator is definitive. Malware investigations usually combine telemetry: endpoint alerts, authentication logs, network flows, DNS, web server logs, cloud audit trails, file integrity, vulnerability data, and user reports. The goal is to determine scope. Is one workstation affected, or many? Is one website plugin compromised, or the hosting account? Is the device only infected, or is it actively communicating with attacker infrastructure?

Reducing the chance of infection

Malware defence starts with reducing easy entry points. Keep operating systems, browsers, applications, plugins, firmware, and dependencies patched. Remove unsupported software and exposed services that are no longer needed. Enforce strong authentication, especially for remote access, administrator panels, cloud consoles, source repositories, and content-management systems. Disable default credentials on appliances and embedded devices.

Least privilege limits damage. Users should not have administrator rights by default. Services should run with only the permissions they need. Cloud roles should be scoped to the workload. Website write access should be limited and auditable. Backups should be protected from the same credentials used by production systems.

Email, web, and download protections reduce common delivery paths, but they do not replace user training and process discipline. Staff should know how to report suspicious messages, unexpected login prompts, strange browser behaviour, and security warnings. Developers and administrators should treat secrets, build pipelines, plugins, and third-party scripts as part of the attack surface.

For availability specifically, network egress controls and monitoring are important. If a compromised device cannot freely scan the internet, contact arbitrary command infrastructure, or generate large outbound traffic, the organisation has more time to detect and contain it.

Containment and recovery

Malware response should be calm and evidence-based. The first priority is to stop ongoing harm without destroying the information needed to understand the incident. Depending on the environment, containment may mean isolating a host from the network, disabling an account, revoking a token, blocking outbound destinations, taking a service out of rotation, or preserving a disk image for analysis. The exact action should match business impact and legal requirements.

Eradication is more than deleting a suspicious file. Responders should identify the initial access path, remove persistence, patch the exploited weakness, rotate affected credentials, review accounts and keys, and check neighbouring systems. If the root cause remains, the malware may return after the first cleanup.

Recovery should verify that services are trustworthy before restoring them to normal traffic. For web applications, that may include checking file integrity, reviewing administrator accounts, auditing plugin versions, clearing malicious scheduled tasks, and confirming that outbound abuse has stopped. For endpoints, it may involve rebuilding devices rather than trusting manual cleanup.

Common misconceptions

One misconception is that malware is only a data-theft problem. It can be an availability problem, a fraud problem, a compliance problem, and an abuse problem at the same time.

Another misconception is that small devices are too unimportant to protect. A camera, router, or forgotten server can still participate in DDoS traffic, scan others, or provide an internal foothold.

A third misconception is that an antivirus alert means the incident is finished. A detection is the start of scope analysis. Teams still need to know how the malware arrived, what it changed, whether credentials were exposed, and whether other systems show related signs.

Planning for malware incidents

A practical malware plan defines owners for triage, containment, investigation, recovery, communications, and legal or regulatory review. It names the evidence sources responders need and the conditions under which systems may be isolated, rebuilt, or restored. It also defines how to preserve business continuity when a critical device, website, or administrator account must be taken offline.

Exercises should include messy scenarios: a website sending spam, an employee laptop beaconing to suspicious infrastructure, a server participating in outbound DDoS, or ransomware affecting a shared file store. After each exercise or real incident, improve patching, credential hygiene, logging, segmentation, backup protection, and egress controls. Malware resilience is not one tool. It is the combination of prevention, visibility, containment, and recovery that keeps compromised systems from becoming a wider outage.