A Beginner's Guide to Penetration Testing: Tools, Techniques, and Best Practices

What a penetration test actually involves — the process, the tooling, the paperwork, and the way in.

---

---

Stand up a fresh VPS with SSH on port 22 and watch the auth log. You will see the first credential-stuffing attempt inside an hour, usually within minutes, from a botnet that found you by sweeping the provider’s entire address range. Nobody targeted you. You were simply reachable.

That is the baseline your infrastructure sits in, and it is why penetration testing exists. Also called ethical hacking, it is the practice of attacking your own systems deliberately and under controlled conditions, to find what breaks before somebody else does it uninvited. The difference is not whether the vulnerability gets discovered. It is whether you discover it on a Tuesday afternoon with a remediation window, or read about it in a breach notification.

This guide walks through the methodology, the tooling, the legal boundaries that keep the work lawful, and the route in if you want to do this for a living. It is written for two readers: the person considering the career, and the person signing off the invoice who wants to know what they are actually buying.

---

What Is Penetration Testing?

Penetration testing — pentesting — is an authorised, simulated cyberattack against a system, network, or application. The word that matters in that sentence is authorised. Strip it out and you have described a crime.

The practical distinction from a vulnerability scan is chaining. A scanner tells you that an internal file share allows anonymous read. It does not tell you that the share contains a decade-old deployment script, that the script has a service account password in plaintext, that the account is a member of a group nested three levels deep into Domain Admins, and that the whole path from anonymous to enterprise takes about eleven minutes. Each individual finding is a medium. The chain is a company-ending incident. Only a human joins them up.

Running a penetration test lets you:

• Surface what scanners structurally cannot find. Business logic flaws — a checkout that accepts a negative quantity, a password reset that trusts a user-supplied email header — have no CVE and no signature. They are found by someone who understands what the application is for.
• Validate your defences. You find out whether the EDR agent actually fired, whether the alert reached a human, and whether that human did anything. Buying the tool and having the tool work are separate achievements.
• Understand real impact. “SQL injection present” and “SQL injection present, and here is a screenshot of your customer table” produce very different responses in a budget meeting.
• Meet compliance requirements. PCI DSS, HIPAA, SOC 2, and ISO 27001 all expect regular testing. Be aware of the trade-off: compliance-driven testing tends to be scoped narrowly and priced down, which is precisely how a tick-box pentest ends up missing the thing that eventually kills you.

✨ Fun Fact

The idea goes back to the late 1960s and 1970s, when the US government assembled “Tiger Teams” to attack the security of military time-sharing systems. The conclusion they reached — that multi-user systems could not be made secure by inspection alone, only by adversarial testing — is still the entire argument for the profession.

Who Performs Penetration Testing?

• Internal red teams: In-house offensive staff who test continuously and know the environment intimately. That knowledge is also the weakness — after eighteen months on the same estate, you stop seeing the things you have walked past a hundred times.
• Third-party consultancies: Bring fresh eyes and the independence an auditor will accept. They also arrive knowing nothing about your architecture, so a meaningful chunk of a two-week engagement is spent learning what your own team already knows.
• Bug bounty hunters: Researchers testing public assets under a published programme, paid per valid finding. Excellent breadth and continuous coverage on internet-facing surfaces; no coverage at all of anything behind the login wall that nobody thought to scope, and no report at the end.

---

Why Penetration Testing Matters Today

The perimeter stopped being a meaningful concept somewhere around the point your staff started authenticating to SaaS applications from home laptops. Identity is the perimeter now, and identity is a much harder thing to draw a box around. Four reasons testing has moved from luxury to baseline:

1. You pick the timeline, or the attacker does Finding a critical flaw during a scheduled engagement means a patch window, a change request, and a Thursday. Finding it during an incident means a conference bridge at 3 a.m. with your general counsel on the line. Same vulnerability, wildly different week.

2. The financial case Regulatory fines are the visible part. The rest is forensics retainers billed by the hour, legal counsel, notification costs, cyber-insurance excess, and the sales pipeline that quietly stops converting for two quarters. An annual test is cheap by comparison — though be honest that it buys reduced probability, not immunity.

3. Cutting through scanner noise A network scan of a mid-sized estate routinely returns several thousand findings, most of them informational, many of them false positives on backported patches. A tester tells you which three are reachable, which two chain, and which one is the reason you should cancel someone’s evening. That triage is most of the value.

4. Testing whether anyone is watching The technical findings are half the deliverable. The other half is a timeline: at 14:12 we ran a credential-dumping tool on a domain-joined host, and nothing happened. No alert, no ticket, no call. That single line moves more budget than a page of CVEs, because it is not a hypothetical about a tool — it is a fact about your team.

---

Approaches to Penetration Testing

Engagements are categorised by how much the tester is told at the start. This is the “box” model, and choosing the wrong box is the most common way a client wastes their own money.

1. Black Box Testing

The tester gets a company name or a domain and nothing else. Topology, architecture, credentials — all of it has to be discovered.

Realistic, and it produces the most convincing narrative for a board. The cost is arithmetic: on a ten-day engagement you may spend four days on reconnaissance and initial access, leaving six to test the application everyone actually cared about. If your goal is coverage rather than a realism exercise, you have just paid consultancy rates for subdomain enumeration.

2. White Box Testing (Crystal Box)

Full transparency — source code, architecture diagrams, network maps, usually administrative credentials.

This is the efficient option for depth. Reading the authentication middleware finds the flaw in twenty minutes that black-box fuzzing might never surface at all. It simulates an insider, or an attacker who has already spent months inside your network quietly reading things. What it will not tell you is whether they could have got in.

3. Gray Box Testing

Partial information: typically a low-privilege user account and a rough network diagram.

The default, and usually the right one. It skips the part attackers find easy — phishing one credential out of a workforce of two thousand is not an interesting research problem — and spends the budget on the part that determines actual blast radius: escalation, lateral movement, and how far a single compromised employee account reaches.

---

The Penetration Testing Methodology

Professional work follows a structured process. The Penetration Testing Execution Standard (PTES) is the common reference; most consultancies run some variation of it.

1. Pre-Engagement Scope is locked down before anything is touched. Rules of Engagement define what is in scope, what is explicitly out, which hours are permitted, and who gets phoned when something falls over. Establish the emergency stop channel here and confirm somebody answers it — a testing window at 02:00 with an out-of-hours contact who has left the company is a genuinely bad night. No signed Statement of Work, no packets.

2. Reconnaissance and OSINT Passive intelligence gathering, with no traffic sent to the target. Certificate transparency logs for forgotten subdomains, public code repositories for committed API keys, job adverts that name the exact EDR product and version in the requirements, staff listings for a phishing pretext. Recruitment pages leak more architecture than most people believe.

3. Threat Modelling and Vulnerability Identification Active scanning begins. Ports, services, versions, and known CVEs are catalogued and mapped against what the reconnaissance suggested. Expect noise here: version banners lie, and Linux distributions backport security fixes without changing the version string, so a scanner will happily report a critical against a package that was patched months ago. Verifying which findings are real is the work.

4. Exploitation Injection flaws, authentication bypasses, deserialisation bugs, unpatched services — whatever provides a foothold. The aim is a controlled, evidenced proof: enough to demonstrate impact, not one step further. A tester who dumps an entire production database to prove SQL injection has caused an incident rather than documented one.

5. Post-Exploitation and Lateral Movement Now the question is blast radius. Can a standard user reach Domain Admin? Which file shares open up? Does persistence survive a reboot? This is the phase that answers what every executive actually wants to know, and it is where an engagement earns or loses its fee.

6. Reporting The only artefact that outlives the engagement. Two layers: an executive summary written in business risk, and a technical section with screenshots, request/response pairs, timestamps, and remediation specific enough to act on. “Implement input validation” is not remediation. “Parameterise the query at OrderController.cs:214” is. If your report cannot be handed straight to a developer, you have written a document, not a deliverable.

7. Retesting The tester returns after remediation to confirm the fixes hold and have not introduced anything new. Budget for this at the start. Retests bolted on afterwards tend to be dropped when the quarter gets tight, and an unverified fix is a fix that a surprising percentage of the time does not work.

---

The Pentester’s Toolkit: Essential Tools

Tools do not find vulnerabilities; they collect evidence quickly so a person has time to think. That said, everyone runs roughly the same set, and knowing what each one is bad at matters more than knowing what it is for.

Network Enumeration and Scanning

• Nmap: Host discovery, port scanning, service and OS fingerprinting, plus a scripting engine that does far more than most people use it for. Its default timing is polite enough to miss things on congested links and slow enough to bore you on a /16, so learn the timing templates before you learn the flags.
• Masscan: Sends packets asynchronously and will sweep an entire external range in minutes. The trade-off is accuracy — at high rates it drops responses and under-reports. Standard practice is Masscan for breadth, then Nmap against the hits for anything you intend to write down.

Vulnerability Scanners

• Tenable Nessus / Qualys / OpenVAS: Automated detection of known CVEs, misconfigurations, and missing patches at scale. Treat the output as a list of leads. Unauthenticated scans in particular infer far more than they confirm, and the backported-patch problem means a confident “critical” is frequently nothing at all.

Exploitation Frameworks

• Metasploit Framework: A curated library of working exploits and payloads with a consistent interface, which turns a day of debugging someone’s proof-of-concept C into a five-minute check. The cost is noise: its default payloads and named pipes are signatured by every EDR product on the market, so on a mature estate it is more useful for validation than for stealth.
• Cobalt Strike: Commercial adversary-simulation tooling for command-and-control and post-exploitation, used by mature red teams — and, for years, by ransomware crews working from cracked copies. That dual life is why its default profiles are so heavily detected, and why serious operators customise everything.

Web Application Testing

• Burp Suite Professional: The intercepting proxy the industry has standardised on. Everything between browser and server becomes editable, which is the whole game for web testing. Client-side validation is a suggestion once traffic passes through it.
• OWASP ZAP (Zed Attack Proxy): Free, open source, and genuinely capable. The active scanner is weaker and the extension ecosystem thinner, but for learning — and for CI pipelines where per-seat licensing is awkward — it does the job.

Password Attacks

• Hashcat: GPU-accelerated hash cracking. Rate depends entirely on the algorithm: NTLM falls at an absurd pace, while a correctly configured bcrypt work factor will still be grinding next week. That gap is the argument for modern password hashing, in one benchmark.
• Hydra: Online brute-forcing against live services — SSH, FTP, HTTP, SMB. Loud by nature, and quite capable of locking out every account in a domain if you point it at Active Directory without checking the lockout threshold first. Do that during a business day and you have caused the outage yourself.

---

Legal and Ethical Boundaries

The techniques in this article are, without authorisation, criminal offences in most jurisdictions — the Computer Misuse Act in the UK, the CFAA in the United States, Malaysia’s Computer Crimes Act 1997. Good intentions are not a defence in any of them. The paperwork is the only thing standing between the two readings of your traffic.

1. Written authorisation is everything Explicit, written permission from someone with the legal authority to grant it. Note the second half of that sentence: a friendly engineer inside the client is not that person, and “the CTO said it was fine on a call” is not a document. Get the signature before the first packet, every time.

2. Stay in scope If the RoE names app.example.com, then api.example.com is off limits until it is added in writing. This bites hardest in cloud environments, where an IP address you resolved this morning may belong to a different tenant this afternoon, and where the provider has its own testing policy that your client cannot waive on their behalf.

3. Handle sensitive data carefully You will encounter personal data, financial records, and health information. Take the minimum evidence that proves the finding — a redacted row, a record count, a screenshot with the fields masked — rather than exfiltrating the table because it was easy. Encrypted storage, secure transfer, documented destruction when the engagement closes. A tester’s laptop is itself an attractive target for precisely this reason.

4. Don’t break what you’re testing Unplanned outages destroy the relationship and, more practically, end the engagement early. Denial-of-service testing and memory-corruption exploits with a real crash probability stay out unless they are explicitly scoped, scheduled, and agreed. When in doubt, demonstrate the vulnerability exists rather than proving how far it goes — then discuss the rest with the client before you do it.

---

Starting Your Career in Penetration Testing

There is no direct route in, and the industry is unusually honest about it: almost nobody’s first job is a pentest job. Help desk, network administration, systems engineering, or a SOC seat comes first. That is not a detour. Attacking systems you have never had to run is how you produce findings that are technically true and operationally useless.

1. Master the Fundamentals

You cannot break what you cannot explain.

• Networking: TCP/IP, DNS, HTTP, TLS, subnetting, routing — practically, not as exam trivia. If you cannot read a packet capture and say what went wrong, half of network testing is guesswork.
• Operating systems: Linux administration from the command line, and Windows with real Active Directory depth. Kerberos in particular. A large share of enterprise findings come down to how Kerberos delegates trust and how service accounts are configured, and you cannot bluff it.
• Scripting: Python for tooling, Bash and PowerShell for everything you do on a host once you are on it. Not to write frameworks — to parse output, iterate a list, and stop doing the same thing four hundred times by hand.

2. Practice Legally

Only against targets you own or are explicitly permitted to attack. The platforms exist so you never need to make that judgement call:

• Hack The Box: Realistic machines and full lab networks, harder and less guided than the alternatives.
• TryHackMe: Structured, gentler paths through networking, web, and privilege escalation. The better starting point if you are new.
• PortSwigger Web Security Academy: Free, exhaustive, written by the people who build Burp. Nothing else in web security comes close on value.

The trap is well known: platform machines are built to be solvable, and always have a way in. Real estates are frequently boring, well-patched, and fall to one forgotten service account. Do not mistake fluency in labs for fluency in engagements.

3. Get Certified

Certification does not make you a tester. It gets your CV past a filter and gives you a syllabus to work through, which are both worth something.

• CompTIA Security+ / PenTest+: Foundational and widely recognised by HR, particularly where government or defence contracts require a listed qualification.
• eLearnSecurity eJPT: Hands-on and accessible. A reasonable first practical exam.
• TCM Security PNPT: Full simulated engagement ending in a written report and a debrief — the report requirement makes it unusually representative of the actual job, and it is priced far below the market.
• Offensive Security OSCP: Still the one hiring managers look for. A long, punishing practical exam followed by a report that also gets marked. It proves you can keep working methodically while stuck, which is most of the job. It does not prove you can test a modern cloud estate, and it should not be your last certificate.

4. Build the Mindset

The technical ceiling is high, but the trait that actually separates testers is stubbornness applied systematically. Reading a feature and asking what happens if the input is negative, or arrives twice, or is submitted by someone who logged out three steps ago. Most real findings are legitimate functionality used in a way the developer never pictured — and finding them means being willing to sit with something boring for two hours after the interesting ideas have failed.

---

Conclusion

A penetration test converts an unknown into a ticket with an owner and a due date. That is the whole proposition, and it is worth being clear about its limits: a test is a snapshot of one scope on one set of dates. Deploy on Friday and the snapshot is already out of date. It complements patching, monitoring, and secure development. It does not substitute for any of them, and a report that sits unread in a shared drive has bought you precisely nothing.

For the individual, the appeal is that the work rewards three skills that rarely appear together — deep technical knowledge, lateral problem-solving, and the ability to explain a Kerberos delegation flaw to a finance director in a way that gets it fixed. The third one is the scarce one, and it is what turns a competent tester into a senior one.

Start with the fundamentals, practise where it is legal, get the paperwork right, and write reports somebody can act on. The rest follows.

---

Ready to Fortify Your Cybersecurity?

If you want a second opinion on your scope, your last report, or where to start, book a free consultation with me here:

https://www.cal.eu/rokibulroni/meeting

Share Your Thoughts!

Have questions or insights about penetration testing? Leave a comment below and join the conversation. If you found this guide helpful, don’t forget to share it with others interested in cybersecurity. You can also check out more articles and resources at rokibulroni.com to deepen your knowledge and stay informed about emerging cyber threats.