Threat Hunting and Threat Intelligence Questions

How each attack works (brief)

• XSS: Attacker injects malicious script into pages viewed by other users (stored, reflected, DOM). Script executes in victim's browser under site origin, stealing cookies, performing actions, or altering UI.
• CSRF: Attacker causes a victim's browser to send authenticated requests to a target site (via form, image, fetch) exploiting existing session/authentication to perform unwanted state-changing actions.

Where they appear in the stack

• XSS: Presentation layer — templates, client-side JS, DOM APIs, input/output encoding points.
• CSRF: Application logic/auth layer — session management, state-changing endpoints (POST/PUT/DELETE), API endpoints lacking request binding to user context.

Three practical defenses for XSS (code-review + SDLC)

1. Output encoding/escaping per context (HTML, JS, URL) — require libraries/templates that auto-escape; flag raw innerHTML usage.
2. Input validation + canonicalization — enforce whitelists for structured inputs and reject dangerous content at entry points.
3. CSP with strict script-src and nonce-based inline policy — verify CSP headers in integration tests and block unsafe-eval/inline.

Three practical defenses for CSRF (code-review + SDLC)

1. Anti-CSRF tokens (per-session or per-request) validated server-side — mandate framework-provided token patterns and test coverage.
2. SameSite=strict/lax cookies and proper cookie attributes (Secure, HttpOnly) — enforce cookie settings in config checks.
3. Require same-origin checks / double-submit cookie or Origin/Referer validation for sensitive endpoints — include automated scanners and unit tests to validate Reject on mismatch.

I would enforce these via secure coding standards, automated SAST/DAST checks, CI tests for headers/tokens, and mandatory code-review checklist items.

Definition — Supply-chain attack (software):
A software supply-chain attack is when an adversary compromises a trusted supplier, build pipeline, or artifact to insert malicious code or backdoors so that downstream consumers receive and execute compromised software.

Typical attack stages

1. Reconnaissance: identify target vendor/tooling
2. Compromise vendor: breach dev workstation, CI, or repo
3. Introduce malicious code: commit trojanized code or dependency
4. Sign/publish malicious artifact: use stolen keys or replace artifacts
5. Distribute via updates: push via trusted package manager/auto-update

Supplier risk-management checklist (Cybersecurity Engineer perspective)

• Vendor vetting

  • Security posture review (ISO/ SOC 2 / SBOM policy)
  • Pen-test & breach history, contract SLAs for disclosure
  • Least-privilege access & MFA for vendor accounts

• SBOM consumption & validation

  • Require SBOMs (CycloneDX/SPDX) per release
  • Automated SBOM ingestion, dependency mapping, SCA alerts
  • Verify provenance and transitive dependencies

• Artifact signing & provenance

  • Enforce reproducible builds and signed artifacts (sigstore/cosign)
  • Multi-party attestation (in-toto) and key custody with HSM/KMS
  • Rotate and monitor signing keys; alert on anomalous signatures

• CI/CD controls

  • Pipeline hardening: ephemeral runners, signed build steps, least privilege
  • Binary transparency logs and immutable build logs
  • Automated tests: SCA, SBOM diff checks, fuzzing, SAST/DAST
  • Git protections: signed commits, protected branches, PR approvals

• Runtime protections

  • Runtime integrity: code signing verification, image signature enforcement
  • Runtime monitoring: EDR, K8s admission controllers, policy engines (OPA/Gatekeeper)
  • Network segmentation, allowlists, memory protections (ASLR, CFI)
  • Rapid rollback & canary deployments, alerting for anomalous behavior

Closing
Implement these controls in a layered, automated fashion and validate with regular red-team exercises and supplier audits.

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.

Approach (brief)
Parse access logs, extract timestamp, IP, username, and result. Use a per-IP sliding-window deque of failed attempts and a per-window set of usernames. Flag IPs exceeding 50 failed attempts within any 10-minute window and involving >20 distinct usernames.

Python implementation

from collections import deque, defaultdict
from datetime import datetime, timedelta

WINDOW = timedelta(minutes=10)
FAIL_THRESHOLD = 50
USER_THRESHOLD = 20

# expected log parser -> return (ts:datetime, ip:str, user:str, result:str)
def parse_line(line): ...
# example assumes parse_line implemented

ip_attempts = defaultdict(lambda: deque())     # deque of (ts, user)
alerts = set()

with open("access.log") as f:
    for line in f:
        ts, ip, user, result = parse_line(line)
        if result.lower() != "failure":
            continue
        dq = ip_attempts[ip]
        dq.append((ts, user))
        # evict old
        while dq and dq[0][0] < ts - WINDOW:
            dq.popleft()
        if len(dq) > FAIL_THRESHOLD:
            users = {u for _, u in dq}
            if len(users) > USER_THRESHOLD:
                alerts.add(ip)

for ip in alerts:
    print("Suspicious IP:", ip)

Why thresholds

• 50 failures in 10 minutes ≈ sustained automated activity; >20 usernames indicates credential stuffing vs single-user brute force.
• Balances detecting high-volume attacks while avoiding single-account lockout noise.

Tuning to reduce false positives

• Exclude known shared IPs / corporate NATs and VPN CIDRs.
• Use adaptive thresholds per subnet, geolocation, or historical baseline.
• Require vertical signals (multiple endpoints, user-agent variety) or combine with successful logins.
• Implement rate-limiting, alert scoring (severity), and feedback loop to adjust thresholds based on analyst validation.

Approach summary (as a Cybersecurity Engineer)
I’d implement a layered API-gateway solution combining per-entity and global controls, flexible token-bucket enforcement for burst handling, plus detection rules for slow DDoS/scraping patterns and observability to tune thresholds.

Token-bucket vs Leaky-bucket

• Token-bucket: allows bursts up to bucket size and refills at rate R — good for user-facing APIs where occasional bursts are acceptable.
• Leaky-bucket: enforces steady output (smoother rate) — better to limit sustained abusive clients.
  I prefer token-bucket at the gateway with optional downstream leaky-bucket shaping for critical backend services.

Per-user vs Global limits

• Per-user (API key, client IP, JWT sub): prevents single client from exhausting resources. Adaptive based on user tier.
• Global limits: protect overall system from mass distributed abuse; enforced as emergency backstop.
  Use hierarchical rules: per-user -> per-API endpoint -> global.

Burst handling & mitigation

• Configure token-bucket size = expected legitimate burst (e.g., 10 requests) and refill rate per SLA.
• Apply progressive penalties: 429 with Retry-After, short-term blacklisting for repeated violations, and challenge (CAPTCHA or proof-of-work) for scraping behavior.

Client feedback via headers
Return standard and custom headers:

• Retry-After: seconds until next token
• X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
• X-RateLimit-Bucket-Size (optional)
  These assist well-behaved clients and reduce accidental retries.

Metrics to monitor & tune

• Request rates per user, per endpoint, and global
• 429/403 rates, error churn, latency P95/P99
• Token exhaustion events and burst frequency
• Source IP entropy and client footprint (UA diversity) for scraper detection
• Correlate with backend CPU/memory and queue lengths
  Use these to adjust refill rates, bucket sizes, and escalate to WAF/rate-based blocking.

Example rule set

• Authenticated: 1000 req/min, bucket 200
• Unauthenticated: 60 req/min, bucket 20
• Global cap: 50k req/min; if exceeded, tighten per-user rates automatically.

This layered, observable approach balances UX and resilience against scraping and slow DDoS while giving actionable telemetry to iterate thresholds.