How T1621 MFA request generation shows up in your identity logs
When a burst of unexpected MFA prompts lands on users, the SOC lead's first question is whether the account is under attack or whether a legitimate app is misbehaving. T1621 Multi-factor authentication request generation is the technique that explains this pattern. An adversary who already holds a valid password does not need the user's second factor. Instead, they trigger the MFA challenge repeatedly against the account, hoping the user approves a prompt out of fatigue, confusion or a wish to make the noise stop. In ATT&CK, the technique sits under the Credential Access tactic (TA0006), whose stated goal is to steal account names and passwords, because a successful prompt approval turns a stolen password into a working session.
The technique shows up most often against cloud identity providers and remote access gateways, where a password is the entry point and MFA is the main barrier left. The first decision for the SOC is to confirm whether the prompts came from your own sign-in flows, such as a user testing a new device or a mobile client retrying, or from a source that no user initiated. Identity provider sign-in logs, which carry User Account Authentication data, should show the source IP, the application, the result of each challenge and whether the password succeeded before the prompts began. Application log content and logon session metadata help tie those events to a session. A repeated pattern of failed or unanswered challenges, following a successful password check from an unfamiliar location, is the signal to escalate.
This page maps the technique to ATT&CK Enterprise 20.0. Technique details, detection strategies and data component references can change between ATT&CK releases, so confirm the version your detections target before you tune them, and record it in your rule metadata. Check the current technique page at the MITRE ATT&CK tactic page for Credential Access and the ATT&CK updates page when a new version ships. Ask your identity provider vendor which MFA events and fields are logged and how long they are retained, because the detection depends on those fields existing in your environment.
Which telemetry reveals MFA request generation and which open-source tool collects it
This table compares the telemetry sources that can reveal T1621 activity, the signal to look for in each, the platforms it covers and the open-source collector that typically ingests it. Use it to decide where to start: User Account Authentication is the primary signal, while identity provider logs and host session context add confirmation. Confirm the data component mappings against the enterprise-attack 20.0 bundle before you build detections.
| Telemetry source | Signal to look for | Platforms covered | Open-source collector |
|---|---|---|---|
| User Account Authentication (DC0002), primary | Bursts of push or prompt verification events for one account that the user did not initiate, often repeated over a short window and followed by a success or a silent timeout | Windows, Linux, macOS, IaaS and other platforms where authentication events reach a log source | Wazuh agents for host authentication logs, forwarded to the Wazuh manager for correlation |
| Application Log Content (DC0038), identity provider and SSO | Repeated MFA challenge events from the identity provider or SSO gateway, with source IP, device, and user agent changes between challenges | Identity Provider, SaaS and IaaS platforms that emit sign-in and MFA logs | Wazuh log collection for exported identity provider logs, or Zeek and Security Onion ingestion of identity log streams where they are available |
| Logon Session Metadata, host-side context | Interactive or network logons that coincide with MFA prompt bursts, showing unusual logon types, session origin or timing | Windows and Linux hosts with session logging enabled; macOS where unified logging is forwarded | Wazuh agents on endpoints, with Velociraptor available for pulling session records during investigation |
| Network Traffic Content (DC0085), supporting | Outbound sign-in or verification requests to identity endpoints from hosts or addresses that do not normally authenticate to them | Network segments where identity traffic is visible, including cloud egress points | Suricata or Zeek sensors within Security Onion, where TLS metadata to identity endpoints is captured |
| Confirmation step, enterprise-attack 20.0 | Check that each data component named here is still mapped to T1621 and its detection strategies in the targeted ATT&CK version | All platforms in scope | Open-source STIX tooling against the enterprise-attack 20.0 bundle, recorded alongside each rule |
Detection logic for MFA prompt bursts and unusual approval patterns
The ideas below all watch the same identity telemetry from different angles: how many MFA challenges a user receives, where they come from, what preceded them, and what follows them. Each threshold is a parameter you set from your own sign-in baseline, and each detection needs a documented list of benign causes so analysts can clear them quickly.
High challenge volume per user
Count MFA challenges issued to each account within a rolling window and alert when the count exceeds that account's own historical range. The window length, the count threshold and the baseline period are parameters you set from your environment, not fixed values. Compare against peer groups for service accounts and shared roles, which behave differently from interactive users. Benign causes include help desk resets, a user re-enrolling a device, and a sign-in loop caused by a misconfigured application, so record those reasons in the alert so triage can separate them from repeated prompts a user never initiated.
Challenges from unfamiliar origins
Flag MFA challenges whose source country, autonomous system, client application or user agent has not appeared for that account in your baseline period. Set the lookback length and the allowed novelty rules from your own data. Travel, VPN exit changes and corporate proxy migrations will raise false positives, so check whether the origin matches a known travel record or an approved network change before escalating. Correlate the origin with the identity provider's risk signals where available, and confirm in your identity platform's documentation which fields it exposes for each sign-in event.
Challenges after failed password attempts
Look for a sequence in which several failed password attempts against an account are followed by an MFA challenge, since an adversary who already holds a valid password may trigger prompts to test whether the victim will approve. Define the failure count and the time gap between failures and the challenge from your baseline. Typical benign sources include a user who mistyped a password several times after a password expiry, and a password change that left a cached credential in a mobile client. Sequence rules of this kind are easier to tune when they share one correlation key, such as the account and the source address.
Prompt followed by new device sign-in
Alert when an MFA challenge is followed within a short interval by a successful sign-in from a device or client that has no prior record for the account. The interval, the device identifier fields you trust and the allowed grace period are all parameters to set locally. Legitimate causes include new phone enrollment, a laptop replacement and a user approving a prompt on a second browser, so require the device to be unknown in both the identity provider and your endpoint inventory before raising the severity.
Unusual approval timing and shift changes
Compare the hour and day of MFA approvals against each user's working pattern, and alert when approvals cluster outside it. Shift schedules, on-call rotations, time zone moves and holiday coverage all create legitimate off-hours approvals, so pull these from your HR or scheduling source before tuning. Record which approvals were answered on the first prompt and which needed several attempts, because a prompt that was ignored repeatedly and then accepted is a pattern worth reviewing with the user. Confirm with the identity platform which timestamps it logs for challenges and for approvals, since the two may differ.
How to confirm the detection fires before you trust it
This sequence proves that the T1621 detection produces the expected events, rule matches and alerts in a controlled lab or cyber range, so the team knows what the detection catches, what it misses and what to tune before relying on it in production.
Agree scope and authorization in writing
The security lead, the identity platform owner and the cyber range operator agree in writing which test tenant, test accounts and MFA methods are in scope, who may run the exercise, when it runs and how it is stopped. The rules of engagement also name the people who must be told before any alert is escalated, so the exercise does not trigger a live incident response. The step is done when every party has signed off on the document and the test tenant is confirmed as isolated from production identities.
Map the expected log events and timing
Before any challenge is sent, the detection engineer writes down which events should appear for each MFA request, using the User Account Authentication and Application Log Content data components referenced for this technique in the ATT&CK version you target. The expected timing is recorded as well, including how long you expect between the challenge, the event being shipped to the SIEM and the rule evaluating it. Confirm these fields against your identity provider's documentation and your Wazuh, Security Onion or other pipeline configuration. The step closes with a reviewed table that the operators can check against during the run.
Confirm log collection on the test tenant
The platform engineer verifies that the identity provider's authentication and MFA audit logs reach the collector, parse correctly and carry the fields your rules depend on, such as user, result, MFA method and source address. Test one benign sign-in on a test account and check that the event arrives with the expected fields in the SIEM. The step is complete when the sample event is visible end to end and any missing or renamed fields are logged as known gaps.
Run a controlled series of MFA challenges
Operators work from the agreed plan to generate a fixed set of MFA challenges against the test accounts, varying the timing, the account and the outcome in ways the plan specifies. The exercise is run by the cyber range team under observation, and every challenge is logged with its start time, account, and intended outcome so it can be matched to telemetry later. The exact techniques used to trigger the challenges are kept in the operator's controlled runbook rather than this page. The step is done when the planned series is finished and the run log is complete.
Record events, rule IDs and alert timestamps
An analyst exports the events from the collector for the run window and records, per challenge, whether the expected events appeared, which detection rule or analytic IDs matched, and the timestamp of each resulting alert. Differences from the mapped expectations, such as missing events, late arrival or alerts that fired on the wrong account, are written down with the evidence attached. The output is a results sheet that links each planned challenge to its telemetry and alert, which becomes the baseline for later reruns.
Compare results against the targeted ATT&CK version
The detection engineer checks that each rule and analytic in the results sheet still maps to the ATT&CK technique and data components for the version the detection targets, using the STIX bundle for that version. If MITRE has renamed, deprecated or revoked any relevant object in a newer release, the mapping is updated and the change is recorded. Confirm the current version and its release notes on the MITRE ATT&CK updates page before closing the comparison, since mappings should name the version they were written against.
Document gaps and tune the detection
The team turns each gap from the results sheet into a tracked item with an owner, covering missing telemetry, noisy matches, late alerts and coverage that the exercise did not test. Tuning changes are made in a separate change record, then the same challenge series is rerun in the test tenant to confirm the fix. The step is complete when the gap register is reviewed by the security lead and the rerun results are attached, so the detection is trusted on evidence rather than on the first successful alert.
Why MFA prompt volume alone is not enough
A single push prompt is normal, so a count of prompts on its own cannot tell a confused user from a forced session. Users dismiss stray prompts, re-authenticate after a password change, or approve a request from a phone they did not expect. A detection for T1621 Multi-factor authentication request generation should therefore score a sequence of events: how many challenges were issued to one account, how quickly they arrived, from which source address, device or client, and what the user did with each one. Denied or unanswered challenges that cluster within a short window, especially after a failed password attempt, carry far more meaning than the same number spread over a working day. Teams should agree on these thresholds with their identity owners before any alert is tuned, and should record the baseline for each identity population they monitor.
The outcome of each challenge matters as much as the challenge itself. In a Wazuh or Security Onion deployment, the identity provider's sign-in and MFA events, normally collected through User Account Authentication telemetry, should be correlated with endpoint session data for the same account and time window. A user who is confused by prompts usually shows a recognizable pattern: a few denials, a device that is online and in use, and a successful sign-in from a familiar location. A forced session tends to show challenges that arrive while the user is not at the keyboard, sign-ins from unfamiliar sources, and logon sessions on endpoints the user did not start. Mapping these fields to a common account identifier is the step that most often fails in practice, so confirm the field names your identity provider emits and the normalization your pipeline applies before relying on the correlation.
Decisions to make before go-live include who receives the alert, what automated containment is acceptable, and how the security team will confirm with the user without relying on the channel that may be compromised. Record these in the detection's runbook and rehearse them in a private cyber range, where prompt bursts can be generated against test accounts that have no production exposure. Confirm with your identity provider vendor which MFA events are logged, how long they are retained, and whether challenge outcomes are exposed at a granularity your rules can use. The ATT&CK mitigations User Training and Multi-factor Authentication address the human and control sides of this risk, and the detection is only as useful as the user reporting and number-matching controls behind it.
Preventive controls: User Training (M1017) and Multi-factor Authentication
T1621 depends on a user approving a prompt they did not start, so the two preventive levers are the person who taps approve and the design of the prompt itself. The cards below cover what to teach users, how to measure that teaching, and which MFA design choices make prompt flooding and fatigue harder to exploit.
Train users to report unexpected prompts
Users should be taught that an MFA prompt for a login they did not start is a security event, not an annoyance. The training should give a simple reporting path, such as a button, a help desk number or a security mailbox, and should say what happens next. Include illustrative scenarios where prompts arrive late at night or repeatedly after a password change. Confirm with your security team that reports reach an analyst who can correlate them with sign-in logs within a defined window.
Train users to deny, not approve
The most important user action is denying an unexpected prompt, not ignoring it. Training should cover the difference between a prompt triggered by the user's own sign-in and one that appears without any action on their side, and should explain that repeated prompts are a reason to deny and report, not to approve and move on. Refresh this content with short, scenario-based exercises rather than a single annual slide deck, and check whether your identity platform records denied prompts so the signal is visible to defenders.
Measure training with report and deny rates
User Training is only a control if you can measure it. Track how many unexpected prompts are reported, how many are denied rather than approved, and how long reports take to reach an analyst. Compare these figures across teams over time, and use the results to target coaching. Ask your training provider whether the platform can report on these outcomes, or whether you need to pull them from identity logs yourself.
Prefer number matching for push prompts
Number matching requires the user to type a number shown on the sign-in screen into the authenticator app, so an approval cannot be granted by a reflexive tap on a prompt sent by an attacker. Confirm whether your identity platform enables number matching by default, applies it to all push methods, and covers both consumer-style and enterprise sign-in flows. Verify the setting in a test tenant before rolling it out, because some legacy clients may not support it.
Limit prompt volume with rate controls
Prompt flooding works by sending many requests until a user approves one out of fatigue. Ask your identity platform whether it throttles MFA requests per account, blocks further prompts after repeated denials, and alerts on bursts of prompts for one user. Set thresholds with your SOC so that a burst triggers a lock or review instead of a silent retry. Test these limits in your cyber range before relying on them.
Adopt phishing-resistant methods where possible
Methods based on public key cryptography and bound to the device or origin, such as hardware security keys and platform authenticators, remove the push prompt entirely for the users who adopt them. Identify which accounts need this first, such as administrators and users with access to payment or patient data. Confirm which phishing-resistant options your identity platform supports for each application, and plan a fallback process for lost or broken devices that does not reintroduce push prompts.
Triage and response when an MFA request alert fires
Start by confirming the alert against the raw identity events before anyone touches the account. For T1621, the signal is a burst of push, prompt or one-time-passcode challenges sent to one user over a short window, usually following a successful password check from an unfamiliar source. Pull the User Account Authentication records for that identity and compare the challenge timestamps, the requesting application, the source address and the factor type. Confirm the pattern is not an expected cause such as a user retrying a slow login from a known device. Record the alert ID, the query used and the time window so the triage can be repeated later.
Next, contact the user through a channel that the attacker could not have reached, such as a phone number already on file in the identity provider or a known manager, not a number or message supplied in the alert or the login page. Ask whether they initiated any sign-in and whether they approved a prompt they did not expect. Then search for successful sign-ins that followed the challenges, because a user who approved a prompt out of fatigue is the most common path to a valid session. Review the session, device and enrollment records for the window, including new device registrations, new factors added, and sign-ins from unusual locations or user agents. The Application Log Content for the identity provider and the connected applications should show which services accepted those sessions.
Decide on containment from that evidence, and default to the more reversible action if the picture is incomplete. Revoke active sessions and refresh tokens first, then reset the password if any factor or credential may have been exposed, and re-enroll factors if a device or number was added without the user's knowledge. Preserve the exported logs, session records and enrollment history before making changes, and hash the exports under your evidence procedure. Escalate to incident response when a challenge was approved and followed by sign-ins to privileged or sensitive applications, when several accounts show the same pattern, when factor enrollment changed during the window, or when the source correlates with other suspicious activity. Confirm your escalation thresholds and retention periods for these logs with your own incident response plan and your identity provider's documentation.
Rehearsing T1621 detection in a private cyber range
The range should mirror your production identity path closely enough that the telemetry is comparable, but it must be isolated from real users and real tenants. Build a segmented identity test tenant that uses the same MFA methods your organization enforces, with synthetic users who hold test factors that can be enrolled, challenged and reset without touching production accounts. Place a few endpoints in the range that generate the sign-in events your detections depend on, and forward their logs to a Wazuh or Security Onion stack so the team practices on the same tooling it uses day to day.
- Segmented identity tenant: Keep the test tenant network-separated and use a naming convention that makes every synthetic account obvious in logs.
- Synthetic users with test factors: Create several accounts with different enrollment states so you can test both enrolled and unenrolled paths.
- Endpoints and log forwarding: Confirm that authentication events from the identity provider and endpoints reach the SIEM with the fields your detection logic needs.
- Open-source stack: Wazuh or Security Onion should hold the rules and dashboards you plan to test, with versions recorded for the exercise.
- Change control: Document who may alter the range, and reset it to a known baseline before each run.
Before the first run, check with your identity platform vendor which MFA request events it logs, at what detail, and whether those logs can be exported to your stack without extra licensing.
An inject is a scripted event the exercise team introduces to see how the controls react. For T1621, the sequence should be written down in advance, with an expected signal for each step and an owner who starts it. Use illustrative sequences such as a burst of push challenges against one synthetic account, followed by a help desk call from a caller claiming to be that user, and then a benign travel prompt from a legitimate test user. Each inject should be described in words and run by hand or through a pre-approved script maintained by the exercise team.
- MFA challenge burst: Trigger a series of unsolicited-looking approval requests against one synthetic account over a short window, and record when each request appears in the logs.
- Help desk call: Have a facilitator phone the help desk as an unverified caller asking for a factor reset, so the team tests its identity verification script.
- Benign travel prompt: Generate a legitimate sign-in from an unusual location for a test user, so analysts learn how to separate expected anomalies from suspicious ones.
- Inject log: Keep a timed record of every inject, its expected detection, and the people who executed it.
- Stop conditions: Define in advance when the exercise pauses, such as any impact on a non-range system.
After each run, compare the inject log with the alerts raised to see which steps produced signal and which passed silently.
Good detection for T1621 shows up as an alert that names the account, the burst pattern, and the time window, and that reaches an analyst before the synthetic user's session is established or the factor is reset. Measure time to alert from the first inject to the first analyst acknowledgement, and record it per inject rather than as one average. Response should then hand off cleanly: the analyst confirms the pattern, opens a case, and passes the account to the identity team, who verify the user through an out-of-band channel, review recent factor changes and decide whether to reset or revoke sessions.
- Time to alert: Record the interval between each inject and its alert, and set a target with your own stakeholders rather than copying a figure from elsewhere.
- Analyst triage: Check that the alert contains enough context, such as source, device, and prior enrollments, to decide quickly.
- Identity team handoff: Confirm the case reaches the identity team with a clear request, such as verifying the user or reviewing factor enrollment history.
- Help desk outcome: Score whether the help desk followed its verification steps and escalated the unverified call.
- Benign prompt handling: Check that the travel prompt was closed as expected without unnecessary lockout.
After the exercise, ask your identity platform team which MFA request events were missing or delayed, and confirm those gaps before changing any rule.
Questions SOC leads and detection engineers ask about T1621
How do you tell MFA fatigue from a legitimate user retrying a login?
Look at the pattern, not a single prompt. A legitimate user usually produces a small number of denied or timed-out prompts followed by one approval from a known device and location. MFA request generation tends to produce a burst of prompts for one account over a short window, often at unusual hours, from an unfamiliar source, and frequently with no approval at all or a sudden approval after many denials. Build your logic around the count of requests per account per time window, the ratio of denials to approvals, and whether the source matches the user's recent baseline. Tune thresholds in your own environment, because normal help desk activity and shift changes can look similar at first. Route high-confidence bursts to an analyst who can contact the user through a verified channel.
Which logs should we retain for MFA investigations, and for how long?
Retain the identity provider's authentication and MFA events, the VPN or SSO application logs that trigger the challenge, and the endpoint or mobile signals that show which device or session was involved. The fields that matter most are the account, the factor type, the result, the source address, the device identifier, the application being accessed and a correlation ID that links the challenge to the session. Retention length is set by your legal, regulatory and internal policy, so confirm it with your compliance lead rather than copying a number from a blog post. Check that logs are shipped to your SIEM before the native platform rotates them, and test that a full investigation can be reconstructed from the stored data alone.
How can we test detection rules without sending real MFA prompts to users?
Test against replayed or synthetic events rather than live prompts. Export representative authentication events from a non-production identity tenant or from a private cyber range, then replay them through your SIEM rule pipeline and confirm which events fire. Label every synthetic event with a clear test marker so it can be excluded from production alerting. Where you must generate prompts in a test tenant, use dedicated test accounts, notify the security operations team in advance and make sure no production user is enrolled in the test flow. Record the expected outcome for each test case so that a later tuning change can be checked against the same set.
How often should we re-validate T1621 mappings when MITRE ATT&CK changes?
Re-validate whenever a new ATT&CK version is released and after any change to your identity platform, because releases can rename, deprecate or revoke techniques and can change detection guidance. Name the ATT&CK version in every detection record so you know which mapping it was built against. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and updated data components, so older rule documentation may need restructuring. Check the MITRE ATT&CK updates pages at each release, compare the technique and data component references against your rules, and rerun your replay test set. Track the result as a dated change record so auditors can see when mappings were reviewed.
Can Sigma rules express MFA request generation patterns across different identity sources?
Sigma can express the core logic, such as a count of challenge events per account over a time window with a filter on the result field, but the portability depends on how each identity source normalizes its logs. Map each source's field names to a common schema in your pipeline, then write the rule against the normalized fields. Some burst or baseline logic needs aggregation features that not every Sigma backend supports, so validate the compiled query on your actual SIEM before relying on it. Keep source-specific conversions in version control with the Sigma rule, and document which identity platforms each rule has been tested against.
Does user training and MFA configuration reduce the risk of request generation?
They reduce the risk, but they do not replace detection. ATT&CK maps User Training and Multi-factor Authentication as mitigations for this technique. Training helps users recognize unexpected prompts and report them rather than approve them. Stronger factor choices, such as number matching or phishing-resistant methods where your platform supports them, make a blind approval less likely. Confirm with your identity provider which options are available in your tenant and which factors your users can enroll. Pair these controls with monitoring, because a prompt flood can still reach users before a training message or configuration change takes effect.
How do we rehearse T1621 detection and response in a private cyber range?
Build a range that mirrors your identity flow with test accounts, a test MFA tenant or simulated identity service, and your production SIEM rules pointed at range logs. Script a scenario in which a test account receives a burst of challenges from an unfamiliar source, then measure whether the alert fires, who receives it and whether the analyst's runbook leads to a verified contact with the account owner. Repeat the exercise after each rule change. Record gaps, such as missing source fields or slow log shipping, and assign owners to fix them. Scope the range and its data handling in writing before the exercise starts.
Official ATT&CK sources for T1621 and Credential Access
Start with the Credential Access tactic page in MITRE ATT&CK, which defines TA0006 as the tactic where an adversary is trying to steal account names and passwords. T1621 Multi-factor authentication request generation sits in this tactic because an attacker who already holds a valid password tries to get past the second factor by triggering repeated push or prompt requests until the user approves one, or by otherwise abusing the authentication flow. Read the MITRE ATT&CK tactic TA0006 page before you write any detection, so your team uses the same definition of the tactic that auditors and red teams will use when they review your coverage.
Next, read the ATT&CK updates page to see which techniques, sub-techniques, detection strategies and data components changed in recent releases. ATT&CK can rename, deprecate or revoke techniques between versions, so a mapping you wrote against one version may not hold for another. Record the ATT&CK version your detections target in your detection register, and confirm in the release notes whether T1621 or its related data components changed before you rely on an older mapping. Your MFA platform team and your SOC lead should both sign off on that version choice.
For mapping checks, use the enterprise-attack 20.0 STIX bundle published in the mitre-attack/attack-stix-data repository. The bundle lets you confirm which data components, such as User Account Authentication (DC0002) and Application Log Content (DC0038), and which mitigations, such as User Training (M1017) and Multi-factor Authentication, are linked to T1621 in the version you target. Parse the bundle with your own script or a STIX library, and compare the output with the live technique page. Where the two disagree, treat the live page as the reference for the version it describes, and ask the ATT&CK team or your vendor to confirm the difference before you change your coverage claims.
How DeployOpen builds T1621 detections and range scenarios
DeployOpen approaches T1621 Multi-factor authentication request generation as a fixed-scope engagement inside the client's own environment. The work starts with agreed telemetry and identity sources, then moves into detection content, cyber range rehearsal and documented handover.
How we scope
- Confirm which identity providers, VPN gateways and SaaS applications emit MFA challenge and approval events into the logging pipeline.
- Agree in writing which platforms are covered, such as Windows, Linux, macOS and IaaS, and which are excluded.
- Record the ATT&CK version the detections will target, so mappings stay correct across future releases.
How we build
- Map User Account Authentication and Application Log Content fields to the detection logic for MFA prompt bursts and unusual approval patterns.
- Write detection rules in open formats such as Sigma and tune them against the client's own authentication baseline.
- Test detections in a private cyber range with simulated MFA fatigue scenarios before any change reaches production.
How we hand over
- Deliver detection documentation covering data sources, logic, known false positives and the response steps for each alert.
- Provide validation results from range exercises, so the client can repeat them after future changes.
- Document the User Training and Multi-factor Authentication mitigation evidence that the client's assessors may request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Confirm with the client how detection content will be reviewed when ATT&CK releases rename or deprecate techniques.
- Agree in the written scope how range exercises will be repeated and who owns the resulting detection changes.
