🎓 Career corner

Learn to read an appliance's own logs: the edge device is part of your scope

This week's Check Point zero-day ran entirely on the firewall itself: attackers came in through the VPN portal, became root through a local socket, and dropped webshells where an endpoint agent never sees them. Many SOCs only watch firewall traffic logs, not the appliance's own system logs. Practice closing that gap:

1. Know what the box logs: pick one appliance you can run in a lab (pfSense, OPNsense, or a vendor trial VM) and list which of its system, auth and admin logs can be forwarded by syslog.
2. Learn the normal: log in, change a setting, run a CLI command, then find each action in those logs. Note exactly what legitimate admin activity looks like.
3. Write the abnormal rule: alert on admin commands from accounts or sources that never do admin work, new files in web directories, and logging gaps (a crashed log service is a classic cover-up).
4. Explain the risk: edge devices sit outside EDR coverage, so their own logs are often the only witness.

In interviews, saying "I'd check the appliance's system logs, not just its traffic logs" shows you think like an attacker who targets the perimeter.

Learn to spot NTLM hash leaks: outbound SMB to the internet is your tell

Today's Outlook zero-day (CVE-2026-124194) is a classic: open a crafted file, Windows tries to authenticate to an attacker's server, and the user's NTLMv2 hash walks out the door. Practice catching this pattern once and you will recognize it for the rest of your career:

1. Know the tell: workstations almost never need to talk SMB (TCP 445/139) to a public IP. An Office app or browser doing it is suspicious by default.
2. Find it in your lab: filter firewall or EDR network logs for destination port 445 where the destination is not a private range, then group by host and process.
3. Ask the triage questions: which process made the connection, did the user just open an attachment, and which account was logged on? That account's password is the one at risk.
4. Know the response: reset that user's password, confirm outbound 445 is blocked at the perimeter, and check for sign-ins from new locations using that account.

Being able to explain why outbound SMB matters, in plain words, is a great interview answer because it shows you understand how credentials actually get stolen.

Write a one-page SOC runbook for one alert you can explain end to end

Interviewers for SOC roles love one question: "Walk me through how you would handle this alert." Prepare one answer on paper this week:

1. Pick one alert: for example a VPN login that bypassed MFA, like the SonicWall SAML flaw in today's Patch Now list.
2. Write the triage steps: what log you open first, which fields you check (user, source IP, auth method, time), and what makes it benign versus suspicious.
3. Add the decision points: when you close it, when you escalate, who you escalate to, and what you preserve (logs, session IDs, screenshots).
4. Add one containment action: disable the account, revoke sessions, block the IP, and say what approval you would need.

Keep it to one page and practice saying it aloud in two minutes. A short, structured runbook shows ticket discipline, which is what hiring teams cannot teach quickly.

Turn every playbook hunt query into a saved search you own

Junior analysts often read hunt queries and move on. Hiring managers want proof you can operationalize them. Pick one Patch Now playbook this week and do this:

1. Port it: paste the Splunk SPL or Sentinel KQL into your lab (or a free trial), fix field names to match your data, and confirm it returns something sane.
2. Save it: turn the tuned query into a named saved search or analytics rule with a short description, severity and the MITRE IDs from the playbook.
3. Document the false positives: write three lines on what noise you saw and how you filtered it—that is the part interviewers probe.
4. Show the work: put the before/after query and the FP notes in a private GitHub gist or lab write-up you can talk through.

One tuned, documented hunt beats ten unread bookmarks. It shows you can take vendor or public guidance and make it detect something in your logs.

Write your own phishing triage checklist, then practice it

Reported phishing is one of the most common tickets a junior analyst works. Interviewers often ask “walk me through how you'd handle a reported phishing email.” Have a repeatable answer:

1. Headers: check SPF, DKIM and DMARC results, and compare the From, Reply-To and Return-Path domains.
2. Links and attachments: never click. Detonate them in a sandbox such as urlscan.io or VirusTotal and note the verdicts.
3. Scope: search mail logs for everyone else who got the same sender, subject or URL.
4. Impact: check proxy or DNS logs to see who clicked, and sign-in logs for anyone who may have entered credentials.
5. Contain and document: purge the messages, block the sender and URL, reset any exposed passwords, and write a short ticket summary.

Practice it on real samples from a public phishing dataset or your own spam folder, and keep the checklist in your GitHub. It shows you think in steps, which is what SOC leads want to hear.

Build a home lab before your first SOC interview

Hiring managers want proof you can work with real logs and alerts. A home lab gives you something concrete to talk about. Two free ways to start:

• Security Onion: a free, open-source platform for network security monitoring and log management. Run it in a VM and watch your own traffic.
• Splunk Enterprise free trial: ingest logs from your own machines and practice writing searches, like the hunt queries in our Patch Now playbooks.

Then write up one investigation and put it on your résumé or GitHub.