When it comes to offensive security, engagements can be broadly broken up into two categories: Penetration testing and red teaming. Understanding the differences between the two is essential when attempting to verify the security of an application, network or organisation.

Penetration Testing

Penetration testing is often broken up into a set of assessment types. Be it an application assessment, internal or external network assessment or something more specific or esoteric. Penetration testing involves a security consultant performing both automated and manual analysis of a target, attempting to find as many vulnerabilities as possible. Penetration testing extends beyond automated vulnerability analysis, with the consultant building an understanding of the application or network throughout the course of the review and identifying specific vulnerabilities by hand.

A penetration test will assess the security of an application or network, usually in isolation from the rest of the organisation’s operating environment. For example, an internal network penetration test will assess the organisation’s network from the perspective of a malicious user on the network, such as a malicious staff member. The consultant will arrive on site, plug their laptop into the desktop network and go from there.

An internal network penetration test will ignore the required steps for an attacker to gain an initial network foothold, instead focusing on the exploits possible from a privileged position. The consultant will attempt to compromise network devices and gain administrative privileges in the environment. An internal network penetration test report will usually include findings concerning internally exposed services, missing patches, insufficient end user device hardening, passwords in documentation retrieved from file servers, gratuitous domain admin access, and so forth. This information can then be used to harden the internal network, but the report does not address the steps an attacker would need to take to gain internal network access in the first place.

An application review will provide information regarding the vulnerabilities within a specific application, and the consultant will generally perform testing from unauthenticated and authenticated attacker perspectives. The report findings usually include hardening issues, such as missing account lockouts and weak cookie security, along with application vulnerabilities, such as injection and cross-site scripting vulnerabilities. An application penetration test will uncover previously unknown vulnerabilities in most cases, but unless otherwise specified the application report will rarely detail issues regarding the application’s integration with the wider organisation. The application is reviewed in solidarity, and the resulting report may be used to harden the target application accordingly.

With the above assessments, you can see how penetration testing will often review only a single component in isolation. Penetration testing can be used to verify the security of the individual building blocks of an organisation, but often vulnerabilities and attack vectors will lurk in the details of how these blocks interact. Which brings us to…

Red Teaming

Red teaming can be considered ‘attacker emulation’. The assessment is usually loosely defined, with the security consultants being provided a target (e.g. a customer database or SCADA control plane) and the rules of engagement (stay out of the petrochemical plants, testing must be in business hours, etc). The consultant attempts to achieve the end goal and avoid detection. Red teaming is a mechanism designed to give an organisation an understanding of how their security and response measures stack up against a real-world threat. Red team engagements combine phishing attacks, social engineering, on-site attacks as well as attacks against an organisation’s IT infrastructure to achieve the set goals.

The resulting report will read more like a narrative as opposed to a list of findings, though both are provided. The consultants detail the steps taken to compromise the organisation and achieve the end goal, detailing reconnaissance steps, initial compromise, lateral movement and finally, exfiltration.

The consultants use similar techniques as the attackers an organisation would be defending against, which provides a realistic view of how the organisation may be compromised.

So… what do we need?

Selecting the right engagement depends on your end goals. If a new application is being deployed, then it’s generally not in the project’s scope to consider phishing attacks or Jack Bauer showing up to your head office. Penetration testing the application will assure that the new site is hardened sufficiently and will identify any vulnerabilities that may expose the application or its users to compromise.

If the aim is to assess the organisation’s overall security, then testing each network and application in isolation isn’t going to be viable, and may fail to exercise practical attack vectors such as phishing and other social engineering attacks. Not to mention the excessive cost with this approach. A red-team engagement would be far more suitable, and would identify the immediate, real-world issues affecting an organisation.