Drag
0

Breach2Alert: Real-Life Web Application Hacking with Kali Linux, Burp Suite & SplunkDetection

Portfolio Thumbnail

Overview

The Breach2Alert project is a hands-on exploration of real-world web application hacking and threat detection. Leveraging the vulnerable OWASP Juice Shop running in a Docker container on Kali Linux, I simulate various attack scenarios using tools like Burp Suite to exploit common OWASP Top 10 vulnerabilities. This offensive approach is paired with defensive monitoring through Splunk, where logs and events generated by the attacks are collected, analyzed, and visualized. The project demonstrates how attackers operate and how security teams can detect and respond to threats in real time using a powerful Security Information and Event Management (SIEM) platform.

Objectives

  1. + Simulate realistic web application attacks on OWASP Juice Shop to understand common vulnerabilities and exploitation techniques.
  2. + Collect and forward application and system logs from the attacked environment into Splunk for centralized analysis.
  3. + Develop effective Splunk queries and dashboards to identify and visualize attack patterns and suspicious behaviors.
  4. + Configure real-time alerts within Splunk to notify security teams of detected malicious activities promptly.
  5. + Demonstrate a comprehensive end-to-end workflow combining offensive testing with defensive detection, highlighting skills vital for SOC analyst roles.

Project Setup & Environment Overview

Architecture & Setup

  • Kali Linux — Host operating system running all tools and Docker containers.
  • OWASP Juice Shop — Vulnerable web app deployed via Docker, accessible on localhost:3000.
  • Docker — Container platform used to isolate and manage the Juice Shop environment.
  • Burp Suite — Intercepting proxy to inspect and manipulate HTTP(S) traffic between the browser and Juice Shop.
  • Google Chrome — Configured with Burp Suite’s CA certificate to securely intercept HTTPS traffic.
  • Splunk — SIEM platform collecting and analyzing logs from Juice Shop and system events for real-time detection.

Steps to Intercept Juice Shop Traffic with Burp Suite

  1. Run Juice Shop Docker container:
    docker run --rm -p 3000:3000 bkimminich/juice-shop
  2. Launch Burp Suite and open the Proxy tab.
  3. Verify Burp Proxy Listener is enabled on 127.0.0.1:8080  (default).
  4. Configure Google Chrome proxy settings:
    • Set manual proxy to 127.0.0.1:8080.
    • Or launch Chrome with proxy flag: chrome --proxy-server=http://127.0.0.1:8080
  5. Install Burp CA certificate in Chrome:
    • Export from Burp: Proxy → Intercept → “CA Certificate”.
    • Import into Chrome’s Trusted Root Certificate Authorities.
  6. Open Juice Shop in Chrome: Navigate to http://localhost:3000. Burp Suite will now intercept traffic.
  7. Start testing: Intercept, analyze, and manipulate HTTP(S) requests to explore vulnerabilities.

Splunk Setup & Log Ingestion from Juice Shop

Splunk & Burp Suite Setup Overview

  • Splunk Enterprise runs locally in a Docker container, ingesting and analyzing logs.
  • OWASP Juice Shop web app runs in Docker on Kali Linux, generating HTTP traffic.
  • Burp Suite intercepts and captures HTTP requests/responses as you interact with Juice Shop.
  • HTTP history is manually exported from Burp Suite in uncoded XML format for easy ingestion into Splunk.

Step-by-Step Splunk & Burp Manual Log Workflow

  1. Start Splunk Docker container:
    docker run -d -p 8000:8000 -e SPLUNK_START_ARGS="--accept-license" \
  -e SPLUNK_PASSWORD="changeme" --name splunk splunk/splunk:latest
  2. Access Splunk UI: Open http://localhost:8000  and log in as:
    • Username: admin
    • Password: changeme
  3. Interact with Juice Shop using Burp Suite:
    • Open Burp Suite and configure your browser to use Burp as a proxy.
    • Make sure Intercept is OFF to allow traffic capture in HTTP history.
    • Browse the Juice Shop app to generate HTTP requests.
  4. Export HTTP history from Burp Suite:
    • Go to Proxy → HTTP history tab.
    • Click Save to file and select XML format (not encoded).
    • Fix XML declaration manually if needed (<?xml version="1.0"?>).
  5. Upload HTTP history to Splunk:
    • Go to Splunk UI → Settings → Add Data → Upload.
    • Select the exported Burp XML file.
    • Set Index to juiceshop (create if needed).
    • Set Sourcetype to burp:httphistory  or similar.
    • Complete the wizard to ingest the data.
  6. Verify logs in Splunk:Run this SPL query to preview the imported HTTP history:
    index=juiceshop sourcetype=burp:httphistory | head 20

What's Next?

After you become familiar with the HTTP logs from Juice Shop and Burp Suite, the next steps are to perform targeted vulnerability testing. We will simulate attacks such as SQL injection, broken authentication, and more. Then, we'll ingest the corresponding logs into Splunk, build detailed SPL queries to detect these attacks in real-time, and configure alerts to mimic a real SOC environment — showing your expertise in both offense and defense. This comprehensive workflow will impress recruiters with your hands-on, end-to-end security monitoring skills.

Vulnerability Exploitation & Detection Overview

SQL Injection (Login Bypass)

SQL Injection (SQLi) is one of the most dangerous vulnerabilities, allowing attackers to manipulate database queries via unsanitized user inputs.

🔍 How It Works

The website has a login form: SELECT * FROM users WHERE email='[user]' AND password='[pass]'; If we enter: Email: ' OR 1=1-- Password: anything The query becomes: SELECT * FROM users WHERE email='' OR 1=1--' AND password='anything'; 👉 OR 1=1 is always true, and -- comments out the rest. 💥 Result: Login bypassed without valid credentials.

🧪 Exploitation Steps

1. Open Juice Shop in your browser. 2. Go to the login form. 3. Enter: Email: ' OR 1=1-- Password: anything 4. You’ll be logged in as admin without knowing credentials. 5. Congrats — you exploited SQL Injection! ✅ Challenge Solved: "Login Admin"

🧰 Burp Suite Tips

1. Intercept the login request in Burp Suite. 2. Forward the request to Repeater. 3. Modify the "email" field payload to: ' OR 1=1-- 4. Send the request. If the app is vulnerable, you'll receive a 200 OK and an authentication token. 👉 See image below showing the Repeater request & token response. 5. You can export the HTTP history to XML for log analysis in Splunk.

📊 SPL Detection Query

index=juiceshop sourcetype=burp 
| search "OR 1=1" OR "1=1--" OR "' OR '" 
| stats count by _time, host, ip

🛡️ Mitigation & Protection

- Use Prepared Statements (e.g., parameterized queries). - Input validation: never trust user input. - Use ORM frameworks to abstract direct SQL. - Apply Web Application Firewalls (WAF) to detect common payloads. - Regularly test your app using DAST tools like OWASP ZAP or Burp.

Broken Access Control (Challenge Metadata Leak)

This vulnerability demonstrates how attackers can access internal challenge metadata via an unauthenticated API endpoint in OWASP Juice Shop, revealing internal logic that should be hidden.

🔍 How It Works

Juice Shop exposes an API endpoint at /api/challenges that returns sensitive internal data. Example: GET /api/challenges?sort=name This endpoint reveals: - Challenge names - Hints - Whether they’ve been solved - Logical internals used to score progress This data should be access-restricted or obfuscated, but is publicly exposed. 💡 This is a realistic Broken Access Control vulnerability because it allows attackers to programmatically map the app’s internal logic and scoring mechanism.

🧪 Exploitation Steps

1. Open Juice Shop in your browser. 2. In DevTools → Network tab, refresh the page. 3. Find the request to: /api/challenges?sort=name 4. Right-click → Open in new tab OR copy as cURL. 5. Send it without authentication headers — you'll still get the full JSON response. 6. Parse the data to identify hidden or unsolved challenges and how the app internally scores them. ✅ Challenge Solved: "Access Score Board"

🧰 Burp Suite Tips

1. Open Burp Suite and intercept any request on Juice Shop. 2. Manually craft a new GET request to: /api/challenges?sort=name 3. Send it to Repeater. 4. Remove all auth headers. 5. Send the request and observe the JSON response revealing internal challenge metadata. 🧠 Pro Tip: This data can be used for automated challenge solving or recon scripting.

📊 SPL Detection Query

index=juiceshop sourcetype=burp 
| search "/api/challenges" 
| stats count by _time, host

🛡️ Mitigation & Protection

- Implement strict access control on internal API endpoints. - Apply Role-Based Access Control (RBAC) to protect metadata routes. - Avoid exposing unnecessary internal logic to the frontend. - Use API gateway or middleware to verify auth tokens before serving responses. - Regularly audit and test your API for unauthorized access using tools like ZAP/Burp.

Related Projects

Work with me

I would love to hear more about your project

Let’s talk