Man-in-the-middle attacks expose why IAM needs stronger verification

At a glance

What this is: This is a primer on man-in-the-middle attacks and the main ways attackers intercept or spoof communications to steal credentials and data.

Why it matters: It matters to IAM and NHI practitioners because interception, session theft, and spoofing can bypass otherwise sound authentication controls and expose service accounts, API keys, and user sessions.

By the numbers:

• Estimates show that 35% of exploitation activity involves man-in-the-middle attacks.
• Nearly 58% of all posts on criminal forums and marketplaces contain banking data collected by MITM or other attack types.
• Business email compromise resulted in over $1.8 billion made by scammers in 2020.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read StrongDM's analysis of man-in-the-middle attacks, detection, and prevention

Context

Man-in-the-middle attacks exploit a basic governance gap: organisations assume the user is talking directly to a trusted system when an attacker is actually intercepting the exchange. In NHI terms, this is not just about password theft. It is about the trust relationship around sessions, tokens, certificates, and service interactions, where a single interception point can expose human and non-human identities alike.

The article focuses on classic interception and spoofing patterns such as rogue Wi-Fi, DNS manipulation, HTTPS downgrade, and session hijacking. That framing is useful because it shows how access risk can begin before an application sees a valid login, which is typical of environments where identity controls are strong on paper but weak in transit.

Key questions

Q: How should security teams reduce man-in-the-middle risk in IAM environments?

A: Security teams should combine strong transport validation with identity controls that assume interception can happen. That means enforcing certificate checks, shortening session lifetimes, segmenting sensitive access paths, and monitoring for replay or suspicious reuse. For NHI environments, it also means reducing standing secrets and treating tokens as high-value credentials, not harmless technical details.

Q: Why do man-in-the-middle attacks still succeed when HTTPS is enabled?

A: HTTPS only protects the channel when the client trusts the correct endpoint and the certificate chain is valid. MITM attacks still succeed when attackers exploit downgrade paths, spoofed domains, compromised endpoints, or weak validation. The control lesson is that encryption is necessary, but trust verification and endpoint integrity determine whether the session is actually safe.

Q: What is the difference between session hijacking and credential theft?

A: Credential theft captures the secret needed to authenticate, such as a password or token. Session hijacking goes further by taking over an already authenticated session, often through stolen cookies or bearer tokens. In practice, session hijacking is more dangerous because it can bypass login controls and preserve access even after a password is changed.

Q: How can organisations protect non-human identities from MITM-style compromise?

A: Organisations should bind non-human identities to specific workloads where possible, rotate secrets aggressively, and avoid long-lived credentials in code or configuration. They should also inspect outbound and service-to-service traffic for unusual routes or reuse patterns. The goal is to make any intercepted secret narrow in scope and short in usefulness.

Technical breakdown

Interception and spoofing in man-in-the-middle attacks

A MITM attack works when an adversary positions themselves between two parties and convinces each side that the other is legitimate. That can happen through rogue wireless access points, DNS poisoning, IP spoofing, or deceptive certificate handling. The technical weakness is not always cryptography itself but the trust assumptions surrounding name resolution, network path, and session establishment. Once the attacker can redirect traffic, even strong credentials can be harvested before the application layer has any chance to enforce policy. For NHI environments, the same pattern applies to service-to-service calls and agentic workflows where trust is derived from network location or a reused token.

Practical implication: Treat network path and identity proofing as separate controls, and do not let transport encryption substitute for endpoint and certificate validation.

Session hijacking and credential replay

The article's discussion of browser cookie theft and captured logins points to a broader issue: stolen credentials are often only the first artifact. Attackers typically replay sessions, use captured tokens against the real service, and move from interception to impersonation without needing the original phishing page. This matters for NHIs because API keys, bearer tokens, and certificates behave like reusable access grants when they are not tightly scoped, rotated, or bound to context. In practice, the danger is not just credential exposure. It is the ability to convert one intercepted exchange into durable access.

Practical implication: Limit token lifetime, bind credentials to specific workloads where possible, and log for anomalous reuse across sessions or locations.

Why HTTPS alone does not close the trust gap

The article correctly notes that HTTPS is necessary but not sufficient. HTTPS protects data in transit only if the client validates the certificate chain, the hostname, and the connection path. Downgrade attacks, weak certificate hygiene, and compromised endpoints can still undermine the channel. For identity teams, this is the point at which Zero Trust Architecture becomes relevant. NIST SP 800-207 treats trust as dynamic and continuously evaluated, which is a better fit for environments where users, workloads, and AI agents all initiate requests from changing conditions.

Practical implication: Pair transport encryption with continuous verification, certificate hygiene, and least-privilege access decisions at every request.

Threat narrative

Attacker objective: The objective is to convert a trusted communication into reusable identity material that can be replayed for fraud, account takeover, or broader network access.

1. Entry occurs when the attacker creates a rogue Wi-Fi network, spoofs DNS, or otherwise inserts themselves into the communication path between user and service.
2. Escalation follows when the attacker captures credentials, cookies, or other session artifacts and reuses them against the legitimate application.
3. Impact occurs when the attacker changes account settings, steals funds, or expands access into broader enterprise systems using the intercepted identity.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Man-in-the-middle risk is an identity governance problem, not just a transport problem. The attack succeeds by exploiting who and what the organisation trusts to speak for a user, service, or workload. That means IAM, PAM, certificate governance, and NHI controls all need to work together, because a valid credential on a compromised channel is still a compromised identity.

Session integrity is the real control gap in most environments. Teams often focus on initial authentication while ignoring what happens after the session begins, which is where replay, cookie theft, and token reuse do the most damage. For NHI programmes, this creates a distinct trust boundary: short-lived, bound, and observable credentials are safer than static secrets that can be intercepted and reused.

Trust-on-first-use is too weak for modern identity flows. The article's examples show that attackers exploit weak validation of sites, networks, and emails, not just weak passwords. In agentic and machine-to-machine environments, that translates into a need for continuous verification, certificate discipline, and policy checks at the point of use, not only at login.

Identity blast radius is the right concept for MITM defence. Once an attacker captures one session or one credential, the damage depends on how far that identity can move. Organisations should therefore assess the blast radius of every human and non-human credential, because over-privilege turns a single interception into a broad compromise.

Zero Trust only works when transport, device, and identity checks are all enforced together. MITM attacks expose the weakness of any model that treats encryption as proof of trust. Practitioners should use this as a forcing function to tighten certificate management, segment access paths, and reduce standing access for service accounts and automation.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• the Ultimate Guide to NHIs also reports that only 20% have formal processes for offboarding and revoking API keys.

What this signals

Identity teams should treat MITM as an early-warning pattern for broader credential weakness. Once attackers can intercept traffic, the same control gaps that allow spoofing often also allow replay, privilege escalation, and lateral movement. That is why session binding, certificate hygiene, and access segmentation belong in the same programme, not three separate checklists.

The operational signal is clear: as environments add more automated access, the value of each intercepted secret rises. With NHIs outnumbering human identities by 25x to 50x, even small validation gaps can create a large hidden attack surface for service accounts and agents.

Identity blast radius: teams should start measuring how far one captured token can travel across users, workloads, and admin planes. That metric is more useful than treating MITM as a purely network-layer issue, because the real risk is how much authority a stolen identity can inherit before detection.

For practitioners

• Harden certificate and hostname validation Require strict certificate chain validation, enforce hostname checks, and remove legacy TLS exceptions that make downgrade attacks easier to exploit.
• Reduce token replay risk Shorten token lifetimes, prefer bound or context-aware credentials, and monitor for reused sessions across unusual IPs, devices, or geographies.
• Segment access paths for sensitive systems Apply network segmentation so that a compromised local path cannot reach high-value applications, administrative planes, or service account endpoints.
• Review service account exposure Inventory service accounts, API keys, and certificates that can be intercepted or replayed, and eliminate any long-lived secrets stored in code or config.
• Train users to verify connection context Teach users and operators to question unexpected Wi-Fi prompts, certificate warnings, and lookalike domains before entering credentials.

Key takeaways

• Man-in-the-middle attacks exploit trust assumptions around channels, sessions, and endpoints, which makes them an identity problem as much as a network problem.
• StrongDM cites 35% of exploitation activity as involving MITM, while NHIMG research shows 97% of NHIs carry excessive privileges, a dangerous combination when credentials are intercepted.
• Practitioners should reduce replay value, enforce certificate discipline, and shrink the blast radius of every human and non-human credential.

Key terms

• Man-in-the-Middle Attack: A man-in-the-middle attack is an interception technique where an attacker positions themselves between two parties that believe they are communicating directly. The attacker can read, alter, or replay traffic, which makes the attack especially dangerous when credentials, sessions, or certificates are involved.
• Session Hijacking: Session hijacking is the takeover of an authenticated session using stolen cookies, tokens, or other session material. It is more damaging than simple credential theft because the attacker can often act as the user without needing to log in again, even if the password changes later.
• DNS Spoofing: DNS spoofing is the manipulation of name resolution so a victim is sent to a fake destination instead of the intended service. In identity security, it matters because users may trust the right brand while unknowingly sending credentials or tokens to an attacker-controlled endpoint.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause before it is detected or revoked. For NHIs and human users alike, it is shaped by privilege scope, token lifetime, and how many systems accept the same credential without additional verification.

Deepen your knowledge

Man-in-the-middle attacks, session theft, and certificate trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building an identity programme that has to survive interception and replay risk, it is worth exploring.

This post draws on content published by StrongDM: Security Man-in-the-Middle (MITM) Attack: Definition, Examples & More. Read the original.