Dive into Pentesting

Introduction to Pentesting :- Pentesting is a proactive security practice used to find weakness in systems, application or networks before an attacker can find and exploit it. As modern systems getting more and more complex, the value of pentest keeps increasing. This room covers what pentesting actually is, how its different from malicious hacking, focus areas during a pentest, relation between vulnerability, threat and risk, why vulnerabilities exist, mindset of a good tester, and ethics/permission/trust principles.
Penetration Testing vs Malicious Hacking :-

What is Penetration Testing - Pentesting is an authorised security assessment performed on systems, application or networks. It's done with explicit permission from system owner and within agreed boundaries only. Its important because modern systems are complex and keep changing constantly, so its hard for organisation to catch every weakness just through design and development. Even a well built system can have hidden weakness. Pentest fills this gap, tells the org how these weakness can be abused so they can prioritise fixing it before real attacker finds it.

Why Pentesting matters -

Helps org prioritise remediation based on risk level.
Protects confidentiality of sensitive data like payment info or PII, and helps stay compliant with frameworks like PCI-DSS and GDPR.
Real world attack simulation checks whether existing security controls actually work.
Gives assurance to leadership, stakeholders and customers that weakness are handled proactively.

Pentester vs Malicious Attacker — (Core Differences)

Authorisation - Pentester — Works with explicit written consent from system owner. Attacker — Works without consent, violates rights and security of the org.
Scope - Pentester — Works within a clearly defined scope set by org to protect critical systems. Attacker — No scope restriction, targets anything that helps them reach their goal.
Coverage - Pentester — Aims for broad coverage, assesses multiple areas of system. Attacker — Focuses only on quickest/most effective path, mostly targets stuff that gives financial benefit.
Responsibility - Pentester — Accountable for actions and impact, expected to be professional always. Attacker — Feels no accountability, takes no responsibility for damage caused.
Penetration Testing Focus Area :-

In a pentest coverage is very important to fully assess the overall security posture on an org. To get meaningful coverage, understanding different areas a tester looks at is necessary.

Web Application Penetration Testing - This focuses on finding gaps and weakness in a web application. Testing usually done from user perspective, interacting with app's UI and its APIs. Goal is to check how app handles user input, authentication, authorisation, sessions and data processing. Since web apps are usually exposed to internet, weakness here can have big impact on users.

Areas checked in Web App Pentest -

Authentication — Checked for weakness in credential handling, password policy, account lockout, MFA implementation, protection against brute-force/credential stuffing, password reset flow and overall auth logic.
Authorisation — Checked for weakness in access control, making sure user can only access resource/action permitted by their role, and protection against vertical and horizontal privilege escalation.
Session Management — Checked for weakness in how session created, maintained and invalidated. Includes session fixation risk, session invalidation after logout, idle timeout enforcement, secure cookie attributes, and CSRF protection.
Input and Output Validation — Checked for weakness in data handling, includes protection against injection attacks, data type validation, and output handling.
Security Configuration — Checked for gaps in server/app config, includes security headers, error handling behaviour, rate limiting, cryptographic config, and exposure of unnecessary services/features.
Network Penetration Testing - This focuses on finding vulnerability in underlying infrastructure that connects systems together. Can be done from external or internal user perspective.

External Network Pentest — Done from external user perspective with little to no info about externally exposed systems. Focuses on external facing infra like internet facing servers, firewalls, VPN gateways, remote access services. Goal is to check how these are exposed and what controls protect them from unauthorised users.

Internal Network Pentest — This is an "assumed breach" scenario, meaning attacker already has access to a system in network. This assessment checks what attacker could do next — moving between systems, escalating privilege, or accessing sensitive data. Goal is to assess trust relationships, access controls, and network segmentation to find weak configs and see if security controls can limit impact of compromise.

Areas checked in Network Pentest -

Authentication Mechanisms — Checked for weakness in network level auth controls like password policy, MFA enforcement, credential reuse, default credentials, and protection against attacks on services like admin portals, VPN, SSH, RDP.
Authorisation and Access Controls — Checked for weakness in network access control, making sure users/systems only access what's permitted by their role/trust level.
Network Segmentation and Trust Relationships — Checked for weakness in trust relationships, firewall rules, and isolation controls.
Configuration and Patch Management — Checked for gaps in device config/services, like outdated software, insecure default config, weak encryption protocols.

Modern web apps and networks are built with many interconnected components/systems. Identifying attack surface helps org find every entry point that could hold weakness and give unauthorised access to attacker. This also helps define scope of pentest before the engagement starts.

Vulnerability, Threat and Risk :-

These 3 are core concepts in cybersecurity used together. They let org assess and manage security concerns in structured way. Understanding relation between these helps a pentester communicate findings and its significance to stakeholders clearly.

Vulnerability - A weakness or gap in org's environment that could be exploited to compromise security of systems, data or operations. It doesn't cause harm on its own, just presents an opportunity for exploitation. There's many types, but focusing on technical vulnerability — weakness in software, systems or config that can be exploited due to coding errors, insecure settings, or flawed design. Example — A web server running outdated software with known flaws is a vulnerability. Weakness exists but nothing happens unless someone takes advantage of it.
Threat - Anything that can exploit a vulnerability and cause harm to org's environment. Represents source of danger that can take advantage of weakness to compromise confidentiality, integrity, availability (CIA) of systems. Threats can be malicious actors like cybercriminals, insider threats, or automated attack tools. Can also be non-malicious like system failures, human error, or environmental incidents. Example — Attacker scanning internet for outdated servers is a threat, they have capability and intent to exploit. Note — Nowadays attackers use AI to automate attacks, find weakness at scale and speed up exploitation. This makes AI a big threat in modern environments.
Risk - Potential damage that could occur if a threat successfully exploits a vulnerability. Overall risk = combining impact and likelihood of exploitation. Sometimes a harmless looking vulnerability can cause big risk if it affects critical system, and a harmful looking one might cause minimal risk if it exists in isolated environment.

Formula (simplified, not a formal calculation) - Vulnerability * Threat = Risk A vulnerability alone isn't risk if no threat can leverage it, and a threat can't cause impact if there's no vulnerability to exploit.

Example — Low Risk - Web app shows detailed error message on invalid input. Vulnerability — Verbose error message revealing internal file paths. Threat — Attacker triggering errors to gather system info. Risk — Limited info disclosure, helps recon but doesn't directly compromise system.

Example — High Risk - Web app lets user change account ID parameter in request and access other user's data. Vulnerability — Broken access control allowing unauthorised access to user data. Threat — Attacker modifying request parameter to retrieve/alter other's sensitive info. Risk — Exposure/manipulation of sensitive customer data, leads to privacy violation and regulatory consequences.

Risk Management - A structured process orgs use to identify, evaluate and control security risks over time. Means understanding which risk matters most and applying right controls to reduce impact/likelihood.

4 Stages of Risk Management Cycle -

Identification — Identifying assets, vulnerabilities, and potential threats affecting org.
Analysis — Evaluating risk to determine impact and likelihood, this decides severity and helps plan remediation.
Mitigation — Reducing/controlling identified risk. Can be patching, strengthening access control, improving config, monitoring tools, or redesigning insecure process.
Monitoring — Continuous monitoring to make sure controls stay effective, new vulnerability gets caught, and emerging threats addressed fast.

Sometimes org may accept or transfer risk if mitigation isn't practical/cost-effective. Accept — Chosen when impact is minimal and cost of reducing risk outweighs benefit. Example — Internal web app shows server version in header. Company accepts risk since version is up to date, app is internal only, and no sensitive data involved. Mitigating is costly and takes time/resource.

Transfer — Shifting responsibility to third party, like buying insurance to cover cost of the risk. Example — Online platform storing payment/personal info buys cyber insurance to cover financial cost if breach happens, because even with effective controls in place, risk can't be fully removed.

Why Vulnerability Exist :-

Vulnerabilities occur through flaws, features, or human error, and can result in compromise of data/resource. Attacker can exploit one or more to reach their goal. Here's common reasons why vulnerability exist -

Human Assumptions - Developers who aren't security aware often assume users will use system only as intended. Attacker challenges this assumption on purpose by using system in unintended way to expose weakness. Example — Dev assumes user will only upload image as profile picture. No file validation in place lets attacker upload malicious script, which server then executes.
Software Bugs - Programming errors introduce unintended behaviour that can be a security risk, arises from logic mistake or incomplete validation. Code might work as designed but still be flawed if not securely coded. Example — Web app doesn't validate input properly when processing form data that interacts with DB. Attacker submits crafted input that alters SQL query, gets unauthorised access to sensitive data.
System Complexity - Modern environments have many interconnected components like APIs, microservices, DBs, third party integrations. More complexity = higher chance of misconfig, which can lead to exploitable vulnerability. Example — Company integrates multiple services (auth provider, payment processor) into web app, overlooks a misconfig that exposes admin APIs. Due to complexity of interaction between components, attacker gets access to critical admin APIs never meant to be exposed.
Over Customisation - Heavy customisation of software/workflow can introduce inconsistency and unintended security gaps. Custom features may not follow standard security practice, and heavily modified systems are hard to maintain/update/patch. Example — Org builds custom auth feature instead of using standard login framework, implements own password storage/session handling/account recovery logic to meet internal needs. Hard to maintain over time, customisation becomes outdated leads to weak hashing algo or inconsistent session timeout.
Technical and Design Flaws - Occurs when security isn't built into design from the start. Source may not be intentional but can pose huge risk. Example — Implementing MFA into existing web app. Dev implements feature but overlooks existing design where fully authenticated session cookie is issued before MFA process completes. This lets attacker navigate to authenticated pages without completing MFA.

Common Cause -> Resulting Vulnerability Table -

Human Assumptions -> Dev assumes users only upload images, no validation -> Unrestricted File Upload (attacker uploads web shell, executes OS commands).
Software Bugs -> Form data concatenated into DB query instead of parameterised input -> SQL Injection (attacker extracts/modifies sensitive records).
System Complexity -> Multiple integrated services, easy to miss a misconfigured API endpoint -> Exposed Admin API (attacker reaches admin functions never meant to be public).
Over-Customisation -> Custom auth replaces standard framework, logic hard to maintain -> Weak Authentication (outdated hashing, broken session logic exposes accounts to takeover).
Technical and Design Flaws -> Authenticated session issued before MFA step completes -> MFA Bypass (attacker navigates authenticated pages without completing MFA).
Pentesters Mindset :-

Technical skill alone doesn't define a good pentester. Knowing how to effectively execute the test matters equally. This covers behaviour/habits that help tester produce meaningful results.

Good Mindset (qualities) -

Understanding the system — Systems behave differently from each other, strong understanding of target helps plan ahead and gives context to explore exploitation opportunities.
Attention to detail — Observing app behaviour and noticing small differences often leads to impactful findings.
Constant curiosity — Constantly asking "what if" helps uncover ideas and opens up further opportunities.
Prioritising critical areas — Focus on high impact functions before low risk features, so effort goes where security issue causes bigger business impact.
Thinking in context — Understanding how a feature is used and what data it handles helps assess risk accurately, evaluates findings based on real world consequence not just technical severity.
Creative thinking — Hardened systems create assumption that no weakness exists. Creativity helps find weakness that could be overlooked otherwise, sometimes involves chaining two vulnerabilities together for bigger impact.

Poor Mindset (bad habits) -

Rushing to exploitation — Attacking without understanding how system works, leads to overlooked weakness, and risk of disrupting system which limits testing.
Ignoring context — Focusing only on technical success without business impact, results in findings lacking real world relevance.
Over-reliance on tools — Depending too much on automated tools without proper analysis, can produce false positives or miss logic based issues needing manual testing.
Making assumptions — Assuming how system works without verification, causes tester to miss important behaviour.
Tunnel vision — Getting fixated on one functionality thinking it'll lead to critical finding, wastes time, reduces coverage, prevents exploring other areas with possibly bigger weakness.
Blindly following checklist — Checklist is useful for full coverage, but over depending on it reduces creative thinking and can miss bigger findings. Also creates false assumption that testing is done once checklist is completed.

Best Practices During a Pentest -

Maintaining Good Notes - Keeping detailed notes throughout helps track activity, findings and observation as assessment progresses. Makes it easy to reproduce issue later if needed, ensures nothing important gets forgotten. Example — If vulnerability found early in assessment, good notes let tester revisit later without repeating whole process.
Collecting Evidence - Like notes, collecting screenshot/tool output/logs supports validity of findings and gives clear proof of impact. Saves time later by avoiding unnecessary reproduction of issue during reporting.
Managing Time - Pentest is done within fixed timeline. Managing time well lets tester balance effort across areas and make sure enough time spent on critical functions and reporting. Better to prioritise auth/access control functionality over spending hours on low impact feature. Also, working on report as you go is a good habit, helps manage time, prevents burnout, ensures deliverables submitted on time. Example — If a critical finding shows up near end of engagement, documenting new findings alongside existing ones and collecting evidence takes time, this creates unnecessary pressure near conclusion if not done along the way.
Proactive Communication - Maintaining proactive communication keeps engagement on track by giving regular progress updates and highlighting blockers early. Communicating roadblocks lets issue get addressed asap. No engagement is perfect, but proactive communication lets effort redirect when needed, support get provided, and reduces impact on coverage.
Staying Professional - Professional behaviour throughout builds trust between tester and org being assessed. Respecting scope boundaries, handling sensitive data responsibly, and conducting testing in controlled manner are essential habits. Also applies to communicating finding to stakeholder — explaining business impact rather than just technical detail helps stakeholder understand significance, and reinforces tester's credibility/reliability.
Ethics, Trust and Permission :-

These 3 principles must be followed to ensure assessment is done professionally. Since pentesting needs access to sensitive systems/data, enforcing these principles is essential to protect org assets and minimise risk throughout assessment. Following them ensures activities align with org's goals.

Ethics - Shown by responsibly assessing systems that may hold sensitive data/critical functionality. Ethical behaviour helps tester make responsible decisions throughout, ensures actions are intentional and justified.

How enforced in practice -

Respecting defined scope, avoiding activity outside authorised boundaries.
Avoiding actions that could disrupt systems/services.
Handling sensitive data responsibly, only accessing data required to demonstrate impact.
Stopping and reporting unexpected access to highly sensitive or out-of-scope systems.
Redacting sensitive data in reports to prevent unintended disclosure.
Permission - Established through formal authorisation and clearly defined scope before executing engagement. Proper authorisation ensures all activity is approved by org being assessed and aligns with their expectation/goal.

How respected in practice -

Obtaining written authorisation before initiating any testing activity.
Defining clear scope and adhering to it.
Confirming testing windows and approved methods before doing potentially disruptive actions.
Seeking clarification when uncertain whether a system/action is in scope.
Pausing and notifying org if activity may exceed authorised boundaries.
Trust - Orgs may be cautious initially allowing external tester to assess systems. But many orgs rely on independent assessment by external party to properly evaluate/improve security posture. So establishing trust from the beginning is valuable.

How trust is built/maintained -

Providing status updates periodically to reassure stakeholders testing is on track.
Being transparent about limitations, blockers, uncertainties during testing to get proper assistance.
Reporting findings accurately, clearly demonstrating business impact.
Providing actionable recommendations that help eliminate/mitigate risk.
Addressing organisational concerns promptly, adapting communication style for technical and non-technical stakeholders.

Ethics, permission and trust are principles that let pentesting exist as a professional security practice. They ensure testing is done professionally and thoroughly, while protecting both tester and system being assessed. Consistently applying these throughout an engagement helps preserve credibility of pentesting as a trusted, reliable and professional security practice.