Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0160: Detection Strategy for Multi-Factor Authentication Request Generation (T1621)

DET0160 is a detection strategy tied to ATT&CK technique T1621, Multi-Factor Authentication Request Generation. Its business significance is that MFA can b...

EnterpriseDET0160Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0160 is a detection strategy tied to ATT&CK technique T1621, Multi-Factor Authentication Request Generation. Its business significance is that MFA can become an operational decision point during account takeover: an attacker with valid credentials may still be blocked, but repeated or suspicious MFA prompts can pressure users and create identity-driven incident risk. Leaders should treat this as an identity security and SOC readiness issue, not only an MFA configuration issue.

Executive priority

Prioritize this where workforce, administrator, or cloud/IaaS access depends on MFA. The key executive question is whether the organization can prove, during an incident or audit, that it can see abnormal MFA request activity, correlate it to account sign-in attempts, and respond before access is granted. This supports business continuity, incident decision-making, identity control assurance, and compliance evidence around access protection.

Technical view

The ATT&CK object itself has no official detection text and no platforms or tactics specified, but it detects T1621, which is under credential access and applies to Windows, Linux, macOS, and IaaS in the related technique context. SOC and detection teams should validate coverage around MFA challenge generation, authentication attempts using valid accounts, MFA approval/denial outcomes, and follow-on session creation. Detection logic should focus on identity-event correlation rather than isolated MFA events.

Likely telemetry

  • Identity provider sign-in and authentication logs
  • MFA challenge generation, approval, denial, timeout, and user-reported suspicious prompt events
  • Account, user, device, source IP, geolocation, and session metadata tied to MFA attempts
  • Cloud/IaaS control-plane authentication and session logs where MFA protects access
  • Endpoint or operating system logon evidence for Windows, Linux, and macOS when correlated with protected account access

Detection direction

  • Validate that MFA request events are collected with enough detail to link the request to the account, source, device, application, and final authentication result.
  • Look for repeated MFA prompts, unusual request timing, unexpected source context, or MFA requests followed by successful session creation.
  • Correlate MFA prompts with prior credential use because T1621 assumes adversaries may already possess valid credentials.
  • Tune for expected user behavior such as legitimate retries, travel, device changes, or application reauthentication to reduce false positives.
  • Check blind spots in third-party identity providers, cloud/IaaS tenants, privileged accounts, and logs that record sign-ins but not MFA challenge outcomes.

Mitigation priorities

  • First, confirm MFA is consistently enforced for accounts and access paths where the related T1621 behavior is relevant, especially privileged and cloud/IaaS access.
  • Second, ensure identity logging retains MFA request and outcome details long enough for investigation and compliance evidence.
  • Third, define SOC triage and incident response actions for suspicious MFA prompt activity, including account containment and user verification.
  • Fourth, review identity policy and user reporting workflows so suspicious MFA prompts are escalated quickly rather than treated as routine authentication noise.
Analyst notes and limits

This take is relationship-driven. The detection strategy object has no official description or detection content, so practical guidance is derived from its stated relationship to T1621 and the supplied T1621 summary. The most important validation question is whether the organization can connect MFA prompt activity to credential use and resulting access decisions.

ATT&CK fields supplied for DET0160 are sparse: platforms, tactics, official description, and official detection are not specified. Platform and tactic context comes only from the related T1621 technique. Local identity architecture, MFA provider logging, retention, and policy configuration are required to determine actual coverage.

Official MITRE ATT&CK definition

Detection Strategy for Multi-Factor Authentication Request Generation (T1621)

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1621 Multi-Factor Authentication Request Generation This object detects Multi-Factor Authentication Request Generation.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
0994a5051eebef7e...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 0994a5051eeb…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0160
    Open source URL
Source and licensing

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.