Detecting T1557 Adversary-in-the-middle

How adversary-in-the-middle detection starts with the traffic path

A SOC lead asking whether credentials or sessions can be intercepted between clients and services should start by mapping the traffic path. T1557 Adversary-in-the-middle is the ATT&CK technique in which an adversary positions itself between two parties so it can read or alter their communication. It sits under the Credential Access tactic (TA0006), which MITRE's tactic page describes as an adversary trying to steal account names and passwords. In intrusions, adversaries typically use it on a shared network segment, a name resolution path or a service that clients trust, and the material they target is usually logon data or session material.

T1557 has four sub-techniques, and this page targets Enterprise ATT&CK version 20.0, released by MITRE on 2026-10-13. Confirm the sub-technique names and platform coverage in the v20.0 STIX bundle before you write detections, because ATT&CK releases can rename, deprecate or revoke techniques. Build an inventory of the paths your clients use to reach identity providers, internal web applications, file shares and network services, including name resolution, address assignment, wireless association and any proxy or gateway in between. For each path, record who can change it, which telemetry records it and which services accept credentials without validating the server's identity.

Decide early which telemetry covers each path. Network Traffic Content and Application Log Content are among the data components ATT&CK most often references for Credential Access detections, so check whether your sensors see traffic on the segments that matter and whether application logs record authentication failures, certificate warnings and unexpected client origins. File Modification on endpoints and network devices can reveal changes to resolver settings or trust stores. Confirm these coverage gaps in a pilot before you commit to a monitoring design.

Which telemetry reveals adversary-in-the-middle on each platform

This table maps the telemetry that most often reveals T1557 activity to each platform family, along with an open-source collector to gather it. Read each row as a question to answer in your own environment: which logs exist, which collector sees them, and which signal would justify an alert. Treat the signals as starting points to validate against your baseline, not as complete detection logic.

Platform	Telemetry and signal to look for	Open-source collector
Linux	File Modification on trust stores, resolver and name service configuration, and certificate bundles, followed by unexpected changes to who can read or write them	Wazuh file integrity monitoring, with Velociraptor for on-demand host checks
macOS	Application Log Content showing unexpected changes to trusted certificate settings or proxy configuration, and File Modification on profile and keychain-related paths	Wazuh agent log collection, with Velociraptor artifacts for configuration review
Network devices	Application Log Content from switches and routers showing ARP or neighbor table changes, duplicate addresses, or unexpected configuration commits	Syslog forwarding into Wazuh, with Zeek or Suricata watching the same segment for ARP anomalies
Windows	Application Log Content for name resolution, proxy and certificate store changes, and File Modification on hosts files and proxy auto-configuration settings	Wazuh Windows event collection, with Velociraptor for file and registry state comparison
Network traffic (all platforms)	Network Traffic Content showing TLS certificate changes for a known server, unexpected certificate issuers, or name resolution answers that disagree with internal records	Zeek for protocol and certificate logs, with Suricata rules for certificate and ARP anomalies
Identity and application logs	Application Log Content showing sign-in from an unfamiliar certificate chain, or session errors that cluster after a certificate or proxy change	Wazuh log analysis with a Security Onion case workflow for correlation

Detection logic for adversary-in-the-middle, with tuning and false positives

Adversary-in-the-middle activity works by changing the path or the trust decisions that clients rely on, so the useful detections compare what a host or sensor sees against a known baseline. The cards below describe each signal, the thresholds to tune for your environment, and the benign sources that will trigger it first. Treat every threshold as a starting point to be confirmed in a lab before it reaches production alerting.

Unexpected name resolution changes

Watch for hosts that resolve internal or high-value service names to addresses outside the approved range, or for resolver settings that change without a matching change ticket. The logic compares resolved answers against an authoritative baseline for a fixed list of identity, mail and API endpoints. Tune the list to services that matter most, and start with a short watch window so you can see normal churn. Common false positives include split-horizon DNS, VPN clients that push their own resolvers, and CDN address rotation for public names.

Certificate mismatches seen by sensors

Network sensors can record the certificate presented for a named service and compare its issuer, subject and fingerprint with the last known good value. A change for an identity provider, mail gateway or internal API is a strong signal to investigate, especially when the new issuer is not in your private trust chain. Set the comparison to alert only on services in a defined list, because public sites rotate certificates often. Common false positives include planned certificate renewals, TLS inspection proxies, and certificate authority migrations that have not yet been recorded in the baseline.

Changes to trust stores

Record additions and removals of root or intermediate certificates on endpoints and servers, and correlate them with the change that should have caused them. A new trusted root that appears outside a managed deployment, or a trust store file modified by an unexpected process, deserves immediate review. Alert on additions to the system trust store first, because user-level additions are noisier. Common false positives include corporate root certificates pushed by management tools, developer tooling that installs local certificate authorities, and browser updates that refresh bundled stores.

Anomalous authentication retries

Count failed and repeated authentication attempts per account, per source and per target within a sliding window, and look for patterns where a client retries after a certificate or TLS error, or where a login succeeds from a new network path immediately after a name or certificate change. Thresholds should come from your own baseline for each application, not from a generic number. Common false positives include password expiry prompts, mobile clients on unstable networks, and service accounts that retry on a timer.

Unexpected file changes to proxy settings

Monitor modifications to proxy configuration, hosts files and client-side network settings on endpoints and servers, and flag changes made outside a configuration management run. A change that redirects traffic for an internal name to an unknown proxy is a direct path to interception, so compare file hashes and ownership with the approved baseline. Review the process that made each change. Common false positives include VPN and endpoint agents that write proxy settings on connect, and administrators who edit hosts files during incident work.

How to validate that the detection fires in a lab

This sequence proves that the T1557 detection fires on the telemetry you expect, in a private range rather than production. It produces a signed-off test record that ties a hypothesis, the ATT&CK v20.0 technique and sub-technique under test, the rule version and the observed alert timing together, along with a list of gaps to fix.

Write the hypothesis and scope the test
The detection owner and the red team lead agree in writing on one hypothesis, for example: when an adversary-in-the-middle activity is simulated against a lab identity flow, the Application Log Content and Network Traffic Content sources will produce events that the chosen rule raises as an alert. The record names the ATT&CK v20.0 technique T1557 and the sub-technique under test, the platforms in scope (Linux, macOS, Network Devices or Windows), and the systems that are off limits. The step is done when the lab owner signs the scope and the test is approved for the range only, never production.
Define expected telemetry and pass criteria
Before any activity runs, the team lists the events each data component should produce on each in-scope host or device, such as application log entries, network traffic records and file modification events where the sub-technique relies on them. It also sets pass criteria in plain terms: the expected event reaches the Wazuh, Security Onion or other collection pipeline, the rule matches it, and an alert is raised with the correct host and severity. The step is done when the criteria sheet is reviewed by a second analyst, so the team cannot change the bar after seeing results.
Confirm log sources and rule version
Before the exercise, an engineer checks that each source is forwarding, that clocks are synchronized across the range, and that the detection rule is deployed at a recorded version. The team notes the exact rule identifier and version, and the ATT&CK v20.0 mapping the rule targets, since techniques can be renamed or deprecated between releases. The step is done when a test event from each source appears in the SIEM with the expected fields, which confirms the pipeline works before the emulation starts.
Run the emulation plan in the range
A red team member or an authorized emulation operator executes the agreed plan inside the private cyber range, following the written steps and nothing beyond them. A second observer logs the start and end time of each action against the range clock so later timing analysis is possible. The step is done when every planned action is marked as executed, skipped or failed, with the reason recorded, and no activity has reached systems outside the range.
Compare observed telemetry with expectations
The detection engineer reviews the raw events and alerts against the criteria sheet, checking each expected data component one by one. Events that arrived but did not match the rule are separated from events that never arrived, because they point to different fixes: rule logic versus collection. The step is done when each criterion is marked as met, partly met or not met, with a link to the evidence in the SIEM.
Measure alert timing and fidelity
The team calculates the delay between each emulated action and the first matching alert, using the range clock, and checks whether the alert carried the correct host, user and technique context. It also notes false positives raised by normal lab traffic during the window. The step is done when the timing and fidelity results are written next to each criterion, and the team agrees whether the delay is acceptable for the response runbook. Ask your own operations team what delay they require, since no benchmark is set here.
Record gaps and assign remediation
The final record lists every gap: missing log sources, rule logic that failed to match, alert routing errors, and mitigation coverage such as User Training or Encrypt Sensitive Information that did not work as intended. Each gap gets an owner, a fix, and a retest date agreed by the sponsor. The step is done when the signed record, including the rule version and the ATT&CK v20.0 mapping, is filed with the detection library so the test can be repeated after any change.

Where the traffic path and trust boundaries matter most

An adversary-in-the-middle only works where the traffic path crosses a boundary the defender does not fully control. For T1557, that usually means the segment between a client and the service it reaches, where an intermediary can read, relay or alter the exchange. In practice this includes shared wireless and access segments, the links between user subnets and server zones, traffic that crosses a VPN or WAN edge, and any hop through a network device managed by a different team or provider. Start by drawing the path for your most sensitive authentication flows (single sign-on, directory binds, administrative consoles and API calls carrying tokens) and mark every point where a host, device or segment is shared, unmanaged or administered outside your change process.

Once the path is drawn, reason about each boundary in two directions. Ask what the client would notice if a hop answered in place of the service, and what the service could observe about the client. Those answers point to the telemetry that matters. Network Traffic Content shows whether a session presented an unexpected certificate, protocol downgrade or name mismatch at the edge. Application Log Content on the service records authentication failures, certificate validation errors and unusual source addresses. File Modification on network devices and proxies can reveal changes to routing, name resolution or trusted certificate stores. Confirm with each platform owner which of these sources you can actually collect at each boundary, because a path you cannot observe is a path you cannot defend in this way.

Treat the path review as a decision exercise, not a one-time diagram. Decide which boundaries require encrypted, mutually authenticated sessions with pinned or strictly validated certificates, and which need a monitoring point such as a sensor span or inspection log. Record the owner, the expected certificate authority and the normal peer for each critical service so that an unexpected change is easy to spot. Confirm with your network and identity teams how changes to trust stores, DNS resolvers and device configurations are approved and logged, since those changes are the usual way an intermediary is placed. Use the result to scope the cyber range scenario in the later exercise section, so that the rehearsed path matches the boundaries you actually operate.

Mitigations that reduce adversary-in-the-middle exposure

T1557 Adversary-in-the-Middle works because an adversary sits between two parties and relays or alters their traffic. The two mitigations mapped to this technique in the ATT&CK knowledge base reduce that exposure from different angles: people recognize and report suspicious interception, and the protocols themselves make interception less useful. Neither replaces network monitoring, so each card names what the defender should confirm in their own environment.

User Training against interception prompts

User Training (M1017) addresses the human side of T1557. Users who are taught to read certificate warnings, unexpected login prompts and unusual redirects are more likely to stop and report them instead of accepting them. Training should cover the specific lures used in your organization, such as fake Wi-Fi captive portals, certificate pop-ups on internal applications and sudden changes to single sign-on screens. Confirm that reports reach the security team and that someone reviews them within a defined window. Training without a reporting path gives users nothing to act on.

Encrypt sensitive traffic end to end

Encrypt Sensitive Information (M1041) reduces what an adversary gains from intercepting traffic. When credentials, session tokens and business data travel over protocols that are encrypted and authenticated, an in-path observer sees ciphertext instead of usable secrets. The defender must confirm which internal and external protocols carry sensitive data without encryption, such as legacy HTTP, unauthenticated LDAP or plain-text mail submission. Confirm also that clients validate server certificates instead of accepting any certificate, since an encrypted channel that skips validation can still be intercepted.

Inventory unencrypted protocols and flows

Encryption only helps where it is applied, so an inventory of protocols in use is the starting point. Build a list of services that carry authentication or sensitive data and record whether each one enforces encryption on every hop. Include internal service-to-service calls, printers, network appliances, and management interfaces, which are often overlooked. The inventory also feeds detection work, because Network Traffic Content telemetry is most useful when the defender knows which plain-text flows should not exist.

Enforce certificate validation in clients

Certificate validation is the control that turns encryption into protection against T1557. Applications, scripts, and devices should reject certificates that are untrusted, expired, or issued for a different host name. Review internal tooling and configuration for settings that disable verification, because these are common shortcuts during development and remain in production. Confirm which certificate authorities clients trust, and who can add to that trust store on managed endpoints. Changes to trust stores are also worth logging through File Modification telemetry.

Retire legacy name resolution fallbacks

Name resolution fallbacks give an adversary a way to redirect clients without touching the target network. Protocols that answer broadcast or multicast queries when a normal lookup fails can be answered by a rogue host on the same segment. Decide which of these protocols your environment still needs, disable the rest through configuration management, and confirm the change on every endpoint group. This is a configuration decision that the defender should document and verify, not assume.

Triage and response when an adversary-in-the-middle alert fires

Start by deciding whether the alert describes a real interception or a benign change, because the response to each is very different. For T1557 Adversary-in-the-Middle, the first checks are whether the alert correlates with a known event such as a planned network change, a certificate renewal, a new proxy or inspection appliance, or a wireless roaming event, and whether the same ARP, DNS or name resolution response pattern appears on more than one host. Confirm with the network and platform owners which changes were scheduled in the alert window before treating the alert as malicious. Record the decision and its reasons in the case file, including the Wazuh, Security Onion or Zeek alert identifiers that were reviewed, so the false positive can be tuned later without losing the audit trail.

If the alert is not explained, identify the affected hosts, segments and accounts. Pull the source and destination pairs, the MAC or IP addresses involved, and the authentication events for any account that logged in from or to the suspected position during the window. Check whether the same accounts reused passwords or session tokens on other systems, and whether any affected user submitted credentials to an unexpected certificate or login page. Preserve evidence before you contain anything: capture the relevant network traffic, export the Zeek connection and TLS logs, collect ARP and DNS caches from the affected endpoints, and hash the logs. Ask the platform owner which of these sources are retained, for how long, and whether packet capture is permitted under your policy.

Contain the interception path first, then rotate credentials. Isolate or move the affected endpoints from the suspect segment, block the rogue address at the switch or firewall, and restore correct name resolution or certificate trust once the source is confirmed. Rotate passwords and revoke sessions for accounts that were exposed, starting with privileged and service accounts, and reissue any certificates that may have been accepted in error. Decide in advance who may authorize containment on production systems, and confirm with the platform owner how your self-hosted identity provider and VPN handle forced sign-out and token revocation. Close the case only after you have validated that the interception has stopped, that the monitoring still sees the expected traffic, and that the lessons feed back into your MITRE ATT&CK updates mapping for the version you target.

Rehearsing adversary-in-the-middle detection in a private cyber range

A Linux and macOS segment of the range should mirror the client's real host build: the same base images, the same trust store configuration, the same package sources and the same log forwarding agent. The range topology is usually a small set of workstations and application servers on an isolated segment, with a monitored gateway and a Wazuh or Security Onion sensor that sees the traffic between them. The injects tell the blue team that a host's trust configuration or name resolution has changed, and they must decide whether that change was authorized. Injects describe the observable state only, such as a modified certificate store entry or a new proxy setting, and never explain how it was produced.

Telemetry checks: Confirm that file integrity monitoring covers the system trust store and the relevant configuration directories, and that the agent forwards changes within an interval the team has agreed.
Good detection: An alert that names the host, the changed path, the user context and the previous value, correlated with any change ticket.
Good response: Triage separates a planned change from an unplanned one within the runbook's target window, and the host is isolated only when the change is unexplained.
Common gap: macOS endpoints often sit outside the same log pipeline as Linux servers, so confirm coverage before the exercise.
Record: Keep the timeline of alerts and analyst decisions for the post-exercise review.

Check whether every Linux and macOS host in scope reports to the central platform and whether the trust store changes are visible there.

Questions SOC leads ask about detecting T1557

How do I tell certificate rotation from adversary-in-the-middle activity?

Treat a certificate change as suspicious until a planned change record explains it. Legitimate rotation usually follows a known schedule, comes from a known issuer and touches a known set of hosts, so the signal is the exception: a new issuer, a new subject, or a change on a host that had no maintenance window. Correlate certificate fingerprint changes from network telemetry with change tickets and certificate inventory, and alert on fingerprint changes that appear on several clients at once or on internal services that never rotated before. Confirm with your platform team which certificate authority and rotation workflow each service uses, because the baseline is only as good as your inventory. Keep the alert in a triage state until the change record is checked.

Which telemetry should a SOC enable first for T1557?

Start with the sources that show who spoke to whom and whether the session was trusted. Network traffic content from sensors such as Zeek or Suricata gives you certificate and protocol metadata. Application logs from identity providers, VPN concentrators and web proxies show failed trust decisions, unexpected redirects and authentication prompts. File modification telemetry on endpoints covers changes to trust stores, proxy settings and host resolution files on Linux, macOS and Windows. Enable these in that order because they cover the most sub-techniques with the least tuning. Document which data components your version of ATT&CK maps to, and confirm the current mapping in the MITRE ATT&CK tactic page for Credential Access before you build coverage reports.

How do I tune T1557 detections for VPN and proxy traffic?

Tune by identity of the device and the path, not by suppressing whole subnets. VPN gateways and corporate proxies legitimately terminate and re-issue TLS, so they will trip certificate-change logic. Build an allowlist that names the specific gateway, its issuing authority and expected certificate lifetime, and review it whenever the gateway is rebuilt. Keep alerts for the same gateway if the issuer changes, if the certificate is presented to hosts outside the expected population, or if the proxy begins handling traffic it never handled before. Test each allowlist entry in your cyber range with a simulated proxy so you know the rule still fires when the expected issuer changes.

How do I confirm which ATT&CK version my T1557 mapping targets?

Record the ATT&CK version in every detection rule, coverage matrix and runbook, then check it against the release record. MITRE publishes each release with notes on renamed, deprecated or revoked techniques, and detection mappings that do not name a version become hard to audit. Pull the matching STIX bundle from the attack-stix-data repository for the version you target, and confirm that T1557 and its sub-techniques still exist with the expected names. The ATT&CK updates page lists each release, so schedule a review when a new one ships and compare the changelog against your rule set.

How should we retest T1557 detections after a new ATT&CK release?

Retest the rules that depend on changed content, not the whole library every time. First compare the release notes against your T1557 coverage, noting any renamed sub-techniques, changed data components or deprecated data sources. Then rebuild the test cases for the affected detections in a private cyber range, run controlled simulations of the behavior described in the technique, and record whether each alert fires, how long triage takes and which false positives appear. Keep the results with the rule version so an auditor or engineer can see what changed. Ask your team to define pass criteria before the test, so the outcome is not judged after the fact.

Can our own team run T1557 detection and range exercises without outside help?

Many teams can, provided they have the telemetry, staff time and a safe environment to test in. The core work is enabling network, application and file sources, writing and tuning rules, and keeping a cyber range that mirrors production trust paths without touching live users. The ongoing cost is mostly staff time: someone must review certificate inventory, tune allowlists and retest after each ATT&CK release. Ask a provider to show how they would scope this work in writing, including which sources, which sub-techniques and which environments are covered. DeployOpen implements and supports self-hosted open-source platforms in your own infrastructure and runs private cyber ranges and security testing, so the scope can be agreed in writing before work starts.

Primary sources for T1557 and ATT&CK v20.0

Before you map any detection to T1557 Adversary-in-the-Middle, fix the ATT&CK version you are targeting. This page uses Enterprise ATT&CK version 20.0, which MITRE released on October 13, 2026. Start with the technique description and sub-technique list on the MITRE ATT&CK site, then read the Credential Access tactic page for the context in which T1557 is used. Check the four sub-techniques, their names and their mitigation links against that same version before they enter your detection backlog, since the sub-technique set is the part most likely to change between releases. Record the version in every rule, ticket and cyber range scenario so later reviews compare like with like.

Release notes are the second check. ATT&CK v18, released October 28, 2025, replaced technique-level detections with detection strategies and analytics, updated data components and deprecated some data sources. v19 followed on April 28, 2026. This matters for T1557 because the telemetry named for it, Application Log Content, Network Traffic Content and File Modification, sits inside that changed model. Read the ATT&CK updates pages and confirm whether File Modification is still a current data source in your target version or has been replaced by a data component. Then update your Wazuh, Sigma and Zeek mappings to match, and assign one engineer to repeat this review each release cycle.

The enterprise-attack 20.0 STIX bundle is the authoritative machine-readable copy of the matrix. MITRE publishes ATT&CK content as STIX 2.1 JSON in the attack-stix-data repository, with one bundle per domain and version. Load the Enterprise bundle for 20.0 to pull the T1557 object, its sub-techniques, and its detection strategy, data component and mitigation relationships, then diff it against the previous release. Confirm that the mitigation IDs you cite for T1557, including User Training (M1017) and Encrypt Sensitive Information (M1041), still apply in that bundle. Keep the bundle file name and checksum in your change record so an auditor can see exactly which content your detections were built against.

How DeployOpen builds T1557 detections and cyber range scenarios

DeployOpen approaches T1557 Adversary-in-the-Middle as a fixed-scope engagement inside the client's own environment, starting from the telemetry the organization already collects. Detection logic, test scenarios and documentation are written against a named ATT&CK version so they stay traceable as the knowledge base changes.

How we scope

Agree in writing which platforms, network segments and sub-techniques of T1557 are in scope.
Inventory existing telemetry for application logs, network traffic content and file modification on each platform.
Confirm the target ATT&CK version and the data components the detections will rely on before work starts.

How we build

Write detection logic for Wazuh, Security Onion, Suricata, Zeek or Sigma as the client's stack requires.
Map each rule to its ATT&CK detection strategy and analytic so coverage can be reviewed line by line.
Build a private cyber range scenario that reproduces the relevant T1557 conditions in a controlled network.

How we hand over

Deliver validation results showing which detections fired, which missed, and why, in the client's environment.
Document alert triage steps, escalation paths and containment actions for the security operations team.
Provide training material for analysts and a rehearsal plan the client can repeat after handover.

How we support

Review detections when ATT&CK releases rename, deprecate or revoke techniques that the rules depend on.
Retest detections after changes to network design, logging configuration or certificate management.
Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the fixed-scope work.

T1557 Adversary-in-the-middle