Послуги з імітації атак хакерів для вдосконалення процесів кібербезпеки.

Послуги з імітації атак хакерів для вдосконалення процесів кібербезпеки.

Simulated hacker attacks to improve cyber security processes.

Simulated hacker attacks to improve cyber security processes.

/ BLOG

From WAF Bypass to Remote Code Execution: A Chain of Errors Leading to Internal Infrastructure Compromise

Heading photo

In today's landscape, a successful attack on a corporate network is rarely the result of a single critical vulnerability. Instead, it is usually a complex chain where minor architectural flaws and misconfigurations amplify one another. To spot these subtle attack vectors before malicious actors exploit them, businesses bring in experts to conduct penetration testing (pentesting).
During a recent project, ITS Red Team specialists evaluated the security posture of a major financial institution through penetration testing. The objective was to test the resilience of a comprehensive system comprising a public website, an API, and an admin panel. This article serves as a step-by-step chronicle of the assessment, demonstrating how seemingly minor weaknesses can pave the way to full server control.

Why a Secure Website Doesn't Guarantee Whole-System Security?

From the outside, the system looked like an impregnable fortress: its architecture consisted of a public website for visitors, an API backend to handle requests, and a hidden admin panel for employees. The main site was securely protected by a Web Application Firewall (WAF) solution, which successfully blocked suspicious scans.
However, an analysis of the external perimeter revealed a critical gap: the WAF only covered the visual side of the resource (www). The API functions processing user data were left completely unprotected.

Illustration

This scenario stems from a common issue — inadequate WAF coverage across web application components. Because a programming interface lacks a graphical user interface, it is often mistakenly viewed as an internal and less vulnerable component. However, an API cannot be hidden; the website openly makes requests to it from the browser, leaving those requests visible to anyone monitoring network traffic. Given this gap in perimeter defense, the testing focused heavily on the backend.

The Entry Point: SQL Injection and Unauthorized Database Access

While analyzing open API endpoints, a critical function was discovered. It passed user input directly to the database without proper sanitization or parameterization (the mechanism that separates data from the command itself). This is a textbook example of an injection vulnerability in the OWASP Top 10.
Exploiting this vulnerability allowed unauthorized SQL queries to run directly against the database, granting the ability to read, modify, and delete all the information inside.
The situation was severely compounded by another architectural flaw: public website data, customer requests, and administrative panel system information were all stored within a single environment. Within this data pool, active admin sessions were uncovered — temporary tokens that authenticate a user without requiring a password re-entry.
To prevent attacks from advancing to this stage, it is highly recommended to extend WAF protection to the API. The primary function of this solution is to block suspicious requests and automated scanners automatically. Deploying this on the backend significantly increases the time and resources an attacker must spend to exploit the vulnerability, giving the monitoring team vital extra time to respond before a data breach occurs.

Privilege Escalation: Public Availability of the Admin Panel as a Fatal Flaw

After acquiring the access tokens, the next phase of the exploitation chain involved attempting to authenticate into the content management system. During OSINT (open-source intelligence) gathering on the client's external infrastructure, a hidden administrative panel was uncovered — which, as it turned out, was publicly accessible.
Rather than isolating the management interface within the internal corporate network — restricting access solely via VPN or an IP allowlist — the developers relied on the "Security by Obscurity" concept. They assumed outsiders simply would not find the complex login URL. Consequently, the admin login portal was accessible from anywhere in the world, completely unrestricted and lacking additional protection (with no WAF configured for the admin panel either).
Using tokens harvested from the database, the team effortlessly logged in to the panel with administrative privileges. To maintain persistence and ensure uninterrupted access, a new account with maximum permissions was created.

How Insecure File Uploads Led to Remote Code Execution?

Once administrative access was secured, the focus shifted to analyzing internal functionalities. A file upload module immediately stood out. Because the upload mechanism lacked proper extension and content validation, a web shell could be uploaded to the server. Injecting this malicious script into the system enabled the execution of arbitrary commands locally on the servers hosting the admin panel, the main website, and the API.
Consequently, a successful database compromise and administrative takeover escalated into a critical Remote Code Execution (RCE) threat. This phase clearly illustrates that inadequate security within sensitive features creates a single point of failure, even when those tools reside entirely within an authorized zone.

From Excessive User Privileges to Complete System Control

Executing commands on a server doesn't automatically mean a complete compromise, as an attacker's capabilities are restricted by the privileges of the user account running the web application. However, this infrastructure violated a fundamental security rule: the Principle of Least Privilege (PoLP), which dictates that an account should have only the permissions necessary to perform its function.
The web server process was running under a local user account with permission to execute arbitrary commands as a superuser (sudo). This allowed for the immediate, absolute takeover of the file system, logs, network interfaces, and the entire operating system.
A web service designed to serve website pages does not need root privileges. Running the process within a restricted user context confines the impact of a potential attack to the web application level, preventing a total compromise of the underlying operating system.

Illustration

Business Risks of a Successful Vulnerability Chain Exploitation

Achieving root access marks the end of the active testing phase, as a complete compromise has been fully documented. From this point on, the consequences are limited only by the goals and imagination of a potential attacker. Below is an overview of what a hacker could achieve with these privileges.
Control over the admin panel grants total authority over everything visitors see. An attacker could deface the website to spread misinformation or alter payment details and external links.
Exfiltrating databases containing personal information, customer complaints, and passport data deals an irreparable blow to a financial institution's reputation. Furthermore, the attacker could lock out legitimate administrators before inflicting damage, severely crippling the incident response efforts.
Gaining superuser rights provides absolute control at the operating system level, allowing any files, configurations, and event logs to be modified or wiped to cover the attacker's tracks.
Another critical fallout is Lateral Movement — pivoting from the compromised server deeper into the internal infrastructure to reach neighboring corporate systems. Specifically, by analyzing local users' command history, attackers risk hijacking test environments and backup systems. In a worst-case scenario, intentionally deleting configurations and wiping backups can completely paralyze the institution's operations for an extended period.

Illustration

Lines of Defense: How to Break the Vulnerability Exploitation Chain

This incident analysis clearly demonstrates that the attack could have been disrupted at any stage. To eliminate such threats, organizations should adopt a comprehensive approach, countering each step of the attacker's progression with a specific security control:
1. API vulnerability exploitation (SQL injection) → Expanding WAF coverage. A WAF solution should filter traffic not just for the main website, but across all external API endpoints. This ensures early anomaly detection and automatically blocks malicious requests at the external perimeter.2. Token theft from the database → Architectural segmentation. User-facing content and the administrative backend logic must be strictly segregated into separate databases. This way, a data breach in the public zone cannot physically compromise administrative credentials.3. Unauthorized access → Network isolation of the admin panel. The management interface must be entirely inaccessible from the public internet. Access should be restricted strictly to secure corporate channels (VPN) or a predefined IP allowlist.4. System takeover (privilege escalation) → Restricting privileges. The user account running the web service should operate with least privilege. The ability to execute system commands with superuser privileges (sudo) without entering a password must be strictly prohibited.

Illustration

ITS Red Team — Simulating Attacks for Proactive Defense

Automated security reports only provide a list of isolated technical vulnerabilities, overlooking how they connect logically in the real world. Professional penetration testing evaluates the actual resilience of a corporate network and uncovers complex compromise vectors.
The ITS Red Team conducts comprehensive pentests using BlackBox (testing from an external attacker's perspective with no prior data) and GreyBox (system analysis based on limited internal privileges) methodologies. As part of the service, we replicate potential adversaries' logic, expose hidden error chains, and pinpoint critical areas where an attack can be intercepted with minimal business disruption.
Reliable defense begins with understanding the logic behind a potential attack vector. To evaluate the true resilience of your architecture and see it through an attacker's eyes in practice, submit a request on the ITS Red Team website.

Need expert advice?