Microsoft Penetration Tester (Junior Level) Interview Preparation Guide

Overview (role perspective)
As a penetration tester I treat all artifacts as highly sensitive—they’re attack tools and evidence. My best practices cover secure storage, transmission, controlled access, retention, disposal, and contractual safeguards.

Secure storage & access control

• Store artifacts in encrypted repositories (AES-256 at rest, e.g., LUKS, BitLocker, or encrypted S3 with SSE-KMS).
• Enforce least-privilege RBAC and MFA for accounts; use ephemeral credentials where possible.
• Keep exploit code and creds in isolated workspaces (VMs/containers) with no internet egress except through monitored jump hosts.
• Maintain audit logs (immutable, centralized SIEM) of access, downloads, and execution.

Secure transmission

• Use end-to-end TLS 1.2+/mutual TLS for transfers; prefer SSH with key auth or SFTP over VPN.
• Exchange credentials via secure secret managers (HashiCorp Vault, AWS Secrets Manager) with short TTLs.

Retention & disposal

• Retention policy: retain artifacts only as long as needed for validation and reporting (typical 30–90 days unless extended by client).
• Secure deletion: overwrite and shred (e.g., srm) or crypto-erase keys; for cloud, delete snapshots and revoke KMS keys.

Contractual protections

• Require explicit scope, data handling SLAs, NDA, data deletion and breach notification clauses, and record-of-destruction.
• Specify liability limits, accepted encryption standards, and retention periods in SOW.

Operational controls & evidence hygiene

• Label artifacts, document chain-of-custody, and include reproduction steps in reports rather than raw credentials.
• Regularly review and rotate testers’ keys and perform post-engagement audit.

Direct answer
Over the life of a connection, TCP's congestion window grows exponentially in slow start, switches to growing linearly in congestion avoidance once it approaches a known safe ceiling, and reacts to loss with fast retransmit and fast recovery rather than always restarting from scratch.

Structured elaboration

1. Slow start: the connection begins with a small congestion window (historically 1 segment; modern stacks start higher, commonly around 10 segments per RFC 6928) and roughly DOUBLES the window every round trip, since each of the ACKs for the previous batch triggers sending two new segments. This continues until either loss occurs, or the window reaches a threshold called ssthresh (slow start threshold), at which point the sender switches strategies.
2. Congestion avoidance: once at or above ssthresh, growth switches from exponential to roughly linear (classically, additive increase of about one segment per round trip), a much more cautious probe for additional capacity.
3. Fast retransmit: if the sender sees three duplicate ACKs (the receiver repeatedly acknowledging the same byte, implying a specific segment is missing but LATER data did arrive), it retransmits the missing segment immediately, without waiting for the retransmission timer to expire, since three duplicate ACKs is strong, specific evidence of loss rather than simple reordering.
4. Fast recovery: after a fast retransmit, rather than collapsing all the way back to slow start, ssthresh is set to about half the current window, and the window itself is set near that halved value, so the sender doesn't have to re-earn all its previous progress from a window of one segment; it resumes near where it estimates the path can actually sustain.

Worked example
Picture a connection whose window has grown to 64 segments in flight when a single segment is lost and detected via three duplicate ACKs (not a full timeout). Fast retransmit resends the missing segment immediately. Fast recovery sets ssthresh to roughly 32 (half of 64) and the window to near that value, then resumes congestion avoidance's linear growth from there, rather than collapsing to slow start's small initial window and doubling all the way back up. Contrast this with a RETRANSMISSION TIMEOUT (no duplicate ACKs arrived at all, meaning the loss was severe enough that the whole flight of data went missing): that's a much stronger loss signal, and the sender resets ssthresh to half the current window but drops the actual window all the way back to slow start's minimum, since a timeout implies the path may be far more broken than a few duplicate ACKs would suggest.

Trade-offs & pitfalls
It's a common mistake to say TCP always halves its window on any loss and moves on; a full retransmission timeout is treated far more conservatively (full reset to slow start) than a fast-retransmit-detected loss (a much gentler recovery), because the ABSENCE of any duplicate ACKs at all is itself informative: it suggests either a much larger loss event or a badly congested/broken path, not just one unlucky dropped segment.

Opening (1 min)

• Quick purpose: scope, test window, objective. Set expectations for risk-focused briefing.

Executive Summary (3 min)

• High-level score/status (risk rating), 3–5 top business-impact findings, likelihood × impact. Verbal: topline risk narrative. Slide: one-sentence findings + heatmap.

Top Risks & Business Impact (6 min)

• One slide per top 3 risks: what we found, attack chain, business impact, exploitability. Verbal: consequences and example exploit flow. Slide: simple diagram and remediation priority.

Remediation Roadmap & Cost/Impact (5 min)

• Recommended fixes (quick wins vs strategic), estimated effort (low/med/high), expected reduction in risk. Verbal: prioritization rationale. Slide: 90-day / 6-month roadmap. Detailed estimates and task-level cost model in appendix.

Compliance & Legal Exposure (2 min)

• Summarize any regulatory gaps or data exposure. Verbal: factual findings and recommended legal engagement. Appendix: full evidence timeline, exploit artifacts, and legal considerations.

Q&A & Next Steps (3 min)

• Assign owners, show validation plan.

Handling difficult exec questions

• Legal exposure: stay factual—describe what was accessed, evidence, and which regs may be implicated; defer legal interpretation to counsel while offering technical remediation and timelines.
• Remediation cost estimates: present ranges and assumptions, show line-item appendix, offer a phased plan that limits immediate cost (patches, compensating controls) and a follow-up retest to validate spend effectiveness.

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.

Brief summary / goal
I would chain an unauthenticated SSRF in a public service to query the cloud provider metadata service, retrieve ephemeral IAM credentials, then use those credentials to read and exfiltrate an S3 bucket. Below are concrete steps, technical challenges, and mitigations.

Exploit chain steps

1. Reconnaissance

   • Identify SSRF endpoint, allowed HTTP methods, accepted URL schemas, response behaviors, and payload size/timeouts.
   • Confirm server is on cloud instance with reachable metadata IP (AWS 169.254.169.254).

2. Bypass protections & request shaping

   • If SSRF allows only GET, craft GET to metadata paths. For AWS IMDSv2 (token required), perform a PUT to /latest/api/token with header
     • If SSRF supports custom headers/methods, request token then request credentials with X-aws-ec2-metadata-token.
   • If SSRF cannot send custom headers, attempt:
     • Metadata paths that don’t require token (older IMDSv1), or
     • Abuse proxyable endpoints (e.g., redirect chains, HTTP/1.0 tricks, CRLF injection if available), or
     • Use path traversal / host header manipulation to reach metadata.

3. Retrieve credentials

   • Request role name from /latest/meta-data/iam/security-credentials/
   • Request credentials from /latest/meta-data/iam/security-credentials/<role>
   • Parse AccessKeyId, SecretAccessKey, Token, Expiration.

4. Use credentials to access S3

   • From attacker-controlled server, instantiate AWS SDK/CLI with retrieved creds and list/get objects from target S3 bucket.
   • If bucket ACLs permit, download objects directly; otherwise, call sts:AssumeRole if credentials allow role chaining.

5. Exfiltration

   • Direct pull to attacker host (typical).
   • If egress blocked, use the vulnerable service as proxy: instruct it to perform S3 GETs and return contents via SSRF responses, or create presigned URLs and fetch externally.
   • If limited network, abuse other cloud services accessible to instance (SNS, SQS, Lambda) to relay data.

Practical example

• With full HTTP support: PUT http://169.254.169.254/latest/api/token -> receive token. GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ with header X-aws-ec2-metadata-token: <token> -> role name. GET role -> JSON creds -> aws s3 cp s3://target-bucket/file - using creds.

Key technical challenges

• IMDSv2 token requirement (needing non-GET or header support).
• SSRF filters blocking private IPs, DNS allowlist, or response truncation.
• Short credential lifetime — must act fast or refresh via token.

Cloud-specific mitigations

• Enforce IMDSv2 on instances; reject IMDSv1.
• Set IMDS hop limit to 1 to prevent container/sidecar access.
• Strict instance IAM roles: least-privilege, avoid broad S3 access, split duties across roles.
• Network controls: egress filtering to block metadata IP from application layer, host firewall rules.
• Application defenses: validate/allowlist outbound URLs, block requests to 169.254.0.0/16, sanitize inputs, deny SSRF vectors.
• Monitoring & detection: alert on metadata token requests, abnormal STS/GetCallerIdentity calls, unusual S3 access patterns, CloudTrail + GuardDuty rules.
• Use IAM Conditions (source VPC, instance profile) and avoid long-lived credentials on instances.

Conclusion / recommendations
Prioritize eliminating SSRF, enforce IMDSv2 and hop limit, apply least-privilege IAM, and add network/application-layer controls and logging to detect and prevent this chain.

I’d start by aligning everyone on the outcome, not the function-specific asks.

Step 1: Clarify the shared goal
I’d bring product, design, data, and engineering into one working session and define the business outcome, success metrics, and deadline constraints.

Step 2: Map dependencies and capacity
I’d list the critical dependencies, identify who owns each one, and make capacity visible by function. That exposes where the real bottlenecks are.

Step 3: Sequence the plan
I’d build the plan around the critical path: what must happen first, what can run in parallel, and what can be deferred. If capacity is tight, I’d use a simple trade-off framework: highest business value, lowest risk, and strongest dependency unlocks first.

Step 4: Create commitment
I’d confirm decision rights, document what each team is committing to, and define checkpoints where we can re-plan if assumptions change.

The goal is not to make everyone equally happy; it’s to make the trade-offs explicit so each group can commit to a plan they helped shape.

Worked example
Say the initiative is a checkout redesign that needs a payments-data migration (data team), a new UI (product design and frontend), and an updated fraud-detection model (data science). In the working session, the shared goal turns out to be reducing checkout abandonment by a set amount before the next major sales event, which becomes the deadline constraint. Mapping dependencies shows the new UI can't ship until the data migration completes, and the fraud model needs at least two weeks of production traffic on the new UI before it can be retrained safely, so the data migration is the critical-path item. Applying the trade-off framework, the data migration (highest dependency-unlock value) is sequenced first, the UI ships second, and the fraud-model update is explicitly deferred to just after the sales event rather than rushed; each team commits to that sequence in writing, with a checkpoint two weeks before launch to re-plan if the migration slips.

Stepwise approach (overview)

1. Triage scanner output to unique findings (IP/hostname, port, service, vuln ID).
2. Gather evidence from the host to confirm: service banners, configs, package manager, process info, and source references.
3. Map version -> component -> fix and produce an actionable remediation.

Concrete actions & examples

• Validate service banner and process:
  • Run:

# TCP banner + process
nc -v <host> <port>
ssh user@host 'ps aux | grep <service>'

• Use banner text to pin vendor/version (e.g., "nginx/1.14.0").
• Check OS/package metadata:

# Debian/Ubuntu
ssh host 'cat /etc/os-release; dpkg -l | grep nginx'
# RHEL/CentOS
ssh host 'rpm -qa | grep httpd'

• Inspect config files to confirm affected module/feature:

ssh host 'grep -R "ssl_protocols" /etc/nginx*'

• For apps, check dependency manifests:

# Node
cat package.json | jq '.dependencies'
# Java
grep -R "<version>" pom.xml

• Correlate with source/repo references: git commit, Dockerfile, container image tags to find exact deployed artifact.

Mapping to remediation

• If package manager shows vulnerable version -> recommend upgrade + test plan (apt/yum update, pinned versions).
• If custom build/source uses vulnerable library -> update dependency, run CI tests, rebuild images, redeploy.
• If misconfiguration exposes vulnerability -> change config, restart service, validate.
• Provide reproducer steps, evidence (screenshots, command outputs), CVE link, and risk/priority.

Why this works
Combining passive scanner evidence with authoritative artifacts (banners, package metadata, configs, source) reduces false positives and yields precise, actionable remediation steps the ops/dev teams can implement.

Direct answer: Server-Side Request Forgery (SSRF) happens when an application fetches a URL on the caller's behalf, and an attacker manipulates that URL to make the server issue requests to destinations it never intended to reach - most dangerously, internal-only services the attacker could never reach directly.

Structured elaboration.

Common attack patterns:

• Cloud metadata endpoint abuse: cloud providers expose an instance-metadata service (historically 169.254.169.254 for AWS/GCP/Azure) reachable only from inside the VM/container, which can hand out temporary IAM credentials with no authentication required by design (it trusts network position). A server that fetches an attacker-supplied URL and is tricked into requesting http://169.254.169.254/latest/meta-data/iam/security-credentials/role can leak those credentials straight into its response.
• Internal host discovery: an attacker supplies internal IP ranges or hostnames (http://10.0.0.5:8080/admin, http://internal-service.local/) that the public internet can't reach directly, using the vulnerable server as a proxy to port-scan and probe the internal network.
• DNS exfiltration / blind SSRF: even when the response body isn't returned to the attacker, DNS lookups or timing differences the vulnerable server makes can leak information about internal network structure to an attacker-controlled DNS server.

Mapping and mitigations. SSRF maps to CWE-918 and to OWASP A10:2021 (Server-Side Request Forgery) under the 2021 edition; the newer OWASP Top 10:2025 edition no longer keeps SSRF standalone, folding it into the broader A01:2025 Broken Access Control category instead. Core mitigations:

1. URL allowlisting - only fetch URLs matching an explicit set of permitted domains/schemes, rejecting everything else by default, rather than trying to blocklist "bad" destinations (which is easy to bypass with alternate IP representations, redirects, or DNS rebinding).
2. Egress network filtering - even if application-level validation has a gap, network policy that blocks the application server from reaching internal-only ranges (including the cloud metadata IP specifically) and unexpected external destinations provides a second, independent layer.
3. Disabling the credential-issuing metadata endpoint's default trust, where the cloud platform supports it (e.g. requiring a hop-limited, token-gated metadata request - AWS IMDSv2 - rather than the older unauthenticated IMDSv1) closes the most damaging specific instance of this pattern at the platform level.
4. Disabling unneeded redirects: an allowlist check performed only against the original URL is silently bypassed if the fetch follows a 302 response pointing at an internal address, so the HTTP client used for the fetch should have automatic redirect-following turned off entirely, or re-validate the destination against the same allowlist on every redirect hop rather than only once at the start.

Worked example. An image-thumbnailing feature accepts a URL and fetches it server-side. An attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/role instead of an image URL; if the fetch has no allowlist and no egress restriction, the server dutifully fetches that internal endpoint and (if the response is rendered back, even as "the image couldn't be processed, here's the raw response") leaks live cloud credentials to the attacker.

Trade-offs and pitfalls: allowlisting by domain name alone can be bypassed via DNS rebinding (a domain that resolves to a safe IP at validation time, then to an internal IP at request time); the more robust fix validates and pins the resolved IP at request time, not just the hostname at validation time, and rejects redirects that would take the request outside the allowed destination set.

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.

Direct answer

In the first 15 to 30 minutes, the priority is confirming scope and taking evidence-preserving containment action, in that order: check identity and endpoint telemetry first, capture what you see before it disappears, then contain based on confidence, and notify as soon as you have enough signal to say something useful.

Structured elaboration

Order of investigation for a credential-compromise or lateral-movement alert:

1. Identity signals first. Check the authentication logs for the account in question: source IP, geolocation, MFA status, time of day relative to the user's normal pattern, and whether the "successful admin login" following failed attempts is consistent with a real user (travel, new device) or clearly anomalous.
2. Endpoint telemetry second. Pull EDR data for any host the account touched around the alert window: running processes, especially anything matching the suspicious pattern (an encoded PowerShell command, an unusual parent-child process relationship), and any outbound network connections from that host.
3. Network telemetry third. Check for lateral movement signals from the account or host: unusual SMB traffic, new connections to other internal hosts, or anything reaching out to an external IP with no legitimate business reason.

What to capture as evidence, before anything else changes: a snapshot of the current process list and network connections on any implicated host, the raw authentication log entries (not just a summary), and a copy of the specific alert with its full context. Do this before taking any containment action that might cause the process or connection to disappear.

Initial containment actions, roughly in order of aggressiveness: disable or force a password reset on the account if compromise looks credible; isolate the specific host at the EDR or network layer if there's endpoint-level evidence of compromise, not just an identity anomaly; and if lateral movement across multiple hosts is confirmed, consider a broader network segmentation action rather than isolating one host at a time.

Who to notify within this window: your incident lead or on-call security manager immediately once you've confirmed this is a real incident (not a false positive), and the system owner of any affected host so they're aware before you take containment action that might affect their service, unless the risk of tipping off an insider is a specific concern.

Worked example

An alert shows ten failed logins on an admin account, followed by a successful login from an unfamiliar country, followed by an EDR alert for a suspicious process on a file server that same account accessed. In order: pull the raw authentication log entries and confirm the geolocation and device fingerprint don't match the user's normal pattern (rules out "they're just traveling"); pull the EDR process tree on the file server and find the suspicious process is an encoded PowerShell command spawning a network connection to an unfamiliar external IP; snapshot the process list and network connections before doing anything else. Given both identity and endpoint evidence now corroborate each other, disable the compromised account immediately (low business cost, high containment value) and isolate the file server at the network layer while notifying the incident lead and the file server's system owner, all within the first 20 minutes.

Trade-offs and pitfalls

The most common mistake under time pressure is jumping straight to containment before confirming the alert is real, which causes unnecessary business disruption on a false positive; the opposite mistake, spending too long gathering evidence before containing a clearly credible compromise, gives the attacker more time to cause damage. The order above (identity, then endpoint, then network, capture-before-contain) is designed to get you to a confident containment decision as fast as possible without either extreme. The exact same triage process applies even when the alert source turns out to be a misconfiguration (an admin endpoint accidentally exposed to the internet) rather than an active attacker; the difference is urgency and communication tone, not method, since you don't yet know which one it is when you start.