Patrick Wayand

Patrick has been in the IT & Security industry since 2013 servicing local governments, fintech, healthcare, biotech, manufacturing, agricultural, and non-profit sectors. He is a Defcon attendee and regular BSides attendee, and believes in contributing to cybersecurity education efforts. As a member of the USF White Hatters Computer Security Club he served as a USF CyberCamp instructor as well as a lock picking village demonstrator at the USF engineering expo. When not conducting RedTeam engagements at NetSPI, Patrick likes to develop tools, scripts, and documentation focused on efficiency and productivity.
More by Patrick Wayand
WP_Query Object
(
    [query] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "102"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "102"
                            [compare] => LIKE
                        )

                )

        )

    [query_vars] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "102"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "102"
                            [compare] => LIKE
                        )

                )

            [error] => 
            [m] => 
            [p] => 0
            [post_parent] => 
            [subpost] => 
            [subpost_id] => 
            [attachment] => 
            [attachment_id] => 0
            [name] => 
            [pagename] => 
            [page_id] => 0
            [second] => 
            [minute] => 
            [hour] => 
            [day] => 0
            [monthnum] => 0
            [year] => 0
            [w] => 0
            [category_name] => 
            [tag] => 
            [cat] => 
            [tag_id] => 
            [author] => 
            [author_name] => 
            [feed] => 
            [tb] => 
            [paged] => 0
            [meta_key] => 
            [meta_value] => 
            [preview] => 
            [s] => 
            [sentence] => 
            [title] => 
            [fields] => 
            [menu_order] => 
            [embed] => 
            [category__in] => Array
                (
                )

            [category__not_in] => Array
                (
                )

            [category__and] => Array
                (
                )

            [post__in] => Array
                (
                )

            [post__not_in] => Array
                (
                )

            [post_name__in] => Array
                (
                )

            [tag__in] => Array
                (
                )

            [tag__not_in] => Array
                (
                )

            [tag__and] => Array
                (
                )

            [tag_slug__in] => Array
                (
                )

            [tag_slug__and] => Array
                (
                )

            [post_parent__in] => Array
                (
                )

            [post_parent__not_in] => Array
                (
                )

            [author__in] => Array
                (
                )

            [author__not_in] => Array
                (
                )

            [search_columns] => Array
                (
                )

            [ignore_sticky_posts] => 
            [suppress_filters] => 
            [cache_results] => 1
            [update_post_term_cache] => 1
            [update_menu_item_cache] => 
            [lazy_load_term_meta] => 1
            [update_post_meta_cache] => 1
            [nopaging] => 1
            [comments_per_page] => 50
            [no_found_rows] => 
            [order] => DESC
        )

    [tax_query] => WP_Tax_Query Object
        (
            [queries] => Array
                (
                )

            [relation] => AND
            [table_aliases:protected] => Array
                (
                )

            [queried_terms] => Array
                (
                )

            [primary_table] => wp_posts
            [primary_id_column] => ID
        )

    [meta_query] => WP_Meta_Query Object
        (
            [queries] => Array
                (
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "102"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "102"
                            [compare] => LIKE
                        )

                    [relation] => OR
                )

            [relation] => OR
            [meta_table] => wp_postmeta
            [meta_id_column] => post_id
            [primary_table] => wp_posts
            [primary_id_column] => ID
            [table_aliases:protected] => Array
                (
                    [0] => wp_postmeta
                )

            [clauses:protected] => Array
                (
                    [wp_postmeta] => Array
                        (
                            [key] => new_authors
                            [value] => "102"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                    [wp_postmeta-1] => Array
                        (
                            [key] => new_presenters
                            [value] => "102"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                )

            [has_or_relation:protected] => 1
        )

    [date_query] => 
    [request] => 
					SELECT   wp_posts.ID
					FROM wp_posts  INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
					WHERE 1=1  AND ( 
  ( wp_postmeta.meta_key = 'new_authors' AND wp_postmeta.meta_value LIKE '{fcd5dcecef4ad42ccd7b5ce0a6af0f8b925945ed86ca312053bbfa727d36871f}\"102\"{fcd5dcecef4ad42ccd7b5ce0a6af0f8b925945ed86ca312053bbfa727d36871f}' ) 
  OR 
  ( wp_postmeta.meta_key = 'new_presenters' AND wp_postmeta.meta_value LIKE '{fcd5dcecef4ad42ccd7b5ce0a6af0f8b925945ed86ca312053bbfa727d36871f}\"102\"{fcd5dcecef4ad42ccd7b5ce0a6af0f8b925945ed86ca312053bbfa727d36871f}' )
) AND wp_posts.post_type IN ('post', 'webinars') AND ((wp_posts.post_status = 'publish'))
					GROUP BY wp_posts.ID
					ORDER BY wp_posts.post_date DESC
					
				
    [posts] => Array
        (
            [0] => WP_Post Object
                (
                    [ID] => 25637
                    [post_author] => 102
                    [post_date] => 2021-06-22 07:00:00
                    [post_date_gmt] => 2021-06-22 12:00:00
                    [post_content] => 

A critical component of an external network penetration test or web application penetration test is to exclude pentester IP addresses from being blocked on the organization’s Intrusion Prevention System (IPS) and Web Application Firewall (WAF) systems. When asked to do this, it is often met with hesitancy. Common concerns I have heard include: 

  • “The findings won’t accurately represent the risks of our attack surface.”
  • “Are we allowing others access too? And will the pentesters reach our internal network?”
  • “If we are paying for a pentest, why should we need to do this additional work to make these temporary configuration changes?”
  • “We are concerned with the efficacy of our IPS/WAF systems and want this to be tested too.”

If pentests aim to test from the perspective of a real threat actor, why would a penetration testing company ask to Allow List their IPs when an attacker would not have the same access? 

It's true that a pentest simulates threat actors, but its core purpose is to identify all the security gaps that exist in the environment being tested. By nature, a tester cannot truly simulate an adversary because adversaries have unlimited time, while pentesters are typically limited to a few days or weeks. Penetration tests have to bridge the gap and emulate rather than simulate a real attacker – and removing the hurdle of bypassing the IPS/WAF is one critical way to do this. 

IPS/WAF can be bypassed using publicly available tools.

IPS/WAFs are great for protecting against the bots and scanners constantly bombarding your external attack surface, but there are many well-known ways to bypass them using publicly available tools and resources. The documentation for these systems is often found online and can be quite detailed, revealing the sequence of events or probes that typically cause them to take defensive action. Attackers with time can learn how to subvert these technologies by utilizing various tools, proxies, and techniques (read: Dark ReadingOWASPSANSBlack Hat). 

Further, intrusion detection and prevention systems rely on signatures. Oftentimes, these signatures are publicly listed and can be easily thwarted. It is important to remember that, during a web app pentest or external network pentest, the goal is not to test your IPS provider, it is to test your attack surface. 

When trying to conduct pentesting under strict time constraints, it starts to make sense why a pentester would want their IP address to not get blocked by rules or signatures. Given a sophisticated attacker has the time and the ability to bypass IPS/WAF implementations, the philosophy for the intents and purposes of offensive security becomes: (attacker + time + IPS/WAF) = (tester - time - IPS/WAF)

It is unrealistic to expect a pentester to accomplish more in days than a black hat hacker group would in months, or thousands of internet bots with unlimited time. Allow listing is a counterintuitive, but necessary, balancing act. Therefore, the value of a pentest should not be measured by its ability to simulate an adversary, but by the quality of findings it uncovers that an adversary could exploit. 

How allow listing/excluding works.

Allow listing, or excluding, IPs on an IPS/WAF is a configuration change that informs these security solutions to continue alerting, identifying, and blocking malicious traffic as it normally would, except for the traffic coming from the testers IP addresses. Important to note: While pentester IPs should not be blocked, logging and alerting functions should continue as security assessors will consider an organizations visibility into events regarding their attack surface. Most major security vendors allow for this type of configuration. If using a next-generation firewall then it is a change made in the WAF or IPS settings, not on the firewall itself. 

It is not necessary to make changes that allow a tester internal network access as these tests should be conducted only on the public facing, or external attack surface. Allow listing/exclusion is only in place for the duration of the penetration testing and removed immediately after. Source IP addresses that are not associated with pentesters will be treated as they normally would. 

If you want to specifically test your WAF, intrusion detection systems (IDS), or intrusion prevention systems (IPS), a WAF or firewall bypass test, red team operation, or black box assessment may be more appropriate.

The benefits of allow listing/excluding your penetration testers.

Allow listing comes with its own challenges, including immense coordination and alignment with all stakeholders. But its benefits outweigh the challenges. 

When a pentester’s IP addresses are allow listed, more findings can be uncovered in the time allotted, resulting in more fixes, less overall risk, and ultimately greater ROI from the resources allocated to testing. Key benefits include:

  1. More true positive findings
  2. Shorter testing timeframe
  3. Correlate alerts with testers to avoid time wasted triaging 
  4. More accurate results and less false positives

Ultimately, it’s up to security leaders to decide what they want from their penetration test. If breadth and depth, start making moves to allow list IPs. The bottom line is that you'll get a better return on your penetration testing budget if you enable your pentesters in this way. For answers to some of the most frequently asked questions regarding allow listing IPs during web app pentesting or external network pentesting, continue reading.

Frequently asked questions about allow listing IP addresses during penetration testing:

I get signature updates every day, shouldn’t I be protected?

While this is a best practice, signatures are only as good as the logic that lies within them. Because a signature is intended to detect a new technique, it does not mean that it is guaranteed. There can be different variations of the technique, the signature may not be comprehensive or work properly, there may be too many false positives and the signature gets turned off by the IPS/WAF administrator, among other reasons.

Will allow listing the tester make us vulnerable?

When done correctly, only traffic coming from the testers supplied IP addresses will be subject to not being blocked by that IPS/WAF. Though, the pentester’s traffic should still generate alerts if it is found to be suspicious. The IPS/WAF will still act as it normally would on all other traffic.

What activities will not allow listing a tester affect?

Any active information gathering techniques as well as brute forcing, directory enumeration, unencrypted exploits, and similar activities.

What is the difference between a pentest versus a red team engagement?

A pentest prioritizes issue discovery while a red team engagement is meant to more closely simulate a real threat actor. A red team engagement typically takes longer and does not require allow listing. A red team engagement will take the path of least resistance during an engagement and report on high severity issues that allow compromise, but there will not be mass scanning and issue discovery as there would in a pentest. Often, red team engagements are leveraged by organizations with a more mature security posture.

Can we test the current configuration of our IPS/WAF too?

Yes, any reputable pentest provider should allow for this. Though, it is important to first understand the third-party testing that IPS/WAF vendors undergo. Variations in implementations of IPS/WAF products do exist across different environments, and it can still be valuable to test against the current configuration or implementation. Solutions to this include starting with allow listing on and turning it off near the end to see if findings can still be replicated, turning allow listing off at the beginning and only turning it on if the testers are not making any significant or valuable progress, or contracting an additional engagement with the testing provider to specifically test the IPS/WAF configuration. Conducting a red team engagement can also be valuable for those with a more mature security posture. 

Our MSSP is telling us that allow listing pentester IPs is not possible, what can we do?

This is unlikely. If they will not allow for allow listing, you may want to extend the time scope of the engagement to ensure you are getting quality results. 

Concerned about your organizations cybersecurity? Work with NetSPI's expert pentesters!
[post_title] => To Add Value to Your Penetration Testing, Allow List Source IPs [post_excerpt] => Learn how to get more out of penetration testing budget by allow listing pentester IP addresses. [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => allow-list-ip-penetration-testing [to_ping] => [pinged] => [post_modified] => 2022-12-16 10:52:01 [post_modified_gmt] => 2022-12-16 16:52:01 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=25637 [menu_order] => 392 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 1 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 25637 [post_author] => 102 [post_date] => 2021-06-22 07:00:00 [post_date_gmt] => 2021-06-22 12:00:00 [post_content] =>

A critical component of an external network penetration test or web application penetration test is to exclude pentester IP addresses from being blocked on the organization’s Intrusion Prevention System (IPS) and Web Application Firewall (WAF) systems. When asked to do this, it is often met with hesitancy. Common concerns I have heard include: 

  • “The findings won’t accurately represent the risks of our attack surface.”
  • “Are we allowing others access too? And will the pentesters reach our internal network?”
  • “If we are paying for a pentest, why should we need to do this additional work to make these temporary configuration changes?”
  • “We are concerned with the efficacy of our IPS/WAF systems and want this to be tested too.”

If pentests aim to test from the perspective of a real threat actor, why would a penetration testing company ask to Allow List their IPs when an attacker would not have the same access? 

It's true that a pentest simulates threat actors, but its core purpose is to identify all the security gaps that exist in the environment being tested. By nature, a tester cannot truly simulate an adversary because adversaries have unlimited time, while pentesters are typically limited to a few days or weeks. Penetration tests have to bridge the gap and emulate rather than simulate a real attacker – and removing the hurdle of bypassing the IPS/WAF is one critical way to do this. 

IPS/WAF can be bypassed using publicly available tools.

IPS/WAFs are great for protecting against the bots and scanners constantly bombarding your external attack surface, but there are many well-known ways to bypass them using publicly available tools and resources. The documentation for these systems is often found online and can be quite detailed, revealing the sequence of events or probes that typically cause them to take defensive action. Attackers with time can learn how to subvert these technologies by utilizing various tools, proxies, and techniques (read: Dark ReadingOWASPSANSBlack Hat). 

Further, intrusion detection and prevention systems rely on signatures. Oftentimes, these signatures are publicly listed and can be easily thwarted. It is important to remember that, during a web app pentest or external network pentest, the goal is not to test your IPS provider, it is to test your attack surface. 

When trying to conduct pentesting under strict time constraints, it starts to make sense why a pentester would want their IP address to not get blocked by rules or signatures. Given a sophisticated attacker has the time and the ability to bypass IPS/WAF implementations, the philosophy for the intents and purposes of offensive security becomes: (attacker + time + IPS/WAF) = (tester - time - IPS/WAF)

It is unrealistic to expect a pentester to accomplish more in days than a black hat hacker group would in months, or thousands of internet bots with unlimited time. Allow listing is a counterintuitive, but necessary, balancing act. Therefore, the value of a pentest should not be measured by its ability to simulate an adversary, but by the quality of findings it uncovers that an adversary could exploit. 

How allow listing/excluding works.

Allow listing, or excluding, IPs on an IPS/WAF is a configuration change that informs these security solutions to continue alerting, identifying, and blocking malicious traffic as it normally would, except for the traffic coming from the testers IP addresses. Important to note: While pentester IPs should not be blocked, logging and alerting functions should continue as security assessors will consider an organizations visibility into events regarding their attack surface. Most major security vendors allow for this type of configuration. If using a next-generation firewall then it is a change made in the WAF or IPS settings, not on the firewall itself. 

It is not necessary to make changes that allow a tester internal network access as these tests should be conducted only on the public facing, or external attack surface. Allow listing/exclusion is only in place for the duration of the penetration testing and removed immediately after. Source IP addresses that are not associated with pentesters will be treated as they normally would. 

If you want to specifically test your WAF, intrusion detection systems (IDS), or intrusion prevention systems (IPS), a WAF or firewall bypass test, red team operation, or black box assessment may be more appropriate.

The benefits of allow listing/excluding your penetration testers.

Allow listing comes with its own challenges, including immense coordination and alignment with all stakeholders. But its benefits outweigh the challenges. 

When a pentester’s IP addresses are allow listed, more findings can be uncovered in the time allotted, resulting in more fixes, less overall risk, and ultimately greater ROI from the resources allocated to testing. Key benefits include:

  1. More true positive findings
  2. Shorter testing timeframe
  3. Correlate alerts with testers to avoid time wasted triaging 
  4. More accurate results and less false positives

Ultimately, it’s up to security leaders to decide what they want from their penetration test. If breadth and depth, start making moves to allow list IPs. The bottom line is that you'll get a better return on your penetration testing budget if you enable your pentesters in this way. For answers to some of the most frequently asked questions regarding allow listing IPs during web app pentesting or external network pentesting, continue reading.

Frequently asked questions about allow listing IP addresses during penetration testing:

I get signature updates every day, shouldn’t I be protected?

While this is a best practice, signatures are only as good as the logic that lies within them. Because a signature is intended to detect a new technique, it does not mean that it is guaranteed. There can be different variations of the technique, the signature may not be comprehensive or work properly, there may be too many false positives and the signature gets turned off by the IPS/WAF administrator, among other reasons.

Will allow listing the tester make us vulnerable?

When done correctly, only traffic coming from the testers supplied IP addresses will be subject to not being blocked by that IPS/WAF. Though, the pentester’s traffic should still generate alerts if it is found to be suspicious. The IPS/WAF will still act as it normally would on all other traffic.

What activities will not allow listing a tester affect?

Any active information gathering techniques as well as brute forcing, directory enumeration, unencrypted exploits, and similar activities.

What is the difference between a pentest versus a red team engagement?

A pentest prioritizes issue discovery while a red team engagement is meant to more closely simulate a real threat actor. A red team engagement typically takes longer and does not require allow listing. A red team engagement will take the path of least resistance during an engagement and report on high severity issues that allow compromise, but there will not be mass scanning and issue discovery as there would in a pentest. Often, red team engagements are leveraged by organizations with a more mature security posture.

Can we test the current configuration of our IPS/WAF too?

Yes, any reputable pentest provider should allow for this. Though, it is important to first understand the third-party testing that IPS/WAF vendors undergo. Variations in implementations of IPS/WAF products do exist across different environments, and it can still be valuable to test against the current configuration or implementation. Solutions to this include starting with allow listing on and turning it off near the end to see if findings can still be replicated, turning allow listing off at the beginning and only turning it on if the testers are not making any significant or valuable progress, or contracting an additional engagement with the testing provider to specifically test the IPS/WAF configuration. Conducting a red team engagement can also be valuable for those with a more mature security posture. 

Our MSSP is telling us that allow listing pentester IPs is not possible, what can we do?

This is unlikely. If they will not allow for allow listing, you may want to extend the time scope of the engagement to ensure you are getting quality results. 

Concerned about your organizations cybersecurity? Work with NetSPI's expert pentesters!
[post_title] => To Add Value to Your Penetration Testing, Allow List Source IPs [post_excerpt] => Learn how to get more out of penetration testing budget by allow listing pentester IP addresses. [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => allow-list-ip-penetration-testing [to_ping] => [pinged] => [post_modified] => 2022-12-16 10:52:01 [post_modified_gmt] => 2022-12-16 16:52:01 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=25637 [menu_order] => 392 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 1 [max_num_pages] => 0 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 404774c7d2cdf292d4989f8d4f74ad32 [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [allow_query_attachment_by_filename:protected] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X