How T1111 multi-factor authentication interception shows up in a SOC queue
If your organization has MFA enabled on identity and remote access, a SOC lead still needs to ask whether a second factor can be captured or replayed by an adversary who already holds a password. T1111 Multi-factor authentication interception is the ATT&CK technique that describes this: an adversary tries to obtain the one-time or secondary authentication material that a user receives or submits, so that the password-only protection MFA was meant to add is bypassed. It sits under Credential Access (TA0006), whose stated goal is to steal account names and passwords, and the second factor is often the step that makes a stolen password useful. In practice, the technique tends to appear after an earlier phase has already succeeded, such as phishing or credential theft, so the first alert in the queue may be an authentication event rather than anything that looks like theft.
For mapping purposes, the ATT&CK version matters. This page targets Enterprise ATT&CK 20.0, and the identifiers, data component names and mitigation names used here should be checked against that version before you write rules or coverage reports. ATT&CK notes that releases can rename, deprecate or revoke techniques, and recent releases (v18, v19 and v20) have changed detection content and data components, so a mapping built against an older version can silently drift. Confirm the version in your SIEM content, your detection inventory and any vendor rule packs. The current mitigation references for this technique, including User Training, should also be verified against the version you adopt before you cite them in an audit or readiness report.
Which telemetry reveals T1111 on Linux, macOS and Windows
This table maps the data components named for T1111 to the signal each one can reveal on Linux, macOS and Windows, and the open-source collector that gathers it. Read the rows together: endpoint data shows processes touching the authentication path, while identity logs show whether an MFA challenge completed. Confirm the 20.0 mapping for this technique in the enterprise-attack STIX bundle before building content on it.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| Process Creation (DC0032) | Unexpected binaries launched from user-writable paths or by unusual parent processes on all three platforms | Wazuh agent with auditd on Linux and Sysmon on Windows, plus Velociraptor for hunts on macOS and Linux |
| Process Access (DC0035) | Handles opened to authentication or session-related processes, mainly visible on Windows | Sysmon process access events forwarded through the Wazuh agent, with Velociraptor for targeted queries |
| Logon Session Creation | New logon sessions for MFA-protected accounts that lack a matching challenge or approval event | Windows Security logon events and Linux PAM logs collected by Wazuh, correlated in Security Onion |
| User Account Authentication (DC0002) | MFA challenge, denial and success events from the identity provider, compared against the endpoint session | Identity provider log integrations ingested by Wazuh, with Security Onion for cross-source review |
| Network Traffic Content (DC0085) | Authentication requests to the identity provider from unexpected hosts or sessions that skip normal MFA steps | Zeek and Suricata sensors in Security Onion, where the protocol content is visible to the sensor |
| Platform visibility gap | macOS process access and some session telemetry may be thinner than Windows, so confirm coverage before relying on it | Confirm with the endpoint vendor or Velociraptor artifact coverage for the macOS build in use |
Detection ideas for MFA interception that a SOC can tune
The cards below describe detection ideas for T1111 Multi-factor authentication interception, grouped by where the signal appears: endpoint process behavior, access to credential and session material, and identity logs. Each idea needs a baseline from your own environment before thresholds are set, and each has known benign sources that should be excluded deliberately rather than by blanket suppression.
Process behavior around authentication stores
Track which processes start or spawn from authenticator-related applications, browser profiles and credential helper services using Process Creation telemetry from Linux, macOS and Windows endpoints. Start with a baseline of parent and child pairs seen over several weeks, then alert on new pairs that involve a credential store or a helper that normally runs without user interaction. Tune by host role, since developer workstations and privileged administration jumpboxes will differ. Main false positives come from password managers, authenticator apps that update themselves, and IT tooling that inventories or repairs browser profiles.
Non-browser access to session material
Flag Process Access or File Access events where a process that is not a browser, authenticator or known sync agent reads browser profile stores, token caches or session databases. Baseline the reader processes per host class, and set thresholds on the count of distinct stores touched within a short window rather than on any single read. Confirm with your endpoint vendor or Sysmon configuration which access rights are logged, because coverage varies. Main false positives include backup software, endpoint protection scanners and migration tools that copy profiles on schedule.
Anomalous authentication sequences in identity logs
Use User Account Authentication events from your identity provider to find sign-in patterns that fit an MFA interception chain: a successful password check followed by a second-factor event from an unfamiliar device, network or user agent, often close in time to a prior session change. Tune thresholds on time between factors, and on the number of distinct locations per user over a rolling window. Expect false positives from travel, VPN exits, device replacement and help desk resets, so join alerts to ticket data where possible.
Sigma rule logic for correlated signals
Express the endpoint and identity ideas as Sigma rules so they can be converted to your SIEM or Wazuh query language and version-controlled. Keep each rule narrow, then correlate outputs at the case level instead of paging on each rule alone. Record the ATT&CK version each rule targets, since technique mappings change between releases, and review rule logic after every ATT&CK update. Expect false positives to cluster in the same benign sources named above, so document an exclusion reason for each allowlist entry and set an expiry date for it.
Baseline and tuning governance
Treat every threshold as a hypothesis that needs a measured baseline from your own estate, recorded with the time window, host groups and sample size used. Review false positive sources with the teams that own password managers, authenticator apps and IT tooling before changing rules, and track alert volume before and after each change. Ask your identity and endpoint vendors to confirm which fields are logged for each event type, because absent fields silently disable detections.
How to validate that the T1111 detection fires
This sequence proves, in a private cyber range, that the T1111 detection produces the expected alert on each platform, with evidence tied to a named rule and ATT&CK version. It ends with a tuning review so the rule is kept only where it is accurate and explainable.
Define scope and approved emulation owner
Before any test, the security lead writes down which Linux, macOS and Windows hosts, identity services and MFA-related log sources are in scope, and which systems are explicitly excluded. A named emulation owner is approved in writing, and the test window and rollback contact are recorded alongside the scope. The step is done when the signed scope document is stored with the test plan and every in-scope host appears in the asset inventory. Confirm the wording of the authorization with your legal and change management teams, since rules of engagement differ by organization.
Document the ATT&CK version and expected telemetry
The test plan states the ATT&CK version the detection targets, because releases can rename, deprecate or revoke techniques and the mapping must match the version in use. For each platform, the team lists the data components expected to carry evidence, such as Process Creation, Process Access and Logon Session Creation, along with the log source that holds them. The step closes when a per-platform telemetry matrix is reviewed and every expected field exists in the Wazuh, Security Onion or other collection pipeline in the range. Gaps found here are fixed before any emulation runs.
Confirm telemetry arrives on Linux, macOS and Windows
Before emulation, the detection engineer checks each platform separately to confirm that the agent is forwarding the relevant events to the SIEM. Linux, macOS and Windows hosts each have different event sources and field names, so a single passing check on one platform does not prove the others. The engineer uses a benign, non-emulated activity to confirm arrival, and records the event timestamps and host identifiers. The step is complete when each platform shows the expected events in the search interface with correct parsing.
Run the approved emulation in the range
The emulation owner runs the agreed, documented test within the approved window, following the written plan rather than improvising. Each step is logged by the owner with a start time, end time and the host it ran on, so later analysis can align the activity with telemetry. The observer records any deviation from the plan. The step is done when the owner signs the run log and the range is returned to its baseline state. Specific emulation actions are kept in the approved test plan and are not reproduced in this page.
Verify the alert fires for each platform
The detection engineer checks, separately for Linux, macOS and Windows, whether the T1111 rule produced an alert within the expected window. For each alert, the engineer confirms the rule identifier, the affected host, the matched fields and the timestamp, and compares them against the run log. A platform with no alert is treated as a failed test for that platform, not as a pass for the whole rule. The step closes when a result is recorded for every platform in scope.
Record evidence with rule ID and ATT&CK version
The team packages the evidence for each run: the scope document, the telemetry matrix, the emulation log, the alert records with timestamps, the rule identifier and version, and the ATT&CK version the rule targets. The package is stored in a controlled location with a dated index so an assessor or internal reviewer can trace one alert back to one planned action. The step is done when a reviewer who did not run the test can follow the chain from plan to alert without asking the owner for clarifications.
Hold the tuning review and retest
After the run, the detection engineer and the emulation owner review any false positives, missed events and noisy alerts with the operations team. Changes to the rule are logged as versioned edits with a reason, and the affected platforms are retested against the same plan. The review also asks whether user training and multi-factor authentication controls, which ATT&CK maps to this technique as mitigations, are working as intended. The step closes when the review outcome is filed, and any rule that still cannot be explained is removed from production until it is fixed.
Preventive controls that reduce MFA interception risk
T1111 succeeds when a user approves, reads out, or enters a second factor for an attacker who already has the password. Preventive controls therefore sit in two places: how people respond to unexpected prompts and codes, and how identity configuration limits what an intercepted factor can do. The cards below cover the first in depth and the supporting controls that make detection and recovery easier.
Train users on unexpected prompts
User Training (M1017) is the mitigation ATT&CK maps to T1111, and it is the control that addresses the human step directly. Teach staff that a push approval, call, or code request they did not start is a security event, not an inconvenience. Use deny and report as the default action, and make the reporting path short enough that people use it at night and on weekends. Check that training covers mobile and desktop prompts alike, and confirm the mapping against the enterprise-attack 20.0 bundle before citing it in an audit file.
Rehearse the number-matching decision
Illustrative scenario: a help desk employee receives a sign-in approval at 2 a.m. and a caller claims to be from IT asking them to accept it. Training should give people one script for this case, including that no legitimate support team asks for an approval or a one-time code. Run short exercises with real prompt screens from your own identity provider, not generic slides, so staff recognize the layout they will see under pressure.
Review account recovery and enrollment
Attackers often target the path that registers a new factor after a password reset. User Account Management (M1018) covers how enrollment, recovery, and privileged account changes are approved and logged. Ask who can add a second factor for another user, whether that action requires a second approver, and whether help desk tools can bypass the normal verification step. Confirm with your identity provider which of these controls it supports and how they are configured.
Log factor changes and sign-in events
Audit (M1047) supports detection of T1111 by making factor enrollment, approval outcomes, and sign-in context available to analysts. Forward identity provider logs to your SIEM, such as Wazuh, and retain enough history to compare a suspicious approval with the user's normal sign-in pattern. Verify that logs record which factor was used, the source network, and the device, since those fields decide whether an analyst can separate a real user from an intercepted session.
Limit approval fatigue at the policy layer
Repeated prompts are the pressure that makes users approve by reflex. Review your identity provider's prompt limits, lockout behavior, and number-matching settings, and decide which sign-in risk levels should require a stronger factor than a simple push approval. Document these settings as configuration evidence, and confirm the exact options with the vendor, because naming and availability differ between products and versions.
What to do in the first hour after a T1111 alert
The first decision after a T1111 alert is whether the signal is a genuine interception or a benign event such as a user re-enrolling a phone or a helpdesk reset. Confirm the alert against the raw events in your SIEM before anything else, then identify the affected account, the device or enrolled factor involved, and the application the user was signing in to. Record the time of the factor event, the source address and the client details, because these fields anchor every later step. Check the identity provider's sign-in history for the same account over the preceding days, looking for concurrent or impossible-travel sign-ins, successful authentications that follow a factor change, and session lifetimes that look longer than the user's normal pattern. Treat any of these as a reason to escalate immediately rather than wait for the full picture.
Containment should favor speed and reversibility. Revoke active sessions and refresh tokens for the account, force a password reset through a channel you trust, and remove or re-enroll the affected factors so that the attacker's enrollment no longer validates. Confirm with the user out of band before they re-enroll, since a convincing prompt is exactly what an attacker wants them to accept. Where the endpoint may be compromised, isolate it according to your incident runbook, but avoid rebooting or wiping it until volatile evidence has been captured. Check whether the same account has elevated roles or access to sensitive applications, and apply temporary restrictions to those paths while the investigation is open.
Preserve evidence before you change more than you must. Export identity provider sign-in and factor audit logs for the account, the endpoint's process creation and logon session records for the window around the alert, and any proxy or VPN logs that show the source of the session. Store copies in write-once or access-controlled storage with hashes recorded, and note who exported what and when. Escalate to the incident commander, the identity team and, if the account belongs to a privileged or regulated system, the relevant data protection or compliance owner. Confirm your organization's notification timelines for each escalation path in advance, because the first hour is when they are easiest to miss.
How to rehearse T1111 detection in a private cyber range
The Linux tab covers a private range built from representative Linux hosts joined to the same identity and logging path as production workstations and servers. Approved staff run emulation under written rules of engagement, and every inject is logged with a timestamp so detections can be matched to actions afterward. The range should record Process Creation telemetry and the authentication events that follow it, so analysts can see whether a suspicious process interacts with MFA-related components.
- Topology: Two or three Linux hosts, a log collector, and a Wazuh or Security Onion instance receiving the same agent feeds as production.
- Injects: Staged scenarios where an approved emulator attempts to intercept or tamper with MFA-related user activity on a host, described in the emulation plan rather than in tooling detail.
- Expected detections: Alerts tied to unusual process lineage, unexpected writes to authentication-related paths, and anomalous sessions following local activity.
- Response: Analysts should triage the alert, confirm the user and host, isolate the session and document the decision within the agreed response window.
- Scoring: Time to detection, alert fidelity, whether the correct runbook was used and whether evidence was preserved.
Before the exercise, confirm with your Linux platform team which audit rules and log sources exist in your environment.
The macOS tab uses a private range of managed Apple endpoints that mirror the configuration of your executive and developer fleet. The main concern is whether your endpoint telemetry captures the process and access events needed to spot interception of MFA activity, and whether analysts can tell a legitimate authenticator app from suspicious behavior. Confirm the telemetry available from your chosen agent before designing injects, because coverage varies by product and version.
- Topology: Several managed macOS endpoints enrolled in your device management platform, with forwarding of endpoint logs to the SIEM.
- Injects: Approved, scripted scenarios that simulate suspicious access to authenticator-related data on a user device, run only by approved staff.
- Expected detections: Process Access and Process Creation events that deviate from the baseline for the user and device.
- Response: Analysts should check whether the device is compliant, review recent sign-ins, and decide on containment without disrupting a legitimate user.
- Scoring: Whether the device owner was reached, whether the response avoided unnecessary lockout and whether the timeline was reconstructed accurately.
Confirm with your endpoint vendor which macOS event types are collected and how long they are retained.
The Windows tab covers a private range built from domain-joined workstations and a member server, with Sysmon-style or vendor endpoint telemetry forwarded to the SIEM. Windows usually provides the richest event coverage, including Logon Session Creation, so this environment often produces the most detections. The exercise should test whether analysts can connect an endpoint event to an authentication event in the identity provider.
- Topology: Domain controller, two or three workstations, and a Wazuh or equivalent manager with Windows event collection enabled.
- Injects: Approved emulation of MFA interception behavior on a workstation, followed by a sign-in attempt from an unfamiliar context.
- Expected detections: Correlated alerts across Process Creation, Process Access and Logon Session Creation for the same account and time window.
- Response: Analysts should revoke sessions, reset affected factors through the approved process and check for lateral movement.
- Scoring: Correlation accuracy, mean time to contain, and whether the account lockout or factor reset followed policy.
Confirm which Windows audit policies are enabled in production, because the range can only prove detections that the production configuration would also generate.
The identity provider tab tests the detections that matter most to MFA interception: unexpected factor enrollment, repeated challenge failures, sign-ins from new devices, and changes to recovery methods. The range should run an identity provider instance that matches production settings for MFA policies, session lifetime and conditional access. Analysts should be able to distinguish a user who was legitimately prompted from a session that was manipulated after authentication.
- Topology: A non-production tenant or instance of your identity provider, with authentication logs forwarded to the same SIEM used by endpoint teams.
- Injects: Approved scenarios that create unusual factor changes, sign-ins from unfamiliar devices and rapid challenge sequences.
- Expected detections: Alerts on factor changes, impossible travel patterns and unusual MFA push or code patterns.
- Response: Analysts should review the sign-in context, challenge the user through an out-of-band channel and apply conditional access controls.
- Scoring: Detection latency, whether the identity team was engaged and whether recovery methods were verified before being trusted.
Confirm with your identity provider which MFA and factor-change events are exposed in its log export, and how long those logs are kept.
Questions SOC leads ask about detecting T1111
How do I confirm which ATT&CK version my T1111 detection rule targets?
Record the ATT&CK version in the rule metadata and in your detection register, and check it against the version your mapping was built from. MITRE publishes ATT&CK content as STIX 2.1 bundles, one per domain and version, in the attack-stix-data repository, so you can pull the exact bundle and confirm the technique and sub-technique IDs your rule references. Releases can rename, deprecate or revoke techniques, so a rule mapped to an older version needs a review each time you adopt a new release. Confirm the version your team uses with your own change record before you rely on any mapping.
How should my team handle ATT&CK v18 detection strategies and DET IDs for T1111?
ATT&CK v18 moved detections on technique pages into detection strategies identified by DET IDs, built from analytics, and it updated data components identified by DC IDs. Treat each DET ID as the unit of coverage: link your SIEM rule or Sigma rule to the strategy it implements, and record which data components its analytics depend on. Where a strategy references a data component you do not collect, mark the gap rather than assuming coverage. Confirm the current strategy and analytic wording in the ATT&CK updates notes before you map your rules.
Which telemetry should I retain to detect T1111 across Linux, macOS and Windows?
Start with the data components that the detection logic for this technique depends on: Process Creation, Process Access and Logon Session Creation, with User Account Authentication where your identity provider exposes it. Retain enough context to tie a process or session to a user, host and time, because interception usually shows up as an unusual combination rather than a single event. Confirm retention periods against your own regulatory and incident response requirements, and check that your Wazuh or Security Onion pipeline keeps these events long enough for investigation.
How do I keep authenticator app activity from creating alert fatigue?
Most noise comes from legitimate authenticator apps, enrollment flows and helpdesk tooling that behave like interception. Build an allow list keyed on signed binary paths, known hosts and expected parent processes, and review it with the identity team before tuning. Route low-confidence matches to a hunting queue rather than the paging queue, and require a second signal, such as an anomalous logon session or an unexpected user context, before escalation. Track the false positive rate per rule during a tuning period and retire allow list entries that no longer match current software.
How do I measure detection coverage for T1111 without overstating it?
Coverage is the share of your mapped analytics that run against telemetry you actually receive and have validated, not the number of rules you have written. For each analytic, record the data source, the host groups it covers, the last successful test date and any known blind spots such as unmanaged macOS endpoints. Compare the result with the mitigation work your organization has done, including User Training (M1017), so that reporting shows both detection and prevention. Present coverage as a dated statement with its gaps, and have an independent reviewer check the method before you share it.
Can my team rehearse T1111 detection in a private cyber range before production?
Yes, a private cyber range lets you replay controlled scenarios against isolated copies of your endpoints and identity stack, then check whether your alerts fire with the expected context. Define the scenario in writing, the telemetry it should produce, the expected alert and the response steps, then record what actually happened. Repeat the exercise after each rule change and after each ATT&CK version update. DeployOpen can design and run such exercises as a fixed-scope engagement, with scope agreed in writing before work starts.
What does DeployOpen handle versus what my own team must keep doing?
DeployOpen can plan, implement and document the open-source logging, detection and cyber range components inside your own infrastructure, and it can run security testing and rehearsal exercises. Your team keeps ownership of the identity configuration, the business decisions on alert severity and the sign-off on allow lists, because those depend on knowledge of your environment. Ongoing tuning, version mapping and continuous testing can be covered by a retainer. Ask for the division of responsibilities in the written scope, and confirm which tasks your own staff must perform each month.
How DeployOpen builds T1111 detections and purple team exercises
DeployOpen approaches T1111 Multi-factor authentication interception as a fixed-scope engagement inside the client's own infrastructure, starting from the telemetry the client already collects. The work is agreed in writing, built against a named ATT&CK version, and handed over with runbooks and evidence the client's own teams can maintain.
How we scope
- Confirm which Linux, macOS and Windows estates and identity sources are in the written scope for T1111.
- Inventory whether Process Creation, Process Access and Logon Session Creation telemetry is already collected and retained.
- Record the ATT&CK version the detections target, since releases can rename or deprecate techniques.
How we build
- Map detection logic for T1111 to the telemetry sources confirmed during scoping, using open-source tooling such as Wazuh or Sigma rules.
- Tune rules in a private cyber range first, so alert volume and false positives are understood before production rollout.
- Document each detection with its data dependencies, known blind spots and the mitigations it supports, including User Training (M1017).
How we hand over
- Deliver detection content, configuration and validation scripts in version-controlled form the client can own.
- Provide a purple team exercise plan that the client's security team can rerun against its own environment.
- Hand over runbooks for triage and response, with a written record of what was tested and what remains open.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope handover.
- Review detection coverage for T1111 again when the client moves to a newer ATT&CK version.
- Confirm with the client's auditor or assessor which evidence they need, since DeployOpen prepares evidence but does not issue attestations.
