Penetration Testing and Red Team, Interview Questions.

A scan finds and lists potential weaknesses automatically. A penetration test is a goal-oriented, authorised assessment where a person validates weaknesses, chains them and shows real impact, then reports remediation. Scans give breadth, pentests give depth and proof.

Black box: no prior knowledge, simulates an outsider. Grey box: partial knowledge such as a low-privilege account. White box: full access to design and code, giving the deepest coverage in the least time.

Planning and scoping, reconnaissance, scanning and enumeration, exploitation and validation, post-exploitation (assessing impact within scope), and reporting with retest. Frameworks include PTES, OWASP testing guide and NIST SP 800-115.

They are the legal and safety boundary. They define targets, allowed techniques, times, contacts, data handling and stop conditions. Testing outside written authorisation can be illegal, and mistakes can cause outages.

Red simulates adversaries, blue defends and detects, purple coordinates both so findings immediately improve detection. Red team engagements test detection and response, not just find vulnerabilities.

Open-source intelligence: information from public sources such as domain records, code repositories, job posts and social media. Defenders use it to see what an attacker can learn and reduce that exposure.

An executive summary in business terms, scope and method, findings with severity, evidence, clear impact, reproduction steps appropriate for engineers, and prioritised remediation. Include positive observations and a retest plan. A report is judged by whether it gets things fixed.

Combine technical severity (CVSS), exploitability, business impact, exposure and chaining potential. Two medium issues that combine into account takeover may be critical overall.

• Broken access control: server-side authorisation checks.
• Injection: parameterised queries and encoding.
• Weak authentication: MFA, rate limits, secure session handling.
• Misconfiguration: hardening baselines and headers.
• Vulnerable components: dependency management.

Weak service account passwords, excessive privileges, unconstrained delegation, legacy protocols (NTLM, SMBv1), unpatched domain controllers, flat admin practices, and exposed credentials in shares and scripts. Fixes: tiering, strong random service account passwords or gMSA, LAPS, protocol hardening and monitoring.

Minimise access, do not copy more than needed as proof, store evidence encrypted, report it promptly, and delete per the agreement. Some findings (such as personal data exposure) are reported immediately, not at the end.

Stop, notify the agreed contact at once, document actions and times, help restore service, and review the testing approach with the client. Having safe testing windows and emergency contacts agreed in advance is part of good scoping.

Port and service scans in firewall and flow logs, many failed logons, unusual enumeration against directory services, new admin sessions from odd hosts, tool signatures in EDR, and odd outbound connections. Detecting test activity is a good measure of monitoring maturity.

Set objectives tied to business risk (for example, reach a specific crown-jewel dataset without being detected), agree rules of engagement, deconfliction, and a white cell of a few informed staff. Measure time to detect and respond, not just whether the goal was achieved, and run a purple debrief.

A pentest is a time-boxed engagement with a known team and defined scope. A bounty is continuous, crowd-sourced and pays for valid findings, giving broad perspective but less control and predictable coverage. They complement each other.

Review identity and permissions for privilege escalation paths, public exposure, secrets in repositories and metadata, network controls and logging, and check that detections catch simulated misuse. Provider rules for testing must be followed, and findings should include IaC-level fixes.

An information leak plus a weak reset flow plus missing rate limiting can add up to account takeover even if each is rated low. Triage should consider chains, which is why root-cause fixes beat patching symptoms.

Written authorisation, third-party systems in scope (cloud, SaaS), privacy and data protection law, responsible disclosure, avoiding collateral damage and honest reporting. When unsure, stop and ask.

Track remediation rate and time, recurring finding classes, improvement between tests, detection performance in red team exercises and whether lessons changed engineering practice. A test that produces a report no one acts on has little value.

Insist on scoping: targets, dates, permissions, contacts, restrictions, and written authorisation. Without them the work is unsafe and possibly illegal. Offer a short call to settle it quickly.

Notify the client contact immediately as a critical issue, supply minimal evidence without further misuse, and recommend removing exposure, changing credentials, enforcing MFA and checking logs for earlier abuse.

Environments, code and attackers change. A pass is a snapshot. Retest after major changes and on a regular cadence, and use results to track improvement and validate that old fixes held.