DFIR (Forensics & Incident Response) interview questions

No. Antivirus is one signal, not proof. It misses fileless and in-memory attacks, brand-new or obfuscated samples, living-off-the-land abuse of legitimate tools, and rootkits built to hide from it. Absence of evidence is not evidence of absence — real assurance comes from EDR telemetry, memory forensics, behavioral analysis, and IOC hunting. Treating a clean AV scan as proof of a clean system is a classic incident-response mistake.

Not by itself. Many systems keep existing sessions and previously issued tokens valid after a password change — OAuth refresh tokens, 'app passwords', API keys, and persistent cookies — so an attacker with a live session can stay in. The correct response is to change the password AND invalidate all sessions and tokens, revoke app credentials, and audit MFA devices and recovery settings. Assuming a password reset alone evicts the attacker is a classic incident-response mistake.

No. Most real intrusions establish persistence (services, scheduled tasks, run keys, implants) that survives a reboot, so the attacker simply returns. Worse, powering off wipes volatile evidence — running processes, network connections, in-memory malware, and encryption keys — that you need to scope the incident. The right move is to contain by isolating the host while preserving memory, then investigate. Rebooting or shutting down as a 'fix' is a damaging instinct.

Reliable incident reconstruction comes from correlating independent telemetry into one timeline: auth logs, EDR process/exec data, filesystem MAC timestamps, network flows and SIEM events, so you can order actions and bound the scope. A single log or the latest event alone misses the chain and can be misleading or tampered with. Guessing from one source or asking the attacker are not investigative methods. Correlation across independent sources is what reveals the full attacker activity and survives an attacker who edited one of them.

Evidentiary integrity rests on hashing the image at acquisition (e.g., SHA-256) and verifying the hash later to prove it's unaltered, maintaining a documented chain of custody, and analyzing a working copy so the original stays pristine. Renaming the file does nothing for integrity, and compressing it to save space neither proves integrity nor helps admissibility. Touching the original risks spoliation that can get the evidence thrown out. Hash, document custody, and work on a verified copy.

A gap in local logs during an incident can mean cleared or tampered logs, a common anti-forensics step, so don't treat absence of logs as absence of activity. Cross-check against centralized/forwarded logs, EDR and network data that the attacker likely couldn't alter, and record the integrity gap as a finding. Assuming the server was idle trusts evidence the attacker may control, treating the gap as proof nothing happened is exactly the conclusion they want, and deleting more logs destroys what's left. Corroborate with independent telemetry instead.

Backups are necessary but not sufficient: disaster recovery and business continuity are the tested capability to restore operations within agreed recovery time and recovery point objectives (RTO/RPO), which requires a documented plan, mapped dependencies, runbooks, and validated restores — not just the existence of backup files. Agreeing they're the same conflates a data copy with an operational capability. DR isn't merely buying insurance, which transfers financial loss but doesn't restore systems. And backups don't make a DR plan unnecessary — untested backups routinely fail when they're finally needed. The clarification: DR must be exercised, not assumed.

Linux persistence hides in scheduled execution and startup paths: cron and systemd timers/units, added SSH authorized_keys, modified shell rc files and profile scripts, and trojanized service binaries or preloaded libraries. Check those systematically. Browser history and wallpaper settings aren't persistence mechanisms, and rebooting won't remove anything that re-establishes itself on boot — it just restarts it. The whole point of persistence is to survive reboots, so a reboot proves nothing.

Detonate only in a disposable, isolated VM with snapshots and a controlled network (e.g., simulated services or tightly monitored egress) so the malware can't reach production or the internet uncontrolled. AV on your laptop won't reliably contain live malware. A production server risks real systems. A colleague's machine just moves the danger. Isolation and revertable snapshots are the core of a safe malware lab.

Family identification drives decisions: from the note, extension, and IOCs you can flag whether a free decryptor exists, the group's typical TTPs (including data theft for extortion), and the likely blast radius, feeding the IR team. Reformatting destroys evidence and scope information. Note grammar isn't actionable. Recommending negotiation is a business and legal decision, not the analyst's first move. Identify first, then enable IR.

Malware commonly checks for VM/sandbox artifacts, short run times, or user interaction and stays dormant when it sees them. Disguise and harden the analysis VM, lengthen execution, or move to bare metal, and pull behavior from a memory image of the live host. Assuming it's broken or that the host was wrong ignores a sample proven malicious in the wild. A reboot changes nothing because the evasion logic still fires every run.

Begin with static triage in an isolated environment: compute hashes, pull strings, inspect PE headers and imports, and check reputation, so you understand the sample before risking execution. Running it on your own workstation can infect you and the network. Uploading client samples with identifying names leaks sensitive data to third parties. Deleting it destroys the evidence and the chance to build detections.

Word spawning a child process right after macros were enabled is a classic malicious-document initial-access pattern. Isolate the host to limit spread, capture volatile evidence, and investigate the spawned process, its network activity, and any persistence. Asking the user to close the file or repairing Office doesn't address an executing payload that may already have run. Doing nothing because the file came by email is backwards — email is exactly how this attack is delivered. Contain first, then investigate.

Legitimate software rarely runs PowerShell out of %TEMP% via a freshly created scheduled task — it's a common persistence and execution technique. Examine the task definition, the invoked script, the creating process and the timeline, contain the host, and sweep the environment for the same pattern. Updates don't look like this, blanket-trusting scheduled tasks ignores a known TTP, and deleting System32 breaks the OS while doing nothing about the threat. The first three options all reflect dangerously weak judgment.

Tabletops rehearse the human and decision side of IR — who has authority to declare an incident, how legal/PR/exec communication flows, and where the playbook breaks — so the first time you make those calls isn't during a real crisis. It's far cheaper to find gaps in a drill than mid-breach. They are not a hollow compliance checkbox, they're not for assigning blame for past incidents, and they are cross-functional, not SOC-only — leadership has to practice the decisions only they can make.

A vendor breach is your incident too: invoke incident response to scope which of your data and integrations were exposed, rotate any shared secrets, API keys and SSO trust, evaluate your own regulatory notification duties, and hold the vendor to disclosure. Passively waiting for the vendor cedes control of your own timeline and obligations. A public contract termination is premature theatrics before you even know your exposure. Assuming you're unaffected skips exactly the assessment that regulators and your own customers expect.

Without control-plane audit logs you're blind to who did what at the cloud layer, and detection, forensics, and compliance all depend on that record. Enable CloudTrail immediately, org-wide, delivering to a separate, access-controlled, tamper-resistant (immutable) bucket. Saying it doesn't matter while nothing is wrong ignores that you'd have no history when something does go wrong. Waiting until an incident means the formative early actions are already unlogged and unrecoverable. Application logs don't capture API, IAM, or console activity at the control plane.

Public customer data is an active exposure, so remediate access first: enable Block Public Access and correct the bucket and IAM policy to stop ongoing leakage. Then pull access logs (S3 server access logs / CloudTrail data events) to assess what was actually reached, and trigger breach and notification processes per policy. Ticketing it for next sprint leaves regulated data exposed for days. Copying the data elsewhere creates a second copy but leaves the original bucket open. Renaming changes nothing about its permissions.

Follow the order of volatility. RAM, live network connections and the process table vanish on shutdown, so capture them first, then take a forensic disk image while documenting hashes and an unbroken chain of custody. A clean shutdown destroys memory-resident evidence — including fileless malware and keys that live only in RAM. Copy-then-delete tampers with the scene and breaks integrity. Running the company antivirus mutates the system and may quarantine or delete the very artifact you need to analyze.

Containment beats premature recovery: stop the spread by isolating affected segments and killing the propagation path — disable the abused service account, block SMB between segments, pull the staging host — while preserving evidence, then eradicate and recover. Restoring into a network that's still encrypting just re-loses the restored data. Paying the ransom doesn't stop active encryption and carries legal and sanctions risk. Cutting power to every machine destroys volatile evidence and can corrupt files mid-write, making clean recovery harder.

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.

Discovering an active intrusion is an out-of-band emergency: the rules of engagement should define an escalation path, so invoke it immediately, preserve evidence, and avoid contaminating an active incident. Continuing to test can interfere with the real attacker or destroy the very evidence responders need. Trying to evict the attacker yourself is out of scope, risky, and may tip them off. Waiting until the final report could mean days of ongoing breach and data loss.

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.

Validate before escalating. Corporate VPNs, cloud proxies (like CASB or M365 service IPs) and mobile carriers routinely produce false 'impossible travel,' so check the egress IPs, the MFA result, and the device/user-agent before pulling the trigger. Auto-locking on every hit causes alert fatigue and erodes user trust in the SOC. Assuming it's always a false positive misses real account takeover. Emailing the manager is slow and isn't a security control — the logs answer the question faster and more reliably.

Assume the password is already compromised: force a reset AND invalidate the account's active sessions and tokens, because a reset alone won't evict an attacker who already holds a live session or refresh token. Then hunt for anomalous logins, MFA prompts, mailbox rules and OAuth grants from the exposure window. Deleting the email or telling the user to change it "next time" leaves the account wide open. An antivirus scan addresses malware on the endpoint, not stolen credentials in the cloud.

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.

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.

Traditional antivirus matches files against signatures of known malware and blocks or quarantines them — great for known threats, weak against novel or fileless attacks. EDR continuously records endpoint behavior (processes, network, registry, memory), uses behavioral analytics to detect suspicious activity, and lets responders investigate, hunt, and remotely contain or roll back. AV is prevention by signature; EDR adds visibility, detection, and response.

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.

Persistence is how malware survives reboots and logoffs. The staples on Windows are registry Run/RunOnce keys (HKLM and HKCU), scheduled tasks, and Windows services, plus startup folders, WMI event subscriptions, and DLL hijacks. You hunt them with autoruns/Sysinternals, Sysmon, and event logs — looking for unsigned binaries, odd paths like %AppData%, and entries created right after initial compromise.

Order of volatility ranks evidence by how fast it vanishes, so you collect the most fragile first. Roughly: CPU registers/cache, then RAM and running state (processes, network connections, ARP), then temporary/swap files, then disk, then remote logging and monitoring data, and finally archival media and backups. You also work on forensic copies, hash them, and keep a chain of custody so evidence stays admissible.

Process injection runs attacker code inside the memory space of a legitimate process so the activity blends in and inherits that process's trust. Classic techniques include DLL injection (CreateRemoteThread + LoadLibrary), process hollowing (start a benign process suspended, unmap it, write malicious code), and APC injection. Defenders detect it via EDR API hooks, anomalous parent/child or memory regions (RWX, unbacked executable memory), and Sysmon CreateRemoteThread events.

Ransomware is malware that encrypts (and increasingly exfiltrates) data, then demands payment. In an active case: isolate affected hosts from the network without powering them off if you can preserve memory, identify scope, patient zero, and the strain, preserve evidence, find and evict the foothold and any backdoors, then restore from known-clean offline backups. Paying is a last resort and never guarantees recovery.

Static analysis examines a sample without executing it — hashes, strings, imports, headers, and disassembly — so it is safe and complete in coverage but defeated by packing and obfuscation. Dynamic analysis detonates the sample in an isolated sandbox and observes real behavior — files, registry, processes, network — which cuts through obfuscation but only reveals what runs in that session and can be evaded by sandbox-aware malware. Analysts combine both.

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.

The Security log is primary: 4624 successful logon (with logon type), 4625 failed logon, 4634/4647 logoff, 4672 special privileges assigned, 4720 account created, 4688 process creation (with command line if enabled), and 4768/4769 Kerberos. Add 7045 service install (System log), 4698 scheduled task created, and PowerShell script-block logging (4104). Logon type and command-line auditing are what make these logs useful.

Business continuity (BCP) is the broad strategy to keep critical business functions operating during and after a disruption; disaster recovery (DRP) is the IT-focused subset that restores systems and data. RTO is the maximum tolerable time to restore a function; RPO is the maximum tolerable data loss measured in time.

Quantitative analysis assigns hard monetary values so you can compute expected loss; qualitative analysis ranks risk on relative scales (high/medium/low) using expert judgment. Quantitative uses SLE = asset value x exposure factor, ARO = expected occurrences per year, and ALE = SLE x ARO to express annual expected loss in dollars.

Because 'delete' normally does not erase the data. It removes the filesystem metadata — the pointer/directory entry — and marks the blocks as free, but the original bytes stay on disk until the OS happens to reuse those blocks for new data. Until that overwrite occurs, forensic tools can carve the content straight back out.

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.

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.

You classify by what the sample is built to do, observed from its behavior and capabilities. A dropper carries and writes a payload to disk; a loader fetches or injects the next stage, often only in memory; a RAT gives an operator interactive remote control; a wiper destroys data or boot records with no recovery intent; ransomware encrypts files and demands payment. Real samples often combine roles — a loader that deploys a RAT — so you describe the capability chain rather than forcing one label, and you map each behavior to ATT&CK techniques.

Command-and-control beaconing is the implant periodically calling home for instructions. You recognize it by regular, low-volume outbound callbacks at a roughly fixed interval — often with jitter to avoid looking mechanical — to a small set of destinations, frequently over HTTP/HTTPS or DNS with encoded or encrypted payloads and a distinctive User-Agent or URI pattern. You extract indicators statically by pulling domains, IPs, URIs and keys from strings and config blocks, and dynamically by detonating the sample against a faked network and capturing the actual callbacks, then map the behavior to ATT&CK and feed the IOCs into detection.

A safe lab isolates the malware from anything it could harm. You run samples in disposable VMs on a hypervisor, take clean snapshots so you can revert after each detonation, and cut off real network access using a host-only network with a simulated internet (INetSim or FakeNet) or an air-gapped segment. You separate the analysis machine from a controlled gateway, never analyze on your daily-driver host, harden against VM-escape, handle samples as password-protected zips, and keep tooling and indicators off the detonation VM. The goal is to observe real behavior while guaranteeing the sample cannot reach production or the internet.

Sandbox-aware malware checks whether it is being watched before it misbehaves. It looks for VM and hypervisor artifacts (drivers, MAC prefixes, registry keys, CPUID), analysis tools and debuggers (process names, IsDebuggerPresent, timing of single-stepping), and signs of a real user (few processes, no recent documents, no mouse movement, low uptime, small disk). It may stall with long sleeps or only fire on a specific date, language, or domain. Analysts counter by hardening the VM to look real, patching out the checks, fast-forwarding sleeps, simulating user activity, and confirming behavior with static disassembly.

Static tooling reads the sample at rest: PEStudio, CFF Explorer and pefile for headers and imports, FLOSS and strings for embedded text, capa for capability mapping, and Ghidra or IDA for disassembly. Dynamic tooling watches it run inside an isolated VM: Procmon and Process Hacker for host activity, Wireshark and INetSim or FakeNet for faked network, Regshot for before/after diffs, and x64dbg for controlled stepping. The workflow is triage statically, detonate dynamically, then return to the disassembler to fill behavioral gaps.

DFIR follows a disciplined process: identification (confirm and scope the incident), acquisition (preserve evidence following order of volatility, with forensic images and hashes), analysis (timeline, root cause, scope of compromise), and reporting (findings for technical and legal audiences). Chain of custody documents who handled each artifact and when, so the evidence holds up if it ever reaches court. Preserve before you remediate.

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 good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.

A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.

Alert fatigue is the desensitization that sets in when analysts face too many low-value or false-positive alerts, causing them to miss or rush real ones. You fight it by tuning noisy rules, prioritizing by risk, deduplicating and grouping related alerts, automating repetitive enrichment with SOAR, and measuring alert quality, not just volume.

Brute force targets a single account with many password guesses, so you see many failures concentrated on one username. Password spray flips it: one or a few common passwords tried across many accounts, low and slow, so each account sees only a couple of failures. The detection signal is the ratio of accounts to failures and the timing, not raw failure counts.

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.

EDR is endpoint-focused: it records and responds to process, file, and network activity on hosts. XDR extends that correlation across multiple domains — endpoint, network, identity, email, cloud — as one vendor-integrated stack. SIEM is the broad log-aggregation layer that ingests data from anything, including non-security sources, for detection, search, and compliance.

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.

Lateral movement is an attacker using a foothold to reach other systems. Signs include unexpected network logons (type 3) and RDP (type 10), access to admin shares like C$ and ADMIN$, remote-execution tools such as PsExec, WMI, and WinRM, pass-the-hash patterns, and a normally local account suddenly authenticating to many hosts.

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.

4624 is a successful logon, 4625 is a failed logon, and 4688 is a process creation. In an investigation you use 4625 to spot credential attacks, 4624 (with its logon type and source) to confirm a successful access and how it happened, and 4688 to see what was actually executed, ideally with command-line auditing enabled.