Email Spoofing, Suspicious Attachments & Dangerous Links

Overview

Attackers use a variety of technical tricks to make emails appear legitimate. Email spoofing forges sender details to impersonate trusted individuals or organizations. Suspicious attachments are the #1 delivery method for ransomware and other malware. Dangerous links lead to phishing pages, drive-by downloads, or exploit kits. This tutorial provides an in-depth technical examination of these attack vectors and how to defend against them.

Table of Contents

Part 1: Email Spoofing — Deep Dive

• 1.1 What is Email Spoofing?
• 1.2 Why is Email Spoofing Possible?
• 1.3 How Email Spoofing Works — Technical Details
• 1.4 Types of Spoofing — Complete Reference
• 1.5 Homograph Attack — Deep Dive
• 1.6 Email Authentication Protocols — Complete Technical Guide
• 1.7 SPF + DKIM + DMARC Full Workflow Diagram
• 1.8 How to Check SPF/DKIM/DMARC in Your Email
• 1.9 Spoofing Prevention Checklist

Part 2: Suspicious Attachments — Complete Guide

• 2.1 Why Attachments Are Dangerous
• 2.2 High-Risk File Types — Complete Reference
• 2.3 Common Malicious Attachment Techniques — Detailed
• 2.4 Real Example: The Macro Attack — Step by Step
• 2.5 Safe Attachment Handling — Complete Guide

Part 3: Dangerous Links — Complete Guide

• 3.1 Types of Malicious Links — Detailed
• 3.2 URL Structure — How to Read a URL Like a Security Pro

Part 4: Practical Defense Strategies

• 4.1 Complete Email Security Checklist
• 4.2 Security Tools Comparison
• 4.3 Browser Extensions for Email Security

Part 1: Email Spoofing — Deep Dive

1.1 What is Email Spoofing?

Email spoofing is the forgery of an email header's "From" address to make the message appear as if it came from someone other than the actual sender. It is a core technique used in virtually all phishing, spam, and BEC attacks. The spoofed sender is typically someone the recipient trusts — a boss, colleague, bank, or well-known company.

1.2 Why is Email Spoofing Possible?

The root cause is historical: the SMTP protocol (defined in RFC 821, 1982) was designed in an era when the internet was a small network of trusted academic and military institutions. Security was not a consideration.

SMTP's Original Design Flaw:

  RFC 821 (1982): The SMTP protocol specifies that the "From" address
  is simply a text field in the email envelope. There is NO built-in
  mechanism to verify that the sender is who they claim to be.

  Analogy: It's like sending a letter through the postal system where
  anyone can write any return address on the envelope — the postal
  service never checks if the return address actually belongs to the
  sender.

  Result: An attacker can set the "From" field to ANY value they want.

1.3 How Email Spoofing Works — Technical Details

Step 1: Attacker crafts an email using their own SMTP server or
        a compromised mail server (open relay)

Step 2: The raw SMTP transaction looks like this:

  EHLO attacker-server.com
  MAIL FROM: <ceo@company.com>          ← Forged envelope sender
  RCPT TO: <finance@company.com>        ← Real recipient
  DATA
  From: "CEO Name" <ceo@company.com>    ← Forged header From
  Reply-To: <attacker@evil.com>         ← Real Reply-To
  Return-Path: <attacker@evil.com>      ← Real Return-Path
  Subject: Urgent: Wire Transfer
  
  Hi, I need you to wire $50,000...
  .
  QUIT

Step 3: Receiving server checks:
  - Is the sender IP in the SPF record for company.com?
    → If NO SPF or SPF=fail → Email may still be delivered
  - Is the DKIM signature valid?
    → If no DKIM → Email delivered anyway
  - What does the DMARC policy say?
    → If no DMARC → Email delivered to Inbox

Step 4: If authentication checks fail AND there's no DMARC policy
        (p=none), the email goes straight to the Inbox 
        appearing to come from the CEO.

1.4 Types of Spoofing — Complete Reference

1.5 Homograph Attack — Deep Dive

Attackers use internationalized domain names (IDN) — characters from different scripts (Cyrillic, Greek, etc.) that look identical to Latin letters.

Look-Alike Character Table

Example: The domain fаcebook.com (with Cyrillic 'а', U+0430) looks EXACTLY like facebook.com in most browsers and fonts. The user cannot tell the difference visually.

One Notable Attack: "vlc" Homograph Attack

In 2017, security researchers discovered that the domain "vlc."
(Cyrillic 'с' at the end) looked exactly like "vlc." and had
an SSL certificate. This could be used to phish users of the
VLC media player.

Browsers have since implemented "Punycode" display — showing
xn--... instead of the fake Unicode characters — but not all
mail clients do this.

1.6 Email Authentication Protocols — Complete Technical Guide

SPF (Sender Policy Framework) — RFC 7208

SPF allows domain owners to publish which IP addresses are authorized to send email on behalf of their domain.

How SPF Works:

1. Domain owner publishes an SPF record as a TXT record in DNS:
   example.com TXT "v=spf1 ip4:192.168.1.0/24 include:_spf.google.com ~all"

2. Receiving server gets email from IP 203.0.113.5 claiming to be from @example.com

3. Receiving server looks up SPF record for example.com

4. Server checks: Is 203.0.113.5 in the allowed list?
   - 192.168.1.0/24 → No
   - _spf.google.com → No (203.0.113.5 is not Google's IP)
   - Result: SPF FAIL

SPF Mechanisms:
  ┌──────────┬─────────────────────────────────────┐
  │ ip4      │ Allow specific IPv4 or range          │
  │ ip6      │ Allow specific IPv6 or range          │
  │ include  │ Include another domain's SPF record   │
  │ a        │ Allow domain's A record IP            │
  │ mx       │ Allow domain's MX record IPs          │
  │ exists   │ Check if a domain exists              │
  │ all      │ Match all (catch-all)                 │
  └──────────┴─────────────────────────────────────┘

SPF Qualifiers:
  + (pass)  → IP is authorized (default, can be omitted)
  - (fail)  → IP is NOT authorized (hard fail)
  ~ (softfail) → Probably not authorized (soft fail)
  ? (neutral) → No claim either way

Example: v=spf1 mx -all
  → Only the domain's mail servers can send email
  → Everything else is a hard fail

DKIM (DomainKeys Identified Mail) — RFC 6376

DKIM adds a digital signature to each email that verifies:

1. The email actually came from the claimed domain
2. The email was NOT tampered with during transit

DKIM Signing Process:

                       ┌─────────────────┐
                       │ Private Key     │
                       │ (Keep secret!)  │
                       └────────┬────────┘
                                ↓
  ┌─────────────────────────────────────────────┐
  │ DKIM Signer creates a hash of the email     │
  │ body + selected headers                     │
  │ Encrypts the hash with the PRIVATE KEY      │
  │ Adds DKIM-Signature header to the email     │
  └─────────────────────────────────────────────┘
                                ↓
                    Email sent to recipient
                                ↓
  ┌─────────────────────────────────────────────┐
  │ DKIM Verifier looks up the PUBLIC KEY in DNS │
  │ Selector: google._domainkey.example.com      │
  │ Decrypts the signature using PUBLIC KEY      │
  │ Recomputes the hash from the email           │
  │ If hashes match → DKIM PASS ✓               │
  │ If hashes differ → DKIM FAIL ✗              │
  └─────────────────────────────────────────────┘

DKIM-Signature Header Example:
  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
                  d=example.com; s=google;
                  h=from:to:subject:date;
                  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
                  b=GwBkf4jK...

Key Fields:
  v=       DKIM version (always 1)
  a=       Signing algorithm (rsa-sha256 most common)
  c=       Canonicalization method (simple/relaxed)
  d=       Domain (the signer's domain)
  s=       Selector (points to DNS record for public key)
  h=       Signed headers (comma-separated list)
  bh=      Body hash (base64-encoded)
  b=       Signature (base64-encoded)

DMARC (Domain-based Message Authentication, Reporting & Conformance) — RFC 7489

DMARC tells receiving mail servers what to do if SPF or DKIM fails. It also provides reporting so domain owners can see who is sending email on their behalf.

DMARC DNS Record:
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100; sp=reject"

DMARC Tags:
  ┌──────────┬──────────────────────────────────────────┐
  │ v=       │ DMARC version (always DMARC1)             │
  │ p=       │ Policy for the domain:                    │
  │          │   none → No action (monitor only)         │
  │          │   quarantine → Send to spam/junk folder  │
  │          │   reject → Reject the email entirely     │
  │ sp=      │ Policy for subdomains (optional)          │
  │ rua=     │ Reporting URI for aggregate reports       │
  │ ruf=     │ Reporting URI for forensic reports        │
  │ pct=     │ Percentage of emails to apply policy to   │
  │ fo=      │ Forensic reporting options                │
  │ adkim=   │ DKIM alignment mode (s=strict, r=relaxed) │
  │ aspf=    │ SPF alignment mode (s=strict, r=relaxed)  │
  └──────────┴──────────────────────────────────────────┘

DMARC Alignment:
  SPF Alignment:
    - The domain in the Envelope From (Return-Path) must match
      the domain in the Header From (visible From address)
    - relaxed (r): subdomain matches (e.g., mail.example.com alignes with example.com)
    - strict (s): exact match required

  DKIM Alignment:
    - The domain in the DKIM signature (d=) must match
      the domain in the Header From address
    - Same relaxed/strict options as SPF

DMARC Processing Logic:
  ┌─────────────────────────────────────────────────────────────┐
  │                                                             │
  │  Email received claiming to be From: user@example.com       │
  │                                                             │
  │  ┌──────────┐    ┌───────────┐                              │
  │  │ SPF Check│    │ DKIM Check│                              │
  │  └────┬─────┘    └─────┬─────┘                              │
  │       │                │                                    │
  │       ▼                ▼                                    │
  │  ┌──────────────────────────────────┐                       │
  │  │         DMARC Evaluation         │                       │
  │  │                                  │                       │
  │  │  SPF passes AND aligns?    OR     │                       │
  │  │  DKIM passes AND aligns?         │                       │
  │  │                                  │                       │
  │  │  YES → DMARC pass ✓              │                       │
  │  │  NO  → Apply policy (p=)         │                       │
  │  │        none    → Deliver         │                       │
  │  │        quarantine → Spam folder  │                       │
  │  │        reject  → Bounce/Delete   │                       │
  └─────────────────────────────────────────────────────────────┘

1.7 SPF + DKIM + DMARC Full Workflow Diagram

┌────────────┐    ┌───────────────────────────────────────────────┐
│   Sender   │    │   Email Headers Added by Sender's Server     │
│  Server    │    │                                               │
│  IP: X     │───→│  From: user@example.com                      │
└────────────┘    │  DKIM-Signature: d=example.com; s=selector;  │
                  │                   b=[signature]               │
                  │  Return-Path: user@example.com               │
                  └──────────────────────┬────────────────────────┘
                                         ↓
                  ┌───────────────────────────────────────────────┐
                  │           Recipient's Mail Server             │
                  │                                               │
                  │  1. DNS Lookup: SPF record for example.com    │
                  │     Query: example.com TXT                    │
                  │     Result: v=spf1 include:_spf.google.com    │
                  │              ip4:209.85.128.0/17 -all         │
                  │     Check: Is sender IP X in allowed list?    │
                  │     Result: ✅ PASS / ❌ FAIL                 │
                  │                                               │
                  │  2. DNS Lookup: DKIM public key               │
                  │     Query: selector._domainkey.example.com TXT │
                  │     Result: v=DKIM1; k=rsa; p=[public key]    │
                  │     Verify: Decrypt signature, check hash     │
                  │     Result: ✅ PASS / ❌ FAIL                 │
                  │                                               │
                  │  3. DNS Lookup: DMARC policy                  │
                  │     Query: _dmarc.example.com TXT             │
                  │     Result: v=DMARC1; p=reject; rua=...       │
                  │     Evaluate: SPF+align OR DKIM+align?        │
                  │     Result: ✅ DMARC pass → Deliver           │
                  │              ❌ DMARC fail → Apply p=reject   │
                  └───────────────────────────────────────────────┘

1.8 How to Check SPF/DKIM/DMARC in Your Email

In Gmail:
  1. Open the email
  2. Click the three dots (⋮) next to Reply
  3. Click "Show original"
  4. Look for:
     spf=pass (or fail)
     dkim=pass (or fail)
     dmarc=pass (or fail)

In Outlook (Web):
  1. Open the email
  2. Click the three dots (⋮) in the top-right
  3. Click "View message details"
  4. Look for Authentication-Results header

Example of good authentication:
  Authentication-Results: mx.google.com;
     spf=pass (google.com: domain of user@example.com designates 209.85.220.41 as permitted sender)
     dkim=pass header.i=@example.com header.s=google header.b=GwBkf4jK;
     dmarc=pass (p=REJECT, sp=REJECT, dis=NONE)
     arc=pass (i=1)

Example of failed authentication (spoofed):
  Authentication-Results: mx.google.com;
     spf=softfail (google.com: domain of transitioning user@spoofed.com does not designate 198.51.100.45 as permitted sender)
     dkim=fail header.i=@spoofed.com header.s=bad header.b=XYZ;
     dmarc=fail (p=QUARANTINE, sp=REJECT, dis=QUARANTINE)

1.9 Spoofing Prevention Checklist

📎 Part 2: Suspicious Attachments — Complete Guide

2.1 Why Attachments Are Dangerous

Email attachments are one of the most common ways to deliver malware because they exploit human trust and curiosity. A well-named file can bypass technical defenses because someone has to intentionally open it.

Once an attachment is opened, it can:
  • Install ransomware — Encrypt all files, demand payment in crypto
  • Install spyware — Monitor keystrokes, capture passwords, record screens
  • Install RAT — Give attacker remote control of your computer
  • Execute macros — Download additional malware from the internet
  • Exploit vulnerabilities — Use a bug in the reader app (PDF, Word, etc.)
  • Create backdoors — Allow persistent access for future attacks
  • Steal credentials — Extract saved passwords from browsers
  • Join botnet — Make your computer part of a spam/malware network

2.2 High-Risk File Types — Complete Reference

2.3 Common Malicious Attachment Techniques — Detailed

2.4 Real Example: The Macro Attack — Step by Step

Email Arrives:
  From:    accounts.payable@supplier-company.com
  Subject: Payment Overdue — Invoice INV-2024-8934
  Body:    "Dear Accounts Payable,
            Our records show that invoice INV-2024-8934 dated
            June 15, 2024 for $12,847.50 is now overdue.
            Please find the updated invoice attached.
            
            Regards,
            Sarah Chen, Accounts Receivable"
  Attachment: Invoice_2024.docm (85 KB)

What Happens When Opened:
  ┌──────────────────────────────────────────────────────┐
  │                                                      │
  │  Step 1: User double-clicks the attachment           │
  │          Microsoft Word opens in Protected View      │
  │          (Read-only mode, macros disabled)           │
  │                                                      │
  │  Step 2: User sees blurred/grayed-out document with  │
  │          yellow bar: "This document contains macros.  │
  │          Enable Content to view the document."       │
  │                                                      │
  │  Step 3: User thinks: "I need to see the invoice"    │
  │          → Clicks "Enable Content"                    │
  │                                                      │
  │  Step 4: The macro executes:                         │
  │          • PowerShell commands injected in macro      │
  │          • Connects to C2 server at 203.0.113.50     │
  │          • Downloads BlackByte ransomware payload     │
  │          • Ransomware encrypts entire C: drive        │
  │          • Displays ransom note:                     │
  │            "Your files are encrypted. Send 3 BTC to   │
  │             this wallet: bc1q... to restore access."  │
  │                                                      │
  │  Result: Entire company network infected             │
  │          Downtime: 2+ weeks                          │
  │          Ransom demand: $500,000                     │
  │          Recovery cost: $2.3 million (IBM 2023)      │
  └──────────────────────────────────────────────────────┘

2.5 Safe Attachment Handling — Complete Guide

🔗 Part 3: Dangerous Links — Complete Guide

3.1 Types of Malicious Links — Detailed

3.2 URL Structure — How to Read a URL Like a Security Pro

URL Anatomy:

  🔗 https://accounts-google.com.secure-login.tk/login?redirect=https://evil.com

  Scheme:  https://
           └── Encrypted connection (but doesn't guarantee safety!)
  
  Subdomain: accounts-google.com
              └──────────┬──────────┘
                    This is a SUBDOMAIN of secure-login.tk
                    NOT a subdomain of google.com!
  
  Domain:   secure-login.tk
              └──────┬─────┘
                 The ACTUAL domain is "secure-login.tk"
                 .tk is a free TLD commonly used by phishers
  
  TLD:      .tk
              └─ Tokelau TLD — often free and abused by attackers
  
  Path:     /login
              └─ Tries to look like a legitimate login page
  
  Query:    ?redirect=https://evil.com
              └─ After "login", redirects the victim to a malicious site

✅ LEGITIMATE:  https://accounts.google.com/login
                    └──────┬──────┘ └┬┘ └──┬──┘
                    Subdomain   Domain  Path
                    (Google's)  (Google) (Legit)

❌ PHISHING:    https://accounts-google.com.secure-login.tk/login
                    └──────────────┬──────────────┘
                    This is ALL a subdomain of secure-login.tk!

3.3 How to Inspect Links — Complete Guide

On Desktop (Windows/Mac/Linux):

Method 1: Hover with Mouse
  ┌─────────────────────────────────────────────────────┐
  │ 1. Move your mouse cursor OVER the link              │
  │    (DO NOT click!)                                   │
  │ 2. Look at the bottom-left corner of your browser    │
  │    The REAL URL will appear there                    │
  │ 3. Compare the displayed text with the actual URL    │
  └─────────────────────────────────────────────────────┘

Method 2: Right-Copy + Paste
  ┌─────────────────────────────────────────────────────┐
  │ 1. RIGHT-CLICK the link (not left-click!)            │
  │ 2. Select "Copy link address" or "Copy link location"│
  │ 3. Open Notepad or text editor                       │
  │ 4. Paste the URL and inspect it carefully            │
  └─────────────────────────────────────────────────────┘

Method 3: Browser Developer Tools
  ┌─────────────────────────────────────────────────────┐
  │ 1. RIGHT-CLICK the link                             │
  │ 2. Select "Inspect" or "Inspect Element"             │
  │ 3. Look at the href="" attribute in the HTML         │
  │ 4. The actual destination is in the href value       │
  └─────────────────────────────────────────────────────┘

Checklist for Desktop Link Inspection:
  □ Domain name spelled correctly?
  □ Unexpected TLD? (not .com, .org, etc.)
  □ Subdomain tricks? (google.com.phishing.com)
  □ URL encoding? (%3F, %2F, @ symbol)
  □ Hyphens in domain? (google-login.com)
  □ Look-alike characters? (g00gle, rnicrosoft)

On Mobile (Android/iOS):

Method 1: Long Press
  ┌─────────────────────────────────────────────────────┐
  │ 1. PRESS AND HOLD (long press) the link              │
  │ 2. Wait for the popup menu                          │
  │ 3. Look at the URL shown in the popup               │
  │ 4. Tap "Copy link address" or "Copy URL"            │
  │ 5. Open Notes app → Paste → Inspect                  │
  │ 6. DO NOT tap "Open" or "Go"                       │
  └─────────────────────────────────────────────────────┘

Method 2: Share Link
  ┌─────────────────────────────────────────────────────┐
  │ 1. Long press the link                             │
  │ 2. Tap "Share" or "Copy"                         │
  │ 3. Send to a note-taking app or yourself           │
  │ 4. Inspect the pasted URL carefully                │
  └─────────────────────────────────────────────────────┘

3.4 URL Shortener Dangers — Complete Breakdown

⚠️ Never click shortened URLs without inspecting them first! Always use a URL expansion/preview service:

• checkshorturl.com — Preview where a shortened URL goes
• unshorten.me — Show the full destination URL
• urlscan.io — Scan the destination for malicious content
• virustotal.com — Check if the URL is known malicious

3.5 URL Analysis — Advanced Techniques

Check Domain Age (New domains = Suspicious)

A brand new domain (registered in the last 30-90 days) is more likely
malicious. Use WHOIS lookup tools:

  whois.domaintools.com   → Check domain creation date
  whois.icann.org          → Official ICANN lookup
  who.is                   → Quick WHOIS check

Red Flags:
  • Domain created < 30 days ago → 🔴 Very suspicious
  • Domain created 30-90 days ago → 🟠 Moderately suspicious
  • Domain created > 1 year ago   → 🟢 More likely legitimate
  • Privacy WHOIS + new domain    → 🔴 Highly suspicious

Check URL Reputation

Use URL scanning services to check if a URL is malicious:

  virustotal.com          → Scans URL with 70+ antivirus engines
  urlscan.io              → Takes a screenshot + analyzes all resources
  google.com/safebrowsing → Google's Safe Browsing check
  ipqualityscore.com      → Fraud detection and risk scoring
  abuseipdb.com           → Check if the IP is known for abuse

Example VirusTotal Result:
  URL: https://bit.ly/3xK9m2P
  Detections: 12/70 (17%)
  Categories:
    - Phishing: 8 engines
    - Malware: 3 engines
    - Spam: 1 engine
  Verdict: ⚠ MALICIOUS

Check SSL Certificate

  ❌ Myth: "HTTPS = Safe"
  ✅ Truth: HTTPS only means the connection is encrypted.
               93% of phishing sites now use HTTPS!

  What to check in the certificate:
    • Issued to: Does the company name match the expected site?
    • Valid from: Was it issued recently (possible sign of phishing)?
    • Certificate Authority: Is it a trusted CA?

  Tool: Click the padlock icon in the address bar → View certificate

3.6 Google Safe Browsing & SmartScreen

How to enable:

• Chrome: Settings → Privacy and security → Security → Enhanced protection
• Edge: Settings → Privacy, search, and services → Microsoft Defender SmartScreen

3.7 Browser Extensions for Link Protection

Part 4: Practical Defense Strategies

4.1 Complete Email Security Checklist

□ DOMAIN AUTHENTICATION:
  □ SPF record published with -all (hard fail)
  □ DKIM signing implemented for all outgoing mail
  □ DMARC policy published (p=reject preferred)
  □ DMARC reporting configured to monitor abuse

□ EMAIL GATEWAY:
  □ Advanced spam/phishing filters enabled
  □ Attachment scanning enabled
  □ Malicious file types blocked (.exe, .vbs, .js, .iso, etc.)
  □ Password-protected archives blocked
  □ Suspicious link rewriting (Safe Links or equivalent)
  □ Sandboxing for unknown attachments

□ ENDPOINT PROTECTION:
  □ Macros disabled by default in Office
  □ File extensions set to "Always show"
  □ Protected View enabled for Office documents
  □ ASR (Attack Surface Reduction) rules configured
  □ Antivirus with real-time protection

□ USER TRAINING:
  □ Regular security awareness training (quarterly)
  □ Phishing simulation campaigns (monthly)
  □ Clear policy for reporting suspicious emails
  □ No-blame culture around reporting

□ INCIDENT RESPONSE:
  □ Documented incident response plan for email attacks
  □ Designated contact for reporting (security@company.com)
  □ Out-of-band verification process for payment requests
  □ Dual approval for wire transfers over threshold

4.2 Tools for Email Security Analysis

4.3 Browser Security Configuration

📝 Practice Questions

1. How does SPF help prevent email spoofing? Explain the SPF check process step by step.
2. What is the difference between DKIM and DMARC? How do they work together?
3. What is a homograph attack and how can you detect one in a URL?
4. List 6 high-risk attachment file types and explain why each is dangerous.
5. How can you inspect a link on mobile before clicking it? Give 2 methods.
6. What is the difference between typosquatting and combosquatting?
7. Why is HTTPS not a reliable indicator of a safe website?
8. What steps should your organization take to configure DMARC properly?
9. How does a macro malware attack work from start to finish?
10. What are URL shorteners and how do attackers abuse them?