Cracking an Intigriti target in under 24 Hours with two vulnerabilities

Overview

This is the story of a focused bug hunting session in collaboration with my teammate @Rashed on an Intigriti target that led to two security findings, one in the triage phase and the other is critical but out of scope :( -- in under 24 hours. --

Target details and sensitive request data are intentionally redacted.

Methodology

I started with a detailed reconnaissance phase mapping the target’s assets and acquisitions, then reviewed application functionality and compared request behavior across user roles and application states.

I will share my reconnaissance methodology and mind maps soon.

Finding One

This report is a collaboration with my teammate @rashed.

Revoked Administrator Retains Privileged Action

An organization administrator who has been removed from the organization can still complete a previously saved privileged administrative action using their existing authenticated session.

An attacker was granted administrator privileges, saved a privileged delete action, and was then removed from the organization by a victim administrator. Despite no longer being a member, the attacker could replay the stored action and affect the victim’s organization account.

This indicates that organization membership and authorization are not being revalidated when an already-authenticated or already-initialized privileged action is executed.

Vulnerability Type

Broken Access Control / Improper Authorization

Affected functionality: organization user-management action endpoint (redacted)

Test Setup

• A victim organization administrator and an invited attacker administrator.
• The attacker is granted the organization administrator role.
• Burp Suite or another proxy to save and replay the affected request.

Reproduction Flow

1. Log in as the victim administrator and invite the attacker account.
2. Grant the attacker organization administrator privileges.

3. Log in as the attacker in a separate browser or session.
4. Save the delete request for a target organization user using Burp Suite.
5. As the victim administrator, remove the attacker from the organization.

6. Verify that the attacker is no longer listed and cannot use the normal interface.
7. Replay the saved request with the attacker’s existing cookies through the redacted endpoint.
8. Observe that the server accepts the privileged action despite the attacker’s removal.

9. Verify from the victim session that the organization account was affected.

Expected Behavior

After removal, the attacker’s current membership and role should be checked at execution time, and the request should be rejected with an authorization error such as 403 Forbidden.

Observed Behavior

The previously authorized session remained capable of executing the privileged action after removal, allowing the revoked administrator to perform an unauthorized action against the organization.

Attack Sequence

Finding Two

Race Condition Bypasses Login Rate Limits and Enables Account Takeover

The target’s login protection could be bypassed by sending multiple authentication attempts concurrently. Because the rate-limit state was not updated atomically, several requests could be processed before the restriction was applied.

This allowed an attacker to perform password-guessing attempts at a higher rate than intended and, with a valid password candidate, take over the targeted account.

When attempting the same attack normally and sequentially, the account was temporarily blocked after repeated failed attempts. During that lockout period, even entering the correct password did not restore access. The race condition was significant because concurrent requests could bypass this protection before the lockout state was consistently applied.

Vulnerability Type

Race Condition / Improper Rate Limiting / Account Takeover

Affected functionality: login request flow and rate-limit control (endpoint redacted)

Root Cause

The application appeared to evaluate the login-attempt limit and process authentication requests concurrently without a reliable atomic counter or server-side lock. Multiple requests could therefore pass the limit check during the same time window.

Reproduction Flow

1. Use an account created for testing or an account for which explicit authorization has been obtained.
2. Submit login attempts through the redacted login endpoint.
3. If we tried normal sequential attempts, the account would be blocked after repeated failures even if we entered the correct password.

4. Send a controlled batch of requests concurrently rather than sequentially.
5. Observe that multiple attempts are processed before the rate limit is enforced.
6. Confirm that the effective attempt rate exceeds the intended protection threshold.

7. When the correct credential is supplied within the tested account’s authorized scope, observe that authentication succeeds and the account can be accessed.

Expected Behavior

All authentication attempts should be counted atomically. Requests that exceed the configured threshold should be rejected consistently, including when they arrive concurrently.

Observed Behavior

Concurrent requests bypassed the intended rate-limit behavior, allowing an attacker to continue password-guessing attempts and ultimately authenticate as the targeted user.

Disclosure

The findings were reported through Intigriti’s responsible disclosure process.