MFA relay attacks show why login risk scoring is not enough

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Artemis Security's research: Real-time MFA relay, factor enrollment, and email deletion combined to hide an account takeover from point tools.

Why it matters: It matters because IAM teams cannot treat sign-in risk, factor enrollment, and downstream session activity as separate controls when attackers can stitch them together in one compromise path.

Context

MFA relay attacks exploit the gap between a valid sign-in and a valid session. In this case, the attacker phished a password and live MFA code, then used the resulting access to enroll their own device, read mail, and delete the alerts that would have exposed them.

For identity programmes, the governance problem is not whether MFA was challenged. It is whether login assurance, factor enrollment, and downstream session activity are treated as one control plane across the IdP, productivity suite, and SIEM.

Artemis Security’s incident demonstrates that separate telemetry sources can each be technically correct while still missing the intrusion. That is a familiar failure mode in federated identity environments where one system authenticates and another inherits the session.

Key questions

Q: What breaks when MFA is satisfied through a real-time relay attack?

A: A real-time relay attack breaks the assumption that a successful MFA challenge proves the legitimate user is present. The login can be genuine at the protocol level and still be attacker-controlled, because the adversary replays the password and live code in the moment they are entered. That makes the session trustworthy only in appearance, not in origin.

Q: Why do login risk scores miss account takeovers that continue after sign-in?

A: Login risk scores are usually evaluated at the point of authentication, not across everything the session does afterward. An attacker can satisfy a challenge, enroll a new factor, access SaaS data, and delete alerts without triggering a second interpretation unless logs are correlated across systems. The weakness is fragmentation, not lack of scoring.

Q: How can security teams measure whether MFA is resisting abuse?

A: Teams should watch for repeated prompts, unusual registration changes, help-desk impersonation reports, and successful approvals outside normal user behaviour. If a control is being triggered often enough to frustrate users, attackers can exploit that pressure. A resistant MFA programme should show low abuse volume, not just high deployment coverage.

Q: Should IAM teams rely on IdP logs alone to investigate federated compromises?

A: No. IdP logs show authentication, but the downstream SaaS platform often holds the evidence of mail access, file previews, and deletion activity. Investigations need the session identifier that crosses the boundary, plus enough telemetry from both sides to show what happened after login. Without that join, the compromise will look smaller than it was.

Technical breakdown

How real-time MFA relay defeats factor-based assurance

A real-time relay attack sits between the user and the legitimate login flow, capturing credentials and one-time codes as they are entered and replaying them before they expire. The authentication system sees valid factors, so the challenge succeeds even though the actor is malicious. This is why factor possession alone is weaker than phishing-resistant authentication: the control proves that someone had the factors, not necessarily that the rightful user did. In practice, short-lived codes and step-up prompts only work when the factor cannot be intercepted and replayed in the same session.

Practical implication: treat OTP-based MFA as relayable unless the factor is bound to the origin or device.

Why factor enrollment becomes a persistence mechanism

Once the attacker clears the initial challenge, enrolling a new trusted device changes the problem from session theft to durable access. Factor enrollment is a governance event, not just a usability step, because it expands the set of actors who can satisfy future challenges. When the new factor is attacker-controlled, every later push or approval flows to the adversary instead of the employee. That makes enrollment one of the highest-risk moments in the identity lifecycle, especially when it happens immediately after a suspicious login from a never-seen device or proxy infrastructure.

Practical implication: alert on new factor enrollment as a privileged identity event, not a routine account change.

Why cross-source correlation is the control that exposes the intrusion

The compromise only became obvious when the Okta session was joined to Microsoft 365 audit data through a shared session identifier. Identity providers often see authentication risk, while SaaS platforms see mailbox and document actions, but neither view is complete on its own. That fragmentation is what attackers rely on when they move from sign-in to data access and then delete the evidence. Correlation across the identity boundary is therefore a detection control, not a reporting convenience, because it reconstructs the full sequence of access, persistence, and cover-up.

Practical implication: correlate IdP, SaaS, and SIEM data on shared session IDs to reconstruct a complete compromise path.

Threat narrative

Attacker objective: The attacker’s objective was durable account takeover with access to mailbox content and adjacent internal documents while suppressing the alerts that would have revealed the compromise.

1. Entry occurred when the attacker phished the employee’s password and live MFA code through a real-time relay and used them to sign in successfully.
2. Credential access and escalation followed when the attacker answered the MFA challenge, then enrolled their own phone as a trusted factor for persistence.
3. Impact came when the attacker SSO’d into Microsoft 365, read the victim’s mailbox, previewed other employees’ documents, and deleted the Okta alert emails that would have exposed the takeover.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Login risk scoring is not an identity boundary. Risk engines can flag anomalous location, device, and proxy use, but they still evaluate a login in isolation. This incident shows that a high-risk sign-in can be technically correct and operationally insufficient when factor enrollment and downstream SaaS activity are outside the same control plane. Practitioners should stop treating the login as the unit of trust and start treating the session as the governable object.

Factor enrollment is the control point attackers want. The attacker did not need to break MFA once they had the factors in real time; they only needed to turn a transient relay into a durable trust relationship. That is why factor enrollment belongs in the same governance tier as password reset and recovery changes. The practical conclusion is simple: if enrollment is not continuously monitored, persistent compromise can be created inside a supposedly protected account.

Shared session correlation is now a core identity capability. The most valuable evidence in this case was not inside one vendor console. It emerged only when the Okta session and Microsoft 365 audit trail were joined. That is the identity equivalent of blast-radius analysis: each platform sees a fragment, but the compromise is visible only across the boundary. Security teams should treat cross-source correlation as a required control for investigation and containment.

Phishing-resistant authentication is the real fix for relayable factor theft. Password plus OTP still works as a second factor in the abstract, but it fails against a live relay because the attacker can reuse the code in the same moment it is issued. This is where factor binding matters more than challenge volume. The message for practitioners is that assurance must survive interception, not just satisfy a prompt.

Cross-source evidence stitching is an emerging named concept here. The incident only became intelligible when identity, mail, file, and alert-deletion events were stitched together through one session ID. That is not a SIEM nuisance problem; it is a governance gap in how fragmented identity events are interpreted. The practitioner implication is to design investigation workflows around joins, not around isolated alerts.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Control planes must now span sign-in, enrollment, and session behaviour. If those stages are governed separately, an attacker can move from relay to persistence to evidence suppression without any one team seeing the whole sequence. The practical shift is to treat the session as the object of record across the IdP and the SaaS layer.

New-device enrollment is the moment identity assumptions collapse. A factor enrolled under attacker control changes future authentication outcomes, so the real risk is not the login itself but the trust boundary it creates. For programmes that still separate authentication from lifecycle governance, this is where the model breaks.

Cross-source joins should be part of every identity investigation workflow. The key evidence in this case emerged only when authentication logs, mailbox events, and file access were stitched together by a shared session ID. Security teams that cannot perform that join will continue to detect fragments instead of incidents.

For practitioners

• Prioritise phishing-resistant factors Move high-risk and privileged users to factors that are bound to origin or device, because real-time relay can satisfy password plus OTP challenges in one session.
• Monitor factor enrollment as a high-risk event Alert when a new device or security method is enrolled on an account that has no prior enrollment history, especially if the login came from anonymizing infrastructure or a new device fingerprint.
• Correlate IdP and SaaS audit logs on session ID Join sign-in events, mailbox actions, file previews, and deletion activity by shared session identifiers so you can reconstruct what the attacker did after authentication.
• Review notification-deletion patterns Treat deletion of new sign-on or new security method emails as a cover-up signal, because the attacker often removes the only alerts that would expose the takeover.
• Audit federation risk coverage Check which platform actually evaluates federated sign-ins and confirm that the downstream SaaS tenant still receives enough telemetry to score and investigate the session.

Key takeaways

• A valid MFA challenge does not guarantee the rightful user is present when the factors can be relayed in real time.
• The attacker gained persistence by enrolling a trusted device and then removed the notification emails that would have exposed the compromise.
• Identity teams need cross-source session correlation, because the decisive evidence often sits across the IdP and the downstream SaaS platform.

Key terms

• Real-Time MFA Relay: A live attack pattern where an attacker intercepts a user’s authentication response and reuses it immediately against the legitimate service. The factor is not stolen for later use, but relayed during the same interaction, which defeats controls that assume a delay between approval and attacker action.
• Factor Enrollment Persistence: Factor enrollment persistence occurs when an attacker adds their own trusted device or method after initial compromise and uses it to maintain future access. In identity programmes, enrollment is a lifecycle event that can silently turn a one-time intrusion into durable account control.
• Session-Level Correlation: Session-level correlation links identity events across logs and tools into one continuous access story. This is critical when an attacker uses valid credentials, because isolated events can look harmless while the full sequence reveals compromise, privilege abuse, or lateral movement.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.