T1111: Multi-Factor Authentication Interception
Adversaries may target multi-factor authentication (MFA) mechanisms, (i.e., smart cards, token generators, etc.) to gain access to credentials that can be used to access systems, services, and network resources. Use of MFA is recommended and provides a higher level of security than usernames and passwords alone, but organizations should be aware of techniques that could be used to intercept and bypass these security mechanisms.
If a smart card is used for multi-factor authentication, then a keylogger will need to be used to obtain the password associated with a smart card during normal use. With both an inserted card and access to the smart card password, an adversary can connect to a network resource using the infected system to proxy the authentication with the inserted hardware token. [1]
Adversaries may also employ a keylogger to similarly target other hardware tokens, such as RSA SecurID. Capturing token input (including a user's personal identification code) may provide temporary access (i.e. replay the one-time passcode until the next value rollover) as well as possibly enabling adversaries to reliably predict future authentication values (given access to both the algorithm and any seed values used to generate appended temporary codes). [2]
Other methods of MFA may be intercepted and used by an adversary to authenticate. It is common for one-time codes to be sent via out-of-band communications (email, SMS). If the device and/or service is not secured, then it may be vulnerable to interception. Service providers can also be targeted: for example, an adversary may compromise an SMS messaging service in order to steal MFA codes sent to users’ phones.[3]
Analyst context for executives and security teams
MFA interception matters because it targets the control many organizations rely on after passwords fail. In this technique, an adversary may capture MFA-related inputs, abuse inserted smart cards or hardware tokens, or intercept one-time codes delivered through channels such as email or SMS. The business risk is not that MFA is ineffective, but that MFA coverage can be weakened if endpoints, token workflows, identity providers, or out-of-band delivery services are not monitored and secured.
Executive priority
Treat this as an identity resilience and incident-readiness issue. Leaders should ask whether MFA evidence is actually logged, whether high-risk authentication events can be investigated quickly, and whether users know how to report suspicious MFA prompts or code requests. Because ATT&CK links this technique to multiple groups, campaigns, and software, including smart-card hijacking, credential logging, reverse-proxy interception, and bypass of two-factor flows, it should influence identity security testing, SOC coverage validation, and audit evidence for privileged and remote access controls.
Technical view
For Linux, macOS, and Windows environments, validate visibility around credential-access behavior that could capture MFA input or proxy authentication through an already-authenticated endpoint. ATT&CK does not provide official detection text for T1111, but the related DET0246 strategy indicates a focus on MFA interception via input capture and smart-card proxying. SOC and IR teams should correlate endpoint telemetry with identity-provider, VPN, smart-card/token, email, SMS, and session logs to distinguish normal MFA use from suspicious capture, replay, or proxy-style authentication patterns.
Likely telemetry
- Endpoint security telemetry from Linux, macOS, and Windows systems used for MFA or privileged access
- Process, driver, input-capture, browser, and credential-access related events where available
- Smart card, hardware token, and authentication middleware logs
- Identity provider authentication logs, including MFA challenge, success, failure, enrollment, and session events
- VPN, remote access, and network resource authentication logs
Detection direction
- Start by confirming whether DET0246-style coverage exists for input capture and smart-card proxying rather than assuming MFA events alone are sufficient.
- Correlate MFA successes with endpoint state, user location/context, session creation, and downstream access to sensitive systems.
- Tune for suspicious combinations: MFA entry on an endpoint with credential-access indicators, unusual authentication through an infected or unmanaged host, or one-time-code use followed by abnormal access.
- Review blind spots around SMS/email MFA delivery, unmanaged user devices, token middleware, browser sessions, and identity-provider logs retained for too short a period.
- Account for false positives from legitimate remote support, accessibility tools, authentication middleware, browser extensions, and normal help-desk MFA recovery activity.
Mitigation priorities
- Use the related M1017 User Training mitigation to ensure users can recognize and report suspicious MFA prompts, code requests, and social-engineering attempts.
- Prioritize securing endpoints that handle smart cards, hardware tokens, or privileged authentication because endpoint compromise can undermine MFA workflows.
- Harden and monitor out-of-band MFA delivery paths such as email and SMS services, since the ATT&CK description notes that insecure devices or services can expose one-time codes.
- Validate identity and remote-access logging before an incident so investigators can reconstruct MFA challenges, sessions, and resource access.
- Apply stronger controls first to privileged users, remote access, and systems where credential theft would create major operational or compliance impact.
Analyst notes and limits
The object is a credential-access technique, not a statement that MFA should be avoided. The defensive lesson is to verify how MFA can be intercepted in local workflows and whether SOC, identity, and IR teams can see enough evidence to respond. Relationship context shows use by several ATT&CK groups/campaigns and software entries, but those relationships should guide threat modeling rather than be treated as proof of current activity in any specific environment.
MITRE does not provide official detection content for this object. The supplied fields do not establish active exploitation against any organization, guaranteed detection logic, or a complete mitigation set beyond User Training. Local architecture, MFA method, identity-provider logging, endpoint visibility, and out-of-band service controls are required to assess real exposure.
Multi-Factor Authentication Interception
Adversaries may target multi-factor authentication (MFA) mechanisms, (i.e., smart cards, token generators, etc.) to gain access to credentials that can be used to access systems, services, and network resources. Use of MFA is recommended and provides a higher level of security than usernames and passwords alone, but organizations should be aware of techniques that could be used to intercept and bypass these security mechanisms.
If a smart card is used for multi-factor authentication, then a keylogger will need to be used to obtain the password associated with a smart card during normal use. With both an inserted card and access to the smart card password, an adversary can connect to a network resource using the infected system to proxy the authentication with the inserted hardware token. [1]
Adversaries may also employ a keylogger to similarly target other hardware tokens, such as RSA SecurID. Capturing token input (including a user's personal identification code) may provide temporary access (i.e. replay the one-time passcode until the next value rollover) as well as possibly enabling adversaries to reliably predict future authentication values (given access to both the algorithm and any seed values used to generate appended temporary codes). [2]
Other methods of MFA may be intercepted and used by an adversary to authenticate. It is common for one-time codes to be sent via out-of-band communications (email, SMS). If the device and/or service is not secured, then it may be vulnerable to interception. Service providers can also be targeted: for example, an adversary may compromise an SMS messaging service in order to steal MFA codes sent to users’ phones.[3]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
G0094: Kimsuky
Kimsuky is a Democratic People's Republic of Korea (DPRK)-based cyber espionage group that has been active since at least 2012. The group initially targeted South Korean government agencies, think tanks, and subject-matter experts in various fields. Its operations expanded to include the United Nations and organizations in the government, education, business services, and manufacturing sectors across the United States, Japan, Russia, and Europe. Kimsuky has focused collection on foreign policy and national security issues tied to the Korean Peninsula, nuclear policy, and sanctions. Kimsuky operations have overlapped with those of other North Korean state-sponsored cyber espionage actors as a result of ad hoc collaborations or other limited resource sharing.[1][2][3][4][5][6]
Kimsuky was assessed to be responsible for the 2014 Korea Hydro & Nuclear Power Co. compromise; other notable campaigns include Operation STOLEN PENCIL (2018), Operation Kabar Cobra (2019), and Operation Smoke Screen (2019).[7][8][9] In 2023, Kimsuky was observed using commercial large language models (LLMs) to assist with vulnerability research, scripting, social engineering and reconnaissance.[10]
DPRK threat actor cluster boundaries overlap in open source reporting, with some security researchers consolidating all attributed North Korean state-sponsored cyber activity under Lazarus Group, rather than tracking operationally distinct subgroups.
G0114: Chimera
G1044: APT42
APT42 is an Iranian-sponsored threat group that conducts cyber espionage and surveillance.[1] The group primarily focuses on targets in the Middle East region, but has targeted a variety of industries and countries since at least 2015.[1] APT42 starts cyber operations through spearphishing emails and/or the PINEFLOWER Android malware, then monitors and collects information from the compromised systems and devices.[1] Finally, APT42 exfiltrates data using native features and open-source tools.[2]
APT42 activities have been linked to Magic Hound by other commercial vendors. While there are behavior and software overlaps between Magic Hound and APT42, they appear to be distinct entities and are tracked as separate entities by their originating vendor.
G1004: LAPSUS$
LAPSUS$ is cyber criminal threat group that has been active since at least mid-2021. LAPSUS$ specializes in large-scale social engineering and extortion operations, including destructive attacks without the use of ransomware. The group has targeted organizations globally, including in the government, manufacturing, higher education, energy, healthcare, technology, telecommunications, and media sectors.[1][2][3]
S1104: SLOWPULSE
S0018: Sykipot
S9003: evilginx2
C0014: Operation Wocao
Operation Wocao was a cyber espionage campaign that targeted organizations around the world, including in Brazil, China, France, Germany, Italy, Mexico, Portugal, Spain, the United Kingdom, and the United States. The suspected China-based actors compromised government organizations and managed service providers, as well as aviation, construction, energy, finance, health care, insurance, offshore engineering, software development, and transportation companies.[1]
Security researchers assessed the Operation Wocao actors used similar TTPs and tools as APT20, suggesting a possible overlap. Operation Wocao was named after an observed command line entry by one of the threat actors, possibly out of frustration from losing webshell access.[1]
C0049: Leviathan Australian Intrusions
Leviathan Australian Intrusions consisted of at least two long-term intrusions against victims in Australia by Leviathan, relying on similar tradecraft such as external service exploitation followed by extensive credential capture and re-use to enable privilege escalation and lateral movement. Leviathan Australian Intrusions were focused on exfiltrating sensitive data including valid credentials for the victim organizations.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.1 | Current bundle | 170612596642… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Mandiant M Trends 2011
Mandiant. (2011, January 27). Mandiant M-Trends 2011. Retrieved January 10, 2016.
Open source URL -
[2]
GCN RSA June 2011
Jackson, William. (2011, June 7). RSA confirms its tokens used in Lockheed hack. Retrieved November 17, 2024.
Open source URL -
[3]
Okta Scatter Swine 2022
Okta. (2022, August 25). Detecting Scatter Swine: Insights into a Relentless Phishing Campaign. Retrieved February 24, 2023.
Open source URL -
[4]
mitre-attack T1111Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.