CPENT Attack-and-Report Sprint

Run a timed CPENT range workflow with evidence and a traceable finding.

Introduction

30 Second Summary

A practical exam clock makes every promising lead feel urgent. Without a clear workflow, useful observations disappear into scattered notes.

In this project, you will run a 55-minute attack-and-report sprint against an authorized Capture the Flag (CTF) Range in the EC-Council CPENT Practice Range. Your compact operations kit will connect Kali Linux and Nmap enumeration to saved evidence and a mini penetration-testing finding.

What You'll Build

You’ll open one folder after the sprint and trace an authorized target from its first response through your attack decision to the evidence-backed finding.

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

A prioritized target database that turns raw scan responses into a clear next action for each candidate.
A timed decision log that shows when you continued an approach. It also records when you switched hypotheses or stopped.
An evidence-backed mini finding that another tester can trace from the affected asset to the saved scan or screenshot.
Secret Mission: Triage a second candidate target under a strict 15-minute limit.

Are there any prerequisites?

You need active access to the CPENT course plus its iLabs and Practice Range. You also need an existing CPENT-compatible Kali Linux practice environment on a Windows device.

Before We Start

Before the timed work begins, this step locks your sprint to the supplied scope of the Capture the Flag (CTF) Range. Your written commitment connects disciplined evidence handling to exam-quality reporting.

Set Up the Sprint Workspace

A timed engagement can collapse before the first scan. Missing range access or evidence tools consume the clock.

The authorized CPENT Practice Range defines your testing boundary. A reliable workspace keeps that boundary visible throughout the sprint.

This step proves that your scanner is ready. It also gives every note and screenshot a known location.

In this step, get ready to:

Review the authorized range scope.
Confirm Nmap is available in Kali Linux.
Create a local Windows workspace for notes and evidence.

Review the authorized range scope

The Scope of Work identifies the subnet or targets you may test. Every later scan must stay inside that boundary.

Return to your current CPENT course portal.
Open the CTF Range you selected earlier.
Read the Scope of Work for the range.
Identify the supplied in-scope subnet or target list.
Record the supplied scope here: your authorized in-scope subnet or target list.

You now have a hard boundary for the sprint. Any address outside the recorded scope remains untouched.

Verify Nmap in Kali Linux

Nmap performs the host discovery used in the next step. Its help screen provides a quick readiness check without sending traffic to a target.

Start your existing CPENT-compatible Kali Linux practice environment.
Open a terminal window inside Kali Linux.
Check whether Nmap can display its help by running this command:

nmap -h

What does this command prove?

The command asks Nmap to display its usage information.
A help screen confirms that the terminal can find and run Nmap.
The command does not scan the range.

✔️ Nmap help opens

Your scanner is ready before the timer starts. That removes one major source of delay from the sprint.

ⓧ Nmap is absent

Kali Linux can install Nmap from its package repository. The installer may request your Kali account password or package confirmation.

Install the Nmap package by running this command:

sudo apt install nmap

What does this command do?

The command asks Kali Linux to install the Nmap package. The package provides the scanner used throughout the sprint.

Complete any installation prompts using your own Kali credentials.
Verify the installation by running this command:

nmap -h

What should you see?

You should see Nmap usage information followed by groups of available options. This confirms that the installation succeeded.

Nmap help still unavailable?

Check that Kali Linux has network access for the package installation. Confirm that the installation completed before rerunning the help command.

Help me diagnose why Nmap help is unavailable in Kali Linux.

Build the local evidence workspace

File Explorer keeps your sprint files visible on your Windows device. The folder structure separates scan output from screenshots and reports.

Press Windows logo key + E to open File Explorer.
Press Alt+D to select the address bar.
Type C:\ into the address bar.
Press Enter to open the drive.
Press Ctrl+Shift+N to create a folder.
Type CPENT-Sprint as the folder name.
Press Enter to save the folder name.
Double-click CPENT-Sprint to open it.

You should now be inside C:\CPENT-Sprint.

Press Ctrl+Shift+N to create the first subfolder.
Type scans as its name.
Press Enter to save the name.
Press Ctrl+Shift+N to create the second subfolder.
Type evidence as its name.
Press Enter to save the name.

You should see the scans folder beside the evidence folder.

Press Ctrl+Shift+N to create the final subfolder.
Type report as its name.
Press Enter to save the name.

Why use three subfolders?

The scans folder holds saved Nmap output.
The evidence folder holds screenshots from authorized testing.
The report folder holds the mini penetration-testing finding.

Notepad provides lightweight files for the scope record and working notes. The scope file contains only the boundary supplied by the range.

Select Start on your Windows device.
Type Notepad into the search field.
Select Notepad from the results.

A blank Notepad document is ready for your scope record.

Enter only your authorized in-scope subnet or target list in the document.
Select File from the Notepad menu.
Select Save As.
Browse to C:\CPENT-Sprint in the save dialog.
Enter scope.txt in the File name field.
Confirm the save.

Good work. Your authorized boundary now has a durable reference for every later scan.

Close Notepad.
Select Start.
Type Notepad into the search field.
Select Notepad from the results.

The target database begins as an empty working file. Later entries will turn scan responses into structured candidate records.

Select File from the Notepad menu.
Select Save As.
Browse to C:\CPENT-Sprint in the save dialog.
Enter target-database.txt in the File name field.
Confirm the save.

You should see target-database.txt in the Notepad title area.

Close Notepad.
Select Start.
Type Notepad into the search field.
Select Notepad from the results.

The decision log also begins empty. It will hold timestamped observations plus decisions about switches and stop rules.

Select File from the Notepad menu.
Select Save As.
Browse to C:\CPENT-Sprint in the save dialog.
Enter decision-log.txt in the File name field.
Confirm the save.

You should see decision-log.txt in the Notepad title area.

Snipping Tool preserves visual evidence from important steps. Your first capture proves which scope was visible before testing began.

Return to the CTF Range Scope of Work in your browser.
Position the supplied in-scope subnet or target list on screen.
Press Windows logo key + Shift + S to open the screenshot overlay.
Drag over the visible scope information.
Save the capture as C:\CPENT-Sprint\evidence\00-scope.png using the Snipping Tool save control.

You should find 00-scope.png inside C:\CPENT-Sprint\evidence.

Before the final check, which signals do you expect from the range scope, Nmap, and Snipping Tool?

Return to the visible Scope of Work in your course portal.

You should see the authorized subnet or target list that you recorded.

Switch back to the Kali Linux terminal from earlier.
Run the Nmap readiness check again:

nmap -h

What should you see?

You should see the Nmap help screen without an installation failure. Your scanner is ready for the timed host-discovery pass.

Did the final Nmap check fail?

Confirm that you are using the same Kali Linux environment where Nmap was installed. Rerun the installation path from the earlier outcome tab if the environment changed.

Help me diagnose the final Nmap readiness check.

Return to the visible Scope of Work on Windows.
Press Windows logo key + Shift + S again.

You should see the Snipping Tool overlay above the visible range scope.

Close the screenshot overlay without taking another capture.
Switch back to File Explorer from earlier.
Open C:\CPENT-Sprint.

You should see the three subfolders plus scope.txt, target-database.txt, and decision-log.txt.

Open C:\CPENT-Sprint\evidence.

You should see 00-scope.png in the evidence folder.

✔️ Awesome, I've got everything!

Your range boundary, scanner, notes, and screenshot workflow are ready. The sprint can now focus on decisions instead of setup.

ⓧ I'd like to double check the final state

Confirm the authorized CTF Range is open with its Scope of Work reviewed.
Confirm Nmap displays its help screen in Kali Linux.
Confirm C:\CPENT-Sprint contains scans, evidence, and report.
Confirm scope.txt contains only your authorized in-scope subnet or target list.
Confirm target-database.txt is an empty working file for structured candidate records.
Confirm decision-log.txt is an empty working file for timestamped observations and decisions.
Confirm C:\CPENT-Sprint\evidence\00-scope.png shows the visible authorized range scope.

Your sprint workspace is ready. Next, you will run a timed baseline enumeration and see which critical decisions raw scan output cannot capture.

Run a Baseline Enumeration

Your authorized range workspace is ready. The next question is which in-scope systems respond.

Raw scan output can look productive. Its value depends on whether it supports a documented next decision.

A seven-minute baseline uses Nmap from Kali Linux to perform host discovery within the authorized scope.

In this step, get ready to:

Run a time-boxed host-discovery pass against the authorized scope.
Capture the observations that stand out during your first reading.
Compare the raw output with the required target-database fields.

Run the seven-minute discovery pass

This first pass asks a narrow question about reachability. The exact scope value keeps every probe inside the supplied Scope of Work.

Return to scope.txt in Notepad.
Record the exact in-scope subnet or target list here: authorized CTF Range scope.
Return to Kali Linux.
Start a seven-minute timer on your Windows device.

Before you run the baseline, which parts of a target record do you expect host-discovery output to answer?

Run host discovery and create the baseline output set with this command:

nmap -sn -oA baseline-enumeration [[AUTHORIZED_SCOPE="authorized CTF Range scope"]]

What does this baseline command do?

The -sn option performs host discovery without a port scan.
The -oA option stores normal, XML, and grepable output formats.
The baseline-enumeration basename keeps the three output files grouped together.
The scope value limits the command to the authorized CTF Range targets.

Moving the output set between Kali Linux and Windows is the fiddly part because practice environments expose local storage in different ways.

Transfer every file with the baseline-enumeration basename to C:\CPENT-Sprint\scans with your environment's existing download or shared-folder workflow.
Return to C:\CPENT-Sprint\scans in File Explorer.

You will see the baseline output set produced by -oA in the scans folder. Good work. Your first authorized enumeration evidence is now preserved outside the range session.

Scan output missing?

Confirm that the command used only the scope copied from scope.txt. Check the Kali terminal folder where you ran the command if the output set is missing from your transfer view.

If no hosts responded, confirm that your current authorized range connection is active before repeating the same scoped command.

Help me diagnose my scoped Nmap host-discovery pass without testing anything outside the CPENT CTF Range.

Capture immediate observations

A first reading captures what stood out before a template directs your attention. These notes preserve the reasoning you had under the clock.

Open the normal-format file from the baseline-enumeration output set in File Explorer.
Read the saved output once from top to bottom.
Return to decision-log.txt in Notepad.
Add the current time with the label Baseline enumeration.
Record only immediately useful observations such as responding hosts, unreachable address space, or filtering clues.
Stop the baseline pass when the seven-minute timer expires.
Save decision-log.txt.

Your decision log now contains time-boxed observations from the first reading. Each note is tied to evidence preserved in the scans folder.

Expose the gaps in raw output

A comparison template tests whether scanner output can support a complete target decision. Every marked gap becomes a question that later analysis must answer.

Return to target-database.txt in Notepad.
Add the required comparison fields by pasting this block below the existing line:

Asset:
Reachability:
Ports and Services:
Filtering Clue:
Evidence File:
Attack Hypothesis:
Next Action:
Time Spent:
Status:

Why use fixed fields?

The fixed fields separate scanner observations from analyst decisions.
A visible marker exposes every conclusion that the baseline cannot support.

Before you place the files side by side, which fields do you think the raw output can fill without adding your own interpretation?

Open the saved normal-format baseline output from C:\CPENT-Sprint\scans.
Place target-database.txt beside the baseline output.
Enter only facts that the raw output directly supports.
Enter Not answered by baseline discovery beside every unsupported field.
Save target-database.txt.

The raw host-discovery output does not contain an evidence path. It does not supply an attack hypothesis.

It also does not choose a next action. You will see Ports and Services marked because -sn does not run a port scan.

Any additional unsupported fields remain visibly marked. That gap is the intended result of this baseline.

Unsure whether a field is supported?

Keep a field factual only when you can point to the exact supporting line in the saved output. Mark assumptions that require another test or analyst judgment.

Help me separate facts from assumptions in my baseline target record.

✔️ My baseline state is complete

Your scoped output set, time-boxed notes, and marked comparison fields now expose the limits of raw enumeration. You have evidence for what the baseline showed and what it could not decide.

ⓧ I need to check the baseline state

Confirm that C:\CPENT-Sprint\scans contains the baseline output set produced with -oA against only the authorized scope.
Confirm that decision-log.txt contains time-boxed observations from the first reading.
Confirm that target-database.txt contains all nine required comparison fields.
Confirm that every field unsupported by the raw discovery pass has a visible marker.

Your baseline has revealed where scanner output stops and analyst reasoning begins. Next, you will turn those gaps into a prioritized target database with interpreted evidence.

Build a Structured Target Database

Your baseline Nmap pass produced raw host-discovery evidence. It also exposed the missing context that makes a timed test actionable.

A target database links each candidate to what you observed. This step turns those records into a prioritized next move.

In this step, get ready to:

Create one structured record for each in-scope candidate.
Interpret candidate responses with narrow saved Nmap passes.
Rank the strongest next target with an evidence-backed rationale.

Structure each candidate record

The required field set already exists in target-database.txt. Each in-scope candidate now needs its own copy of that structure.

Return to target-database.txt in Notepad.
Duplicate the existing field set until every candidate listed in scope.txt has one record.
Enter each candidate's exact in-scope value under Asset.
Fill Reachability from the baseline host-discovery result.
Fill Filtering Clue from the response patterns in the baseline result.
Point Evidence File to the matching baseline output under C:\CPENT-Sprint\scans.
Complete the remaining fields with an observed fact or a clear unknown status.

Why preserve unknowns?

An explicit unknown keeps the record honest. It also gives the next scan a precise question to answer.

Save target-database.txt.
Compare the number of candidate records with the authorized entries in scope.txt.

You should see one structured record for every supplied in-scope candidate.

Interpret candidate responses

A quiet response can reflect filtering or discovery behavior. Narrow follow-up passes help you distinguish those clues without expanding beyond the authorized scope.

Keep every pass inside scope

The entries in scope.txt are your hard boundary. Every follow-up stays limited to those exact candidates.

Switch back to the Kali Linux terminal from the baseline scan.
Recall the saved baseline Nmap command from the terminal history.
Replace the range-wide scope with one exact Asset value from your target database.
Add --reason to expose why Nmap assigned each reported state.
Keep -oA in the command.
Choose a new candidate-specific output base under C:\CPENT-Sprint\scans.
Run the edited command.

You'll see Nmap include the reason behind each reported host or port state.

How does this pass add context?

The --reason option exposes the evidence behind a reported state.
The candidate-specific target keeps the pass narrow.
The -oA option preserves the result in normal, XML, and grepable formats.

Review the reported reasons for the selected candidate.
Update Reachability with the supported interpretation.
Update Filtering Clue with the supported interpretation.
Add -Pn only when the clue indicates that host discovery may be filtered.
Keep the -Pn pass limited to that single in-scope candidate.
Choose another candidate-specific output base under C:\CPENT-Sprint\scans.
Run the tuned pass when the filtering condition applies.

When this pass is needed, Nmap treats the specified candidate as active for the requested scan functions. The saved result gives your filtering interpretation a traceable evidence source.

Identify any ports discovered by the authorized candidate-specific passes.
Run a targeted follow-up on only those discovered ports with -sV.
Save the service-detection pass with -oA under C:\CPENT-Sprint\scans.
Update Ports and Services with the observed service information.
Update Evidence File with the relevant candidate-specific output base.
Update Attack Hypothesis with one plausible path supported by the observed response.

You'll see service information for the discovered ports you selected. Your candidate record now connects that interpretation to saved Nmap evidence.

Candidate evidence does not line up?

Confirm that the recalled command still targets the exact Asset value from the authorized scope. Confirm that each pass uses a distinct output base.

Preserve a limited result as evidence of the response you received. Help me interpret my authorized candidate-specific Nmap results without suggesting scans outside the supplied CPENT CTF Range scope.

Prioritize the first attack path

Prioritization gives the next test a defensible starting point. Your first-ranked candidate should offer the best use of time based on the evidence you have now.

Return to target-database.txt in Notepad.
Compare the candidates by access complexity.
Compare the candidates by their expected filtering mechanism.
Compare the candidates by their plausible attack vector.
Move the strongest candidate record to the top of the file.
Set its Status to show that it is ranked first.
Add one rationale sentence beneath Status that covers all three ranking factors.
Set Next Action to the single authorized test that follows from the recorded hypothesis.

Update Time Spent for the work completed on that candidate.
Return to decision-log.txt in Notepad.
Append the decision to prioritize the first-ranked candidate.
Save target-database.txt.
Save decision-log.txt.

Before the final check, can another tester see why this candidate comes first without rereading every raw scan?

Return to the first-ranked record in target-database.txt.
Trace its Evidence File reference to the matching saved output under C:\CPENT-Sprint\scans.
Review the record against every required field.

What should you see?

At least one candidate has a current Status.
Its Evidence File points to saved candidate-specific output.
Its Filtering Clue explains the observed response.
Its Attack Hypothesis follows from the saved evidence.
Its Next Action defines one controlled test.
Its priority rationale addresses access complexity, expected filtering mechanism, and plausible attack vector.

That raw-output gap is closed. Your first candidate now has evidence, interpretation, and a defensible next action.

Arrange the Notepad view so the field labels and priority rationale are visible.
Keep candidate addresses, credentials, and restricted range details outside the capture area.
Capture the sanitized view with Windows logo key + Shift + S using the Snipping Tool.

✔️ My target database is ready

Your target database now turns authorized scan evidence into a ranked decision. You are ready to test the first attack path.

ⓧ I'd like to double check the final state

Confirm the baseline -sn output set remains under C:\CPENT-Sprint\scans.
Confirm target-database.txt contains one structured record per in-scope candidate.
Confirm every record includes Asset, Reachability, Ports and Services, Filtering Clue, Evidence File, Attack Hypothesis, Next Action, Time Spent, and Status.
Confirm candidate-specific --reason evidence is saved with -oA.
Confirm every -Pn pass is limited to one candidate where discovery may be filtered.
Confirm every -sV pass is limited to discovered ports.
Confirm one candidate is ranked first with a rationale covering the three required factors.
Confirm decision-log.txt contains the decision to prioritize that candidate.

Your first-ranked candidate now has a traceable path from scanner response to next action. Next, you'll test that path under a strict time limit and preserve the strongest observable result.

Test an Attack Path and Capture Evidence

Your target database has turned scan responses into a ranked decision. You can now test the strongest hypothesis against the prioritized in-scope target.

Enumeration becomes useful when it leads to a controlled test. A result becomes report-ready when timestamped notes point to matching penetration testing evidence.

In this step, get ready to:

Run one hypothesis-matched test within a twelve-minute limit.
Use a five-minute stop rule to avoid an unproductive rabbit hole.
Capture the strongest result in a traceable evidence file.

Match the technique to the hypothesis

A hypothesis-matched test gives your earlier scan interpretation a controlled way to prove itself. The twelve-minute limit protects your scope control while preserving time for documentation.

This test can feel high-stakes. Your supplied scope plus a familiar CPENT iLabs technique keeps the attempt controlled.

Return to the first-ranked candidate in target-database.txt.
Confirm that the candidate still appears in scope.txt.
Review the Attack Hypothesis field.
Review the Next Action field.
Start a twelve-minute timer using your usual timer app.
Record the test start time in decision-log.txt.
Apply one matching technique previously practiced in CPENT iLabs against the prioritized target.
Observe the response for evidence that supports or weakens the hypothesis.

A successful access attempt is one possible result. A clear rejection or filtering response can also test the hypothesis.

Technique producing no useful response?

Confirm that the technique matches the service information in the target record. Stop immediately if the tool attempts to leave the supplied range scope.

Help me review my hypothesis-matched CPENT range test without sharing target details or credentials.

Use the five-minute stop rule

A stop rule turns stalled progress into a documented decision. It prevents repeated actions from consuming the rest of your sprint.

Assess the current response when the timer reaches five minutes.

✔️ I found new evidence

Record the new evidence in decision-log.txt.
Continue testing the same hypothesis until the twelve-minute timer expires.

ⓧ No new evidence after five minutes

Record the attempted technique in decision-log.txt.
Record the target response in decision-log.txt.
Select the next-ranked in-scope hypothesis from your target database.
Switch once to the technique that matches the new hypothesis.
Stop any unchanged repeat of the failed action.

A valid switch tests a different recorded assumption. This keeps the second attempt connected to your evidence.

What completes the decision log?

The start time anchors the beginning of the test.
The end time proves that the twelve-minute limit was respected.
The tested technique identifies the action behind the response.
The observed response records what actually happened.
The five-minute decision explains why you continued or switched.

Stop the active test when the twelve-minute timer expires.
Complete the current entry in decision-log.txt using the details above.

That was the disciplined part of the sprint. You now have a bounded test with a documented decision trail.

Preserve the strongest result

Evidence connects your written interpretation to an observable result. The strongest item is the response that most clearly supports or weakens the tested hypothesis.

The Snipping Tool saves that result in the evidence folder you prepared earlier. A restricted or unsuccessful response still belongs in the record when it shows what the target did.

Select the strongest observable result from the timed test.
Frame the capture so credentials remain outside it.
Press Windows logo key + Shift + S to open the screenshot overlay.
Drag the capture area around the observable result.
Use the prioritized target plus the observed result in this filename: target-observation.png.
Save the capture as target-observation.png under C:\CPENT-Sprint\evidence.
Open the saved capture from C:\CPENT-Sprint\evidence using the Windows file browser.

You should see the target response clearly inside the saved image. Sensitive information should remain outside the captured area.

Good. Your evidence folder now holds a report-ready result from the timed test.

Map the test into the target record

The Attack Hypothesis field identifies the hypothesis or authorized technique you tested.
The Status field states the observed result.
The Evidence File field contains the exact saved filename.
The Time Spent field records the elapsed test time.
The Next Action field states the next justified follow-up.

Return to the prioritized record in target-database.txt.
Update the prioritized record from your completed decision log using the fields above.
Save target-database.txt.

Before you check the final trail, do you expect another tester to reach the exact evidence without guessing?

Read the updated prioritized record from top to bottom.
Open the screenshot named in the Evidence File field.

You should see every mapped field filled for the prioritized target. The filename should open the screenshot whose visible response matches the record.

Does the evidence trail break?

Compare the filename in Evidence File with the file under C:\CPENT-Sprint\evidence. Check the target record for an empty result or next action.

Help me audit my local attack-path evidence trail without exposing restricted range details.

Your traceability check is complete. The target record now leads another tester to the exact local evidence without replaying your session.

Keep range evidence private

Keep the actual attack-path screenshot local. A safe validation image shows the evidence folder with target-specific text covered.

Your authorized test now has a decision trail plus matching evidence. Next, you will turn that trail into a mini penetration-testing finding.

Write a Traceable Mini Finding

Your time-boxed test now has a recorded result with linked evidence. The next goal is a mini penetration-testing finding that another tester can trace from each statement to its source.

The CPENT exam includes a penetration testing report submission. Your finding must stand on its own without replaying the entire session.

In this step, get ready to:

Create a structured mini finding for the prioritized target.
Separate observed results from untested hypotheses.
Prove that every technical claim traces to authorized evidence.

Create the finding structure

A consistent field order makes the finding easier to review. Notepad keeps the report beside the evidence you already collected.

Select Start on Windows.
Type Notepad into the search bar.
Select Notepad from the search results.
Type Title, Affected Asset, Status, Technical Summary, Reproduction Steps, Evidence, Impact, Remediation, and Retest Check on separate lines in this exact order.
Use Notepad's save controls to save the new file as C:\CPENT-Sprint\report\finding-01.txt.
Confirm that Notepad displays finding-01.txt as the current file.

You should see finding-01.txt with all nine field labels ready for evidence-backed content.

What Belongs in Each Field?

Title names the observed issue.
Affected Asset identifies the prioritized in-scope target.
Status states whether the result is confirmed or remains an untested hypothesis.
Technical Summary explains the observed behavior.
Reproduction Steps records the authorized actions in order.
Evidence points to saved scan output or a screenshot.
Impact describes what the observation means for the affected target.
Remediation addresses the observed weakness.
Retest Check defines the evidence that would show the fix works.

Cannot Find the Saved File?

Check that the destination is C:\CPENT-Sprint\report. Check that the filename ends with .txt.

Help me verify where Notepad saved my mini finding.

Write from observed evidence

The target database, decision log, scan output, and screenshot now form the source set for your finding. Every claim should stay within what those artifacts support.

In Notepad, open C:\CPENT-Sprint\target-database.txt.
Open C:\CPENT-Sprint\decision-log.txt in Notepad.
Return to C:\CPENT-Sprint\report\finding-01.txt.
Enter the observed issue under Title.
Enter the prioritized in-scope target under Affected Asset.
Compare the title with the observed result in the prioritized target record.
Compare the affected asset with the exact in-scope target in that record.

The title now matches the observed issue. The affected asset now matches the prioritized scope record.

Set Status to confirmed result or untested hypothesis based on the saved evidence.

Separate Evidence from Hypotheses

Use confirmed result only when a saved artifact directly supports the statement.

Use untested hypothesis when the target record proposes an explanation that your test did not verify.

Write the observed behavior under Technical Summary.
Check each summary sentence against the target database or decision log.

Every sentence in the technical summary should have a matching source in your saved notes.

Write the authorized test actions under Reproduction Steps.
Enter the exact saved output or screenshot paths under Evidence.
Follow each evidence reference to its matching saved file.

Each reference should open the candidate-specific scan evidence or the linked screenshot from the time-boxed test.

State the supported consequence under Impact.
Write a response to the observed weakness under Remediation.
Compare the remediation with the weakness described in the technical summary.

The remediation should address the behavior you observed without assuming an unverified cause.

Define the evidence that would verify the fix under Retest Check.
Save C:\CPENT-Sprint\report\finding-01.txt.

Your saved finding now contains all nine fields. Its claims come from the target database, decision log, scan output, and screenshot.

Run the traceability check

Traceability lets another tester move from a report statement to the artifact that supports it. This final check also keeps every reproduction step inside the authorized range.

Before you begin the final check, could another tester start at finding-01.txt and reach every cited source without asking where it lives?

Start from C:\CPENT-Sprint\report\finding-01.txt.
Follow Affected Asset to the exact record in C:\CPENT-Sprint\target-database.txt.
Follow each Evidence reference to its saved output or screenshot.
Compare Reproduction Steps with C:\CPENT-Sprint\scope.txt.
Compare each technical statement with its cited saved artifact.

Each asset reference should resolve to the matching target record. Each evidence reference should resolve to an existing file.

Confirm that Status preserves the distinction between a confirmed result and an untested hypothesis.
Compare Remediation with the observed weakness.
Confirm that Retest Check defines how to verify the remediation.
Correct each mismatch you discover.
Save C:\CPENT-Sprint\report\finding-01.txt.

What Does a Passing Check Show?

The affected asset leads to the matching prioritized target record.
Every technical statement has support in saved output or a screenshot.
Every evidence reference opens the matching saved file.
Every reproduction step stays within the scope recorded in scope.txt.
The remediation addresses the observed weakness.
The retest check defines how another tester can verify the fix.

Your report contains restricted practice-range details, so the proof image should show only the filename. This keeps the checkpoint useful without exposing target data.

Keep finding-01.txt open in Notepad.
Press Windows logo key + Shift + S to open the Snipping Tool overlay.
Capture only the Notepad title area that shows finding-01.txt.

The captured image should show the saved filename while the document body remains outside the capture area.

✔️ My finding passes the traceability check

That is the hard part done. Your mini finding now connects the observed result to its target record, authorized reproduction steps, saved evidence, remediation, and retest check.

ⓧ I would like to double check the final finding

Confirm that C:\CPENT-Sprint\report\finding-01.txt contains Title, Affected Asset, Status, Technical Summary, Reproduction Steps, Evidence, Impact, Remediation, and Retest Check.
Confirm that the file uses only observed facts from the target database, decision log, saved scan output, and screenshot.
Confirm that Status clearly distinguishes confirmed results from untested hypotheses.
Confirm that every technical statement points to saved output or a screenshot.
Confirm that every reproduction step stays within the authorized scope in C:\CPENT-Sprint\scope.txt.
Confirm that the remediation addresses the observed weakness.
Confirm that the retest check defines how to verify the remediation.

Secret mission

Triage a Second Target in 15 Minutes

Repeat the structured workflow against the second-ranked in-scope candidate under a strict 15-minute clock. Preserve one verified fact in the second target record. Stop when the timer expires.

Clean Up Your Resources

Choose whether to keep your authorized range session active, pause it for later, or remove the local sprint evidence. The local files create no additional charges because the project uses your existing CPENT Practice Range access.

Resources you used:

An authorized CPENT CTF Range session with a VPN connection.
Your scope notes at C:\CPENT-Sprint\scope.txt.
Your structured records at C:\CPENT-Sprint\target-database.txt and C:\CPENT-Sprint\decision-log.txt.
Baseline, candidate-specific, and second-target Nmap output under C:\CPENT-Sprint\scans.
Range screenshots and second-target evidence under C:\CPENT-Sprint\evidence.
The completed mini finding at C:\CPENT-Sprint\report\finding-01.txt.

Keep everything running

No action is needed. Choose this if you are continuing the authorized range work now.

Retain the complete C:\CPENT-Sprint workspace.
Reuse the target database during future authorized range sessions.
Continue testing only the targets or subnet supplied in the current Scope of Work.
Keep CPENT range solutions, credentials, target details, and restricted screenshots private.

Pause - I'll come back to this later

End the active range work while preserving your local evidence. Choose this when you want to review the sprint later.

Disconnect from the CPENT Practice Range VPN.
Stop the CTF Range session through your current course portal workflow.
Confirm the current portal shows that the range session has stopped.
Retain C:\CPENT-Sprint for later review.
Keep CPENT range solutions, credentials, target details, and restricted screenshots private.

Delete - I don't want to use this again

Removing local practice evidence is permanent. Deleting C:\CPENT-Sprint removes every saved scan, note, screenshot, and finding inside it.

Disconnect from the CPENT Practice Range VPN.
Stop the CTF Range session through your current course portal workflow.
Confirm the current portal shows that the range session has stopped.
Sanitize every reusable template by removing range solutions, credentials, target details, and restricted screenshots.
Move sanitized reusable templates outside C:\CPENT-Sprint.
Open C:\ in your Windows file browser.
Delete the CPENT-Sprint folder.
Confirm C:\CPENT-Sprint no longer appears in your Windows file browser.

Nice Work!

You did it! You completed an authorized CPENT attack-and-report sprint under time pressure. Your evidence-backed mini finding is ready for another tester to trace.

What you learned:

Converted scoped Nmap results into a structured target database that ranks candidates using evidence-backed priorities.
Used a time-boxed decision log to test one authorized attack path without repeating a failed assumption.
Produced a traceable mini finding that links each observed claim to saved evidence.
Secret Mission: Repeated the structured workflow against the second-ranked target within a strict 15-minute limit to preserve a verified fact with a clear next action.

Ready to quiz yourself?