How Attackers Bypass 2FA with Response Tampering
This post covers two real-world 2FA bypasses found via response tampering on the Synack Red Team. In both cases, the application validated OTP completion on the client side rather than the server, allowing an attacker to manipulate HTTP responses to skip the 2FA step entirely.
Technical Summary
Exploits Explained
Two real-world 2FA implementations validated OTP completion on the client side instead of the server.
In the first case, changing the HTTP status code from 400 to 200 and a body parameter from 0 to 1 was enough to bypass the check entirely.
In the second, replacing a failed OTP response body with the successful one moved the attacker forward without the back end ever confirming a valid code was entered.
Neither flaw could be caught by automated scanners, since both required comparing valid and invalid responses side by side to spot the trust boundary.
Two-factor authentication (2FA) is now widely used to secure user and employee accounts in web applications. As data breaches continue to expose credentials at scale, credential stuffing attacks have become increasingly common. Because users frequently register for new applications and reuse the same email and password combinations across multiple platforms, bypassing 2FA is a high-value objective for attackers seeking to compromise accounts.
Response tampering is one of the more common and dangerous bypass techniques. The root cause is a logical flaw in the application’s code that can only be detected through manual testing by experienced security researchers.
In this blog, I’ll cover two real-world 2FA bypass techniques via response tampering that I’ve found throughout my time as a member of the Synack Red Team.
Case Study 1: Exploiting Missing Back-End OTP Validation in a Node.js App
One application with node.js technology was using 2FA confirmation for the first registration in a mobile phone. After the first form sending, the application was sending a one-time password code to the mobile number assigned. When an invalid code was entered, the application returned a code is invalid error.
Analyzing back-end requests showed that the application returned a “400 Bad Request” error, within two parameters in the body, named “size” and “timeout” where both had “0” values.
By using response tampering and changing HTTP status response code from “400 Bad Request” to the “200 OK” and “size” parameter from “0” to “1,” it was possible for an attacker to bypass the 2FA control found in the front-end. While the main root cause here was not checking the 2FA code confirmation on the back-end within the session successfully, response tampering was helping attackers easily exploit it by further enumerating API endpoints and request structure.
Case Study 2: Bypassing OTP Validation by Tampering with JSON Response Body
Another application was using 2FA technologies as an additional security control while logging in to the application. When choosing an already added OTP method, the application was redirecting users to the code entrance page.
On an invalid OTP attempt, the application returned an error response with the below JSON body:
On a successful OTP attempt, the application returned the below JSON body:
Comparing the two responses was one of the main clues to finding this kind of bypass. It was obvious for this one: When the “actionResult” parameter was value “challenge,” it was returning the user/attacker to the 2FA page again. On the other hand, when it was “success,” the user was redirected to the next step.
Well, that was not that easy this time. This case was more complex. Because some parameters were stored in the browser’s localStorage, changing only the “actionResult” parameter caused the application to redirect back to the login page. However, replacing the full response body of a failed OTP request with the success response body was sufficient to bypass 2FA confirmation. This indicated that the session cookies were not validated against the OTP completion state on the back-end. The application was trusting client-side controls alone.
Because the success response body contained no complex values to guess, such as a session or OTP token subject to further validation, an authenticated attacker could replay this response repeatedly and use the information gathered for further attacks.
Thanks for reading. Be sure to follow Synack and the Synack Red Team on LinkedIn for upcoming Exploits Explained posts in this series.
About the Author
Ozgur Alp is an offensive security specialist with over a decade of experience in penetration testing, consulting, and security training, holding both OSCP and OSWE certifications. He currently ranks in the top three all-time on the Synack Red Team, with more than 2,000 accepted vulnerabilities across 500+ unique client engagements, including 250+ critical findings at CVSS 9.0 or above. As a LEGEND Hall of Fame inductee, Ozgur has fulfilled all five of Synack’s exclusive researcher criteria and has earned TITAN status for four consecutive years. A member of the Synack Circle of Trust, he advises on platform direction and researcher experience, has helped 20+ new researchers join through the Envoy program, and organized the first official global SRT hangout. Beyond active research, Ozgur shares expertise through technical writing, university-level instruction, public speaking at events including Black Hat, and on-site consulting with organizations worldwide.
Frequently Asked Questions
Two-factor authentication is designed to add a second layer of identity verification beyond a username and password, typically through a one-time code sent to a phone or generated by an authenticator app. A bypass via response tampering occurs when the server never actually validates that the 2FA step completed successfully on the back end. Instead, it relies on the client-side response to determine whether to proceed. An attacker intercepts that response using a proxy tool like Burp Suite, modifies it to mimic a successful verification, and the application moves them forward without ever confirming a valid code was entered.
The root cause is a logical flaw in how the application handles authentication state, not a malformed input or a known payload pattern. Automated scanners look for signature-based vulnerabilities. They cannot reason about the difference between a 400 and a 200 response in the context of an OTP flow, recognize that a response parameter controls session progression, or determine that a success response body can be replayed against a failed request. Detection requires a human tester who can read the application’s behavior, compare valid and invalid responses side by side, and hypothesize what the server is actually trusting.
Not if the server never checks the OTP state when issuing or validating that cookie. In the second example in this post, the session cookies were present and appeared valid, but the back end did not tie them to whether the OTP step had been completed successfully. That meant an attacker could replay a success response body against a failed OTP request and still be moved forward in the flow. The cookie authenticated the session, but it did not verify the 2FA outcome. Proper protection requires the server to explicitly confirm OTP success before advancing the user’s session state, regardless of what the client reports.
What would 1,500
elite hackers find in
your stack?
The Synack Red Team and Sara AI Pentesting work side by side to test your environment and find vulnerabilities that matter.
