MITRE ATTACK Framework Questions

Comprehensive knowledge of the MITRE ATTACK knowledge base, including the matrix of adversary tactics, techniques, and sub techniques. Candidates should understand the full lifecycle of adversary behavior such as reconnaissance, resource development, initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact. Skills assessed include mapping real world incidents to ATTACK techniques and technique identifiers, profiling adversary types and campaigns, using ATTACK to design realistic penetration tests and red team exercises, and planning purple team and threat hunting activities. Also important is the ability to translate ATTACK mappings into detection hypotheses and telemetry requirements, recommend mitigations and compensating controls, and communicate findings to technical and non technical stakeholders for incident response and security engineering improvements.

HardSystem Design

18 practiced

For an organization adopting Kubernetes and microservices, design an ATT&CK-based detection strategy focused on container escape and lateral movement inside the cluster. Identify required telemetry (container runtime events, kube-audit, node logs, network flows), example detection rules, and network or RBAC controls that limit attacker movement.

Sample Answer

**Approach (brief)** Design detections mapped to MITRE ATT&CK techniques for container escape (e.g., TESC: Escape to host) and lateral movement (e.g., Lateral Movement via kubectl, API abuse). Combine host/container runtime, kube-audit, node logs, and network flow telemetry; enforce network/RBAC controls to reduce blast radius.

**Required telemetry**- Container runtime events: process execs, new privileges, filesystem mounts, container start/stop, capabilities changes (Falco, Docker/CRI-O events). - Kube-audit: all API server requests, impersonation, exec/attach events, pod creation with hostPath/hostNetwork/privileged. - Node logs: syscalls denied, kernel messages (dmesg), SSH/cron/cronlogs, kubelet logs. - Network flows: Cilium/Calico flows, service-to-service connections, pod-to-node, DNS queries.

**Example detection rules**- Falco (container escape indicator):

yaml

# falco rule
- rule: Privileged Container Changed / HostPath Mounted
  desc: Detect containers with privileged flag or hostPath mounts
  condition: container.privileged=true or container.mounts.path startswith /host
  output: Privileged/HostPath mount in container (user=%user.name container=%container.name)
  priority: CRITICAL

- SIEM/KQL (kube-audit):

kql

KubeAudit
| where verb in ("exec","attach") and (requestObject.spec.containers[*].securityContext.privileged == true or requestObject.spec.volumes[*].hostPath != "")
| extend user = user.username, pod = requestObject.metadata.name

- Network flow anomaly (NetFlow): - Alert when pod makes outbound connections to >50 unique IPs in 10m or to internal node SSH ports.

**Network & RBAC controls**- NetworkPolicy: default deny ingress/egress; explicit service whitelists; isolate namespaces; restrict hostNetwork=true usage.- CNI-level egress controls + eBPF policy enforcement to block lateral SSH/RDP and limit pod-to-node access.- RBAC: least privilege for service accounts, deny wildcard verbs in ClusterRoleBindings, require OPA/Gatekeeper admission to prevent hostPath/privileged/hostPID usage.- Pod Security Admission: enforce baseline/restricted profiles.

**Detection playbook / investigation steps**- On alert, collect: pod manifest, kube-audit trail for user/serviceAccount, container process tree (ps + pcap if available), node syslogs, network flows in window. Quarantine pod via NetworkPolicy and scale down service account tokens.

**Trade-offs**- High-fidelity vs noise: prioritize rules that combine multiple signals (audit + runtime + network) to reduce false positives. Use enrichment (image vulnerability, SA policies) to prioritize response.

This strategy gives layered telemetry, concrete detections, and controls to limit attacker movement inside the cluster.

MediumTechnical

17 practiced

Design an EDR-based detection for persistence created via WMI Event Subscriptions. Specify the telemetry fields you need to capture (WMI object names, command-lines, creators), a detection algorithm or rule, likely false positives, and investigation/remediation steps after detection.

Sample Answer

**Approach summary**I would build an EDR detection combining enriched WMI telemetry, behavioral rules, and contextual risk scoring to surface malicious WMI Event Subscription persistence.

**Telemetry to capture**- WMI class/object names (e.g., __EventFilter, __FilterToConsumerBinding, CommandLineEventConsumer, ActiveScriptEventConsumer)- Full command-lines and script contents (base64 or decoded) for consumers- Creator/owner (process, user, service) and process parent tree (PID, parent PID, executable path, signer)- Creation/modification timestamps and host metadata (OS, domain)- Registry/ADS access tied to WMI changes and remote DCOM calls- Network connections from consumer-creator processes

**Detection algorithm / rule**- If a new __EventFilter or FilterToConsumerBinding is created AND the bound consumer is CommandLineEventConsumer or ActiveScriptEventConsumer AND the creating process is unsigned or running from user-writable path OR parent is suspicious (e.g., PowerShell, mshta, wscript) → score high.- Heuristics: uncommon filter names, encoded scripts in consumer, filters referencing system events rarely used, remote creator host != endpoint.- Enrich with threat intel for known malicious script hashes and correlate with privilege escalation events.

**Likely false positives**- Legitimate admin automation (SCCM, monitoring agents) creating WMI subscriptions- Backups or management tools using scripted consumersMitigation: maintain allowlist of known management binaries, verify code signing and company-approved paths.

**Investigation steps**1. Query EDR for the subscription object, consumer script content, and creator process tree.2. Retrieve timeline: who created it, from which host, and when; check for lateral movement indicators.3. Validate against allowlist and test-run script in sandbox for behavior.4. Hunt for related artifacts: scheduled tasks, autoruns, suspicious registry keys, network IOCs.

**Remediation**- Isolate affected host(s).- Export and preserve WMI objects for forensics; remove malicious __Filter, Consumer, and Binding via WMIC/PowerShell (Remove-WmiObject or Cim cmdlets).- Kill and remediate creating process; remove dropped files; rotate credentials if compromised.- Patch endpoint, update detections, add allowlist entries for legitimate automation, and document lessons learned.

HardTechnical

22 practiced

Design cross-platform detection strategies for credential dumping: target LSASS memory access on Windows, keychain extraction on macOS, and access to /etc/passwd or /etc/shadow on Linux. For each OS list telemetry sources, detection heuristics, likely evasion techniques, and compensating controls to reduce risk.

Sample Answer

**Overview**I would build OS-specific detection playbooks covering telemetry, heuristics, evasion tactics, and compensating controls so alerts are actionable and triageable.

**Windows — LSASS memory access**- Telemetry: EDR process injection/ReadProcessMemory events, Windows Audit Process Access (4663 with Object Type Process), Sysmon ProcessAccess events, kernel callbacks, NTLM/kerberos auth anomalies, process command lines, minidump creation.- Heuristics: Unexpected process opening lsass.exe with PROCESS_VM_READ or PROCESS_QUERY_INFORMATION; rundll32/cmd/powershell reading LSASS; creation of lsass.dmp, procdump, or suspicious .dmp written to non-admin paths; credential API hooks.- Evasion: Direct kernel drivers, DSE/KPTI bypass, live memory scraping via signed-msft tools, process hollowing, timestomping.- Controls: Enable LSA protection (RunAsPPL), Credential Guard, EDR with kernel sensors, restrict Debug Programs/SeDebugPrivilege via GPO, monitor and block Procdump/Dbg tools, MFA + rotate credentials.

**macOS — Keychain extraction**- Telemetry: Endpoint logs (process exec), Apple System Logs, endpoint filesystem access to ~/Library/Keychains, keychaind IPC, authd prompts, TCC privacy access events, EDR macOS telemetry.- Heuristics: Processes accessing keychain items without UI prompt or by bypassing SecItemCopyMatching; unsigned binaries calling Security APIs; abnormal access from browser helper or background agents; mass export of keychain files.- Evasion: Exploiting user approval dialogs, using Apple-signed binaries, using keychain access via Safari/Chrome tokens, kernel extensions.- Controls: Enforce keychain ACLs, restrict sudo/use of admin accounts, enable System Integrity Protection (SIP), notarization checks, EDR macOS behavioral blocks, require user prompts for keychain access.

**Linux — /etc/passwd and /etc/shadow access**- Telemetry: Auditd syscall logs (open/read), kernel LSM hooks, process exec, file integrity monitoring, sudo/su logs, PAM logs, EDR agent telemetry.- Heuristics: Non-root processes reading /etc/shadow, sudden cat/rsync/tar of /etc, suspicious use of unprivileged escalation tools, unexpected cron/jobs reading passwd/shadow, processes spawning shell from unusual locations.- Evasion: Copying to memory-only tools, mounting shadow via compromised container, kernel rootkit hiding reads, abusing sudoers misconfigurations.- Controls: Strict file permissions, auditd rules for /etc/shadow reads, restrict sudo to necessary commands, PAM hardening, implement 2FA for privileged access, host-based IDS, immutable files where feasible.

**Operational notes**- Prioritize low-noise, high-fidelity rules (combine process context + file access + parent/child chain).- Build playbooks: triage steps, required artifacts, containment (kill process, rotate credentials, revoke tokens), and post-incident hardening.- Test detections regularly via red-team / purple-team to tune for evasions.

MediumTechnical

24 practiced

Given ATT&CK technique 'Bypass User Account Control' (T1548.002) is frequently observed in your environment, propose technical mitigations, compensating controls, and detection strategies to reduce risk. Explain trade-offs and possible operational impacts of your recommendations.

EasyTechnical

20 practiced

List the standard ATT&CK tactic names in the typical adversary lifecycle order, from reconnaissance through impact, and provide one example technique for each tactic. Briefly explain why that technique fits the named tactic.

Sample Answer

**Answer (InfoSec Analyst perspective)**

**Reconnaissance** — Example: Active Scanning (T1595). Why: Attackers gather target IPs/services by scanning; as an analyst I monitor scanning signatures in network logs.

**Resource Development** — Example: Acquire Infrastructure (T1583). Why: Adversaries purchase domains/C2 infrastructure before attacks; tracking new suspicious domains helps detection.

**Initial Access** — Example: Phishing (T1566). Why: Phishing delivers credentials or malware to gain entry; email gateways and user-reporting are primary defenses I manage.

**Execution** — Example: Command-Line Interface (T1059). Why: Running commands executes payloads or scripts; process and command-logging are crucial for incident triage.

**Persistence** — Example: Create Account (T1136). Why: New accounts allow long-term access; account provisioning anomalies are high-priority alerts.

**Privilege Escalation** — Example: Exploitation for Privilege Escalation (T1068). Why: Exploiting vulnerabilities to gain higher privileges; patching and EDR block these attempts.

**Defense Evasion** — Example: Obfuscated Files or Information (T1027). Why: Obfuscation hides malicious code from detection; I look for decoding behavior and unusual process activity.

**Credential Access** — Example: Brute Force (T1110). Why: Repeated auth attempts aim to obtain valid credentials; monitoring failed logins and rate limits mitigates risk.

**Discovery** — Example: Network Service Scanning (T1046). Why: Identifies reachable services for lateral moves; network flow and scanning detection help block reconnaissance.

**Lateral Movement** — Example: Remote Services (T1021). Why: Using RDP/SMB to move across hosts; I monitor remote session anomalies and block unauthorized access.

**Collection** — Example: Data from Local System (T1005). Why: Gathering files before exfiltration; DLP and file access alerts detect mass collection.

**Command and Control** — Example: Web Protocols (T1071). Why: C2 over HTTP(S) blends with normal traffic; proxy logs and TLS inspection reveal suspicious C2 patterns.

**Exfiltration** — Example: Exfiltration Over Web Service (T1567). Why: Using cloud/web services to move data out; monitoring outbound transfers and unusual endpoints is essential.

**Impact** — Example: Data Encrypted for Impact (Ransomware) (T1486). Why: Encrypting files disrupts operations and demands payment; detection focuses on rapid file modifications and backup integrity.

Unlock Full Question Bank

Get access to hundreds of MITRE ATTACK Framework interview questions and detailed answers.

Join thousands of developers preparing for their dream job.