SOC Analyst L1 (Tier 1), Interview Questions.

Tier 1 is the front line. You monitor the SIEM and EDR queues, triage alerts (decide whether each is a real threat or noise), enrich them with context (who, what host, what time, threat intelligence), follow the playbook, document every step in the ticket, and escalate anything confirmed or uncertain to Tier 2. You also handle user-reported phishing, hand over cleanly between shifts, and flag noisy rules so they can be tuned. Speed matters, but accurate notes and good judgment about when to escalate matter more.

• True positive: the alert fired and there really is malicious activity.
• False positive: the alert fired but the activity is benign. It wastes time and causes fatigue.
• True negative: no alert, and nothing bad happened.
• False negative: no alert, but there was malicious activity. This is the worst, because the threat goes unseen.

A SOC balances the two errors: tuning that removes false positives must not create false negatives.

A Security Information and Event Management system collects logs from many sources (endpoints, servers, firewalls, identity, cloud, email), normalises and stores them, lets you search and correlate across them, and raises alerts from detection rules. It turns millions of raw events into a prioritised queue and gives analysts one place to pivot during an investigation. Examples include Splunk, Microsoft Sentinel, Elastic and QRadar.

An event is any recorded occurrence (a login, a process start). An alert is an event or pattern of events that a rule flagged as worth a look. An incident is a confirmed or highly likely security event that threatens confidentiality, integrity or availability and needs a coordinated response. Most alerts are not incidents.

An Indicator of Compromise is evidence that something already happened: a malicious file hash, a bad IP or domain, a registry key. An Indicator of Attack describes behaviour that suggests an attack in progress, such as Word spawning PowerShell or a burst of failed logins then a success. IOCs are easy to match but attackers change them quickly. IOAs are harder to evade because they track technique, not artefacts.

• 22 SSH, 23 Telnet, 21 FTP, 25 SMTP, 53 DNS, 80 HTTP, 443 HTTPS
• 88 Kerberos, 389 LDAP, 636 LDAPS, 445 SMB, 135 and 139 Windows RPC and NetBIOS
• 3389 RDP, 5985 and 5986 WinRM
• 1433 MSSQL, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch

Knowing what should and should not be exposed helps you judge alerts fast: RDP or SMB open to the internet is almost always a finding.

• 4624 successful logon and 4625 failed logon (check the logon type and failure sub status).
• 4672 special privileges assigned to a logon (an admin-level logon).
• 4688 process created (with command line auditing on).
• 4720 user account created, 4732 member added to a local group, 4740 account locked out.
• 1102 the Security log was cleared, a classic sign of anti-forensics.
• 7045 (System log) a new service was installed.

Brute force tries many passwords against one account, so you see many failures for a single user and often a lockout. Password spraying tries one or a few common passwords across many accounts, staying under lockout limits, so you see a few failures each across many users from one source. Credential stuffing replays username and password pairs leaked from other breaches, so you see many different accounts with varied attempts, often from a botnet, and the occasional success.

SPF lists which servers may send mail for a domain's envelope sender. DKIM adds a cryptographic signature to the message, checked with a public key in DNS. DMARC ties them to the visible From domain (alignment), tells receivers what to do on failure (none, quarantine or reject), and sends reports. A message can pass SPF and still be a spoof if the visible From domain does not align, which is why DMARC matters.

Severity describes the technical impact of the issue (a ransomware detection is high severity). Priority is how urgently you act, which also depends on asset criticality, exposure, and business context (a medium-severity finding on a payment server may be top priority). Good triage uses both, and the playbook defines the response time for each.

A hash (such as SHA-256) is a fixed-length fingerprint of a file's content. The same file always gives the same hash, and a one-byte change gives a completely different one. Analysts look a hash up in threat intelligence or a service like VirusTotal to see if the file is known malware, search the SIEM and EDR for the hash to find every host that has it, and record it as an indicator. Remember that a hash miss does not mean a file is safe, because attackers recompile to change it.

1. Confirm the pattern: count failures, time window, and the source IPs. Is the success from the same IP as the failures?
2. Check the source: internal or external, known VPN or office range, reputation, geolocation.
3. Check the account: privileged, service account, dormant, recently reset?
4. Look at what happened after the success: new sessions, mailbox rules, file access, MFA prompts, privilege changes.
5. If the success looks attacker-driven, escalate and recommend disabling the account and revoking sessions. If it matches a user who mistyped, document and close.

Do not click or open anything on a normal workstation. Gather the original message as an attachment (not a forward) so headers survive. Check the sender and the authentication results, compare the display name with the real address and the Reply-To, read the links without clicking (hover, or extract the URLs), and check the domain's age and reputation. For attachments take the hash and detonate in a sandbox. Search the mail system for the same message to find other recipients. If malicious, block the sender, URL and hash, purge the mail, and check whether anyone clicked.

Read the Received lines from bottom to top: the bottom one is the first hop. Check Return-Path (envelope sender), From (what the user sees), Reply-To (where replies go), Message-ID, and Authentication-Results for the SPF, DKIM and DMARC verdicts. Mismatches between From, Return-Path and Reply-To, or a failed DMARC, are strong signals.

Authentication-Results: mx.example.com;
  spf=fail smtp.mailfrom=billing@lookalike-example.net;
  dkim=none;
  dmarc=fail header.from=example-corp.com
From: "Finance Team" <finance@example-corp.com>
Return-Path: <billing@lookalike-example.net>
Reply-To: payments.desk@mailbox-example.org

Event 4624 carries a logon type. 2 interactive (at the keyboard), 3 network (file shares, many remote tools), 4 batch (scheduled task), 5 service, 7 unlock, 9 new credentials (runas /netonly), 10 remote interactive (RDP) and 11 cached credentials. Type 10 from an unexpected source, or type 3 from a workstation to many servers, deserves a closer look.

One source touching many ports on one host (a vertical scan) or one port on many hosts (a horizontal sweep), usually with many connection attempts that never complete (SYN without handshake), short-lived flows, and sequential or random port numbers in a short window. Internal sources scanning are more worrying than internet noise, since they suggest a compromised host doing discovery. Check the source, whether it is an authorised vulnerability scanner, and what that host did before and after.

First rule out false positives: VPN or proxy egress, mobile carrier or cloud IP geolocation errors, a corporate cloud service. Then check the sign-in details: device, browser, MFA result, application. Look at the activity after login (mail forwarding rules, OAuth consents, large downloads). Contact the user through a known channel, not by replying to anything suspicious. If it looks hostile, recommend a password reset, session revocation and MFA re-registration, and escalate.

Decode the command to see what it does, then look at the context: parent process (Word, Excel or a script host is suspicious), user, host, signed or unsigned, and any network connections or downloaded files. Admins and software also use encoded PowerShell, so context decides. If it downloads or runs something unknown, escalate and consider isolating the host.

# PowerShell -EncodedCommand is base64 of UTF-16LE text
echo 'VwByAGkAdABlAC0ASABvAHMAdAAgACcAaABpACcA' | base64 -d | iconv -f UTF-16LE -t UTF-8

• Parent and child: does the process tree make sense (winword.exe spawning powershell.exe does not)?
• Path: running from Temp, Downloads, AppData or a user profile is a flag for system-looking names.
• Signature and hash: signed by a trusted publisher? Known to threat intelligence?
• Command line arguments and the user context.
• Network connections and files it touched or dropped.
• Prevalence: have other hosts in the estate ever run it?

Not automatically. Verify the quarantine really succeeded, then work out how it arrived (email, web, USB, share) and whether it executed before detection (process creation, persistence, outbound connections). Search for the same hash on other hosts. If it was blocked on delivery and there is no sign of execution, close with notes. If anything ran, treat it as an incident and escalate.

Escalate when there is confirmed or suspected compromise, a privileged or executive account is involved, there are signs of spread or lateral movement, sensitive data may be affected, ransomware indicators appear, the scope is unclear, the playbook does not cover it, or the SLA is close to breaching. Escalating a borderline case with good notes is better than sitting on it. Include what you checked, what you found, and what you recommend.

The alert and source, timestamps in UTC, affected users and hosts, the queries you ran, evidence with links or screenshots, indicators (IPs, domains, hashes), what you ruled out and why, actions taken, the verdict with reasoning, and next steps. A stranger on the next shift should be able to pick up the case without asking you anything.

It gives a shared vocabulary of attacker tactics (the goals, such as Initial Access, Execution, Persistence, Lateral Movement, Exfiltration) and techniques (the methods). Mapping an alert to a technique tells you what stage of an attack you may be seeing and what to look for next, which makes escalation notes clearer and shows where detection coverage is thin.

• Domains that look randomly generated (high entropy), a sign of domain generation algorithms.
• Bursts of NXDOMAIN responses from one host.
• Very long subdomains or unusual TXT queries, which can mean DNS tunnelling.
• Regular, repeating queries at fixed intervals (beaconing).
• Newly registered or rare domains, and use of a resolver other than the corporate one.

Rare or newly seen domains, direct requests to IP addresses, odd user agents (scripting tools on a normal desktop), large uploads (bytes out much larger than bytes in), connections to file sharing, paste or anonymisation sites, repeated requests at fixed intervals, blocked categories being retried, and TLS to unusual ports. Combine with the user and host to judge whether it fits their role.

A playbook is a documented, repeatable procedure for a type of alert (phishing, malware, brute force). SOAR (Security Orchestration, Automation and Response) codifies playbooks into automated workflows: enrich indicators, query threat intelligence, open tickets, notify users, and take containment actions after approval. It removes repetitive work so analysts spend time on judgment.

Collect details (when it started, what they installed or clicked). Check the EDR and AV for alerts, review running processes, startup items, browser extensions and notification permissions, and recent downloads. Look at the host's network connections and any known-bad destinations. If there is evidence of compromise, isolate and escalate. Ask whether coworkers report the same, and do not dismiss it as "just slow".

Measure first: alerts per analyst, time per alert, and the false positive rate per rule. Then tune the noisiest rules with evidence (tighten logic, add precise, owned and time-limited exclusions), group and deduplicate related alerts, auto-enrich with context, and automate the ten most common benign cases through SOAR. Add a feedback loop so analysts mark why they closed each alert, and let detection engineers fix the causes. Suppressing a rule blindly creates false negatives, so keep a review date on every exclusion.

Look for outbound transfers where bytes out far exceed bytes in, to rare or new destinations, at odd hours, to personal cloud storage or webmail, or to the internet over unusual protocols. Endpoint logs may show an archive (7z, rar, zip) being created just before. DNS logs can show tunnelling. Cloud audit logs show mass downloads or sharing changes. A departing employee or a freshly compromised account raises the likelihood.

You are rarely expected to prove them, but you should recognise the pattern. Kerberoasting shows as one user requesting many service tickets (event 4769) in a short time, often with the older RC4 encryption type. Pass-the-hash shows as network logons (type 3) using NTLM, from a workstation to many hosts, sometimes with logon type 9. Either way, escalate with the evidence and avoid taking disruptive action yourself.

It is the documented record of who handled evidence, when, and what they did, with integrity checks such as hashes. If an incident leads to HR, legal or law enforcement action, evidence without a clean trail may not be usable. For Tier 1 that means: do not alter or delete evidence, save emails and logs in original form, record timestamps, and do not run tools on an affected machine without approval.

Field names depend on how logs are ingested, so check your schema. Two common forms:

// Microsoft Sentinel / KQL
SecurityEvent
| where EventID == 4625 and TimeGenerated > ago(1h)
| summarize Failures = count(), Users = dcount(TargetUserName) by IpAddress
| order by Failures desc

# Splunk / SPL
index=wineventlog EventCode=4625 earliest=-1h
| stats count AS failures dc(Account_Name) AS users BY Source_Network_Address
| sort - failures

A high count with many users from one IP suggests spraying. A high count against one user suggests brute force.

Authentication (directory, identity provider, VPN), endpoint process and command line telemetry (EDR or Sysmon), network (firewall, proxy, DNS), email gateway, cloud audit logs, server and application logs, and DHCP to map IPs to hosts, all with synchronised time (NTP). Gaps mean you cannot scope an incident: you may not know which accounts or hosts were touched, so you must assume the worst. Report log gaps as findings.

The actor has legitimate access, so you compare behaviour with the person's role and baseline: unusual data volumes, off-hours access, access to systems outside their job, use of removable media or personal cloud. Handle it discreetly: involve HR and legal through the proper channel, limit who knows, preserve evidence carefully, and avoid confronting the person. Never act on suspicion alone.

Say so early. Gather what you can (context, related events, threat intelligence), document your reasoning and what is unknown, check the knowledge base, then escalate with a clear question rather than guessing or closing it. A good analyst knows the limits of their knowledge, and the cost of a wrongly closed true positive is far higher than the cost of a quick question.

1. Capture the original message and extract the sender, subject, message ID, URLs and attachment hashes.
2. Run a message trace to find every recipient, then pull or purge the message with approval.
3. Block the sender, domain, URL and hash at the mail gateway, proxy and DNS.
4. Find who clicked (proxy logs, URL rewriting) and whether they entered credentials or downloaded a file.
5. For the user who clicked: check sign-in logs, reset the password, revoke sessions, review mailbox rules, and run an EDR scan.
6. Escalate if any compromise is confirmed, and send a short user advisory.

Check the travel context through a trusted channel, the MFA outcome (a push the user did not request suggests MFA fatigue), the device and its posture, concurrent sessions, and what the session accessed. Because it is an executive, treat it as high priority. If anything looks off, kill the session, reset credentials, and escalate immediately. Contact the person out of band, never through the suspicious session.

Assess the intelligence first: its confidence and age, and whether the IP is shared hosting or a CDN that could cause a false positive. Identify the process making the connection, the data volume, and whether the traffic is regular (beaconing). Check the server's role, and search other hosts for the same destination. If it looks genuine, isolate the server (coordinating with its owner), block the IP, and escalate.

Treat it as critical and escalate to incident response at once. Identify the likely source host from the file owner and last writes, isolate that host and disable the account, and cut its access to the share. Do not reboot or wipe anything, since evidence and memory matter. Check which shares and hosts are affected, confirm the state of backups, preserve the note, and follow the communication plan. Speed in the first minutes limits how much gets encrypted.

Is the source internal or external? Are the failures against one account or many? Is there a success (4624) afterwards, or an account lockout (4740)? What is the timing pattern (steady, bursts)? An internal workstation may be compromised, or a service with stale credentials may be misconfigured. If spraying is likely or a success follows, block or isolate the source, reset the affected accounts, and escalate.

Check for signs of business email compromise: a lookalike domain or display-name spoof, a mismatched Reply-To, urgency and secrecy. If anyone has acted, alert finance and the bank immediately, since a fast recall can recover funds. Search for the same message in other mailboxes, block the sender, and escalate. Verify the request with the executive through a separate known channel, and recommend DMARC enforcement and payment verification controls.

Write a short summary of every open incident and ticket with its status, what has been done, what is pending, approvals needed, key indicators and deadlines. Call out risks and anything that could escalate. Walk the incoming analyst through it, and update the tickets so nothing lives only in your head. A clean handover prevents dropped cases and duplicate work.