Penetration Test a LAN Web App

Run a full pentest on a local web app using Nmap and OWASP ZAP.

Introduction

30 Second Summary

Every web application you use online is sitting on a server somewhere, listening for connections. Some of those connections are intentional. Others are doors left wide open that nobody checked.

In this project, you will perform a structured penetration test against a real web application running on your local network. You will discover open ports, scan for vulnerabilities, and manually exploit weaknesses using the same methodology professional pentesters follow.

What You'll Build

By the end, you will have a vulnerability findings document from a real penetration test you conducted yourself, proving you can go from zero knowledge of a target to a categorized list of confirmed security weaknesses.

By the end of this project, you'll have:

  • A full network reconnaissance report showing every open port and the exact software versions running on the target, including services you did not expect to find.
  • An automated vulnerability scan report from OWASP ZAP with findings categorized by risk level, generated by sending real attack payloads against the application.
  • A manually confirmed vulnerability you discovered yourself by fuzzing high-value endpoints with injection payloads the automated scanner missed.
  • Secret Mission: Attempt Server-Side Request Forgery (SSRF) through the app's URL-accepting inputs to access internal network resources the server should never expose.

Are there any prerequisites?

No prior cybersecurity experience is required. You need a Mac with Homebrew installed and OWASP ZAP already on your machine. This guide covers the full setup for everything else, including Nmap installation and ZAP reconfiguration.

Before We Start

Before We Start...

Before diving in, take a moment to commit to what you are building and why. In penetration testing, having clear authorization and a defined scope is what separates ethical hacking from unauthorized access.

Set Up Your Tools

You have a target application and authorization to test it. But before you can discover what the server is exposing or launch any attacks, you need the right tools installed and configured.

In this step, you will install Nmap for network scanning and switch OWASP ZAP out of Safe Mode so it can actually perform security tests.

In this step, get ready to:
  • Install Nmap via Homebrew and verify it is working.
  • Create a dedicated workspace folder for your findings.
  • Reconfigure OWASP ZAP from Safe Mode to Protected Mode.
Install Nmap via Homebrew

Nmap is a network scanner that discovers open ports and identifies what software is running on a target machine. It is the first tool any penetration tester reaches for when starting reconnaissance.

  • Press Cmd+Space to open Spotlight.
  • Type Terminal and press Enter to open it.
  • Install Nmap using Homebrew by running this command:
brew install nmap

What does this command do?

Homebrew downloads the Nmap binary and all its dependencies, then links the nmap command into your shell path so you can run it from any terminal session.

Seeing an error during install?

If you see a message about Xcode Command Line Tools, run xcode-select --install first, then retry brew install nmap.

If Homebrew itself is not recognized, revisit the Homebrew installation at brew.sh. help me troubleshoot my Homebrew installation

.

  • Verify the installation by running:
nmap --version

Check the output and find the tab below that matches what you see.

✔️ I see Nmap version 7.99

Nmap is installed and ready. You are good to continue.

ⓧ I see an older version

You have a previous Nmap installation that is out of date. Upgrade it by running:

brew upgrade nmap

After the upgrade finishes, run nmap --version again to confirm it now shows 7.99.

ⓧ Command not found

The install did not complete successfully. Try running the install command again:

brew install nmap

If it still fails, check that your Homebrew installation is healthy by running:

brew doctor

Follow any instructions Homebrew provides to resolve issues, then retry the install. help me fix my Nmap installation

.

Create a workspace folder for your findings

Throughout this project, you will save scan outputs and notes. A dedicated folder keeps everything in one place so you can reference your findings later.

  • Create the pentest-findings folder in your home directory and move into it by running:
mkdir -p ~/pentest-findings && cd ~/pentest-findings
  • Confirm you are in the right location by running:
pwd

You should see a path ending in pentest-findings (something like /Users/yourname/pentest-findings).

Not seeing the right path?

If pwd shows a different location, run cd ~/pentest-findings to navigate there directly. If you get a "No such file or directory" error, run mkdir -p ~/pentest-findings first.

help me create and navigate to my pentest-findings folder

Reconfigure ZAP from Safe Mode to Protected Mode

OWASP ZAP is currently in Safe Mode, which blocks all dangerous operations. This means you cannot spider, actively scan, or fuzz any target. You need to switch to Protected Mode to unlock these capabilities.

  • Press Cmd+Space to open Spotlight.
  • Type OWASP ZAP and press Enter to open the application.
  • Wait for ZAP to fully load. You will see the main window with a toolbar at the top.
  • In the main toolbar, locate the mode dropdown. It currently displays Safe Mode.
  • Click the dropdown arrow to expand the list.
  • Select Protected from the dropdown.

The dropdown now displays Protected Mode. This change persists between sessions, so you will not need to set it again.

Why Protected Mode instead of Standard?

ZAP has four modes: Safe, Protected, Standard, and ATTACK. Standard Mode removes all restrictions, meaning you could accidentally attack any site you browse through ZAP.

Protected Mode unlocks all the dangerous operations (spidering, active scanning, fuzzing, force browsing, intercepting, and resending requests) but only against URLs you explicitly add to your scope. This prevents accidental damage to sites you do not intend to test.

Don't see the mode dropdown?

The mode dropdown is on the main toolbar, which runs horizontally across the top of the ZAP window just below the menu bar. Look for a dropdown that reads Safe Mode with a small arrow beside it.

If the toolbar is not visible, go to the View menu and ensure the toolbar is enabled. help me find the ZAP mode dropdown

.

Your tools are ready. You have Nmap installed for network scanning, a workspace to save your findings, and ZAP configured to perform real security tests. Next up, you will point Nmap at your target and discover every port and service it is exposing.

Run Network Reconnaissance with Nmap

Your tools are installed and ZAP is ready to attack scoped targets. Now it is time to find out what the server is actually exposing to the network.

You have a target IP address, but you do not know which ports are open, which services are listening, or what software versions are running. There could be unexpected services you are not aware of. This step uses network reconnaissance to reveal the full attack surface before you scan for vulnerabilities.

In this step, get ready to:
  • Run a full port scan with service fingerprinting to discover every open port and identify what software is running on each one.
  • Run NSE vulnerability scripts to check discovered services for known CVEs and misconfigurations.
  • Review and document findings to identify high-value targets for the next phase.
Run a full port scan with service and version detection

A standard scan only checks the top 1,000 ports and guesses service names from a lookup table. That misses unusual ports and tells you nothing about the actual software behind each one.

You will scan all 65,535 ports and probe each open one for its exact software version. This is the difference between knowing "port 8080 is open" and knowing "port 8080 is running Apache httpd 2.4.52".

Before you run this, think about your target application. How many ports do you expect to be open? Do you think there are services beyond the web interface?

  • Run the full port scan with version detection by running this command:
nmap -sV -p- [[TARGET_IP="your target's IP address"]] -oN ~/pentest-findings/nmap-scan.txt

What does this command do?

  • -sV enables version detection. Nmap probes each open port to identify the application name, version number, and protocol.
  • -p- scans all ports from 1 through 65,535 instead of just the default top 1,000.
  • -oN ~/pentest-findings/nmap-scan.txt saves the output in normal format to a file while also printing it to your terminal.

Why does this take a few minutes?

Nmap is probing all 65,535 possible ports on your target. For each open port it finds, it then sends additional probes to fingerprint the exact software and version. Expect this to take 2-5 minutes depending on your network speed and how many ports are open.

When the scan finishes, you will see a table with four columns: PORT, STATE, SERVICE, and VERSION.

Each row represents a discovered port. The VERSION column shows the exact software running on that port, such as OpenSSH 4.3 or Apache httpd 2.2.3.

Scan seems to hang or returns no results?

  • Confirm your target IP is correct and the machine is powered on by running ping followed by the IP. You should get replies back.
  • If Nmap shows all ports as filtered, a firewall between you and the target is blocking traffic. Make sure you are on the same LAN.
  • If you see a permissions error, try prefixing the command with sudo. Some scan types require elevated privileges on macOS.

help me troubleshoot my Nmap scan that is not returning results on macOS

Run NSE vulnerability scripts against discovered services

You now know which ports are open and what software is running. The next question is: are any of those software versions known to be vulnerable?

Nmap includes a library of NSE (Nmap Scripting Engine) scripts that automatically check for known CVEs, default credentials, and common misconfigurations.

  • Run the vulnerability scripts against your target by running this command:
nmap -sV --script vuln [[TARGET_IP="your target's IP address"]] -oN ~/pentest-findings/nmap-vuln.txt

What does this command do?

  • --script vuln runs Nmap's built-in vulnerability detection scripts against each discovered service. These scripts check for specific known exploits and misconfigurations.
  • The scan still uses -sV because the scripts need version information to determine which CVE checks apply to each service.
  • Results are saved to ~/pentest-findings/nmap-vuln.txt alongside your earlier port scan.

This scan will take a few minutes as well. When it finishes, you will see output beneath each port that includes vulnerability names, CVE identifiers, and whether the check passed or failed.

  • Confirm both scan files were saved by running:
ls ~/pentest-findings/

You should see nmap-scan.txt and nmap-vuln.txt listed in the output.

Only seeing one file?

  • Make sure the second scan completed without errors. If the script scan failed, check that your target is still reachable.
  • Confirm you included the -oN ~/pentest-findings/nmap-vuln.txt flag at the end of the command. Without it, results only print to the terminal and are not saved.

help me figure out why my Nmap vulnerability scan did not save to a file

Review your findings

You now have two scan reports. Time to read them like a pentester and identify what matters.

  • Open your port scan results by running:
cat ~/pentest-findings/nmap-scan.txt
  • Look at the port table and note down the following for each open port:

What should I look for?

Unexpected ports are high-value targets for the next phase. Database ports (like 5432 for PostgreSQL or 6379 for Redis), debug interfaces, and admin panels should not typically be exposed on the network.

Outdated software versions are also critical. If you see an old version of a web server or SSH daemon, that version likely has known CVEs you can look up.

  • Now open the vulnerability scan results by running:
cat ~/pentest-findings/nmap-vuln.txt
  • Look for lines containing CVE identifiers (formatted like CVE-2021-XXXXX) or lines marked as VULNERABLE.
  • Note any services flagged for default credentials or known misconfigurations.

What if the vulnerability scripts found nothing?

That is normal for well-maintained targets. NSE scripts only detect specific known vulnerabilities. The absence of findings here does not mean the app is secure. It means these particular automated checks did not find anything.

The ZAP active scan in the next steps will test the web application layer where most real vulnerabilities live.

You now have a complete map of your target's network footprint. Next up, you will point ZAP at the web application itself and crawl every page, endpoint, and form input it exposes.

Spider the App and Review Passive Scan Results

Your Nmap scans revealed which ports and services are exposed on the target server. That tells you what doors exist, but not what is behind them.

Now you need to map the web application itself. Every page, form, API endpoint, and parameter is a potential entry point for an attacker. OWASP ZAP's spider crawls the app like a user would, discovering all of these entry points automatically. Its passive scanner then flags basic issues in the responses without sending any attack traffic.

In this step, get ready to:
  • Add your target to ZAP's scope and spider the entire application.
  • Review the passive scanner's baseline findings in the Alerts tab.
Add your target to ZAP's scope and spider it

ZAP's spider follows every link and form action it can find, building a tree of all discoverable URLs. Before it can do anything in Protected Mode, you need to add the target to your scope.

  • Switch to OWASP ZAP (already open in Protected Mode from the previous step).
  • Click the browser icon in the top toolbar to open ZAP's built-in browser.
  • In ZAP's browser, navigate to your target URL (e.g., http://<TARGET_IP>:<PORT>).
  • Click through a few pages and interact with the app for 30-60 seconds to let ZAP capture traffic.

Check the Sites tab on the left panel of ZAP. You should see your target URL appear as a tree node with some discovered pages underneath it.

Why browse manually first?

Many modern web apps are single-page applications that load routes dynamically with JavaScript. ZAP's traditional spider follows HTML links, so it may miss JavaScript-rendered endpoints.

By manually browsing first, you ensure ZAP captures those dynamic routes in its Sites tree. The spider then builds on top of what you already discovered.

  • In the Sites tab on the left, right-click your target site node.
  • Select Include in Context, then click Default Context.
  • Click OK in the Session Contexts dialog that appears.

Why add the target to a context?

In Protected Mode, ZAP only allows dangerous actions (spidering, active scanning, fuzzing) against URLs that are explicitly in your scope. Adding the target to the Default Context tells ZAP this site is your authorized target.

  • Right-click your target site node in the Sites tab again.
  • Select Attack, then click Spider... from the submenu.
  • In the Spider dialog, confirm the Starting Point is set to your target URL.
  • Click Start Scan.

Watch the Spider tab in the bottom Information Window. You will see URLs appearing as the spider discovers pages and endpoints. This typically takes 1-3 minutes depending on the size of the app.

Spider not finding anything?

  • Make sure you browsed the app manually first. If the Sites tree was empty before you launched the spider, it has no starting links to follow.
  • Confirm the target is in scope. Right-click the site and check that it shows under Include in Context. In Protected Mode, the spider will refuse to crawl out-of-scope URLs.
  • Verify the target is actually responding. Open the URL directly in your regular browser to confirm it loads.

Still stuck? Help me troubleshoot why ZAP's spider is not discovering any URLs on my target.

Review passive scan results

While the spider ran, ZAP's passive scanner automatically analyzed every HTTP response that passed through it. The passive scanner does not send any attack traffic. It simply inspects what the server already returned and flags anything that looks like a misconfiguration or information leak.

Before you look at the results, think about what the passive scanner could realistically find without injecting any payloads. What kinds of issues are visible just by reading the server's responses?

  • Click the Alerts tab in the bottom Information Window of ZAP.
  • Look at the left pane of the Alerts tab. Alerts are displayed in a tree structure organized by risk level: High, Medium, Low, and Informational.
  • Click on any alert to see its details in the right pane, including the URL, the evidence in the response, and a description of the issue.

You should see findings at mostly Low or Informational severity. These are your baseline. Common passive findings include missing security headers, server version disclosure, and insecure cookie configurations.

What do these severity levels mean?

  • High: Critical vulnerabilities that could allow immediate compromise. Rare from passive scanning alone.
  • Medium: Significant issues worth investigating. The passive scanner sometimes flags these for things like missing Content Security Policy headers.
  • Low: Minor issues like information leakage through server banners or private IP disclosure.
  • Informational: Observations that are not vulnerabilities but provide useful context, like technology detection.

The passive scanner is good at establishing the basic security posture of an app. It cannot find injection vulnerabilities, broken authentication, or logic flaws. Those require active attack payloads.

  • Note the total number of alerts shown in ZAP's footer at the bottom of the window, broken out by risk category.
  • Check the Sites tab on the left. Confirm that the tree now shows a full hierarchy of discovered URLs, pages, and endpoints under your target.

This is your baseline. The Sites tree shows the full attack surface of the application, and the Alerts tab shows what the passive scanner found just by observing. In the next step, you will send real attack payloads against every one of these endpoints.

Your application is now fully mapped. You have a complete picture of every endpoint the spider discovered, plus a baseline of passive findings. Next up, you will unleash the active scanner to send real attack payloads against every one of those endpoints and uncover the dangerous vulnerabilities hiding beneath the surface.

Run the Active Vulnerability Scan

Your spider crawled the application and the passive scanner flagged basic configuration issues. Those findings were mostly Low and Informational: missing headers, insecure cookie flags, server version disclosure.

The passive scan never injected anything into the application. The dangerous vulnerabilities like SQL injection and Cross-Site Scripting remain hidden until real attack payloads hit every endpoint the spider discovered. That is exactly what the active scanner does.

In this step, get ready to:
  • Launch the active vulnerability scan against your scoped target.
  • Analyze new findings by severity level and compare to your passive baseline.
  • Export a professional vulnerability report as an HTML file.
Launch the active scan against your scoped target

The active scan sends known attack payloads (SQL injection strings, XSS vectors, path traversal sequences) to every endpoint the spider discovered. It tests each parameter it finds.

  • In OWASP ZAP, right-click your target site in the Sites tree on the left panel.
  • Select Attack, then click Active Scan... from the submenu.
  • In the Active Scan dialog, confirm the Starting Point shows your target URL.
  • Leave the Policy set to Default Policy (Medium strength, Medium threshold).
  • Click Start Scan.

The scan takes 5-15 minutes depending on how many endpoints the spider found. Watch the Active Scan tab at the bottom of ZAP for progress.

What does the active scan actually do?

ZAP attempts to find vulnerabilities by using known attacks against your selected targets. For every parameter on every endpoint, it injects payloads designed to trigger SQL errors, reflect script tags, traverse file paths, and more.

The Default Policy uses Medium strength (a moderate number of attack variations per parameter) and Medium threshold (balanced sensitivity for reporting potential vulnerabilities). This gives thorough coverage without making the scan excessively long.

Scan not starting?

If you see a message that no URLs are in scope, your target was not added to the Default Context properly. Right-click the target in the Sites tree, select Include in Context, then Default Context. Then try launching the active scan again.

If ZAP blocks the scan entirely, check the mode dropdown in the toolbar. It must show Protected (not Safe Mode). Safe Mode blocks active scanning.

Still stuck? Why won't my ZAP active scan start against my target?

Analyze your findings

Before you look at the results, think about this: you already had Low and Informational findings from the passive scan. What new severity levels do you expect the active scan to have uncovered?

  • Once the scan completes, click the Alerts tab at the bottom of ZAP.
  • Sort by Risk (High first) by clicking the Risk column header.
  • Click any High or Medium severity finding to expand it.

You should now see new findings at Medium or High severity that were not present after the passive-only scan. These might include SQL Injection, XSS, Path Traversal, or Remote Code Execution.

  • For each High or Medium finding, note these four details in the detail pane on the right:
  • Compare to your passive-only baseline. You should now see entirely new categories of vulnerabilities that were invisible before the active scan.

Why are these findings more severe?

The passive scan only observed existing traffic. It could spot missing headers or insecure cookies because those are visible in normal responses. But SQL injection requires actually sending a malicious query and observing the server's reaction. The active scan proved these vulnerabilities exist by triggering them.

The active scanner cannot find logical vulnerabilities such as broken access control. Manual penetration testing (the next step) addresses that gap.

No High or Medium findings after the scan?

If you only see Low and Informational alerts, the target application may have strong input validation. Try checking the Active Scan tab to confirm the scan actually completed (progress bar at 100%).

If the scan completed but found nothing, your target may genuinely be well-secured against common attack patterns. This is still a valid finding. Document it as evidence the application resists automated attacks.

Need help interpreting your results? Help me understand my ZAP active scan results and what they mean.

Export your vulnerability report

A professional pentest always produces a written deliverable. ZAP can generate a formatted HTML report containing all your findings categorized by risk level.

  • In the ZAP menu bar, click Report.
  • Click Generate Report... from the dropdown.
  • In the Generate Report dialog, select an HTML template from the Template pulldown (e.g., Traditional HTML Report).
  • Set the report output path to ~/pentest-findings/zap-report.html.
  • Click Generate Report.

Now open the report in your browser to confirm it generated correctly.

  • Open the report by running this command in Terminal:
open ~/pentest-findings/zap-report.html

You should see a formatted vulnerability report in your browser. It categorizes every finding by risk level (High, Medium, Low, Informational) and includes the URL, parameter, payload, and evidence for each alert.

What does the report contain?

The HTML report is a self-contained document you could hand to a client or attach to a security assessment. It includes alert counts by risk level, detailed descriptions of each vulnerability, the exact request that triggered it, and remediation guidance.

This report combines both your passive findings (from the spider phase) and your active findings (from this step) into one document.

Report file not opening?

If the open command says the file does not exist, double-check the path you entered in ZAP's save dialog. Run ls ~/pentest-findings/ to confirm zap-report.html is listed.

If ZAP did not save the file, return to Report > Generate Report... and try again, making sure you type the full path including the ~ character.

Still having trouble? Help me export my ZAP vulnerability report as an HTML file.

You now have a professional vulnerability report from a real active scan. Next up, you will manually fuzz high-value endpoints to find vulnerabilities the automated scanner overlooked.

Manually Fuzz High-Value Endpoints

Your automated active scan just revealed vulnerabilities across the app's endpoints. That is a strong start, but automated scanners follow generic patterns.

Your target app has unique features like ingestion endpoints, pipeline configurations, and scheduling inputs that the scanner may not have tested thoroughly. Manual fuzzing lets you craft specific payloads targeting these high-value endpoints. This is where you find vulnerabilities the automated scan missed.

In this step, get ready to:
  • Identify high-value endpoints from the Sites tree and History tab.
  • Fuzz a chosen endpoint with injection payloads using ZAP's Fuzzer.
  • Confirm and document any findings you discover manually.
Identify high-value endpoints from your scan results

Not all endpoints are equally interesting to a pentester. Endpoints that accept user-supplied URLs, file uploads, or free-text queries are far more likely to contain injection vulnerabilities than static pages.

  • Switch back to OWASP ZAP and expand your target site in the Sites tree on the left panel.
  • Look for endpoints related to file ingestion or data upload. These are URLs containing words like ingest, upload, import, or pipeline.
  • Also look for scheduling or job creation endpoints. These contain words like schedule, job, run, or trigger.
  • Check for AI or RAG-related endpoints. These contain words like agent, query, prompt, or rag.
  • Click the History tab at the bottom of ZAP.
  • Look for POST requests with parameters. These are the endpoints that accept user input you can fuzz.
  • Pick one endpoint that accepts user input. You will fuzz this endpoint in the next substep.

What makes an endpoint high-value?

Any endpoint where the server processes data you supply is a potential injection target. The more complex the processing (parsing a URL, evaluating a query, reading a file), the more likely it is to have a vulnerability the automated scanner missed.

POST requests with body parameters are the best candidates because they typically feed directly into server-side logic.

Fuzz the endpoint with injection payloads

ZAP's Fuzzer sends hundreds of attack payloads to a single parameter, then shows you which responses differ from normal. A different status code or response size signals that you have triggered unexpected behaviour on the server.

  • In the History tab, find the request to your chosen endpoint.
  • Right-click it and select Attack, then Fuzz....
  • The Fuzzer dialog opens showing your request in the Fuzz Locations tab.
  • Highlight the parameter value you want to test (the actual value text in the request body or URL).
  • Click Add... to open the Payloads dialog.
  • In the Payloads dialog, click Add... again.
  • Select Type: File Fuzzers.
  • Expand the tree and select jbrofuzz, then choose a relevant category (e.g., an XSS or SQL Injection payload set).
  • Click Add, then click OK to close the Payloads dialog.

What are File Fuzzers?

File Fuzzers are pre-built payload collections bundled with ZAP. They include payload sets originally from the OWASP JBroFuzz project and fuzzdb. Each category contains hundreds of known-malicious strings targeting a specific vulnerability class.

For example, the SQL Injection set contains strings like ' OR 1=1-- and many variations. The XSS set contains script injection attempts. ZAP sends each payload to your target parameter one by one.

Before you click Start Fuzzer, what do you expect to see if one of these payloads triggers a vulnerability? Think about what would change in the server's response.

  • Click Start Fuzzer.
  • Watch the Fuzzer tab at the bottom as results stream in.
  • Look for responses with different status codes (500, 403) or significantly different response sizes compared to the baseline.

Any response that stands out from the baseline is a potential finding. A 500 error means your payload caused an unhandled exception on the server. A dramatically different response size may mean the payload altered what the server returned.

Not seeing any results in the Fuzzer tab?

Make sure you highlighted the actual parameter value (not the parameter name) before clicking Add... in the Fuzz Locations tab. The highlighted text is what gets replaced by each payload.

Also confirm your target is still in scope. Protected Mode only allows fuzzing against in-scope URLs.

If the Fuzzer completes instantly with zero results, the endpoint may have rejected the connection. Try a different endpoint from your high-value list.

Help me troubleshoot this

Confirm and document any findings

A response that looks anomalous is not a confirmed vulnerability yet. You need to reproduce it manually to rule out false positives. ZAP's Request Editor lets you edit and resend individual requests to verify what you found.

  • In the Fuzzer results, find a response with an anomalous status code or response size.
  • Right-click it and select Open/Resend with Request Editor.
  • The Request Editor opens with the exact request that produced the anomalous response.
  • Modify the payload slightly to confirm the vulnerability is real (not a false positive). For example, change a SQL injection payload to extract different data, or adjust an XSS payload to use a different tag.
  • Click Send and observe whether the modified payload also triggers an anomalous response.
  • If the modified payload also produces a non-standard response, you have confirmed the vulnerability.

What counts as a confirmed vulnerability?

A finding is confirmed when you can reliably reproduce it with different payloads targeting the same weakness. If only one specific string triggers the anomaly and slight variations do not, it may be a false positive or a WAF artefact.

Document your findings regardless. Even a probable finding is worth recording for further investigation.

  • Return to Terminal and create your findings file by running this command:
touch ~/pentest-findings/manual-findings.txt
  • Open ~/pentest-findings/manual-findings.txt in any text editor.
  • For each confirmed finding, document the following on separate lines:
  • The full URL of the vulnerable endpoint.
  • The parameter that is vulnerable.
  • The payload that triggered the anomalous response.
  • The response evidence that proves the vulnerability (status code, error message, or leaked data).
  • Save manual-findings.txt.
  • Confirm the file exists by running:
ls ~/pentest-findings/

You should see manual-findings.txt alongside nmap-scan.txt, nmap-vuln.txt, and zap-report.html.

Don't see manual-findings.txt?

Make sure you ran the touch command from a Terminal window, not from inside ZAP. The file is created in your home directory's pentest-findings folder.

If you see the other files but not manual-findings.txt, check for typos in the filename.

Help me find my file

You now have a complete penetration testing toolkit in action. You went from blind network reconnaissance, through automated scanning, to targeted manual exploitation. Your findings folder contains evidence from every phase of the test.

Secret mission

Attempt SSRF via Ingestion Endpoints

Your automated scanner found injection flaws, but it completely missed one of the most dangerous vulnerability classes: Server-Side Request Forgery. The app accepts URLs as input for ingestion and pipeline configuration. Can you trick it into fetching internal resources it was never meant to expose?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally, so there are no ongoing costs.

Resources you used:

  • Nmap (installed via Homebrew).
  • ~/pentest-findings/ directory with scan outputs and manual findings.
  • OWASP ZAP mode configuration (changed from Safe Mode to Protected Mode).

Keep everything running

No action needed. Choose this if you plan to continue testing the same target or want to run additional scans later.

  • Nmap stays installed and ready for future scans.
  • Your findings in ~/pentest-findings/ remain available for reference.
  • ZAP stays in Protected Mode, which is the recommended mode for any future pen testing work.

Pause - I'll come back to this later

Free up system resources by closing ZAP, but keep your files and tools installed so you can pick up where you left off.

  • Quit OWASP ZAP if it is still running.
  • Your scan findings in ~/pentest-findings/ stay on disk for when you return.
  • Nmap remains installed and takes no resources when idle.

Delete - I don't want to use this again

Remove all project resources and revert configuration changes.

  • Delete your findings folder by running this in Terminal:
rm -rf ~/pentest-findings
  • Uninstall Nmap by running:
brew uninstall nmap
  • Confirm Nmap is removed by running:
nmap --version

You should see command not found, confirming Nmap is no longer installed.

  • Revert ZAP to Safe Mode: open OWASP ZAP, click the Mode dropdown in the main toolbar, and select Safe Mode.

Nice Work!

Nice Work!

You just completed a structured penetration test against a live web application on your network. You followed the same methodology professional pentesters use: reconnaissance, automated scanning, and manual exploitation.

You've learned how to:

  • Perform full network reconnaissance with Nmap, discovering every open port, running service, and software version on a target server.
  • Run an automated active vulnerability scan with OWASP ZAP and generate a professional vulnerability report categorized by risk level.
  • Manually fuzz high-value endpoints with targeted injection payloads to find vulnerabilities the automated scanner missed.
  • Secret Mission: Attempted SSRF attacks against URL-accepting inputs to access internal network resources the server should never expose.

Ready to quiz yourself?