How to navigate Adversary‑in‑the‑Middle (AitM) attacks

Security leaders, email admins, and web teams who need a clear, actionable plan to stop Adversary‑in‑the‑Middle (AITM) techniques that target email and TLS/HTTPS. Focus areas include DNS spoofing, email hijacking/domain spoofing, SMTP STARTTLS downgrades, HTTPS spoofing, SSL/TLS stripping, and TLS hijacking.

• Enforce DMARC at p=reject to block exact domain impersonation and reduce email-borne AITM.
• Deploy MTA‑STS + TLS‑RPT (or DANE where supported) to prevent SMTP downgrade or impersonation attacks by enforcing encrypted, authenticated delivery of incoming emails.
• Use DNSSEC + CAA to harden certificate issuance pathways and mitigate DNS spoofing.
• Enable HSTS (with preload) to neutralize SSL stripping in browsers; monitor certificates continuously (CT logs, expiry, mis-issuance).
• Continuously discover and authenticate every email sender (esp. SaaS/3rd‑parties), and monitor look‑alike domains.
• Use Red Sift OnDMARC and Red Sift Certificates to stay protected against AITM attacks.

1. AITM in context: Why email and certificates are prime targets
2. Threats and how they work
3. DNS spoofing / cache poisoning
4. Email hijacking and domain spoofing
5. STARTTLS downgrade (SMTP)
6. HTTPS spoofing and SSL/TLS stripping
7. TLS/SSL hijacking via rogue/forged certs
8. Controls that matter (and how to roll them out)
9. Quick wins vs. strategic investments
10. 30/60/90‑day implementation plan
11. Stakeholders and RACI
12. Success metrics and reporting
13. Incident playbooks
14. Executive FAQ

Modern communications hinge on identity (who is talking) and channel integrity (that the message wasn’t altered). Adversary‑in‑the‑Middle attacks exploit the gaps between those two factors, commonly targeting:

• Email: Attackers spoof your domain or intercept SMTP paths to phish, insert malicious content, or re‑route messages.
• Web (HTTPS) & TLS: Attackers break HTTPS guarantees through SSL stripping, downgrade, or mis‑issued/forged certs to view/alter traffic.

The result: stolen credentials, invoice fraud, and data exfiltration, often without malware.

Goal: Divert victims to attacker‑controlled infrastructure for web or mail (e.g., fake MX, fake A/AAAA).

How it works: Attackers poison resolver caches or exploit weak authoritative responses. Once DNS answers are tampered with, users are directed to impostor web servers or SMTP relays. Business impact: Session hijack, credential theft, delivery interception, and issuance of fraudulent TLS certificates if DNS control is impersonated long enough.

• Sudden MX/NS/A record anomalies
• Certificate issuance for your domains you didn’t request
• Users reporting “your site looks odd” or mixed‑content warnings

• Monitor DNS changes: Use DNS monitoring tools (like DNS change alerts within Red Sift OnDMARC for MX records) to alert you when MX, NS, or A records change unexpectedly. Compare against known baselines or change logs.
• Track certificate transparency logs: Regularly review CT logs or set up automated alerts (i.e. within Red Sift Certificates account) to catch certificates issued for your domains that you didn’t request.
• Watch for user-side warnings: Pay attention to reports of browsers showing mixed-content warnings, invalid certificate errors, or unusual redirects (maybe some screenshots of examples), these can signal tampering or misissued certificates.

Goal: Send mail that appears to be from your domain or manipulate delivery paths (BEC, invoice redirection).

How it works: Abuse of lax SPF/DKIM/DMARC, misconfigured third‑party senders, or unprotected parked domains.

Business impact: Payment fraud, reputational damage, response‑based credential theft.

• Sudden rise in failed DMARC alignment
• Spoofed display names / exact‑domain phishing reaching inboxes
• Unvetted SaaS platforms sending on your behalf

• Review DMARC reports regularly: Monitor aggregate and forensic reports for spikes in alignment failures or new sources attempting to send as your domain. (also could make a suggestion to setup Saved view alerting or Threshold alerts within OnDMARC) 
• Inspect inbound phishing patterns: Look for messages using your exact domain or familiar display names that bypass filtering (can create transport rules to deal with display name spoofing) these often indicate gaps in authentication or enforcement.
• Audit third-party senders: Periodically review connected SaaS tools and ensure they’re authorized and properly configured to send on your behalf (Another opportunity to reference Saved View alerts and Threshold Alerts within OnDMARC)

Goal: Force mail servers to send in cleartext or to a malicious relay. How it works: Attackers strip the STARTTLS advertisement or tamper with MX lookups to divert to an attacker host that pretends to be the destination. Business impact: Confidentiality breach of email in transit; credential/session capture between MTAs.

• TLS‑RPT reports showing repeated failures to negotiate TLS
• Sudden shifts in cipher/version usage or spikes in plaintext delivery

• Monitor TLS-RPT and SMTP logs for repeated TLS negotiation failures. Look for frequent "handshake failed", "STARTTLS not offered", or "TLS disabled" messages from multiple senders or a cluster of sending IPs.
• Watch for sudden shifts to weaker TLS versions or ciphers. A spike in TLS 1.0/1.1 or legacy cipher suites in your mail logs or telemetry can indicate forced downgrades.
• Check for spikes in plaintext delivery. Unexplained increases in messages delivered without STARTTLS, or a rise in messages seen on port 25 with no TLS, are red flags.
• Correlate by sending IP and time. If failures come from the same upstream network range or coincide with short time windows, that suggests an active on-path interference.
• Validate MTA-STS and TLS reporting results. MTA-STS failures, policy lookups that suddenly fail, or mismatch errors in TLS-RPT often accompany downgrade attempts.
• Inspect SMTP session traces. Look for sessions where the server advertises STARTTLS but the client falls back or the handshake aborts. A pattern of advertised then missing STARTTLS is suspicious.
• Use packet captures for confirmation. TCP/TLS traces showing a downgrade in ClientHello or repeated TLS alerts help confirm an on-path manipulation.
• Alert on behavior anomalies, not just single failures. One failed handshake may be benign. Trigger investigation when failures are repeated, widespread, or matched with other indicators above.

Goal: Downgrade or remove HTTPS, serving HTTP content or injecting mixed content. How it works: On-path actors block 301/302 HTTPS redirects or suppress TLS, presenting an HTTP page. Users who click through or never reach HTTPS are vulnerable to credential theft and content injection. Business impact: Account takeovers, malware injection, session hijack.

• Reports of the site loading over plain HTTP
• Browser warnings about insecure forms or mixed content

Goal: Terminate TLS with a certificate the client accepts but you didn’t authorize. How it works: Corporate proxies, compromised CAs, or mis‑issuance enable the attacker to present a chain the client trusts. In mobile/IoT, weak pinning or outdated trust stores help. Business impact: Stealthy decryption and content manipulation.

• New certs in CT logs you did not request
• OCSP/CRL anomalies, unexpected intermediates

• Inventory all sending sources; configure DKIM & SPF (if available) per sender; ensure SPF flattening/permits are within 10‑lookup limit. Or use a DMARC provider like Red Sift who overcomes the SPF lookup limit.
• Phase: none → p=none (monitor) → p=quarantine → p=reject.
• Red Sift OnDMARC helps discover senders via DMARC reports, validate alignment, and safely move to enforcement.

• Publish an MTA‑STS policy (mode: enforce; mx: your authorized MX hosts). Validate via TLS‑RPT telemetry.
• Where supported, use DANE with DNSSEC to provide cryptographic binding of MX to cert.

1. Support intermediary forwarding cases; rotate keys; use 2048‑bit DKIM; restrict selectors per platform.
2. Implement BIMI (with VMC or a CMC)
3. Incentivizes DMARC enforcement and builds user trust in visual identity. Note: Users can benefit from easy Brand Indicators for Message Identification (BIMI) implementation with Red Sift OnDMARC with a newer Common Mark Certificate (CMC), not requiring a trademark like the traditional Verified Mark Certificate (VMC).  

• Register high‑risk variants; ensure DMARC p=reject on non‑sending domains.

1. DNSSEC on apex and mail subdomains to mitigate spoofing; sign MX, CNAME, and relevant records.
2. CAA records to restrict which CAs can issue for your domains; include iodef for mis‑issuance alerts.
3. Certificate management: Use short‑lived certs; automate via ACME; enable OCSP stapling; monitor CT logs for mis‑issuance/typosquats. If you're not sure where to start, Red Sift makes certificate easy with Red Sift Certificates.
4. Continuous discovery of hostnames/subdomains with exposed services; remove legacy endpoints.

1. HSTS with adequate max‑age (≥ 6 months) and preload for core zones (after validating subdomain readiness). Add includeSubDomains when safe.
2. TLS configuration: Enforce TLS 1.2+ (prefer 1.3), disable weak ciphers (3DES, RC4), and legacy renegotiation.
3. Cookie and session security: Mark cookies Secure + HttpOnly + SameSite=Lax/Strict; force HTTPS redirects at edge.
4. Content integrity: Use Subresource Integrity (SRI) for third‑party JS; avoid mixed content; prefer first‑party hosting for critical assets.

• Move non‑sending domains to DMARC p=reject immediately.
• Turn on TLS‑RPT and review reports weekly.
• Publish CAA restricting to your chosen CA; add iodef email.
• Enable HSTS on marketing sites (staged rollout) and force HTTPS redirects.
• Add monitoring of CT logs for new certs and look‑alike domains.

• Full DMARC enforcement (p=reject) on primary sending domains across all SaaS platforms.
• MTA‑STS enforce or DANE across all MX; DNSSEC on apex and critical subdomains.
• Web fleet TLS modernization (TLS 1.3, cipher policy, OCSP stapling, automation).

• Inventory email senders; enable DMARC p=none with reporting to a dedicated mailbox.
• Publish TLS‑RPT; collect data from inbound partners.
• Enable HSTS on low‑risk sites; enforce HTTPS redirects.
• Add CAA and begin CT log monitoring.

• Move to DMARC p=quarantine on domains where SPF/DKIM alignment is green.
• Publish MTA‑STS in testing, then enforce for core MX hosts.
• Turn on DNSSEC for apex domain.
• Standardize TLS 1.2+ everywhere; block weak ciphers; secure cookies.

• Move priority domains to DMARC p=reject; BIMI if brand team aligns.
• Expand HSTS across primary zones; evaluate preload readiness.
• Roll out DANE on mail domains where resolvers support it.
• Establish steady‑state dashboards and monthly exec reporting.

• CISO / Head of Security — Accountable
• Email/Collaboration Team — Responsible (SPF/DKIM/DMARC, MTA‑STS, TLS‑RPT)
• Network/DNS Team — Responsible (DNSSEC, CAA, CT monitoring)
• Web Platform/DevOps — Responsible (TLS config, HSTS, OCSP, automation)
• Brand/Marketing — Consulted (BIMI, domain portfolio)
• Legal/Compliance — Informed (policy, data protection)

• % of domains at DMARC p=reject (target: 100% non‑sending; ≥ 90% sending)
• of authenticated senders vs. unknown sources
• % of SMTP sessions meeting MTA‑STS/DANE policy; TLS‑RPT failure rate
• % of web traffic negotiated at TLS 1.3; HSTS coverage across domains
• Time‑to‑detect mis‑issued certificates (via CT) and time‑to‑revoke
• Volume of exact‑domain spoofing observed in SEGs

1. Validate current DNS state via authoritative queries; compare against baseline.
2. Check CT logs for unexpected certs; trigger CA revocation if needed.
3. Rotate credentials for affected services; publish incident comms via trusted channels.
4. Enable or validate DNSSEC; review registrar/registry locks and MFA.

1. Inspect DMARC aggregate for source; block unapproved senders (SPF/DKIM/DMARC updates).
2. Escalate domain(s) to p=quarantine/reject; enforce on parked domains.
3. User comms: warn, purge via M365/Google rules; update banners.
4. Post‑mortem: add BIMI, evaluate look‑alike takedown.

1. Identify failing partner MXes; share TLS‑RPT evidence; prefer MTA‑STS enforce.
2. If persistent, coordinate alternate secure route or quarantine messages pending fix.
3. Review your MX TLS config; enable modern ciphers, valid certs.

1. Confirm HSTS not enabled or insufficient; enable with safe max‑age and test.
2. Force HTTPS at edge; remove mixed content; enable SRI for external JS.
3. Review CDN/WAF rewrite rules; ensure 301 canonicalization to HTTPS.

1. Verify issuance details; request CA revocation; publish customer advisory if needed.
2. Rotate keys/certs on impacted endpoints; confirm OCSP stapling works.
3. Strengthen CAA; review ACME credentials; consider sub‑CA scoping with CA.

We make the process streamlined for busy teams. Choose Red Sift to shut down AITM risk across email and certificates with one focused platform. Red Sift OnDMARC gets you to DMARC p=reject quickly, discovers every sender, aligns SPF and DKIM, and enforces MTA-STS and TLS-RPT. 

Red Sift Certificates delivers full TLS visibility, CT log monitoring, automated issuance and renewal, and strong CAA, DNSSEC, and HSTS hygiene. 

Get faster time to enforcement, clearer reporting, and fewer spoofing and downgrade attempts. Start with Red Sift and turn policy into measurable protection. Book a free demo today.

Q: Will DMARC stop all phishing? A: No. It stops direct domain spoofing (the most convincing kind) and improves downstream filtering. Combine with user training and look‑alike domain monitoring.

Q: Is HSTS enough to stop SSL stripping? A: Yes, when deployed correctly—especially with preload. Without HSTS, first‑visit users can be downgraded.

Q: Do we need both MTA‑STS and DANE? A: Where possible, use both. MTA‑STS is broadly deployable today; DANE provides cryptographic binding when DNSSEC is in place.

Q: What role does Red Sift OnDMARC play? A: It streamlines discovery and authentication of all mail sources, drives you safely to DMARC p=reject, and operationalizes MTA‑STS/TLS‑RPT with clear reporting—closing the top AITM paths over email.