Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Mini Vulnerability Scanner

An internship-scoped project covering the first three phases of a real penetration test: recon (what's exposed), enumeration (what's running), and reporting (what to fix, ranked by severity). It does not include exploitation — matching a version to a known CVE and running an exploit against it are different skills, and this project deliberately stops at identification.

⚠️ Read this before running it

Only scan systems you own or have explicit written authorization to test. Port scanning and probing systems you don't control is illegal in most jurisdictions (e.g. the US Computer Fraud and Abuse Act, UK Computer Misuse Act) even if nothing is damaged or taken. scan.py requires you to type a confirmation before it scans anything — that's not boilerplate, it's the actual line between "practicing pentesting" and "committing a crime." Good default targets while learning: 127.0.0.1 / localhost, a VM you built yourself, or a legal practice range like TryHackMe or Hack The Box.

Files

File Role
port_scanner.py Threaded TCP connect scan + banner grabbing across common ports (or a custom range).
fingerprint.py Matches grabbed banners against a small table of known-outdated-version signatures (CVE + description, no exploit code).
http_checks.py Fetches a URL and checks for missing security headers (HSTS, CSP, X-Frame-Options, etc.) and cookie flag issues.
report.py Aggregates findings into a severity-sorted report, rendered as HTML or JSON.
scan.py CLI entry point — wires everything together, gated behind the authorization prompt.

Running it

# Basic scan of your own machine
python3 scan.py 127.0.0.1

# Also check a web app's HTTP headers, custom port range, save as JSON
python3 scan.py 127.0.0.1 --ports 1-1024 --http http://127.0.0.1:8080 \
    --format json --out report.json

# Each module also runs standalone for testing/learning:
python3 port_scanner.py 127.0.0.1
python3 fingerprint.py
python3 http_checks.py http://127.0.0.1:8080

No third-party dependencies — pure standard library (socket, concurrent.futures, urllib, ssl, json), so it runs anywhere Python 3.10+ is installed.

How each phase works

1. Port scanning (port_scanner.py) A "TCP connect scan": for every candidate port, attempt a full socket.connect(). If the handshake succeeds, the port is open, and the script tries to read whatever the service says first (its "banner") — many services (FTP, SSH, SMTP) announce their software name and version unprompted, which is exactly the information an attacker (or a defender doing an audit) wants. This is the same core technique nmap -sT uses; a raw SYN scan is faster and stealthier but needs raw-socket privileges, which is out of scope for a pure-Python educational tool.

2. Identifying outdated software (fingerprint.py) Banners are matched against a small table of regexes mapped to real CVEs — e.g. the vsftpd 2.3.4 backdoor (CVE-2011-2523), the Apache 2.4.49 path traversal (CVE-2021-41773). This is "version-based vulnerability identification," the same idea behind tools like nmap --script vuln or vulners, just at a much smaller scale. A real assessment would pull from a live, maintained feed (e.g. NVD's API) instead of a hardcoded list.

3. Weak configuration checks (port_scanner.py + http_checks.py) Two kinds: ports that are risky to expose regardless of what's running on them (databases, Telnet, SMB — see RISKY_IF_OPEN), and HTTP response headers that indicate a web app is missing standard defenses (HSTS, CSP, secure cookie flags). Both are the kind of finding a real audit checklist opens with, because they're cheap to check and commonly missed.

4. Reporting (report.py) Findings are tagged critical / high / medium / low / info and sorted so the most urgent items are read first — the same shape as a real pentest report, just without the executive-summary prose. HTML output is meant to be skimmable by a non-technical stakeholder; JSON output is meant to feed into other tooling (a ticketing system, a dashboard, CI).

Ideas for extending this

  • Swap the hardcoded SIGNATURES table for live lookups against the NVD CVE API.
  • Add a raw-socket SYN scan mode (requires root) for speed comparison against the connect-scan approach.
  • Add TLS/certificate checks (expired certs, weak cipher suites, self-signed certs on a production host).
  • Add authenticated checks (e.g. default-credential testing against a service you've deliberately configured with known test credentials, in your own lab only).
  • Export findings in a format matching a standard framework, e.g. mapping each finding to an OWASP Top 10 or CWE category.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages