Incident Response and Forensics Interview Questions for Cyber Security

NIST SP 800-61 describes preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. The 2025 revision aligns these with the NIST CSF 2.0 functions of Govern, Identify, Protect, Detect, Respond and Recover. Preparation includes playbooks, contacts and tools. Containment limits spread, eradication removes the attacker, recovery restores operations, and lessons learned improve controls and detections.

An event is any observable occurrence, like a login or a file change. An alert is an event or pattern that a tool flags as possibly malicious. An incident is a confirmed or highly likely violation of security policy that needs response, such as a compromised account. Clear definitions matter because incidents trigger escalation, legal review and regulatory reporting timelines.

Chain of custody is the documented record of who collected evidence, when, how, where it was stored and every person who handled it. It proves evidence was not altered, which is essential if the case goes to court or regulators. Practices include hashing disk images at acquisition, using write blockers, storing evidence securely and logging every transfer with signatures and timestamps.

A blameless review covers the timeline, root cause, how the attacker got in, what detected it, what slowed response, business impact and decisions made. It ends with specific actions that have owners and dates, such as enabling MFA on all VPN users or adding a detection rule. Tracking these actions to completion matters more than the report itself, otherwise the same incident repeats.

Under the CERT-In directions issued in April 2022, service providers, intermediaries, data centres and body corporates must report specified cyber incidents to CERT-In within six hours of noticing them. They must also keep ICT system logs for 180 days within India and synchronise clocks with NTP servers of NIC or NPL. Reportable incidents include ransomware, data breaches, and attacks on servers and cloud systems.

Collect the most volatile evidence first because it disappears quickly. The order is CPU registers and cache, memory including running processes and network connections, temporary files, disk, remote logs, and finally archived media. That is why responders capture RAM before shutting down a machine, since malware running only in memory, decrypted keys and active connections are lost at power off.

Short-term containment stops the spread quickly, for example isolating hosts through EDR, disabling accounts, blocking IPs or domains and segmenting networks. Long-term containment keeps business running while preparing clean systems, such as rebuilding servers in a separate network. Responders must balance speed with evidence preservation and avoid alerting a sophisticated attacker too early if they need to understand the full scope.

Memory forensics analyses a RAM capture to find running processes, injected code, network connections, loaded DLLs, command history and encryption keys. It reveals fileless malware that leaves little on disk. Volatility 3 is the common open source framework, with plugins such as windows.pslist, windows.netscan and windows.malfind. Captures are taken with tools like WinPmem or through EDR live response.

Static analysis examines a sample without running it: hashes, strings, imports, PE headers, YARA rule matches and disassembly. Dynamic analysis runs it in an isolated sandbox to observe processes, file changes, registry edits and network calls. Static is safe and fast but defeated by packing; dynamic shows real behaviour but malware may detect sandboxes. Analysts usually combine both in a controlled lab.

In BEC, attackers take over or impersonate an executive, vendor or finance mailbox to trick staff into making payments or changing bank details. It often uses no malware, just a compromised account, mailbox forwarding rules and convincing requests. Controls include MFA, DMARC enforcement, alerts on new inbox rules, and a mandatory call-back process on a known number for any change to payment details.

Contact the bank immediately to try to stop or recall the transfer; speed matters most. Report to the cybercrime portal and police. Investigate the email: was the CEO mailbox compromised or spoofed? Check sign-in logs, forwarding rules and other targeted staff. Reset credentials, enforce MFA and DMARC, and add a call-back rule for payment changes. Include legal and management throughout.

Treat it as a potential insider incident and involve HR and legal before contacting the employee. Preserve evidence such as DLP alerts, proxy logs, endpoint file activity and cloud app logs, and document what data was involved and its sensitivity. Restrict the user's access as advised. Legal decides on next steps, such as requesting deletion with an undertaking. Then improve DLP and offboarding controls.

Pick a realistic scenario, such as ransomware on a weekend, and invite IT, security, legal, communications and business leaders. A facilitator releases injects step by step, like a ransom note appearing or a journalist calling, and participants explain decisions using the real plan. Record gaps in contacts, authority, backups and reporting timelines. Share findings and track fixes, and repeat at least twice a year.

Situation: during a phishing campaign, 40 users received a credential-harvesting email on a Friday evening. Task: contain it before attackers used stolen accounts. Action: I purged the email across mailboxes, identified six users who clicked, reset their passwords, revoked sessions and blocked the domain, while updating my lead every 30 minutes. Result: no account misuse was found and the playbook was updated.

I lead with business impact: what is affected, current status, risk to customers or data, and decisions needed from them. Technical details go in an appendix. For example, in a past incident I gave updates every two hours in a fixed format: what we know, what we are doing, what we need, next update time. This kept leaders calm and decisions quick.

Situation: during a suspected malware case, a senior engineer wanted to wipe the laptop immediately to save time. Task: contain the threat while preserving evidence. Action: I explained that we needed a memory capture and EDR timeline first, which would take 20 minutes, and isolated the laptop meanwhile. Result: the capture revealed stolen browser credentials, so we reset them before they were misused.

Legal advises on regulatory notification, such as CERT-In within six hours and the Data Protection Board and affected people under the DPDP Act, contractual duties to clients, evidence handling and privilege. Communications manage messaging to customers, staff, media and investors so statements are accurate and consistent. Technical teams should involve them early, because poor communication can cause more damage than the incident itself.

Activate the incident plan and set up a war room with a separate communication channel. Contain by isolating affected segments, disabling compromised accounts, and blocking known command and control. Preserve evidence from a few hosts. Identify initial access and scope, including data theft. Verify offline backups, rebuild from clean images, and restore by business priority. Report to CERT-In within six hours and involve legal before any ransom discussion.

Do not just delete it. Capture the file, web logs and a memory image if possible, then identify when it was created and which request uploaded it. Search logs for commands executed through it and lateral movement from the server. Contain by isolating the server or blocking the path at the WAF, then patch the vulnerable application, rebuild from a clean image and rotate any credentials stored on it.

Search the hash, file name and parent process across all endpoints, and look for related indicators like network destinations and persistence mechanisms. Build a timeline to find patient zero and the delivery method, for example an email attachment or a compromised software update. Group affected hosts by criticality, isolate them, and check whether any credentials were stolen to plan resets broadly.

Deactivate the key immediately and check who owns it. Review cloud audit logs for every action taken with it, such as new instances, users, roles or policy changes, because attackers often create persistence. Terminate unauthorised resources, delete created users and keys, and check billing impact. Then find how it leaked, move workloads to roles with short-lived credentials and enable budget and anomaly alerts.

Collect timestamps from many sources: Windows event logs, file system MFT records, prefetch, browser history, EDR telemetry, proxy, firewall and cloud logs. Normalise all of them to UTC, then merge them using tools like Plaso and Timeline Explorer. Mark key points such as initial access, privilege escalation, lateral movement and exfiltration. The timeline drives scoping, root cause and the incident report.