How to Detect Man-in-the-Middle Attacks: Indicators, Methods, and Detection Gaps

Introduction

Most MITM attacks don’t announce themselves. No alerts fire, no certificates visibly break, and no users report anything unusual. By the time the interception is discovered, credentials or session tokens are already in attacker hands.

Knowing how to detect man-in-the-middle attacks requires looking across multiple layers: network traffic, DNS resolution, TLS certificate integrity, and session behavior. No single signal is conclusive on its own, and the most sophisticated attacks are specifically engineered to suppress the indicators most teams rely on.

This article covers the technical methods used to detect MITM attacks, the indicators worth monitoring, and the structural gaps that leave customer-facing environments exposed even when internal controls are solid.

What Is a Man-in-the-Middle Attack? (And Why Detection Is Harder Than It Looks)

A man-in-the-middle (MITM) attack is the covert interception or manipulation of communications between two parties, without either knowing. The attacker doesn’t force entry. They quietly position themselves between two endpoints, reading and altering every message that passes through.

The core mechanics run in three stages:

• Traffic redirection – the attacker inserts themselves into the communication path, routing traffic through infrastructure they control before it reaches its intended destination.
• Session hijacking – once positioned, the attacker captures or impersonates an active authenticated session, inheriting the victim’s access without needing their credentials.
• Credential interception – login data, session tokens, and authentication cookies are harvested in transit, giving the attacker persistent, reusable access.

The most common attack vectors include ARP spoofing, DNS poisoning, SSL stripping, and rogue access points. Each exploits a different entry point, but the objective is the same: invisible insertion into a trusted communication channel.

In threat intelligence contexts, MITM is increasingly called adversary-in-the-middle (AiTM), particularly for phishing proxy attacks. AiTM kits deploy reverse proxies that relay authentication requests in real time, capturing session cookies and bypassing MFA entirely. ENISA’s Threat Landscape identified AiTM phishing as a significant escalation in credential-based attacks, precisely because it defeats controls organizations have long relied on.

The attack is engineered to be invisible. Most detection methods only surface indicators after interception has already begun.

Common Signs of a Man-in-the-Middle Attack

Spotting a MITM attack in progress is harder than most detection guides admit. The indicators below are observable signals worth investigating, not definitive proof of compromise. Their absence doesn’t mean a session is clean. An attacker operating through a transparent proxy may leave none of these traces at all.

• 1. Invalid, unexpected, or self-signed SSL/TLS certificate warnings

The browser flags a certificate mismatch, an untrusted issuer, or an expired cert. It’s one of the most visible signals, but only if the user notices and reports it. Most don’t.

• 2. HTTPS downgraded to HTTP

SSL stripping silently removes transport encryption, forcing the connection to plain HTTP. The address bar changes, but most users aren’t watching. Traffic is now readable in transit.

• 3. Unexpected URL redirections or domain substitutions

The user lands on a lookalike domain or gets routed through an unfamiliar intermediary. The page looks identical to the legitimate site. The URL is the only tell, and it’s easy to miss.

• 4. Forced re-authentication or unexpected login prompts

The attacker drops the existing session to force credential re-entry. A sudden “please log in again” prompt mid-session is a red flag, especially if no timeout occurred.

• 5. DNS resolution anomalies

A domain resolves to an unexpected IP address, or TTL values change without explanation. As OWASP notes, DNS-layer manipulation is a core enabler of session interception and is rarely visible to end users.

• 6. Abnormal session behavior

Unexpected logouts, session resets, unusual latency spikes, or duplicate session tokens. These look like application bugs, which is exactly why they get dismissed.

• 7. ARP table inconsistencies

On a local network segment, the same MAC address mapping to multiple IP addresses is a classic ARP spoofing indicator. As Sycope’s network analysis research confirms, this address conflict is the most characteristic symptom of ARP poisoning in LAN environments.

Most of these indicators are either user-reported or require active monitoring infrastructure to surface. In external customer environments, where users connect through networks and devices the enterprise doesn’t control, the organization may never see these signals at all. That’s not a monitoring gap. It’s a structural blind spot.

Technical Methods to Detect MITM Attacks

Network-layer detection isn’t guesswork. It’s a set of well-established disciplines. Each method below targets a specific phase of the MITM attack chain. Used together, they form a credible detection baseline for any security team.

Network traffic monitoring and packet inspection

Tools like Wireshark and tcpdump give analysts deep visibility into raw packet data, making it possible to spot anomalous traffic patterns, unexpected intermediary hops, or protocol downgrades from HTTPS to HTTP. When a session is being intercepted, traffic often shows subtle irregularities: unusual latency spikes, mismatched TCP sequence numbers, or unexpected retransmissions. Packet inspection is most effective in controlled network segments where analysts have full capture access.

Intrusion detection systems (NIDS and HIDS)

Network-based intrusion detection systems (NIDS) like Snort and Suricata match live traffic against known MITM signatures and behavioral rules, flagging ARP anomalies, SSL stripping attempts, and suspicious redirect patterns. Host-based IDS (HIDS) complements this by monitoring endpoint-level indicators: unexpected process activity, certificate changes, or local ARP table modifications. Together, they cover both the wire and the host.

ARP spoofing detection

ARP spoofing is one of the most common MITM entry points on local networks. Attackers broadcast forged ARP replies to poison the ARP cache of target devices, redirecting traffic through an attacker-controlled machine. Monitoring ARP tables for duplicate MAC-to-IP mappings, unexpected ARP reply floods, or entries that change without a corresponding DHCP event can surface this activity early. Tools like arpwatch and XArp provide continuous ARP table monitoring and alert on suspicious changes.

DNS anomaly detection

DNS manipulation is a quieter attack vector, and harder to catch. Indicators include unexpected TTL reductions, resolution mismatches between expected and actual IP addresses, and unauthorized DNS server substitutions. Comparing live DNS responses against known-good baselines, and monitoring for responses that differ across resolvers, can expose DNS hijacking before users reach a spoofed destination. DNSSEC validation adds a cryptographic layer that makes unauthorized record modification detectable.

TLS certificate validation monitoring

Certificate pinning enforces expected certificate fingerprints at the application layer, rejecting connections that present an unexpected certificate, even a technically valid one issued by a trusted CA. Certificate Transparency (CT) log monitoring adds a second layer: as Let’s Encrypt notes, CT logs provide a publicly auditable record of every certificate issued, making it possible to detect unauthorized certificates for monitored domains before they’re deployed in an attack.

Network flow analysis

NetFlow, IPFIX, and sFlow data don’t capture packet payloads, but they reveal traffic routing patterns that packet inspection misses at scale. Unexpected routing hops, asymmetric traffic volumes between two endpoints, or unusual latency profiles between client and server can all indicate an active intermediary. Flow analysis is particularly useful for detecting MITM activity across high-volume environments where full packet capture isn’t practical.

These methods are proven and worth deploying. The question isn’t whether they work. It’s where their visibility ends.

Network Traffic Monitoring and Packet Inspection

Tools like Wireshark and tcpdump give security teams deep visibility into raw network traffic, making it possible to spot anomalous intermediary hops, unexpected protocol downgrades from HTTPS to HTTP, suspicious certificate exchanges, and traffic patterns that don’t match expected baselines. When a MITM attack is in progress, packet inspection surfaces the fingerprints it leaves behind: irregular handshake sequences, mismatched cipher suites, or traffic routed through unexpected IP addresses.

The critical constraint: this method only works where you control the network segment being monitored. For traffic flowing through a customer’s browser, a mobile app, or a third-party network, that visibility simply doesn’t exist.

Intrusion Detection Systems (NIDS and HIDS)

Network-based IDS tools like Snort and Suricata inspect traffic flows for known MITM attack signatures, flagging patterns such as ARP spoofing sequences, unexpected SSL handshake anomalies, or suspicious certificate exchanges. Host-based IDS adds a complementary layer, monitoring system-level events for behavioral indicators like unexpected process activity or unauthorized configuration changes.

The critical limitation: both approaches depend heavily on signature matching against known attack patterns. Adversary-in-the-middle (AiTM) techniques using custom proxy tooling or novel traffic manipulation slip through undetected, because no matching signature exists yet. Novel attacks, by definition, don’t look like the last one.

ARP Spoofing Detection

ARP table monitoring watches for duplicate MAC-to-IP mappings and unexpected ARP reply floods, the telltale signs of ARP cache poisoning. Tools like arpwatch and XArp continuously track ARP activity and alert administrators to anomalies in real time. This works for LAN-based MITM scenarios where the attacker is on the same local network segment.

It provides no visibility into attacks at the application or session layer, or in external customer-facing environments where you have no network-level access.

DNS Anomaly Detection

DNS anomaly detection only works when you know what normal looks like. Unexpected TTL changes, resolution mismatches between expected and actual IP addresses, and unauthorized DNS server substitutions are reliable indicators of tampering, including MITM-enabling techniques like DNS poisoning and fast flux. CISA’s 2025 advisory on fast flux specifically flags unusually low TTL values and rapid IP changes as key detection signals.

Without a documented baseline of normal DNS resolution behavior, these deviations are nearly impossible to catch before damage is done.

TLS Certificate Validation Monitoring

Two complementary controls tighten TLS-layer detection: certificate pinning and Certificate Transparency (CT) log monitoring.

• Certificate pinning enforces expected certificate fingerprints within applications, so any substituted certificate, even one signed by a trusted CA, triggers an immediate validation failure.
• CT log monitoring works differently. As MDN Web Docs explains, CT logs maintain a publicly auditable, append-only record of every issued TLS certificate. Monitoring your domains against these logs surfaces unauthorized certificates the moment they’re issued, before attackers deploy them against users.

That makes CT log monitoring one of the earliest detection points in the MITM attack chain.

Where Traditional MITM Detection Falls Short

The network-layer detection methods above are legitimate, well-established, and worth deploying. But they share a structural blind spot no configuration change will fix: they require visibility into the traffic path. In modern MITM attacks targeting your customers, that path runs entirely outside your perimeter.

• The infrastructure control problem

Enterprise network monitoring works within the enterprise network. When a customer’s browser connects to an attacker’s AiTM proxy on rented cloud infrastructure, your SIEM sees nothing. Your IDS sees nothing. The attack is invisible by design.

This isn’t a theoretical gap. Sekoia.io’s Q1 2025 global AiTM analysis identified 11 major AiTM phishing kits actively targeting organizations, including Tycoon 2FA, EvilProxy, and Evilginx. Every one operates outside enterprise network visibility. They’re not probing your firewall. They’re standing between your customer and your login page.

• The perimeter boundary problem

Trace the attack chain for a typical AiTM campaign:

1. Attacker stands up proxy infrastructure and a cloned site
2. DNS or traffic redirection routes the customer to the spoofed asset
3. Customer authenticates through the proxy, believing it’s legitimate
4. Attacker captures credentials or live session cookies
5. Attacker replays those tokens against your real application

Steps one through four happen entirely outside your security perimeter. The first signal many enterprises receive is a fraudulent transaction post-login. By then, the session is already compromised.

• The user-reporting dependency

Many MITM indicators rely on users noticing something wrong: a certificate warning, an unexpected prompt, a slightly off URL. Sophisticated AiTM kits are engineered to suppress these signals. They serve valid-looking certificates via reverse proxy, mirror the legitimate site’s UI precisely, and complete the authentication flow without friction. The attack that leaves no visible trace is the one that succeeds.

• Detection timing is the critical variable

This is the point most detection frameworks miss. It’s not just whether you detect a MITM attack. It’s when in the attack chain you detect it.

Network alerts and post-login fraud controls sit at the tail end of the chain. By the time anomalous session behavior triggers a SIEM rule, credential exposure has already occurred. The IBM Cost of a Data Breach Report 2024 found that credential-based breaches took an average of 292 days to identify and contain. That’s a detection timing problem, not just a detection problem.

Detecting a cloned site before a customer reaches it is categorically different from detecting a fraudulent transaction after the fact.

• The MFA bypass gap

MFA was supposed to close the credential exposure window. AiTM techniques specifically target that assumption. By proxying the authentication flow in real time, attackers capture session cookies after MFA completes, bypassing it entirely without the user or the enterprise knowing. The Verizon DBIR 2025 found that 9% of credential attacks used AiTM techniques. Standard MFA monitoring doesn’t detect this, because from the authentication system’s perspective, the login succeeded.

None of this makes network-layer detection obsolete. It remains essential within the perimeter. But for customer-facing digital environments, it leaves a critical detection surface uncovered: the session layer, where interception actually happens.

How to Strengthen MITM Detection in Digital Channels

Strengthening MITM detection in customer-facing environments means extending visibility beyond the network perimeter to the session and interaction layer. Network controls cover what you own. The attack surface your customers navigate is a different problem.

Here are five concrete methods to improve detection coverage and shorten the window between interception and response.

• 1. Continuous TLS integrity monitoring

Deploy real-time monitoring of TLS certificates across all customer-facing assets, not just internal infrastructure. Automated alerting on certificate anomalies, unexpected issuers, mismatched fingerprints, or newly issued certificates for monitored domains via CT logs can surface attacker infrastructure before users are targeted. As inventivehq.com notes, attackers must obtain SSL certificates to make phishing and proxy sites appear legitimate, which means CT log monitoring creates a genuine early-warning signal. This moves detection from post-compromise to pre-exposure.

• 2. Real-time traffic redirection detection

Monitor for DNS resolution changes, BGP route anomalies, and unexpected intermediary hops in traffic paths to customer-facing assets. When users are routed through unauthorized intermediaries, the window to act is narrow. DNS TTL anomalies and resolution mismatches are often the first observable signal that something has been tampered with upstream. Detecting redirection before credentials are submitted is the difference between prevention and incident response.

• 3. Session integrity analysis

Monitor active sessions for behavioral signals that indicate interception rather than legitimate user activity. Key indicators include simultaneous session tokens from geographically inconsistent locations, session cookie reuse patterns inconsistent with device fingerprints, and anomalous request sequencing that suggests automated proxy replay. This layer operates on the session itself, not the network path, which means it catches interception that never touches your internal infrastructure.

• 4. Cross-channel anomaly correlation

Connect signals across web, mobile, and authentication layers to identify coordinated interception patterns. A spike in certificate warnings correlating with authentication anomalies and DNS resolution changes across a specific user segment is a far stronger signal than any single indicator in isolation. SIEM integration enables this correlation at scale, turning weak individual signals into high-confidence detections.

• 5. Monitoring spoofed digital assets linked to interception infrastructure

Proactively detect cloned or spoofed sites used as MITM entry points before users reach them. A February 2026 study found more than 28,000 deceptive domain variations linked to just 20 of the world’s most visited websites already registered by third parties. This includes monitoring for lookalike domain registrations, newly spun-up sites mimicking brand assets, and SEO poisoning campaigns routing users to attacker-controlled proxies. Detecting the infrastructure before it’s weaponized is the earliest possible detection point in the attack chain, and the one most likely to prevent harm rather than just document it.

Step 1: Establish Continuous TLS Certificate Monitoring Across Customer-Facing Assets

Monitor what you own, including the parts you’ve forgotten about.

TLS certificate monitoring means tracking certificate issuer changes, fingerprint mismatches, and newly issued certificates for your domains in public certificate transparency (CT) logs. Tools like crt.sh aggregate CT log data publicly, so you can spot unauthorized certificates before attackers deploy them against your users.

The outcome: early detection of attacker infrastructure, cloned subdomains, and spoofed login pages, before a single customer session is intercepted.

The common mistake is limiting TLS monitoring to internal assets. Customer-facing subdomains, partner integrations, and API endpoints are exactly where attackers build MITM infrastructure. If those aren’t in scope, your monitoring has a blind spot that’s visible to everyone except you.

Step 2: Implement Real-Time Traffic Redirection Detection

Treating DNS monitoring as a periodic audit is a detection gap waiting to be exploited. By the time a scheduled check flags a resolution mismatch, credentials may already be captured.

Effective redirection detection requires continuous comparison of expected IP addresses against live DNS resolution results for owned domains. Any deviation signals a potential hijack. Pair this with BGP route change monitoring to catch upstream traffic manipulation before it reaches your users, and traceroute-based path analysis to identify unexpected intermediary hops.

The goal is detecting active redirection before a user submits credentials, not after. Real-time signals make that possible. Scheduled scans don’t.

Step 3: Deploy Session Integrity Analysis

Post-login behavioral analytics start too late. By the time they fire, credential exposure has already happened.

Session integrity analysis moves detection earlier by monitoring the session itself for interception signals:

• Concurrent session tokens from geographically inconsistent locations – the same token active in two countries simultaneously is a hard indicator of theft
• Session cookie reuse patterns mismatched against device fingerprints – a valid cookie presenting from an unrecognized device profile suggests proxy replay
• Anomalous request sequencing – automated proxies replay requests in patterns no human user produces
• Unusual latency spikes – consistent added latency across a session often reflects traffic routed through an unauthorized intermediary

These signals surface active interception even when network-layer controls see nothing. OWASP’s session management guidance explicitly flags concurrent session anomalies and device-context mismatches as key indicators of session compromise.

Step 4: Enable Cross-Channel Anomaly Correlation

A single anomalous signal is noise. Correlated signals across channels are evidence.

Treating each alert source in isolation is one of the most common mistakes in MITM detection. A certificate warning spike means little on its own. Pair it with an authentication anomaly and a DNS resolution change affecting the same user cohort, and you have a high-confidence detection event.

SIEM integration or dedicated correlation rules connect signals across web, mobile, and authentication layers in real time. Dark Reading notes that siloed detection tools drive false positives and analyst burnout. Correlation fixes both: fewer noise alerts, sharper MITM detection signals.

Step 5: Monitor for Spoofed Digital Assets and Attacker Infrastructure

Detecting attacker infrastructure before it’s weaponized is the earliest possible intervention point in the MITM attack chain. It precedes any user exposure.

Attackers register lookalike domains using typosquatting, homoglyph substitution, and brand-adjacent naming to build proxy infrastructure days or weeks before launching campaigns. Krebs on Security reported in December 2025 that over 90% of typosquatting domains now redirect visitors to malicious content. SEO poisoning compounds this, routing users to attacker-controlled proxies through organic search results.

Proactive monitoring of newly registered domains, certificate transparency logs, and brand-mimicking assets creates a pre-exposure detection window. That window is where takedown action is still possible.

The common mistake: waiting for user reports or post-incident forensics to surface spoofed infrastructure. By then, sessions are already compromised.

How MITM Attacks Lead to Fraud Exposure

Detection isn’t just a technical problem. It’s a financial one. Every minute a MITM session goes undetected, the attacker holds valid authentication material, and the fraud clock is running.

When a MITM attack intercepts a session, the attacker doesn’t need to brute-force anything. The legitimate user has already authenticated. The attacker captures the session token or credentials in transit and walks through the front door. No login anomaly fires. No failed attempt is logged. From the system’s perspective, the session looks completely normal.

What happens next moves fast. Captured tokens are replayed within minutes. The attacker accesses the victim’s account – banking portal, eCommerce profile, loyalty program – and executes transactions or harvests data before any alert surfaces. This is the account takeover window: brief, quiet, and expensive.

The numbers confirm it. According to the FBI IC3 2025 Annual Report, account takeover fraud generated approximately $359.7 million in reported losses from around 4,700 complaints in 2025 alone, with impersonation of financial institutions cited as a primary attack vector. That’s only what gets reported. TransUnion’s H2 2025 Fraud Report found digital account takeover volume increased 21% from H1 2024 to H1 2025, with ATO responsible for 31% of all fraud losses reported by U.S. businesses – the single largest fraud category.

The fraud chain runs from interception to compromise to execution, and it moves faster than most detection stacks can respond. MITM isn’t just a network security problem. It’s a direct path to digital impersonation, financial loss, and customer harm. Closing that exposure window means detecting interception earlier in the chain, before credentials are captured and before the attacker’s session is already live.

FAQ: Key Questions on MITM Attack Detection

What are the signs of a man-in-the-middle attack?

Common indicators include unexpected SSL/TLS certificate warnings, HTTPS connections downgraded to HTTP, unfamiliar login prompts, sudden session logouts or resets, and unusual latency during authenticated sessions. DNS resolution changes and unexpected domain redirects are also warning signs.

These are indicators, not proof. A well-executed MITM attack may produce none of them, particularly when the attacker controls the certificate chain or operates a convincing spoofed site.

How can you detect a MITM attack?

Detection spans multiple layers. At the network layer, packet inspection tools like Wireshark and tcpdump surface ARP anomalies and suspicious traffic patterns. Intrusion detection systems flag unusual network behavior. TLS certificate monitoring and Certificate Transparency log analysis catch unauthorized certificates.

At the session layer, monitoring for integrity anomalies, unexpected re-authentication events, and behavioral deviations can identify interception that network tools miss entirely.

Can HTTPS prevent MITM attacks?

HTTPS significantly reduces MITM risk by encrypting traffic in transit, but it doesn’t eliminate it. SSL stripping attacks downgrade HTTPS connections to HTTP, exposing session data. Certificate spoofing and rogue certificate authorities let attackers present a trusted-looking certificate while intercepting traffic.

HSTS and certificate pinning reduce these risks, but neither is foolproof. HTTPS is a necessary control, not a complete defense.

What tools detect MITM attacks?

Network-layer tools include Wireshark and tcpdump for packet analysis, Snort and Suricata for intrusion detection, and ARP monitoring utilities for spoofing detection. DNS monitoring platforms flag unexpected TTL changes and resolution mismatches.

For session-layer visibility, behavioral analytics platforms and real-time session integrity monitoring tools detect interception patterns that network tools can’t observe, particularly in external customer-facing environments.

How do MITM attacks lead to fraud?

MITM attacks intercept credentials or session tokens during active user sessions. Those stolen assets compromise accounts, enabling fraudulent transactions or data exfiltration. The FBI reported over $262 million in account takeover losses in 2025, with attackers frequently using intercepted credentials to lock victims out and wire funds before detection. The faster interception is identified, the smaller the fraud exposure window.

Conclusion

MITM detection isn’t a single tool or a single signal. It requires layered visibility across ARP tables, DNS resolution, TLS certificates, network traffic, and session behavior. Each layer catches what others miss. The harder problem is external environments, where network controls don’t reach and attackers operate through spoofed assets and proxy infrastructure that sits entirely outside your perimeter.

Extend Detection Beyond the Network Perimeter

Network-level monitoring provides strong coverage within the enterprise perimeter – but customer-facing session interception often falls outside that visibility window. Learn how real-time session visibility strengthens man-in-the-middle detection in digital environments.

See How Session-Layer Detection Works

FAQs

Q: What are the signs of a man-in-the-middle attack?

A: Common indicators include unexpected SSL/TLS certificate warnings, HTTPS connections being downgraded to HTTP, suspicious URL redirections or lookalike domains, forced re-authentication prompts, DNS resolution anomalies, and abnormal session behavior such as unexpected logouts or unusual latency. These are indicators, not definitive proof – their absence does not confirm a session is clean. Sophisticated MITM attacks, particularly AiTM proxy-based attacks, are specifically designed to suppress visible warning signals.

 

Q: How can you detect a MITM attack?

A: Detection requires monitoring across multiple layers: ARP table monitoring for duplicate MAC-to-IP mappings (LAN-based attacks), DNS anomaly detection for unexpected resolution changes, TLS certificate validation via certificate pinning and Certificate Transparency log monitoring, network traffic inspection using tools like Wireshark or Suricata, and session integrity analysis for behavioral signals indicating proxy interception. In external customer environments, session-layer monitoring and spoofed asset detection extend visibility beyond what network controls alone can observe.

 

Q: Can HTTPS prevent man-in-the-middle attacks?

A: HTTPS significantly reduces MITM risk by encrypting traffic in transit, but it does not eliminate it. SSL stripping attacks can silently downgrade HTTPS connections to HTTP before encryption is established. Certificate spoofing and fraudulent certificates issued for legitimate domains can deceive browsers into trusting attacker-controlled connections. AiTM phishing proxies relay HTTPS traffic in real time, capturing session cookies after authentication completes – bypassing both encryption and MFA. HTTPS is a necessary control, not a sufficient one.

 

Q: What tools detect MITM attacks?

A: Network-layer tools include Wireshark and tcpdump for packet inspection, Snort and Suricata for intrusion detection, XArp and arpwatch for ARP spoofing detection, and NetFlow analyzers for traffic anomaly detection. For TLS monitoring, Certificate Transparency log aggregators (such as crt.sh) surface unauthorized certificates. For external customer environments, session integrity monitoring platforms and digital asset monitoring tools extend detection to the session and interaction layer, where network tools have no visibility.

 

Q: How do MITM attacks lead to fraud?

A: MITM attacks intercept credentials or session tokens during authentication, giving attackers valid access material without triggering login anomalies. Attackers replay captured session cookies or use harvested credentials to access victim accounts – often within minutes. This enables fraudulent financial transactions, loyalty point theft, PII exfiltration, or account takeover for downstream fraud. The FBI IC3 2025 Annual Report recorded approximately $359.7 million in ATO fraud losses, with impersonation of financial institutions cited as a primary attack vector.