The Purple Team Journey by Ozz961

  Bash Scripting for Beginners — Level 1: Linux Command-Line Foundations Series: Bash Scripting for Beginners Level: 1 — Beginner Environment: Ubuntu Terminal Focus: File listing, navigation, copying, permissions, searching, and user management Introduction Welcome to Level 1 of this Bash scripting series! Before writing scripts that automate tasks, you need to understand how to interact with Linux through the command line. The terminal allows you to navigate directories, inspect files, manage permissions, search the filesystem, and administer user accounts. These skills are especially useful in cybersecurity, where you may need to investigate files, inspect permissions, manage Linux systems, or automate repetitive tasks. In this lesson, we'll work through seven practical exercises using Ubuntu. What you'll learn By the end of this lesson, you should be able to: List files and inspect their permissions. Navigate a directory structure using relative paths. Copy files using c...

 In this lab titled “Information Disclosure in Version Control History” , the objective was to identify and exploit sensitive data exposure caused by improper handling of version control artifacts, specifically an exposed .git directory on a web server. The engagement began with a reconnaissance phase, where I performed directory brute-forcing using dirsearch to enumerate hidden paths and commonly exposed files. During this enumeration, I discovered that the target was serving the .git directory over HTTP, which immediately indicated a high-risk misconfiguration. Exposed Git metadata often allows reconstruction of the entire source code repository, including commit history, branches, and previously deleted sensitive information. Following the discovery, the next phase focused on extracting the repository contents from the exposed .git directory. Instead of manually reconstructing the repository structure, I used an automated Git dumping utility sourced from GitHub designed spe...

Introduction In this lab, the objective was to gain access to an administrative interface protected by authentication controls. Through systematic enumeration and analysis of application behavior, I identified a trust issue involving client-controlled headers combined with information disclosure through an unexpected HTTP method. This write-up explains the methodology, findings, exploitation process, and root cause behind the vulnerability. Initial Enumeration The first step involved enumerating application endpoints and observing how the server responded to different requests. During testing, I discovered the following endpoint: GET /admin The server returned: HTTP/1.1 401 Unauthorized A 401 Unauthorized response indicated that the endpoint existed but required additional authorization rather than being inaccessible or nonexistent. HTTP Method Testing To understand whether the endpoint handled different HTTP methods differently, I tested multiple request methods against /admin . Most...

This exercise was completed as part of a PortSwigger Web Security Academy lab focused on information disclosure through exposed debug endpoints . The goal of the lab was to identify hidden resources on the target application and retrieve a secret value exposed through a debug interface. The scenario simulates a real-world misconfiguration where development or debugging features are accidentally left enabled in a production environment. Such features often expose sensitive system information, including environment variables, configuration data, and internal application details that should never be publicly accessible. Reconnaissance and Hidden Directory Discovery The first step involved performing directory enumeration against the target application to identify hidden or unlinked paths. Since the vulnerable endpoint was not visible through normal navigation, content discovery techniques were required. During brute-force enumeration, the directory /cgi-bin was discovered. This direct...

This exercise was completed as part of a PortSwigger Web Security Academy lab focused on information disclosure vulnerabilities caused by exposed backup files . The purpose of the lab is to demonstrate how sensitive information can be unintentionally leaked through misconfigured web servers that expose development artifacts such as backup files and source code. The scenario simulates a real-world web application where hidden directories are accessible over the internet and contain files that were never intended to be publicly available. These types of issues are common in misconfigured deployments where backup files are left inside web roots or where directory listing protections are not properly enforced. The objective of the lab was to locate a backup file containing application source code, analyze it, and retrieve a hard-coded database password embedded within the code. This password would then be submitted to complete the lab. Reconnaissance and Content Discovery The first step in...

In this lab, the objective was to identify sensitive information exposed through unhandled application errors. Using Burp Suite, HTTP requests were intercepted while browsing product pages. Each request contained a productId parameter, which was observed in the intercepted traffic within the proxy history. The request GET /product?productId=1 was selected for further testing and sent to Burp Repeater to allow controlled modification and analysis of the parameter behavior. In Burp Repeater, the productId parameter was modified from its expected integer value to a non-numeric format ( 1/2 ). This alteration was used to test how the backend handles unexpected input types. The application failed to process the request correctly and triggered an unhandled exception. Instead of returning a controlled error response, the server generated and returned a detailed stack trace in the HTTP response. The stack trace contained internal application information that is typically restricted in pro...

 In this lab, the vulnerability is demonstrated through a live chat feature that relies on a WebSocket connection for real-time communication. When the user clicks “Live chat” and sends a message, the browser establishes a persistent WebSocket session with the server. Using Burp Suite, this traffic can be observed in the WebSockets history tab, where each chat message appears as a WebSocket frame being transmitted through the connection. To begin exploring the application’s security controls, the WebSocket message is right-clicked and sent to Repeater. From there, the payload is modified to include a basic cross-site scripting attempt such as an image tag with an error handler, for example <img src=1 onerror='alert(1)'> . When this modified message is resent through the WebSocket channel, the application responds by blocking the payload. More importantly, the WebSocket connection is immediately terminated, indicating that some server-side filtering or intrusion detection...

Cross-site WebSocket hijacking is a vulnerability that arises when a WebSocket endpoint accepts connections without properly validating the origin of the request or protecting the handshake with anti-CSRF mechanisms. In this lab scenario, a live chat feature is implemented using WebSockets to support real-time communication between users and a support agent. When a user opens the chat and sends a message, the application establishes a persistent WebSocket connection. This connection is then reused not only for live messaging but also for retrieving historical chat data from the server, which introduces a sensitive data exposure surface. The initial interaction begins by clicking “Live chat” and sending a chat message. This establishes the WebSocket connection and allows normal communication. When the page is reloaded, the application automatically reconnects to the WebSocket endpoint. At this point, Burp Suite’s WebSockets history tab reveals an important behavior: the client sends a R...

In this lab, the vulnerability is explored through a live chat feature that uses WebSockets for real-time communication between the user and a support agent. The interesting part is not just that messages are sent in real time, but how they can be intercepted and modified in transit, which ultimately exposes a stored XSS issue. The attack begins by opening the Live chat interface and sending a normal chat message. At this stage, the application behaves as expected: the message is transmitted instantly and appears in the chat window. However, under the surface, this message is not using a standard HTTP request. Instead, it is being sent over a persistent WebSocket connection. To confirm this, Burp Suite is used as an intercepting proxy. Inside Burp, the WebSockets history tab shows that the chat message is indeed being transmitted through a WebSocket frame. This is an important observation because it confirms that the communication bypasses traditional HTTP request logs and instead fl...

 The Bypassing Access Controls Using Email Address Parsing Discrepancies vulnerability is a sophisticated example of how inconsistencies between different parsing mechanisms can undermine otherwise well-intentioned access control restrictions. In this lab, the application attempts to restrict account registration to users with email addresses belonging to a trusted internal domain. The intention is to ensure that only legitimate users associated with the organization can create accounts and access privileged features. However, the application validates email addresses using one interpretation method while the underlying email delivery system parses them differently. This discrepancy creates an opportunity for attackers to craft specially encoded email addresses that pass validation but deliver confirmation emails to attacker-controlled inboxes. The attack begins by identifying the registration restriction enforced by the application. When opening the registration page and attempti...

 The Authentication Bypass via Encryption Oracle vulnerability demonstrates how cryptographic functionality can be abused when an application exposes both encryption and decryption behavior to the client. In this lab, the application uses encrypted cookies to store authentication and notification data. Although the encryption itself may be technically strong, the application leaks enough information through different endpoints to act as an encryption oracle and a decryption oracle , allowing an attacker to forge valid authentication tokens and impersonate another user. The attack begins by logging in as a normal user with the “Stay logged in” option enabled. After authentication, the server issues a stay-logged-in cookie. By inspecting the request and response in Burp Suite, it becomes clear that this cookie is encrypted rather than plain text. This suggests that the application uses the cookie to persist authentication state securely. At this point, the attacker does not know ...