Ethical Hacking Interview Questions 2026

Passive recon — gathering info without sending packets to target (Google dorking, Shodan/Censys queries, GitHub source code search, social media OSINT). Stealthy, can't be blocked. Active recon — direct interaction (port scans, banner grabbing, web crawling). Faster but detectable. Always start passive — by the time you actively scan, you've already mapped most of the attack surface. Tools: passive — recon-ng, Maltego, theHarvester, Wayback Machine. Active — nmap, masscan, gobuster, ffuf.

Multi-source approach: (1) Passive sources — amass enum -passive, subfinder, assetfinder. Pull from CT logs, DNS aggregators, search engines. (2) Active resolution — massdns to verify which subdomains have live IPs. (3) Permutation/wordlist — gobuster vhost mode + custom wordlists for missed subdomains. (4) JS file analysis — extract subdomain references from target's JavaScript with subjs + mantra. (5) Combine + dedupe → final subdomain list. Critical: assets like staging/dev/admin subdomains often have weaker security than primary domain.

Beyond basic ' or 1=1 -- testing: (1) Test in HTTP headers (User-Agent, Referer, X-Forwarded-For); (2) Test cookies — many apps blindly trust cookies; (3) Test JSON parameters in API endpoints (sqlmap supports JSON body via -r); (4) Test boolean-based — change parameter value, observe page diff (true vs false response patterns); (5) Time-based — IF(condition, SLEEP(5), 0) and observe response time; (6) Out-of-band — DNSlog.cn callbacks for blind SQLi where no direct response exists. Tool: sqlmap with --level=5 --risk=3 --tamper for advanced detection.

SSRF (Server-Side Request Forgery) — server-side code fetches a URL the attacker controls. Detection: parameter accepts URL (e.g., 'image_url=', 'callback='), modify to internal IP (127.0.0.1, 169.254.169.254 cloud metadata), observe response. Escalation paths: (1) AWS — http://169.254.169.254/latest/meta-data/iam/security-credentials/ → leak IAM credentials → AWS CLI access; (2) GCP — metadata.google.internal headers; (3) Azure — 169.254.169.254 with Metadata header; (4) Internal services — Redis (gopher://), Memcached, internal Jenkins → RCE; (5) PHP wrappers — file://, php:// for local file read; expect:// for command exec. SSRF → cloud creds → RCE chain is the most common high-bounty pattern in 2026.

Prototype pollution — attacker modifies Object.prototype in JavaScript, affecting all subsequent object creations. JS-specific. Detection: parameters like __proto__, constructor.prototype in request body. Real chain: (1) Find merge function (lodash.merge < 4.17.20 or similar) accepting user input. (2) Pollute prototype: {'__proto__': {'isAdmin': true}}. (3) Subsequent code checks user.isAdmin → returns true even for non-admin user → privilege escalation. (4) Some chains lead to RCE in Node.js when polluted properties are used in template engines (Pug, Handlebars). 2024 GitHub disclosure: prototype pollution → RCE in Express middleware was a $50K bounty.

Kerberoasting — extract service account password hashes from AD. Chain: (1) As any AD user, query domain for SPNs (Service Principal Names) — every service-using account has SPN. (2) Request Kerberos service ticket (TGS) for each SPN — TGS is encrypted with service account's NTLM hash. (3) Extract TGS using Rubeus or impacket-GetUserSPNs. (4) Crack offline with hashcat (-m 13100) using rockyou.txt or custom wordlists. (5) Service accounts often have weak/stale passwords + are admins → recover password → privilege escalation. Defence: long random service account passwords (24+ chars), Group Managed Service Accounts (gMSA), AES-only Kerberos.

BloodHound (Specter Ops) — Active Directory attack path visualisation tool. Workflow: (1) SharpHound (data collector) — gather AD info: users, groups, sessions, ACLs, GPOs. (2) Upload data to Neo4j-backed BloodHound GUI. (3) Query attack paths — built-in queries like 'shortest path from any user to Domain Admin'. (4) Identify chained vulnerabilities: GenericWrite → ForceChangePassword → AdminTo → DA. (5) Plan exploit — execute attack chain using PowerSploit, Mimikatz, ImpacketIn. BloodHound mastery is non-negotiable for senior AD pen-test interviews. CE version free; Enterprise version (paid) has more features.

All authentication abuse techniques in Windows AD. PtH — use NTLM hash directly (without knowing password) to authenticate to remote service. Tools: Mimikatz sekurlsa::pth, Impacket secretsdump → wmiexec. PtT — use Kerberos ticket (TGT or TGS) without knowing password. Common: dump tickets from compromised host with Mimikatz, replay on attacker box. PtK — use Kerberos AES key (256/128) without password — works because AES keys derive from password and timestamp. Newer than PtH, harder to detect. Defence: Credential Guard, restricted-mode RDP, LSA Protection, Protected Users group, regular Kerberos ticket lifetime reduction.

(1) Identify vulnerable function (strcpy, gets, sprintf without bounds checking). (2) Send oversized input to crash binary (segfault). (3) Find offset — pattern_create.rb + pattern_offset.rb (Metasploit utilities) to find exact offset where RIP is overwritten. (4) Identify register state — RAX/RDI/RSI controlled, look for jump targets. (5) Find ROP gadgets with ROPgadget or Ropper — chain to call mprotect (make stack executable) or system('/bin/sh') directly. (6) Bypass ASLR via info leak (printf format string, libc address leak). (7) Bypass stack canaries via brute-force or info leak. Modern exploitation requires bypassing DEP, ASLR, canaries, CFI — pure stack overflow into shellcode is rarely viable on hardened targets.

Stack overflow — overwrite return address on stack, redirect execution. Mitigations: stack canaries, ASLR, DEP/NX. Heap overflow — corrupt heap metadata or in-place objects to gain primitives (arbitrary read, arbitrary write, type confusion). Modern heap exploitation focuses on tcache poisoning (glibc), unsorted bin attack, House of Force. Mitigations: ASLR (heap randomised), tcache safelinking (glibc 2.32+), heap layout randomisation. Stack overflow exploitation is rarer in modern apps; heap and use-after-free are more common in browsers, kernels. CTF preparation differs significantly between the two.

(1) Static analysis — APKTool to decompile, jadx-gui to read decompiled Java/Kotlin. Search for hardcoded secrets, API endpoints, weak crypto. (2) Dynamic analysis with Frida — hook root detection, certificate pinning, encryption functions to bypass and observe. (3) MITM proxy — Burp Suite + bypass cert pinning (Frida hooks for SSLPinningChecker). (4) API security testing — once MITM established, fuzz APIs for OWASP API Top 10 (broken auth, BOLA/IDOR, mass assignment). (5) Local data — extract /data/data/com.bank.app/, look for unencrypted SharedPreferences, SQLite databases, cached files. (6) Insecure IPC — exposed Activities, Services, Content Providers. Banking apps have high bounty payouts ($10K-25K) — invest in mastering this niche.

(1) IAM enumeration — list users/roles, identify over-privileged service accounts. Tools: ScoutSuite, Prowler, pacu. (2) S3 bucket enumeration — public buckets, leaked AWS credentials in CI/CD logs. (3) EC2 metadata access — SSRF in deployed app → http://169.254.169.254/latest/meta-data/iam/security-credentials/ → temporary creds. (4) Lambda function review — environment variable secrets, IAM role misuse. (5) Cross-account assume-role abuse — chain accounts together. (6) GuardDuty / CloudTrail evasion — operate during quiet windows, use diverse user agents. Required cert: AWS Cloud Practitioner minimum, Solutions Architect Associate strongly recommended for context. Tools: pacu, ScoutSuite, Prowler, CloudGoat (vulnerable lab).

OWASP Testing Guide / PTES + custom adaptation: (1) Pre-engagement — scope, rules of engagement, emergency contacts, written authorisation. (2) Reconnaissance — passive then active. (3) Threat modelling — identify high-value assets, likely attack paths. (4) Vulnerability identification — automated (nmap NSE, nuclei) + manual (Burp Suite, custom testing). (5) Exploitation — controlled exploitation, evidence collection. (6) Post-exploitation — privilege escalation, lateral movement (where in scope). (7) Reporting — executive summary + technical findings + business impact + reproduction steps + recommendations. (8) Re-test after fixes. Time allocation: 30% recon, 40% exploitation, 30% reporting (reporting is the deliverable, don't shortcut it).

Audience-tailored sections: (1) Executive summary — 1 page, business risk + key findings + recommendations. CXOs read only this. (2) Methodology — scope, tools used, time spent. (3) Findings list — sorted by severity (Critical → High → Med → Low → Info). (4) Per-finding sections — title, CVSS score, business impact, technical detail, screenshots/HTTP evidence, full reproduction steps, remediation guidance. (5) Appendices — full raw scan output, supporting evidence. Tone: factual, never accusatory. Always provide remediation alongside finding. Bug bounty reports often rejected for: insufficient impact explanation, missing repro steps, hostile tone toward vendor.

(1) Burp Suite Pro — web app testing standard. (2) Nmap — port scanning + NSE scripts. (3) Metasploit Framework — exploit chains. (4) sqlmap — SQL injection automation. (5) Nuclei — template-based vulnerability scanning. (6) Wireshark — packet analysis. (7) Hashcat / John — password cracking. (8) BloodHound + SharpHound — AD attack mapping. (9) Frida — mobile/desktop runtime instrumentation. (10) Bonus: Garak / PyRIT for LLM red teaming (emerging in 2026). Honourable mentions: Mimikatz (Windows post-exploitation), Volatility (memory forensics), Ghidra (reverse engineering), Cobalt Strike (commercial — red team).

CEH — multiple-choice, 4-hour exam, theoretical knowledge of tools/concepts. ₹100K. Pass rate ~60%. OSCP — 24-hour practical exam in custom lab environment, requires actually compromising machines + writing professional report within 24 hours. ₹135K+. Pass rate ~30%. Skills tested: Linux + Windows enumeration, web exploitation, AD attacks, privilege escalation, post-exploitation. CEH proves you know the tools; OSCP proves you can use them under pressure. Both are valuable — most senior pen-testers have both. CEH for HR filter, OSCP for technical credibility.

Time blocks: 0-12 hours: target machines worth most points first (typically 25-pt and 20-pt machines). Take screenshots of every successful exploitation step in real-time. 12-18 hours: complete remaining machines as time/skill allows. 18-22 hours: take a 4-hour break (sleep is critical, not optional — fatigue compounds errors). 22-24 hours: write the report draft. Total report budget: 24 hours after exam ends. Report-writing is where many candidates fail — practice writing a complete report in under 8 hours during prep. Don't claim full pwn without screenshot evidence; partial credit available for partial proof.

Use STAR format. Best examples: (1) Bug bounty find with documented payout — credibility unmatched; (2) CTF challenge solved creatively (not just following walkthroughs); (3) Internal pen-test with unique attack chain — even from coursework. Avoid hypotheticals ('I would do X') and overly generic answers ('found XSS once'). Specific + technical + outcome-driven wins. Bonus: tie back to lessons learned — interviewers want to see how you process and grow from each engagement.

Sources weekly: (1) Twitter/X — @SwiftOnSecurity, @bugbountywriteup, @PortSwigger researchers; (2) HackerOne disclosed reports + Bugcrowd disclosed reports; (3) PortSwigger Web Security Academy free training; (4) DEFCON / Black Hat talk recordings on YouTube (don't pay to attend); (5) Personal lab — replicate every interesting CVE within a week of publication. Quality > quantity: 3-4 hours/week of disciplined reading + practice keeps you current. Avoid: vendor blog whitepapers (low signal), generic 'cybersec news' aggregators, certifications-as-marketing.

Required research: visit company's tech blog, read their open-source repos, find their disclosed CVE history (if any). Your answer should reference concrete things ('I read your team's blog post on X technique', 'noticed your CVE-XXXX-YYYY in product Z'). Avoid generic answers ('I want a challenging environment'). Tie your specific skills to their visible needs. Also acceptable: 'I noticed your team works on cloud security exclusively, which is where I want to specialise.' Specific > generic always.