lesson_11: scanning isn't pressing run
01 — what this tool is trying to teach
this tool is not a scanner.
that matters.
a scanner sends traffic.
this page does not.
this page is a command planning view.
it helps you understand what a scanner command means
before you run anything for real.
micro meaning
the browser is not attacking anything
the terminal output is a preview
the command is the thing you would copy and run locally
the lesson is not:
how to scan faster
the lesson is:
how to think before scanning
because most bad scanning does not start with bad tools.
it starts with bad planning.
02 — why command generation matters
a command is not just text.
a command is a decision.
command example
nuclei -u https://example.com -t http/exposures/configs/git-config.yaml -rl 5 -c 5
this is not only saying:
run nuclei
it is saying:
target this url
use this template
limit requests to this rate
run this much concurrency
produce this kind of output
each flag changes behavior.
each behavior has operational meaning.
that is why this tool shows the command before anything else.
you should know what you are asking the scanner to do
before you do it.
03 — the target is not neutral
when you enter a target,
you are not entering decoration.
you are defining where activity will be directed.
target example: url
https://example.com
for nuclei or httpx,
this means an http target.
target example: ffuf pattern
https://example.com/FUZZ
for ffuf,
this means a url pattern.
target example: host
192.0.2.10
for nmap,
this means a host.
same input box.
different operational meaning.
that is why classification matters before scanning.
a url is not an ip.
a domain is not a cidr block.
a hostname is not automatically an owned asset.
the tool should help you slow down
before you collapse all of that into one button.
04 — scanning pressure is real
scanning pressure means:
how much activity your command may create.
it can come from:
requests per second
packet rate
threads
concurrency
crawl depth
wordlist size
template request count
port range
retry behavior
these are not cosmetic settings.
they change the amount of traffic.
pressure example
5 requests per second
does not sound dramatic.
but across many targets,
many templates,
and retries,
it can become meaningful very quickly.
micro meaning
rate controls speed
concurrency controls parallelism
timeout controls waiting
retries control repetition
depth controls expansion
wordlist size controls volume
template choice controls request shape
port range controls packet volume
this is why the interface should show pressure.
not because the estimate is perfect.
because the operator needs to think.
05 — nuclei is template-driven
nuclei does not magically “scan everything”.
nuclei runs templates.
a template describes:
what to request
what to match
what to extract
what evidence to report
template example
http/exposures/configs/git-config.yaml
this template is not the same as:
http/cves/2024/CVE-2024-22024.yaml
one may be an exposure check.
one may be a cve-oriented validation.
same tool.
different intent.
that is why the selected template matters more than the scanner name.
micro meaning
nuclei is the engine
the template is the test
the target is where the request goes
the matcher defines what counts as a hit
the output is evidence
not truth.
06 — max-request is an impact hint
some nuclei templates include a max-request value.
that value helps you estimate how many requests the template may send per target.
small template example
max-request: 1
means the template is expected to send one request per target.
larger template example
max-request: 10
means the template may send up to ten requests per target.
now multiply that.
request math example
10 requests per target
100 targets
1 retry
that is no longer just “one template”.
it may become:
1,000 planned target requests
2,000 worst-case attempts with retry
that is why request math belongs in the ui.
not to scare people.
to make the operation visible.
07 — ffuf is substitution, not magic
ffuf uses placeholders.
the most common placeholder is:
FUZZ
url pattern example
https://example.com/FUZZ
if the wordlist contains:
admin
login
backup
api
ffuf will try:
https://example.com/admin
https://example.com/login
https://example.com/backup
https://example.com/api
that is the real model.
wordlist entry becomes request.
wordlist size becomes request volume.
so the important question is not:
can ffuf find something?
the better questions are:
what am i asking it to try?
how many times?
against what target?
08 — status codes are evidence, not conclusions
ffuf output often looks exciting.
status output example
200 /backup
403 /admin
301 /login
404 /api
but each code means something different.
200 may mean content exists.
403 may mean a route exists,
but access is denied.
301 may mean a valid redirect.
404 usually means not found,
unless the application uses strange custom behavior.
micro meaning
a status code is a response signal.
it is not a vulnerability by itself.
that is why filtering matters.
and that is why the tool should teach
what each kind of result may indicate.
09 — httpx is classification before escalation
httpx is often used before heavier tools.
it helps answer:
is the host alive?
does it speak http?
what status does it return?
what title does it expose?
what technology hints appear?
is there a cdn or provider hint?
this is not exploitation.
this is classification.
httpx output example
https://example.com [200] [example domain] [cloudflare]
that tells you something about the visible web surface.
but it does not prove ownership.
it does not prove origin.
it does not prove vulnerability.
it helps decide what should happen next.
10 — subfinder produces candidates
subfinder is passive discovery.
that means it collects names from sources.
candidate name example
api.example.com
dev.example.com
staging.example.com
cdn.example.com
these are candidates.
not confirmed assets.
not automatically in scope.
not automatically alive.
micro meaning
subfinder expands the question.
dnsx and httpx help validate parts of the answer.
a weak workflow says:
subfinder found it, therefore scan it.
a stronger workflow says:
subfinder found a candidate, now classify and validate it.
11 — dnsx validates naming evidence
dnsx asks dns questions.
questions dnsx helps answer
does this hostname resolve?
does it have a cname?
does it publish mx records?
does it expose txt policies?
does it point toward a provider?
this is useful because names alone are not enough.
a subdomain may be stale.
a cname may point to a managed service.
an mx record may reveal mail posture.
a txt record may reveal verification or policy.
micro meaning
dnsx turns candidate names into dns evidence.
but dns evidence is still not ownership proof by itself.
12 — naabu sees ports, not applications
naabu discovers open tcp ports.
port output example
example.com:80
example.com:443
example.com:8080
that means:
a tcp service may be reachable.
it does not mean:
the service is vulnerable
the application is owned by the target
the port should be attacked
the correct next step is validation.
next-step example
open web ports may go into httpx.
open unknown ports may need careful service identification.
port discovery should reduce uncertainty.
not create permission.
13 — nmap is deeper validation
nmap can do more than port discovery.
it can perform service detection.
it can attempt version detection.
it can produce structured outputs.
nmap command example
nmap -sT -sV -p 80,443,8080 example.com
this asks a more specific question than:
is the port open?
it asks:
what service appears to be there?
micro meaning
port scan finds doors
service detection reads labels
version detection guesses details
none of these are impact by themselves.
they are evidence.
14 — katana expands surface through crawling
katana starts from a seed url.
then it follows links.
depending on settings,
it may parse javascript.
it may discover routes.
it may produce many urls.
crawl output example
/
/login
/assets/app.js
/api/v1/status
crawl depth matters.
depth 1 is not depth 5.
javascript parsing matters.
rps matters.
each one can expand activity.
micro meaning
crawling is not just reading one page.
it is controlled expansion.
that is why a crawl tool needs planning.
15 — amass is graph thinking
amass is not just a subdomain list.
it is closer to surface mapping.
it can connect:
domains
subdomains
ip addresses
providers
asn hints
source relationships
but graph data is not permission.
a relationship does not automatically mean scope.
a discovered name does not automatically mean asset.
micro meaning
amass helps you see possible structure.
you still need attribution.
you still need validation.
you still need rules of engagement.
16 — waybackurls is memory
waybackurls reads historical url memory.
archive output example
https://example.com/login
https://example.com/admin
https://example.com/search?q=test
these routes may be useful.
but archive data is not current truth.
a route may be gone.
a product may have moved.
a path may no longer exist.
a historical endpoint is not an invitation to replay everything live.
micro meaning
archive output is context.
not permission.
not current exposure.
not automatic scope.
17 — why the preview exists
the preview exists because beginners often copy commands without understanding them.
that is dangerous.
not because the tools are bad.
because the operator is blind.
a good preview should show:
what command will be generated
what kind of traffic it represents
what the output may look like
what the output can indicate
what the output cannot prove
where the user should slow down
that is the whole point.
not fake hacking.
not decoration.
not theater.
command literacy.
18 — metrics should teach pressure
metrics should not be decorative.
a useful metric tells the operator something real.
useful metric examples
target requests
packet budget
wordlist attempts
crawl expansion
template request count
interesting responses
noise filtered
these are learning metrics.
they help the user see the relationship between settings and activity.
pressure example
if wordlist size goes up,
ffuf request volume goes up.
if port range goes from 4 ports to 1-1024,
nmap or naabu activity changes.
if nuclei target count goes from 1 to 100,
template requests multiply.
that is the lesson.
the interface should make invisible pressure visible.
19 — output is evidence, not authority
scanner output can look official.
colors.
severity labels.
json fields.
template names.
status codes.
service names.
but output is still just evidence.
evidence examples
a nuclei hit is not automatically a vulnerability.
a 403 route is not automatically sensitive.
an open port is not automatically exploitable.
a technology fingerprint is not proof of version or impact.
micro meaning
scanner output starts the review.
it does not end the review.
20 — scope is the control layer
scope sits above every tool.
above nuclei.
above ffuf.
above nmap.
above naabu.
above archive data.
above curiosity.
scope example
if a hostname looks interesting but is out of scope,
the answer is not:
scan carefully.
the answer is:
do not scan it.
scope is not a suggestion.
scope is the authorization boundary.
without scope,
technical capability is irrelevant.
21 — what this page should produce
this page should not produce confidence theater.
it should produce a better operator.
the user should leave understanding:
what tool they selected
what the command means
what the target input represents
how much traffic the settings may create
what kind of output may appear
what the output can indicate
what the output cannot prove
what should be checked before running anything real
that is the value.
not automation.
not attack.
not speed.
planning.
22 — final line
a scanner is not the beginning of understanding.
it is what you run after you understand enough to ask a precise question.
good scanning is not pressing run.
good scanning is choosing the smallest careful action
that can answer the next justified question.