MFA only stops an intruder if the second factor cannot be copied, and many factors in daily use can be. MITRE ATT&CK records the theft of one-time codes, smart card PINs and token values as T1111 Multi-Factor Authentication Interception in the Credential Access tactic (ATT&CK v20, platforms Windows, Linux and macOS). It sits beside T1621, where the adversary floods the user with prompts; here the adversary quietly captures or proxies the factor instead. This page is the technique reference in our ATT&CK series: what T1111 covers, which factors are exposed to which interception route, the v20 detection analytics, and the prevention and response steps that close the gap. It is written for identity engineers, SOC analysts and incident responders and contains no attack procedures. Prompt flooding is covered in the MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation guide and is not repeated here.
Key takeaways
- Interception targets copyable factors. One-time passwords, SMS and voice codes and token values can be captured and replayed; NIST SP 800-63B-4 states that OTP and out-of-band authenticators are not phishing-resistant.
- The endpoint is part of the authenticator. ATT&CK describes keyloggers capturing smart card PINs and token codes, then proxying authentication through the inserted card, so a compromised workstation defeats even hardware factors that are not bound to the session origin.
- The phone network is an attack surface. CISA lists SS7 weaknesses and SIM swap as threats to SMS and voice MFA and calls them a last resort; NIST classes PSTN out-of-band verification as restricted.
- Detection is mostly behavioural. The v20 detection strategy DET0246 looks for keyboard capture, keylogger drivers and smart card use without local interaction, so EDR and identity provider telemetry must be joined.
- The durable fix is origin-bound cryptography. FIDO2/WebAuthn and PKI-based authenticators bind the response to the relying party, which removes most of what T1111 can capture.
What T1111 covers in ATT&CK v20
ATT&CK describes adversaries targeting MFA mechanisms such as smart cards and token generators to gain credentials for systems and services. It names three broad routes: keylogging the PIN or password used with a smart card, then using the inserted card on the infected host to proxy authentication; capturing token codes (including the PIN prefix) for replay within the code's validity window, or to predict later values where seed material has also been stolen; and intercepting codes sent out of band by SMS or email, including by compromising the messaging service that delivers them.
| Attribute | ATT&CK v20 value | Defender implication |
|---|---|---|
| Technique | T1111 Multi-Factor Authentication Interception | No sub-techniques; scope spans endpoint, network and telecom routes |
| Tactic | Credential Access | Usually follows a password theft and precedes T1078 Valid Accounts |
| Platforms | Windows, Linux, macOS | The capture point is often the user's own workstation |
| Groups and campaigns recorded | APT42, Chimera, Kimsuky, LAPSUS$, Operation Wocao, Leviathan Australian Intrusions | State and financially motivated actors both use it |
| Mitigation mapped | M1017 User Training ("Remove smart cards when not in use") | The mapped mitigation is thin; the real controls are authenticator choice and endpoint hardening |
| Detection strategy | DET0246 Detection Strategy for MFA Interception via Input Capture and Smart Card Proxying | Analytics AN0687 (Windows), AN0688 (Linux), AN0689 (macOS) |
The procedure examples ATT&CK records show the range: APT42 intercepting SMS one-time passwords and using cloned sites to capture tokens, Chimera registering alternate phone numbers for compromised users to receive SMS codes, Kimsuky using a proprietary tool to intercept one-time passwords, and the Sykipot malware, which proxied authentication through detected smart cards.
Adjacent techniques
- T1557 Adversary-in-the-Middle: a reverse proxy relays the whole sign-in, code included, and keeps the session. See the MITRE ATT&CK T1557 Adversary-in-the-Middle and the AiTM Phishing Guide.
- T1056.001 Keylogging: the input capture that feeds smart card and token interception. See the MITRE ATT&CK T1056 Input Capture.
- T1539 Steal Web Session Cookie: skips the factor entirely by taking the post-MFA session. See the MITRE ATT&CK T1539 Steal Web Session Cookie.
- T1451 SIM Card Swap (ATT&CK for Mobile): moves the victim's number to an adversary SIM so SMS and voice codes arrive elsewhere. See the SIM Swap Fraud Guide.
Which factors are exposed to which route
The useful question for defenders is not "do we have MFA" but "which interception routes does each of our factors survive". The table below combines the CISA hierarchy of MFA strength with NIST SP 800-63B-4 classifications.
| Factor | Endpoint capture (keylogger, malware) | Telecom interception (SS7, SIM swap, number change) | Relay or replay by a proxy | Standards position |
|---|---|---|---|---|
| SMS or voice code | Exposed if typed on a compromised host | Exposed | Exposed | NIST: PSTN out-of-band is restricted; CISA: last resort |
| Email code or magic link | Exposed, and exposed again if the mailbox is compromised | Not applicable | Exposed | Not phishing-resistant |
| Authenticator app TOTP or hardware OTP token | Exposed (code and PIN prefix can be logged) | Not applicable | Exposed within the validity window | NIST: OTP is not phishing-resistant |
| Push with number matching | Limited (approval happens on the phone) | Not applicable | Exposed to a real-time proxy | CISA: resists push bombing, not phishing |
| Smart card or PIV with PIN | PIN exposed; card can be proxied while inserted on an infected host | Not applicable | Resistant where the protocol binds to the verifier | CISA: PKI-based MFA is phishing-resistant |
| FIDO2/WebAuthn security key or platform passkey | Use while the device is in the adversary's control remains possible; the credential cannot be copied off the authenticator | Not applicable | Resistant (origin-bound) | CISA: the only widely available phishing-resistant option |
Two lessons follow. First, even the strongest factor is only as trustworthy as the device it is used on: an adversary with code execution on the workstation can ride a live session or a card left in the reader, which is why ATT&CK's only mapped mitigation is to remove smart cards when not in use. Second, everything typed or received as a code can be relayed, so every OTP-class factor needs compensating controls until it is retired.
Detection
T1111 leaves few traces at the identity provider when it succeeds, because the adversary presents a correct code. Detection therefore has two halves: catching the capture on the endpoint, and catching the use of captured material at sign-in.
Endpoint analytics (ATT&CK v20 DET0246)
| Platform | Behaviour to watch | Log source in the analytic | Tuning element |
|---|---|---|---|
| Windows (AN0687) | Unexpected keyboard capture API calls, keylogger driver loads, or smart card authentication in logon sessions not started by local user interaction | Sysmon Event ID 10 (process access), 13 and 14 (registry); Security Event IDs 4624 and 4648 | Process exclusions for accessibility tools such as Magnifier; time window for co-occurrence |
| Linux (AN0688) | Access to /dev/input devices, kernel module loads, or input polling from non-user shells | Syscall auditing (open, read, ioctl on input devices); syslog or dmesg module loads | Allowed kernel module list; device paths in use |
| macOS (AN0689) | Processes requesting input monitoring or accessibility rights, polling HID services without user interaction, or changes to TCC settings | Unified log (com.apple.tccd, com.apple.securityd); osquery process and TCC database queries | Developer signing status; expected input monitoring apps |
Identity and telecom signals
- New phone number or MFA method: ATT&CK records Chimera registering alternate phone numbers to receive codes. Alert on any MFA method registration or phone change, especially one followed within hours by a sign-in from a new device.
- Correct code, wrong context: a successful OTP sign-in from an unfamiliar ASN, hosting provider or country while the user's managed device is active elsewhere.
- Carrier events: NIST SP 800-63B-4 section 3.1.3.3 tells verifiers using the PSTN to consider risk indicators such as device swap, SIM change and number porting. Where a carrier or messaging provider exposes these signals, feed them into sign-in risk.
- Smart card use without presence: Event ID 4648 (explicit credentials) or remote logons using a certificate-based credential while the workstation is locked or idle.
- Repeated OTP failures then success: NIST requires verifiers to limit consecutive failed attempts to no more than 100 per authenticator (section 3.2.2); bursts well below that limit still deserve an alert.
Metrics
- Percentage of privileged and remote access users on phishing-resistant authenticators (FIDO2 or PKI).
- Number of applications and users still allowed SMS or voice as a factor, with a dated retirement plan for each.
- Median time from an MFA method or phone number change alert to user verification.
- Percentage of smart card workstations with automatic lock on card removal and a removal policy enforced.
- EDR coverage of input capture detections (DET0246 equivalents) across Windows, macOS and Linux admin workstations.
Prevention and hardening
| Control | What it removes | Notes and sources |
|---|---|---|
| Phishing-resistant MFA (ATT&CK M1032) | Relay and replay of captured codes | CISA calls it the gold standard; NIST SP 800-63B-4 requires a phishing-resistant authenticator at AAL3 and that one be offered at AAL2 |
| Retire SMS and voice for workforce sign-in | SS7, SIM swap and number-change interception | NIST treats PSTN as restricted and requires an alternative authenticator to be available to every subscriber |
| Lock down MFA method changes | Adversary-registered phone numbers and authenticators | Require a phishing-resistant factor or verified help desk process to add or change a method; see the MFA Fatigue and Bypass Guide |
| Smart card hygiene (M1017) | Proxying through an inserted card | Card removal policy, lock on removal, and short PIN caching; see the Smart Card and PIV/CAC Authentication Guide |
| Hardened admin workstations | Keyloggers on the devices that hold privileged factors | Application control, EDR with input capture detection, no browsing or email on admin devices |
| Short validity and one-time use for codes | Replay window | Verifiers should reject a code already used; OTP rate limits per NIST section 3.2.2 |
| Token seed protection | Prediction of future token values | ATT&CK notes seed theft enables prediction; store seed files with the protection given to signing keys and reissue tokens if seeds are exposed |
Choosing a path by organisation size
- Small organisations: move administrators and finance staff to FIDO2 security keys or platform passkeys first, using what the email and SSO platform already supports, as CISA advises. Disable SMS as a fallback for those users.
- Large enterprises with PKI: smart cards remain a strong choice where the card is used with protocols that bind to the verifier; add card removal enforcement and keep FIDO2 for cloud services that do not accept certificates.
- Customer-facing services: SMS may stay for reach, but treat it as restricted in the NIST sense: offer passkeys, consider SIM change and porting signals before sending codes, and step up for sensitive actions.
Phased rollout
- Inventory factors: list every application, the factors it accepts and the fallback methods users can still pick. Fallbacks are where interception usually succeeds.
- Protect the highest-value users first: administrators, help desk staff, finance approvers and executives, in line with CISA's advice to prioritise high-value targets and critical resources such as email and identity servers.
- Pilot in report-only mode: apply an authentication strength or conditional access policy requiring phishing-resistant MFA in report-only or audit mode for a pilot group and review which sign-ins would fail.
- Enforce in rings: move ring by ring, removing SMS and voice from each ring once users have registered a stronger method. Keep a documented, time-limited exception process.
- Harden method management: require strong verification to register or reset factors, and alert on every change.
- Roll back safely: keep break-glass accounts with hardware keys stored offline so a failed enforcement can be reversed without reopening SMS for everyone.
Response runbook
- Confirm the route: was the code captured on the endpoint, received by a changed phone number, or relayed by a proxy site? The route decides the clean-up.
- Contain the identity: revoke sessions and refresh tokens, reset the password, remove any MFA methods or phone numbers the user did not add, and re-register factors on a trusted device.
- Contain the endpoint: isolate the workstation if input capture is suspected, collect volatile evidence, and reimage rather than clean. Treat every credential typed on that host as exposed.
- Check the carrier: where SMS was involved, confirm with the mobile operator whether a SIM change or port-out occurred and ask for an account lock.
- Hunt for spread: look for the same infrastructure, MFA method changes or new device registrations across other accounts within the same window.
- Close the class: move the affected user group to phishing-resistant MFA rather than only resetting the victim.
Where identity fits
T1111 is about human factors, but the same lesson applies to non-human identities: any secret that can be read in transit or typed on a compromised host can be replayed. Service accounts that use shared one-time codes or SMS-based recovery, and automation that stores token seeds alongside scripts, inherit the weakness. Give workloads cryptographic, non-exportable credentials and keep recovery paths for privileged human accounts on phishing-resistant factors. See the Phishing-Resistant MFA Guide.
Framework mapping
| Framework | Reference | Relevance to T1111 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2(1), IA-2(2) Multi-factor Authentication; IA-2(8) Access to Accounts, Replay Resistant | Require MFA and replay-resistant mechanisms |
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management; IA-5(2) Public Key-based Authentication | Method registration, changes and PKI-based factors |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring | Input capture and method change detection |
| NIST CSF 2.0 | PR.AA-03; DE.CM-03; DE.CM-09 | Authentication strength; monitoring of personnel activity and endpoints |
| NIST SP 800-63B-4 | Sections 2.2, 2.3, 3.1.3.3, 3.1.4, 3.2.2 | Phishing resistance by AAL, PSTN restriction, OTP limits, rate limiting |
| MITRE ATT&CK v20 | M1032 Multi-factor Authentication; M1017 User Training | Mitigations for the technique and its neighbours |
Common failure patterns
- Strong factor, weak fallback: users enrolled in FIDO2 can still choose SMS at the sign-in prompt, so the adversary simply asks for the weaker method.
- Unprotected method changes: a phone number can be changed with only a password, which is exactly the Chimera procedure ATT&CK records.
- Cards left in readers: smart cards stay inserted all day on workstations with no lock on removal, giving malware a live authenticator to proxy.
- Resetting the password only: responders reset the password but leave adversary-added MFA methods and refresh tokens in place.
- Admin work on general-purpose devices: privileged users read email and browse on the device where they type smart card PINs and OTP codes.
Practitioner checklist
- Map every application to the factors and fallbacks it accepts, and flag SMS, voice and email codes.
- Require phishing-resistant MFA for administrators, help desk staff and remote access first.
- Remove SMS and voice as fallbacks for users who hold a stronger factor.
- Require strong verification and alerting for every MFA method and phone number change.
- Enforce lock on smart card removal and train users to remove cards when away.
- Deploy endpoint detections for keyboard capture, keylogger drivers and input monitoring on Windows, Linux and macOS.
- Correlate successful OTP sign-ins with device and network context in the SIEM.
- Include factor removal, session revocation and carrier checks in the account compromise runbook.
Standards and references
- MITRE ATT&CK: Multi-Factor Authentication Interception (T1111)
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- CISA: Implementing Phishing-Resistant MFA
- MITRE ATT&CK: Multi-Factor Authentication Request Generation (T1621)
- MITRE ATT&CK: Input Capture, Keylogging (T1056.001)
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation · Phishing-Resistant MFA Guide · SIM Swap Fraud Guide · Keyloggers Guide · MFA Adoption Statistics