White Box Penetration Testing

White Box Penetration Testing

There are two main ways to conduct penetration testing: black box and white box.  Both provide different approaches to the methodology and require different levels of interaction from the client. White box can often return more findings while improving the tester’s efficiency.

We’ve already covered black box testing in the first part of this two-part series. If you missed the first post of black box testing, you can find it here.

If you recall from the first part of this series, a pen-test is a simulation of how an attacker would attack your product or infrastructure, with the end goal of reducing the risk of cyber threats by following the recommendations you get with the pen-test’s report.

You’ll also recall that there are two main methods of pen-testing. Black box has no source code, configurations, documentation, nor access to the development team. On the other hand, white box testing provides some or all of these aids to speed up the testing and give the tester’s a one-up on how actual attackers would see your system.

Each piece of additional information we as testers get gives us a one up on attackers; this saves us time and provides better value for money.

Source code is invaluable when conducting a pen-test. It will often lead the investigation to areas of interest quicker, can show dangerous test cases without having to test them blindly, and reveal dangerous and insecure functionality that would otherwise be hidden from us.

Many things from SQL injection to insecure deserialization can stand out as vulnerabilities from reviewing the source code but can seem secure from a black box perspective. Hidden functionality or high attack complexity can make these vulnerabilities very hard to find black box, and almost impossible to exploit blindly – especially on the limited time frame of a pen-test.

Similarly, documentation can help us understand complex backend logic that might be used insecurely without us having to analyse it from scratch, which again, saves us time and you money.

With the emergence of cloud-native applications, configurations are more important than ever. Not only of how your applications and infrastructure are configured, but also the account used to manage your cloud infrastructure.

Since access to an organisations cloud account can mean a complete cyber compromise of the organisation – and serious legal, financial, and reputational consequences – it’s important to also verify that the cloud infrastructure is locked down appropriately.

Because of the head-start white box testing provides the testers, it provides a higher level of security assurance to the product or infrastructure being tested. This can be required for mission-critical applications, or where security is a high priority – for example, an application handling sensitive medical data or a bank’s backend server applications.

All this additional information has to come from somewhere though, so the lead up to a white box penetration test is more involved from the client. The manager organising a white box pen-test has to gather the source code and any extra information to send us, in addition to getting us any credentials we may need for an app and whitelisting us in any network or web application firewalls that may be in place. This increases the lead-in time to the pen-test, and the effort required to complete the engagement.

White box penetration testing is pen-testing with source code, allowing the testers to “see behind the curtain.” It enables testing to be performed faster, can find otherwise hidden vulnerabilities, and provide an overall higher level of security assurance. While it requires more work from the organisation receiving the pen-test, the better value for money and more thorough testing often outweighs the additional inconvenience. Red Cursor offers both white box and black box pen-testing; you can view our pen-testing services on our penetration testing services page.

More Blogs

May 31, 2021

Upgrading from AppLocker to Windows Defender Application Control (WDAC)

Windows Defender Application Control (WDAC), formerly known as Device Guard, is a Microsoft Windows secure feature that restricts executable code, including scripts run by enlightened Windows script hosts, to those that conform to the device code integrity policy. WDAC prevents the execution, loading and running of unwanted or malicious code, drivers and scripts. WDAC also… Continue reading Upgrading from AppLocker to Windows Defender Application Control (WDAC)

Read More
cyber security companies | penetration testing | managed security service provider | cyber security consultant
June 22, 2021

Bypassing LSA Protection (aka Protected Process Light) without Mimikatz on Windows 10

Starting with Windows 8.1 (and Server 2012 R2) Microsoft introduced a feature termed LSA Protection. This feature is based on the Protected Process Light (PPL) technology which is a defense-in-depth security feature that is designed to “prevent non-administrative non-PPL processes from accessing or tampering with code and data in a PPL process via open process… Continue reading Bypassing LSA Protection (aka Protected Process Light) without Mimikatz on Windows 10

Read More
cyber security companies | penetration testing | managed security service provider | cyber security consultant
June 7, 2020

Using Zeek to detect exploitation of Citrix CVE-2019-19781

Using the tool Zeek, formally known as bro, is a high-level packet analysis program. It originally began development in the 1990s and has a long history. It does not directly intercept or modify traffic, rather it passively observes it and creates high-level network logs. It can be used in conjunction with a SIEM to allow… Continue reading Using Zeek to detect exploitation of Citrix CVE-2019-19781

Read More