How to Prevent Phishing Attacks: Technical and Organizational Controls
A comprehensive guide to phishing prevention covering URL filtering, email gateway scanning, anti-impersonation controls, lookalike domain monitoring, and phishing simulation programs.
Phishing is the entry point for over 90% of successful cyberattacks. It works not because technical defenses are absent, but because it targets the human element — and humans, under time pressure or impersonation of authority, make mistakes. Effective phishing prevention requires layered technical controls that reduce the volume and effectiveness of attacks, combined with organizational controls that reduce the likelihood of human error when attacks do reach inboxes.
The Modern Phishing Threat Landscape
Modern phishing has evolved well beyond "Nigerian prince" emails. Sophisticated attacks include:
Spear phishing: Highly personalized attacks targeting specific individuals using information harvested from LinkedIn, company websites, and social media. An attacker who knows you're expecting an invoice from a vendor can craft a convincing impersonation.
Business Email Compromise (BEC): Impersonation of executives, vendors, or partners to initiate wire transfers, change payroll bank accounts, or exfiltrate sensitive information. BEC causes billions in losses annually.
Adversary-in-the-Middle (AiTM) phishing: Phishing sites that proxy your real authentication page in real time, capturing both the credential and the MFA token simultaneously, then replaying them to the real site. This defeats SMS and app-based TOTP MFA.
Vendor and supply chain phishing: Compromising a trusted vendor's email account and sending phishing from that legitimate account. Your email gateway trusts it because the sender domain is real and authenticated.
Email Gateway Scanning and Filtering
Your email gateway is the first technical layer. Modern secure email gateways (SEGs) — Microsoft Defender for Office 365, Proofpoint, Mimecast, Google Workspace Advanced Protection — provide:
URL Rewriting and Time-of-Click Scanning
URLs in emails are rewritten to pass through the gateway's proxy. When a user clicks the link, the gateway scans the destination page in real time and blocks it if it matches phishing patterns.
Configuration for Microsoft Defender for Office 365:
# Enable Safe Links for all users
Set-SafeLinksPolicy -Identity "Default" `
-EnableSafeLinksForEmail $true `
-EnableSafeLinksForTeams $true `
-EnableSafeLinksForOffice $true `
-ScanUrls $true `
-EnableForInternalSenders $true `
-DeliverMessageAfterScan $true `
-AllowClickThrough $false `
-EnableOrganizationBranding $false
# Apply to all users
New-SafeLinksRule -Name "Safe Links for All" `
-SafeLinksPolicy "Default" `
-RecipientDomainIs "yourcompany.com"
AllowClickThrough $false is critical — it prevents users from bypassing the block warning.
Anti-Impersonation: DMARC, DKIM, and SPF Enforcement
Configure your gateway to reject emails that fail authentication. A DMARC policy of p=reject at your domain prevents anyone from spoofing your domain in the From header. But you also need to enforce DMARC at the gateway for inbound mail:
# Microsoft Defender: enable DMARC rejection for inbound mail
Set-AntiPhishPolicy -Identity "Default" `
-EnableMailboxIntelligence $true `
-EnableMailboxIntelligenceProtection $true `
-MailboxIntelligenceProtectionAction Quarantine `
-EnableSpoofIntelligence $true `
-AuthenticationFailAction Quarantine `
-EnableFirstContactSafetyTips $true
For your own sending domain, ensure your DMARC policy is at enforcement:
_dmarc.yourcompany.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:dmarc-forensic@yourcompany.com; pct=100; adkim=s; aspf=s"
p=reject tells receiving mail servers to discard any email from your domain that fails DMARC. adkim=s and aspf=s set strict alignment, requiring the DKIM signature domain and SPF EHLO domain to exactly match your From domain.
Anti-Impersonation for Executives and Key Roles
Configure impersonation protection for executives and other high-value targets:
# Protect specific executives from impersonation
Set-AntiPhishPolicy -Identity "Default" `
-EnableTargetedUserProtection $true `
-TargetedUsersToProtect @(
"CEO Name;ceo@yourcompany.com",
"CFO Name;cfo@yourcompany.com",
"CISO Name;ciso@yourcompany.com"
) `
-TargetedUserProtectionAction Quarantine `
-EnableTargetedDomainsProtection $true `
-TargetedDomainsToProtect @("yourcompany.com", "yourparentcompany.com") `
-TargetedDomainProtectionAction Quarantine
This blocks emails where the display name says "CEO Name" but the actual sending address is ceo@gmail.com or any other non-company domain.
URL Filtering at the Endpoint
URL filtering at the DNS or proxy level provides a second layer of protection after the email gateway. Even if a phishing email reaches the inbox and the user clicks the link, URL filtering can block the connection to the phishing site.
DNS-Based URL Filtering
Configure endpoints to use a DNS resolver with phishing protection:
Cloudflare Gateway (Zero Trust):
# Configure the DNS-over-HTTPS endpoint for Cloudflare Gateway
# Your team's gateway URL with phishing + malware filtering
# https://YOUR_TEAM.cloudflare-gateway.com/dns-query
Categories to block in Cloudflare Gateway:
- Phishing
- Newly Registered Domains (filter for 30 days after registration)
- Dynamic DNS (common for malware C2 and phishing infrastructure)
Quad9 (free, blocks phishing/malware domains):
# Set DNS to 9.9.9.9 / 149.112.112.112 on all endpoints
# On macOS via MDM (Jamf):
defaults write /Library/Preferences/SystemConfiguration/preferences.plist \
NetworkServices.DNS.ServerAddresses -array "9.9.9.9" "149.112.112.112"
Proxy-Based Web Filtering
For environments with a web proxy (Zscaler, Cisco Umbrella, Palo Alto Prisma), configure URL categories:
- Block: Phishing, Newly Registered Domains, Dynamic DNS
- Inspect SSL: Decrypt HTTPS traffic to phishing-prone categories
- Alert: File downloads from uncategorized domains, password field submissions to non-allowlisted sites
Lookalike Domain Monitoring
Attackers register domains that visually resemble your domain to run phishing campaigns that appear legitimate. Common techniques:
| Your Domain | Lookalike Technique | Example |
|---|---|---|
yourcompany.com | Typosquatting | youcompany.com, yourcompamy.com |
yourcompany.com | Homoglyph attack | yоurcompany.com (Cyrillic 'о') |
yourcompany.com | TLD variation | yourcompany.net, yourcompany.co |
yourcompany.com | Subdomain impersonation | yourcompany.com.attacker.xyz |
yourcompany.com | Keyword addition | yourcompany-support.com, yourcompany-secure.com |
Automated Lookalike Detection
import itertools
import re
from typing import Generator
def generate_typosquats(domain: str) -> Generator[str, None, None]:
"""Generate common typosquatting variations."""
name, tld = domain.rsplit('.', 1)
# Missing letter
for i in range(len(name)):
yield f"{name[:i]}{name[i+1:]}.{tld}"
# Transposition
for i in range(len(name) - 1):
transposed = name[:i] + name[i+1] + name[i] + name[i+2:]
yield f"{transposed}.{tld}"
# Common character substitutions
substitutions = {
'o': '0', 'i': '1', 'l': '1', 'e': '3', 'a': '4', 's': '5'
}
for char, substitute in substitutions.items():
if char in name:
yield f"{name.replace(char, substitute)}.{tld}"
# Common additions
for keyword in ['secure', 'support', 'login', 'account', 'verify']:
yield f"{name}-{keyword}.{tld}"
yield f"{keyword}-{name}.{tld}"
# Common TLD variations
for alt_tld in ['net', 'co', 'io', 'org', 'info']:
if alt_tld != tld:
yield f"{name}.{alt_tld}"
def check_domain_registration(domain: str) -> bool:
"""Check if a domain is registered (simplified)."""
import socket
try:
socket.gethostbyname(domain)
return True
except socket.gaierror:
return False
Use tools like dnstwist for production lookalike monitoring:
pip install dnstwist
# Generate and check all variants
dnstwist --registered --format json yourcompany.com > lookalikes.json
# Check for MX records (indicates active email sending)
dnstwist --registered --mxcheck yourcompany.com
Integrate into a weekly cron job and alert when new registered lookalikes are found. File domain abuse reports via registrar abuse contacts or ICANN for clear impersonation cases.
Phishing Simulation Programs
Technical controls reduce phishing volume. Phishing simulations improve employee behavior when phishing does reach inboxes.
Designing Effective Simulations
Effective simulation programs:
-
Vary difficulty levels: Don't only send obvious phishing. Include sophisticated spear phishing that uses publicly available information about the target.
-
Simulate current threat patterns: AiTM phishing, QR code phishing (QR codes bypass URL scanning), and voicemail-attached phishing are active techniques.
-
Educate at the moment of failure: When a user clicks a simulated phishing link, immediately show a training page explaining what indicators they should have recognized.
-
Measure and improve: Track click rate, report rate, and credential submission rate by department and over time. A declining click rate and improving report rate indicate the program is working.
-
Don't punish, train: Simulations should feel like a learning opportunity, not a gotcha. Organizations that use simulation results for HR disciplinary action see reporting rates drop as employees fear getting colleagues in trouble.
Reporting Mechanism
Make it easy to report phishing. The Microsoft Defender "Report Message" add-in and Google's built-in phishing report button are standard. For non-standard email clients, provide a dedicated email alias:
phishing@yourcompany.com
Configure an auto-responder that acknowledges the report and provides feedback on whether it was a real phishing attempt or a simulation:
Thank you for reporting a suspicious email!
Our security team has received your report and will investigate.
If this was a phishing simulation, you'll hear back within 24 hours.
If this was a real phishing attempt, we'll notify you of any actions taken.
Reporting suspicious emails keeps our company safer.
— Security Team
Employees who report phishing (real or simulated) should be praised, not ignored. This encourages the behavior and creates a human sensor network for attacks that bypass technical controls.
Phishing-Resistant MFA
Standard TOTP and push MFA are vulnerable to AiTM phishing. Phishing-resistant MFA uses protocols that cryptographically bind authentication to the origin:
FIDO2/WebAuthn hardware keys (YubiKey, Google Titan): The key signs a challenge that includes the domain. Phishing sites cannot use the signed response because the domain doesn't match.
Passkeys: Same cryptographic binding as FIDO2 but stored in the platform authenticator (Apple Keychain, Google Password Manager, Windows Hello). Passkeys cannot be phished because the signing operation requires the browser to verify the requesting domain matches where the passkey was registered.
Requiring FIDO2 or passkeys for privileged access (VPN, admin consoles, cloud provider access) provides the strongest anti-phishing guarantee available today. Even a sophisticated AiTM attack that captures a session cookie cannot obtain the FIDO2 assertion needed for a fresh authentication from a different origin.
Deploying phishing-resistant MFA for all users requires an identity provider that supports it (Okta, Azure AD, Google Workspace) and compatible devices. A phased approach — starting with executives and privileged users, then rolling out broadly — is the practical deployment path.