Offensive Security is about thinking like an attacker to find weaknesses before real hackers do. The opposite, defensive security, is about keeping hackers out and acting when it goes wrong.

Two people work at the same bank. Read what each is doing:

Sarah TESTING LOGINS

Tries logging into the bank's website using common passwords on a test account, to see whether it accepts weak ones.

Mike ADDING A FIREWALL RULE

Adds a firewall rule that prevents suspicious login attempts on their systems.

This room uses a virtual desktop to simulate a real system. Press the green "View Site" button below to get started.

A fake banking application called FakeBank will launch. When the lab loads, you'll see the banking application running in your browser on the right, showing Mrs G. Benjamin's banking account.

Now we will find a weakness in the FakeBank website. One common thing Hackers look for on a website is pages that are not linked. Hackers are interested in these hidden pages because they can often lead to sensitive pages or information that the organisation did not intend for us to see.

We can use popular cyber security tooling to find these pages by using common words and phrases, such as "login", "admin", etc. One of those tools is dirb, which can be used in the terminal. 

The terminal is used to interact with the device and cyber security tools.

Inside the terminal, dirb is used by providing the command and the URL to test. For example:

dirb http://example.com

Use this knowledge to scan http://fakebank.thm to answer the question below.

You should now have found a hidden admin panel that lets you add money to your account.

To navigate to this hidden admin panel, we will add this newly discovered page to the search bar located at the top of the website. To do so, you will need to add the following: /bank-transfer. This demonstrates that just because something is hidden doesn't mean it isn't accessible and secure.

It looks like we can deposit money into Mr's G.Benjamin's account using this admin panel. Test this by selecting the account number you verified in task 2 (8881) and depositing at least 2,000 until your balance turns positive.

Overview

The frameworks we have covered so far, OSSTMM, OWASP WSTG, NIST SP 800-115, PTES, ISSAF, and MITRE ATT&CK, represent the core methodologies and knowledge bases a junior penetration tester is most likely to encounter. But the landscape does not end there. Depending on the industry, platform, or regulatory environment your client operates in, you may need to be aware of more specialized frameworks that address specific domains.

This task surveys five additional frameworks. The goal is not deep mastery of each one but landscape awareness: knowing they exist, understanding their niche, and recognizing when a client engagement might call for one of them.

The Frameworks

WASC Threat Classification was developed by the Web Application Security Consortium (WASC) as a taxonomy for categorizing web application vulnerabilities and attack types. It organizes threats into categories such as insufficient authentication, information leakage, and abuse of functionality. While it was influential in the mid-2000s and helped standardize how the industry discussed web threats, it has since been largely superseded by the OWASP Top Ten and WSTG as the dominant web security references. You may still encounter it referenced in older documentation or compliance frameworks.

CSA Cloud Controls Matrix(CCM) is published by the Cloud Security Alliance (CSA) and provides a cyber security controls framework specifically designed for cloud computing environments. It maps controls across 17 domains, including data security, identity and access management, and infrastructure security, and aligns them with major standards like ISO 27001, NIST, and PCI DSS. CCM is not a penetration testing methodology; it is a governance and compliance tool that helps organizations assess whether their cloud providers and configurations meet security requirements. You would encounter it when a client needs a cloud security posture assessment rather than a traditional pentest.

OWASP Mobile Application Security Testing Guide (MASTG) is the mobile counterpart to the WSTG we covered in Task 3. Maintained by OWASP, the MASTG provides detailed test cases for Android and iOS application security, covering areas like data storage, cryptographic implementation, network communication, platform interaction, and code quality. If your engagement involves testing a mobile banking app, a healthcare patient portal app, or any client-facing mobile application, the MASTG is the go-to reference. It is used alongside the OWASP Mobile Application Security Verification Standard (MASVS), which defines the security requirements that the MASTG tests against.

PCI DSS Penetration Testing Guidelines are defined within the Payment Card Industry Data Security Standard, specifically in Requirement 11.4 (PCI DSS v4.0). Unlike the general-purpose frameworks covered earlier, these guidelines are regulatory mandates: any organization that processes, stores, or transmits cardholder data must conduct penetration tests that meet PCI DSS criteria. The guidelines specify that tests must cover both the external perimeter and the internal network, must be conducted at least annually and after significant infrastructure changes, and must validate network segmentation controls. When your client is a retailer, payment processor, or any entity in the payment card ecosystem, PCI DSS requirements will shape both the scope and the reporting format of your engagement.

CBEST Framework was developed by the Bank of England in collaboration with the UK financial sector. It is a threat-intelligence-led penetration testing framework designed specifically for UK financial institutions, including banks, insurers, and financial market infrastructure providers. CBEST engagements begin with a bespoke threat intelligence phase that identifies the most relevant threat actors and attack scenarios for the specific institution, and the subsequent penetration test simulates those realistic threat scenarios. CBEST is notable for its close integration of threat intelligence with hands-on testing and for its regulatory backing within the UK financial sector.

Comparison Table

Closing Notes

The key takeaway from this survey is that framework selection is driven by context. The client's industry, regulatory obligations, technology platform, and geographic jurisdiction all influence which framework applies. A penetration tester working with a UK bank must understand CBEST. A tester assessing a mobile health app will reach for OWASP MASTG. A tester working with a payment processor cannot avoid PCI DSS requirements. Knowing the landscape means you can recognize which framework a given engagement demands, even if you need to study it in detail at that point.