Premise

A payment provider came to us for pre-transaction security validation of their ADS environment. Previous internal audits showed no major concerns.

A publicly accessible Spring Boot Actuator endpoint was leaking heapdump files containing live AWS credentials for a privileged production role.

We were able to achieve a complete cloud environment compromise — no complex exploitation needed, just download and extract.

We are familiar with compromise chains like this because we have long been advocates for integrating our application security into our infrastructure assessments.

While many penetration testing companies keep their AppSec and infrastructure teams separate, we often exploit application issues as a part of both external and internal attack simulations.

With more companies adopting proper secure configuration baselines, live vulnerability discovery becomes more of a requirement for conducting infrastructure penetration tests than a luxury.

We saw this as an opportunity to share our approach when it comes to application security, and the advantages it brings to assumed breach assessments and red team simulations.

Application security for initial access

RCE chains in third-party software are a valid initial access vector, with exploitation of publicly-exposed assets consistently staying in the top 3 methods used during real-world breaches (alongside phishing and supply chains).

On the other hand, spending half a year dissecting the customer’s exposed third-party VPN solution or an on-premises mail server instance usually falls out of the expected timeline and the budget.

This is why we employ a more sensible approach, honing in on low-hanging fruit that may still be out of reach for infrastructure teams with no vulnerability research capabilities.

During our passive and active reconnaissance phases, we pick out the applications that we have the largest probability to breach: forgotten testing assets, demo rollouts, internal-use self-written applications,

development and monitoring solutions, etc. We are also less interested in traditional application security vulnerabilities that pose a risk, but that are harder to use in the context of an actual breach. Instead,

we focus on anything that could grant us access to internal assets (like SSRFs or open HTTP proxies), configuration and other information leaks, or RCE opportunities like custom plugin systems or mass administration solutions.

In this case, we were able to secure privileged initial access precisely because the application security engineer and the AWS penetration testing person were a part of the same team: something that would not be possible if the test were separated into two engagements, especially if these did not share a timeline.

Application security for privileged escalation and lateral movement

The same talking points apply for internal assessments or later stages of a red team: for most of our mature customers, you can’t just LDAP relay your way to the domain admin anymore. This is why, for us, the way to internal compromise

is also paved with custom vulnerabilities. In large infrastructures with dedicated internal development processes, there is always a bulk of internal applications, scripts, or configuration management solutions built with no security

in mind and tightly integrated with tier-0 assets like internal identity access management or mass administration.

Most internal development processes adopt an eggshell security model – it is never assumed that the security of internal-only applications will be an issue, since “they are not exposed”.

We can leverage this most of the time to escalate, with no exceptions for customers that apply all the proper secure configuration baselines.

Next time you order an infrastructure penetration test, pay close attention to the methodology used: if only standard attacks are used with no attempts to leverage environment-specific vulnerabilities, you may be no more secure than when you started.