Threat Modeling a Legacy System: How Fixing One Choke Point Eliminated Entire Attack Vectors

Part 1 —What are we working on and What can go wrong?

At a high level, the system is fairly typical. There is a web dashboard used by employees and managers, a mobile app for customers, and a backend running in AWS. The key detail here is that everything ultimately converges into the EC2 instance, where the application, database, and supporting components live.

Data flow diagram containing all relevant flows for the application

Instead of starting with vulnerabilities or SAST/DAST reports, I started with a simpler question: what is the most important asset in this system? What do I need to protect first? That’s why I chose to focus on the database first. It contains all customer data, and if it is compromised, it directly affects trust and could realistically lead to losing clients and revenue.

With this priority defined, I asked myself: “what would an attacker need to do to exfiltrate the database?”. That framing immediately changes how you look at the system. You stop thinking in terms of isolated bugs and start thinking in terms of paths. A few obvious attack vectors came up quickly. An attacker could try to exploit the web application, for example through SQL injection. They could attempt to compromise infrastructure, like gaining access to an SSH key or an AWS account. They could go after backups stored in S3. Or they could try to access internal tooling that connects directly to the database.

Initially, I assumed SQL injection would be the dominant risk, “it’s an OWASP Top 10 risk, why wouldn’t it be the priority?”. It is usually the first risk that comes to mind in systems like this. But once I looked more closely at how the backend was implemented, that assumption started to weaken. The application relied on frameworks like Spring JPA, which significantly reduced the likelihood of exploitable injection points compared to what I had imagined.

At the same time, another component stood out: phpMyAdmin.

Inside the EC2 instance, phpMyAdmin sits very close to the data. While the application goes through layers (web server, backend logic, authorization checks), phpMyAdmin is essentially a direct interface to MySQL. If an attacker reaches it, most of those layers become irrelevant.

What made this important was not just its existence, but how many attack paths converged into it. An external attacker with no credentials could attempt phishing to obtain access. They could reuse credentials exposed in scripts or source code. They could exploit known vulnerabilities. They could attempt brute force. Different techniques, different entry points, but the same outcome: direct access to the database. That was the turning point. Multiple attack paths were converging into a single control point. To make this clearer, I mapped these paths into a simplified attack tree focused on a single goal: exfiltrate database information.

Attack tree, notice how different techniques such as phishing, credential leaks, brute force, and known vulnerabilities can all lead to the same outcome.

At this stage, I still lacked confidence in how complete my analysis was. That is where mapping the scenarios to MITRE ATT&CK helped. It forced me to step outside my own assumptions and check whether I was missing common attacker behaviors, especially around credential access and reuse. In practice, it validated some of my initial thoughts, but more importantly, it exposed patterns I had not fully considered. Instead of thinking what vulnerabilities exist, the question became what techniques an attacker would actually use here, and what they need to succeed. This was especially evident around credential exposure and reuse, which appeared repeatedly across different attack paths.

With that perspective, prioritization became much clearer.

I ended up with four main candidates: infrastructure-level access to the MySQL server, interface-level access through phpMyAdmin, access to backups in S3, and SQL injection through the web application. If I had to fix only one thing first, the answer was not the most complex or technically interesting one. It was the one that was publicly exposed and required the least effort for an attacker to cause real impact. That was phpMyAdmin.

At the same time, there were other areas I knew deserved attention. Infrastructure configurations like security groups, IAM policies, or the lack of a proper CI/CD pipeline all introduce risk. In a more mature environment, these would be part of the baseline.

But this is where constraints matter, my goal was not to redesign everything, it was to reduce the most critical risks as quickly as possible. So instead of trying to fix everything at once, I focused on what was both exposed and directly connected to the most valuable asset.

Focusing on that single access point meant addressing multiple attack paths at once. It also meant prioritizing based on impact and exposure, not on how “serious” a vulnerability sounds in isolation. SQL injection, for example, can be critical, but in this case it required more constraints and offered less direct control compared to accessing the database through an administrative interface.

This is where one of the main takeaways became clear to me: you do not need a perfect threat modeling to make meaningful security improvements. You need a clear objective, a realistic view of how attackers operate, and the discipline to focus on what actually reduces risk.

In the next part, I’ll go deeper into the decisions. I’ll break down what made phpMyAdmin such a central point, which mitigations I considered, which ones I deliberately did not implement, and how a relatively small set of changes ended up eliminating multiple attack paths at once.

Thanks for reading! If you found this breakdown helpful or want to talk product security and threat modeling, let’s connect on LinkedIn: https://www.linkedin.com/in/felipevalencio/

P.S: If you are interested in Product Security, check this post: Product Security Manifesto.