50 Cybersecurity Interview Questions 2026 — Real Questions + Model Answers

Confidentiality, Integrity, and Availability — the three core properties that all information security controls aim to protect.

Confidentiality: Only authorised parties can access information. Enforced through access controls, encryption, and least-privilege policies. A data breach violates confidentiality.

Integrity: Information is accurate and has not been tampered with. Enforced through hashing, digital signatures, and audit logs. A database manipulation attack violates integrity.

Availability: Systems and data are accessible when authorised users need them. Enforced through redundancy, DDoS mitigation, and disaster recovery. A ransomware attack primarily violates availability.

Strong answer addition: “Most security incidents violate multiple properties simultaneously — ransomware violates availability and often confidentiality through data exfiltration before encryption.”

TCP establishes a reliable connection before data transfer using a three-step process:

SYN: Client sends a SYN (synchronise) packet to the server with its initial sequence number (ISN).

SYN-ACK: Server responds with SYN-ACK, acknowledging the client’s ISN and sending its own ISN.

ACK: Client sends ACK acknowledging the server’s ISN. Connection is established.

Why it matters for security: SYN flood attacks exploit this — sending SYN packets but never completing the handshake, consuming server resources by maintaining half-open connections. Nmap’s SYN scan uses this by sending SYN, receiving SYN-ACK (confirming port open), then sending RST instead of ACK to avoid completing the connection.

Authentication: Verifying who you are — proving identity. Username/password, MFA, biometrics, certificates. “You are who you claim to be.”

Authorisation: Determining what you’re allowed to do after identity is established — access control. RBAC, ACLs, permissions. “You are allowed to access this resource.”

Authentication always precedes authorisation. A privilege escalation attack typically bypasses authorisation (an authenticated low-privilege user gains high-privilege access). A broken authentication attack (credential stuffing, session hijacking) bypasses authentication entirely.

Common follow-up: “What’s the difference between authorisation and access control?” — Access control is the mechanism that enforces authorisation policy.

Symmetric encryption: Same key encrypts and decrypts. Fast, suitable for large data. Key distribution is the problem — how do you share the key securely? Examples: AES-256, ChaCha20.

Asymmetric encryption: Public/private key pair. Public key encrypts, private key decrypts (or private signs, public verifies). Solves key distribution but is computationally expensive. Examples: RSA-2048, ECC.

How TLS combines both: Asymmetric encryption is used to establish the session and exchange a symmetric key. All subsequent data transfer uses the faster symmetric cipher. This is called a hybrid approach.

Common follow-up: “What key length is considered secure for RSA in 2026?” — 2048-bit minimum, 4096-bit for long-term sensitive data. RSA-1024 is deprecated.

IDS (Intrusion Detection System): Monitors and alerts — passive. Detects suspicious traffic patterns and logs/alerts on them. Does not block traffic. Out-of-band deployment — receives a copy of traffic. Lower latency impact, false positives are annoying but not disruptive.

IPS (Intrusion Prevention System): Monitors and blocks — active. Sits inline in the network path. Can drop packets, terminate connections, block IPs. False positives become outages. Requires careful tuning before deployment.

Common follow-up: “What are the two detection methods?” Signature-based (matches known attack patterns — fast, misses zero-days) and anomaly-based (establishes baseline, flags deviations — catches novel attacks, higher false positive rate).

A zero-day is a vulnerability that is being exploited in the wild before the software vendor has released a patch — the vendor has had “zero days” to fix it. The exploit is known to attackers but not to defenders.

Zero-day exploit lifecycle: Discovery (researcher or attacker finds the flaw) → Silent exploitation (used privately or sold) → Disclosure (vendor notified or public discovery) → Patch release → CVE assignment → End of zero-day window.

The term is sometimes misused to mean any unpatched vulnerability. Technically, a vulnerability is only zero-day while no patch exists.

Defence question follow-up: “How do you defend against zero-days?” — Defence in depth, behavioural detection (anomaly-based IDS), network segmentation, least-privilege to limit blast radius, threat intelligence feeds for emerging IOCs.

The OSI model has 7 layers. From bottom to top: Physical (1), Data Link (2), Network (3), Transport (4), Session (5), Presentation (6), Application (7).

Attack mapping by layer: DDoS volumetric attacks → Layer 3/4. ARP spoofing / MAC flooding → Layer 2. SSL stripping → Layer 6. SQL injection, XSS, HTTP floods → Layer 7. Man-in-the-middle → Layers 2-4. DNS poisoning → Layer 7 (DNS runs over Layer 3/4 but the attack targets application-layer name resolution).

Interviewer shortcut tip: “Can you explain where DDoS attacks occur?” Walk from L3 volumetric (ICMP flood, UDP amplification) to L7 application attacks (HTTP GET flood, Slowloris) — this shows you understand the distinction between bandwidth exhaustion and connection/resource exhaustion.

A MITM attack intercepts communication between two parties who believe they’re communicating directly. The attacker can read, modify, or inject data. Techniques: ARP poisoning (intercepts LAN traffic), SSL stripping (downgrades HTTPS to HTTP), evil twin Wi-Fi (rogue access point), DNS spoofing (redirects to attacker-controlled server).

Prevention: TLS/HTTPS with certificate pinning (prevents SSL stripping), HSTS headers (enforces HTTPS), DNSSEC (authenticates DNS responses), mutual TLS (both parties authenticate), static ARP entries or dynamic ARP inspection for LAN, VPN for untrusted networks.

CVSS (Common Vulnerability Scoring System) provides a standardised numerical score (0.0–10.0) for vulnerability severity. Version 3.1 is current standard; v4.0 is adopted by some frameworks.

Base score components: Attack Vector (Network/Adjacent/Local/Physical), Attack Complexity (Low/High), Privileges Required (None/Low/High), User Interaction (None/Required), Scope (Changed/Unchanged), Confidentiality/Integrity/Availability impact (None/Low/High).

Score ranges: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9.

Important caveat: CVSS measures technical severity in isolation — it doesn’t account for exploitability in your specific environment, asset criticality, or compensating controls. A CVSS 9.8 on a system not exposed to the internet may be lower priority than a CVSS 7.0 on an internet-facing authentication endpoint.

Vulnerability: A weakness in a system that could be exploited. SQL injection in a web application, unpatched CVE in a server, misconfigured S3 bucket.

Threat: A potential danger that could exploit a vulnerability. A threat actor (ransomware group, nation-state, insider), a natural disaster, a hardware failure.

Risk: The likelihood that a threat will exploit a vulnerability combined with the potential impact. Risk = Threat × Vulnerability × Impact.

A vulnerability with no plausible threat carries low risk. A critical threat with no applicable vulnerability also carries low risk. Risk is what drives remediation prioritisation — not raw CVSS scores.

SQL injection occurs when user input is incorporated into a SQL query without proper sanitisation, allowing an attacker to modify the query logic. Injecting ' OR '1'='1 into a login field may bypass authentication. Injecting '; DROP TABLE users; -- can delete data.

Prevention: Parameterised queries / prepared statements (the primary fix — user input is treated as data, never as SQL code). Input validation as defence-in-depth. Stored procedures with proper parameterisation. Least-privilege database accounts (the web app user shouldn’t have DROP privilege). WAF as a compensating control (not a primary fix).

Follow-up: “What’s the difference between in-band, blind, and out-of-band SQLi?” In-band: result returned directly in the response. Blind boolean: no result returned but behaviour changes based on true/false conditions. Blind time-based: no visible change but response time varies (SLEEP()). Out-of-band: data exfiltrated via DNS or HTTP callback.

XSS allows attackers to inject client-side scripts into web pages viewed by other users. The injected script executes in the victim’s browser with the victim’s session context — enabling cookie theft, session hijacking, keylogging, and phishing.

Reflected XSS: Payload is in the request (URL parameter, form input) and reflected immediately in the response. Not stored. Victim must click a crafted link. Medium severity.

Stored XSS: Payload is stored in the application (database, comments section) and executed for every user who views the content. No crafted link needed. High severity.

DOM-based XSS: Vulnerability is in client-side JavaScript that reads from a DOM source (location.hash, document.referrer) and writes to a DOM sink (innerHTML, eval). The payload may never reach the server. Requires JavaScript analysis to find.

Prevention: Output encoding (HTML entity encoding at point of rendering), Content Security Policy (blocks inline scripts), HttpOnly cookie flags (prevents cookie theft via XSS), input validation as defence-in-depth.

Cross-Site Request Forgery tricks an authenticated user’s browser into making unintended requests to a web application where they’re logged in. The attacker’s page contains a hidden form or image tag that sends a state-changing request (fund transfer, password change, account deletion) to the target site. The browser automatically includes the victim’s session cookies.

Prevention: CSRF tokens (unique, unpredictable value per session/request that the attacker can’t guess). SameSite cookie attribute (Strict or Lax) prevents cookies from being sent on cross-site requests. Checking the Origin/Referer header. Requiring re-authentication for sensitive actions.

Key distinction: CSRF exploits the trust a site has in a user’s browser. XSS exploits the trust a user has in a site’s content. These are often confused in interviews.

Insecure Direct Object Reference (IDOR) occurs when an application uses user-supplied input to access objects directly without authorisation validation. An attacker changes a predictable identifier to access another user’s data.

Example: A banking application uses GET /account?id=12345 to show your account. Changing the ID to 12346 returns another user’s account details with no authorisation check. The application authenticates you but doesn’t verify you own ID 12346.

Prevention: Server-side authorisation check on every object access — verify the authenticated user owns or has permission to access the requested object. Use indirect references (map sequential internal IDs to user-specific tokens). Never expose database primary keys directly.

IDOR is the single highest-paying vulnerability class in bug bounty programs. Any parameter containing a user, account, order, or document identifier is a candidate.

The OWASP Top 10 is a regularly updated list of the most critical web application security risks, maintained by the Open Web Application Security Project. The 2021 edition (current as of 2026) lists: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery (SSRF).

It matters for interviews because it provides the shared vocabulary that security practitioners, developers, and executives use. Most web application security assessments use the OWASP Top 10 as the minimum coverage checklist. Many compliance frameworks (PCI DSS, SOC 2) reference it explicitly.

Server-Side Request Forgery (SSRF) tricks a server into making HTTP requests to locations specified by the attacker. The server becomes a proxy for the attacker’s requests — with the server’s network access and identity.

What attackers can do: Reach internal services not exposed to the internet (internal APIs, admin panels, databases). Access cloud metadata endpoints (http://169.254.169.254/ on AWS returns IAM credentials). Port scan internal networks. Bypass IP allowlists (request comes from an authorised internal IP). Read internal files via file:// scheme if supported.

The 2019 Capital One breach exploited an SSRF vulnerability to access the AWS metadata endpoint and retrieve IAM credentials, leading to data exfiltration of 100 million customer records.

JSON Web Token — a stateless authentication mechanism. Three base64url-encoded parts separated by dots: Header (algorithm, token type), Payload (claims — user ID, roles, expiry), Signature (cryptographic signature using the server’s secret key).

Common JWT vulnerabilities:

None algorithm attack: If the server accepts "alg":"none" in the header, the signature is not verified. Attacker modifies the payload, sets algorithm to none, removes the signature. Classic critical vulnerability.

Algorithm confusion (RS256→HS256): Server uses RS256 (asymmetric). Attacker changes header to HS256 (symmetric) and signs the token with the server’s public key (which is publicly available). If the server’s library uses the public key as the HS256 secret, the forged token passes verification.

Weak secret: If the HS256 secret is short or predictable, it can be brute-forced offline. Tool: hashcat -m 16500.

TLS (Transport Layer Security) provides encryption, authentication, and integrity for network communication. The TLS handshake negotiates a secure session before data transfer.

TLS 1.3 handshake (simplified): Client sends ClientHello (supported cipher suites, TLS version, random value). Server responds with ServerHello (chosen cipher suite, its certificate, key share). Client verifies the certificate against trusted CAs. Both sides derive session keys from the key exchange (ECDHE in TLS 1.3). Encrypted application data begins.

Key improvements in TLS 1.3: Removed weak cipher suites (RC4, MD5, SHA-1). Mandatory forward secrecy (ECDHE). Faster handshake (1-RTT instead of 2-RTT). 0-RTT resumption for returning connections (with replay attack trade-off).

Clickjacking embeds a target website in a transparent iframe overlaid on a decoy page. The victim believes they’re clicking on the visible decoy content but actually interact with the invisible target site, triggering actions on their behalf (like button clicks, form submissions).

Prevention: X-Frame-Options header (DENY or SAMEORIGIN — prevents the page from being embedded in iframes). Content-Security-Policy frame-ancestors directive (more flexible modern replacement). Frame-busting JavaScript (deprecated approach, bypassable).

A web application penetration test systematically evaluates the application against known vulnerability classes. Coverage typically follows OWASP Testing Guide or OWASP Top 10 as the minimum standard:

Authentication and session management (weak passwords, session fixation, token predictability). Access control (IDOR, privilege escalation, horizontal/vertical privilege separation). Injection flaws (SQLi, XSSi, CMDi, XXE, SSTI). Business logic vulnerabilities (price manipulation, workflow bypasses, race conditions). Sensitive data exposure (insecure transmission, credential disclosure in errors, PII in logs). Security configuration (HTTP security headers, TLS configuration, information disclosure, default credentials). Third-party component analysis (CVE scanning of dependencies).

Deliverable: a written report with severity ratings, reproduction steps, evidence screenshots, and remediation guidance. CVSS scoring or internal severity framework.

My response follows the PICERL framework:

Identify: Confirm ransomware (ransom note, encrypted files, unusual process activity). Identify patient zero — which system first showed symptoms? Timeline reconstruction via logs, EDR, SIEM.

Contain: Immediately isolate affected systems from the network (unplug network cables, disable NIC, or use EDR’s network isolation feature — NOT shutting down, which may trigger additional payload execution). Disable affected accounts. Identify the blast radius — which systems are affected or at risk.

Eradicate: Identify the ransomware variant (VirusTotal hash match, ransom note fingerprinting, ID Ransomware tool). Determine the initial access vector (phishing email, RDP, vulnerability exploitation). Remove the malware from affected systems. Patch the vulnerability that was exploited.

Recover: Restore from clean backups (confirm backup integrity first). If no backups: assess decryption feasibility (known decryptors, negotiation decision). Staged return to production with monitoring.

Lessons Learned: Post-incident review within 2 weeks. Document timeline, attack chain, detection gaps, and control failures. Update playbooks.

Account compromise investigation starts with timeline and context before any remediation actions that could disrupt ongoing collection.

Initial triage: Review login history — unusual geolocations, impossible travel (logins from different countries within minutes), abnormal hours, new devices. Check failed login attempts before the suspicious login. Review what the account accessed after the suspicious login — lateral movement indicators.

Containment decision: Disable the account or force password reset + MFA reset. Alert the account owner through an out-of-band channel (not the potentially compromised email).

Investigation: Identify the initial access method — credential stuffing (check HaveIBeenPwned for the email), phishing (check email logs), session token theft (check for impossible travel without repeated auth). Review all actions taken by the account: data access, email sent, password changes, API calls.

Scope assessment: Was the account used to create persistence (new accounts, OAuth authorisations, API keys)? Was sensitive data accessed or exfiltrated? Are other accounts at risk (password reuse, shared credentials)?

Security Information and Event Management — a platform that aggregates, correlates, and analyses log data from across the environment to detect threats and support investigations. Examples: Splunk, Microsoft Sentinel, IBM QRadar, Elastic SIEM.

Core functions: Log aggregation from endpoints, servers, firewalls, applications. Correlation rules that trigger alerts when event patterns match known attack signatures. Normalisation of diverse log formats into a common schema. Threat intelligence integration (known malicious IPs, domains, hashes). Investigation and timeline reconstruction. Compliance reporting.

Common Splunk query pattern: index=main sourcetype=windows_security EventCode=4625 | stats count by src_ip | where count > 50 — finds brute force attempts (>50 failed logins) by source IP.

Interview tip: If you’ve used any SIEM in a lab (Splunk free trial, Elastic in home lab, Microsoft Sentinel free tier), be specific. “I built a Splunk home lab and wrote detection rules for…” demonstrates hands-on experience.

Alert triage is the core SOC skill. The process for every alert:

1. Understand the alert rule: What specific condition triggered it? What’s the expected false positive rate for this rule type?

2. Gather context: What is the affected asset? Is it an important system (production server, privileged workstation) or low-value (test machine, isolated lab)? What was the asset doing before and after the alert?

3. Corroborate: Does any other data source confirm suspicious activity? (If a malware alert fires, is there also unusual outbound network traffic? Unusual process creation? A related authentication event?) A true positive typically has multiple corroborating signals.

4. Apply knowledge: Is this a known false positive pattern? (Security scanners, patch management tools, and backup agents are common benign causes of “suspicious” alerts). Is there a known campaign using this technique right now?

5. Document and escalate: If confirmed true positive or uncertain — escalate. If confirmed false positive — document for rule tuning. If you suppress alerts without documentation, you create detection blind spots.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base of real-world threat actor behaviours, organised by tactic (what the attacker is trying to achieve) and technique (how they achieve it).

Enterprise tactics (in kill-chain order): Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact.

Use in IR: Map observed TTPs to ATT&CK to understand where in the attack chain the adversary is, identify what they likely did before and after observed activity, and structure the detection gap analysis. “They’re at T1003 (OS Credential Dumping) — we should check for T1550 (Pass the Hash) next.”

Use in detection engineering: Prioritise detection coverage against techniques most used by threat actors targeting your industry (ATT&CK Navigator visualises this).

Digital forensics is the collection, preservation, analysis, and presentation of digital evidence for legal or investigative purposes.

Key principles: Chain of custody (document every person who handles evidence and when). Integrity preservation (evidence must not be modified — use write blockers for disk imaging, hash verification). Order of volatility (collect most volatile data first: RAM/running processes → network connections → disk image). Forensic copy (work on copies, never originals). Repeatability (another examiner following the same process should reach the same conclusions).

Evidence priority (volatile to persistent): Running processes and memory → Network connections and open sockets → Login sessions → Running services → File system (modification, access, creation times — MAC times) → Registry → Event logs → Disk image.

Lateral movement detection requires looking for anomalous authentication and access patterns rather than just known attack tool signatures.

Key indicators: Administrative tool use from unexpected sources — PowerShell, PsExec, WMI executing remotely from non-admin workstations. Pass-the-hash (Event ID 4624 Logon Type 3 with NTLM authentication where Kerberos is expected). Unusual service account logins — service accounts authenticating interactively or to systems they don’t normally access. Abnormal RDP connections — workstation-to-workstation RDP (should be rare). New local admin accounts or privilege grants. Kerberoasting (Service Principal Name requests en masse — look for many TGS requests from a single account).

Detection in practice: Baseline normal — what is typical authentication volume and destination for each account type? Alert on deviations. Privileged accounts connecting to assets they’ve never connected to before is a high-fidelity signal.

Alert-based detection: Reactive — wait for a rule or signature to trigger, then investigate. Assumes known threat patterns. Misses novel techniques and living-off-the-land attacks that don’t trigger signatures.

Threat hunting: Proactive — analysts generate hypotheses about how an attacker might operate in the environment and search for evidence of that activity before an alert fires. “I hypothesise that an attacker with initial access via phishing would use PowerShell for discovery. Let me query all PowerShell execution events in the past 30 days for unusual patterns.”

Hunting methodology: Hypothesis → Data collection (logs, EDR data) → Analysis → Discovery (finding or absence of finding) → Feedback (new detection rule if something found, or increased confidence in current coverage if not). The outcome of a successful hunt is either a real finding or an improved detection rule — both are valuable.

Prioritised by investigative value:

Windows Security Event Logs: 4624/4625 (logon success/failure), 4648 (explicit credential use), 4688 (process creation — needs audit policy enabled), 4697 (service installed), 7045 (new service), 4720/4732 (account created/added to group), 4771 (Kerberos pre-authentication failure — Kerberoasting indicator), 4769 (Kerberos service ticket request).

Network logs: Firewall logs (allow/deny by IP/port), DNS query logs (C2 domain lookups, unusual volume, DGA domains), proxy logs (HTTP/S requests including user-agent and URL), NetFlow (IP conversation summaries — useful for finding C2 beacon patterns).

Endpoint/EDR: Process creation with parent-child relationship, network connections by process, file creation/modification, registry changes.

Application logs: Web server access logs (authentication attempts, unusual paths, error codes), authentication logs (SSO, LDAP/AD authentication events), database audit logs (unusual queries, schema changes).

A tabletop exercise is a discussion-based simulation where key stakeholders walk through their response to a hypothetical security incident without taking any real actions. Typically facilitated by a security leader or external consultant.

Format: Facilitator presents a scenario (ransomware outbreak, data breach, insider threat, DDoS). Participants discuss what they would do at each stage — who is notified, what decisions are made, how containment is executed, when legal/comms/executive teams are engaged. The facilitator injects complications as the scenario progresses (“now assume the attacker has also compromised the backup server”).

Value: Exposes gaps in IR plans, communication breakdowns, unclear decision ownership, missing escalation paths, and untested runbooks — without the pressure of a real incident. Required by many compliance frameworks (SOC 2, ISO 27001) as evidence of incident response programme maturity.

Vulnerability scan: Automated tool (Nessus, Qualys, OpenVAS) runs against targets, identifies known CVEs by matching service banners and version numbers against a vulnerability database. Produces a list of potential vulnerabilities. Typically runs in hours. Low cost, high coverage of known issues. Produces false positives and cannot verify exploitability.

Penetration test: Human-led assessment that attempts to exploit vulnerabilities to determine real-world impact. Verifies exploitability, chains vulnerabilities, identifies business logic flaws that scanners can’t detect, and simulates what a real attacker could achieve. Takes days to weeks. Produces a verified findings report with exploitation evidence.

Analogy: A vulnerability scan is a security camera checking for unlocked doors. A penetration test is a red team member trying to break in.

My recon methodology moves from passive to active, building the attack surface map before touching any target systems.

Passive (no contact with target): WHOIS, DNS enumeration (subdomains via Amass, subfinder, dnsx), certificate transparency (crt.sh for subdomain discovery), Google dorking (site:target.com filetype:pdf, inurl:admin), Shodan (open ports, service banners, exposed assets), LinkedIn (employee names and roles for social engineering and spear phishing), GitHub (leaked credentials, internal infrastructure details in repos), Wayback Machine (historical content, old endpoints).

Active (direct contact with target): Port scanning (Nmap SYN scan, service version detection), web crawling (Burp Spider, ffuf directory bruteforce), technology fingerprinting (Wappalyzer, whatweb), authentication testing (login page enumeration, default credentials).

Passive recon builds the target list. Active recon confirms what’s live and identifies initial attack vectors.

Linux privilege escalation follows a systematic enumeration-first approach before attempting any exploit.

Automated enumeration first: Run LinPEAS or LinEnum to get a comprehensive overview quickly. Review the output before manual checks.

Manual checklist: sudo -l (what can current user sudo?). SUID/SGID binaries (find / -perm -4000 -type f 2>/dev/null) — check GTFOBins for any that allow shell escape. Writable cron jobs (ls -la /etc/cron*) — if writable by current user, inject a reverse shell. Writable service files. PATH hijacking (writable directory in PATH + a script that calls a binary by relative path). Kernel exploit (last resort — uname -r, check exploitdb).

Most common in CTF/exam: Sudo misconfiguration (sudo vim → :!/bin/bash), SUID binary (use GTFOBins), cron job running a writable script as root.

Windows privilege escalation also starts with automated enumeration.

Automated tools: WinPEAS, PowerUp.ps1 (PowerSploit), Seatbelt, PrivescCheck.

Key checks: Unquoted service paths (a service running C:\Program Files\My Service\service.exe without quotes — if any parent directory is writable, plant a binary at C:\Program Files\My.exe). Weak service permissions (sc.exe sdshow ServiceName). AlwaysInstallElevated registry key (set → any .MSI runs with SYSTEM). Stored credentials (cmdkey /list, Credential Manager, password in registry/files). SeImpersonatePrivilege (potato attacks — PrintSpoofer, GodPotato). Scheduled tasks running as SYSTEM with writable scripts.

Token impersonation (SeImpersonatePrivilege) via printspoofer/godpotato is the most reliable route in modern CTFs and exams.

The order matters — situational awareness before any noisy actions.

1. Situational awareness (quiet): Who am I (whoami /all, id)? What system am I on (hostname, systeminfo, uname -a)? What network am I on (ipconfig /all, ifconfig)? Are there other systems on this network (arp -a)?

2. Check for monitoring: What security tools are running (ps aux | grep -i security, netstat -an)? Am I in a sandboxed environment (low process count, VM indicators, unusual timing)?

3. Establish persistence (if authorised/required by scope): Before continuing, ensure you won’t lose access if the exploit crashes or the system reboots.

4. Document: Screenshot every step. Note timestamps, commands run, and systems accessed. Pentest documentation is the difference between a professional deliverable and an unusable mess.

SQL injection testing follows a systematic input-then-verify approach across every user-controlled input.

Identify inputs: Map all parameters using Burp Suite Spider — GET/POST parameters, cookie values, HTTP headers (User-Agent, X-Forwarded-For, Referer — often passed to queries for logging).

Manual error probing: Inject a single quote (') — does the response change? Return a SQL error? Behave differently? Inject 1 AND 1=1 vs 1 AND 1=2 — different results confirm boolean-based SQLi.

Time-based blind: If no visible response change: inject ' AND SLEEP(5)-- (MySQL) or '; WAITFOR DELAY '0:0:5'-- (MSSQL) — a 5-second delay confirms injection even without visible output.

Automated confirmation: After manual confirmation, use SQLMap for thorough exploitation: sqlmap -u "URL" --dbs. Never run SQLMap blindly on production — always manual confirmation first.

My standard web application pentesting toolkit:

Proxy/Intercept: Burp Suite (core tool — repeater, intruder, scanner). OWASP ZAP (free alternative, strong AJAX spider).

Reconnaissance: ffuf (directory/parameter fuzzing), Amass/subfinder (subdomain enumeration), Nikto (web server misconfiguration scanning).

Exploitation: SQLMap (SQL injection automation), commix (command injection), XSStrike (XSS detection and exploitation).

Authentication: Hydra (brute force HTTP forms), Hashcat (offline hash cracking).

Wordlists: SecLists (Danielmiessler/seclists) — the definitive wordlist collection for directory bruteforce, usernames, passwords, payload fuzzing.

The tool matters less than the methodology. I use Burp Suite for everything and supplement with specialised tools for specific techniques. An interviewer asking “what tools do you use?” is really asking “do you understand the methodology behind the tools?”

Pivoting uses a compromised system as a relay to reach network segments otherwise inaccessible from the attacker’s machine. The compromised host bridges two network segments.

When it’s used: A web server in the DMZ is compromised. The web server has network access to an internal database server that the attacker cannot reach directly. The web server becomes the pivot point — traffic from the attacker routes through it to the database server.

Techniques: SSH tunnelling (ssh -L local_port:target_ip:target_port user@pivot). SOCKS proxy via Metasploit (route add + auxiliary/server/socks_proxy). Chisel (fast TCP/SOCKS tunnel, useful when SSH isn’t available). ProxyChains (routes tool traffic through the proxy). SSHuttle (VPN-like tunnel over SSH).

Context in engagement: Pivoting is usually restricted in scope and requires explicit client authorisation for each network segment. Always confirm scope boundaries before pivoting.

A professional pentest finding has a consistent structure that works for both technical and non-technical audiences:

Title: Clear, specific. “SQL Injection in /api/user endpoint” not “Injection Issue”.

Severity: Critical/High/Medium/Low with CVSS score.

Description: What is the vulnerability? One paragraph — technical but accessible.

Impact: What can an attacker do if they exploit this? Concrete business terms — “an attacker could access all 50,000 customer records” not “data exposure is possible”.

Steps to Reproduce: Exact reproduction steps, including request/response screenshots. Another tester should be able to reproduce the finding from this section alone.

Evidence: Screenshots, request/response captures, proof-of-concept output.

Remediation: Specific, actionable fix — not “sanitise user input” but “use parameterised queries for all database interactions, specifically in the getUserById() function at /api/user.js line 47″.

References: CWE, CVE, OWASP reference, or relevant documentation.

Penetration test: Point-in-time, scope-defined assessment of specific systems or applications. Goal: find as many vulnerabilities as possible in the defined scope. Typically 1-4 weeks. Full disclosure of findings. Collaborative — client knows it’s happening and usually provides credentials/access.

Red team engagement: Adversary simulation — mimics how a specific threat actor would attack the organisation. Narrow goal (exfiltrate specific data, reach a target system). Extended timeline (weeks to months). The blue team doesn’t know it’s happening. Tests detection and response capability, not just vulnerability existence. Success is not finding vulnerabilities — it’s achieving the objective without detection.

Analogy: A penetration test checks whether all the locks on your building work. A red team engagement tests whether your security guards notice when someone breaks in.

This is an invitation to frame your narrative, not a request for your life story. Structure: present role/background (1 sentence) → relevant experience progression (2-3 sentences) → why this role/company specifically (1-2 sentences).

Example structure: “I’m a [current role] at [current employer] where I [key responsibility]. Before that, I [previous relevant experience]. I specialise in [your strongest area] — specifically [specific achievement or project]. I’m interested in this role because [specific reason that connects your background to the role].”

Keep it under 90 seconds. Practice it. The opening of an interview sets tone — a rambling, unstructured intro signals poor communication skills.

Use STAR. The interviewer is testing: do you have real hands-on experience? Did you handle disclosure responsibly? Can you communicate technical findings clearly?

Structure: Situation (what were you testing, what was the context). Task (what was your objective). Action (what specifically did you find, what was the technical detail, what steps did you take). Result (how was it remediated, what was the impact, what did you learn).

If you don’t have professional experience: A CTF finding, HackTheBox machine, or bug bounty submission counts. “I found an SQL injection vulnerability on HackTheBox’s [machine name] that led to full database access and then privilege escalation to root via…” demonstrates methodology regardless of whether it was a paid engagement.

Never make up findings. Interviewers ask follow-up questions — fabricated stories collapse immediately under pressure.

Be specific. “I follow cybersecurity news” is vague. Name your actual sources.

Strong answer: “I read Krebs on Security and Bleeping Computer for threat intelligence. I follow the National Vulnerability Database for CVE releases and triage them against my environment. I monitor specific threat actor feeds through [specific OSINT source]. I do CTFs on HackTheBox or TryHackMe monthly to keep technical skills sharp. I also attend [specific conference or local BSides event] when I can.”

Be ready for the follow-up: “Tell me about a recent vulnerability or threat you read about this week.” If you’re not actually following security news regularly, start now — this question appears in nearly every interview and a blank answer is a significant negative signal.

This tests communication skills — critical in any security role that interfaces with business stakeholders. The interviewer is checking: can you translate technical findings into business risk?

Key elements of a good answer: You identified the audience’s knowledge level and adapted accordingly. You used analogies or business impact framing rather than technical jargon. The stakeholder understood the risk and took appropriate action.

Example frame: “I found a critical SQL injection vulnerability in our customer portal. Instead of presenting the technical details to the CTO, I explained it as: ‘An attacker could access every customer account without a password — essentially our entire customer database could be exported in minutes.’ I showed a brief demo of the impact. We got emergency patching approved within the hour.”

The story should demonstrate that you translated technical severity into business impact, not just simplified the technical explanation.

The interviewer is testing: can you advocate for your technical position without being difficult? Can you accept decisions you disagree with professionally?

Strong answer structure: Present a real disagreement (not a trivial one). Explain how you raised your concern (with data and reasoning, not emotion). Describe how the disagreement was resolved. Reflect on the outcome — even if you were overruled, did you handle it professionally?

Avoid: stories where you were clearly right and the other person clearly wrong (paints you as self-righteous). Avoid: stories with no disagreement (signals you don’t advocate for your positions). Avoid: stories where you capitulated immediately without voicing your concern.

The formula: genuine gap + what you’ve done to address it + current status.

Example: “My weakest area has been Active Directory attacks — I’ve spent most of my career on web application security and hadn’t built AD lab experience. Over the last three months I’ve built a small AD lab with a domain controller and two workstations, worked through BloodHound enumeration and Kerberoasting techniques, and completed the TryHackMe AD path. My AD enumeration is now solid and I’m comfortable with the core attack paths.”

Never say: “I work too hard” or “I’m a perfectionist.” Interviewers have heard it ten thousand times and it signals you’re either not self-aware or not being honest.

The genuine answer demonstrates self-awareness, learning orientation, and the discipline to actually close the gap — all qualities you want in a security practitioner.

The interviewer wants to know: will this person grow in the role, or will they leave in 6 months? Is their trajectory aligned with what we can offer?

Strong answer: Shows growth ambition that’s achievable within the company’s structure. Connects your target to the role’s realistic progression path. Demonstrates you’ve thought about your career, not just the immediate job.

Examples by role: Analyst: “I want to develop deeper expertise in [specific area — threat intel, DFIR, cloud security] and move toward a senior analyst role. Long-term I’m interested in threat hunting.” Pentester: “I want to deepen expertise in [web app/network/cloud pentesting] and ideally progress to leading engagements independently. I’m working toward [OSCP/BSCP/GPEN].” SOC: “I want to develop detection engineering skills and move from alert triage toward building detection rules and tuning SIEM coverage.”

This tests initiative and ability to own something end-to-end without constant direction. Choose a project with a tangible outcome — a detection rule you built, a lab you set up, a process you documented and implemented, a tool you automated.

If you’re entry-level with no professional project: your home lab, a CTF challenge you built, a bug bounty finding, or a security automation script you wrote independently all qualify. The key is that you identified a need, defined an approach, executed it, and produced a result.

Avoid “I participated in a team project” answers for this question — the word “independently” is deliberate. The interviewer specifically wants to understand how you work without close supervision.

The interviewer wants evidence that you stay structured and effective when stressed. This is especially important for SOC and IR roles.

Strong answer: “I focus on the process — having a clear playbook or framework means I don’t have to make structural decisions under pressure. During an active incident, my first step is always documenting what I know and what I don’t know before taking any containment action. That prevents ‘thrash’ — taking actions in the wrong order and making the situation worse. I’ve also learned that clear, frequent communication with stakeholders matters as much as the technical response — people escalate anxiety when they have no information.”

If you have a real incident story, use it. If not, describe a simulated incident (tabletop exercise, CTF, Hack The Box scenario under time pressure) and what you learned about your own response patterns.

Always have questions. Saying “no, I think you’ve covered everything” signals low interest or poor preparation. The questions you ask reveal as much about your professional maturity as your answers.

High-quality questions by category:

Team/culture: “What does the on-call rotation look like and how does the team handle alert fatigue?” “How does the security team collaborate with engineering on vulnerability remediation?”

Technical environment: “What’s your current SIEM setup and are there plans to evolve it?” “What’s the maturity level of the detection engineering function — mostly commercial rules or significant custom rule development?”

Growth: “What does success look like in the first 90 days for this role?” “What are the most common growth paths for people in this role at this company?”

Avoid: “What’s the salary?” (ask HR, not the hiring manager). “How many days off do I get?” (Google the benefits package). “Can I work remotely?” (clarify before the interview through the recruiter).