Pentest and red team roles require both technical depth and professional judgment. These questions cover methodology, Windows attack techniques, web vulnerabilities, and the ethical decision-making that separates good consultants from reckless ones.
Reconnaissance: Passive information gathering with no direct contact with target systems — OSINT, DNS enumeration, LinkedIn, job postings (which reveal tech stack), WHOIS, certificate transparency logs.
Scanning and Enumeration: Active interaction with the target — port scans, service detection, web crawling, directory brute-forcing, identifying the attack surface.
Exploitation: Using identified vulnerabilities and misconfigurations to gain initial access.
Post-Exploitation: Privilege escalation, lateral movement, persistence, data access — demonstrating real business impact beyond the initial foothold.
Reporting: Documenting every finding with severity rating, evidence, business impact, and actionable remediation guidance. The report is the deliverable the client actually keeps and acts on.
Black box: No prior knowledge of the target. Simulates an external attacker with no insider information. Tests detection and response capability as well as vulnerabilities — if your SOC doesn't catch a black box tester, that's a finding. Most realistic but least efficient at finding all vulnerabilities.
Grey box: Partial knowledge — typically a standard user account, some network documentation, or application credentials. Simulates an insider threat, a phishing victim, or an attacker who has done some reconnaissance. Balances realism with coverage. Most common in practice.
White box: Full knowledge — source code, architecture diagrams, admin credentials. Maximizes vulnerability coverage because you're not spending time on discovery. Doesn't simulate a realistic attacker perspective but finds the most issues per hour of testing.
Privilege escalation is moving from lower-privileged access to higher-privileged access on the same system — for example, from a standard user to local administrator, or from local admin to SYSTEM.
Unquoted Service Paths (T1574.009): If a Windows service binary path contains spaces and isn't enclosed in quotes, Windows tries each space-delimited prefix as a potential executable. An attacker who can write to an earlier path component can place a malicious binary that runs as SYSTEM when the service starts.
AlwaysInstallElevated (T1548.002): If both the HKLM and HKCU registry keys for AlwaysInstallElevated are set to 1, Windows MSI installer packages run with SYSTEM privileges regardless of who executes them. An attacker with a low-privileged shell can drop a malicious MSI and run it as SYSTEM.
Kerberoasting is an Active Directory attack that exploits the Kerberos ticket-granting mechanism. Any domain-authenticated user can request service tickets (TGS tickets) for service principal names (SPNs) — this is normal Kerberos behavior by design.
These service tickets are encrypted with the NTLM hash of the service account's password. An attacker requests tickets for all SPNs, extracts them, and takes them offline to crack the password with tools like Hashcat or John the Ripper.
It's effective because: (1) it requires only a standard domain user account to perform, (2) the ticket requests look like normal Kerberos traffic, and (3) service accounts often have weak passwords because they've never been audited.
Mitigation: Use long random passwords (25+ characters) for service accounts, or better yet, Group Managed Service Accounts (gMSA) which rotate automatically and have 120-character random passwords.
BloodHound is a tool for mapping Active Directory relationships and finding attack paths from any compromised account to high-value targets like Domain Admin.
It works by ingesting AD data collected by SharpHound (a C# collector that runs on a domain-joined host) and building a graph database of all AD objects and their relationships — who has local admin where, what groups have what permissions, delegation chains, trust relationships, and shortest paths to Domain Admin.
Offensively: it instantly shows attack paths that might take days to find manually, especially through multi-hop chains (e.g., User A has local admin on Server B, Server B has a session from User C, User C is a Domain Admin).
Defensively: BloodHound is equally valuable for identifying unnecessary privilege relationships, over-permissioned accounts, and dangerous delegation settings — and then removing them before an attacker finds them.
SQL injection occurs when user-supplied input is incorporated into a database query without proper sanitization or parameterization, allowing the input to be interpreted as SQL commands rather than data.
Classic example: a login form that constructs SELECT * FROM users WHERE username='[input]'. Entering ' OR '1'='1 closes the string and appends always-true logic, potentially bypassing authentication entirely.
To test: Manually inject single quotes (') and common SQL syntax into every user-controlled input — form fields, URL parameters, cookie values, JSON fields. Observe whether the application returns a database error (confirming injection is possible). Try time-based payloads ('; WAITFOR DELAY '0:0:5' -- in MSSQL) to detect blind injection where no error is displayed. Use sqlmap for automated, comprehensive coverage after initial manual confirmation.
Test every input that reaches the database — not just obvious search boxes. Headers, cookies, and API parameters are frequently overlooked.
The OWASP Top 10 is the Open Web Application Security Project's list of the most critical web application security risks. It's updated periodically and widely used as a baseline for web application security testing and secure development training.
Current key entries: Broken Access Control (most common — users accessing resources they shouldn't), Cryptographic Failures (weak encryption, exposed keys), Injection (SQLi, command injection, XSS), Insecure Design (security not considered in architecture), Security Misconfiguration (default credentials, unnecessary features enabled), Vulnerable and Outdated Components (libraries with known CVEs), Identification and Authentication Failures, Software and Data Integrity Failures (CI/CD tampering, insecure deserialization), Security Logging and Monitoring Failures, Server-Side Request Forgery (SSRF).
A vulnerability assessment scans for known vulnerabilities using automated tools (Nessus, Qualys, Tenable) and produces a report of what's present — no exploitation, no proof of impact, no attempt to chain vulnerabilities. It's broad, fast, and relatively cheap.
A penetration test actively exploits identified vulnerabilities to demonstrate real-world impact — can an attacker actually use this vulnerability to reach sensitive data, pivot to other systems, or compromise the environment? It validates whether vulnerabilities are actually exploitable in context, tests detection and response capabilities, and demonstrates business risk rather than just vulnerability presence.
Both have a place in a mature security program: vuln assessments for broad continuous coverage, pen tests for targeted risk validation and compliance demonstration. A vuln assessment might find 50 findings; a pen test determines which 3 of those lead to domain compromise.
A useful finding includes: a clear description of the vulnerability, evidence (screenshots, commands run, output), a severity rating with explicit justification (not just a CVSS score), concrete business impact (what could an attacker actually achieve with this — not "could lead to unauthorized access" but "could allow an attacker to extract all customer PCI data"), and remediation guidance specific enough to act on.
The worst reports say "patch your systems." The best say: "Update OpenSSL from 1.1.1k to 3.2.0 on servers listed in Appendix A. This vulnerability (CVE-XXXX-YYYY) is actively exploited in the wild and has a working public exploit."
Ask yourself for every finding: could a developer or sysadmin fix this without asking you a follow-up question? If the answer is no, the finding isn't done.
Unexpected findings have two types: out-of-scope systems (you've hit something not in the rules of engagement) and sensitive data discovery (you've accessed real customer data, credentials, financial records).
For out-of-scope systems: stop exploitation immediately and notify the client contact per your engagement rules. Document what you found, when, what access you gained (if any), and what you did when you realized it was out-of-scope. The client decides next steps.
For sensitive data: do not enumerate, exfiltrate, or explore further. Take the minimum evidence needed to document the finding (a single screenshot showing the access, not the data itself). Escalate immediately to the client engagement manager. Real customer data has legal and regulatory implications regardless of your engagement scope.
In both cases: integrity is non-negotiable. Your professional reputation and your client's security depend on it.
Document everything immediately: Commands run, access achieved, timestamps, hashes captured (without extracting them unnecessarily). This is the crown jewel finding of the engagement.
Notify the client promptly. You've demonstrated the core business risk — full domain compromise. Continuing to enumerate the environment beyond what's needed to document the finding isn't justified and increases the risk of accidental impact. Per most rules of engagement, domain compromise is a "stop and call" event.
Clean up any artifacts: If you created persistence (as part of demonstrating the capability), remove it completely and document what you placed and where.
The full attack path — how you got from initial access to domain admin — is the most valuable part of the report. Document every hop in detail so the client can remediate each step.
This question tests whether you'd use domain admin access to keep exploring for maximum impact, or demonstrate the risk and stop. The right answer is stop.
Stop immediately. Do not enumerate, paginate through records, download, or explore further. Even within a scoped pentest, accessing more real customer data than necessary to document the finding creates liability for you, your firm, and the client.
Document with minimum evidence: A single screenshot showing the exposed endpoint and an example record (ideally redacted or of a test record if visible) is enough to document the severity. The finding is the access, not the contents.
Escalate immediately to your engagement manager and the client's security contact. This may be a breach or compliance event depending on jurisdiction and data type — the client's legal team needs to be aware as soon as possible. Notification timelines under GDPR, CCPA, and other regulations may be running from the moment you discovered this.
The severity rating on this finding should be Critical regardless of how it was accessed.