Attack Vectors and Threat Landscape Questions

Comprehensive knowledge of cyberattack types, common attack vectors, and the evolving threat landscape across human, application, network, and supply chain layers. Candidates should be able to explain how each attack class operates, typical entry points and vulnerable assets, and real world examples. Core topics include phishing and social engineering; malware families such as ransomware and rootkits; denial of service and distributed denial of service attacks; man in the middle attacks; injection attacks including structured query language injection; cross site scripting; cross site request forgery; broken authentication and session management; insecure direct object references and other entries from the Open Web Application Security Project Top Ten; privilege escalation; brute force attacks; zero day exploits; insider threats; insecure configuration; insecure deserialization; and supply chain attacks. For each class candidates should cover indicators of compromise and detection signals, logging and monitoring strategies, behavioral analysis and anomaly detection methods, and threat hunting approaches. Candidates should also discuss prevention and mitigation controls such as secure coding practices, input validation and parameterized queries, output encoding and content security policy, secure authentication and session management, access controls and network segmentation, rate limiting and traffic filtering, secure configuration and patch management, backup and recovery, and supply chain risk management. They should be able to map these controls to incident response activities including containment, eradication, recovery, and post incident remediation, and demonstrate how to use threat modeling to prioritize defenses based on asset criticality and likely attack paths. Finally, candidates should be prepared to describe trends in the threat landscape, high profile breaches and lessons learned, the difference between active and passive attacks, and how threats and defensive priorities vary by industry and organizational scale.

EasyTechnical

39 practiced

Provide an example HTTP request or JSON API call that illustrates an insecure direct object reference (IDOR) and explain how an attacker could exploit it. Then describe design and testing measures you would implement to prevent IDOR, including authorization checks, object-level access controls, and CI tests.

Sample Answer

**Example vulnerable API request (IDOR)**

http

GET /api/v1/users/12345/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJ...user_token_for_67890

An attacker with a valid token for user_id 67890 changes the path to /users/12345/profile and accesses user 12345's data because the server trusts the object ID in the URL instead of enforcing owner checks.

**How attacker exploits it**- Simple enumeration or guessable IDs (sequential integers) lets attacker iterate IDs.- Automated script sends requests with different IDs using the stolen/valid token to harvest profiles.

**Design measures to prevent IDOR**- Enforce authorization by comparing authenticated principal to resource owner on every access (never rely on client-sent IDs alone).- Use opaque, non-guessable identifiers (UUIDv4 or random tokens) and avoid sequential IDs.- Implement object-level access control (ACLs) and policy checks in a centralized auth layer/middleware.- Principle of least privilege: return minimal fields and require additional checks for sensitive attributes.- Use token binding or include owner claims in JWT and validate them server-side for consistency.

**Testing & CI controls**- Add automated unit/integration tests asserting access forbidden (403) when token user != resource owner.- Fuzzing/enumeration tests that try batch ID access patterns using CI pipelines.- Introduce negative tests (attempt access with different roles/scopes) and run in PR gates.- Include runtime monitoring/alerting for abnormal ID enumeration patterns (rate limits, WAF rules).- Code review checklist requiring explicit object-level auth checks before returning resources.

EasyTechnical

44 practiced

In Python using psycopg2, show a short example of an insecure SQL query vulnerable to injection and then provide a secure parameterized version. After your code example, explain how you would detect SQL injection attempts via web and database logs and list quick containment actions when SQL injection is suspected in production.

Sample Answer

**Insecure (vulnerable) example**

python

# Python + psycopg2 — vulnerable to SQL injection
user_input = "1 OR 1=1"
cur.execute(f"SELECT id, username FROM users WHERE id = {user_input};")
rows = cur.fetchall()

**Secure parameterized version**

python

# Use parameterized queries to avoid injection
user_input = "1 OR 1=1"
cur.execute("SELECT id, username FROM users WHERE id = %s;", (user_input,))
rows = cur.fetchall()

**Why secure works**- psycopg2 parameterization sends values separately from SQL, preventing attacker-controlled text from becoming executable SQL.

**Detecting SQLi via logs**- Web logs: unusual query strings, repeated payload markers (', --, OR 1=1), multiple 500/400 responses, large parameter lengths, rapid repeat requests from same IP.- Database logs: parse errors, unexpected long queries, frequent use of OR/UNION/SELECT in parameters, abnormal spikes in slow queries or row counts.- Use IDS/IPS/WAF alerts, anomaly detection (rate-based, regex), and correlation (web request → DB query).

**Quick containment actions**- 1) Block offending IPs / rate-limit user agents at edge (WAF).- 2) Deploy WAF rules to drop common payloads and normalize inputs.- 3) Rotate/limit DB credentials used by app, revoke compromised sessions.- 4) Enable parameterized queries and roll back recent deploys if they introduced vulnerability.- 5) Snapshot logs and isolate affected services for forensic analysis; increase DB logging level.- 6) Patch code, run tests, and perform targeted pentest before re-enabling traffic.

MediumTechnical

37 practiced

A production API log shows exceptions during object deserialization and you observe unusual outbound commands executed by auxiliary systems. Explain how insecure deserialization vulnerabilities operate, what specific log indicators you would search for to confirm exploitation, and describe the code changes and patching steps you would perform to remediate and prevent insecure deserialization.

Sample Answer

**Brief approach**Describe exploitation mechanics, list forensic/log indicators to search, then give concrete code changes and patching steps to remediate and prevent reoccurrence.

**How insecure deserialization works**- Attackers craft serialized payloads that, when deserialized by a trusting runtime (e.g., Java ObjectInputStream), trigger gadget chains leading to arbitrary code execution, command execution, or data exfiltration.- Exploits rely on unsafe deserialization of untrusted input, presence of exploitable classes/gadgets, and permissive class resolution.

**Log indicators to search for**- Stack traces showing deserialization classes: java.io.ObjectInputStream, readObject, readExternal, javax.naming.Reference, org.apache.commons.collections.functors.*, or suspicious gadget classes.- Exceptions with ClassNotFoundException, InvalidClassException, or Unexpected class names in logs.- Outbound connections/commands immediately following deserialization errors (DNS queries, HTTP POSTs, SSH/LDAP binds).- New process starts or unusual command-line args from app server (e.g., java exec calls).- Unusual parameter patterns: long Base64 blobs, serialized payload markers (AC ED 00 05 for Java).

**Code changes to remediate**- Replace native Java serialization with safer formats (JSON with explicit parsing libraries like Jackson with configured whitelists) or use protobufs.- If serialization required, implement a strict whitelist: validate classes before deserialization using ObjectInputFilter (Java 9+) or custom validation.- Disable dynamic class loading during deserialization; avoid readObject/readResolve overrides that execute logic.- Remove or update vulnerable libraries (Commons-Collections, Spring versions) and eliminate known gadget classes from classpath.

**Patching & deployment steps**1. Emergency mitigation: deploy WAF rules to block payload signatures and rate-limit endpoints; add egress rules to block suspicious outbound hosts.2. Hotfix: add ObjectInputFilter to reject unexpected classes; add input size limits and timeouts.3. Code patch: implement safe deserialization alternative, add unit/integration tests asserting rejection of malicious payloads.4. Dependency updates: upgrade/remove vulnerable libs and rebuild.5. CI checks: add SAST rules and automated tests for insecure-deserialization patterns; require code review for serialization use.6. Post-deploy monitoring: enable detailed logging around deserialization points, alert on exploitation indicators, and run endpoint scans for persistence.

**Why these steps**They remove exploitable attack surface, enforce explicit type validation, and add detection/containment so similar attacks are prevented and rapidly detected.

MediumTechnical

35 practiced

Outline a WAF rule set and monitoring strategy to mitigate multiple OWASP Top Ten risks including SQL injection, XSS, CSRF, insecure deserialization, and malicious file uploads. Provide example rule types, a strategy for whitelisting versus blacklisting, and explain how you would test and tune rules to minimize false positives while maintaining protection.

Sample Answer

**Approach summary**Design layered WAF rules that combine signatures, behavioral/anomaly detection, and explicit input validation, then iterate via staged deployment, monitoring and feedback to minimize false positives.

**Example rule set (by OWASP risk)**- SQLi: regex/parameterized signature checks, anomaly score on unusual SQL keywords, strict parameterized input policy (block on high-confidence). - XSS: sanitize/block payloads with script tags, event handlers, JS pseudo-protocols; apply HTML-encoding enforcement and CSP header checks. - CSRF: enforce SameSite cookies, require valid anti-CSRF token presence for state-changing endpoints; block requests missing token. - Insecure deserialization: block suspicious Content-Type/serialized payloads; enforce allowlist of acceptable object types and validate length/entropy; sandbox processing paths. - Malicious uploads: enforce extension+MIME whitelist, content inspection (file signatures), antivirus/AV-scanner sandboxing, size limits, strip metadata, deny executable types.

**Rule types**- Signature/regex, positive (whitelist) parameter schemas, anomaly-scoring, rate-limiting, geo/IP reputation, file-signature validation, header enforcement (CSP, X-Frame-Options).

**Whitelist vs Blacklist strategy**- Prefer whitelisting for inputs where structure is known (file types, API parameter schemas, allowed file extensions, allowed HTTP methods). - Use blacklisting/signatures for unknown or free-form inputs (comments, search) combined with anomaly scoring and rate limits. - Default-deny for sensitive endpoints (admin, payment) with explicit allow rules.

**Monitoring & measurement**- Centralized logs to SIEM (fields: rule-id, score, request snapshot, user-agent, IP, session). - Dashboards: rule hit rate, false-positive rate (user complaints, 200->blocked), top blocked URIs, anomaly scores over time. - Alerts for sudden spikes, repeated blocks for same user/IP, escalation to SOC.

**Testing & tuning workflow**1. Baseline: run new rules in shadow/monitor mode for 1–2 weeks collecting hits. 2. Use labeled datasets: replay known-good traffic and attack corpora (OWASP, ZAP, custom payloads). 3. Adjust thresholds: raise sensitivity where false positives occur; add exceptions or refine regex/parameter schema. 4. Gradual enforcement: move high-confidence rules to blocking, keep medium-confidence as challenge (CAPTCHA) or rate-limit. 5. Feedback loop: integrate developer/QA review, run periodic false-positive audits, automated regression tests for business flows.

**Minimizing false positives**- Use context-aware rules (parameter name, endpoint, HTTP verb). - Apply staged enforcement, challenge responses, and learning-mode. - Maintain an allowlist of safe clients/endpoints and time-windowed suppressions for known integrations.

This combination ensures layered protection across OWASP Top Ten while allowing measurable tuning to protect availability and reduce false positives.

MediumTechnical

44 practiced

Draft an incident response plan for a ransomware outbreak that has encrypted files on several file servers. Cover detection and identification indicators, containment strategies (network isolation, EDR quarantine), eradication and remediation steps, recovery and restore strategies including verification, forensic evidence collection and chain-of-custody, external communication, and post-incident hardening measures.

Sample Answer

**Situation & scope**- Confirm impacted file servers, share names, hostnames, timestamps, and number of encrypted files. Engage IR lead and legal.

**Detection & identification indicators**- Alerts: multiple AV/EDR detections for ransomware signatures, mass file rename/extension changes, high entropy, rapid file I/O, suspicious process spawning (PowerShell, wmic), anomalous SMB activity, deletion of shadow copies, ransom notes.- Validate with EDR telemetry, SIEM queries (failed backups, unusual logins), and snapshot of affected hosts.

**Containment**- Short-term: Isolate affected hosts from network (switch port down, VLAN quarantine) and block C2 domains/IPs in perimeter devices.- EDR: quarantine processes, block binaries, suspend compromised user accounts, disable lateral auth (NTLM/SMB) from impacted machines.- Preserve network and host memory snapshots before reboots.

**Eradication & remediation**- Identify initial entry (phishing, RDP, exploit), remove persistence, patch vulnerabilities, reset credentials, rotate keys/secrets.- Clean images or rebuild hosts from known-good baselines; do not decrypt in place without vetting.

**Recovery & restore**- Restore from immutable/offline backups with point-in-time prior to encryption.- Validate integrity: checksum, sample file open/read, and application-level tests.- Staggered bring-up: restore one server, verify, then resume others.

**Forensics & chain-of-custody**- Collect disk images, memory dumps, EDR logs, network captures. Label evidence, record collector, timestamps, and storage location. Maintain chain-of-custody forms and preserve original media.

**External communication**- Notify stakeholders, legal, and regulators per SLA. Coordinate with PR: factual, limited technical detail. Engage law enforcement and trusted ransomware negotiator if needed.

**Post-incident hardening**- Implement EDR tuning, MFA, least privilege, patch management, network segmentation, immutable backups, detector playbooks, purple-team testing, and improved backup verification cadence. Conduct full post-mortem and update IR runbooks.

Unlock Full Question Bank

Get access to hundreds of Attack Vectors and Threat Landscape interview questions and detailed answers.

Join thousands of developers preparing for their dream job.