In short
Ethical hacking is the authorised, documented act of attacking an organisation's own systems the way a real attacker would, so that weaknesses are found and fixed before a criminal finds them. A penetration test is the structured engagement that does this — scoped, time-boxed, contracted, and ending in a report with risk ratings and remediation advice. In India it is mandatory practice in banking (RBI cyber-security framework), insurance, telecom, UIDAI/Aadhaar ecosystems and any CERT-In-regulated body, and it is routinely assessed in university Information Security papers, in GATE CS/IT security questions, and in interviews at TCS, Infosys, Wipro, HCLTech, Accenture, Deloitte, KPMG, EY, Paladion/Atos, Lucideus/SAFE Security, CloudSEK and the big product companies. The one thing that separates ethical hacking from a cybercrime is written authorisation — the techniques are identical.
Explained
Definitions, intent and legal basis
- Ethical hacker (white hat): a tester with written permission from the system owner to find and report vulnerabilities, without damaging, stealing or disclosing data. Black hat: unauthorised and malicious. Grey hat: unauthorised but non-malicious — still an offence in India.
- Vulnerability: a weakness (unpatched service, weak password policy, missing input validation). Threat: an actor or event that could exploit it. Exploit: code or technique that uses the weakness. Risk = likelihood × impact. Payload: what the exploit delivers (shell, beacon). Zero-day: a vulnerability with no vendor patch yet.
- Vulnerability assessment (VA): broad, mostly automated, finds and lists weaknesses. Penetration test (PT): narrower, manual, proves exploitability and impact by chaining weaknesses. VAPT is the Indian industry term for the two sold together.
- Red team: goal-driven, stealthy, adversary-emulation over weeks, tests detection as much as prevention. Blue team: defenders. Purple team: the two working together to tune detection.
- Indian legal frame (the examinable part):
- Information Technology Act, 2000 (as amended 2008) — Section 43 (civil liability for unauthorised access, damage, denial of access), Section 66 (computer-related offences, up to 3 years and/or fine), Section 66C (identity theft), Section 66D (cheating by personation using a computer), Section 65 (tampering with source code), Section 72 (breach of confidentiality by a person acting under the Act), Section 43A (compensation for failure to protect sensitive personal data), Section 70B (CERT-In as the national incident-response agency).
- CERT-In Directions of 28 April 2022: reportable cyber incidents must be reported within 6 hours of noticing; logs to be kept for 180 days within India; data-centre/VPN/cloud providers to keep subscriber records (5 years after de-registration). Applies to the client, and shapes what a tester must flag.
- Digital Personal Data Protection Act, 2023 — penalties for failure to take reasonable security safeguards; the safeguard duty and penalties apply from 13 May 2027 under the DPDP Rules 2025 (until then IT Act s.43A governs).
- RBI: cyber-security framework for banks and the master directions for NBFCs/UCBs require periodic VAPT and application security testing; SEBI CSCRF and IRDAI guidelines impose similar periodic testing. Sector practice is annual plus after every major change — exact frequency differs by circular, so state it that way.
- ISO/IEC 27001:2022 control on technical vulnerability management, IS/ISO/IEC 27001 adopted by BIS; PCI DSS v4.x requires internal and external penetration testing at least annually and after significant change.
- Authorisation documents: signed scope/authorisation letter ("get-out-of-jail letter"), NDA, rules of engagement (ROE), emergency contacts, test window, explicit out-of-scope list. Testing anything outside scope — a shared host, a third-party API, a cloud provider's own infrastructure — is an offence even mid-engagement.
Types of testing and engagement models
- By knowledge given: black box (no information — closest to a real outsider, but slower and may miss depth), white box / crystal box (full source, configs, credentials — deepest coverage per rupee), grey box (partial, e.g. one low-privilege login — the commonest commercial choice).
- By position: external (from the internet), internal (assumes a foothold or insider), wireless, physical (tailgating, lock bypass, rogue device), social engineering (phishing, vishing, pretexting).
- By target: network infrastructure, web application, API, mobile (Android/iOS), thick client, cloud configuration, Active Directory, SCADA/OT, IoT/embedded, source-code review.
- By awareness: announced (IT team knows) vs unannounced; double-blind (neither side's defenders know) tests the SOC too.
- Testing types: SAST (static, on code), DAST (dynamic, on running app), IAST, SCA (dependency/library scanning), fuzzing.
- Bug bounty / responsible disclosure: continuous, crowd-sourced, pay-per-valid-bug (HackerOne, Bugcrowd; Indian programs run by Zomato, Paytm, Flipkart, NPCI partners, RBI-regulated fintechs). Complements, does not replace, a scoped test — no coverage guarantee.
The five-phase methodology (standard exam answer)
- Reconnaissance / footprinting — collect information. Passive: WHOIS, DNS records, certificate transparency logs, Google dorks (
site:,filetype:,inurl:), Shodan/Censys, LinkedIn and job ads for the tech stack, leaked-credential dumps, archived pages. Active: ping sweeps, banner grabbing, DNS zone transfer attempts. Tools:whois,dig,nslookup, theHarvester, Maltego, Amass, Recon-ng, OSINT framework. Output: domains, subdomains, IP ranges, employee names, email format, technologies. - Scanning — find live hosts, open ports, services, versions and known vulnerabilities. Nmap for host discovery and port/service/OS detection; Nessus / OpenVAS / Qualys / Nexpose for vulnerability scanning; Nikto, WhatWeb for web servers. Distinguish port states: open, closed, filtered.
- Enumeration and vulnerability analysis — extract usernames, shares, SNMP data, SMB/NetBIOS info, LDAP entries, directory structures; map findings to CVE identifiers and verify they are real, not scanner noise (false positives). Tools: enum4linux, smbclient, ldapsearch, snmpwalk, dirsearch/gobuster, Burp Suite, SQLMap.
- Exploitation / gaining access — prove impact. Metasploit Framework, custom exploits, Hydra/Medusa for credential attacks, Responder for LLMNR/NBT-NS poisoning and NTLM hash capture (Impacket's ntlmrelayx for relaying), BeEF for browser attacks, SQL injection and command injection by hand. Keep within ROE: no destructive payloads, no ransomware simulation unless explicitly contracted.
- Post-exploitation, privilege escalation and persistence — local privilege escalation (kernel exploits, SUID binaries, misconfigured sudo, unquoted service paths, token impersonation, Mimikatz credential dumping, Kerberoasting in AD), lateral movement (pass-the-hash, RDP, WMI, SSH key reuse), pivoting through a compromised host, data-access proof. Covering tracks is a real attacker phase that an ethical hacker does NOT perform — logs are left intact; instead the tester records timestamps so the blue team can correlate.
- Reporting and retest — the deliverable. Executive summary, scope and dates, methodology, each finding with description, affected asset, evidence (screenshot, request/response), severity and CVSS vector, business impact, reproducible steps, remediation; then an appendix of out-of-scope observations. A retest/closure report after fixes is normally contracted.
- Clean-up is a formal step: remove uploaded shells, test accounts, cron jobs, added SSH keys; hand over a written list of every artefact created.
Frameworks, standards and tooling
- PTES (Penetration Testing Execution Standard) — pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, reporting.
- OSSTMM — measurement-oriented, defines the RAV (risk assessment value). NIST SP 800-115 — technical guide to information security testing. OWASP Web Security Testing Guide (WSTG) and MASVS/MASTG for mobile — the test-case checklists. MITRE ATT&CK — tactics/techniques matrix used to plan red-team scenarios and to map detection gaps.
- Cyber kill chain (Lockheed Martin): reconnaissance → weaponisation → delivery → exploitation → installation → command and control → actions on objectives.
- Platforms: Kali Linux, Parrot OS (attack distros); DVWA, OWASP Juice Shop, Metasploitable, bWAPP, TryHackMe, Hack The Box (legal practice labs — practise here, never on live sites).
- Certifications Indian employers ask for: CEH / CEH Practical (EC-Council) for entry roles and tender eligibility, OSCP (Offensive Security) — the hands-on benchmark, CRTP/CRTE (Indian-origin, Altered Security — Active Directory), eJPT/eWPTX, GPEN, OSWE, CISSP and CISA for management/audit tracks. CERT-In empanelment of an auditing organisation is what Indian government and PSU tenders actually require.
Scoring, prioritisation and reporting quality
- CVSS v3.1 / v4.0 gives a 0-10 Base score from exploitability metrics (Attack Vector, Attack Complexity, Privileges Required, User Interaction) and impact metrics (Confidentiality, Integrity, Availability) plus Scope in v3.1 (v4.0 removes Scope, adds Attack Requirements, and splits impact into vulnerable-system C/I/A and subsequent-system C/I/A); Temporal/Threat and Environmental metrics adjust it for the real environment.
- Severity bands (CVSS v3.1): 0.0 None; 0.1-3.9 Low; 4.0-6.9 Medium; 7.0-8.9 High; 9.0-10.0 Critical.
- CVE = unique identifier for a public vulnerability; CWE = the weakness class (e.g. CWE-89 SQL injection, CWE-79 XSS); NVD = the database carrying CVSS scores; EPSS = probability a CVE will be exploited in the next 30 days — increasingly used to rank patching ahead of raw CVSS; CISA KEV = known-exploited list.
- A finding must be reproducible: exact URL/parameter, payload, request and response, and the account used. Severity in the report should be the environmental severity, not the raw NVD number — an internal-only, firewalled service with a 9.8 CVE is not a critical business risk.
- Limitations of a penetration test: point-in-time (valid only for the test window), scope-bound, dependent on tester skill, cannot prove absence of vulnerabilities, risks service disruption, and cannot replace secure SDLC, patching and monitoring.
Key points
- Authorisation - the only legal difference between an ethical hacker and an offender under IT Act Sections 43 and 66; get it in writing before the first packet.
- VA vs PT - assessment lists weaknesses in breadth; penetration test proves exploitability in depth.
- Five phases - reconnaissance, scanning, enumeration/analysis, exploitation, post-exploitation; reporting is the deliverable.
- Passive vs active recon - passive never touches the target (WHOIS, dorks, Shodan); active does (ping sweep, banner grab) and is logged.
- Black/grey/white box - no information, partial information, full information; grey box is the common commercial model.
- Red vs blue vs purple - attack simulation, defence, and the joint detection-tuning exercise.
- Rules of engagement - scope, test window, out-of-scope assets, escalation contacts, no-go actions such as DoS and data exfiltration.
- Covering tracks - an attacker phase deliberately omitted by ethical hackers; logs stay intact for correlation.
- CVSS - 0-10 base score; 9.0+ Critical, 7.0-8.9 High, 4.0-6.9 Medium, 0.1-3.9 Low.
- CVE vs CWE - specific published vulnerability vs the generic weakness class.
- Privilege escalation - vertical (low user to root/admin) vs horizontal (one user's data to another's).
- Pivoting - using a compromised host as a route into networks not reachable from outside.
- False positive vs false negative - a reported non-issue vs a missed real issue; manual verification removes the first, skilled testing reduces the second.
- CERT-In - national agency under IT Act Section 70B; 6-hour incident reporting, 180-day Indian log retention, empanelled auditors for government work.
- RBI / SEBI CSCRF / IRDAI / PCI DSS - sectoral mandates for periodic VAPT and testing after significant change.
- Point-in-time - a clean report means nothing about tomorrow's patch level; continuous testing and monitoring are needed.
- Nmap, Burp Suite, Metasploit, Nessus, SQLMap, Mimikatz, Hydra - the tool set interviewers expect you to name and justify.
- Practice legally - DVWA, Juice Shop, Metasploitable, HTB, TryHackMe; never on a live site you do not own.
Formulas and examples
CVSS v3.1 Base (Scope unchanged) = Roundup( min[(Impact + Exploitability), 10] )
Impact (ISS) = 1 − [(1 − C)(1 − I)(1 − A)]; Impact = 6.42 × ISS
Exploitability = 8.22 × AV × AC × PR × UI
AV: Network 0.85, Adjacent 0.62, Local 0.55, Physical 0.20
AC: Low 0.77, High 0.44; PR (Scope unchanged): None 0.85, Low 0.62, High 0.27; UI: None 0.85, Required 0.62
Base = 0 if Impact ≤ 0
ALE = SLE × ARO (SLE = single loss expectancy in ₹, ARO = annual rate of occurrence per year, ALE in ₹/year)
ROSI = (ALE_before − ALE_after − Cost of control) / Cost of control
Testing effort (person-days) ≈ Σ (assets × days per asset type) + reporting days
Example 1 — CVSS base score for an unauthenticated remote SQL injection with full data access (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).
- C = 0.56, I = 0.56, A = 0 → ISS = 1 − (1−0.56)(1−0.56)(1−0) = 1 − (0.44 × 0.44) = 1 − 0.1936 = 0.8064
- Impact = 6.42 × 0.8064 = 5.177
- Exploitability = 8.22 × 0.85 × 0.77 × 0.85 × 0.85 = 8.22 × 0.85 = 6.987; × 0.77 = 5.380; × 0.85 = 4.573; × 0.85 = 3.887
- Sum = 5.177 + 3.887 = 9.064 → min(9.064, 10) = 9.064 → Base = 9.1 (Critical)
Example 2 — the same flaw, but only reachable after login with a low-privilege account (PR:L → 0.62).
- Exploitability = 8.22 × 0.85 × 0.77 × 0.62 × 0.85 = 5.380 × 0.62 = 3.336; × 0.85 = 2.835
- Sum = 5.177 + 2.835 = 8.012 → Base = 8.1 (High)
- Reading: requiring authentication drops the score by one band — useful when arguing remediation priority to a client.
Example 3 — annualised loss and whether the test pays for itself. An e-commerce firm estimates that a successful injection-led data breach costs ₹1.8 crore (regulatory, notification, forensics, churn) and judges it likely once in 4 years.
- ARO = 1/4 = 0.25 per year; SLE = ₹1,80,00,000 → ALE = 0.25 × 1,80,00,000 = ₹45,00,000 per year
- A ₹6,00,000/year VAPT + WAF programme is assessed to cut the frequency to once in 20 years: ARO = 0.05 → ALE_after = ₹9,00,000/year
- Benefit = 45,00,000 − 9,00,000 = ₹36,00,000; ROSI = (36,00,000 − 6,00,000)/6,00,000 = 5.0, i.e. 500%
Example 4 — risk matrix and ranking of four findings. Likelihood and impact on 1-5.
| Finding | Likelihood | Impact | Risk | Band |
|---|---|---|---|---|
| Unauthenticated SQLi on login page | 5 | 5 | 25 | Critical |
| Default SNMP community string (internal) | 4 | 3 | 12 | High |
| Missing HttpOnly flag on session cookie | 3 | 3 | 9 | Medium |
| Server version banner disclosure | 4 | 1 | 4 | Low |
- Fix order follows the risk score, but the SNMP issue is internal-only, so after environmental adjustment it may be scheduled after the cookie fix if the internal network is strongly segmented.
Example 5 — scan arithmetic and scope sizing. A /24 internal subnet is tested.
- Hosts scanned = 2⁸ − 2 = 254 usable addresses; 96 respond. Nmap full TCP scan = 65,535 ports × 96 hosts = 6,291,360 probes; at an effective 1,200 probes/second this is 6,291,360/1,200 ≈ 5,243 s ≈ 1 h 27 min, which is why testers start with the top 1,000 ports.
- The scanner reports 410 findings; manual verification confirms 262. False-positive rate = (410 − 262)/410 = 148/410 = 36.1% — the standard justification for manual penetration testing over a bare scan.
| Vulnerability assessment | Penetration test | Red team exercise | |
|---|---|---|---|
| Goal | List weaknesses | Prove exploitability and impact | Emulate a real adversary, test detection |
| Breadth vs depth | Wide, shallow | Narrow, deep | Objective-driven |
| Automation | Mostly automated | Tool-assisted, manual | Heavily manual, custom tooling |
| Duration | Hours to days | 1-3 weeks | 4-12 weeks |
| Defender awareness | Known | Usually known | Usually unknown |
| Output | Scan report with CVSS | Exploitation narrative + remediation | Attack path, detection gap, ATT&CK map |
Where it is used
- Banking and fintech: RBI-regulated banks, NBFCs and payment aggregators run periodic VAPT on net-banking, UPI apps and ATM switches; NPCI-linked integrations need application security sign-off before go-live.
- IT services and consulting: TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Accenture, Deloitte, KPMG, EY, PwC and specialist firms (SAFE Security, CloudSEK, Sequretek, Network Intelligence, Payatu) staff VAPT and red-team practices from campus.
- Government and PSU tenders: security audits must be done by CERT-In empanelled organisations; UIDAI, NIC, state e-governance portals and defence PSUs contract this work.
- Product security teams: Flipkart, Zomato, Swiggy, Paytm, PhonePe, Zoho, Freshworks run in-house AppSec teams plus public bug bounty programs; roles are Security Engineer, AppSec Engineer, Offensive Security Engineer.
- Job roles and typical entry package: Penetration Tester / VAPT Analyst, Security Analyst (SOC L1-L2), AppSec Engineer, Red Team Operator, Security Consultant — campus offers commonly ₹3.5-8 LPA, specialist offensive roles higher; figures move year to year.
- Regulated non-financial sectors: telecom (DoT security assurance for network equipment), healthcare and insurance (IRDAI), cloud providers' shared-responsibility testing of customer configurations.
Interview questions
- Q: What makes hacking "ethical"? A: Prior written authorisation from the asset owner, a defined scope, no damage or data theft, and full confidential disclosure of findings to the owner; without the authorisation the same act is an offence under Sections 43 and 66 of the IT Act, 2000.
- Q: Difference between a vulnerability assessment and a penetration test? A: A VA is broad and largely automated and lists possible weaknesses; a PT is manual and selective and proves which ones are actually exploitable and what the business impact is.
- Q: Name the phases of a penetration test. A: Reconnaissance, scanning, enumeration and vulnerability analysis, exploitation, post-exploitation and privilege escalation, then reporting, clean-up and retest.
- Q: Which phase do ethical hackers deliberately skip, and why? A: Covering tracks — logs and audit trails are left intact so the blue team can correlate the test with its own detections, and tampering would destroy evidence.
- Q: Passive versus active reconnaissance? A: Passive gathers information without sending traffic to the target (WHOIS, DNS, certificate logs, Shodan, Google dorks); active probes the target directly (ping sweeps, port scans, banner grabbing) and appears in the target's logs.
- Q: You get a critical finding mid-test that is being actively exploited by someone else. What do you do? A: Stop testing that asset, invoke the escalation contact in the rules of engagement immediately, preserve evidence, and advise the client of the CERT-In 6-hour incident-reporting obligation — it has become an incident response, not a test.
- Q: What is CVSS and what is its main limitation? A: A 0-10 scoring system from exploitability and impact metrics; the base score ignores the client's environment, so an internal, segmented, compensating-control-protected asset needs the environmental metrics (or an EPSS/KEV view) before you call it critical.
- Q: Vertical versus horizontal privilege escalation? A: Vertical raises your privilege level (user to administrator); horizontal keeps the level but reaches another user's data or account at the same level.
- Q: What is pivoting? A: Routing attack traffic through an already-compromised host to reach internal networks that are not directly reachable from the tester's position — the proof that flat networks are dangerous.
- Q: Black box, grey box or white box — which would you recommend to a client and why? A: Grey box for most engagements: full source and credentials (white box) give the best coverage per rupee but no realism check, black box is realistic but wastes paid days on discovery; grey box gives depth plus an authenticated-user attacker view.
- Q: How do you handle a suspected false positive from a scanner? A: Reproduce it manually against the target, capture the request and response as evidence, and if it cannot be reproduced record it as a false positive in an appendix rather than as a finding.
- Q: Is a clean penetration test report proof that the system is secure? A: No — it is point-in-time, scope-limited and tester-dependent; it proves nothing about assets outside scope, about new code, or about the environment after the next patch cycle.
- Q: What legal and compliance documents must exist before day one? A: Signed authorisation/scope letter, NDA, rules of engagement with test window and escalation contacts, out-of-scope list, and for third-party-hosted or cloud assets the hosting provider's permission or acceptable-testing policy.
Common mistakes
- Treating "no malicious intent" as a defence — grey-hat testing without permission is still unauthorised access under the IT Act; interviews test this deliberately.
- Writing the five phases but omitting reporting, clean-up and retest — in exams and in practice the report is the product.
- Listing "covering tracks" as an ethical-hacking phase because the textbook attack model includes it.
- Submitting raw scanner output as a penetration-test report: no manual verification, no environmental severity, no reproduction steps, false positives left in.
- Confusing CVE (a specific published vulnerability) with CWE (the weakness class) and CVSS (the score), or quoting NVD severity as the client's business risk.
- Scope creep — testing a subdomain, shared hosting neighbour, third-party API or cloud control plane that the authorisation letter does not name.
- Running DoS, brute-force lockouts or destructive payloads on production without explicit ROE permission, then reporting an outage as a "finding".
- Practising techniques on live public websites instead of DVWA, Juice Shop, Metasploitable or an HTB/TryHackMe lab.
Related topics
Web application security (OWASP Top 10) · Network security: firewalls, VPN and IDS · Security operations: SOC and SIEM · Digital forensics · IT governance, risk and compliance · Information security fundamentals