Technical Preparation

• Access Requirements: We determine the types of access required for the test, such as specific user roles, user accounts with administrative privileges or accounts using MFA.
• Tool Configuration: Select and configure the appropriate tools and methods for the test. Ensure they are updated to address recent vulnerabilities and are capable of logging activities without causing disruptions.

Stakeholder Engagement

• Communication Plan: We establish a communication plan with all stakeholders, including security teams, IT management, and any operational personnel to align on the test objectives and procedures.
• Incident Response Coordination: We coordinate with the stakeholders incident response team to prepare for any potential discoveries of active security incidents during the test.

Customer Safety Processes

• Backup Systems: When testing production systems customer stakeholders should ensure that backups are available for all critical data and configurations in case the test inadvertently affects system stability or data integrity.
• Impact Analysis: Customer stakeholders should conduct a risk assessment to identify potential impacts of the test on the system and operations, preparing mitigation strategies for identified risks.

Documentation and Record-Keeping

• Test Plan Documentation: We maintain detailed documentation of the test plan, methodologies, tools, and any customer procedures used during the penetration test. This should include the rationale for choosing specific testing methods and the expected test outcomes.

Define The Test Objectives And Scope

• Objective Setting
• Working with customer stakeholders we clearly define what the penetration test aims to achieve. Common objectives include identifying exploitable vulnerabilities, evaluating the effectiveness of existing security measures, and testing the response capabilities of the security team.
• Scope
  In-scope Resources: Working with the customer stakeholders we then determine which  of the web application environments resources, services and data are included in the test. This includes specifying environments (production or non-production), types of data, and services like VMs, databases, and storage accounts. Clearly defining the scope helps prevent unauthorised access to sensitive areas and ensures compliance with both organisational policies and external regulations.
  Limitations: Clear boundaries are set to avoid any impact on production systems or data. This includes time frames for testing to minimise disruption to normal business operations.
• Compliance and Regulations
• We ensure that the testing activities align with relevant legal and regulatory  guidelines.

Pre-Flight Checks

• Stakeholder Briefing (optional dependent on the customer): We hold a meeting with all relevant stakeholders to review the test plan, confirm scope, and discuss any potential concerns or limitations.
• Logistical Arrangements: We ensure all necessary tools, access credentials, and resources are in place before the testing begins. This includes setting up secure channels for data collection and reporting.
• Legal and Ethical Compliance: As part of the pre-flight checks we re-confirm that all testing activities are authorised and documented, with special attention to ethical considerations and data protection laws.

Conduct Search Engine Discovery and Reconnaissance for Information Leakage

• We use Open-Source Intelligence (OSINT) techniques: to collect data about the target organisation. Utilising search engines like Google, Bing, and others to discover publicly available information that could reveal insights into the application’s architecture, technologies used, and potential entry points.We use advanced search operators to find specific file types, sensitive directories, accidentally exposed documents, and employee details.
• DNS and Service Enumeration: We employ tools to scan for DNS records and visible services that can be accessed. Tools like third-party scanners can provide insights into the services exposed to the internet.
• Identifying Entry Points: We determine potential entry points for attacks, using public records of SSL certificates issued to identify publicly exposed APIs, web applications, and management interfaces that could provide initial access to the environment.
• Security Policy Review (optional): We analyse the security policies applied across underlying web application environment to understand the controls in place. This review can help identify potential misconfigurations or overly permissive settings that could be exploited.

Fingerprinting The Web Server

• We then determine the web server type, version, and configuration settings. Knowing the server details can help identify known vulnerabilities specific to the versions identified in use. Using tools like Nmap and Shodan to gather comprehensive server information.

Review Webserver Metafiles for Information Leakage

• We examine files like robots.txt and .htaccess that might inadvertently reveal directory structures or the file locations.

Enumerate Applications on The Web Server

• We identify all applications hosted on the server, noting versions and configurations, to map the full attack surface. By checking directories, virtual hosts, and existing applications for version information and entry points.

Review Webpage Comments and Metadata for Information Leakage

• We scrutinise HTML, CSS, and JavaScript files for developer comments that might contain sensitive information such as internal IP addresses, deprecated features, or upcoming changes. Using tools like BurpSuite Pro to automate the extraction and analysis of comments.

Identify the Web Application Entry Points

• We catalog all user input fields, API endpoints, and interaction points. These are potential vectors for injection attacks and other exploits.We use automated tools like Burp Suite to interact with the application and identify how and where it accepts user input.

Map Execution Paths Through the Web Application

• We then understand the flow of data through the application, identifying critical processing points such as form submissions or login processes. We use both static and dynamic analysis tools to trace how data moves through the application.

Fingerprint The Web Application Frameworks Used

• We then Identify the frameworks and libraries used by the web application, such as Angular, React, or Django. This helps us to understand the specific framework vulnerabilities.We examine HTTP headers, file structures, or specific files like manifest.json or bundle.js.

Map Application Architecture (White box and Grey Box Testing)

• If within the scope of the engagement, we then document the architecture of the web application including all interconnected systems like databases, third-party services, and internal APIs. We diagram the relationships and data flows between components to identify potential areas where data might be exposed or intercepted.

Test Network/Infrastructure Configuration

• We examine the network setup and infrastructure configurations to ensure they are secure and conform to best practices. This includes checking firewall rules, router configurations, and other network appliances.We utilise network scanning tools like Nmap, Nessus, or network configuration management software to detect unprotected services, open ports, and other vulnerabilities that may be present due to misconfiguration.

IP/URL identification  and Asset Discovery

• IP and URL Identification: We use the collected public data  to determine the applicable IP addresses and URL's for the penetration test. This includes SSL certificate information that has been made public.
• Asset Inventory: We utilise third-party tools to list all assets within the scope, categorising them by type (e.g., VMs, containers, and other networked devices.).

Port and Service Enumeration

• Network Scanning: We use network scanning tools to identify open ports and services. Tools like Nmap, Masscan  to scan IP addresses and URL's associated with the Web Application to find entry points and detect open ports that could indicate running services.
• Service Detection: For each open port, we determine the service type including web servers, database services, and cloud-specific services.
• Configuration Review: We examine the configuration of these services to identify weak security practices such as default settings, unnecessary services, or deprecated protocols to ensure that data transmitted over the Internet is securely encrypted.

Vulnerability Scanning

• Automated Scanning: Once the open ports are identified, we further enumerate the types of services running on those ports using tools like Nessus Professional or Qualys that can detect common misconfigurations and known security flaws.
• Custom Scripts and Tools:  We deploy scripts designed to uncover the web application environmental-specific misconfigurations or inadequacies, especially those not typically identified by generic scanning tools.
• Simulate Network Attacks: We use tools like Metasploit to test the effectiveness of network controls against simulated attacks.
• Web Application Scanning: We then use web application scanners like Burp Suite professional and Qualys Web Application scanning to discover and catalog web applications, APIs, and their endpoints that are hosted within the web application environment. And to identify vulnerabilities, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
• API Testing: We test exposed APIs for security issues related to authentication, authorisation, and data validation, which are critical in cloud environments

Test File Extension Handling for Sensitive Information

• We ensure that the web application handles file extensions securely, particularly those that can execute code or contain sensitive information. We perform manual and automated testing to attempt to upload and execute various file types. Check if the server properly handles these files to prevent execution and leakage of sensitive data. This includes checks if the server is running antivirus.

Review Old, Backup and Unreferenced Files for Sensitive Information

• We identify outdated, backup, and unreferenced files that may still reside on the system and contain sensitive information or introduce vulnerabilities. We use tools like dirbuster to scan directories for old and backup files. Manually reviewing the content of these files to check for sensitive data or information about the application’s architecture.

Enumerate Infrastructure and Application Admin Interfaces

• We discover and then evaluate any administrative interfaces for the infrastructure or application to ensure they are secure and properly restricted. We check for common admin paths, and try default login credentials. We review the port scanning results to discover hidden services and interfaces.

Test HTTP Methods

• We assess the HTTP methods enabled on the server (e.g., GET, POST, DELETE, PUT) and ensure that only necessary methods are available to prevent misuse. We use tools like Curl or Burp Suite to test various HTTP methods and identify improper server responses or unauthorised access.

 Test HTTP Strict Transport Security

• We confirm that HTTP Strict Transport Security (HSTS) is properly implemented to force HTTPS on all communications and avoid SSL stripping attacks. We check the headers returned from web requests for the presence of the Strict-Transport-Security header with an appropriate max-age directive.

Test RIA Cross Domain Policy

• We review the cross-domain policies (such as crossdomain.xml in Flash or clientaccesspolicy.xml in Silverlight) to ensure they do not permit data leakage or cross-site scripting. We review the policy files for overly permissive settings and test for cross-domain data access vulnerabilities.

Test File Permissions

• We verify that files and directories have appropriate permissions set to prevent unauthorized access or modification. We use tools and scripts to analyse file and directory permissions, ensuring sensitive files are not accessible or writable by unauthorized users

Risk Identification

• Threat Modeling (optional CSTAR approach) : If within the scope of the engagement, based on gathered data, we develop threat models that describe potential attack vectors specific to the organisation's  web applications environment environment. Considering both external and insider threats.(Learn More)

Build Review - Test Application Platform Configuration (Optional)

• If within the scope of the engagement, we evaluate the configurations of the web server, application server, and database server. This includes checking for default settings, unnecessary services, and ensuring secure communication protocols are used. We use automated configuration scanning/build review tools and manual review to identify potential configuration weaknesses like unnecessary database permissions, or insecure file permissions.

Directory and Access Enumeration (Optional)

• Environmental Active Directory (AD) Scanning (optional configuration review) :
• If within the scope of the engagement, we enumerate the environments AD to gather information on user accounts, roles, and permissions. Tools like BloodHound or custom PowerShell scripts are employed to visualise privilege relationships and identify misconfigurations for vulnerabilities like overly permissive access, which could be exploited during later phases.(Learn More)
• Storage Access Evaluation: We check storage accounts and databases for improper permissions or exposed sensitive data.

Security Group and Network ACL Analysis

• Virtual Network Analysis (optional segmentation testing):
• If within the scope of the engagement, we assess the segmentation and isolation practices within the web application's environment  to identify potential lateral movement pathways. for vulnerabilities like overly permissive access, which could be exploited during later phases.(Learn More)

• Review The Web Application's environment Firewall and Network Controls (optional firewall review): If within the scope of the engagement, we analyse firewall rules that control inbound and outbound traffic to the environment resources to identify overly permissive settings or configuration errors.(Learn More)

Test Role Definitions

• We ensure that the role definitions within the application enforce the principle of least privilege effectively. Roles should be clearly defined and limited to only the necessary permissions for the tasks users are meant to perform. We review the role configurations and permissions settings. Test by switching roles and verifying within Burp Professional that access limits are enforced according to the role definitions.

Test User Registration Process

• We evaluate the security of the user registration process to ensure that it prevents automated sign-ups and enforces strong authentication practices. We attempt to register with weak passwords, use automation scripts or Burp Professional scripts to simulate bulk registrations, and check for CAPTCHA or other anti-bot measures.

Test Account Provisioning Process (optional process review)

• If within the scope of the engagement, we assess the procedures involved in account provisioning to ensure they do not introduce security vulnerabilities, such as granting excessive permissions or failing to verify new accounts properly.We  trace the account creation process from start to finish, examining how new accounts are verified, activated, and assigned roles.

Testing for Account Enumeration and Guessable User Account (optional)

• We determine if the web application allows attackers to enumerate user accounts or guess user account details through error messages or predictable user ID patterns. We conduct tests like submitting numerous failed login attempts or registration processes using Burp Repeater to see if the application reveals whether email addresses or usernames are valid.

 Testing for Weak or Unenforced Username Policy

• We check if the application’s username policies are robust enough to prevent easily guessable usernames.We attempt to create accounts with simple or commonly used usernames to test the effectiveness of username policies.

Testing for Credentials Transported over an Encrypted Channel

• We test that all credentials are transmitted over secure, encrypted channels to prevent interception by malicious parties. We use tools like Wireshark or Burp Suite to monitor the data transmitted during authentication processes and verify that HTTPS or other secure protocols are used.

Testing for Default Credentials

• We identify if default credentials provided by system manufacturers or software providers are still in use, which are a common vector for attacks. We attempt to log in using known default usernames and passwords or use scripts to do the same. This can include administrative credentials that have not been changed post-installation.

Testing for Weak Lock Out Mechanisms

• We evaluate the effectiveness of the account lockout mechanisms after several failed login attempts to prevent brute force attacks. We conduct brute force attacks on the supplied user accounts to see if and when the account gets locked and how the application handles the lockout.

Testing for Bypassing Authentication Schema

• We test the robustness of the authentication scheme to determine if there are ways to bypass it entirely. We employ various methods such as session hijacking, modification of session tokens, or manipulation of hidden fields to attempt to bypass the login process.

Testing the Remember Password Functionality

• We evaluate if the 'remember me' functionality is implemented securely without allowing an attacker to hijack sessions or steal credentials.We analyse how the authentication tokens stored in cookies are secured and managed, checking for flags such as HttpOnly and Secure.

Testing for Browser Cache Weakness

• We determine if sensitive information from the authentication process is stored insecurely in the browser cache.We check for sensitive data storage in browser cache through browser settings and inspect the cache storage manually after authenticating.

Testing for Weak Password Policy

• We verify that the application enforces a strong password policy, reducing the risk of passwords being easily guessed or cracked. We attempt to register or change passwords to simple or commonly used passwords to test the enforcement of password complexity requirements

Testing for Weak Security Question/Answers

• We assess the security of password recovery mechanisms that utilise security questions, ensuring they cannot be easily guessed. We analyse the difficulty of security questions and attempt to reset passwords using easily accessible or guessable information.

Testing for Weak Password Change or Reset Functionalities

• We evaluate the security of mechanisms for changing or resetting passwords to ensure they do not introduce vulnerabilities. We attempt to change passwords without proper authorisation, or try intercepting reset links or tokens to check for vulnerabilities.

Testing for Weaker Authentication in Alternative Channel

• We evaluate that the alternate authentication methods, such as mobile or email OTP, voice recognition, etc., maintain the same level of security as the primary authentication method. We test alternative channels for authentication weaknesses, such as susceptibility to interception or replay attacks.

Testing Directory traversal/file include

• We validate that the application properly restricts file access, preventing users from accessing files or directories outside of their intended permissions. We attempt to access files and directories that should not be accessible by manipulating input paths in URL parameters or file requests, such as using "../" patterns (directory traversal) or including files from external sources (file inclusion).

Testing for bypassing the authorisation schema

• We verify that all mechanisms in place to enforce user permissions are robust and cannot be bypassed.We try accessing functionalities that should be restricted by manipulating session tokens, cookies, or crafting specialised requests to bypass normal authorization checks.

Testing for Privilege Escalation

• We validate if lower-privileged users can escalate their privileges to access data or functions reserved for higher-privileged users. We modify user roles, access rights, or session information to attempt privilege escalation; this includes both vertical escalation (user to admin) and horizontal escalation (accessing data of another user at the same privilege level).

Testing for Insecure Direct Object References

• Objective: We check for vulnerabilities that allow users to access objects directly by altering parameter values in the URL or request (e.g., database record identifiers). We manipulate reference numbers or strings in URLs or POST data to attempt to access unauthorised resources or actions. Monitor whether the system adequately checks for user permissions before serving these requests.

Testing for Bypassing Session Management Schema

• We evaluate the robustness of the session management controls to ensure they cannot be bypassed or manipulated.By attempting various attacks such as session fixation, where an attacker sets a user's session ID before they log in, or session hijacking, where an attacker takes over a user's session after they've authenticated.

Testing for Cookies Attributes

• We ensure that cookies used in managing sessions have secure attributes set, such as HttpOnly, Secure, and SameSite. We:inspect cookies set by the application during and after authentication to verify that these attributes are correctly implemented to prevent cookies from being accessed by client-side scripts or transmitted over insecure connections.

Testing for Session Fixation

• We test the application for vulnerabilities that allow session fixation attacks, where an attacker can force a specific session ID on a user. We try to inject or assign a known session ID and use that session ID to authenticate as the user, examining whether the application allows the session ID to persist through the authentication process.

Testing for Exposed Session Variables

• We check if sensitive session variables such as authentication tokens are exposed through the client-side code or can be manipulated via the client. We review JavaScript and client-side code for exposure of sensitive session information and attempt to manipulate session variables using tools like browser developer tools or proxy tools.

Testing for Cross Site Request Forgery (CSRF)

• We test that the application is not vulnerable to CSRF attacks, where an attacker can trick a user into performing actions that they are authenticated to do. We test for the presence of anti-CSRF tokens in state-changing requests and attempt CSRF attacks by crafting malicious requests that mimic legitimate requests from an authenticated user.

Testing for Logout Functionality

• We verify that the logout functionality works correctly, ensuring that all session tokens are invalidated upon logout. We log out from the application and then attempt to reuse the previous session cookie(s) to access the application. And then check the server responses to ensure that the session is truly invalidated.

Test Session Timeout

• We validate that the application properly times out inactive sessions to reduce the risk of session hijacking. We leave a session idle and attempt to perform actions after different periods of inactivity to see if the application enforces session expiration.

Testing for Session Puzzling

• We test for session puzzling issues where an application does not properly handle simultaneous requests in a single session that can lead to logic flaws.We perform concurrent requests with conflicting or varied data using the same session tokens to see how the application handles these scenarios.

Testing for Reflected Cross Site Scripting

• We validate if the application properly sanitises user input to prevent XSS where malicious scripts are reflected back to the user's browser. We input malicious JavaScript codes in forms, URL parameters, or any input vectors to see if they are executed in the browser.

Testing for Stored Cross Site Scripting

• We ensure the application prevents user inputs containing malicious scripts from being permanently stored and later presented to users. We submit scripts through input fields that save data (like comments, profiles) and check if these scripts are executed on subsequent page views

Testing for HTTP Verb Tampering

• We assess if the application responds appropriately to various HTTP methods or verbs that could alter the application state.We use tools like Burp Suite to send requests with different HTTP methods (PUT, DELETE, TRACE, etc.) and identify if unauthorised actions are possible.

Testing for HTTP Parameter Pollution

• We evaluate the resilience of the application against attacks involving the manipulation of query string parameters.We inject multiple instances of the same parameter in HTTP requests to see if the application mishandles the input, leading to potential exploits.

Testing for SQL Injection

Involves examining the web application for vulnerabilities that allow an attacker to execute arbitrary SQL commands through the user input fields. SQL injection attacks can lead to unauthorised access to or manipulation of database information. Effective testing must consider the specifics of the database management system in use, as each system has unique features and vulnerabilities.

SQL: Oracle Testing

• We verify SQL injection vulnerabilities in applications that use Oracle databases, by testing for typical SQL injection payloads such as ' OR '1'='1, but also Oracle-specific specific syntax to bypass standard SQL injection defenses, such as using alternative concatenation operators or exploiting Oracle functions.. We check for Oracle error messages that might reveal information about the database structure.

SQL: MySQL Testing

• Objective: Focus on identifying SQL injection flaws in applications backed by MySQL databases.By 
  leveraging MySQL's string concatenation functions, format specifiers, and delay functions like SLEEP() to construct time-based blind SQL injection attacks. We explore vulnerabilities specific to MySQL such as the handling of escape characters or the batched queries using semicolons.

SQL: MS SQL Server Testing

• We test for SQL injection vulnerabilities in systems utilising Microsoft SQL Server.By using payloads that exploit the EXEC command to run arbitrary SQL code.We test for out-of-band SQL injection by exploiting SQL Server’s ability to make DNS requests or HTTP requests using xp_dirtree, xp_fileexist, or similar extended stored procedures.Investigate the potential for error-based SQL injection by inducing errors that will return information about the database.

SQL: Testing PostgreSQL

• We test for SQL injection vulnerabilities in applications using PostgreSQL databases. We exploit PostgreSQL's array functions and type casts to bypass input validation.and experiment with stacked queries and PostgreSQL-specific functions like COPY TO/FROM PROGRAM to perform command execution. We use the pg_sleep() function to facilitate time-based SQL injection tests.

SQL: MS Access Testing

• We identify SQL injection issues in applications that interact with Microsoft Access databases. We
  test for simplistic payloads as Access does not support multiple queries in a single SQL statement. We use union-based SQL injection to extract data, focusing on the differences in SQL syntax between Access and other SQL databases.

SQL: Testing for NoSQL Injection

• We examine NoSQL databases like MongoDB for injection vulnerabilities, which differ significantly from traditional SQL injection. We test for injection by supplying malformed JSON or JavaScript objects in inputs that interact with the database.We leverage MongoDB operators such as $gt, $ne, or $regex in user inputs to alter query logic.We explore the application’s handling of BSON (Binary JSON) and JavaScript code, often used in NoSQL queries, to perform unauthorized actions or retrieve data.

Testing for LDAP Injection

• We evaluate how the application handles input used in constructing LDAP queries to prevent attackers from altering LDAP statements. We inject malicious LDAP statements through input fields to test if the application improperly filters input, potentially allowing unauthorised access.

Testing for ORM Injection

• We test for vulnerabilities in Object Relational Mapping (ORM) that allow attackers to inject malicious input.We use ORM specific payloads to manipulate ORM queries through input fields, checking for improper handling of input.

Testing for XML Injection

• We test for flaws in XML parsers and processing that could allow an attacker to inject malicious content.
  Techniques: Manipulate XML data inputs to test if the application fails to properly sanitise input, potentially allowing XML-related attacks like XXE

Testing for SSI Injection

• We assess the application's vulnerability to Server-Side Includes (SSI) injection, which could lead to the execution of server-side commands. We inject SSI directives into input fields to see if they are executed by the server.

Testing for XPath Injection

• We evaluate security measures against XPath injection attacks that could allow unauthorised access to XML documents.We use XPath injection techniques in any XML or XPath input fields to attempt to alter document structure or retrieve hidden data.

IMAP/SMTP Injection

• We identify vulnerabilities where malicious commands are injected into IMAP or SMTP sessions. We craft inputs that may be interpreted by mail servers as commands, for instance by including CR (carriage return) or LF (line feed) characters to manipulate SMTP or IMAP server responses or actions. We test email fields or any feature interacting with mail servers for response splitting or unexpected command execution.

Testing for Code Injection

Code injection flaws occur when an attacker can introduce malicious code into a software system.

Code: Testing for Local File Inclusion

• We determine if local files can be included in output, leading to information disclosure or server-side code execution. We manipulate file paths in URL parameters or input fields to include files that exist on the server, like configuration files or logs.

Code: Testing for Remote File Inclusion

• We assess if external or remote files can be included or executed through the web application.
  Technique: Try to exploit any feature that fetches and executes files from a remote location by providing URLs pointing to files that the attacker controls.

Testing for Command Injection

• We identify instances where shell commands injected through web inputs are executed on the server.We Input shell commands into form fields, URL parameters, or HTTP headers, looking for ways to escape the context of the input and execute commands.

Testing for Buffer Overflows

Buffer overflows can lead to arbitrary code execution, application crashes, or other unexpected behaviors.

Buffer: Testing for Heap Overflow

• We test dynamic memory allocation for overflows that corrupt heap data.We attempt to overflow application buffers by providing input that exceeds the expected size, whilst monitoring application stability or behavior for signs of memory corruption.

Buffer: Testing for Stack Overflow

• We check for vulnerabilities where the call stack is overflowed by user input.We provide excessive input data to functions that store data in stack-allocated buffers, particularly in languages susceptible to stack overflows like C or C++.

Buffer: Testing for Format String

• We exploit format string vulnerabilities typically found in unmanaged code. We input format specifiers (e.g., %s, %x, %n) into text fields to try and manipulate the output or execute arbitrary memory addresses.

Testing for Incubated Vulnerabilities

• We identify vulnerabilities that may not provide immediate gains for an attacker but can be combined with other exploits.We investigate lesser-known or low-severity issues that could lead to more significant vulnerabilities when chained with other exploits.

Testing for HTTP Splitting/Smuggling

• We check if it's possible to manipulate HTTP headers and methods to perform HTTP response splitting or smuggling. We inject CR/LF characters into inputs that affect HTTP headers to alter response headers or split responses, potentially leading to cache poisoning or cross-user attacks.

Testing for HTTP Incoming Requests

• We assess the handling of incoming HTTP requests for potential vulnerabilities. We monitor how the application processes incoming HTTP requests, testing for improper handling of methods, headers, or payloads that could lead to unauthorized access or information disclosure.

Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection

• We validate that only strong, secure cryptographic ciphers are used in SSL/TLS configurations to protect data during transmission. We use tools like SSL Labs' SSL Test, OpenSSL, or TestSSL.sh to scan the SSL/TLS configurations of the web server. These tools check for the presence of weak ciphers such as RC4 or DES, SSL versions 2 or 3, and weak key exchanges. They also review certificate chains for validity and configuration errors.

Testing for Padding Oracle

• We detect vulnerabilities that allow attackers to decrypt data by manipulating the padding of encrypted messages, commonly found in CBC mode encryption. We perform active attacks using tools like Burp Suite’s Padding Oracle tool or scripts that systematically modify ciphertexts and observe the application's responses to determine if information on the padding validity is leaked, which can subsequently be used to decrypt data.

Testing for Sensitive Information Sent via Unencrypted Channels

• We ensure that all sensitive data is transmitted over encrypted channels to prevent interception by unauthorised parties. We monitor network traffic using tools such as Wireshark or tcpdump to capture data packets. We then analyse these packets for any sensitive information (like passwords, credit card data, personal information) being sent over non-HTTPS or other unencrypted protocols.

Testing for Weak Encryption

• We identify the use of encryption algorithms or protocols that are known to be weak and susceptible to decryption by attackers. We review the application’s codebase and configuration files for encryption methods.We look for the usage of deprecated algorithms like MD5 or SHA-1, small key sizes (e.g., RSA keys under 2048 bits), or improper usage of strong algorithms that could lead to vulnerabilities (e.g., ECB mode in block ciphers).

Test Business Logic Data Validation

• We ensure that all user inputs are validated according to business rules before processing. We test inputs for different data types and boundary values to check if the application improperly processes unexpected or incorrect data.

Test Ability to Forge Requests

• We determine if users can manipulate requests to bypass the intended business logic, potentially leading to unauthorized actions or data access. We use tools like Burp Suite to modify requests, parameters, and headers to attempt actions beyond a user’s privileges or intended use cases.

Test Integrity Checks

• We verify that all actions on data are properly checked for integrity, ensuring that data manipulation or transfer adheres to business rules. We manipulate data in transit or storage and observe whether the application detects and reacts appropriately to the integrity violation.

Test for Process Timing

• We check if the application handles timing issues correctly, such as performing actions in a specific order or within certain time frames.We perform actions out of order or simulate race conditions to see if the application fails to enforce process timings, potentially allowing actions that should be blocked or managed differently.

Test Number of Times a Function Can be Used Limits

• We ensure that the application enforces limits on the number of times a function can be used or invoked.We attempt to exceed usage limits to determine if the application properly enforces restrictions based on business rules.

Testing for the Circumvention of Work Flows

• We identify if users can bypass required steps in workflows, potentially skipping necessary checks or actions. We attempt to complete application workflows in non-standard ways to check if all required steps are enforced.

Test Defenses Against Application Misuse

• We assess the robustness of the application's defenses against misuse or abusive behavior.
  Technique: Simulate misuse scenarios like rapid submission of forms, simultaneous requests, or abuse of functionalities to test the application’s response and resilience.

Test Upload of Unexpected File Types

• We verify that the application correctly handles file uploads, restricting file types according to business needs and security policies. We upload various unexpected or prohibited file types to test the application’s filtering and validation mechanisms.

Test Upload of Malicious Files

• We ensure the application can identify and block uploads containing malicious content. We attempt to upload files that contain scripts, executables, or other potentially dangerous content to see if the application properly scans and blocks these files.

Testing for DOM-based Cross-Site Scripting

• We ensure that the application is not vulnerable to DOM-based XSS, where malicious scripts are injected through client-side scripting. We manipulate DOM elements dynamically to inject harmful scripts and observe if they execute without proper sanitisation.

Testing for JavaScript Execution

• We identify issues in JavaScript handling that could allow for unintended script execution.We input unexpected JavaScript commands into form fields, URLs, or other input vectors to test for JavaScript execution vulnerabilities.

Testing for HTML Injection

• We conduct tests to prevent attackers from injecting arbitrary HTML content into the web page, which could alter the page's content or steal information.We inject HTML tags through user inputs and monitor if they are executed as part of the HTML DOM.

Testing for Client-Side URL Redirect

• We check for vulnerabilities that allow unauthorised redirection to malicious websites.We craft URLs that manipulate redirection logic to redirect users to unintended websites or malicious sites.

Testing for CSS Injection

• We determine if it's possible to inject custom CSS rules that could alter the appearance of the web page or be used for phishing attacks. We attempt to include external CSS styles or inline styles in user inputs to see if they are applied.

Testing for Client-Side Resource Manipulation

• We ensure that client-side resources like cookies, localStorage, and sessionStorage are secure against unauthorized access and manipulation.We manipulate client-side storage objects to test for vulnerabilities like improper access controls or data exposure.

Test Cross-Origin Resource Sharing

• We Verify that CORS policies are correctly implemented to prevent unauthorized cross-origin requests.
  Approach: Conduct tests to attempt accessing resources from different origins to evaluate CORS settings.

Testing for Cross-Site Flashing

• We identify vulnerabilities related to Flash files that could be used to execute cross-site scripting or other malicious activities. We test for Flash parameter injection and cross-site loading issues.

Testing for Clickjacking

• We assess if the application is vulnerable to clickjacking attacks, where users are tricked into clicking something different than expected. We use framing techniques to overlay transparent or opaque layers over the application to trick users into performing unintended actions.

Testing WebSockets

• We ensure that WebSocket connections are secure and cannot be hijacked or manipulated. We test for vulnerabilities in the WebSocket handshake process and data transfer integrity.

Test Web Messaging

• We verify the security of web messaging implementations, particularly postMessage use, to prevent cross-origin script attacks. Se send messages between different origins and test if messages are properly validated before processing.

Test Local Storage

• We confirm that data stored in local storage is protected from unauthorised access and manipulation. We attempt to access or manipulate localStorage data from different contexts or origins. 

Techniques

Establishing Persistence

• Backdoors: We install back-doors on compromised systems to ensure continued access, even if the original entry point is closed or the user credentials are changed.
• Scheduled Tasks: We use native operating system features to create scheduled tasks or cron jobs that call back to the attacker’s control server or re-execute malware at regular intervals.
• Web Shells: We deploy web shells on web servers, which allow for persistent, remote administration over the web interface.

Network Analysis and Manipulation

• Sniffing and Traffic Analysis: We capture network traffic within Web Applications environment to extract credentials, session tokens, or other sensitive data.
• Man-in-the-Middle Attacks: We position ourselves between two communicating parties to intercept or manipulate data being exchanged, typically by exploiting weaknesses in network protocols.

Credential Harvesting and Reuse

• Extract Credentials: We use tools to extract credentials stored on compromised instances or intercepted during communication. The use software like hashcat using powerful GPU's to recover weak passwords.
• Role Switching: We exploit stolen role credentials and the policies to grant broader access than initially available, including elevating privileges within Active Directory or other Directory services.
• Exploiting System Vulnerabilities: We take advantage of system-level vulnerabilities or misconfigurations to escalate privileges from a lower-privileged user to an administrative user.

Lateral Movement Techniques

• Pass-the-Ticket/Pass-the-Hash Techniques: We use techniques to authenticate to other systems using stolen Kerberos tickets or NTLM hash values without knowing the actual passwords.
• Network Pivoting:  We utilise existing credentials or sessions to access other systems within the Web Applications environment, such as moving from one virtual machine to another within the same network. We also use a compromised VM as a pivot point to access internal networks or other virtual networks connected through peering.

Exploiting Trust Relationships

• Service to Service Exploitation: We exploit connections or trust relationships between services, such as moving from a compromised web server to a connected database server. Or utilise permissions granted to one service (like API) to access or manipulate other services (like filesystems or databases).

Access to Key Assets

• Data Access: Locate and access databases, file servers, and other storage solutions within the web applications environment to extract sensitive data.
• Critical Infrastructure Access: Gain control over critical infrastructure components like domain controllers, network infrastructure devices, or security solutions to deepen control over the environment.

Command and Control Channels

• Data Exfiltration Routes: We establish secure channels for data exfiltration to external servers or through DNS queries.
• Covert Channels: We set up covert channels to communicate between compromised assets without detection.

Monitoring and Evasion Techniques

• Log Manipulation: We modify or delete logs to erase traces of activity and evade detection by security monitoring tools.
• Security Group Manipulation: We adjust security group rules to facilitate movement while attempting to remain under the radar.