Phase 1: Preparation and Planning – bWAPP Penetration

Test
1. Objectives
● Assess the security posture of the bWAPP application in a controlled lab
environment.
● Identify and document vulnerabilities within the bWAPP system.
● Evaluate potential risks associated with discovered vulnerabilities.
● Provide recommendations for remediation and improving security.
● Enhance penetration testing skills through practical hands-on experience.

2. Scope
● Target System:
○ Web Application: bWAPP vulnerable web application.
○ Hosting Server: Localhost or virtual machine running bWAPP.
○ Database: MySQL database used by the bWAPP system.
○ Infrastructure: Local network environment where the system is hosted.
● Known-environment Testing:
○ Full knowledge of the environment (white-box testing).
○ Access to source code, credentials, and configuration files is permitted.
● Unknown-environment Testing:
○ Not applicable. This test is conducted with full prior knowledge of the system.
● Out of Scope:
○ Any system, service, or infrastructure unrelated to the bWAPP lab setup.
○ No external or production systems are included in this test.

3. Methodology
● Follow the OWASP Testing Guide and industry-standard penetration testing phases:
1. Information Gathering: Identify technologies used, open ports, services, and
application structure.
2. Threat Modeling: Analyze potential threats based on application and
environment characteristics.
3. Vulnerability Analysis: Utilize tools (e.g., Burp Suite, Nmap, OWASP ZAP)
to identify known vulnerabilities.
4. Exploitation: Safely attempt to exploit vulnerabilities to assess real-world
risks.
5. Post-Exploitation: Evaluate access levels achieved and data that could be
compromised.
6. Reporting: Document findings with evidence, risk ratings, and actionable
remediation recommendations.
4. Timeline

5. Legal and Compliance

● Regulatory Compliance Considerations
○ This penetration test is conducted in a controlled lab environment and does not
involve real-world or production systems; therefore, regulatory compliance
frameworks such as GDPR, HIPAA, PCI-DSS, or GLBA are not directly
applicable. However, industry best practices regarding responsible
vulnerability testing, data privacy, and ethical hacking are followed.
● Local Restrictions
○ All testing activities are performed in a legal and ethical manner, confined to
local lab systems. No unauthorized scanning or testing of external networks or
systems will occur.
● Service-Level Agreement (SLA), Confidentiality, Statement of Work (SOW),
Master Service Agreement (MSA), Non-Disclosure Agreement (NDA)
○ As this is a student or research-driven penetration test of bWAPP, formal
agreements such as SLA, SOW, MSA, and NDA are not required. However, if
conducted in a corporate environment, the following would be necessary:
■ SLA: Defines expected response times and deliverables.
■ SOW: Details scope, objectives, and timeline.
■ MSA: Establishes overarching legal terms for all engagements.
■ NDA: Ensures confidentiality of all sensitive information.
● Contract
○ No commercial contract applies for this test. For professional services, a
signed agreement would be required to define roles, responsibilities, scope,
and liabilities.
● Disclaimers
○ This penetration test is for educational and research purposes only. The tester
assumes full responsibility for ensuring testing is conducted ethically, legally,
and within the defined scope.
6. Rules of Engagement Document
● Testing will be limited strictly to the bWAPP application and associated local
infrastructure.
● No external IP addresses or networks will be scanned or attacked.
● Testing Time Window: No time restrictions in a local environment. In corporate
testing, specify testing hours.
● Permitted Tools: Nmap, Burp Suite, OWASP ZAP, Nikto, SQLMap, etc.
● Data Handling:
○ No sensitive real user data involved. Any data collected will remain within the
test environment.
● Communication:
○ Regular progress updates during each phase.
○ Immediate reporting of any critical findings.
● Incident Response:
○ In the event of unintended system impact, testing will be stopped, and the
issue will be investigated.
● Reporting:
○ A detailed final report will be submitted, including all findings, evidence, risk
levels, and mitigation recommendations.

7. Team and Members

The penetration testing project is conducted by the following team members:

● Trần Đức Thiện – Team Leader

● Nguyễn Văn Khoa
● Hoàng Trọng Tiến
● Nguyễn Trọng Thành
● Vũ Minh Đức

8. Written Agreement (Agreement/Contract)

This agreement outlines the terms and conditions under which the penetration test of the
bWAPP application will be conducted by the security testing team.

a. Included Items (Based on Sections 1.1 to 1.7)

● Objectives: Evaluate the security posture of the bWAPP application and identify
vulnerabilities in a safe and controlled environment.
● Scope: Testing will be strictly limited to the bWAPP web application, its local hosting
environment, and database.
● Methodology: The team will follow OWASP and industry-standard penetration
testing methodologies.
● Legal and Compliance: All testing is conducted ethically, legally, and with consent.
 ● Rules of Engagement: Testing tools, techniques, and responsibilities are clearly
defined.
● Team Members: Identified in Section 7.
● Schedule: A detailed timeline is provided in Section 9 (Detailed Planning).

b. Costs

● This is a non-commercial, educational penetration test conducted at zero cost. No

financial compensation is involved for either party.

c. Responsibilities of Each Party

● Penetration Testing Team:

○ Conduct testing responsibly, within the defined scope.
○ Avoid causing damage to systems or data.
○ Report all findings accurately and promptly.
○ Maintain confidentiality of any data accessed.
● System Owner / Lab Supervisor:
○ Provide necessary access to the bWAPP system and environment.
○ Support the testing team in case of technical issues.
○ Review and approve the final report.

d. Process for Handling Critical Vulnerabilities

● If a critical vulnerability is discovered:

○ Testing will be paused immediately.
○ The team will notify the system owner/supervisor without delay.
○ A mitigation or containment strategy will be discussed and agreed upon.
○ Testing may resume only after approval and necessary safeguards are in place.

9. Detailed Planning

This section outlines the detailed project plan for conducting the penetration test on the
bWAPP application, including defined phases, timeline, task assignments, tools, and
communication strategies.

Project Phases

Information Gathering (Reconnaissance)

○ Identify all entry points, pages, and potential inputs in the bWAPP application.
○ Map the application's structure, functions, and available features.

Analysis (Vulnerability Assessment)

○ Scan for common vulnerabilities (e.g., SQL Injection, XSS, CSRF).

 ○ Assess configurations and user access controls.
○ Review input validation and session management.

Exploitation (Proof of Concept)

○ Safely exploit identified vulnerabilities to verify their impact.

○ Document results and collect evidence (screenshots, logs).

Reporting

○ Compile a comprehensive report including methodology, findings, severity

ratings, and recommendations for mitigation.
○ Deliver final report and debrief findings.

Schedule for Each Phase

Phase Start Date End Date

Phase 1: Preperation and 03/10/2025 03/13/2025

Planning

Phase 2: Information 03/14/2025 03/15/2025

Gathering
(Reconnaissance)

Phase 3: Vulnerability 03/16/2025 03/17/2025

Analysis

Phase 4: Exploitation 03/18/2025 03/20/2025

Phase 5: Post-Exploitation 03/18/2025 03/20/2025

Phase 6: Reporting 03/20/2025 03/21/2025

Task Assignments

Team Member Assigned Tasks

Trần Đức Thiện (Leader) Phase 2, Phase 4

Nguyễn Văn Khoa Phase 1, Phase 4

Nguyễn Trọng Thành Phase 3, Phase 4

 Hoàng Trọng Tiến Phase 4, Phase 6

Vũ Minh Đức Phase 5, Phase 4

List of Tools to be Used

● Nmap – Network scanning and port mapping

● Burp Suite – Web application proxy and vulnerability scanner
● OWASP ZAP – Automated vulnerability scanning and testing
● Nikto – Web server vulnerability scanner
● SQLMap – SQL Injection testing
● Browser Developer Tools – Manual testing and inspection

Communication and Progress Reporting Methods

● Daily Stand-ups: Quick status updates among team members.

● Progress Tracking: Shared project board (e.g., Trello/Notion) for task management.
● Issue Escalation: Immediate verbal and written communication to the team leader.
● Final Debrief: Team meeting upon report completion for lessons learned and future
improvements.

Phase 2: Information Gathering (Reconnaissance)

1. Identify Assets and Activities
In this phase, we need to identify key assets and activities in bWAPP to understand the
scope of testing. The main assets include:

● Web Application: bWAPP is a PHP/MySQL-based application that simulates

common security vulnerabilities.
● Server System: The web server running bWAPP (Apache, Nginx, or XAMPP).
● Database: MySQL storing user information, login credentials, and transactions.

Key Features:

● Login/Logout functionality.
● Data input functions (forms, search boxes).
● Session management.
● Authentication and authorization mechanisms.
● API endpoints, if available.
The goal is to identify potential exploitation points through attack surface analysis.

2. Identify Threats by a Threat Modeling

Based on OWASP Top 10 and SANS Top 25, we can identify potential threats:

Injection Attacks:

● SQL Injection (SQLi): Check if input parameters can be exploited with SQL code
injection.
● Command Injection: Attempt to exploit shell commands through uncontrolled inputs.

Broken Authentication:

● Check if login credentials can be brute-forced.

● Look for vulnerabilities in password management (password reset, insecure storage).

Sensitive Data Exposure:

● Verify if sensitive information is exposed on the web interface or stored without

encryption.

Cross-Site Scripting (XSS):

● Inject malicious JavaScript into input fields and check for execution in browsers.

Cross-Site Request Forgery (CSRF):

● Determine if the application has CSRF protection measures.

Security Misconfiguration:

● Check HTTP headers, server configurations, and directory access permissions.

Using the STRIDE model to classify threats:

● Spoofing: Identity impersonation.

● Tampering: Data modification.
● Repudiation: Denying actions.
● Information Disclosure: Leaking sensitive data.
● Denial of Service: Service disruption attacks.
● Elevation of Privilege: Unauthorized access escalation.

3. Performing Passive Reconnaissance

Passive reconnaissance is the process of gathering information without directly interacting
with the target.

Tools and Methods:

● Google Dorking: Using advanced search queries to discover sensitive information.

○ site:example.com inurl:login
○ filetype:log site:example.com
● WHOIS Lookup: Identifying domain and server information.
● Shodan: Checking which ports are open on a server.
● OSINT Framework: Searching for information from public sources such as GitHub
and Pastebin.
● Wayback Machine: Reviewing historical versions of a website.

The objective of passive reconnaissance is to collect as much information as possible

without leaving traces on the target system.

4. Performing Active Reconnaissance

Active reconnaissance involves gathering information by directly interacting with the system.

Tools and Methods:

● Nmap: Scanning ports and detecting running services.

○ nmap -sV -A target_ip
● Nikto: Scanning web servers for vulnerabilities.
○ nikto -h http://target
● Dirb/Dirbuster: Scanning hidden directories on the server.
○ dirb http://target
● Burp Suite: Analyzing and intercepting requests/responses to find vulnerabilities.
● Wappalyzer: Identifying technologies used on the website (CMS, frameworks,
JavaScript libraries).

The results from this process will help identify weaknesses and potential exploitation areas.

Phase 3: Vulnerability Analysis

1. Manual Analysis
During this phase, we conduct a thorough security analysis using well-known frameworks
and standards, including: OWASP Top 10, SANS Top 25, Misconfiguration Checks,
Session Management Checks, Authentication and Authorization Checks, Input
Validation Checks, Source Code Review (if White Box Testing applies), and API
Testing (if applicable).
Based on the identified vulnerabilities, our analysis is categorized into the following groups:

1.1 Injection Attacks

This category includes vulnerabilities where attackers can inject malicious code into the
application due to improper input validation and output encoding.
• HTML Injection - Reflected (GET, POST, Current URL)
• HTML Injection - Stored (BLOG)
• iFrame Injection
• OS Command Injection
• SQL Injection - GET (Search), POST (Search), AJAX JSON jQuery, Login Form
• XML/XPath Injection (Login Form)

1.2 Broken Authentication & Session Management

These vulnerabilities compromise authentication mechanisms and session handling,
potentially allowing attackers to hijack user accounts or manipulate sessions.
• Broken Authentication - Insecure Login Forms
• Broken Authentication - Password Attacks
• Session Management - Administrative Portals
• Session Management - Cookies (HTTPOnly)

1.3 Cross-Site Scripting (XSS)

XSS vulnerabilities allow attackers to inject and execute malicious JavaScript within a web
page, which can be used to steal user data or perform unauthorized actions.
• XSS - Reflected (GET, POST, Custom Header)

1.4 Insecure Data Transmission & Storage

These vulnerabilities arise from transmitting or storing sensitive data in an insecure manner,
potentially exposing credentials or confidential information.
• Clear Text HTTP (Credentials) - Low Security Level
• HTML5 Web Storage (Secret) - Low Security Level
• Text Files (Accounts) - Low Security Level

2. Severity Assessment
Once vulnerabilities are identified, we use the Common Vulnerability Scoring System
(CVSS) to assess their severity on a scale from 0.1 to 10.0, classified as follows:
• Critical (9.0 - 10.0): Highly exploitable vulnerabilities that could lead to full system
compromise, severe data breaches, or remote code execution.
o OS Command Injection
o SQL Injection - Login Form
 o Broken Authentication - Password Attacks

• High (7.0 - 8.9): Vulnerabilities that have a significant impact but may require specific
conditions for exploitation.
o XSS - Reflected (GET, POST, Custom Header)
o Session Management - Cookies (HTTPOnly)
o XML/XPath Injection (Login Form)

• Medium (4.0 - 6.9): Moderate-risk vulnerabilities that may require user interaction or
have limited scope.
o HTML Injection - Stored (BLOG)
o iFrame Injection
o Session Management - Administrative Portals
• Low (0.1 - 3.9): Minor vulnerabilities that are difficult to exploit or have negligible
security impact.
o Clear Text HTTP (Credentials)
o HTML5 Web Storage (Secret)
o Text Files (Accounts)
Severity assessment is based on:
✔ Exploitability (Ease of attack execution)
✔ Impact (Potential damage to confidentiality, integrity, and availability)
✔ Remote Exploitation (Possibility of attack without local access)
✔ Authentication Requirements (Whether authentication is needed for exploitation)

Conclusion
By conducting a manual analysis based on industry standards and assessing vulnerabilities
using CVSS scoring, we can effectively prioritize security risks and recommend appropriate
mitigation strategies to strengthen system security.

Phase 5: Post-Exploitation
5.1 Creating a Foothold

● Deploying Web Shells and Reverse Shells:

○ Upload web shells to compromised servers for remote command
execution.
○ Use reverse shells to establish outbound connections to attacker-
controlled machines.
○ Example tools: Weevely, China Chopper, Metasploit.
● Scheduled Tasks and Service Creation:
○ Create cron jobs (Linux) or scheduled tasks (Windows) for persistent
execution.
○ Register new system services that automatically restart upon reboot.
● Modifying System Permissions:
 ○ Add new users to privileged groups (e.g., sudo or Administrators).
○ Adjust ACL (Access Control Lists) to grant unauthorized access.
● Encrypted Communication Channels:
○ Use SSL/TLS, SSH tunnels, or covert channels (e.g., DNS tunneling) to avoid
detection.
● Persistence Mechanisms:
○ Install SSH keys for persistent backdoor access.
○ Modify registry keys (Windows) or /etc/passwd (Linux) for stealth
persistence.
○ Use boot-time scripts to re-establish access after reboot.

5.2 Maintaining Persistence After Compromising a System

● Creating Stealth Accounts:

○ Add hidden administrator accounts for long-term access.
○ Modify /etc/shadow or Windows SAM database to maintain control.
● Startup and Service Modifications:
○ Edit system startup scripts (e.g., .bashrc, .bash_profile,
rc.local).
○ Modify Windows registry keys
(HKLM\Software\Microsoft\Windows\CurrentVersion\Run).
○ Install malicious services that restart automatically.
● Hiding Malicious Processes and Files:
○ Use rootkits to mask malware presence.
○ Hide processes via process hollowing or DLL injection.
○ Encrypt and obfuscate payloads to bypass antivirus.
● Process Injection and Memory Residency:
○ Inject malicious code into legitimate processes (e.g., explorer.exe,
svchost.exe).
○ Use PowerShell or reflective DLL injection for stealth execution.
● Automated Reconnection Mechanisms:
○ Configure scripts to reconnect in case of lost access.
○ Use tools like reGeorg or Chisel for dynamic tunneling.
● Monitoring Incident Response Activity:
○ Observe security tools and administrator activity.
○ Disable logging mechanisms or tamper with logs to evade detection.
Phase 6: Reporting
1. Executive Summary
The penetration test conducted on the bWAPP application aimed to assess its security
posture in a controlled lab environment. Key findings include multiple critical vulnerabilities,
such as SQL Injection, HTML Injection, and OS Command Injection, which can lead to
unauthorized access, data theft, and exploitation of system resources. Detailed
recommendations are provided to mitigate these risks and enhance overall security,
ensuring a robust defense against potential attackers.

2. Scope Details
● Target System:
○ Web Application: bWAPP
○ Hosting Server: Localhost (Dockerized environment)
○ Database: MySQL
○ Infrastructure: Local lab network
● Testing Type: Known-environment testing (white-box approach)
● Exclusions: External or production systems

3. Methodology
The penetration testing followed the OWASP Testing Guide and industry standards,
consisting of the following phases:

1. Preparation and Planning: Defined objectives, scope, and testing approach.

2. Information Gathering (Reconnaissance): Identified technologies, open ports, and
services used in the application.
3. Vulnerability Analysis: Conducted manual and automated scans to detect
vulnerabilities.
4. Exploitation: Performed controlled exploitation to validate the impact of
vulnerabilities.
5. Post-Exploitation: Evaluated persistence methods and data accessed through
exploited vulnerabilities.
6. Reporting: Documented findings, evidence, and remediation strategies.

4. Findings
4.1 Critical Vulnerabilities

1. SQL Injection (SQLi)

○ Description: The application allows SQL queries to be manipulated via user

input, bypassing authentication mechanisms.
○ Impact: Unauthorized access to database, data theft, and potential data
modification or deletion.
 ○ Evidence: Exploited search functionality with payloads such as ' OR 1=1 -
-, revealing sensitive database information.
○ Recommendation: Implement prepared statements (parameterized queries)
and validate all user inputs using a whitelist approach.
2. HTML Injection

○Description: HTML content injected into user inputs is rendered directly on

pages, leading to cross-site scripting (XSS) vulnerabilities.
○ Impact: Allows attackers to perform phishing, manipulate page content, and
steal sensitive information.
○ Evidence: Reflected HTML injection through URL parameters, demonstrated
by payloads like <script>alert('XSS')</script>.
○ Recommendation: Sanitize all user inputs using functions like
htmlspecialchars() and implement a strict Content Security Policy
(CSP).
3. OS Command Injection

○ Description: User inputs are executed as OS commands without proper

sanitization.
○ Impact: Full system compromise, allowing attackers to access sensitive files
and control the server.
○ Evidence: Executed commands such as ; cat /etc/passwd, confirming
the vulnerability.
○ Recommendation: Restrict user inputs to predefined acceptable values and
avoid using functions like system() or exec().

4.2 High Vulnerabilities

1. Insecure Session Management

○ Description: Sessions can be hijacked through manipulation of session

cookies or lack of secure flags.
○ Impact: Unauthorized access to user accounts and sensitive data.
○ Evidence: Demonstrated session replay using stolen PHPSESSID values.
○ Recommendation: Implement HttpOnly and Secure flags on cookies and
regenerate session IDs upon login/logout.
2. Directory Traversal

○ Description: Crafted input allows attackers to traverse directories and access

system files.
○ Impact: Exposure of sensitive configuration files and server information.
○ Evidence: Retrieved sensitive files like /etc/passwd using traversal
payloads.
○ Recommendation: Validate and restrict user inputs to prevent directory
traversal attempts.
4.3 Medium/Low Vulnerabilities

● Cleartext Transmission of Credentials: Detected during login, exposing

usernames and passwords.
○ Recommendation: Enforce HTTPS for all communications.
● Insecure Storage of Secrets in HTML5 Web Storage: Allows access to sensitive
data through browser developer tools.
○ Recommendation: Store secrets securely on the server side.

5. Remediation
1. Implement Input Validation

○ Validate all inputs using allowlists to prevent injection attacks.

○ Strip or encode special characters where applicable.
2. Adopt Secure Coding Practices

○Use modern frameworks with built-in security measures (e.g., Django,

ASP.NET).
○ Follow secure development lifecycle (SDL) practices.
3. Apply Secure Configuration Settings

○ Enforce HTTPS across all endpoints.

○ Implement Content Security Policies (CSP) to block unauthorized scripts.
○ Configure secure headers (e.g., X-Content-Type-Options, X-Frame-Options).
4. Regular Security Assessments

○ Conduct periodic penetration tests and vulnerability scans to identify new

threats.
5. Incident Response Plan

○ Develop and test a robust incident response plan to address discovered

vulnerabilities promptly.

6. Conclusion
The bWAPP application contains multiple critical and high-severity vulnerabilities that pose
significant security risks. Addressing these issues with the recommended remediation steps
will greatly enhance the application’s security posture and reduce exposure to threats.
Ongoing assessments and adherence to secure coding standards are essential for
maintaining long-term security.

7. Appendix
● Tools Used:

○ Nmap: Network scanning and port mapping.

 ○ Burp Suite: Proxy and vulnerability scanner.
○ OWASP ZAP: Automated vulnerability scanning.
○ Nikto: Web server vulnerability scanner.
○ SQLMap: Automated SQL Injection exploitation tool.
● Key Payloads:

○ SQL Injection: ' OR 1=1 --

○ HTML Injection: <script>alert('XSS')</script>
○ OS Command Injection: ; cat /etc/passwd
● References:

○ OWASP Testing Guide

○ CVSS Scoring System