SKILLS/performing-alert-triage-with-elastic-siem/SKILL.md
Perform systematic alert triage in Elastic Security SIEM to rapidly classify, prioritize, and investigate security alerts for SOC operations.
npx skillsauth add pinkpixel-dev/skills-collection-2 performing-alert-triage-with-elastic-siemInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Alert triage in Elastic Security is the systematic process of reviewing, classifying, and prioritizing security alerts to determine which represent genuine threats. Elastic's AI-driven Attack Discovery feature can triage hundreds of alerts down to discrete attack chains, but skilled analyst triage remains essential. A structured triage workflow typically takes 5-10 minutes per alert cluster using Elastic's built-in tools.
When viewing an alert in Elastic Security, review the alert details panel:
Alert Details Panel:
- Rule Name and Description
- Severity and Risk Score
- MITRE ATT&CK Mapping
- Host and User Context
- Process Tree (for endpoint alerts)
- Timeline of related events
| Field | Purpose | ECS Field |
|---|---|---|
| Rule severity | Initial priority assessment | kibana.alert.severity |
| Risk score | Quantified threat level | kibana.alert.risk_score |
| Host name | Affected system | host.name |
| User name | Affected identity | user.name |
| Process name | Executing process | process.name |
| Source IP | Origin of activity | source.ip |
| Destination IP | Target of activity | destination.ip |
| MITRE tactic | Attack stage | threat.tactic.name |
FROM logs-endpoint.events.*
| WHERE host.name == "affected-host" AND @timestamp > NOW() - 1 HOUR
| STATS count = COUNT(*) BY event.category, event.action
| SORT count DESC
FROM logs-*
| WHERE user.name == "suspicious-user" AND @timestamp > NOW() - 24 HOURS
| STATS count = COUNT(*), unique_hosts = COUNT_DISTINCT(host.name) BY event.category
| SORT count DESC
FROM .alerts-security.alerts-default
| WHERE source.ip == "10.0.0.50" AND @timestamp > NOW() - 24 HOURS
| STATS alert_count = COUNT(*) BY kibana.alert.rule.name, kibana.alert.severity
| SORT alert_count DESC
FROM logs-system.auth-*
| WHERE source.ip == "10.0.0.50" AND event.outcome == "success"
| STATS login_count = COUNT(*), hosts = COUNT_DISTINCT(host.name) BY user.name
| WHERE hosts > 3
Check indicators against threat intelligence:
FROM logs-ti_*
| WHERE threat.indicator.ip == "203.0.113.50"
| KEEP threat.indicator.type, threat.indicator.provider, threat.indicator.confidence, threat.feed.name
FROM logs-endpoint.events.file-*
| WHERE file.hash.sha256 == "abc123..."
| STATS occurrences = COUNT(*) BY host.name, file.path, user.name
| Classification | Criteria | Action | |---|---|---| | True Positive | Confirmed malicious activity | Escalate to incident, begin containment | | Benign True Positive | Expected behavior matching rule | Document in alert notes, acknowledge | | False Positive | Rule triggered on benign activity | Mark as false positive, create tuning task | | Needs Investigation | Insufficient data for determination | Assign for deeper investigation |
For each triaged alert, document:
Elastic Security includes 1000+ pre-built detection rules organized by:
{
"name": "Multiple Failed Logins Followed by Success",
"type": "threshold",
"query": "event.category:authentication AND event.outcome:failure",
"threshold": {
"field": ["source.ip", "user.name"],
"value": 5,
"cardinality": [
{
"field": "user.name",
"value": 3
}
]
},
"severity": "high",
"risk_score": 73,
"threat": [
{
"framework": "MITRE ATT&CK",
"tactic": {
"id": "TA0006",
"name": "Credential Access"
},
"technique": [
{
"id": "T1110",
"name": "Brute Force"
}
]
}
]
}
Elastic's Attack Discovery automatically:
| Risk Score | Severity | Asset Criticality | Response SLA | |---|---|---|---| | 90-100 | Critical | High | 15 minutes | | 70-89 | High | High | 30 minutes | | 70-89 | High | Medium | 1 hour | | 50-69 | Medium | Any | 4 hours | | 21-49 | Low | Any | 8 hours | | 1-20 | Informational | Any | 24 hours |
| Metric | Target | Measurement | |---|---|---| | Mean Time to Triage (MTTT) | < 10 minutes | Time from alert creation to classification | | False Positive Rate | < 30% | False positives / total alerts | | Escalation Rate | 10-20% | Escalated alerts / total alerts | | Alert Coverage | > 80% | Triaged alerts / generated alerts per shift | | Reclassification Rate | < 5% | Changed classifications / total classified |
tools
Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.
data-ai
Detects lateral movement techniques including Pass-the-Hash, PsExec, WMI execution, RDP pivoting, and SMB-based spreading using SIEM correlation of Windows event logs, network flow data, and endpoint telemetry mapped to MITRE ATT&CK Lateral Movement (TA0008) techniques.
tools
Kubernetes penetration testing systematically evaluates cluster security by simulating attacker techniques against the API server, kubelet, etcd, pods, RBAC, network policies, and secrets. Using tools
testing
Assess the security posture of Kubernetes etcd clusters by evaluating encryption at rest, TLS configuration, access controls, backup encryption, and network isolation.