I work the alerts, and I write the detections that raise them.
Blue team. Most of my hours go where a SOC actually lives: Sysmon and Windows event logs, AD authentication, PowerShell activity, Splunk searches that start as a hunch and end as a rule.
Cloud isn't a separate track for me — it's another log source on the same console. A role session hitting CloudTrail from an address that has no business holding those credentials is the same investigation I'd run on a workstation, with different field names. Being able to follow the attacker across both is the part that stopped me being a beginner.
The loop I enjoy: run the technique in my lab, find it in the logs, write it in Sigma or SPL, then break my own rule until it survives contact with normal traffic. Half of detection engineering turns out to be deleting rules that were never going to fire cleanly. Everything below is the working record of that.
SOC-Log-Analysis-Datasets — Windows, web, firewall, and cloud logs with attack vectors embedded, MIT licensed. Curated synthetic dataset across 5 security domains with 35+ ⭐ stars and a hands-on hunting playbook.
the-10-task-to-master-wazuh — 10 enterprise detection engineering & threat hunting challenges: AWS CloudTrail, Real-Time FIM differential analysis, custom PCRE2 rules, VirusTotal CTI, Active Defense containment, and OpenSearch Dev Tools REST querying.
enterprise-threat-detection-soc-lab — My SOC lab, end to end: endpoint and cloud telemetry ingestion, custom Splunk SPL detections, attack emulation mapped to ATT&CK. The whole pipeline, not a rule in isolation.
active-directory-soc-lab — Enterprise Active Directory infrastructure on Windows Server 2022: forest root, multi-master replication with ADC, AD-integrated DNS/DHCP, GPO WMI filtering, and advanced audit policies ready for SOC threat detection.
soc-investigation-casefiles — Hands-on Tier-1 SOC alert triage and investigation case files: evidence timelines, disproving benign hypotheses, IOC extraction, and containment playbooks.
My-Portfolio_Website — Evidence-first defensive security portfolio hosted live on GitHub Pages: interactive physics-based pull-cord theme switch, verified technical case files, and responsive industrial design.
Techniques I've run end to end: executed the behaviour, pulled the telemetry, wrote the rule, tuned out the noise.
| Technique | ATT&CK | Telemetry | Detection logic |
|---|---|---|---|
| RDP & SSH Brute Force | T1110.001 | Windows 4625/4624 & Linux /var/log/secure |
Event correlation tracking failure surges followed by success + dynamic firewall-drop |
| Encoded PowerShell Execution | T1059.001 | Sysmon EID 1, Windows 4688 | Obfuscated Base64 CLI flags (-e, -ec, -enc, pwsh.exe) spawned by non-standard parents |
| AWS IAM User Creation | T1136.003 | CloudTrail (aws-s3 wodle) |
Root/privileged ARN invoking CreateUser via AWS Management Console or CLI |
| System Binary Integrity Tampering | T1565.001 | Linux syscheck FIM (inotify) |
Real-time differential diff alerts on unexpected file modifications in /usr/bin/ |
| Malicious Payload Drop + CTI Enrichment | T1203 | FIM hash → wazuh-integratord |
Automated VirusTotal API lookup matching known malicious hashes (e.g. EICAR 66/68 detection) |
| Network Service Discovery | T1046 | Suricata eve.json NIDS |
Port scan signature (Rule 86601) paired with scoped child suppression (Rule 100060) |
Detection rule example from the lab (Sysmon Encoded PowerShell execution):
title: Suspicious Encoded PowerShell Execution
status: experimental
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 1
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
CommandLine|contains:
- ' -e '
- ' -ec '
- ' -enc '
- ' -encodedcommand '
condition: selection
level: high
falsepositives:
- Legitimate administrative orchestration scripts (verify parent process lineage before escalating)Directly correlates with the telemetry and hunting queries proven across the Splunk and Wazuh repositories.
SIEM & Detection
Endpoint & Identity
Triage & Analysis
Network & Traffic
Cloud Telemetry
Automation & Tooling
Frameworks & Process
Scope before anything else. One host or many, one identity or many. That answers whether this is a ticket or an incident.
Look for what disproves me. Writing down the benign explanation first stops me from building a story around the first suspicious field I see.
Enrich, then escalate. Identity, owner, change history, reputation. An escalation with no context is a forwarded email.
Verdict with a confidence level. "Likely benign, medium confidence, here's what would change my mind" hands off cleanly. "Suspicious" doesn't.
Every false positive is a tuning ticket. A rule nobody trusts is worse than no rule.
- Growing the lab's detection library and writing each case up as I close it
- Splunk Core Certified Power User, in progress
- Rebuilding public detection rules in my own environment to find where mine are weaker
Open to SOC analyst and detection engineering work — remote or relocating. Happy to walk through any case file in the-10-task-to-master-wazuh.


