Because they sit between the user and the OTP without needing full device takeover. The victim still gets the code, the bank still sees a valid OTP, and the attacker receives the forwarded value in time to complete the session. SMS delivery and identity assurance are not the same thing.
How phishing APKs sit inside the OTP flow
Phishing APKs work because they do not need to defeat SMS delivery itself. They only need to capture the one-time code after the victim receives it, then relay it fast enough for the attacker to finish the login, reset, or enrolment step before the code expires. That is why SMS can remain “delivered” while the session is still compromised.
In practice, the APK acts like a man-in-the-middle for the authentication step. The user sees a believable sign-in screen, enters the code, and the attacker forwards it to the real service. The bank or provider receives a valid OTP from a live session, so the transaction looks legitimate unless the defender correlates device, location, and timing signals.
This is also why the attack is usually opportunistic rather than magical. It depends on social engineering, fast forwarding, and poor step-up controls, not on breaking the telecom channel. When the primary assurance factor is possession of a received SMS, an attacker who can intercept the user interaction can often satisfy the check without owning the device end to end.
Why SMS proves delivery, not user authenticity
SMS-based authentication assumes that control of the phone number is enough to prove the right person is present. In reality, an OTP only shows that a code reached a device and was entered within the time window. It does not prove the user is interacting with the genuine app, on the expected device, or in a trusted session.
That distinction matters because phishing APKs exploit the gap between delivery and assurance. The victim can still receive the message, so the service sees no delivery failure. But the attacker can steal the code at the human interface and use it as a temporary bearer token. The weakness is not the SMS transport by itself, it is relying on SMS as if it were phishing-resistant authentication.
For that reason, the important comparison is not SMS versus “no security.” It is SMS versus stronger factors that bind authentication to the real device, the real origin, or a cryptographically protected authenticator. A code that can be retyped or forwarded is inherently easier to proxy than an authenticator that cannot be relayed in real time.
What defenders should look for when SMS OTP is being relayed
The signals are usually in the sequence, not the message content. Fast OTP submission after delivery, repeated authentication from new devices, unusual app installs before a sign-in, and mismatches between user activity and device context are all consistent with a relay attack. The malicious APK may also push the user toward recovery or session refresh paths to widen the window of access.
Defensive telemetry should therefore focus on authentication context and step-up behaviour. If the service can see device reputation, geolocation drift, impossible travel, or anomalous session creation, those factors should influence challenge decisions. This is where phishing-resistant options become materially different, because they reduce the value of a code that can be copied out of band. Workforce Identity Security Guide and Passwordless and Passkeys Guide cover that shift from code-based trust to phishing-resistant sign-in patterns.
For a broader view of how OTP relay, MFA fatigue, and session theft fit together, MFA Guide is useful because it separates the factor from the assurance model. That distinction is the key to diagnosing why a valid OTP is still not a reliable signal of user presence.
Risk and Threat Considerations
Phishing APKs are dangerous because they convert a one-time password into a reusable interception point. Once the code is captured and relayed in time, the attacker can complete account access without needing the victim’s full device compromise, which makes the attack scalable against SMS-reliant flows.
Failure mechanism: The attacker places a malicious app between the user and the legitimate authentication flow, captures the OTP at the moment of entry, and forwards it before expiry so the backend accepts a valid but proxied authentication event.
Impact: The service may grant access, session creation, or recovery actions to an attacker who never had direct control of the original account holder’s device state, increasing the chance of account takeover and follow-on fraud.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | SMS OTP bypass is an authenticator assurance problem and phishing-resistant auth issue. |
| Recommendation — Prefer phishing-resistant authenticators and step-up rules for sensitive sign-ins. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question turns on OTP handling, relay risk, and authenticator strength. |
| Recommendation — Limit SMS OTP use and manage authenticator lifecycle and rotation carefully. | ||
| OWASP ASVS | V6 — Authentication | The issue is weak authentication assurance and relayable OTP flows. |
| V10 — OAuth and OIDC | Phishing-resistant sign-in and token-bound authentication reduce relay abuse. | |
| Recommendation — Require stronger authentication controls than SMS for high-risk actions. Use stronger federation and authentication patterns that resist OTP relay. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SMS bypass leads directly to unauthorized access and account takeover. |
| Recommendation — Restrict access paths and enforce stronger controls for sensitive accounts. | ||
Practitioner Guidance
What to verify: Treat any SMS OTP flow as weak if it does not include device-binding, origin binding, or strong step-up logic. If your telemetry cannot distinguish a genuine user session from a relayed one, the control is providing far less assurance than the user experience suggests.
Decision rule: If the protected action is account recovery, payment approval, password reset, or admin enrolment, prioritise phishing-resistant authentication over SMS. If SMS must remain temporarily, restrict it to lower-risk flows and add risk-based checks that can block unusual device or session patterns.
Practitioner takeaway: The real control objective is not “send and confirm a code,” it is “prove the authenticator is bound to the intended user and session,” because a code that can be proxied is only as strong as the relay path around it.
Related resources from NHI Mgmt Group
- Why do malicious APKs bypass traditional OTP-based authentication?
- Why do SMS-based authentication methods create more risk in environments exposed to phishing and SIM-swap fraud?
- Why does SIM swap fraud bypass SMS-based two-factor authentication so easily?
- How should security teams replace SMS-based authentication without creating new phishing or carrier dependency risks?