Threat Intelligence interview questions

No. MFA raises the bar a lot, but OTP and push factors are phishable: adversary-in-the-middle kits (e.g. Evilginx) proxy the login and relay the code in real time, and MFA-fatigue/push-bombing tricks users into approving. Captured codes are reusable within their short window. The misconception is 'MFA = unphishable'; the factor type is what matters. Phishing-resistant MFA — FIDO2/WebAuthn passkeys bound to the site's origin — is what actually defeats this.

Urgency, authority, and skipping verification are textbook social-engineering pressure aimed at a high-value account. The agent must follow the defined identity-verification process before resetting anything, and escalate if it can't be satisfied. Resetting on demand, using a guessable 'security question' like a favorite color, or emailing the new password to the caller all hand an attacker control of the executive's account.

The SOC needs to act, so deliver structured, actionable detection content: network IOCs, hashes, host artifacts like the mutex, and behavioral or YARA signatures they can deploy to hunt and block. An exhaustive API narrative isn't directly operational. A single hash is trivially changed by attackers. Speculative attribution isn't something the SOC can defend with. The goal is detections the SOC can ship today.

A 30% click rate is a baseline to improve, not a list of people to punish: pair role-based training and a frictionless report button with technical defenses (MFA, email filtering, least privilege) so a single click doesn't lead to compromise, and track the trend over time. Publicly shaming employees suppresses the reporting you depend on. Declaring the workforce hopeless removes a control you should be strengthening. Another scary all-staff email isn't a measurable intervention and doesn't change behavior.

Security spend should follow risk, not hype: use a risk assessment to direct money where business impact and likelihood are highest and current control coverage is weakest, then measure the reduction you achieve. Buying whatever the popular vendor sells ignores your actual threat profile and often funds shelfware. Spreading the budget evenly underfunds the few areas that matter most. Copying competitors assumes their risk profile equals yours, which it rarely does.

Eradicating before you understand scope lets the attacker persist on systems you haven't found and simply return. Quickly hunt the IOCs and stolen credentials across the estate, identify every affected host and persistence mechanism, then eradicate everywhere at once. Wiping one host is whack-a-mole that tips off the attacker while leaving their other footholds intact. A week-long full internet blackout is disproportionate and harms the business. Deleting just the malware file ignores persistence, lateral movement, and the credentials already stolen.

Cut false positives through detection engineering, not by blinding yourself. Re-tune so alerts fire only on patterns that matter — many accounts hit with one password (spraying), one account hit many times (stuffing/brute force), impossible travel — while keeping the raw failed-login events searchable on a dashboard. Then measure alert precision over time. Disabling the rule removes a real signal, blanket suppression creates a permanent blind spot, and hiring people to triage pure noise doesn't scale and burns them out.

High-volume, high-entropy TXT or long-subdomain queries to a single domain is a classic DNS tunneling / C2-and-exfil signature: data is being smuggled inside DNS to evade egress filtering. Capture a query sample for analysis, sinkhole or block the domain to cut the channel, and pivot to the host to find the responsible process. Dismissing it as normal caching or a slow website misses live exfiltration. Restarting the DNS server does nothing about the compromised endpoint and just disrupts name resolution.

Triage by impact and reachability: credential dumping (a mimikatz signature) on a domain controller is a crown-jewel event that can lead to full domain compromise, so work it first. The external port scan was already blocked by the IDS, the unapproved browser extension is low severity, and an expired TLS cert on an internal test box is informational. The core SOC skill is prioritizing by blast radius and likelihood of escalation, not by alert age or how loud the alert is.

AI helps the SOC by triaging and de-duplicating alerts, summarizing incidents, enriching context, drafting detections, and accelerating analyst onboarding — reducing fatigue and dwell time. The risks: hallucinated or confidently wrong conclusions, automation bias where analysts stop verifying, prompt injection through attacker-controlled log or alert data, sensitive data leaking into third-party models, and adversaries using the same tools. Keep a human in the loop, verify outputs, and isolate untrusted inputs.

Credential stuffing replays known username:password pairs from third-party breaches, betting on password reuse — high success rate per attempt, often distributed across many IPs and devices to look human. Password spraying tries one or two common passwords (like Winter2026!) across many accounts to stay under lockout thresholds. Stuffing exploits reuse; spraying exploits weak shared passwords. MFA defeats both.

The Cyber Kill Chain models an intrusion as seven sequential stages: reconnaissance, weaponization, delivery, exploitation, installation, command and control (C2), and actions on objectives. Defenders map detections and controls to each stage; because the stages are sequential, breaking any single link — blocking the phishing email, killing C2 — disrupts the whole attack. It pushes you to detect early rather than only at the final breach.

DNS exfiltration encodes stolen data into DNS queries (e.g. long subdomain labels sent to an attacker-controlled authoritative server), abusing the fact that DNS is almost always allowed outbound and often unmonitored. Detect it with anomalies: unusually high query volume to one domain, long/high-entropy subdomains, many unique subdomains per parent domain, TXT/NULL record abuse, and queries to newly registered or rare domains.

The classic model is PICERL: Preparation, Identification (detection), Containment, Eradication, Recovery, and Lessons Learned. NIST groups it as Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. The order matters because you must scope and contain before you eradicate, and you only recover once the threat is removed — otherwise you reinfect. It is a loop, not a line: lessons learned feed back into preparation.

An IOC is a forensic artifact that something bad already happened — a malicious file hash, a C2 IP or domain, a known-bad registry key. An IOA is a behavioral signal of an attack unfolding regardless of the specific tools — e.g. a Word document spawning PowerShell, then reaching out to the internet. IOCs are reactive and easy to evade by changing a hash; IOAs catch intent and survive tool changes.

A honeypot is a decoy system or service with no legitimate business use, deliberately exposed to attract attackers. Because nothing benign should ever touch it, any interaction is a high-confidence alert. Low-interaction honeypots emulate services cheaply; high-interaction ones are real systems that yield richer intel but carry more risk. Honeytokens are the same idea applied to fake credentials, files, or records. Value: early detection, low false positives, and threat intelligence.

An IDS (intrusion detection system) monitors traffic and raises alerts but does not block — it's typically out-of-band. An IPS (intrusion prevention system) sits inline in the traffic path and can actively drop or block malicious traffic. IPS prevents, but a false positive can break legitimate traffic.

Phishing is social engineering that tricks people into revealing credentials, sending money, or running malware, usually via fake emails or sites. Defense is layered: email filtering and authentication (SPF/DKIM/DMARC), MFA to limit stolen-credential damage, user awareness training, and an easy way to report suspicious messages.

A vulnerability is a weakness (unpatched software). A threat is an actor or event that could exploit it (a ransomware group). Risk is the combination of likelihood that a threat exploits a vulnerability and the impact if it does. Risk = threat x vulnerability x impact, and it's what you actually prioritize.

A zero-day is a vulnerability the vendor doesn't yet know about (or hasn't patched), so defenders have had 'zero days' to fix it. Since no patch exists, defense relies on layered controls, behavior-based detection, segmentation, least privilege, and fast incident response rather than a signature.

Generally a false negative is worse from a pure security standpoint: it means a real attack went undetected, so there is no response, no containment, and the breach can dwell undiscovered. But false positives are not harmless — high volumes cause alert fatigue, where analysts start ignoring alerts and miss the real one. The right answer names the trade-off, not just a winner.

A baseline is a model of normal behaviour for a host, user, account, or network segment — what processes run, who logs in from where and when, typical data volumes, normal beaconing intervals. Once you know normal, anomalies (rare parent-child process pairs, first-seen binaries, logons at odd hours, unusual data egress) become detectable as deviations. Baselining is the foundation of anomaly detection, but it requires enough clean history and careful handling of legitimate change so you do not drown in false positives.

C2 beaconing is the periodic check-in an implant makes to its controller. Hunt for it in network/proxy/DNS telemetry by looking for regularity: connections to a destination at near-fixed intervals (even with jitter), small uniform request sizes, low data-in/data-out ratios, long-lived rare destinations, and suspicious TLS/JA3 fingerprints or odd user-agents. The signal is the rhythm and the rarity of the destination, not the payload — which is usually encrypted.

Start from the techniques you want to detect, then work backwards to the telemetry that reveals them — ATT&CK's data sources mapping helps. In practice the highest-value sources are endpoint process/command-line and module-load telemetry (EDR/Sysmon), authentication and identity logs, DNS and proxy/network flow, and cloud control-plane logs. You then audit what you actually collect and retain versus what each technique needs, exposing visibility gaps. A technique you cannot see in any log is not huntable yet.

Detection engineering treats detections as a software product with a lifecycle: identify a threat or technique to cover, research the telemetry and behaviour, develop the rule, test it against true-positive and benign data, deploy it (often staged), validate with adversary emulation, then continuously tune for false positives and retire rules that no longer earn their keep. Each stage is documented and version-controlled, and coverage is tracked against a framework like ATT&CK.

LOLBins (living-off-the-land binaries) are legitimate, signed, pre-installed system tools — like certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — that attackers abuse to download, execute, or persist while blending in with normal admin activity. Because the binary itself is trusted, you cannot detect on the file; you detect on context: anomalous command-line arguments, unusual parent processes, unexpected network connections from these tools, and execution from odd paths or by odd users.

The Pyramid of Pain ranks indicator types by how costly it is for an attacker to change them once you detect on them. Hashes are trivial to alter (bottom), then IP addresses, domain names, network/host artifacts, tools, and finally TTPs at the top — which an attacker can only change by fundamentally re-tooling their behaviour. Detecting on higher levels causes more 'pain' and is more durable, so mature programs invest detection effort toward behaviours and TTPs rather than just IOCs.

TTP-based hunting uses MITRE ATT&CK as the map: pick a technique relevant to your threat model (ideally one with weak coverage), form a concrete hypothesis about how it would appear in your telemetry, identify the data sources that reveal it, query for it, and analyze hits. A good hunt is scoped, hypothesis-driven, tied to a real adversary behaviour, repeatable, and produces a durable output — a new detection, a documented coverage gap, or evidence the technique is absent — regardless of whether it finds a compromise.

UEBA (User and Entity Behaviour Analytics) builds behavioural baselines for users and entities (hosts, service accounts, devices) and uses statistics or machine learning to score deviations as risk. It excels at threats that have no clean signature: compromised credentials, insider misuse, and lateral movement — e.g. a user suddenly accessing systems they never touch, at unusual hours, or moving abnormal data volumes. It complements rule-based detection rather than replacing it, and needs tuning to avoid false positives from legitimate behaviour change.

Threat hunting is the proactive, hypothesis-driven practice of searching telemetry for adversary activity that existing detections missed. Unlike alert triage — which is reactive and waits for a tool to fire — hunting starts from a question ('if an attacker did X, what evidence would I see?'), tests it against data, and either finds something or produces a new detection. It assumes prevention and alerting are imperfect and that a determined adversary may already be inside.

Sigma is an open, vendor-neutral YAML format for describing SIEM detections. You define a logsource (product/category, e.g. Windows process_creation), a detection block with named selections of field/value matches, and a condition that combines them. A converter (like sigma-cli/pySigma) translates the rule into the query language of your actual backend — Splunk, Sentinel, Elastic — so one rule is portable. It also carries metadata: title, level, status, false positives, and ATT&CK tags.

A YARA rule has a meta block, a strings section (text, hex, or regex patterns, including wildcards and jumps), and a condition that combines those matches with boolean and count logic. An effective rule keys on something durable and distinctive — a unique code stub, a mutex name, a config marker, or an unusual import combination — rather than on values an attacker trivially changes like a single hash or a generic string. You balance specificity against false positives, test against a clean corpus, and document the rule so others trust and maintain it.

Coordinated vulnerability disclosure is a process where a researcher reports a flaw privately to the vendor, both sides agree on remediation and a timeline, and details are published only after a fix is available (or an agreed deadline lapses). It balances giving defenders time to patch against the public's right to know. A security.txt file and a clear policy make reporting frictionless; bug bounty programs add structured rewards on top.

ATT&CK is a knowledge base of real adversary tactics (the why), techniques (the how), and procedures. You use it to map your existing detections onto the matrix, identify coverage gaps, and prioritize the techniques used by threat actors that actually target your sector. It gives a common language across CTI, detection engineering, and IR, turning 'are we secure?' into a concrete, measurable coverage map driven by real-world adversary behavior.

Purple teaming is collaborative rather than adversarial: the red side executes specific, agreed TTPs (often mapped to MITRE ATT&CK) while the blue side watches their telemetry in real time to confirm whether each technique is logged, alerted, and detectable. You measure detection coverage technique-by-technique, tune detections and close gaps immediately, then re-test. The deliverable is improved, measurable detection — not a list of who 'won.'

A pentest aims for broad coverage — find as many vulnerabilities as possible in a scoped target. A red team is objective-driven adversary emulation: pick a goal (e.g., reach the crown-jewel data), emulate a specific threat actor's TTPs, stay stealthy to test detection and response, and avoid noisy scanning. Red teaming measures the blue team and the whole org, not just the asset; both need tight rules of engagement and authorization.

A risk assessment identifies assets and their value, the threats and vulnerabilities that could affect them, then estimates risk as a function of likelihood and impact. You can do it qualitatively (high/medium/low, fast and subjective) or quantitatively (SLE × ARO = ALE, data-driven but harder). Frameworks like NIST RMF and ISO 27005 give it structure, and the output feeds risk treatment: mitigate, transfer, avoid, or accept.

Passive reconnaissance gathers information without directly interacting with the target's systems — OSINT, DNS records, certificate transparency. Active reconnaissance touches the target, like port scanning or banner grabbing, which is noisier but yields more detail.

Almost everything touches DNS, so DNS logs reveal threats other sources miss: command-and-control beaconing (regular callbacks to a domain), DNS tunneling and exfiltration (high volume of long, encoded subdomains), and algorithmically generated (DGA) domains. You detect these through patterns like query regularity, entropy, record types, and volume rather than single bad lookups.

First understand why the rule is firing so much — find the common benign pattern behind the noise. Then write the narrowest possible exclusion (specific host, account, or behavior), document the rationale, and validate that a true positive would still fire. Avoid broad suppressions that quietly create blind spots.

ATT&CK is a knowledge base of real-world adversary tactics and techniques. In a SOC you map each detection rule to the techniques it covers, build a coverage map (often with the ATT&CK Navigator), then prioritize closing gaps based on which techniques are most relevant to your threat model and which you have no visibility into.

Examine the email safely without clicking: check the headers and sender authentication (SPF/DKIM/DMARC), inspect URLs and attachments in a sandbox or with reputation tools, then scope it — who else received it, did anyone click or enter credentials. Based on findings, remediate by purging the email, blocking indicators, and resetting any exposed credentials.

A SIEM ingests and correlates logs from across the estate to generate alerts — it is your detection and search layer. A SOAR sits downstream and automates the response: it runs playbooks, enriches alerts via integrations, and handles case management so analysts spend less time on repetitive steps.

Confirm the alert is real before acting: read what fired and why, then enrich it — who is the user, is the source IP/geo/device expected, is this impossible travel, were there prior failures? Classify true vs false positive, escalate or contain if real (disable session, force MFA reset), and document everything so the next analyst can follow your reasoning.