Interview Q&A — Reporting, Purple Team & Consulting Leadership

Phases 11–12: Reverse engineering, vulnerability discovery, engagement reporting, purple team methodology, executive communication, detection metrics, and consulting behaviors.

Reverse Engineering (Phase 11)

Q: Walk me through how you triage an unknown binary in the first 10 minutes.

Answer outline:

Minute 0–2 — Static headers. file (magic bytes, architecture, type). strings / FLOSS (extract printable strings; look for URLs, IPs, commands, base64-like strings). dumpbin /headers or pefile — machine type, subsystem, TimeDateStamp, import table, PDB path.

Minute 2–4 — Imphash and entropy. Compute imphash (family classification). Compute per-section Shannon entropy: .text > 7.0 suggests packed/encrypted. DIE (Detect-It-Easy) for packer identification.

Minute 4–7 — Import table analysis. What DLLs and functions? A binary that only imports kernel32!GetProcAddress and kernel32!LoadLibraryA but nothing else is resolving all other imports dynamically (a packer or loader pattern). A binary importing ntdll!NtAllocateVirtualMemory

  • ntdll!NtWriteVirtualMemory + ntdll!NtCreateThreadEx is an injector.

Minute 7–10 — Export table and known-bad matches. Check exports for reflective-loader names. Check imphash against known-bad databases. Check SHA256 against VirusTotal (if authorized and internet-connected). Look for the PDB path to surface build environment details.

Output: a preliminary classification (loader, injector, C2 beacon, credential stealer, dropper) + OPSEC indicator flags + recommended next step (dynamic analysis, deeper static RE, or escalate to malware analysis team).

Q: Name three source code vulnerability classes and how you detect each in a code review.

Answer outline:

1. SQL Injection (CWE-89). Pattern: user-controlled data concatenated into a SQL string.

# VULNERABLE:
query = "SELECT * FROM users WHERE name = '" + user_input + "'"
cursor.execute(query)

# SAFE: parameterized query
cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,))

Detection: grep for string concatenation patterns adjacent to SQL keywords (SELECT, INSERT, UPDATE, DELETE, WHERE) + variable that traces to a request parameter. SAST tools (semgrep, bandit, CodeQL) flag this automatically.

2. Command Injection (CWE-78). Pattern: user-controlled data in a shell command string.

# VULNERABLE:
os.system("ping " + user_input)
subprocess.run(user_input, shell=True)

# SAFE:
subprocess.run(["ping", user_input], shell=False)

Detection: grep for os.system, subprocess.run with shell=True, exec(, eval( where the argument is not a constant. Trace data flow from request parameter to the dangerous sink.

3. Path Traversal (CWE-22). Pattern: user-controlled path component not sanitized before filesystem access.

# VULNERABLE:
filename = request.get("file")
with open("/data/" + filename) as f:  # "../../../etc/passwd" works
    return f.read()

# SAFE:
import os
safe_path = os.path.realpath(os.path.join("/data", filename))
if not safe_path.startswith("/data/"):
    raise ValueError("Invalid path")

Detection: user-controlled variable in open(), os.path.join, Path() calls. Check for realpath + prefix validation as the fix pattern. semgrep has rules for this.

Reporting (Phase 12)

Q: What makes a red team finding complete? Walk me through the required fields.

Answer outline:

A complete finding contains seven fields — without any one of them, the finding fails to deliver actionable value to the client:

  1. Title and severity. Clear, one-line description. Severity (Critical/High/Medium/Low) with CVSS score or business-impact justification.

  2. ATT&CK mapping. The specific technique ID and sub-technique (e.g., T1558.003 for Kerberoasting). This is the universal reference that a blue team can use to look up the technique, its data sources, and existing detections.

  3. Precondition. What must be true for this finding to be exploitable? An unquoted service path is only exploitable if a writable intermediate directory exists. State the precondition explicitly — it drives both severity and remediation priority.

  4. Evidence and narrative. What was observed, when, and how. Sanitized (no real credentials, no PII). Screenshots or log excerpts. Observation separated from inference.

  5. Detection opportunity. The specific log source, event ID, and detection rule that would have caught this action. Ideally a Sigma rule or auditd rule that the client's team can deploy immediately. This is the item that makes the finding last beyond the engagement.

  6. Remediation. Specific, actionable steps: quote the service path, revoke the privilege, enforce IMDSv2, patch the DACL. Include the timeline recommendation (immediate vs. next patch cycle) and the owner (IT, Cloud, AppSec).

  7. Residual risk. After the recommended remediation is applied, what risk remains? This prevents over-confidence: even after quoting the service path, the underlying privilege model that allowed a service account to reach that path may still be misconfigured.

Q: Explain precision, recall, and F1 as applied to security detections. What does low recall mean for a detection rule?

Answer outline:

In a security detection context:

  • True Positive (TP): detection rule fires on a real attack event.
  • False Positive (FP): detection rule fires on a benign event (noise).
  • True Negative (TN): detection rule correctly does not fire on a benign event.
  • False Negative (FN): detection rule does not fire on a real attack event (missed detection).

Precision = TP / (TP + FP) — of all the alerts this rule generates, what fraction are real? Low precision = noisy rule that generates many false alerts → analyst fatigue → alerts ignored.

Recall = TP / (TP + FN) — of all real attack events, what fraction does this rule catch? Low recall = the rule misses attacks. Low recall is a security gap: the adversary can execute the technique and the detection does not fire.

F1 = harmonic mean of precision and recall = 2 × (P × R) / (P + R). A balanced measure.

Purple team application: in a purple team session, the blue team runs the detection rule while the red team executes the technique. TP = rule fires when red team executes. FN = red team executes but rule does not fire. FP = rule fires during normal activity control period.

A detection rule with recall = 0.2 means the red team can execute the technique 80% of the time without alerting. That is the gap the purple team session identifies — and the finding the Lab 02 coverage scorer reports as the top gap to close.

Consulting Behaviors

Q: How do you explain a critical technical finding to a non-technical executive?

Answer outline:

Step 1 — Lead with business impact, not technical mechanics. "An attacker who gains access to any of your employee laptops could, in under 30 minutes, obtain administrative access to your domain controller, giving them full control over all 5,000 Active Directory accounts" — not "we demonstrated Kerberoasting against a service account with an SPN."

Step 2 — Quantify risk in business terms. Map the finding to a regulatory or financial consequence: "Access to the domain controller would allow an attacker to access the payment processing systems in scope for PCI DSS, triggering a potential breach notification requirement under [applicable regulation]."

Step 3 — State the fix in plain language. "The service account's password needs to be rotated to a 25-character random password, and the account should be configured to use a stronger encryption algorithm." Avoid jargon.

Step 4 — State the timeline. "We recommend this be addressed within 7 days — it is a Critical finding because the precondition (low-privileged domain user) applies to every employee."

Step 5 — Invite questions, don't lecture. "Does this raise questions about other systems in your environment? We can scope a follow-on exercise if needed."

The goal: the executive leaves with a clear picture of what is broken, what it means for the business, what to do, and how urgent it is — without needing to understand Kerberos.

Q: Your purple team session shows that 60% of the ATT&CK techniques you exercised generated no alert. How do you present this to the client and what do you recommend?

Answer outline:

Frame it as a measurement, not a failure. "We tested 25 techniques. 10 generated alerts, 5 generated partial alerts, and 10 generated no alert. This gives us a detection recall rate of 40% for the tested technique set. This is a baseline — the engagement identified which gaps to close first."

Prioritize by risk. The 10 techniques that generated no alert are not equal. Run them through the Pyramid of Pain and the client's threat model: techniques used by financially-motivated actors targeting their industry get priority. The Lab 02 coverage scorer's top_gaps output is the prioritization input.

Translate each gap to a detection recommendation. For each blind technique, provide:

  • The missing data source (e.g., Sysmon EID 8 for remote thread injection).
  • The Sigma/auditd rule to deploy.
  • The expected false-positive rate.
  • An estimate of engineering effort.

Set up a follow-on purple team. "We recommend a follow-on exercise in 90 days after these detections are deployed to measure improvement. The goal is to move recall from 40% to above 80% for the priority technique set."

Benchmark against industry. "A 40% detection recall for this technique set is consistent with organizations at a similar maturity level. The gap is addressable in one remediation cycle with the right prioritization."