case study
Attacks
This section demonstrates hands-on exploitation of OS Command Injection, Stored Cross-Site Scripting (XSS), and Server-Side Request Forgery (SSRF) within an intentionally vulnerable threat intelligence application deployed in an isolated Docker environment. Each attack was tested from initial discovery through exploitation and impact validation, followed by analysis of the root cause and recommended remediation.
The application was deployed locally in an isolated Docker environment, providing a controlled target for testing realistic web application attack techniques and validating their security impact.
-Docker Desktop + Docker Compose v2 (Linux).
-Git used for local source control and application management.
-Optional: Node.js 22 only if you develop the app outside Docker (npm run dev).
#Deploy Insecure Threat Intel App
I deployed the vulnerable threat intelligence application as a three container Docker environment consisting of the application, PostgreSQL database, and Nginx reverse proxy.
INSECURE-threat-intel-app runs three containers:
| Service | Image / build | Port | Role |
| postgres | postgres:16-alpine | internal | Database with synthetic dashboard.panel_feed and lab vulnerability tables |
| app | Built from Dockerfile | internal (4321) | Astro dashboard, login, six feed panels, integrated product features |
| nginx | nginx:1.27-alpine | 8081 → 80 | Reverse proxy in front of the app so you browse without the :4321 port |
Network Topology (local)
Browser :8081
↓
[nginx] reverse proxy (:80)
↓
[app container] Astro SSR + auth (:4321, internal)
↓
[postgres] synthetic panel data + lab vulnerability tables1.Start Vulnerable Lab Environment
I started the Docker Compose environment and verified that the PostgreSQL database, Astro application, and Nginx reverse proxy containers were running successfully.
npm run docker:up
docker-compose -f docker/docker-compose.yml up --build
2.Verify Vulnerable Application
I accessed the application through the local Nginx endpoint on port 8081 and authenticated to verify that the vulnerable dashboard was operational before beginning attack testing.
#IDOR Attack
I tested the vulnerable threat intelligence application for an Insecure Direct Object Reference (IDOR) vulnerability by analyzing how authenticated users access internal documents. Using Burp Suite, I identified a predictable document reference, enumerated object IDs, and confirmed that the analyst account could access a sensitive document belonging to another user. The test demonstrated a broken access control condition caused by missing server-side ownership validation.
##Attacker Methodology
1.Identify Direct Object Refrence
I authenticated as the analyst user and reviewed the Documents section. Opening one of the analyst's authorized documents revealed that individual records were retrieved using a numeric id parameter.
For example:
/documents?id=1001
This identified a predictable direct object reference that could be tested for broken access control.
2.Capture Authorized Request
I captured the document request in Burp Suite and sent it to Intruder for controlled enumeration. The authenticated request provided a baseline for testing whether modifying only the document ID could expose records outside the analyst user's authorized resources.
3.Enumerate Document References
I configured Burp Intruder to modify the id parameter and test additional sequential document references. Because the application used predictable numeric identifiers, nearby IDs could be enumerated without modifying the authenticated session.
id parameter.4.Identify Unauthorized Document
The enumeration identified id=1011 as a valid document outside the analyst user's visible document set. The server returned the record successfully rather than rejecting the request based on ownership.
This demonstrated that the application was retrieving documents based on the supplied ID without adequately validating whether the authenticated user was authorized to access the requested object.
1011 during enumeration, revealing a valid record outside the analyst user's authorized document set.5.Confirm Horizontal IDOR
I requested document 1011 while remaining authenticated as analyst. The application displayed a Sensitive document belonging to bob, confirming horizontal privilege escalation through IDOR.
The record was not exposed through the analyst user's normal interface, but remained directly accessible by manipulating the document reference.
##Finding
-Vulnerability: Insecure Direct Object Reference (IDOR) / Broken Access Control
-Affected endpoint: GET /documents?id={id}
-Affected parameter: id
-Authorized objects: 1001–1005
-Unauthorized object accessed: 1011 (Bob's sensitive document)
Impact: An authenticated user can access another user's sensitive records.
Root cause: The server retrieves documents by object ID without enforcing ownership authorization.
##Remediation
-Enforce server-side authorization on every object request using ownership validation or role-based access control (RBAC).
-Use non-guessable object identifiers together with authorization controls rather than relying on obscurity alone.
-Implement integration tests to verify that one authenticated user cannot access resources belonging to another user.
#SQL Injection (SQLi) Attack
I tested the vulnerable threat intelligence application for SQL Injection (SQLi) by analyzing database backed inputs with Burp Suite. Testing identified SQL injection vulnerabilities in both the Marketplace search and authentication functionality. I demonstrated the impact by manipulating the Marketplace query to return unintended records and exploiting the login request to bypass password validation.
##Attacker Methodology
1.Identify Marketplace Search Input
I identified the Marketplace search field as a database backed input and submitted a normal search request to establish the application's expected behavior before testing for SQL injection.
2.Capture Marketplace Request
I captured the Marketplace request in Burp Suite and sent it to Repeater, allowing the q parameter to be modified and tested independently.
3.Establish Baseline Response
I sent the legitimate Marketplace request to Repeater and reviewed the 200 OK response to establish the application's normal behavior before modifying the query.
4.URL-Encode SQL Injection Payload
I used Burp Decoder to URL-encode the SQL injection payload so it could be safely inserted into the Marketplace q parameter for testing.
5.Confirm Marketplace SQL Injection
I inserted the encoded payload back into the Marketplace request and submitted it through Repeater. I tested variations of the SQL payload and compared the resulting responses, using the 200 OK status and changes in returned records to identify successful query manipulation. A working boolean based payload caused the application to return records outside the intended search criteria, confirming SQL injection in the Marketplace search functionality.
6.Test Authentication for SQL Injection
I tested the application's authentication functionality for a second SQL injection vector. I supplied SQL syntax in the username field to alter the backend authentication query and comment out the password validation portion of the statement.
7.Confirm Authentication Bypass
The manipulated login request successfully authenticated as analyst without requiring the correct password, confirming an authentication bypass through SQL injection.
analyst without providing the valid account password.##Finding
-Vulnerability: SQL Injection (SQLi)
-Affected endpoints: GET /marketplace?q={query} and POST /api/auth/login
-Affected parameters: q, username
-Marketplace impact: Manipulation of query logic and unauthorized disclosure of product records
-Authentication impact: Authentication bypass without a valid password
Impact: An attacker can manipulate backend SQL queries to retrieve unintended database records and bypass application authentication, potentially providing unauthorized access to protected application functionality.
Root cause: User-controlled input is incorporated into SQL queries without proper parameterization, allowing supplied SQL syntax to modify the intended query logic.
##Remediation
-Use parameterized queries / prepared statements for all database operations.
-Avoid raw SQL or ORM query fragments containing untrusted user input.
-Apply least-privilege permissions to application database accounts.
-Use a WAF only as a compensating control; the underlying vulnerable code path must be corrected.
#Command Injection Attack
I tested the threat intelligence application for OS command injection and identified the artifact parameter in the Ingest Artifact Integrity Check as vulnerable. By manipulating the parameter with shell metacharacters and chained commands, I confirmed arbitrary command execution as root within the application container and demonstrated access to local system files.
##Attacker Methodology
1.Identify Command Injection Attack Surface
I reviewed the application's functionality to identify features that could invoke operating system commands. The Tools → Ingest Artifact Integrity Check was identified as the primary target because it processes the user-controlled artifact parameter through a server-side file hashing operation.
2.Establish Legitimate Integrity Check Baseline
I submitted a valid staged artifact through the Ingest Artifact Integrity Check and verified that the application returned the expected SHA-256 hash. I then captured the corresponding GET /tools?artifact= request in Burp Suite and sent it to Repeater to establish a clean baseline before modifying the parameter.
Baseline artifact:
feed-2026-01-05.jsonExpected response:
b1946ac92492d2347c6235b4d2611184… /tmp/cti-ingest/feed-2026-01-05.jsonBurp:
Burp Suite Validation:
I captured the legitimate GET /tools?artifact=feed-2026-01-05.json request in Burp HTTP History and sent it to Repeater, preserving the original request and response as a clean baseline for comparison against subsequent command injection tests.
3.Test Shell Metacharacter Handling
I modified the artifact parameter in Burp Repeater by appending shell metacharacters such as ; and |. This allowed me to test whether the application properly validated the supplied filename or passed the value into a shell command without sufficient sanitization.
feed-2026-01-05.json;
feed-2026-01-05.json|
Observation: The modified requests were used to determine whether shell metacharacters affected server-side processing of the artifact parameter before attempting command execution.
4.Confirm Command Injection Through Command Chaining (; or &&)
I tested command chaining by appending controlled operating system commands to the legitimate artifact filename using the ; and && shell operators. The id payload successfully executed and returned operating system account information in the application response.
feed-2026-01-05.json; id
feed-2026-01-05.json && hostname
id command to the artifact value. The returned uid=0(root) output demonstrates command execution as root within the application container.This confirmed that the application passed the user-controlled artifact value into a shell command without sufficient validation, allowing arbitrary operating system command execution. The id command returned uid=0(root) gid=0(root) groups=0(root), confirming that the injected command executed as the root user inside the application container. Because UID 0 represents the root account on Linux systems, successful command injection provides the attacker with the highest privilege level available within the container, significantly increasing the potential impact of the vulnerability.
Root Cause Evidence
The successful payload demonstrated that the user-controlled artifact value was incorporated directly into a shell command. The application effectively executed:
sha256sum/tmp/cti-ingest/feed-2026-01-05.json;id5.Validate Command Execution Impact
After confirming command injection, I tested additional controlled commands to determine the level of access available through the vulnerable artifact parameter. These tests demonstrated that the vulnerability could be used to execute arbitrary operating system commands and potentially access files within the application container.
feed-2026-01-05.json; whoami
feed-2026-01-05.json; uname -a
feed-2026-01-05.json; cat /etc/passwd
whoami, which returned root from within the application container.
/etc/passwd, confirming that the vulnerability could be used to access operating system files within the application container.These tests demonstrated that the command injection vulnerability extended beyond execution of a single command and could be used to enumerate the container environment and access local system files.
##Finding
-Vulnerability: OS Command Injection
-Affected endpoint: GET /tools?artifact={artifact}
-Affected parameter: artifact
-Baseline: feed-2026-01-05.json → expected SHA-256 hash
-Confirmed payload: feed-2026-01-05.json; id
-Execution context: uid=0(root)
-Additional impact: Arbitrary command execution and local file access within the application container
Impact: An authenticated attacker capable of controlling the artifact parameter can inject operating system commands that are executed by the application container. Testing confirmed execution as root, significantly increasing the potential impact and allowing access to local system resources.
Root cause: The application incorporates the user-controlled artifact value directly into a shell command without sufficient input validation or separation between user input and command execution.
##Remediation
-Avoid invoking a shell with user-controlled input. Use native hashing APIs or execute system utilities with fixed argument arrays rather than constructing shell command strings.
-Apply strict allowlisting to artifact filenames and reject shell metacharacters or unexpected path values.
-Resolve and validate artifact paths within the intended ingestion directory.
-Run the application using a least-privileged service account rather than root to reduce the impact of successful command execution.
-Maintain container isolation and restrict access to unnecessary files, capabilities, and host resources.
#XSS Attack
I tested the threat intelligence application for stored Cross-Site Scripting (XSS) through the Shift Collaboration feature. User-controlled content was stored and rendered as active HTML, allowing a persistent payload to execute when the affected page was viewed.
##Attacker Methodology
1.Identify Potential XSS Attack Surface
I reviewed the application for locations where user-controlled content could be rendered in the browser. Dashboard content was server generated and did not provide an obvious injection point, so I focused on application features that accepted and displayed persistent user input.
2.Identify User-Controlled Persistence Point
I identified Tools → Shift Collaboration as a potential stored XSS attack surface because the feature accepts analyst supplied case references and shift notes, stores the submitted content, and displays it to users who load the page. This persistence made the shift note field a candidate for stored XSS testing.
3.Establish Normal Input Baseline
I submitted a legitimate shift note to establish the applications expected behavior before introducing test payloads. The note was successfully stored and displayed in the Shift Collaboration thread, confirming that user-supplied content persisted across page loads.
4.Test HTML Rendering and Output Encoding
I tested the persistent Shift Collaboration input with harmless HTML to determine whether user-controlled content was safely encoded or interpreted by the browser. The HTML was rendered rather than displayed as literal text, indicating that output encoding was not being properly enforced and that the feature warranted further XSS testing.
| Field | Value |
| Case reference | 4471 |
| Shift note | Callback observed: <code>203.0.113.44</code> — escalate if persistence confirmed. |
Probe Analysis
The <code> tag was intentionally used as a harmless HTML probe rather than immediately attempting script execution. The IP address 203.0.113.44 served as visible test content. When the application rendered the IP using the <code> formatting instead of displaying the tags as literal text, it demonstrated that the stored shift note was being interpreted as HTML. This provided evidence of an unsafe rendering path and justified progressing to an XSS payload.
5.Confirm Stored XSS Through Malicious HTML
I escalated the HTML rendering test by submitting a crafted image element containing an onerror event handler. The payload was stored within the Shift Collaboration thread and designed to execute JavaScript when the referenced image failed to load.
Lookalike login page at projectzero-secure[.]lab. Callback 203.0.113.44:443.<br>
Mandiant report excerpt (screenshot):<br>
<img src="/vault/reports/case4471.png" alt="landing page capture" onerror="this.insertAdjacentHTML('afterend','<div style="position:fixed;inset:0;background:rgba(9,9,11,.9);display:flex;align-items:center;justify-content:center;z-index:50"><div style="background:#18181b;border:1px solid #3f3f46;border-radius:12px;padding:2rem;max-width:360px"><h3 style="margin:0 0 .5rem;color:#fafafa;font-size:18px">Session expired</h3><p style="margin:0 0 1rem;color:#a1a1aa;font-size:13px">Re-authenticate to view restricted IOC attachments.</p><input placeholder="Password" type="password" style="width:100%;padding:.5rem;margin-bottom:.75rem;border-radius:6px;border:1px solid #3f3f46;background:#09090b;color:#fafafa"><button style="width:100%;padding:.5rem;border-radius:6px;background:#0284c7;color:white;border:none">Continue</button></div></div>')">
Execution Result
After reloading the Tools page, the stored payload was rendered and the onerror handler executed automatically. The injected JavaScript created a fake Session expired authentication prompt, confirming persistent JavaScript execution in the user's browser.
Because the payload executes whenever the stored content is rendered, an attacker could potentially manipulate page content, perform actions within the victims authenticated session, or present convincing phishing interfaces. In a real attack, captured information could potentially be transmitted to attacker-controlled infrastructure.
6.Confirm Stored XSS Persistence
I reopened the Tools page without resubmitting the payload. The payload executed again, confirming that it was persistently stored by the application rather than reflected only in the original request.
7.Assess XSS Impact
The stored payload could execute when another user views the affected content. Although HttpOnly protects the session cookie from direct JavaScript access, XSS could still manipulate page content, perform actions within the victim's authenticated session, or present phishing interfaces.
##Finding
-Vulnerability: Stored Cross-Site Scripting (XSS)
-Affected feature: Tools → Shift Collaboration
-Affected input: Shift note
-Injection point: User-controlled HTML stored and rendered in the collaboration thread
-Confirmed payload: HTML containing an onerror event handler
-Execution: Payload persisted and executed when the affected page was loaded
-Security control: Session cookie protected with HttpOnly
Impact: An authenticated attacker can store malicious client-side content that executes when another user views the affected thread. Successful exploitation could manipulate page content, perform actions within the victim's authenticated session, or present convincing phishing interfaces.
Root cause: User-controlled shift notes are rendered as active HTML without proper contextual output encoding, allowing injected HTML and JavaScript event handlers to execute in the browser.
##Remediation
-Apply contextual output encoding when rendering user-controlled content so submitted HTML is displayed as text rather than interpreted by the browser.
-Avoid unsafe HTML rendering mechanisms such as set:html for untrusted input. If rich HTML is required, sanitize it with a vetted allowlist-based sanitizer.
-Implement a restrictive Content-Security-Policy (CSP) that prevents inline JavaScript and event handlers from executing.
-Maintain HttpOnly and SameSite protections on session cookies as defense-in-depth.
-Test stored user input with XSS payloads after remediation to verify that injected markup no longer executes.
#SSRF Attack
I tested the CTI Reports image processing functionality for Server-Side Request Forgery (SSRF) by embedding controlled URLs within uploaded SVG files. Testing confirmed that the application resolved these resources server-side, allowing access to internal services and ultimately exposing simulated IAM credentials from an internal metadata endpoint.
##Attacker Methodology
1.Identify SSRF Attack Surface
I reviewed the application for functionality that caused the server to process or retrieve external resources. The CTI Reports feature was identified as a potential SSRF attack surface because uploaded cover images could contain references to external resources that were resolved by the server.
2.Create an SVG with an External Resource
I created a controlled SVG file containing an <image> element with an href pointing to a locally hosted web service:
The SVG was then uploaded through the CTI Reports → Cover image functionality. This tested whether the application would process the embedded URL and initiate the request server-side.
poc.svg as the CTI report cover image for server-side processing.The SVG was then uploaded through the CTI Reports → Cover image functionality. This tested whether the application would process the embedded URL and initiate the request server-side.
3.Confirm Server-Side Resource Retrieval
After uploading the crafted SVG, the application processed the embedded http://localhost:4321/ reference and returned the fetched HTTP response within the CTI report. This confirmed that the resource was retrieved by the application server rather than by the client browser.
This established the SSRF primitive: user-controlled content could influence where the server made outbound requests. I then used this behavior to determine whether resources beyond the application's normal external-facing functionality could be reached.
4.Probe Internal Application Services
After confirming server-side URL retrieval, I escalated the test by using the provided SSRF SVG to target an internal metadata style endpoint that was not intended to be directly accessible to the external user.
The application processed the embedded resource and returned an HTTP 200 response containing simulated IAM security credentials, including an access key, secret access key, session token, and role information.
This demonstrated the security impact of SSRF: an attacker could abuse the application's trusted network position to access internal services and retrieve information that would otherwise be inaccessible externally.
##Finding
-Vulnerability: Server-Side Request Forgery (SSRF)
-Affected feature: CTI Reports → Cover image upload
-Attack vector: SVG with attacker-controlled external resource reference
-Confirmed behavior: Server processed and fetched URLs embedded within uploaded SVG files
-Internal access: Application could reach resources accessible from its server-side network context
-Sensitive data exposure: Simulated IAM role credentials were retrieved from an internal metadata endpoint
-Impact: Internal service access and potential cloud credential exposure
Impact: An authenticated attacker able to upload a crafted SVG could force the application server to make requests to internal resources that are not normally externally accessible. Testing demonstrated retrieval of simulated IAM credentials, which could potentially allow further access to cloud resources based on the permissions assigned to the exposed role.
Root cause: The application processed attacker-controlled SVG content and resolved embedded URLs server-side without sufficiently restricting the destinations or resource types the server was permitted to access.
##Remediation
-Restrict or disable server-side resolution of external resources within uploaded SVG files.
-Validate uploaded files by actual content/type and reject SVGs containing external URL references when they are not required.
-Apply a strict allowlist of permitted outbound destinations rather than accepting arbitrary URLs.
-Explicitly block requests to loopback, private/internal networks, link-local addresses, and cloud metadata services.
-Apply network-level egress controls so the application can communicate only with services required for normal operation.
-Use least-privileged IAM roles so credential exposure has limited impact if another SSRF vulnerability is discovered.
#Why This Matters
These exercises demonstrate how seemingly legitimate application features can become attack paths when user-controlled input crosses security boundaries without proper validation. By exploiting Command Injection, Stored XSS, and SSRF, I demonstrated the ability to move beyond vulnerability identification and validate real security impact, including operating system command execution, persistent client-side code execution, internal service access, and exposure of simulated cloud credentials.
The project strengthened my ability to approach web applications from an attackers perspective, validate findings through controlled exploitation, assess their impact, identify root causes, and recommend practical defensive controls.