CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Web Applications and Internal Penetration Tests

Until recently, I really didn't care about web applications on an internal penetration test. Whether it was as an entry point or target, I was not interested, since I typically had far better targets and could compromise the networks anyway. However, the times have changed, internal environments are much more restricted, not many services are exposed, and applications are the main reason for the tests. This is not supposed to be a guide to analyze web applications, but some thoughts regarding web apps during internal pentests.

Reaching the Apps

As a pentester at SpiderLabs, we normally do our internal tests remotely, mostly using the SSH protocol and this is another thing that kept us from web applications, the terminal. The command-line is certainly not the best scenario for web applications assessment, but there are tools and tricks that can help us with the task.

As mentioned, one of the challenges for testing applications on an internal test is how to access the network remotely. Using SSH, we have different alternatives. For instance, it is possible to set up an SSH proxy with the -D flag and using the -X to initiate an X11 display for the connection (although even with compression, I do not recommend this).

Once we solve the best equation for access, it is time to start.

Entry Point

Using the proxy established by the SSH connection, you are now able to use any web assessment tool. However you may find countless web servers and applications, so identifying security issues on each one is not feasible for a time-limited test. Every test is mostly guided by the tester's experience, and that is true in this situation as well. I like to use the WhatWeb tool for checking what is the technology utilized on the application and server. Another interesting fact, when your access is internal, you will often find these web applications unprotected with no WAF to interfere with your probing.

Ww.png_shadowFigure 1: Running WhatWeb on an internal network.

That gives me some idea of what I can expect from the application and whether it's worth taking the chance to analyze them. Remember that the test is time-limited, s0 we can't waste time, we need to pwn ;) A big part of the web assessment on the internal pentests is to choose the applications you want to investigate. What you will analyze will be fundamental for the final results of the engagement.

I normally try to check for well-known applications or odd/old applications. I also look for anything that rings the bell as directory indexing enabled, default files, verbose errors, etc. It is common to identify legacy applications, which is normally a gold pot. 

After deciding which applications to target (maybe choosing more than one), I perform brute-force/crawling by using the tool dirb, another command-line utility very helpful in this situation.

Dirb.png_shadowFigure 2: Using the dirb utility with default wordlist.


You may normally find interesting stuff during the initial phase including unprotected management consoles, LFI/RFI vulnerabilities, repositories, frameworks, sensitive information, etc. 

Rce.png_shadowFigure 3: RCE found using an open Jenkins application.

As an internal penetration test, I'm primarily concerned with only high/critical risk vulnerabilities and when you don't have to work about WAF there's a lot you can look for. This used in our favor to exploit unexpected behavior on web apps like SQL Injection (SQLi). A well-known tool for SQL Injection exploitation can also be used for identification, the popular sqlmap. You can use the flag --crawl and the utility will go deep on the application (by a number of layers) as defined to search for SQLi vulnerabilities. The --batch flag will automate the process and there will be no questions to be responded to during the analysis.

Target Apps

If you are familiar with red team engagements, you know that the targets are mainly defined by applications. Even with access to a server, dealing with the information on it is not that straightforward. While working with desktop applications, we may collect a lot of information from the processes' memory but that is not the case with web browsers, at least not easy as with in-house desktop apps. However, in web browsers, we have access to a lot of other types of data to analyze such as favorite websites, saved passwords, cached sessions, etc. Having desktop access will facilitate that job and you can use any of the common access tools available like VNC, RDP, LogMeIn, and others.

I like to check the home directory for identifying what user can have access to the specific machine but as you explore you will probably find your own favorite sources of data!


There's no turning back and web applications are here to stay. Due to the cloud environment, we may not have many services to interact with, so we have to make sure our ability to work with web apps is kept sharp. Hopefully, this post gives you some new ideas for your next internal pentest and some tools to practice within the meantime,

Latest SpiderLabs Blogs

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway

Overview A command injection vulnerability has been discovered in the GlobalProtect feature within Palo Alto Networks PAN-OS software for specific versions that have distinct feature configurations...

Read More


We all know the cybersecurity industry loves its acronyms, but just because this fact is widely known doesn’t mean everyone knows the story behind the alphabet soup groups of letters, we must deal...

Read More

Phishing Deception - Suspended Domains Reveal Malicious Payload for Latin American Region

Recently, we observed a phishing campaign targeting the Latin American region. The phishing email contained a ZIP file attachment that when extracted reveals an HTML file that leads to a malicious...

Read More