June 25, 2019

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

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)
  • 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..

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

June 06, 2019

Not Just a Vuln Scan - Are You Receiving/Providing Quality Security Assessments?


Having a diverse background in Information Security has given me what I think is a unique perspective on both the receiving end and the giving end of technical security assessments.  In sales support roles, I'm always trying to help understand and get to the bottom of what it is exactly that our customer is most in need of.  There's something really rewarding in being able to translate and traverse the middle ground between technical jargon and bridging the gap between sales and executive-level decision makers.  It may sound cliche to say, but I honest-to-goodness really have a passion for helping people find the most value in these assessments and to walk away with them being more secure than they were before engaging with our team.

Similarly, it really irks me to my core when I come across a statement of work or the results of a previous assessment and it was performed in a way that does not maximize the effectiveness of said assessment.  With so many technical service offerings available and different organizations providing these services, it's hard to fault the customer or even the sales person who may simply struggle to understand them fully.  Perhaps there's a limited budget available and services weren't properly prioritized.  This is why it's so important to have a technical resource available during the beginning phases of sales conversations, even though most of us in this field just like to focus on delivery.  Today, just about everyone offers a Penetration Test but testing methodologies are not always standardized and sadly, some aren't even a pentest by definition!  

In this blog I hope to lay out some ways in which as a customer you can help ensure you're getting a quality assessment.  If you're a technical resource, I also hope to help outline ways in which you can make sure you're offering the right assessment and delivering consistent, actionable results which are valuable to your customer.

Some Definitions

Since I mentioned penetration testing, let's go there.  A question I often get, as I imagine most of you readers do as well, is, "What is the difference between a penetration test and a vulnerability scan?".  Don't feel bad asking this if you don't know, because sadly, many sales and technical people offering theses services don't seem to know this either.  There's also red teaming.  It's important to know what you're getting for your money but even more critical when dealing with PCI, because a vulnerability scan won't fulfill the council's requirements and could leave you failing compliance.

I'm probably going to over-simplify this definition for many, but simply put, a vulnerability scan is a passive or active scan of hosts and services to identify vulnerabilities and their severity, impact, and risk to the organization.  There is a lot of value in a vulnerability scan, as it helps you proactively identify and resolve potential patching deficiencies and configuration issues before an attacker may.  It also compliments your patch management process to ensure patches aren't being missed.  However, this by itself, it not a pentest.

A traditional network penetration test (pentest) is the act of exploiting or validating these vulnerabilities with the intent to demonstrate the impact to the organization.  Other tools and techniques can be used to simulate what an attacker may do, going further than just a single scan.  It's worth noting that both vulnerability scans and penetration tests may or may not include web applications.  Some focus on web applications specifically, often referred to as a "Web Application Pentest" or an "Application Security Test".

Lastly, a red team is essentially a penetration test but with the intent of simulating an attacker targeting the environment directly.  This is often done in an opsec friendly way to "stay under the radar" and avoid detection from defensive teams and technologies.  There's also more reconnaissance up front since the scope and access to the environment isn't likely to be provided by the customer.


Now we should all know at a high level what the differences are between these services.  However, you'll see that not all pentests are created equal.  If you're looking at penetration testing quotes keep in mind that you're most likely not comparing apples to apples, so going with the most affordable doesn't necessarily mean it will satisfy all of your requirements.  Now, if you're looking to "check a box" to meet compliance regulatory requirements or to satisfy your customer requests, you may be okay with a basic "out of the box" assessment.  Keep in mind that there are firms (I've seen the service contracts) that offer a vulnerability assessment but call it a penetration test in order to offer competitive pricing, I can only assume.  If you come across one of them, please point them to this blog. 😉


Something I came across recently was an outsourced pentest that had already been sold.  It's not uncommon to find a limited scope, with the intent to do a sampling of assets in the environment for budget or time constraints.  I have my own opinion about sampling when it comes to penetration testing (don't do it!).  Essentially an attacker will often find the easiest path in, the weakest link.  If you miss it because you didn't look at everything at least once, you're not doing yourself any favors.  This particular SOW stated that about 5% of the environment would be tested every quarter, for a year.  This included vulnerability scans as well, with the same scope.  

I understand wanting to limit the cost, but in this situation it would be better to take that same investment and put it towards a vulnerability scan for the ENTIRE environment, then focus the penetration testing on critical assets and the highest severity findings from the vulnerability assessment.  If it can only be done twice a year for the pentest, that's better than four very limited tests.  The way this was set up, they'll never have a complete picture of their environment at any one point in time.  Had I been involved from the beginning or this was Pondurance offering the service, I would have made these suggestions to the customer in a pre-sales conversation.

Frequency of Testing

I just touched on it in the last paragraph, but the frequency of testing can play a role in the thoroughness and efficiency of an assessment.  It is commonly recommended to perform a penetration test about twice a year.  This is due to the dynamic nature of enterprise environments and the frequency of security vulnerabilities that are introduced into any system.  How much is too much though?  I'd rather see a comprehensive penetration test once a year than two or even four "budget" pentests.  Attackers are financially motivated and if targeting a specific organization, time is often not a constraint for them.  Consultants on the other hand, are.  A good penetration tester will make the best use of their time, manually digging and looking for unique opportunities to move laterally and compromise credentials and hosts along the way.

If you decide you do want frequent tests, make sure you're not being over-charged either.  The first assessment should have more time allocated to it with subsequent ones benefiting from familiarity and experience with the environment gained.

Maturity / Security Posture

Another common gotcha I see is when a customer or the sales person tries to put the proverbial cart before the horse.  You can't run before you can walk.. I'll spare you the rest. 😃  Sometimes I wonder what my own sales team thinks when I'm in a scoping meeting and I'm actively reducing the scope of our services.  Fortunately, my team at Pondurance is as passionate as I am about helping our customers so they've always been cool (at least in person!) about my stepping in and altering course.  Many customers bring this on themselves, assuming the best place to start in their security journey is to go all out and do a red team assessment.  

I often offer a lower cost but more effective first step, such as a security architecture review (gap analysis) or perhaps a vulnerability management program.  Similarly, we offer a penetration test with every vulnerability management program offering.  Many customers initially want the pentest first, followed by monthly external scans and quarterly internal scans.  I always push back on this and instead, suggest we do the pentest at the end of the assessment.  What value is there in an easy pentest, demonstrating the environment is full of holes?  It's like shooting fish in a barrel, an easy win for the tester.  Wouldn't there be so much more value in waiting a year while the customer receives their scan results and work on remediation throughout that time?  Then, when they feel they've done everything they can to protect themselves we test that defense by simulating a real-world attack.

Things to Look For

Pre-Engagement Red Flags

One of the earliest indicators when assessing a new partner for security assessments is the questionnaire.  This is the document, or form, that the sales representative uses to help scope the engagement appropriately.  This document should be pretty telling for how and where they put their emphasis on time.  While true that a number of IP addresses or URLs help provide a baseline estimate for determining how much time an assessment may take, there should be follow-up qualifying questions to gain more context around those.  How are those accessible?  Does a /24 subnet REALLY have all 254 IP addresses in use, or are you paying too much when there are just a handful of hosts within that?

Are they simply quoting you for everything you ask for or are they wanting to discuss what your end goals are with you in order to better serve your needs?  This also shouldn't be a meeting to throw more stuff at you, but rather a conversation about the bigger picture to ensure the right services can be offered.  This can result in a reduction in scope, as I mentioned above.  If it's right for the customer, it should be right for the firm.

Ask about testing methodologies and frameworks.  Does their testing include Manual testing?  Are they following a standard process such as the Penetration Testing Execution Standard (PTES)?  Is there a Quality Assurance component for both the technical work as well as the deliverable?  What does the deliverable look like?  Can you see a redacted version?  Are their reports actionable with clear recommendations and not just a regurgitation of all of the issues you'll be facing in your copy?

Lastly, and probably most obvious, is the Statement of Work (SOW).  Does this contract clearly define the testing process and expected deliverable formats?  Does it specify the project management component?  Exactly how much time is dedicated to manual testing vs automated scanning.  Are they charging time for tools to run?  Are compliance tests called out for their specific requirements?  Is retesting something you're expecting and is it a separate line item?  What are their data retention periods?  There have been some big security vendors in the news recently for breaches that resulted in sensitive client data being exposed.  *cough* Hacking Team *cough*

Engagement Red Flags

Once the engagement is sold and there's a kickoff meeting to discuss expectations around timing, the testing process, and delivery, do you discuss these things in detail?  Are the rules of engagement specifically called out and discussed in depth?  

Something I've found from my experience as a Systems Administrator and being on the receiving end of a penetration test, is that you may have certain expectations for findings.  For example, I was at an organization where we had certain service accounts we knew needed to be transitioned, as well as some unsupported operating systems we had scheduled to retire.  I specifically looked for these results on the penetration test report as a quick sanity check to make sure they were at least finding the low hanging fruit.

Ironically, as a tester I'm always concerned the client is doing the same to me, and they should!  It's a great way to check my work and it's a challenge to make sure I try to find everything I can.  No pentester can ever find everything, but again, the low hanging fruit should be discovered and exploited if possible.  I wonder how many of our customers have had honeypots and I just didn't know it. 😅  Although this could be seen as a waste of time, it's yet another way to measure the effectiveness of your red team.  I've also been pitted against a blue team SOC and blacklisting security devices, which made me really think carefully about how I was going to do my passive information gathering and fly under the radar.  Now we get into purple-team operations where we can test the effectiveness of both teams and use the results as a training opportunity for each!

Post-Engagement Red Flags for Future Consideration

It may be difficult to determine the quality of the test based on the results alone.  After all, the clients aren't typically as technical in the same areas as the company providing the testing services.  However, the quality of the report should be obvious.  Do they do a good job of breaking down the main issues in a prioritized, easy to understand executive summary?  Does the report also give enough technical detail so that the responding IT department can resolve the issues being addressed?  

Does their deliverable contain screenshots as evidence of the exploited vulnerabilities and are they effective in demonstrating the risk posed by them?  Are there other supporting data files from tool outputs, such as vulnerability scan dumps, tool state files, and raw stdout?  Are they willing to share a list of all of the tools that were used during the assessment?  Part of the value in the assessment may be the education of tools and processes which can be used in internal training.  A big part of what I do in Dynamic Application Security Assessments is to provide Burp Suite Professional project state files so that the developers can load the findings into their own tools and replay the payloads to verify that their findings were resolved on their own.  I've even had the sales team in some instances add in an ad-hoc training opportunity for an entire team, tacked on to the end of the review meetings.

Speaking of review meetings, this in my opinion, is the most valuable part of the engagement for the customer.  This should be offered a week or two after the results are provided, to allow time for the customer to digest and form questions.  Are they conducting these as personally as possible?  These should be done face to face, when feasible, and should be an open-floor presentation style to allow for healthy back-and-forth dialogue.  It's an opportunity to really utilize those advisory resources that the consultancy has to offer by asking questions and making sure everyone's on the same page in regards to remediation, etc.  Lastly, is the project closed immediately after the review meeting and the invoice is paid, or do they offer to answer lingering questions afterwards?  I always personally offer this, knowing there may not be time available in the budget to charge to because I see the value in helping customers who in all likelihood, won't get around to resolving the huge list of issues you dumped into their laps until after the project is finished.


This is by no means a comprehensive list of things to do and look for when shopping for or offering security services.  These are just a few things I see regularly and since I have a passion for making sure people get the most "bang for their buck", I wanted to share with the community as well.  I think we can all do a better job as the technical delivery and sales teams to meet our customer's needs, and I strongly believe developing that quality reputation goes a long way in the overall success of the business.  A lot of that comes down to communication up front, and not assuming our customers know what's best for themselves.  We need to listen to them if they want something specific, but they're also hiring us to be their trusted advisors.

Please share any other thoughts and ideas!  I'd love to hear how people are testing their testers.  😄

- Curtis Brazzell