I'm a SOC analyst focused on detection engineering. I built a seven-host home lab, wrote nine detections mapped to MITRE ATT&CK, then attacked the environment myself to prove the rules worked.
My favourite part is connecting the evidence: encoded PowerShell, credential access, then lateral movement. Separate events become one explainable incident—and a decision an analyst can defend.
AI helps me move faster, not skip the proof. I use ChatGPT, Codex and Claude for threat research, query prototyping and incident documentation. Every conclusion still has to survive the raw logs, a repeatable attack and human review.
Before this: contract IT support — Active Directory, Windows Server, and the particular patience required by a printer that works for everyone except one guy in accounting. CompTIA CySA+ exam booked. Based in Oshawa, Ontario.
Open to work — Tier 1 SOC, security operations, vulnerability management
AI in the analyst loop
AI shortens the path from an alert to a testable hypothesis. Telemetry decides whether the hypothesis is true.
Investigate
Turn scattered events into a timeline and surface questions worth checking.
Build
Draft KQL, Python and detection logic faster, with assumptions made explicit.
Validate
Replay the attack, inspect source events and measure false positives.
Document
Convert findings into a clear incident record, rule notes and next actions.
Operating rule: AI output is a lead, never evidence. I verify fields, timestamps and logic against the original telemetry, keep sensitive data out of prompts and record what was tested.
Detections
Rules I wrote in my lab. Open one to see the query, what I tuned, and why.
Elastic SIEM · lab.internal[░░░░░░░░░░░░░░]
What fired
A process opened a handle to lsass.exe with read-memory access rights. Credential dumpers need that access. Very little else asks for it.
The rule
event.code : "10"
and winlog.event_data.TargetImage : "*\\lsass.exe"
and winlog.event_data.GrantedAccess : ("0x1010" or "0x1410" or "0x143a")
and not process.executable : ("*\\MsMpEng.exe" or "*\\wmiprvse.exe")
What tuning taught me
The first version fired 40+ times a day on Defender and WMI. I filtered on the granted-access mask instead of the process name. A renamed dumper still needs the same access rights, so the rule still catches it.
PowerShell launched with -enc and a base64 blob. Encoding alone isn't suspicious; plenty of management tooling does it. The rule keys on the parent process instead.
The rule
process.name : "powershell.exe"
and process.command_line : ("*-enc*" or "*-EncodedCommand*")
and process.parent.name : ("winword.exe" or "excel.exe"
or "outlook.exe" or "wscript.exe")
Why the parent matters
An Office app spawning an encoded shell is the macro chain. Scoping to those four parents dropped false positives to zero across two weeks of lab traffic.
I ran the attack myself: Metasploit against the vulnerable host, then back to the console cold to see what the stack had caught.
The gap it exposed
Zeek flagged the exploit traffic. The endpoint side showed nothing, because the target is Linux and I hadn't put an agent on it. That gap is now on the coverage map.
One simulated intrusion, in the order I saw it, with the call I made at each stage.
T+00:00
Macro-borne execution on a workstation
Sysmon EID 1 shows winword.exe spawning powershell.exe with an encoded command. The parent-process rule fires within seconds.
→ Confirmed true positive, isolate host
T+00:04
Discovery, quiet and unalerted
The shell enumerates domain users and local groups. Nothing fired: I had the telemetry but no rule. Discovery needs volumetric rules, not signatures.
→ Documented as detection gap
T+00:11
Credential access on the domain controller
A handle opens against lsass.exe with dump-capable access rights. At this point it stops being a workstation problem.
→ Escalate, assume domain credentials exposed
T+00:19
Lateral movement over SMB
Zeek shows admin-share access to a second host minutes after the credential theft. The SMB session alone would have been ambiguous; the sequence isn't.
→ Contain both hosts, force credential reset
T+01:30
Write-up and rule changes
Documented the chain, added the missing discovery rule, and re-ran the same attack to confirm it fired.
Mapped to MITRE ATT&CK. Gaps included, because I have some.
0
hosts in the lab
0
techniques mapped
0
detections tested
0
documented gaps
✓Written and tested~Telemetry, rule not tuned·Known gap
Initial access
Execution
Persistence
Credential access
Lateral movement
Command and control
Pick a technique to see what the lab does about it.
Experience
Roughly in reverse. The useful bits, not the job descriptions.
2026 — now · Oshawa
Blue team track — mentored, 10–15 hrs a week
I gave myself sixteen weeks and a stack of VMs. What came out the other end is the lab this whole site is about: 9 rules written, tuned and verified by attacking my own network, 18 techniques mapped, and 3 gaps I can name out loud. The gaps took longer to find than the detections. CySA+ sits at the end of it, booked.
Elastic SIEM
Sysmon
Zeek
KQL
MITRE ATT&CK
Sep 2025 — now · independent
Security Health Check — my own thing
Small businesses with no IT person, which in practice means one laptop holding the whole company and a router nobody has logged into since it was installed. I check identity hygiene, patching, endpoints, backups and what's exposed to the internet, then write it up in language the owner can act on. Nothing goes in a report until I've tested it in my own lab first.
Assessments
Threat intel
Reporting
Jan — Aug 2025 · Oakville
IT Support Technician at Logic Play Web Solutions
Eight months of tickets — 60+ a month through ServiceNow and Jira, 90% closed first contact. A lot of it was Active Directory: permissions nobody had reviewed in years, onboarding that ran on tribal knowledge. I wrote the runbooks mostly so I'd stop answering the same question twice, and mean response time fell 20%. That's also where I learned to read a packet capture, which turned out to matter more than anything else on this list.
Active Directory
Windows Server
Azure AD
PowerShell
ServiceNow
Jira
School
Cybersecurity Graduate Certificate at Durham College
Splunk forwarders, Zabbix SNMP, joining Linux boxes to a Windows domain with SSSD and Kerberos, standing up a PKI with AD Certificate Services. Before that, a Network Management diploma at LaSalle and a Bachelor of Computer Applications.
Cisco Networking Academy — CCNA: Enterprise Networking, Security and Automation, Jan 2025. The course certificate, not the 200-301 exam — that one I'm still working on, and I'd rather say so than let you assume.
The lab
Seven hosts, set up and logged by me.
lab.internal/
├── siem/ elastic 8.x · kibana · fleet server
├── endpoint/ sysmon · elastic agent
├── network/ zeek 6.x · conn, dns, http, ssl
├── perimeter/ pfsense ce · attack | victim | monitor
├── identity/ windows server ad · ad cs · gpo · sssd
├── offense/ kali linux · metasploit
├── targets/ metasploitable 2
└── secondary/ security onion 2.4 · splunk uf · zabbix
Telemetry reaching the SIEMNetwork data only — no endpoint agent
Every host in the lab, and how its logs actually get to Elastic. The dashed line is the gap I found the hard way: Metasploitable is Linux and never got an agent, so when I ran the SMB exploit against it, Zeek saw the traffic and the endpoint side saw nothing at all.
Security Onion runs in EVAL mode because of RAM limits. Zabbix monitoring broke early on from DHCP-driven IP drift, which is how I learned to pin the monitored hosts.
Planned lab · validation pending
Microsoft Sentinel lab
The next build: detect a controlled password-spray pattern, turn it into a Sentinel incident and document the analyst decision at each stage.
Simulated attackControlled failed sign-ins
Windows eventsSecurity Event 4625
AMA + DCRCollect and route
Analytics ruleGroup by account and IP
IncidentEntities, triage and evidence
Proposed detection
SecurityEvent
| where TimeGenerated > ago(15m)
| where EventID == 4625
| where isnotempty(IpAddress) and IpAddress != "-"
| summarize FailedAttempts=count()
by Account, IpAddress, bin(TimeGenerated, 5m)
| where FailedAttempts >= 10
Build and proof plan
Connect an isolated Windows test VM through Azure Monitor Agent and a Data Collection Rule.
Confirm the expected fields arrive in the SecurityEvent table.
Generate controlled failures, tune the threshold and document normal noise.
Create the scheduled analytics rule, map account and IP entities, then verify the incident timeline.
Publish screenshots and results only after the test is repeatable.
Why it is marked planned: the architecture and query are ready to build, but no production claim is made until ingestion, detection and incident creation are verified end to end.
Technical stack
Certifications and credentials
Verified on Credly. The security badges support the SOC work; the AI credentials support the workflow I use to research, prototype and document it. Click any badge to check it at the source.
