How do white-hat hackers actually break into a system? The 6-phase pentest process, from recon to web shell

No black screens of flashing green text, no single magic command that cracks a server in a split second. A widely shared summary of a hands-on freeCodeCamp course shows that real-world penetration testing is a systematic, disciplined 6-phase process: network reconnaissance with Nmap, web surface enumeration, defeating the authentication layer, exploiting a file-upload vulnerability to plant a web shell, and finally automating the whole reconnaissance stage with Bash and Python.

Quick answer

• Pentesting (penetration testing) means simulating a real attack on a system — with legal authorization — to find vulnerabilities before criminals do.
• The standard process has 6 phases: (1) Linux and command-line foundations, (2) reconnaissance and network scanning with Nmap, (3) web enumeration and fuzzing, (4) attacking authentication with Burp Suite and ffuf, (5) exploiting a file-upload flaw to install a web shell, (6) automation with Bash and Python.
• Where this walkthrough comes from: the hands-on course "How Ethical Hackers Actually Break Into Systems" by freeCodeCamp (instructor Declan Middleton), performed entirely against a dedicated Capture The Flag virtual machine — a legal, safe lab environment.
• The biggest lesson for defenders: security is a chain — one service leaking its version, one login page without rate limiting, or one upload function that never checks file types is enough to lose the whole system.
• The hard boundary: every technique described applies only to systems you own or are authorized in writing to test; breaking into other people's systems without permission is a criminal offense.

What is pentesting, and how is it different from illegal hacking?

Penetration testing is an activity in which a security specialist — a white-hat hacker — is authorized by the system's owner to play the attacker's role: using the very techniques and tools that cybercriminals use in order to find, prove and report vulnerabilities before they are exploited for real. The single decisive difference between pentesting and an illegal attack is authorization and a pre-agreed scope: the same port scan is a security service when covered by a contract and a defined scope, and a crime when it is not.

For training, pentesting is practiced in labs and CTF (Capture The Flag) virtual machines — systems deliberately built with vulnerabilities so learners can attack them legally. The original post by Lu Minh Khuong (VGU Tech Alumni group) summarizes exactly such a freeCodeCamp course, and the author states upfront that it is course material, not footage of a real-world operation.

The 6 phases at a glance

Phase	Goal	Main tools / techniques
1. Linux & command line	Master the working environment and the target machine	Parrot OS / Kali Linux, terminal, user and permission management
2. Recon & network scanning	Map open ports, services and versions	Nmap (-sV, -sC, decoy/SYN stealth scans, ProxyChains)
3. Web enumeration	Find technologies, hidden directories and endpoints	whatweb, curl -I, ffuf, dirsearch, SecLists wordlists
4. Attacking authentication	Get through the admin login gate	Burp Suite request interception, ffuf brute force (Cluster Bomb), rockyou.txt
5. Exploitation & web shell	Turn application access into server control	searchsploit / Exploit-DB, arbitrary file upload flaw, PHP web shell
6. Automation	Speed up repetitive reconnaissance	Bash host/port sweep scripts, Python (socket, requests)

Phase 1: Why does everything start with Linux and the command line?

Most powerful security tools run on Linux (dedicated distributions such as Parrot OS or Kali Linux), and security practitioners work mainly in the terminal rather than a GUI — because the command line gives precise control over processes, permissions and networking, and is easy to record and automate.

The foundational operations fall into two groups: identity and system administration — checking the current session (whoami, hostname, kernel version with uname -r), managing accounts and sudo rights (usermod -aG sudo, chmod) — and network checks: viewing local interfaces (ip a, ifconfig), testing packet replies (ping), and discovering live devices on the same subnet (netdiscover). Simple as they sound, they are the alphabet every later phase is written in.

Phase 2: How does Nmap map a system?

Faced with an unfamiliar IP address, the first objective is knowing which "doors" the machine has open:

• Basic port and service scan: Nmap identifies open ports — in the classic lab, port 22 (SSH) and port 80 (HTTP).
• Version scan (nmap -sV): pinpoints exact software and versions, for example an Apache 2.4.x web server on Debian. Version information is the key to looking up publicly disclosed exploits for that exact version.
• Default script scan (nmap -sC): automatically checks sensitive files such as robots.txt — which sometimes accidentally reveals hidden admin paths, like a file manager sitting at /extplorer.
• Low-visibility techniques: when a test must avoid intrusion detection systems and firewalls, testers combine decoy IPs (-D RND:10), SYN stealth scans (-sS) or routing through ProxyChains to diffuse the real source address.

For defenders, the message of this phase is blunt: every service exposed to the network and every version banner leaked is free intelligence for an attacker.

Phase 3: What is web enumeration looking for?

When port 80 is open but the homepage is just a default page, attention shifts to the application layer:

• Technology fingerprinting: whatweb, or inspecting HTTP headers with curl -I, reveals the server architecture, the backend language (PHP, for example) and related libraries.
• Directory and file fuzzing: tools such as dirsearch or ffuf, fed with standard wordlists like SecLists, brute-force large numbers of paths to find endpoints, hidden parameters or subdomains that exist but are never linked from the interface.
• Filtering noise by status code: excluding 403, 404 and 301 responses focuses attention on resources that actually exist instead of thousands of false trails.

Phase 4: How is the login layer defeated?

Having found an admin login but holding no credentials, the tester proceeds in two steps:

1. Capture and analyze the traffic with Burp Suite: Burp acts as an intercepting proxy between browser and server, recording the exact structure of the login HTTP POST request — the username and password parameters, the session cookie — so the authentication mechanism is fully understood.
2. Automated brute force with ffuf: the captured raw request is fed to ffuf using the Cluster Bomb technique (combining multiple lists at once) with a common password wordlist such as rockyou.txt. If the system has no rate limiting and still uses default or weak credentials, finding the right pair becomes only a matter of time.

This is one of the most common real-world weaknesses — and one of the cheapest to fix: limit failed attempts, lock accounts temporarily, enforce strong passwords and enable two-factor authentication.

Phase 5: From a login to a web shell — how?

Once inside a file-manager application (the lab uses eXtplorer, an old web file manager), the tester continues:

• Look up known vulnerabilities: searchsploit (the Exploit-DB database) checks whether the exact software version in use has publicly known flaws.
• Exploit the arbitrary file upload flaw: if the application allows uploading or creating files without strictly validating file types, the attacker can push a web shell — a small PHP script (such as p0wny-shell) that acts as a browser-based control console — into the web directory.
• Trigger the web shell: simply requesting the uploaded file's URL gives the attacker an interactive command interface on the target server: reading and writing system files, and preparing the next step of privilege escalation.

This chain shows how one "convenience" upload function can nullify every defensive layer in front of it.

Phase 6: Why must pentesters write their own tools?

A professional pentester does not retype the same commands by hand for every target. Automating reconnaissance is a required skill:

• Bash scripts: package the initial sweep — checking whether hosts are alive (ping) and quickly scanning a target port list — to save time in the first pass.
• A Python recon tool: use the socket library to resolve domains to IPs (gethostbyname) and the requests library to automatically fetch HTTP status codes, extract full response headers and analyze the server's response structure.

Writing your own tools is also the line between a "tool user" and someone who understands systems: when an off-the-shelf tool does not fit the situation, the pentester builds a replacement.

What should defenders take from this process?

Every attack phase maps to a concrete defensive layer any organization can audit today:

Weakness exploited	The matching fix
Unused services left open, software versions exposed	Close unused ports/services, hide version banners, patch and update on a schedule
Admin directories and endpoints found by fuzzing	Never rely on "secret paths" for security; put authentication and IP restrictions on admin areas
Login without rate limiting, default/weak passwords	Limit attempts, temporary lockouts, change all defaults, enforce MFA and strong passwords
Upload function that never validates file types	Validate extensions and content server-side, store uploads outside the web root, never grant execute rights on upload folders
Nobody reads the logs	Monitor authentication and access logs for anomalies — almost every step above leaves clear traces

Frequently asked questions

Where do you start learning pentesting?

Following the summarized course's own path: get solid on Linux and the command line first, then networking fundamentals (ports, protocols, DNS), then scanning and exploitation tools — and practice only in labs or authorized CTF virtual machines, never on other people's real systems.

Is pentesting just running off-the-shelf tools?

No. Ready-made tools (Nmap, Burp Suite, ffuf) are only the surface; what decides outcomes is systematic thinking — reading scan results, chaining small clues into an attack path, and writing your own Bash/Python automation when needed, as phase 6 of the process shows.

What should a small business without a security team check first?

The three cheapest, highest-impact items map to the three broken links in this walkthrough: change every default password and enable login-attempt limits; audit every file-upload feature on the website; close unused ports/services and update software that is no longer supported.

How dangerous is a web shell?

Very. A web shell gives an attacker an interactive control interface directly on the web server — stealing data, defacing the site, planting more malware and using the server as a springboard into the internal network. It is often the starting point of major data breaches.

Can I try these techniques on someone else's website "just to check for them"?

No — legally, that is unauthorized intrusion regardless of good intentions, because you have no permission from the system owner. Legitimate pentesting always requires a written agreement and scope beforehand, or happens inside a lab/CTF environment.

Conclusion

The full picture from freeCodeCamp's course shows that real pentesting is a job of patience and method: most of the time goes into reconnaissance, enumeration and connecting clues, while the moment of "owning the server" is merely the final result of a chain that was already weak. For administrators and business owners, understanding this process is not about attacking anyone — it is about knowing exactly which link of your own chain is exposed, before someone else points it out the unwanted way.

Source: shared by Lu Minh Khuong in the VGU Tech Alumni Facebook group (3 Nov 2026), summarizing freeCodeCamp's course "How Ethical Hackers Actually Break Into Systems", edited and extended with a defender's perspective by Wotech Electronics.