When an alert fires or a user reports something strange, the first useful question is "what kind of attack could this be?" Knowing the common families, and what each one looks like from the inside of your systems, shortens that first hour considerably. It also tells you which controls are worth building before anything happens.

In part 3 we defined threat, vulnerability and risk. This part tours the attacks that most organisations actually face. It is written from the defender's side: the signs you would notice and the controls that stop or limit each attack. It deliberately contains no step-by-step attack techniques.

Malware: software with hostile intent

Malware is the umbrella term for software designed to harm, spy on or take control of a system. The families differ mostly in how they spread and what they do once inside.

Type How it spreads What it does Signs you might notice
Virus Attaches to files or documents, runs when they are opened Damages files, drops other malware Changed files, antivirus alerts
Worm Spreads by itself across networks through vulnerable services Rapid infection of many hosts Sudden scan traffic between internal hosts
Trojan Disguised as legitimate software Opens a backdoor, installs other tools New processes, unexpected outbound connections
Ransomware Usually delivered by phishing or exposed remote access Encrypts data and demands payment, often steals data first Mass file renames, high disk activity, ransom notes
Spyware and infostealers Bundled with fake software, malicious extensions Steals credentials, cookies, keystrokes Logins from unknown locations, session reuse
Botnet agent Any of the above Joins the host to a remote-controlled network Periodic outbound traffic to the same destinations

Controls that work across families:

  • Patch promptly, especially internet-facing services and remote access gateways. Worms and many ransomware groups depend on known, unpatched flaws.
  • Endpoint detection and response (EDR) on laptops and servers, with alerts that someone reads.
  • Least privilege: users without local admin rights, services without broad permissions.
  • Application allow-listing on servers where the set of programs is known.
  • Offline or immutable backups, tested by restoring, so ransomware cannot hold your data hostage.
  • Egress filtering: servers that do not need the internet should not reach it.

Infostealers deserve a special mention for developers. They steal browser session cookies and saved credentials, including tokens for source control, cloud consoles and CI systems. Short session lifetimes, hardware-backed MFA and alerting on token use from new locations limit the damage.

Phishing and social engineering

Phishing tricks a person into giving up credentials, approving a payment or running malware. It remains one of the most common initial access methods because it attacks people, not software.

  • Phishing: broad campaigns, the same message to many recipients.
  • Spear phishing: targeted at one person or team using real context, such as a supplier name.
  • Whaling: targeted at executives, often about payments or legal matters.
  • Business email compromise (BEC): the attacker controls or imitates a real mailbox and asks for a transfer or a change of bank details.

Signs: urgency, unusual requests, slightly wrong sender domains, login pages on unfamiliar domains, and requests to bypass the normal process.

Controls:

  • Phishing-resistant MFA (security keys or passkeys) so a stolen password is not enough.
  • SPF, DKIM and DMARC on your domains so attackers cannot easily send mail as you.
  • Out-of-band verification for payment and bank detail changes: call a known number, never the one in the email.
  • An easy report button and a team that responds quickly. Reports are your early warning system.

A later part of this series covers email security in more depth.

Denial of service

A denial of service (DoS) attack tries to make a service unavailable. A distributed denial of service (DDoS) attack does it from many sources at once, usually a botnet.

There are three broad kinds:

  • Volumetric: floods the network link with traffic, often using UDP amplification.
  • Protocol: exhausts connection tables in servers, load balancers or firewalls, for example with floods of half-open TCP connections.
  • Application layer: sends expensive but legitimate-looking requests, such as searches or login attempts, until the application runs out of capacity.

Controls:

  • A CDN or DDoS protection service in front of public endpoints absorbs volumetric attacks you cannot handle on your own link.
  • Rate limiting per client, per account and per endpoint, especially on login, search and export.
  • Caching so repeated requests do not reach the origin.
  • Autoscaling with limits and a plan for shedding non-essential load.
  • Not exposing origin servers directly, so attackers cannot bypass the protection layer.

Man-in-the-middle

In a man-in-the-middle (MITM) attack, the attacker sits between two parties and reads or modifies their traffic. It happens on untrusted Wi-Fi, through compromised routers, through DNS manipulation and when applications fail to validate certificates.

Signs are rare on the victim's side, which is why prevention matters more than detection.

Controls:

  • TLS everywhere, including internal service-to-service traffic.
  • HSTS on websites, so browsers refuse to downgrade to plain HTTP.
  • Never disable certificate validation in code, even "temporarily" for testing. Search your code base for flags that turn verification off.
  • DNSSEC and trusted resolvers where you control DNS.
  • Mutual TLS between internal services that handle sensitive data.

Injection and other application attacks

Injection attacks send input that the application treats as code: SQL injection, command injection, cross-site scripting and template injection. They exploit the gap between data and instructions.

Signs: errors containing database or parser messages, unusual characters in request logs, web application firewall alerts and unexpected queries in database logs.

Controls:

  • Parameterised queries and safe APIs instead of building commands from strings.
  • Output encoding by context (HTML, attribute, JavaScript, URL), ideally automatic through the template engine.
  • Allow-list validation for values such as sort fields and file names.
  • Least-privilege database users, so a successful injection cannot drop tables or read other schemas.
  • A content security policy to limit the damage of cross-site scripting.

Application security gets its own parts later in the series.

Credential attacks

Many breaches need no exploit at all; the attacker simply logs in. Credential stuffing reuses passwords leaked from other sites, password spraying tries a few common passwords against many accounts, and stolen session tokens skip the password entirely.

Controls: MFA, checking new passwords against known-breached lists, rate limiting and lockout with care to avoid locking out real users, monitoring for many failures from one source, and short-lived sessions bound to the device where possible.

What to build first

If you are starting from little, this order gives the most protection per hour of work for a typical software company:

  1. MFA on email, source control, cloud consoles and CI, preferably phishing-resistant.
  2. Automatic patching for internet-facing systems and laptops.
  3. Backups that attackers cannot delete, with a tested restore.
  4. A CDN or DDoS protection in front of public sites, with origin access locked down.
  5. EDR on endpoints, with alerts routed to a person.
  6. Parameterised queries and output encoding enforced in code review and linters.

Key takeaways

  • Malware families differ in how they spread and what they do; patching, least privilege, EDR and immutable backups cover most of them.
  • Phishing attacks people; phishing-resistant MFA and out-of-band verification defeat most of it.
  • DoS comes in volumetric, protocol and application flavours; put protection in front and rate-limit expensive endpoints.
  • MITM is prevented by TLS everywhere and never disabling certificate validation.
  • Injection is a data-versus-code problem solved by parameterisation and encoding.

The next part explains the cryptography that several of these controls rely on: encoding, encryption and hashing.

References