What interviewers are actually testing
SOC interviews for L1 and L2 roles rarely test obscure trivia. They test whether you can look at a log line and know what it means, and whether you reason calmly from evidence to a decision. The fundamentals below come up again and again. Know them well enough that you do not have to think about them, so your thinking goes to the scenario.
If you are earlier in the journey, start with the SOC analyst career roadmap. If a term below is unfamiliar, the glossary has short definitions, and the cheatsheets collect most of this in reference form.
Ports and protocols
You should be able to name the service on these ports without hesitation, and say why each one matters to a defender. The full list lives on /cheatsheet/ports.
| Port | Service | Why a SOC cares |
|---|---|---|
| 22/tcp | SSH | Brute force, lateral movement on Linux, tunnelling |
| 25/tcp | SMTP | Mail relay, spam, exfiltration via mail |
| 53/udp+tcp | DNS | C2 over DNS, tunnelling, DGA lookups |
| 80, 443/tcp | HTTP, HTTPS | Most C2 and exfiltration hides here |
| 88/tcp | Kerberos | Kerberoasting, golden and silver tickets |
| 135/tcp | MS RPC | Remote management, WMI, lateral movement |
| 389, 636/tcp | LDAP, LDAPS | AD reconnaissance |
| 445/tcp | SMB | Lateral movement, ransomware spread, PsExec-style execution |
| 3389/tcp | RDP | External exposure, brute force, hands-on-keyboard access |
| 5985, 5986/tcp | WinRM | PowerShell remoting, lateral movement |
Know the difference between TCP and UDP, the three-way handshake (SYN, SYN-ACK, ACK), and what a SYN without a reply suggests in a firewall log (filtered port, scan, or a down host).
HTTP status codes
Web proxy and WAF logs are full of these. Know the classes and the security-relevant codes; /cheatsheet/http-status-codes has the full list.
| Code | Meaning | Analyst reading |
|---|---|---|
| 200 | OK | Request succeeded. For a scanner hitting /admin, that is bad news |
| 301, 302 | Redirect | Phishing chains, open redirects |
| 401 | Unauthorized (not authenticated) | Many in a row: brute force or credential stuffing |
| 403 | Forbidden (authenticated or not, access denied) | Probing for protected paths |
| 404 | Not found | Bursts across many paths indicate content discovery scanning |
| 429 | Too many requests | Rate limiting doing its job |
| 500 | Server error | Injection attempts sometimes trigger these; a 500 after a payload is worth a look |
A classic interview question: "You see thousands of 404s from one IP, then a 200 on /backup.zip. What happened?" Answer: directory brute forcing that found a real file. The 200 is the event that matters; check the response size and what that file contains.
Windows event IDs
This is the section most interviews dig into. Know these from the Security log:
| Event ID | Meaning | Typical use |
|---|---|---|
| 4624 | Successful logon | Who logged on where, with which logon type |
| 4625 | Failed logon | Brute force, password spraying |
| 4634 / 4647 | Logoff / user-initiated logoff | Session duration |
| 4648 | Logon with explicit credentials | runas, some lateral movement tools |
| 4672 | Special privileges assigned to new logon | Admin-equivalent logons |
| 4688 | Process creation | Command lines (if enabled), parent/child chains |
| 4697 | Service installed | Persistence, PsExec-style execution |
| 4698 | Scheduled task created | Persistence |
| 4720 | User account created | Backdoor accounts |
| 4728 / 4732 / 4756 | Member added to global / local / universal security group | Privilege escalation |
| 4768 / 4769 | Kerberos TGT / service ticket requested | Kerberoasting (many 4769s with RC4 encryption) |
| 4776 | NTLM credential validation | NTLM brute force, pass-the-hash context |
| 1102 | Security audit log cleared | Anti-forensics, almost always worth an alert |
From the System log, 7045 (new service installed) is also worth knowing.
Logon types
When you discuss 4624 or 4625, the logon type is half the story:
| Type | Meaning |
|---|---|
| 2 | Interactive (at the keyboard) |
| 3 | Network (SMB share, many remote tools) |
| 4 | Batch (scheduled tasks) |
| 5 | Service |
| 7 | Unlock |
| 8 | NetworkCleartext (credentials sent in clear, for example basic auth) |
| 9 | NewCredentials (runas /netonly) |
| 10 | RemoteInteractive (RDP) |
| 11 | CachedInteractive (cached domain credentials) |
4625 failure reasons
The Status/SubStatus code tells you why a logon failed. Two to remember: 0xC000006A means the username exists but the password was wrong; 0xC0000064 means the username does not exist. Many failures with 0xC0000064 across different usernames suggests enumeration or spraying with a guessed user list. Many failures with 0xC000006A against one account suggests brute force against a real user.
Answer event ID questions with a pattern, not just a definition. "4625 is a failed logon" is a definition. "Many 4625s with logon type 3 from one source across many accounts, followed by a 4624 from the same source, looks like password spraying that succeeded" is what the interviewer wants to hear.
Sysmon event IDs
Sysmon gives richer telemetry than native logs. Know the main ones:
| Sysmon ID | Event |
|---|---|
| 1 | Process creation (with hashes and full command line) |
| 3 | Network connection |
| 7 | Image loaded (DLL) |
| 8 | CreateRemoteThread (injection indicator) |
| 10 | ProcessAccess (for example, access to lsass.exe, credential dumping) |
| 11 | File created |
| 12 / 13 / 14 | Registry object created or deleted / value set / key or value renamed |
| 15 | FileCreateStreamHash (alternate data streams, Mark of the Web) |
| 22 | DNS query |
| 23 | File delete (archived) |
A strong answer links IDs: "Sysmon 1 shows winword.exe spawning powershell.exe with an encoded command, Sysmon 3 shows that PowerShell process connecting out, Sysmon 11 shows a file written in AppData." That is an attack chain from three events. Our article on detecting LOLBins goes deeper into the process creation patterns.
Regex you should be able to write
You will be asked to write or read a simple pattern. Practise on /tool/regex and keep /cheatsheet/regex nearby.
IPv4 (loose): \b(?:\d{1,3}\.){3}\d{1,3}\b
Email (loose): [\w.+-]+@[\w-]+\.[\w.-]+
Encoded PowerShell: (?i)powershell(\.exe)?\s+.*-e(nc|ncodedcommand)?\s+[A-Za-z0-9+/=]{20,}
SHA-256: \b[a-fA-F0-9]{64}\b
Know the limits: the IPv4 pattern also matches 999.999.999.999. Being able to say "this is deliberately loose, I would validate matches afterwards" shows judgement. Our regex guide for security analysts covers the common traps.
CIDR and subnetting
Expect at least one subnet question. Memorize:
| CIDR | Addresses | Usable hosts |
|---|---|---|
| /32 | 1 | single host |
| /30 | 4 | 2 |
| /29 | 8 | 6 |
| /28 | 16 | 14 |
| /24 | 256 | 254 |
| /16 | 65,536 | 65,534 |
And the private ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Interview favourite: "Is 172.20.5.4 private?" Yes, 172.16.0.0/12 spans 172.16.0.0 to 172.31.255.255. Check your own answers with the CIDR calculator until you can do them in your head.
Sample interview questions and how to answer them
"Walk me through how you would triage a phishing report." Structure beats detail. Check headers (sender, return path, SPF/DKIM/DMARC results), extract and enrich URLs and attachments, determine whether anyone clicked or replied, scope (who else received it), contain (purge, block), document. Mention you would never open the attachment on your workstation. Our phishing email analysis guide follows this structure.
"You see event 1102 on a domain controller at 03:00. What do you do?" Treat it as suspicious until proven otherwise. Identify the account that cleared it (it is in the event), check for change tickets, look at what happened just before (other hosts' logs, EDR telemetry, the SIEM copy of the logs that were cleared locally), and escalate. Saying "the SIEM still has the forwarded events" shows you understand log architecture.
"What is the difference between a true positive, a false positive and a benign true positive?" True positive: the rule fired and the activity is malicious. False positive: the rule fired on activity that does not match what it intends to detect. Benign true positive: the rule correctly detected the behaviour, but it is authorized (an admin running a pentest tool with approval). The last one is where tuning conversations start.
"An IP in an alert is on a threat intel blocklist. Is the host compromised?" Not necessarily. Ask what the connection was (DNS only, a blocked attempt, a completed session with data transfer), how old and how reliable the indicator is (shared hosting and CDN IPs go stale fast), and what the host did before and after. Indicators are leads, not verdicts.
"How would you explain an incident to a non-technical manager?" What happened, what the impact is, what has been done, what is needed from them. Four sentences, no jargon.
For L2 roles, expect deeper scenarios: a 4769 burst with RC4 encryption type (Kerberoasting), Sysmon 10 targeting lsass.exe (credential dumping), a new service on many hosts at once (remote execution or ransomware staging). Be ready to propose both a containment step and a detection to catch it next time.
"I don't know, but here is how I'd find out" is a good answer. Interviewers prefer an honest gap plus a sensible method over a confident guess. Name the log source you would check and what you would look for.
The night-before checklist
- [ ] Name the service for the ten ports above, without notes.
- [ ] Recite 4624, 4625, 4688, 4720, 4672, 1102 and logon types 2, 3, 10.
- [ ] Explain the difference between 0xC000006A and 0xC0000064.
- [ ] Link Sysmon 1, 3, 10 and 11 into an attack story.
- [ ] Write an IPv4 and a SHA-256 regex from memory.
- [ ] Calculate hosts in a /27 and say whether
172.31.0.1is private. - [ ] Rehearse phishing triage as a five-step answer.
- [ ] Prepare one real investigation from your labs to talk through end to end.
Knowing the fundamentals cold is what frees you to think in the interview. Revise the tables, then spend the rest of your time explaining scenarios out loud.
