Hey, I’m Karan.
I turn signals
into stories.
A SOC analyst focused on detection engineering. I build, test, and tune the alarms that make an attacker’s next move harder.
Curious by default. Evidence first.Tier 1 SOC · Security operations · Vulnerability management
Detections
Real lab traffic. Tested rules. Lessons from the alerts that fired—and the ones that didn’t. Explore four rules and one incident walkthrough from a nine-rule lab.
SEV-1 Suspicious memory access to LSASS 40+/day → 0
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.
Stack
Write-up on GitHub →SEV-2 Encoded PowerShell command line 0 FP / 2 wks
What fired
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.
Stack
Write-up on GitHub →SEV-2 Periodic outbound connection, low jitter <5s stddev
What fired
Same internal host, same external IP, connections about every 60 seconds with very little variance and near-identical payload sizes.
Detection logic · illustrative pseudocode
zeek.session_id : * and network.protocol : "http" | stats count(), stddev(interval) by source.ip, destination.ip | where stddev < 5 and count() > 30
Why network data
This never touches an endpoint agent. If the host is compromised its own logs are suspect, so I run Zeek alongside Sysmon rather than picking one.
Stack
Write-up on GitHub →SEV-3 SMB exploitation attempt against legacy host gap found
What fired
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.
Stack
Write-up on GitHub →CASE Full intrusion chain, five stages 5 stages
What this is
One simulated intrusion, in the order I saw it, with the call I made at each stage.
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.
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 gapCredential 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.
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 resetWrite-up and rule changes
Documented the chain, added the missing discovery rule, and re-ran the same attack to confirm it fired.
→ One new rule, one tuned, one gap closedCoverage
18 techniques mapped. Nine tested, six with telemetry, and three known gaps. Select a technique for the evidence.
Initial access
Execution
Persistence
Credential access
Lateral movement
Command and control
Experience
From resolving support tickets to investigating the story behind an alert.
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
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
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
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.
Watch the attack. Follow the evidence.
One intrusion, five decisions. Follow the attacker across the lab, then watch the evidence become an investigation.
Document → workstation → Sysmon → SIEM alert
Simulated attacker
Lab-controlled intrusion
Malicious documentWIN-WKS02
Office → PowerShell
Execution detectedWIN-DC01
Domain credentials
Not involved yetZeek + pfSense
Independent network view
Watching connectionsElastic SIEM
Sysmon + network evidence
Parent-process alertSecond host
SMB admin shares
Not involved yetA document spawns PowerShell with an encoded command on the workstation.
Sysmon Event ID 1 records the parent and child processes. The parent-process rule fires.
Confirm the true positive and recommend isolating the workstation.
Explore the full lab setup Hosts, telemetry, and the Linux blind spot ↗
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
Selected hosts and collectors, and how their logs 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.
Microsoft Sentinel
A proposed cloud detection lab: follow a Windows event from the host to an incident an analyst can investigate.
From a failed sign-in to an investigation
Illustrative architecture · no deployed rules or results claimed yet
Start with an event you can explain.
Proposed exercise: generate failed Windows sign-ins in an isolated test environment. Event 4625 is the starting evidence, not proof of an attack by itself.
Planned investigation
Repeated failed sign-ins from one source. Establish a baseline, inspect the account and source, then test an alert threshold.
Evidence to publish
Connector health, a sample event, the tested query, an incident walkthrough, and false-positive tuning notes.
Response boundary
Analyst review first. An optional Logic Apps playbook could enrich or notify; automated containment is not part of this proposed flow.
See the proposed detection logic Kusto · illustrative threshold
This example is not a tested lab result. Confirm field population, audit policy, collection, and normal traffic before setting an alert threshold.
SecurityEvent
| where TimeGenerated > ago(15m)
| where EventID == 4625
| where isnotempty(IpAddress) and IpAddress != "-"
| summarize FailedAttempts = count()
by Account, IpAddress, bin(TimeGenerated, 5m)
| where FailedAttempts >= 10Detailed build & validation plan
- Prepare the isolated labCreate a Windows test VM and a Log Analytics workspace with Microsoft Sentinel enabled. Restrict administrative access and use dedicated test accounts. Set a budget and retention limit before collecting events.
- Connect and verify telemetryInstall the Windows Security Events solution, configure its AMA connector and data collection rule, and verify Event 4625 reaches SecurityEvent. Check timestamps, Account, Computer, and IpAddress before writing a rule.
- Build and test the detectionGenerate a controlled sequence of failed sign-ins with your own test accounts. Compare it with ordinary mistakes. Tune the query window and threshold, then create a scheduled analytics rule with account and IP entity mapping. Review overlapping windows and alert grouping to avoid duplicate incidents.
- Investigate and documentConfirm that the alert creates an incident. Inspect the account, source address, and event timeline. Record a true-positive and a benign example, along with the tuning changes. Publish sanitized evidence without credentials, public endpoints, or account identifiers.
- Add response after the basics workOptionally connect an automation rule to a Logic Apps playbook for enrichment or notification. Test permissions and failure handling; keep containment a reviewed analyst decision.
| Test | What to verify | Evidence to keep |
|---|---|---|
| One ordinary failed sign-in | Event arrives; no threshold alert | Sanitized event record |
| Repeated failures in one window | Query matches and a configured rule alerts | Query output + incident |
| Benign repeated mistakes | Analyst can explain and tune the noise | Before/after tuning notes |
| Agent stops sending | Identify missing telemetry separately from no attacks | Connector/agent health evidence |
Architecture references: Windows events via AMA · SecurityEvent collection · Sentinel playbooks
Technical stack
Elastic SIEM
Kibana
Splunk
Sysmon
Zeek
Wireshark
Nmap
pfSense
Kali Linux
Metasploit
Active Directory
Windows Server
Azure
PowerShell
Python
Bash
MITRE ATT&CK
Docker
Security Onion
Git
ServiceNow
Claude
ChatGPT- Codex
AI-assisted workflow · ChatGPT, Codex, and Claude for learning, coding, and documentation.
Learning & credentials
SOC and incident response first. Each course-completion badge links to its verification on Credly.
SOC in PracticeIBM SkillsBuild
Incident Response & ForensicsIBM SkillsBuild
CCNA: Enterprise NetworkingCisco Networking Academy
Generative AI FoundationsAWS Academy
Build an AI AgentIBM SkillsBuild
CompTIA CySA+ (CS0-004) is booked and in progress. That one's a proctored exam; the badges above are course completions.
A good conversation
starts with hello.
Have a role, a project, or a question in mind? Write your message here, then send it from your email app.
Let’s start a conversation.
sonikaran8899@gmail.com ↗