PENETRATION TEST

The External Network pentest covers the underlying server infrastructure for a website (or other target), and not the applications themselves that work on the server. It's a test for the network layer, simulating what an attacker can do to the target's external network perimeter. So for instance, if it was a payment gateway running on an Apache server behind a Firewall, the External Network Pentest would test the firewall and the Apache Server, and not touch the website contents. If we want to test the website (web application) itself, then that would be a Web Application pentest. If we want to test both, it would be an External Network Pentest + Web Application Pentest. Targets for this type of test would be External IP addresses (ex: 207.154.195.119)

The Internal Network pentest is, like the External Network pentest, held on the Network layer. The approach is similar to an External Network pentest, in that it deals with IPs and services, but conducted against targets in an INTERNAL Network, which is accessed from the outside through a VPN provided to Cerebral by the client. Targets for this type of test can be Internal IP addresses (ex:192.168.10.10) or Internal IP address ranges (Ex:10.10.10.1/24)

Web Application pentests are focused directly on Web Application structures that reside on web servers. Testing is conducted on the Application Layer, and the test deals with targets like Wordpress, APIs, JavaScript & PHP applications and so on. Targets for this type of test would look like https://www.example.com, https://www.example.com/payment/cards/*, http://192.168.10.20/users/*, and so on

Mobile application pentests are conducted against mobile application packages like APKs and IPAs. Clients send Cerebral's pentest team a compiled copy of the latest version of the application package they have available. Targets for this type of test would be APK or IPA files.

Wi-Fi Network pentests deal with cracking the security protecting password-protected wireless networks on the protocol layer. The goal of the test is to break into the network as an outside attacker, without any credentials supplied, by physically capturing radio signals containing wireless data packets from the air. Due to the physical nature of this type of test, Wireless penetration tests cannot be conducted remotely, and pentester needs to be physically present in the clients target premises. Targets do not need to be specified for this type of test.

Social engineering tests focus on the security awareness present in a company's target personnel. Pentesters first collect information on a target company, then prepare and launch convincing phishing campaigns against each individual within the target scope of the test. By utilizing advanced phishing techniques, simulated malicious content is e-mailed to targets, to see whether any of the target personnel take the bait, however obviously none of the simulated malicious payloads actually harm or exploit their systems. Targets for this type of test would be a list of e-mail addresses that the client wants this test to be performed against.

Cloud Penetration Testing is an authorised simulated cyber-attack against a system that is hosted on a Cloud provider, e.g. Amazon’s AWS or Microsoft’s Azure. The main goal of a cloud penetration test is to find the weaknesses and strengths of a system, so that its security posture can be accurately assessed. Cloud Penetration Testing involves a mixture of external and internal penetration testing techniques to examine the external posture of the organisation. Examples of vulnerabilities determined by this type of active testing can include unprotected storage blobs and S3 buckets, servers with management ports open to the internet and poor egress controls.

Segmentation testing is not a penetration test in the classic definiton of the term. It is focused more on checking to see if certain parts of a network infrastructure are accessible from other parts where they're supposed by design to be unaccessible. However, the methods and knowledge used for this type of test are from the same family of network enumeration techniques used in penetration tests, and therefore segmentation testing is usually performed by penetration testers.

Segmentation testing is required by a variety of compliance standards commonly used.

To conduct testing, the client needs to provide Cerebral Sec with VPN or SSH connections into both inside and outside any senstive closed-networks for which the test is to be conducted. Access from inside the networks to the outside and from outside these connections to the inside are attempted using network enumeration methods. A separate VPN connection for each network to be tested is required.

Targets for this type of test would look like "192.168.10.1/28

Running a penetration test on your production environment has a sure advantage: being conducted under actual conditions of use of your website/ web application/ API/… with the last developments set up. However, since penetration testing methods can sometimes be disruptive and unexpected on the target systems, testing the production environment can in some rare cases interfere with the normal running of your business.

At Cerebral, we take many measures to make sure testing is not harsh so as to not cause such occurances, however due to the nature of penetration testing, we also like to be open in that we cannot guarantee 100% problem-free operation all of the time.

To avoid any potential risks of disruption due to pentesting, it is possible to realise penetration tests in an iso-production environment, an absolutely identical environment to the production environment. Doing a penetration test on the pre-production environment is also interesting, as it is very similar to the final environment. Tests will not touch services used by your users/customers. This is particularly appropriate for critical infrastructure, for which the data or system integrity is crucial.

Virtualized container environments are not a third alternative to Production and Staging environments as they can be present in both, but their structure is different enough to warrant letting the penetration testing team know beforehand in order to map out attack plans to the targets accordingly.

Network Diagrams are visual representations of any given network infrastructure.

Having access to source code of application(s) in the scope can give the pentest team increased visibility into how the applications process data that gets put in.

For the APIs in the scope, we may need some documentation that lists the target endpoints along with sample request/response pairs. Ideally something like a JSON swagger file or a collection of cURL requests etc. would be perfect.

Note that we only need this if the API targets in the scope have any endpoints / functionalities that are not fully usable over the graphical user interface of the web target in the scope. If we can call all the API functionality through the site UI, then no documentation will be needed.

While we browse through the entire functionality offered by every application in scope, if there are “invisible” endpoints of the API that are not functional over the graphical user interface of the applications, but their existence simply have to be known beforehand by a user, without the visibility offered by documentation, these may go undiscovered. We do run some discovery scans on the applications on wordlists of possible endpoints as part of the pentests, however these can only reveal “commonly found” endpoint names, and only if the APIs behave in a way that make such enumeration possible. So having documentation on hand is the best way to ensure the entire application surface gets tested sufficiently.

Having access to reports of previous pentests (not performed by Cerebral Security) can provide extra visibility for the pentest team to better understand weaknesses of the target infrastructure or re-check vulnerabilties previously found to make sure they have been mitigated.

Having access to the software architecture details can help the pentest team gain further insight into the targets and how they could be exploited.

Having access to the list of technologies used in the targets can help the pentest team save time in enumerations and avoid some false positives.

If the target scope has any payment functionalities to be tested that accept Credit Cards, the client is advised to provide Cerebral's pentest team a minimum of one "dummy" credit card to be used for testing of these payment functions. Dummy credit cards are special credit cards defined in the system by the developers for testing purposes, where any transaction performed using information of these cards simulates an actual transaction going through, without any real financial actions taking place. As certain security bypass techniques can require payment requests to be repeated many times, or edited to test certain attack vectors such as injections, it is important to make sure the pentest team can do so without worrying about generating actual money transfers during testing.

If the target scope has any payment functionalities to be tested that accept crpytocurrency, the client is advised to provide Cerebral's pentest team a minimum of one "dummy" cryptocurrency wallet to be used for testing of these payment functions. Dummy cryptocurrency wallets are special digital wallets defined in the system by the developers for testing purposes, where any transaction performed using information of these wallets simulates an actual transaction going through, without any real financial actions taking place. As certain security bypass techniques can require payment requests to be repeated many times, or edited to test certain attack vectors such as injections, it is important to make sure the pentest team can do so without worrying about generating actual cryptocurrency transfers during testing.

If the target scope has any payment functionalities to be tested that accepts payments from PayPal, the client is advised to provide Cerebral's pentest team a minimum of one "dummy" PayPal account to be used for testing of these payment functions. Dummy accounts are special accounts defined in the system by the developers for testing purposes, where any transaction performed using information of these accounts simulates an actual transaction going through, without any real financial actions taking place. As certain security bypass techniques can require payment requests to be repeated many times, or edited to test certain attack vectors such as injections, it is important to make sure the pentest team can do so without worrying about generating actual money transfers during testing.

For Internal Network penetration tests, it is essential that the pentest team is provided access into every target segment of an internal network via a VPN connection provided by the customer. The connection needs to be placed in a location on the network where the pentester's connection can reach all of the target machines within the tests scope. VPN connections are also required to carry out Segmentation testing. VPNs should provide access to both inside the CDE (Cardholder Data Environment), and outside the CDE, so that access can be checked from both ends. If the CDE spans multiple subnets that are segmented from each other, a VPN connection will be needed for each segment.

For tests where the rules of engagement do NOT specify a Black Box pentest, it may be necessary to whitelist Cerebral's testing IP addresses in the customers external perimeter configuration. During Grey Box and especially White Box tests, connections getting dropped by defenses elongate the testing process considerably. If IP whitelisting is marked, the pentest team will get in touch with the client after this form is returned to relay IP addresses to whitelist for their test.

SSH is not ideal for Internal Network pentests or segmentation tests as a replacement for VPN connections, but in certain situations it may be the only chance to provide access. Please bear in mind this introduces some major complications to the testing process, and will result in the testing process being elongated by changing margins, resulting in your project becoming longer to deliver, and the pricing quoted accordingly.

For Grey or White Box Internal Network Pentests taking place in an Active Directory environment, testing requires that the customer provide the pentest team at least one valid Active Director user to be used for interacting with the domain environment. The account provided is recommended to be of similar privileges as a low-level user in the customers organization, for example a new employee in the organization, or someone else with the bare minimum access rights to be able to interact with the AD, but without elevated privileges, to see what can and cannot be accessed from this starting position. Users provided should be in the domain users group.

For Grey or White Box Web Application Penetration Tests, if the testing team are for whatever reason unable by design to create their own testing accounts to use for pentesting, it is required for the customer to supply valid testing accounts. When providing accounts for web applications, it is important that the testing team is provided TWO accounts of each USER ROLE that exists in the target applications design. So for instance, for a web application where there are the user levels of: "customer", "merchant", and "moderator", two of each of these user roles, totaling a number of at least 6 accounts would be needed. This is so that testing can uncover not only vertical permission bypasses (bypassing of functionality usage restrictions between account types), but also horizontal bypasses (a malicious user performing actions relegated to another user of the same user type). If testers can register their own accounts during the test for each of the user roles that exist, customer does not need to provide any accounts.

For Grey or White Box Network Penetration Tests, sometimes virtualized container systems will also have their own account management systems. Examples of these would be Docker accounts or Kubernetes accounts. These do not exist within web applications, but within the container environment itself. For testing of malicious usage of accounts within the container environment, testers will need to be supplied a minimum of ONE user for the container environment, to see what information can be gathered without permission from these infrastructures using the account provided.