Entry-Level Penetration Tester Interview Preparation Guide for Spotify

Approach (role: Penetration Tester)

I’d design a layered compliance program combining continuous automated discovery, pipeline-enforced gates, and scheduled manual validation to meet PCI-DSS and ISO 27001 requirements (vulnerability management, secure SDLC, and testing controls).

Controls to implement

• Automated authenticated scanning (SAST/DAST/IAST) against dev, staging, prod-like environments; weekly for public-facing assets (PCI DSS Req.11.2, ISO A.12.6.1).
• CI/CD security gates: fail build for high/critical SAST findings, require MR approval + remediation plan for medium findings; container image scanning before deploy (SBOM).
• Periodic manual penetration tests: annual full-scope and quarterly focused tests on high-risk systems or after major releases (PCI DSS Req.11.3).
• Vulnerability triage workflow with risk scoring (CVSS + business context) and SLA remediation timelines (30/90/365 days mapped to severity).
• Change control and evidence of remediation validation (re-scan + exploit validation).
• Logging/monitoring controls to detect exploitation attempts (ISO A.12.4/A.16).

Evidence artifacts for auditors

• Scanner reports (raw + filtered), authenticated scan configs, scheduling logs
• CI/CD pipeline run logs and artifact SBOMs; fail/pass decisions and MR IDs
• Penetration test reports with test plan, scope, methodology, PoC, risk ratings, remediation verification
• Triage tickets (Jira) showing assignment, remediation, verification, and closure timestamps
• Patch/upgrade records, change approvals, and re-scan validation results
• SLA dashboards and monthly executive summary PDFs

Reporting cadence and false-positive management

• Daily digest for security team (new highs), weekly operational report (new/aging findings), monthly compliance report (trends + SLA status) for auditors, quarterly executive review with pen test summary.
• To limit false positives: authenticated scans, tuning scanner rules per-app, automated de-duplication, and mandatory manual verification for anything classified medium/above before gating production. Maintain a documented false-positive whitelist with justification and periodic revalidation (90 days).

This combines continuous detection with human validation to satisfy PCI-DSS/ISO audit expectations while keeping noise manageable and ensuring exploitability is proven.

Direct answer
Flow control protects the RECEIVER from being overwhelmed by data it can't process fast enough; congestion control protects the NETWORK from being overwhelmed by more traffic than the path between sender and receiver can actually carry. They use different signals and different windows, and confusing them leads to fixing the wrong end of the problem.

Structured elaboration
Flow control is implemented via the receive window (often written rwnd): the receiver advertises, in every ACK, how many more bytes of buffer space it currently has available. If the receiver's application is slow to read data out of its socket buffer, the advertised window shrinks, telling the sender to slow down regardless of how healthy the network path is. This is purely an endpoint-to-endpoint negotiation; the network in between plays no role.

Congestion control is implemented via the congestion window (cwnd), a value the SENDER maintains based on inferred network conditions, growing during slow start and congestion avoidance, and shrinking sharply when loss (or, with explicit congestion notification, an ECN mark) signals that the path is overloaded. Crucially, the sender is never allowed to have more unacknowledged data in flight than the SMALLER of rwnd and cwnd, whichever is more restrictive wins.

Worked example
Consider a video-conferencing server pushing data to a client on a fast, low-latency corporate network with no packet loss anywhere on the path. If the client's own CPU is pegged and its application isn't draining its TCP receive buffer fast enough, throughput will stall even though the network itself has plenty of headroom, that's a rwnd (flow control) problem, and the fix is on the client (free up CPU, drain the socket faster), not on the network. Conversely, if the same server saturates a congested shared WAN link, cwnd will shrink due to loss even though the receiver's buffer is empty and eager for more data, that's a congestion-control problem, and the fix is either reducing the amount of data in flight or addressing the actual network bottleneck, not the receiver.

Trade-offs & pitfalls
Confusing the two leads to genuinely wrong fixes: tuning net.ipv4.tcp_rmem (receive buffer size, which affects flow control's rwnd) will do nothing for a connection that's actually congestion-limited, and conversely, tuning the congestion control algorithm won't help a connection that's flow-control-limited by a slow receiving application. The fastest way to tell them apart in practice: watch which window value (rwnd vs cwnd) is the SMALLER, limiting one during the stall, most modern TCP instrumentation (ss -i on Linux) exposes both.

Definition — concise

• Least privilege: I give principals only the minimal permissions needed to perform their tasks, nothing more.
• Separation of duties (SoD): I split critical tasks among multiple roles/users so no single account can perform conflicting or high-risk actions end-to-end.

Three practical checks I would perform

1. Cloud IAM permission audit (least privilege)

• Action: Enumerate principals and attached roles (e.g., gcloud iam roles list / aws iam list-attached-role-policies), then map allowed API calls using policy simulator or access-graph tools.
• What I look for: Overbroad roles (Owner, Editor) on service accounts or users, wildcard permissions, or cross-project/organization privileges.
• Evidence: Examples of excessive permissions and an exploit path to sensitive resources.

2. Service account key and usage review (least privilege + SoD)

• Action: Find service accounts with long-lived keys, broad roles, or unused privileges; inspect IAM bindings and key creation timestamps (gcloud iam service-accounts keys list / aws iam list-access-keys).
• What I look for: Keys stored in repos, keys with broad scopes, or service accounts used interactively by humans.
• Evidence: Ability to use a key to access data/modify infra; recommend short-lived tokens, workload identity, and scoped roles.

3. On-prem administrative role separation and delegation check (SoD)

• Action: Review AD groups, nested group membership, and delegated rights via PowerShell (Get-ADGroupMember, Get-ADPermission) and check privileged local accounts on servers.
• What I look for: Single accounts in both approve-and-deploy groups, excessive group nesting that grants privilege escalation, or local admin rights for service accounts.
• Evidence: Demonstrable path where one account can both approve changes and execute them; recommend role separation, just-in-time elevation, and reviewed delegation.

Approach summary (from a penetration tester perspective)
I recommend a layered, risk-weighted placement of scanners so fast checks run early and heavier tests run later, plus clear developer feedback and pragmatic gating.

Scan types by CI/CD stage

• Commit (pre-push / pre-commit hooks / PR): fast SAST rules (low-noise), secret scanning, linting, dependency manifest checks (SCA) for known critical CVEs, basic credential checks. Purpose: immediate, high-signal issues.
• Build (CI pipeline): full SAST, SBOM generation, dependency vulnerability scanning, container image static scan (OS packages, layered CVEs). Still fast but more comprehensive.
• Pre-deploy (staging): DAST (auth-enabled), IAST if available, container runtime configuration checks (CIS), infra-as-code scans (Terraform/CloudFormation). Environment mirrors prod.
• Production (runtime): continuous container scanning, RASP or EDR telemetry, external attack surface monitoring, authenticated vulnerability scans, and scheduled full DAST/pen-test windows.

Presenting results to developers

• Inline in PRs: concise summary + top 3 findings blocking merge with file/line links and suggested fixes.
• Dev dashboard: prioritized backlog with CVSS, exploitability, proof-of-concept links (I often attach reproduction steps I use).
• False-positive workflow: one-click mark/submit for triage with justification; automatic suppression windows for known exceptions.
• Enrichment: link to CWE, remediation snippets, and who to contact for escalation.

Gating criteria (balance security vs productivity)

• Block merge only on Critical/High with exploitability = true OR secrets detected or policy violations (e.g., hardcoded credentials).
• For Medium/Low: create automated tickets and require triage within SLA (e.g., 7 days) but allow merge.
• Thresholds: fail build if > N critical or > M high within same module; otherwise warn.
• Performance: run expensive scans asynchronously and surface results in staging; allow deploy with risk acceptance token for emergencies.
• Continuous improvement: track false positives and tune rules; run periodic pen-tests to validate pipeline coverage.

This keeps developer flow fast while ensuring I/O to surface attackable issues early and escalate real risks before production.

Approach (brief)
I map pen-test TTPs to MITRE ATT&CK by: enumerate actions during an engagement, assign ATT&CK tactic/technique IDs, list telemetry that would observe each action, propose concrete detection logic, and surface likely gaps so defenders can prioritize coverage.

Example: Credential Dumping (T1003)

• Telemetry sources: Windows Security/ Sysmon (ProcessCreate, ImageLoaded), LSASS memory dumps, Endpoint EDR process artifacts, PowerShell logs, Network SMB auths.
• Detection logic: alert on suspicious tools (procdump, Mimikatz) spawning from uncommon parents; high-frequency read access to lsass.exe memory; exports of lsass dump to network shares; anomalous use of comsvcs.dll or sekurlsa hooks. Correlate with privileged logins and process hashes.
• Common gaps: lack of process-memory monitoring, disabled Sysmon/ETW, no baseline for administrative tool usage, missed obfuscated/custom loaders.

Example: Lateral Movement (T1021 / T1076)

• Telemetry sources: Windows Event Logs (4624/4648), SMB/Remote Service logs, RDP logs, EDR process creation, network flow logs.
• Detection logic: alert on credentialed remote logons from workstation-to-server; non-standard admin tools used remotely (psexec, wmiexec); one host authenticating to many endpoints in short window; new service creation + remote command execution.
• Common gaps: limited east-west network visibility, missing authentication telemetry from legacy devices, deferred logging, lack of identity-transaction correlation.

Prioritize closing gaps that expose high-impact techniques first (credential access, lateral movement) by enabling Sysmon/EDR, collecting process memory events, centralizing auth logs, and tuning baselines.

Overview (role perspective)
As a penetration tester I’d question "95% fixed in 30 days" because it can be gamed or misleading. Below are three concrete pitfalls with corrective measures or complementary metrics.

1) Survivor / sampling bias
Problem: Teams may close easy findings or exclude assets before scan, leaving hard ones unreported — inflates the rate.
Fix / complementary metric: Report denominator details — include total critical findings, percentage excluded with reason codes, and “findings discovered by pen test vs scanner.” Track time-to-fix distribution (median, P90) not just a single threshold.

2) Reopened or recurring findings
Problem: Findings marked fixed but reappear (misconfigurations, regression) — one-shot pass hides recurrence.
Fix / complementary metric: Measure recurrence rate: % of critical findings that reappear within 90 days. Also track verification method (automated scan vs manual pen test validation).

3) Changing scanner coverage / triage rules
Problem: Scanner tuning, rule changes, or CVSS mapping shifts can change what counts as “critical,” enabling metric manipulation.
Fix / complementary metric: Freeze and publish scanner rule-set and severity mapping per reporting window. Complement with vulnerability age by discovery date and a “criticality-stable” subset (CVEs with consistent severity across scanners).

These controls give stakeholders honest, actionable insight into remediation effectiveness.

Differences: TGT vs Service (TGS) ticket

• Purpose

  • TGT: Proof that the client authenticated to the KDC; used to request service tickets without reauthenticating.
  • TGS ticket: Ticket for a specific service (identified by SPN) that the client presents to that service to get access.

• Who can decrypt

  • TGT: Encrypted with the KDC/krbtgt long‑term key; only the KDC can decrypt/validate it.
  • TGS: Encrypted with the target service principal’s key (derived from that service account password or managed key); the service and KDC can decrypt.

• Lifetime & use

  • TGT: Longer lifetime, renewable; used repeatedly to obtain TGS tickets.
  • TGS: Shorter lifetime, service-specific, presented to the service to establish a session.

Kerberoasting (brief, attacker POV)

• What the attacker requests

  • Attacker requests a TGS for a target SPN by issuing an AS-REQ / TGS-REQ for that service on behalf of a compromised (or valid) user. The KDC returns a TGS encrypted with the service account’s NTLM/AES key.

• How attacker extracts offline password material

  • The attacker extracts the TGS ticket blob from memory or from the response (e.g., via Rubeus, GetUserSPNs/SetSPN enumeration + TGS request).
  • That ticket contains data encrypted with the service account’s key. The attacker performs offline brute‑force / dictionary attacks against that ciphertext to recover the service account’s plaintext password (or its key). No online AD interaction required, so rates limited only by attacker resources.

• High‑level defense to reduce effectiveness

  • Use strong, long, randomly generated service account passwords and rotate them frequently — or use Group Managed Service Accounts (gMSA) so passwords aren’t human‑set.
  • Disable legacy/weak ciphers (RC4) and enforce AES keys where possible.
  • Limit which accounts have SPNs and avoid using high‑privilege accounts (e.g., domain admins) for services.
  • Monitor/alert on anomalous TGS‑REQ patterns and mass SPN enumeration.

This answer reflects how an attacker performs Kerberoasting and practical mitigations you’d recommend during a pentest report.

Direct answer

Start by scoping the problem precisely enough that ownership boundaries become visible, then build a coalition of every team whose work the fix touches rather than waiting for someone to volunteer ownership. Secure a sponsor with authority spanning those teams who can prioritize the fix against each team's other work, and sequence the remediation so early, low-risk wins buy the credibility needed to sustain a multi-month effort.

Structured elaboration

1. Scope with evidence. Document the pattern concretely enough, which systems or teams are affected and how you know, that it reads as a shared problem rather than one team's incident. Vague framing invites everyone to assume it is someone else's issue.
2. Coalition, not delegation. Identify every team whose systems or processes need to change and bring them into a kickoff where they see the evidence directly, rather than hearing about it secondhand from you.
3. Sponsorship. Find someone with authority spanning all the affected teams who can prioritize the fix against each team's existing roadmap. Without this, the effort re-competes for attention every sprint and eventually loses.
4. Phased roadmap. Ship interim mitigations that reduce risk within days to weeks, while the durable fix is designed and rolled out over the following weeks to months. The organization should not be fully exposed while waiting for the complete fix.
5. Communication rhythm. A lightweight, regular update, what is done, what is blocked, what is next, keeps the effort visible to the sponsor and affected teams over a multi-month timeline, instead of fading once the initial urgency wears off.
6. Closure and verification. Define what "done" looks like before you start, and verify it at the end. A systemic fix without a defined closure condition tends to drift indefinitely.

Worked example

Suppose the systemic problem is a class of vulnerability that recurs across several services owned by different teams (the same shape applies to a systemic reliability gap or an accessibility gap spanning many product surfaces). Six teams share the affected pattern. A kickoff is scheduled within the first week so all six see the evidence together. A low-risk compensating control is rolled out across all six teams within the first two weeks, buying time while the durable fix, a shared library or pattern change, is designed and rolled out over roughly two months. Progress is reported every two weeks to the sponsoring lead and the six teams. The effort closes only once every team has migrated to the durable fix and the compensating control has been verified safe to remove.

Trade-offs & pitfalls

• Trying to fix it yourself across every team's codebase does not scale past a handful of teams and burns out the person carrying it.
• Skipping interim mitigation and going straight for the durable fix leaves the organization exposed to the systemic risk for the entire multi-month build, a costly bet if anything slips.
• Junior candidates tend to focus on getting the technical fix right. Senior candidates weight the coalition and sponsorship just as heavily, because a correct fix with no organizational backing stalls the moment it competes with someone's sprint commitments.
• Not defining "done" is a common pitfall: an effort with no closure condition can run indefinitely, consuming goodwill and losing the sponsor's attention long before every team has actually migrated.

A01 – Broken Access Control

• Description: Users can perform actions or access resources beyond their privileges (e.g., horizontal/vertical escalation).
• Test/Tool: Manual role-fuzzing, Burp Suite repeater to modify IDs/roles, forced browsing and parameter tampering.
• Mitigation: Enforce server-side authorization checks (deny-by-default), centralize access control, use least privilege and vertical/horizontal checks in middleware.

A02 – Cryptographic Failures

• Description: Sensitive data exposed due to weak/absent encryption, poor key management, or insecure algorithms.
• Test/Tool: Inspect TLS with SSL Labs, use Burp to detect cleartext data, check config for weak ciphers and exposed secrets in repos.
• Mitigation: Enforce TLS 1.2+/strong ciphers, encrypt sensitive fields at rest, use managed KMS and rotate keys.

A03 – Injection

• Description: Untrusted input alters command/query logic (SQL, NoSQL, OS, LDAP), enabling data theft or remote code exec.
• Test/Tool: SQLMap/SQLi payloads, Burp intruder for payload injection, manual crafted payloads for different contexts.
• Mitigation: Use parameterized queries/ORMs, input validation, least-privilege DB accounts, and prepared statements.

A04 – Insecure Design

• Description: Architectural or design-level flaws lacking threat modeling lead to systemic insecure behaviors.
• Test/Tool: Threat modeling review, design walkthroughs, abuse-case analysis and checklists (STRIDE).
• Mitigation: Perform threat modeling, adopt secure-by-design patterns, security requirements early in SDLC.

A05 – Security Misconfiguration

• Description: Default, incomplete, or incorrect configurations expose attack surface (exposed debug, open S3, permissive CORS).
• Test/Tool: Automated scanners (Nessus, Nikto), AWS/GCP config checks, manual review of headers, CORS, directory listings.
• Mitigation: Harden configs, remove defaults, automated configuration management, IaC security scans and least privilege.

A06 – Vulnerable and Outdated Components

• Description: Using components with known vulnerabilities allows easy compromise (libraries, frameworks, containers).
• Test/Tool: Software composition analysis (Snyk, OWASP Dependency-Check), container image scanning, CVE lookups.
• Mitigation: Maintain SBOM, automate dependency updates, patch management and runtime protection.

A07 – Identification and Authentication Failures

• Description: Broken auth lets attackers bypass login, reuse tokens, or perform credential stuffing.
• Test/Tool: Burp intruder for password spraying, session fixation tests, inspect JWTs and token expiry, MFA bypass attempts.
• Mitigation: Enforce MFA, secure session management (HttpOnly/Secure cookies), rate limiting and strong password policies.

A08 – Software and Data Integrity Failures

• Description: Insecure CI/CD or unsigned updates allow malicious code injection or tampering of artifacts.
• Test/Tool: Review build pipelines, verify artifact signing, tamper attempts on update mechanisms and dependencies.
• Mitigation: Sign and verify artifacts, secure CI credentials, use reproducible builds and integrity checks.

A09 – Security Logging and Monitoring Failures

• Description: Insufficient logging/alerting prevents detection and response to active breaches.
• Test/Tool: Verify presence/quality of logs (auth, admin actions), simulate incidents and check alerts, review retention and centralization.
• Mitigation: Centralized logging, alerting for suspicious events, retention policies, regular log review/playbooks.

A10 – Server-Side Request Forgery (SSRF)

• Description: App can make backend requests to internal services on attacker’s behalf, exposing internal metadata and services.
• Test/Tool: Burp to manipulate URLs, proxy requests to attacker-controlled endpoints, scan for open internal endpoints.
• Mitigation: Validate/whitelist outbound URLs, restrict egress, metadata service protections and network segmentation.

Direct answer: Time-based blind SQL injection recovers a target value one character at a time by asking the database a true/false question per guess and measuring whether the response is delayed, when neither the response content nor an error message gives away anything directly.

Manual methodology first. Before automating anything, confirm the injection point is exploitable and time-based blind is actually the right technique: submit a payload like ' AND SLEEP(5)-- (or the target database's equivalent - pg_sleep(5) for Postgres, a WAITFOR DELAY for SQL Server) and confirm the response takes measurably longer than a baseline request with no injection. If it does, you have a working timing oracle; then extract a specific value by asking about it one character and one position at a time, for example: ' AND (SELECT SUBSTRING(version(),1,1)) = 'x' AND SLEEP(2)-- for each candidate character x, watching for which guess makes the response slow.

Automation, verified by execution. I built and ran this exact algorithm against a simulated timing oracle (a local function standing in for "send payload, measure response time" so the logic is testable deterministically without depending on real network jitter, which the charter's reproducibility rule flags as unverifiable and environment-dependent):

import string, time

def guess_char_via_timing(position, is_true_fn):
    for ch in string.ascii_lowercase + string.digits + "!":
        if is_true_fn(position, ch):
            return ch
    return None

def oracle(position, candidate):
    # In a real attack this sends the crafted payload and measures wall-clock
    # response time; here it's a direct ground-truth check plus an injected
    # delay, so the ALGORITHM's correctness is verified without depending on
    # actual network timing, which is not reproducible across environments.
    if position <= len(SECRET) and SECRET[position - 1] == candidate:
        time.sleep(0.01)
        return True
    return False

recovered = "".join(guess_char_via_timing(pos, oracle) for pos in range(1, len(SECRET) + 1))

Run against a target value s3cr3t!, this recovered the string character-by-character exactly: s3cr3t!, confirmed by direct comparison. In a real engagement, oracle() would instead send an HTTP request with the crafted payload and measure elapsed time against a threshold (with several repeated measurements and a statistical margin, since real network timing has jitter a single sample doesn't account for).

Trade-offs and pitfalls: time-based blind extraction is slow (one HTTP round trip per character per candidate character in the alphabet you're testing, so len(secret) x alphabet_size requests in the worst case) and noisy in a real network (queueing delays, other traffic, and the target server's own load can all produce false timing signals), so a responsible engagement narrows the character set as much as possible (numeric-only for a version string, hex-only for a hash) and uses binary search over ranges where the DBMS syntax allows it (SUBSTRING(...) > 'm' narrows the alphabet by half per request instead of testing each character individually) rather than the linear scan shown here, which trades simplicity for speed. Always run this kind of testing against a target you're authorized to test, with rate limiting on your own tooling so you don't accidentally degrade the target's availability while extracting data slowly.