Incident Responder 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.

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.

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.

A SUID-root binary executes with root privileges, and if it's world-writable an attacker can replace or modify it to run arbitrary code as root — a classic local privilege-escalation path. Remove the SUID bit, correct ownership and permissions, and investigate how the misconfiguration appeared, since it may indicate compromise. Encrypting the file leaves the executable path intact, and renaming it just moves the problem without removing the escalation. Neither addresses the root cause.

Fileless malware lives in process memory (injection, reflective loading, LOLBins), so acquire and analyze a memory image to find the injected code, suspicious modules, and process relationships. A disk AV scan and a clean disk tell you nothing about an in-memory implant. The recycle bin is irrelevant. Memory forensics is the right tool when there's no file to triage, and you should capture before the host is rebooted.

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.

LSASS stores cached credentials and secrets, so an unexpected process reading its memory is a hallmark of credential theft (e.g., mimikatz-style dumping). Triage the offending process and parent, isolate the host to stop lateral movement, and rotate the credentials that could have been captured — including privileged and service accounts. It has nothing to do with graphics rendering or disk space, and ignoring it as normal can lead to domain-wide compromise. The benign-sounding distractors are exactly how analysts miss an active intrusion.

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.

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.

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.

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.

On Windows, local account hashes (NTLM) live in the SAM hive under C:\Windows\System32\config\SAM, protected while the OS runs; live credentials sit in LSASS memory, and domain hashes are in NTDS.dit on a domain controller. On Linux, hashes are in /etc/shadow (readable only by root), while /etc/passwd holds account metadata. Attackers steal these to crack passwords offline or pass-the-hash.

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.

CloudTrail records every API call in the account — who did what, when, from where — giving you the authoritative audit trail for investigations and compliance. GuardDuty is a managed threat-detection service that analyzes CloudTrail, VPC flow, and DNS logs to surface findings like credential exfiltration or crypto-mining. CloudTrail is the source of truth you must protect; GuardDuty turns that telemetry into actionable alerts.

Perfect Forward Secrecy (PFS) means each session derives a unique key from an ephemeral key exchange that is thrown away afterward. If an attacker later steals the server's long-term private key, they still cannot decrypt previously captured traffic, because that key was never used to derive the session keys. It's achieved with ephemeral Diffie-Hellman (DHE/ECDHE).

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 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.

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.

No. The padlock means the transport is encrypted and the certificate is valid for that domain — it says nothing about whether the operator is honest or the content is malicious. Free, automated certificates mean phishing and malware sites almost always have a perfectly valid padlock too. HTTPS protects the channel, not the destination.

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.

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.

A disassembler like Ghidra or IDA gives you the full static map: cross-references, decompiled pseudocode, and every code path whether or not it runs. A debugger like x64dbg lets you execute the sample under control — set breakpoints, inspect registers and memory, watch decryption happen, and follow the path the code actually takes with real inputs. You read structure and intent statically, then attach the debugger to resolve what static analysis cannot: runtime-decrypted strings, dynamically resolved APIs, packed payloads, and which branch a condition takes. The two together close each other's gaps.

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.

Packing compresses or encrypts the real payload and prepends a stub that unpacks it into memory at runtime; obfuscation transforms the code or data to resist reading and signatures. You detect packing from high section entropy near 8.0, a tiny or stub-only import table, unusual or writable-executable section names like UPX0, an entry point that sits outside .text, a large virtual size versus small raw size, and detectors like Detect It Easy or PEiD. None of these is conclusive alone, so analysts weigh several signals together and confirm by observing the unpack at runtime.

A PE file starts with the DOS header and its e_lfanew pointer to the PE/NT headers, which hold the File Header and Optional Header (entry point, image base, subsystem). It is divided into sections — .text for code, .data, .rdata, .rsrc for resources — each with a virtual address and raw size. During triage you read the import table for suspicious APIs, the section table for odd names and high entropy that hint at packing, the timestamp and rich header, embedded resources, and any digital signature. Mismatches between these tell you a lot before you ever run the file.

Process injection runs malicious code inside another process to hide and to inherit trust. Classic remote injection allocates memory in a target with VirtualAllocEx, writes a payload via WriteProcessMemory, and runs it with CreateRemoteThread. Variants include DLL injection via LoadLibrary, process hollowing that unmaps a suspended legitimate process and replaces its image, APC injection that queues code to a thread, and reflective or manual-mapped loading that avoids LoadLibrary entirely. You spot them by the telltale API sequences, RWX memory in a normally-clean process, threads with no backing file on disk, and parent-child anomalies.

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.

Unpacking recovers the original code the packer hid. For known packers you use the matching unpacker or an emulator. For custom packers you unpack manually: run the sample in a debugger, let the stub decompress the payload into memory, find the moment it jumps to the original entry point (often by breaking on memory that becomes executable, or on the tail jump), then dump the process image from memory and rebuild the import address table with a tool like Scylla or PE-sieve. The result is a runnable or analyzable PE containing the real payload.

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.

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.

Traceroute discovers the routers between you and a destination by exploiting the TTL field. It sends packets with TTL=1, then 2, then 3, and so on. Each router decrements TTL; when TTL hits zero, that router drops the packet and returns an ICMP Time Exceeded message, revealing its address. By stepping the TTL up, traceroute maps each hop in order until the destination is reached.

A DMZ (demilitarized zone) is a network segment that sits between the untrusted internet and the trusted internal network, hosting public-facing services like web, mail, and DNS servers. Firewall rules let the internet reach the DMZ but tightly restrict the DMZ's access to the internal network. The goal is containment: if a public server is compromised, the attacker is stuck in the buffer zone rather than landing inside the LAN.

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account with an SPN. That ticket is encrypted with the service account's NTLM password hash, so you extract it and crack the password offline — no privileged access needed to start, and it's near-silent.

A bind shell opens a listening port on the target and waits for you to connect to it. A reverse shell makes the target connect outbound to a listener you control. Reverse shells usually win because outbound traffic bypasses inbound firewall rules and NAT.

Reduce attack surface (remove unused packages/services), enforce key-only SSH with no root login, keep the system patched, run a default-deny firewall exposing only needed ports, apply least privilege via sudo and file permissions, enable auditd and centralized logging, and add integrity monitoring plus MAC like SELinux or AppArmor.

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.

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.

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.