SOC Analyst L2 (Tier 2), Interview Questions.

Tier 1 triages and escalates. Tier 2 investigates in depth: confirms whether an incident is real, determines scope (which users, hosts, data), pulls and analyses evidence, runs containment with approval, and writes the findings. Tier 2 also tunes detections, mentors Tier 1, and feeds lessons back into playbooks. The question changes from "is this bad?" to "how far did it go and how do we stop it?".

NIST 800-61 describes four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity (lessons learned). SANS splits it into six: preparation, identification, containment, eradication, recovery, lessons learned. Tier 2 lives mostly in analysis and containment.

The kill chain has seven stages: reconnaissance, weaponisation, delivery, exploitation, installation, command and control, actions on objectives. It is a linear, high-level story. ATT&CK is a detailed matrix of real techniques grouped under 14 enterprise tactics, not necessarily in order. Use the kill chain to explain an attack to management and ATT&CK to map detections and gaps.

It ranks indicators by how much it hurts an attacker when you block them: hash values (trivial), IP addresses (easy), domain names (simple), network and host artefacts (annoying), tools (challenging), and TTPs (tough). Detections built on behaviour at the top force the attacker to change how they work, not just swap an artefact.

After the first foothold, an attacker moves to other systems to reach valuable targets. Signals: logons (type 3 and 10) from one workstation to many hosts, use of remote admin tools (PsExec-style service creation, WMI, WinRM, scheduled tasks), new services (7045), admin share access, and credential use that does not match the user's normal pattern.

Techniques an attacker uses to keep access after reboot or password change. Common ones: Run keys and startup folders, scheduled tasks, new services, WMI event subscriptions, new local or cloud accounts, SSH authorized keys, web shells, mailbox rules and OAuth app grants, and cloud access keys. Hunting persistence is a core Tier 2 task.

System Monitor is a Microsoft Sysinternals driver that writes rich endpoint events to the Windows event log. Useful IDs: 1 process create (with hashes and parent), 3 network connection, 7 image loaded, 8 CreateRemoteThread, 10 process access (credential dumping signal on lsass), 11 file create, 13 registry value set, 22 DNS query. It fills the gaps in native logging.

Evidence-based knowledge about adversaries that helps decisions. Strategic (who targets us and why, for leaders), operational (campaigns and how they work), tactical (TTPs, for defenders and detection) and technical (IOCs for blocking). Quality depends on source, confidence, age and relevance to your environment.

1. Pivot on every indicator: user, source IPs, hashes, domains, mutexes, filenames, command lines.
2. List what the account touched: logons across hosts, mailboxes, cloud consoles, file shares.
3. Look for the earliest evidence to find patient zero and the initial access vector.
4. Check persistence and any new accounts or keys.
5. Check for data staging and exfiltration.
6. Define a timeline and keep updating the scope until no new indicators appear.

Assume the attacker used more than you have found, and avoid containing too early if it will tip them off before you know the extent (a judgment call with the incident commander).

Short-term: isolate the host with EDR (keeps memory and the session for forensics), disable or reset the account, revoke tokens and sessions, block IOCs at proxy, DNS and firewall, quarantine mail. Long-term: rebuild systems, rotate secrets, patch. The trade-off is speed versus evidence and business impact: pulling a power cable stops spread but loses memory, and isolating a production server may take down a service. Agree actions with the system owner and incident commander.

• Prefetch: program run counts and times (when enabled).
• Amcache and Shimcache: evidence a binary existed or was seen, with caveats on what each proves.
• Event logs: 4688, Sysmon 1, 7045, task scheduler logs.
• UserAssist, BAM: user-launched programs.
• SRUM: resource usage per application.

Be careful with wording: Shimcache shows presence, not always execution.

Look for Sysmon event 10 where the target is lsass.exe with suspicious access masks, process creation of known dumping utilities or renamed copies, comsvcs-style dump commands, creation of large dump files, access to the SAM, SYSTEM and NTDS.dit files, and shadow copy creation. Then assume the credentials of any account logged on to that host are burned: reset them, and hunt for their use elsewhere. Credential Guard and LSA protection reduce exposure.

Pass-the-hash: NTLM network logons (4624 type 3) for accounts that normally use Kerberos, from workstations to many servers, sometimes with mismatched host and account patterns. Pass-the-ticket / golden ticket: Kerberos tickets with abnormally long lifetimes, TGS requests (4769) without a preceding TGT (4768), encryption downgrades, and tickets for accounts that do not exist. Fixing needs rotation (krbtgt twice for golden tickets) and tiered admin practices.

Look for new or modified script files in web directories, web server processes spawning shells (w3wp.exe or nginx/apache children like cmd.exe or sh), unusual POST requests to a single file, and odd outbound connections. Preserve the file and logs, find the initial vulnerability, check other servers on the same stack, and rotate any secrets the server held. Removing the file without fixing the entry point just invites a return.

Identify the key and owner via CloudTrail, list all calls made with it (source IPs, user agent, regions, services), check for new users, roles, keys or policies, and for resource creation (compute for mining, snapshots shared out). Then deactivate the key, review and revoke temporary sessions (attach a deny policy tied to token issue time), remove attacker-created resources, rotate related secrets, and find how the key leaked (public repo, CI log, developer machine).

Sign-in logs for the account after the phish time, new MFA methods, mailbox rules (forwarding or hiding replies), OAuth consents, mail sent by the account, file downloads, and access from new devices. Reset the password, revoke refresh tokens and sessions, remove malicious rules and apps, and notify people who received mail from the account if it was used for further phishing.

Triage is reactive to alerts. Hunting is proactive: start from a hypothesis (for example, "an attacker with valid credentials is using remote services to reach our database tier"), query telemetry for evidence, and either find activity or conclude it is absent. Good hunts end with a new detection, a fixed logging gap, or a documented negative result.

Collect events from every source, normalise time to UTC and note clock skew, then order by time and tag each with source, host, user and ATT&CK technique. Mark confirmed facts separately from hypotheses. Look for gaps and for the earliest event. A good timeline answers who, what, when, how and what next, and is the backbone of the final report.

After an incident, ask which alert should have fired and did not. Check whether the log source was missing, the rule logic too narrow, the alert suppressed, or the alert fired but was closed wrongly. Fix the cause (add telemetry, widen the rule, change process) and test it. This is how a SOC improves from real incidents.

Find a verifiable benign explanation: a change ticket, a known admin tool on the expected host, a scanner on its allowlist, a user confirmation through a trusted channel, or consistent historical behaviour. If the only evidence is "it looks normal", it is not enough. Record the evidence and consider a narrowly scoped, owned exclusion.

Red (attack simulation) and blue (defence) work together in the open: the red team runs agreed techniques, the SOC checks what was logged, alerted and responded to, and they fix gaps immediately. The result is measured detection coverage by ATT&CK technique and faster tuning than waiting for a real attack.

Behavioural approach: alert on a new service (7045 or 4697) whose image path is in a user-writable location, uses a command shell, has a random name, or is created remotely (a network logon immediately before it from a non-admin host). Add context: is the source host an authorised admin jump host? Enrich with parent process and the account's normal pattern, and keep an allowlist of deployment tooling. Validate against a test run and measure false positives before enabling paging.

// KQL sketch
SecurityEvent
| where EventID in (4697, 7045)
| where ServiceFileName has_any ("\\Users\\", "\\Temp\\", "cmd.exe", "powershell")
| project TimeGenerated, Computer, ServiceName, ServiceFileName, SubjectUserName

Group connections by source, destination and port over a window, then measure regularity: low variance in the interval between connections (allowing for jitter), similar byte sizes, long-lived small transfers, and rare destinations. Filter known updaters and CDNs. Statistical scoring finds candidates, and an analyst then checks the process, user agent, certificate and domain age.

Running processes and parent trees (including hidden or unlinked ones), network connections, injected code regions, loaded modules, command lines, credentials and keys in memory, and malware configuration. Memory shows things that never hit disk. Capture it before isolation reboots or powers off the machine, and hash the image. Tools such as Volatility are standard.

Track mean time to detect, acknowledge and respond, but pair speed with quality: escalation accuracy, rate of reopened tickets, detection coverage against ATT&CK, false positive rate per rule, and incidents found by hunting versus alerts. Single metrics get gamed (closing tickets quickly to hit time targets), so review samples of closed alerts for correctness.

Say what cannot be proven. Use secondary sources (EDR, proxy, DNS, flow data, cloud audit, email gateway, backups, disk artefacts), and assume the widest plausible scope for containment decisions. After the case, fix retention and coverage, and report the risk. Never fill gaps with guesses written as facts.

An executive summary, timeline, root cause and initial access vector, scope (assets, accounts, data), impact, actions taken, indicators, ATT&CK mapping, what worked and what failed, and prioritised recommendations with owners and dates. Write it blameless, factual and readable by both executives and engineers, with evidence referenced.

It describes an intrusion event through four features: adversary, capability, infrastructure and victim, with meta-features such as time, phase and result. Pivoting between these links events into campaigns (for example, shared infrastructure suggests the same operator). It helps attribute clusters of activity and plan which pivots to follow.

Prioritise by relevance to your sector and technology, confidence and freshness, expire old indicators, and prefer behaviour-based detections to long lists. Automate ingestion with scoring, test indicators against history (retro-hunt), and feed sightings back to your sharing group. IOC lists age quickly, so treat them as a hunting lead, not a verdict.

As soon as personal data may be affected, regulated systems are involved, an employee is the suspected actor, extortion or law enforcement may be needed, or external communication is likely. Regulations have clocks (for example GDPR 72 hours to notify the authority, CERT-In 6 hours for certain incidents in India), so loop them in early through the incident commander.

1. Confirm: view the process tree, command line (decode if encoded), file origin (email or download), and hashes.
2. Contain: isolate the laptop through EDR, disable the user session after talking to the incident commander.
3. Scope: what did the file-server connection do? Review file server logons, files read and written, other hosts the account touched, and other recipients of the same document.
4. Eradicate: remove persistence, reset credentials the host held, block IOCs, purge the email.
5. Recover: reimage if integrity is uncertain, monitor the account.
6. Learn: macro policy, attachment controls, detection for the parent-child chain.

Declare a major incident and assemble the team. Stop spread: isolate affected segments and hosts, disable compromised accounts, protect backups (offline and immutable copies, disconnect backup servers). Preserve evidence (memory and disk images from a few representative hosts, ransom note, logs). Identify initial access and any data theft, since double extortion is common. Decide restore order by business criticality, engage legal and communications, and do not decide on payment inside the SOC. Rebuild identity (domain compromise) before restoring services.

Check whether a change window or automation explains it (a deployment tool, patching). If not, treat the account as compromised: identify the source host, the logon types, tools and commands run on the servers, and any new services or tasks. Disable the account, isolate the source, hunt for the same behaviour with other accounts, and assess domain-level compromise (DC logs, replication requests, ticket anomalies).

It resembles DNS tunnelling for command and control or exfiltration, but check for legitimate causes first (some security products and mail checks use odd DNS). Measure volume and entropy, identify the process responsible, review the domain's registration and reputation, and inspect what the host did around the same time. If it is malicious, block the domain at the resolver, isolate the host, and search for other hosts querying it.

Treat the secret as compromised immediately: revoke or rotate it first, before cleaning history. Review audit logs from the time of the push for use by unknown sources, remove unauthorised resources, check for persistence (new keys, roles), and assess data access. Then purge the secret from history, add secret scanning and pre-commit checks, and share the lesson. Bots find exposed keys within minutes, so speed matters.

Short, regular, plain-language updates: what we know, what we do not know, business impact, what we are doing, what we need from them, and when the next update comes. Separate facts from assumptions, avoid jargon and blame, and never speculate about attribution or data loss before evidence. Consistent cadence builds trust.