Послуги з імітації атак хакерів для вдосконалення процесів кібербезпеки.
/ BLOG
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.
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.
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.
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.
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.
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.
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.