Web Security Series #2 — Bypassing Authentication via MFA Tampering (Second-Factor Replay Attack)

Multi-Factor Authentication (MFA) is widely used to strengthen authentication mechanisms by requiring users to verify their identity using more than one factor. Typically, after entering a username and password, a user must provide a one-time verification code generated through a device or authentication system.

While MFA significantly improves security, improper implementation can introduce vulnerabilities. One such vulnerability is MFA tampering, also known as a second-factor replay attack. In this write-up, I demonstrate how a misconfigured MFA mechanism can allow an attacker to authenticate as another user by modifying a captured request.

This article is part of my Web Security Series, where I document hands-on web security labs and explain how different vulnerabilities can be exploited and mitigated.

Understanding MFA Tampering

MFA tampering occurs when an attacker intercepts an authentication request containing a valid MFA token and modifies certain parameters before forwarding the request to the server.

In secure implementations, an MFA token should be strictly bound to the specific user and session that generated it. However, if the server fails to validate this relationship correctly, the same MFA token may be reused for another account.

This weakness allows an attacker to authenticate as a different user by simply modifying parameters such as the username in the intercepted request.

Such vulnerabilities highlight the importance of implementing strong server-side validation and session binding when designing authentication systems.

When This Attack Can Be Performed

This attack technique is typically used during the exploitation phase of a penetration test when certain conditions are present.

It may be applicable when:

• Valid credentials and an MFA code are available for one account.
• The application prevents modifying the username in the browser interface during the MFA step.
• The authentication request containing the username and MFA code can still be intercepted and modified.
• The server does not properly validate that the MFA code belongs to the original user or session.

⚠️ These techniques should only be tested in authorized environments, such as security labs or systems where explicit permission has been granted.

Lab Objective

The objective of this lab is to:

Authenticate as a different user (jeremy) by intercepting and modifying the MFA submission request that originally contains the credentials and MFA code for another user (jessamy).

Lab Environment

In this lab scenario, the application provides valid credentials for one account.

Provided credentials

username = jessamy
password = pasta

username = jessamy
password = pasta

The MFA code is also available through the lab environment.

However, the login interface does not allow modification of the username during the MFA verification step. Despite this restriction in the user interface, the authentication request sent to the server can still be intercepted and modified.

Tools Used

The following tools are used during this lab:

• Burp Suite (for intercepting and modifying HTTP requests)
• Web browser configured with Burp proxy
• Lab environment providing test credentials and MFA code

Burp Suite is particularly useful because it allows testers to inspect and modify HTTP traffic between the browser and the server.

Step 1 — Perform Initial Authentication

First, log in using the credentials provided by the lab.

username = jessamy
password = pasta

username = jessamy
password = pasta

After submitting these credentials, the application prompts for the MFA verification code.

The MFA code can be obtained by clicking the "found here" link provided by the lab.

Step 2 — Intercept the MFA Request

Before submitting the MFA code, ensure that Burp Suite Proxy Intercept is enabled.

Enter the MFA code into the form but keep interception active so that the request is captured before reaching the server.

At this stage, the username cannot be modified in the browser interface, but the HTTP request will still contain the username parameter.

Step 3 — Capture the HTTP Request in Burp

Once the MFA code is submitted, Burp Suite intercepts the HTTP request.

Navigate to:

Burp Suite → Proxy → Intercept

Burp Suite → Proxy → Intercept

You should see a POST request containing both the username parameter and the MFA code.

Step 4 — Modify the Username Parameter

In the intercepted request, locate the username parameter.

Example original request:

username=jessamy&mfa_code=123456

username=jessamy&mfa_code=123456

Modify the username to another user in the system.

Modified request:

username=jeremy&mfa_code=123456

username=jeremy&mfa_code=123456

The MFA code remains unchanged.

This manipulation attempts to reuse the valid MFA code issued for jessamy to authenticate as jeremy.

Step 5 — Forward the Modified Request

After modifying the request, click Forward in Burp Suite so that the tampered request is sent to the server.

If the server fails to validate the relationship between the MFA code and the username, the authentication request will succeed.

Step 6 — Verify Successful Authentication

Return to the web application and observe the result.

If the attack succeeds, the application authenticates the session as jeremy, even though the MFA code originally belonged to jessamy.

Why This Vulnerability Occurs

This vulnerability exists because the server does not properly bind the MFA token to the original user or session.

Instead of verifying that the MFA code belongs to the specific account that initiated authentication, the system simply validates the code itself.

As a result, modifying the username parameter allows the attacker to authenticate as another user.

Security Impact

Improper MFA validation can lead to serious security consequences, including:

• Unauthorized account access
• Privilege escalation
• Compromise of sensitive data
• Bypassing strong authentication mechanisms

Even though MFA is designed to enhance security, poor implementation can completely undermine its purpose.

How to Prevent MFA Tampering Attacks

Developers can prevent this vulnerability by implementing proper server-side validation mechanisms.

Recommended security practices include:

• Binding MFA tokens to a specific user session
• Validating that the MFA code belongs to the correct username
• Expiring MFA tokens after a single use
• Implementing secure session management
• Monitoring abnormal authentication behavior

These controls ensure that MFA verification cannot be reused or manipulated.

Conclusion

This lab demonstrated how improper implementation of multi-factor authentication can lead to an authentication bypass vulnerability.

By intercepting and modifying the MFA verification request using Burp Suite, it was possible to authenticate as a different user by reusing another user's MFA code.

Understanding vulnerabilities like MFA tampering helps security professionals identify weaknesses in authentication systems and implement stronger defenses against real-world attacks.

Connect With Me

If you found this write-up helpful, feel free to follow my cybersecurity learning journey.

🔗 LinkedIn: linkedin.com/in/laibakashif0011