Dive Into Pentesting — Jr Penetration Tester Path (Part 1)

TryHackMe

The whole point of this room is figuring out where the weaknesses are in systems and networks before attackers get there first. The main things I took away: understanding what separates a malicious hacker from an authorized one, getting a grip on how vulnerability, threat, and risk actually relate to each other, and learning why those vulnerabilities exist in the first place.

Pentesting vs. Malicious Hacking

Pentesting is an authorized security assessment. You’re operating on written consent, within agreed boundaries. You might be allowed to attack a web app or run a phishing simulation, but you’re not touching production databases or launching denial-of-service attacks. Even when an attack is permitted, there’s a defined scope — and you don’t step outside it.

Here’s how the two actors break down:

FactorPenetration TesterMalicious AttackerAuthorizationOperates with explicit written consent from the system ownerNo consent — violates the rights and security of the organizationScopeWorks within a clearly defined boundary set by the organizationNot restricted by scope — targets whatever helps them reach their goalCoverageAims for broad coverage across multiple areas of a systemFocuses on the quickest or most effective path, often chasing financial gainResponsibilityAccountable for their actions, expected to act professionallyNo accountability, no responsibility for the damage caused

📌 Q: What is the common shortened term for penetration testing? Pentesting

📌 Q: Which actor aims for broad coverage and assesses multiple areas of a system?

Penetration Tester

📌 Q: Which actor focuses on the quickest path to success?

Attacker

Scope of Operations

Knowing your scope is what lets you actually use your skillset properly. Two main areas:

Web App Pentesting

This one’s handled from the customer’s perspective — how the app takes input, what it does with that input, what the UI exposes, whether the API is leaking anything it shouldn’t be. The goal is finding those gaps before someone on the internet finds them for you.

A few core concepts to understand here:

Authentication — Simply: who are you, and how do you prove it? Passwords, MFA, PINs, biometrics — all of this falls here.

Authorization — Should you be here? You can log into your own Netflix account. You shouldn’t be able to log into someone else’s. That’s the distinction.

Session Management — How is an ongoing session created, maintained, and closed? This covers things like idle timeouts (you’ve seen this on banking sites — stay inactive too long and you’re logged out automatically), what protective measures are in place against CSRF, and how the logout process actually works.

Input and Output Validation — There’s a saying in retail that the customer is always right. Here, the opposite applies: never trust user input. Always validate what comes in and think carefully about how your app handles and responds to it.

Security Configuration — This is where you look for things like weak cryptography, gaps in server or app config, missing security headers, and sloppy error handling.

Network Penetration Testing

This focuses on the infrastructure connecting everything — routers, switches, servers, workstations, firewalls. Testing can be done from the outside or from within.

External testing is done from the perspective of someone with little to no prior access. The focus is on internet-facing infrastructure: servers, firewalls, VPN gateways, remote access services. How exposed are they? What controls are protecting them from unauthorized users?

Internal testing is an “assumed breach” scenario — a threat actor already has a foot in the door. The question becomes: what can they do next? Move laterally? Escalate privileges? Access sensitive data? This type of assessment looks at trust relationships, access controls, and network segmentation to figure out whether the existing controls can actually limit the damage.

The foundational concepts here are the same as web app testing, but the focus shifts — instead of session cookies and CSRF, you’re looking at VPN configurations, software credentials, exposed services, and so on.

📌 Q: What type of network penetration test focuses on internet-facing infrastructure from the perspective of an unauthorized user?

External

📌 Q: During testing, you discovered that session cookies remain valid after a user logs out of the application. Which testing focus area does this issue fall under?

Session Management

Vulnerability, Threat, and Risk

These three terms get used together constantly, and for good reason — they build on each other.

Vulnerability is a weakness or gap in an organization’s environment. By itself, it doesn’t cause harm. Running outdated software isn’t going to crash your systems on its own, but it leaves a door open.

Threat is anything that can exploit that vulnerability and cause harm. Threats can be malicious actors — cybercriminals, insider threats, automated attack scripts. A good example of the “automated” part: the 2020 KuCoin breach, where the attacker drained funds using automated scripts. You could tell they were automated because transactions were firing roughly every 19 seconds — a pattern visible in the on-chain CSV data. But threats don’t have to be malicious either. Back when I was working as a 3D designer, we dealt with data loss regularly — not because of any attacker, just machines that couldn’t handle the workload.

Risk is the potential damage if a threat successfully exploits a vulnerability. The formula is straightforward: Vulnerability × Threat = Risk.

There’s also a useful rule of thumb: the cost of fixing a risk shouldn’t exceed the cost of what you’d lose if that risk materialized.

Two quick examples of how this plays out:

Low Risk — A web app shows verbose error messages with internal file paths when something breaks. An attacker can trigger errors to gather system info, but all they’re getting is reconnaissance material. Not great, but not catastrophic.

High Risk — A web app lets users change an account ID parameter in a request and pull up other users’ data. That’s broken access control. An attacker modifying those parameters gets access to sensitive customer data, which means data privacy violations and regulatory consequences. That’s a serious risk.

Risk Management

Knowing what risk is gets you halfway there. Managing it is the other half.

Identification — Figuring out what assets, vulnerabilities, and threats are actually in play.

Analysis — Evaluating how likely exploitation is and what the impact would be. This determines severity and helps prioritize what to fix first.

Mitigation — Taking action: patching, tightening access controls, fixing configurations, adding monitoring, or redesigning insecure processes.

Monitoring — Keeping an eye on things continuously so that new vulnerabilities get caught and controls stay effective over time.

📌 Q: An organization patched a high-severity issue that you reported. What stage of the risk management cycle does this activity fall under? Mitigation

📌 Q: Would an SQL injection vulnerability present a higher risk on an external-facing application or an internal-facing application?

External-facing application

That’s Part 1. Part 2 will go deeper into the Why Vulnerability exists | Pentester Mindset | Ethics, Permission and Trust. Follow along here for the next writeup.