NightX — Operate it like a professional

00WELCOME

What this course is

Get oriented before you run a single scan.

NightX is a professional web penetration testing framework — one CLI tying together recon, header analysis, subdomain enumeration, fingerprinting, vulnerability scanning, auth testing, API testing, and reporting. This course doesn't re-explain every flag — the README already does that. It teaches the order and judgment a professional applies so a scan produces a report you'd actually hand to a client.

AUTHORIZED TESTING ONLY NightX is for authorized security testing only. Only test systems you own or have explicit written permission to test — unauthorized use is illegal. Confirm scope, testing window, and out-of-scope systems in writing before Module 01.

WHO THIS IS FORSomeone who has already run sudo bash install.sh and nightx --help at least once and wants a repeatable professional workflow instead of one-off commands.

01MODULE 01

Installation & setup

One installer, then verify before you rely on it.

git clone https://github.com/hackops-academy/nightx.git
cd nightx
sudo bash install.sh   # handles everything automatically

NightX targets Kali Linux with Python 3.9+. Once installed, confirm the CLI is on your path and review the command list before your first real engagement:

nightx --help
nightx list-scans

PRO HABITRun nightx scan http://testphp.vulnweb.com --skip-subdomains -v once right after install — a known, legal target confirms every module actually works before you point NightX at a client.

Uninstalling later is just as direct: sudo bash /opt/nightx/uninstall.sh.

02MODULE 02

Anatomy of a full scan

Know what scan actually runs before you run it unattended.

nightx scan is the full pentest — all 6 modules in sequence. Everything else in the CLI (headers, vuln, subdomains, fingerprint, api) is that same module run in isolation, which is what you reach for once you already know which phase you care about.

headers→subdomains→fingerprint→vuln→auth→api→report

nightx scan https://target.com
nightx scan https://target.com -v -t 20

PRO HABITRun individual modules (Modules 03–08 below) against a new target before you ever hand it to the combined scan command unattended — you want to know each phase's normal output and normal runtime first.

03MODULE 03

Headers module

The fastest, lowest-risk signal you'll get all engagement.

Checks HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP, CORP, COEP, cookie flags, and information disclosure — then rolls it into a score out of 100.

nightx headers https://target.com

Risk to target

None — read-only HTTP checks

Best used

First, before anything else

PRO HABITRun headers standalone before a full scan and save the score separately — it's often the single number a client's non-technical stakeholders will actually remember from your report.

04MODULE 04

Subdomain enumeration

Map the real attack surface — most of it isn't the URL you were handed.

Combines DNS brute-force with crt.sh certificate-transparency log lookups, then resolves and live-checks every candidate host.

nightx subdomains target.com \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -t 100 -o subs.txt

Bring your own wordlist with -w — SecLists is the standard choice for anything beyond the built-in list.
Raise -t (threads) for large wordlists, but watch for rate-limiting on the target's DNS or WAF.
Save results with -o so Module 06's vuln scan and Module 08's API scan can be pointed at the full discovered surface, not just the one host you started with.

05MODULE 05

Fingerprinting

Know what you're actually attacking before you attack it.

Identifies CMS platforms (WordPress, Drupal, Joomla), WAF/CDN vendors (Cloudflare, Akamai, Imperva, ModSecurity), frontend/backend frameworks (React, Angular, Vue, Laravel, Django), and 40+ sensitive paths.

nightx fingerprint https://target.com

PRO HABITA detected WAF changes your plan for Module 06 — expect blind/time-based techniques to be noisier and slower to confirm, and budget extra time for false-positive triage rather than assuming a clean read.

06MODULE 06

Vulnerability scanning

Where real payloads start leaving your machine.

Tests for SQL injection, XSS, open redirect, SSRF, path traversal, command injection, CORS misconfiguration, and clickjacking.

nightx vuln https://target.com

Class	What it means for triage
SQL injection	Manually confirm before reporting — highest severity, highest false-positive cost
XSS	Check reflection context; not every reflection is exploitable
SSRF	Verify against an out-of-band listener where possible
CORS	Confirm the misconfiguration actually exposes authenticated data
Command injection	Treat any hit as critical until disproven

THIS PHASE IS ACTIVEUnlike headers or fingerprinting, vuln scanning sends real exploit-style payloads. Confirm scope and timing windows before this module runs, the same way you would before running sqlmap or Burp's active scanner by hand.

07MODULE 07

Auth testing

Where a lot of real-world breaches actually start.

Checks for default credentials, JWT attacks, weak session-token entropy, and missing brute-force protection.

nightx scan https://target.com --skip-vuln --skip-api

PRO HABITDefault-credential findings and weak brute-force protection are the fastest wins to explain to a non-technical client — lead your report's auth section with those before the more abstract JWT/entropy findings.

08MODULE 08

API testing

Modern apps leak more through their API than their pages.

Checks for exposed Swagger/OpenAPI docs, IDOR, GraphQL introspection left enabled, mass assignment, and broken authentication on API routes.

nightx api https://target.com

PRO HABITIf fingerprinting (Module 05) flagged a frontend framework like React or Angular, always run this module — those apps almost always ship a JSON API behind the UI that the standard vuln scan alone won't fully exercise.

09MODULE 09

Flags & tuning

The difference between a scan that finishes and one that doesn't.

Flag	Short	Default	Use it when
`--output`	`-o`	`./reports`	Client wants reports in a specific folder
`--threads`	`-t`	`10`	Large scope and a target that can take the load
`--wordlist`	`-w`	built-in	You need SecLists-grade subdomain coverage
`--format`	`-f`	`html`	Client tooling needs `json` or plain `txt`
`--verbose`	`-v`	off	First run against any new target
`--skip-subdomains`	—	off	Scope is one host, not a domain
`--skip-vuln` / `--skip-auth` / `--skip-api`	—	off	Recon-only pass, or re-running just one phase

# recon only, nothing active
nightx scan https://target.com --skip-vuln --skip-auth --skip-api

# faster subdomain-heavy run
nightx scan https://target.com --skip-subdomains -t 30

10MODULE 10

Reports & history

The deliverable is the point — treat report generation like part of the scan, not an afterthought.

nightx scan https://target.com -f json -o ~/reports
nightx list-scans

Use html for a client-facing deliverable, json when you're piping results into your own tooling, and txt for a quick terminal-friendly diff between two runs.
list-scans is your audit trail — check it before a follow-up engagement so you're not guessing what was covered last time.

PRO HABITKeep -o pointed at a per-client folder from the very first scan. Retroactively reorganizing reports after the engagement is where findings quietly go missing.

11MODULE 11

The full methodology

How the modules above chain into one engagement.

1 — Confirm scope, testing window, out-of-scope systems in writing

2 — Verify the install against a legal practice target

3 — Run headers standalone — fast, zero-risk baseline

4 — Enumerate subdomains with a real wordlist; save results

5 — Fingerprint every live host discovered

6 — Run vuln scanning with confirmed scope and timing

7 — Run auth testing; lead findings with default creds

8 — Run API testing on any host with a detected framework

9 — Re-run the full scan only once each phase's output looks sane on its own

10 — Generate the client-facing report; archive with list-scans

WHAT SEPARATES A PROFESSIONAL RUN FROM A DEFAULT RUNNot the flags — the discipline of running phases individually first, verifying each one's output makes sense, and only then trusting the combined scan command unattended.

12MODULE 12

Practice range & next steps

Rehearse the whole methodology somewhere nothing is at stake.

testphp.vulnweb.com is a public, legal practice target maintained for exactly this kind of testing — use it to run the full methodology from Module 11 end to end before taking on real work.

nightx scan http://testphp.vulnweb.com --skip-subdomains -v

Run every module individually against the practice target, then the combined scan, and compare findings.
Generate all three report formats (html, json, txt) once so you know what each looks like before a client is waiting on it.
Time a full run. A professional's edge is knowing which phases are safe to parallelize and which need your full attention.

NEXTOnce the practice range feels routine, run the same methodology against your own authorized lab targets before taking on client engagements.