Question 1

What is your triage priority order, and what three questions do you ask before escalating?

Accepted Answer

My triage priority is: Contain → Verify → Escalate. First, I immediately isolate the source endpoint via EDR or network quarantine to stop lateral movement. Second, I ask three questions: (1) Is the user a legitimate admin who normally uses RDP? I check the user's AD group membership and recent login history. If they are not in Domain Admins and have never RDP'd before, this is highly suspicious. (2) Are the destination servers in the user's normal scope of work? If a finance employee is RDP'ing to database servers, this is abnormal. (3) Did the RDP sessions use legitimate credentials or pass-the-hash? I check Windows Event ID 4624 (logon type 10 for RDP) and look for NTLM logons (Event ID 4624 with Authentication Package: NTLM) which suggest PtH. If the answers are "no, no, and NTLM," I escalate as a confirmed compromise. Before escalating, I also capture a memory dump of the source endpoint and preserve Windows Event Logs and Sysmon data to a write-once storage. I document the timeline with exact timestamps for each RDP session.

Question 2

What does this pattern tell you about the malware type, and what host-based evidence do you look for?

Accepted Answer

The rigid 5-minute interval with small payloads is classic **C2 beaconing** from a **RAT (Remote Access Trojan)** or **meterpreter-style implant**. The :00 and :05 timing suggests the malware uses a simple cron-like scheduler, not jitter, which is common in off-the-shelf malware or early-stage implants. The 100-byte payload suggests it is likely sending a heartbeat or waiting for commands, not exfiltrating data. On the host, I look for: (1) **Scheduled Tasks** (Windows) or **cron jobs** (Linux) created in the last 7 days. (2) **Running processes without verified signatures** — I use Sysinternals Autoruns and Process Explorer to find unsigned binaries in AppData, Temp, or ProgramData. (3) **Network connections** — `netstat -ano` or `Get-NetTCPConnection` to find the process PID owning the connection to the suspicious domain. (4) **DNS cache** — `ipconfig /displaydns` to see if the domain resolved recently. I also check **proxy logs** and **firewall logs** for the first occurrence of this domain — that timestamp is likely the initial infection time. For deeper analysis, I run **Volatility** on a memory dump to find injected code or hooked system calls.

Question 3

What is your incident response playbook for the next 60 minutes?

Accepted Answer

Minute 0-5: **Scope**. I pull the email headers from the 50 inboxes and identify the malicious domain. I query proxy/firewall logs for all users who visited the domain. Minute 5-15: **Contain**. I force-reset passwords for the 5 confirmed victims and any user who visited the domain. I block the phishing domain at the firewall, DNS, and proxy levels. I also revoke all active sessions for the affected users in Azure AD. Minute 15-30: **Investigate**. I analyze the phishing page (if still live) using URLScan or VirusTotal. I check if the attacker used the captured credentials by reviewing Azure AD Sign-In Logs for impossible travel or new device registrations. Minute 30-45: **Hunt**. I search all endpoints for similar emails using the attacker's subject line pattern or sender domain. I also hunt for any new inbox rules created by the attacker (O365 attackers often set rules to auto-delete security alerts). Minute 45-60: **Communicate and Remediate**. I notify the 50 users with a simulated phishing follow-up. I deploy a new email rule to quarantine similar emails. I update the email gateway blocklist and tune detection rules. Finally, I document the IOCs (domains, IPs, file hashes) in the threat intel platform.

Question 4

What does this technique tell you about the attacker's maturity, and what three forensic artifacts do you collect?

Accepted Answer

This is a **living-off-the-land** technique using PowerShell Download Cradle — common in both APT and commodity malware. The attacker's maturity is **intermediate**: they know how to evade basic signature detection with encoding, but they are not using advanced techniques like AMSI bypass or reflective PE injection. The use of `IEX` (Invoke-Expression) and `Net.WebClient` is a classic script-kiddy/pen-tester pattern. The three forensic artifacts I collect are: (1) **PowerShell Operational Log** (Event ID 4104) — contains the full decoded script block if script block logging is enabled. (2) **Sysmon Event ID 1 (Process Create)** and **Event ID 3 (Network Connect)** — shows the exact parent process that spawned PowerShell and the network connection to evil.com. (3) **NTFS USN Journal and MFT** — shows if payload.ps1 was written to disk, even if deleted. I also check **Temporary Internet Files** and **Prefetch** for execution evidence. If **AMSI (Anti-Malware Scan Interface)** is enabled, I check `amsi.log` for scan results — sometimes AMSI blocks the script and the attacker retries with obfuscation. For the interview, I mention that mature attackers would use `powershell -ep bypass -enc` with a custom AMSI bypass or direct syscalls, so seeing plain `IEX` suggests either a less sophisticated actor or an early-stage reconnaissance tool.

Question 5

What three evidence sources reconstruct the attacker's commands even without bash history?

Accepted Answer

First, **`.bash_history` for other users** — if the attacker switched users with `su` or `sudo`, the other user's bash history may still contain commands. I also check `/root/.bash_history` and `/home/*/.bash_history`. Second, **`/var/log/auth.log` or `/var/log/secure`** — records every sudo command, SSH login, and privilege escalation with timestamps. Even if bash history is deleted, auth.log shows what commands were executed via sudo. Third, **file system timestamps (MAC times)** — I use `fls` and `ils` from The Sleuth Kit to list deleted files and their access/modify times. If the attacker downloaded tools, the `/tmp` or `/dev/shm` directories may have deleted files with timestamps showing when they were created. I also check: (4) **Syslog** for commands sent via remote management (Ansible, SaltStack). (5) **Auditd logs** if auditd was running — it logs every syscall including execve. (6) **Shell history alternatives** — `zsh` history (`~/.zsh_history`), `fish` history, or `less ~/.python_history`. For the interview, I mention that a **well-hardened server should have auditd + rsyslog forwarding to a SIEM** so that even if local logs are deleted, the SIEM retains a copy. I also use `strings` on the disk image to search for command artifacts in unallocated space.

Question 6

What three data points differentiate legitimate cloud storage use from exfiltration?

Accepted Answer

First, **file type analysis**. Legitimate work files are typically Office docs, PDFs, and project files. Exfiltration often involves database dumps (.sql, .bak), compressed archives (.zip, .tar.gz), or entire folder structures. I check the DLP logs or proxy logs for file extensions and names. Second, **timing and velocity**. A user uploading 50GB at 3:00 AM on a Saturday is abnormal unless they are in a different timezone. I compare the upload time against their normal working hours and recent activity. Third, **access patterns before upload**. Did the user access files they normally do not touch? I check file server audit logs for access to HR records, customer databases, or financial folders in the hours before the upload. I also check if the user recently received a resignation letter or performance warning — insider threat context matters. For the interview, I mention **UEBA (User and Entity Behavior Analytics)** which baseline normal behavior and flag deviations. I also check if the Dropbox account is **company-managed** (Dropbox Business) or personal — personal accounts are higher risk. Finally, I scan the uploaded files with DLP fingerprinting to see if they contain PII, PCI, or IP data.

Question 7

What is your incident response recommendation, and what three recovery alternatives do you evaluate first?

Accepted Answer

My recommendation is **do not pay**. Paying funds criminal operations, does not guarantee decryption, and may trigger sanctions violations (OFAC has designated some ransomware groups). The three alternatives to evaluate first are: (1) **Offline backups** — check if immutable backups exist (Veeam Hardened Repository, tape, air-gapped cloud). If backups are clean and from before the infection time, recovery is hours, not days. (2) **NoMoreRansom or ID Ransomware** — identify the ransomware strain. Some strains (e.g., older versions of GandCrab, Shade) have free decryptors published by security researchers. (3) **Shadow Copies and System Restore** — even if encrypted, Windows Volume Shadow Copy Service (VSS) snapshots may exist if the ransomware did not explicitly delete them (`vssadmin delete shadows`). I check `vssadmin list shadows` immediately. For the response, I isolate all affected systems, preserve memory dumps from one victim for malware analysis, and check if the ransomware spread via SMB (EternalBlue-style) or phishing. I also check **Active Directory** for new accounts or Group Policy changes — some ransomware (e.g., Ryuk, Conti) uses AD to propagate. For the interview, I mention that **cyber insurance** often has clauses voiding coverage if the ransom is paid without law enforcement consultation.

Question 8

Is this a botnet, a proxy network, or a legitimate red team exercise, and how do you determine which?

Accepted Answer

This is most likely a **residential proxy network or bulletproof hosting** used by attackers. A botnet would show more diverse ISPs and geographic spread. A red team exercise would be pre-authorized and documented. To determine which: (1) **Check the threat intel feed** — query the IPs in AbuseIPDB, GreyNoise, or VirusTotal. Residential proxy networks (e.g., Bright Data, Oxylabs) have known ASN ranges. If the IPs map to a known proxy ASN, it is likely a commercial proxy service abused by attackers. (2) **Analyze the attack pattern** — botnets typically use identical payloads; a red team uses varied, sophisticated payloads. If all 50 IPs send the exact same `UNION SELECT` payload with the same encoding, it is a distributed scanner, not a red team. (3) **Check internal calendars** — verify with the security team if a red team is scheduled. Red teams always notify before attacking production. (4) **User-Agent analysis** — residential proxies often rotate real browser UAs; botnets use generic UAs like `Mozilla/5.0`. If the UAs look realistic but the behavior is automated, it is a proxy network. My response: block the ASN range temporarily, enable WAF rate limiting, and add the IPs to a threat intel blocklist. I also notify the ISP's abuse contact.

Question 9

Why is this suspicious, and what memory artifacts confirm process hollowing or DLL injection?

Accepted Answer

`svchost.exe` spawning `notepad.exe` is suspicious because `svchost.exe` should not normally launch user applications like Notepad. This is a classic **process hollowing** pattern: the attacker starts a legitimate process (Notepad) in suspended mode, hollows out its memory, and injects malicious code. The memory artifacts I look for are: (1) **MZ header mismatch** — the on-disk image of `notepad.exe` has a valid PE header, but the in-memory image has a different MZ header or starts with shellcode. I use `PE-sieve` or `Moneta` to scan for this. (2) **Unmapped executable memory** — legitimate Notepad has RWX pages only in specific regions. Injected code often resides in RWX pages outside the module's normal memory map. I check with `Vmmap` or `Process Hacker`. (3) **Thread start address anomaly** — if a thread in Notepad starts at `0x00400000` (normal) vs `0x00AB0000` (suspicious), it indicates injected code. I use `Process Hacker` or `WinDbg` to inspect thread start addresses. For the interview, I also mention **ETW (Event Tracing for Windows)** subscriptions — Sysmon Event ID 8 (`CreateRemoteThread`) and Event ID 10 (`ProcessAccess`) are the best telemetry for catching injection in real time. I also check if `notepad.exe` has network connections — legitimate Notepad has none; if it connects to the internet, it is almost certainly hollowed.

Question 10

What is your 24-hour action plan, and what compensating controls protect you if patching takes a week?

Accepted Answer

Hour 0-2: **Verify exposure**. I run a vulnerability scan (Nessus, Rapid7) to confirm which appliances are vulnerable and check vendor advisories for IOCs (exploit artifacts, backdoor files). Hour 2-4: **Hunt**. I search VPN logs for the IOCs: specific URLs, User-Agent strings, or source IPs associated with the exploit. I also check for unauthorized admin accounts or config changes. Hour 4-8: **Contain**. If exploitation is confirmed, I disable internet-facing management interfaces on all 50 appliances and restrict VPN access to known IP ranges via geo-blocking. Hour 8-24: **Patch priority**. I patch the 5 appliances that show signs of compromise first, then the remaining 45 by business criticality. Compensating controls if patching takes a week: (1) **WAF/CDN in front of VPN** — Cloudflare or AWS WAF blocks known exploit payloads before they reach the appliance. (2) **MFA enforcement** — even if the VPN is compromised, MFA prevents credential-based lateral movement. (3) **Network segmentation** — place VPN appliances in a DMZ with strict ACLs to internal networks. (4) **Honeypot VPN** — deploy a decoy appliance to detect active scanning. I also increase log monitoring frequency to 15-minute checks and enable **full packet capture** on the VPN segment for forensic analysis.

Question 11

What three additional data points confirm or refute the VPN explanation?

Accepted Answer

First, **VPN gateway logs**. If the user connected via the corporate VPN, the VPN concentrator (AnyConnect, GlobalProtect) logs the assigned virtual IP and the public IP of the connection. If the Mumbai login has no corresponding VPN session but shows a direct corporate app login, it is suspicious. Second, **device fingerprinting**. Azure AD and Okta record the device ID, browser fingerprint, and OS. If the New York login was from a managed Windows laptop and the Mumbai login was from an unknown Linux machine, the VPN explanation is unlikely. Third, **MFA logs**. If the user passed MFA in New York but the Mumbai login did not trigger an MFA challenge (because the attacker used a stolen session cookie), this is a strong indicator of account takeover via session hijacking. I also check **proxy logs** — if both logins came from the same proxy IP but different X-Forwarded-For headers, it could be a VPN exit node being abused. For the interview, I mention that **impossible travel is a noisy alert** — users on planes with in-flight WiFi or near time zone borders often trigger it. The key is correlating with MFA, device trust, and session behavior.

Question 12

What dynamic analysis steps reveal its true behavior, and what sandbox evasion techniques might it use?

Accepted Answer

Dynamic analysis steps: (1) **Run in an isolated sandbox** (Cuckoo, ANY.RUN, or a local VM with no network access). Monitor API calls with **API Monitor** or **x64dbg**. If it calls `socket` → `connect` to an external IP, I have the C2 address. (2) **Monitor registry and file system changes** with **ProcMon**. Ransomware creates registry run keys; infostealers access browser credential stores. (3) **Memory analysis** with **Volatility** after execution. Injected code, unpacked payloads, and decrypted strings live in memory even if the disk file is clean. Sandbox evasion techniques the DLL might use: (1) **VM detection** — checking for VMware Tools, VirtualBox guest additions, or low RAM/CPU count. (2) **Sleep/delay loops** — waiting 10+ minutes before executing payload to evade short sandbox runs. (3) **User interaction checks** — calling `GetLastInputInfo` to verify mouse/keyboard activity; sandboxes have none. (4) **Domain/IP reachability test** — resolving a non-existent domain that only the sandbox's fake DNS would respond to. To defeat evasion, I use **hybrid analysis** with a 24-hour runtime, **human interaction simulation** (moving mouse), and **fake internet** (InetSim) that responds to all DNS queries realistically. For the interview, I also mention **YARA rules** — I write a YARA signature for the DLL's import hash (imphash) to hunt for similar samples across the enterprise.

Question 13

What is your immediate containment, and how do you determine if any sensitive data was exfiltrated?

Accepted Answer

Immediate containment: (1) **Block public access** — apply an S3 Block Public Access policy at the bucket level to prevent any new public access. (2) **Identify the owner** — check AWS CloudTrail for `PutBucketAcl` or `PutBucketPolicy` events to find who made the bucket public. (3) **Inventory the 200 public files** — use `aws s3api list-objects-v2` with a filter for public ACLs. To determine exfiltration: (1) **S3 Server Access Logs** — if enabled, they show every GET request with source IP, User-Agent, and timestamp. I look for bulk downloads (high byte counts) or downloads from unfamiliar IPs. (2) **AWS CloudTrail Data Events** — records S3 object-level API calls. I query Athena for `GetObject` events on the public files. (3) **Threat intel** — check if any of the source IPs accessing the bucket are known malicious (Tor exit nodes, scanner IPs). If no access logs exist, I check **VPC Flow Logs** if the bucket is accessed via VPC endpoint. For the interview, I mention that **public S3 buckets are often caused by CloudFormation or Terraform misconfigurations** — I audit the IaC templates to prevent recurrence. I also recommend **Amazon Macie** for automated sensitive data discovery in S3.

Question 14

Is this a threat that requires active response, and what three defensive actions do you take?

Accepted Answer

Yes, persistent reconnaissance is a **pre-attack indicator**. Attackers often map the perimeter for weeks before launching an exploit. Even if no breach occurred, this intelligence is valuable. Three defensive actions: (1) **Threat intel enrichment** — query the IP in Shodan, Censys, and threat feeds. If it belongs to a known APT infrastructure or scanning service, I block it at the perimeter firewall and WAF. (2) **Honeypot deployment** — deploy a decoy service (e.g., a fake RDP or SSH endpoint) on the scanned port and monitor if the attacker interacts with it. This reveals their TTPs (Tactics, Techniques, Procedures) without risk to production. (3) **Defensive countermeasures** — if the attacker scans port 3389 (RDP), I ensure no RDP is exposed to the internet. If they scan for a specific CVE, I verify patching status and increase monitoring on that service. I also create a **Sigma/YARA rule** to detect similar scanning patterns from other IPs. For the interview, I mention that **not every scan requires a full incident response**, but persistent scanning from the same source for 3 weeks warrants a **threat intel report** to the community (ISAC) and coordination with the ISP or law enforcement if the attacker is known.

Question 15

What three technology investments and two process changes achieve best-in-class detection and response?

Accepted Answer

Technology investments: (1) **EDR + XDR on every endpoint**. Best-in-class SOCs have 100% EDR coverage. XDR correlates endpoint, network, and identity telemetry into a single timeline, reducing the time analysts spend context-switching. (2) **AI/ML-powered SIEM** — tools like Sentinel, Chronicle, or CrowdStrike Falcon LogScale use ML to baseline behavior and detect anomalies that rule-based SIEMs miss. This cuts MTTD from anomaly to alert from days to minutes. (3) **SOAR (Security Orchestration, Automation and Response)** — automates tier-1 response: isolating endpoints, blocking IPs, disabling accounts, and opening tickets. SOAR reduces MTTR by 70% for common incidents. Process changes: (1) **Shift from alert-driven to hypothesis-driven hunting**. Instead of waiting for alerts, analysts spend 30% of their time proactively hunting using MITRE ATT&CK techniques. (2) **Tabletop exercises and purple teaming**. Monthly simulations with the red team validate detection coverage and response playbooks. For the interview, I also mention **metrics-driven improvement**: track "mean time to contain (MTTC)" and "false positive rate" per detection rule. Rules with > 5% false positives get tuned or retired. Finally, I emphasize **24/7 coverage** — best-in-class requires follow-the-sun SOC operations, not just a single shift.

SOC Analyst Interview Questions: Incident Response & Threat Detection Scenarios

More Network Security Interview Prep