One-Two Punch: Using AppSec to Up Your Pentests and Phishing Gigs

Jun 26 · 8 min read

Let’s Get Ready to Rumble!

In this corner we have the previous InfoSec champion of the world, penetration testing. Pentesting is no stranger in the Cybersecurity space. In the other, and also popular, dynamic application security testing. These are not the same, but have you considered using AppSec to enhance your existing penetration testing and phishing engagements? Instead of viewing these consulting services as distinct, isolated components, AppSec can be a great multiplier when teamed up with pentesting/red teaming and phishing. The result is a more comprehensive, holistic view of the environment and can lead to better results in the other red team activities.

I’m writing this blog because it’s not always obvious to pentesters and I often find critical web vulnerabilities that were missed by other teams. AppSec seems to be the path less traveled, especially when the engagement isn’t sold specifically as a static or dynamic application security gig. The client is expecting that punch to the head, the vulnerability scan and the Man-in-the-Middle attack. They’re not expecting that left hook, the external command injection vulnerability on their HR server. It can be the difference between a knockout (KO) and a total knockout (TKO) report for the client. Just ask King Hippo.

Round 1: Penetration Testing & Red Team (Physical)

Fortunately for you, dear reader, I decided not to go into full-on story mode with this blog. I’ll cite some examples at a high level that I’ve experienced personally but for the most part I’ll keep it short and simple. There are multiple instances I’ve experienced while doing either penetration testing or red team activities where AppSec made the difference between a successful engagement and a so-so one. You might be thinking, “Well my vulnerability scanners support application testing”. True, but they typically aren’t very comprehensive. Sorry, they just aren’t. (Looking at you, Tenable!)

Traditional Penetration Testing

The issues below are just some examples of web findings I’ve come across that aided with my penetration tests in the past:

  • SQL Injection (SQLi)
  • Local File Include (LFI)
  • Server Side Request Forgery (SSRF)
  • Unrestricted File Uploads (Web Shells, Hashes, etc)
  • Command Injection
  • Misconfigured Web Services / Information Disclosure (Directory Listing, Verbose Error Messages, etc)

I was once doing a pentest for a new client who was big on rotating their security vendors annually. Although I support having a fresh set of eyes working on your environment each time, I think there’s some value in security professionals knowing your network and business. As a manager I strongly believed in rotating the lead internally for each recurring engagement. I digress..

This one particular environment was somewhat mature from a security perspective and had regular vulnerability scanning and penetration testing performed on their external perimeter. Not surprisingly, I wasn’t able to find anything worthwhile to leverage in order to gain access to the Internal environment and my go-to (phishing) wasn’t in scope. Instead, I used the leftover time I had available to do some application security testing in Burp Suite Professional. Using my nmap/Nessus host and service discovery results, I sucked the web services into Burp’s sitemap and started testing. It wasn’t long until I found unauthenticated SQL injection with os-shell access. The service was running as an elevated account, so from here it was an easy win from an internal testing perspective.

Had the web applications been tested by the prior security firm this wouldn’t have happened and I would likely have struggled to find any worthwhile results during the engagement. I’ve seen the same thing with LFI for gaining access to credentials, SSRF to access sensitive internal systems that aren’t exposed publicly, unrestricted file uploads leading to web shells and NTLMv2 hash leaks, and misconfigured web services resulting in sensitive information disclosure by means of directory listing and verbose error messages. I’ve also seen directory listings that exposed SQL backup files and htaccess files with credentials or hashes in them. I’m sure I’m not alone here.. In my previous blog I even demonstrated how a Command Injection vuln in a FireEye web appliance allowed me to get root access to the underlying operating system when there were no other service vulnerabilities present.

Red Team / Physical Penetration Testing / Physical Social Engineering

These engagements can be really fun. Typically there’s a lot of recon and planning that goes on prior to an on-site activity. Here are just a few of the things I’ve seen via web applications that could come in really handy during a red team engagement;

  • Physical Access Control Systems (Default or Weak Credentials, Auth Bypass, etc)
  • Access and Control of Camera / Security Systems
  • Access Codes for Doors / Badges
  • Building and Cubicle Diagrams

As you can imagine, having someone on your team who can give you access to the facilities while you’re physically on-site doing a red team can come in really handy. A remote teammate or even you yourself with an Internet connected device could remotely open garage doors, unlock interior doors, and disable the cameras to go undetected, Mission Impossible style! I’ve accessed building codes and cubicle layouts just from unauthenticated directory listing vulns on publicly facing web servers before!


  • HTTP_Screenshot (SpiderLabs)

This is an oldie but a goodie. If you can get past the dependencies to install successfully (PhantomJS, etc) then it’s worth it. This is an Nmap NSE script, so you can run it during host and service enumeration to get a separate image file (PNG) created for each web service, from the perspective of a browser. I always use this for penetration tests so I can quickly look through the web services to determine if there’s a web portal I want to target manually. This is especially useful when your target is a web development or web hosting company and there are a good deal of web services in the environment.

  • Burp Importer

I love this one. On my team we use Nessus as one of many tools in our arsenal, but really leverage it mostly for host and service discovery. The .nessus file type that you can export is really just an XML file underneath the hood. This Burp Suite Professional Extender plugin is really nice in that it imports all relevant web services by IP and Port into the Burp Sitemap via the Nessus output. It makes adding them to your Target and spidering/scanning really quick and convenient.

  • DirBuster / Burp Content Discovery

Because most web services detected will be by the IP address and port, the default web path may not be known. Instead, you may get a default IIS/Apache landing page or a 403 Forbidden response code. Even if you do get a valid page, it’s possible there are other “hidden” paths or files uploaded to the web directory that shouldn’t be accessible, so using a tool like Burp’s Content Discovery or OWASP’s DirBuster is a great way to find what others may have missed.

  • WPScan

This is true for any Content Management System (CMS), but Wordpress especially is a goldmine for security issues, typically due to a lack of patching in regards to libraries, themes, and plugins. WPScan is an excellent tool for quickly identifying the version and the vulnerable components as well as enumerating and brute forcing user accounts.

Round 2: Phishing

I never do phishing without doing some AppSec up front first. It’s come in handy more times than I care to count. Most AppSec vulnerabilities that are useful for phishing involve being able to host content on the target’s own environment so that URLs can be crafted to look like they originate from the legitimate domain. Here are the ones I’m specifically looking for:

  • Open Redirects

Open Redirect vulnerabilities (via GET requests) allow the attacker to craft a URL that originates from the target domain but redirects via a 302 response code to a third party domain of their choosing. This technique is used by attackers in the real-world often and for good reason, it’s very difficult for a user, even with security awareness training, to spot the fake request since they recognize the domain. This, and the techniques below, often sail right past any web content filters and spam filters as well. Attackers can even obfuscate the redirect parameters at the end of the URI by using URL encoding, making it that much more difficult to spot as a fake.

  • Unrestricted File Upload + Indirect Object Reference (IDOR)

During a penetration test for a large university, I leveraged a combination attack where the school had student printing services with an unrestricted file upload vulnerability. I was able to bypass the client-side content-type filters to upload an HTML file instead of a DOCX file. In addition to this, they had Indirect Object Reference issues and it was trivial for me to be able to locate and craft a URL to access my uploaded HTML file. Compounding the issue further was the fact that no authentication was required, so what I now had was my own site hosted by the .edu domain, which is difficult to spoof otherwise since .edu top level domains are off-limits to the general public. As you can imagine, it was easy from here to set up a fake login form that posted credentials to my own third party site and redirect the unknowing victim on to their post-authenticated resource.

  • Cross Site Scripting (XSS)

Cross Site Scripting vulnerabilities are yet another way to control the content hosted on the phishing recipient’s own domain. By injecting HTML into the page by means of XSS, it is possible to alter the content of forms. Additionally if the X-Frame-Options security header is missing in the web service’s configuration settings, it’s possible to create a full-frame iframe and completely redesign the vulnerable target site, hosting your own content. If this is stored or reflected XSS you can craft a URL to your page and email the link to your victim.

  • Remote File Include (RFI)

RFI vulnerabilities are ways to include, or reference, external resources. Sometimes this can be JavaScript, server-side scripting pages, or just a static HTML page. RFI is another example of potential content modification, making it possible to craft a URL originating from the legitimate victim’s domain but actually pulling content from an attacker-controlled server.

DING DING! And Our Winner Is…

Hopefully this blog serves to help those who don’t typically take an in-depth look at web applications during phishing or penetration testing activities. If you already do this, great! Keep it up! I likely missed some examples and vulnerabilities that can be used in this manner, so please let me know if you have something to add so we can all improve. 😃 Dynamic Application Security Testing can stand on it’s own as an excellent service, but it’s unique in that it can also serve as a teammate to these other services, much like Mickey is to Rocky. Until next time! (Cue Eye of the Tiger Music)


Curtis Brazzell

Written by

Passionate geek for Information/Cyber Security! I’m always learning and am happy to contribute anything I can share with the community. Follow me @ Twitter!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade