Attack Vector

An attack vector is the route an attacker takes into a system: the specific combination of exposure and technique that turns a weakness into access. It is distinct from the vulnerability itself — the vulnerability is the flaw, the vector is how it gets reached.

Email is the most heavily used attack vector against organisations, for a structural reason: it is the one service that accepts unsolicited input from strangers by design, and it delivers that input to a human being.

Which attack vectors target email users?

These aim at the person, not the software:

• Phishing — a message impersonating a trusted party to harvest credentials, usually through a link to a convincing login page. Credentials for the mail system itself are the highest-value target, because they unlock everything else.
• Business email compromise (BEC) — a targeted request, apparently from an executive or a supplier, to change payment details or make a transfer. There is typically no link and no attachment, which is precisely why content filters miss it.
• Malware attachments — archives and macro-enabled documents disguised as invoices, delivery notes or scanned documents. See abuse for what these look like in practice.
• Thread hijacking — a reply injected into a genuine existing conversation from a compromised participant. The context is real, so the usual cues are absent.

Which attack vectors target the mail server?

These aim at the infrastructure:

• Credential stuffing against SMTP AUTH, IMAP and POP. Reused passwords tried at scale against the submission service. This is the single most common route to a compromised mailbox, and the resulting outbound spam is what gets the sending IP blacklisted.
• Open relay exploitation. A server that accepts mail for destinations it does not host is used to launder someone else’s spam. Almost always the result of an over-broad ACL or mynetworks entry.
• Directory harvest attacks. Bulk RCPT TO probing to enumerate which addresses exist, producing a list to sell or to target.
• Web form and application injection. Contact forms and web applications that hand unvalidated input to the local MTA, letting an attacker add recipients or headers.
• Protocol and parser vulnerabilities. Flaws in the MTA or in the content scanner, reachable by anyone who can open a connection to port 25. These are rare but severe, since they need no user interaction at all.

Which attack vectors abuse email without touching your systems?

Some vectors damage you without any compromise on your side:

• Domain spoofing. Forging your domain in the From: header of mail sent from somewhere else entirely. SPF, DKIM and DMARC exist so receivers can detect this; without a DMARC policy, they mostly cannot.
• Lookalike domains. Registering exarnple.com or example-invoices.com and sending from it. The mail authenticates perfectly — for the wrong domain.
• Backscatter. Bounce messages for spam that forged your address, flooding a mailbox you control and damaging your reputation through traffic you never generated.
• Subscription bombing. Signing an address up to thousands of mailing lists to bury a specific message, such as a fraud alert or an order confirmation.

How are email attack vectors reduced?

There is no single control, but the ones that remove whole classes of vector are worth prioritising:

1. Multi-factor authentication on mail access, which removes credential stuffing as a route regardless of password quality.
2. A closed relay policy and narrow allow lists, so the server cannot be used by anyone who has not authenticated.
3. SPF, DKIM and a DMARC policy at reject, which makes spoofing your domain detectable by receivers and eventually unprofitable.
4. Attachment type policy at the gateway, since blocking executables and macro-enabled documents outright is more reliable than trying to determine whether a given one is malicious.
5. Rate limits and alerting per authenticated account, which turn a successful compromise into a contained incident rather than an IP-range listing.
6. A monitored abuse@ address, so that when something does get through, you hear about it from a report rather than from a blocklist. See abuse desk.