Brute Forcing Financial Apps With HackerOne

About a month ago, I identified my first vulnerability — a SQL injection in a financial application. That discovery marked the beginning of my journey into bug bounty hunting, an area I’ve recently started exploring. There’s something particularly intriguing about testing financial applications; their security is critical, yet they often harbor overlooked weaknesses. While participating in another vulnerability disclosure program focused on financial software, I uncovered a brute-force vulnerability.

While testing app.finmark.com, I discovered a brute-force vulnerability in its authentication system.I noticed that the login page’s distinct error messages inadvertently exposed two significant security weaknesses: username enumeration and explicit attempt tracking.

When entering an invalid email, the application explicitly responded with a message that said “user not found”.

Sending a valid email and an invalid password for the first time meant the application responded with a message saying “5 login attempts remaining”.

Additionally, the application enforces a five-attempt lockout policy, which, when coupled with these error messages, allows an adversary to precisely gauge their password guessing window. This structured feedback enables attackers to compile a list of legitimate accounts and attempt password breaches using a targeted dictionary of the five most commonly used passwords that comply with the platform’s password policy. This vulnerability effectively provides a clear roadmap for account compromise, making it easier for attackers to execute a controlled brute-force attack while staying within the system’s predefined constraints. Discovering these issues has only deepened my curiosity and motivation to further refine my skills in application security — especially within the financial sector, where robust defenses are essential.

Moreover the response headers made things very easy for hackers who elected to use Burp Intruder, as invalid email entries resulted in HTTP Error 400 response code, while valid email entries with invalid passwords resulted in HTTP Error 401 response codes. This made enumerating valid emails via response code very straightforward.

Successful login attempts resulted in an HTTP 200 response code which made filtering successful logins with Burp Suite’s intruder even simpler.

This vulnerability could allow unauthorized access to user accounts, putting sensitive personal and corporate data at risk. Attackers can first enumerate valid usernames based on distinct error messages and then systematically test the five most commonly used passwords that comply with the website’s password policy within the defined five-attempt window. This method significantly increases the chances of successful account breaches, potentially leading to data theft, identity fraud, financial losses, and even lateral movement within corporate networks.

Another concern is the potential for account lockout attacks, where a malicious actor repeatedly submits login attempts with a known incorrect password, effectively denying access to legitimate users. Addressing this issue requires careful rate-limiting mechanisms and adaptive lockout strategies that differentiate between genuine users and automated attacks.