MITRE ATT&CK overview

How AlertKick's eBPF security events map onto the MITRE ATT&CK framework - what the tactics and techniques mean, and how to use them when triaging.

Updated

MITRE ATT&CK is a public catalogue of how attackers actually behave once they’re inside a system. It groups behaviour into tactics (the why - “persistence”, “privilege escalation”) and techniques (the how - “create or modify systemd service”, “abuse sudo”). AlertKick’s eBPF security pipeline tags every event with the relevant tactic and technique codes, so when you see an alert you immediately know what part of the kill-chain it’s on.

Why this matters

A raw eBPF event by itself (“process X opened /etc/shadow”) is hard to triage without context. The same event might be a legitimate password tool, an attacker enumerating credentials, or a misconfigured monitoring agent. The MITRE mapping doesn’t tell you which of those it is, but it does tell you:

  • What stage of an attack this would be - early reconnaissance behaves very differently from late-stage exfiltration
  • What to look for next - each technique has documented follow-ons in the catalogue
  • Whether multiple events are related - events tagged with adjacent tactics on the same host within a short window suggest a chain, not noise

How the mapping works

Every event that comes out of the agent’s eBPF probes is run through the detection ruleset. Matching rules contribute MITRE tactic/technique codes to the event, stored as:

{
  "mitre_tactics":    ["TA0003", "TA0004"],
  "mitre_techniques": ["T1543.002", "T1548.001"]
}

A single event can carry multiple tactics (it’s normal for “persistence” and “privilege escalation” to co-occur). The dashboard renders tactic codes as short labels on each event; click one to filter the timeline to other events tagged with the same tactic.

The tactics, in plain English

CodeTacticWhat it means in practice
TA0001Initial AccessFirst foothold - a successful exploit or stolen credential
TA0002ExecutionRunning attacker code on the host
TA0003PersistenceSurviving a reboot or a process kill
TA0004Privilege EscalationGoing from a regular user to root (or root to kernel)
TA0005Defense EvasionHiding from logging, AV, or auditing
TA0006Credential AccessStealing passwords, keys, or session tokens
TA0007DiscoveryLooking around - what’s installed, who’s logged in
TA0008Lateral MovementHopping from one host to another
TA0009CollectionGathering files or data of interest
TA0010ExfiltrationSending the collected data out
TA0011Command and ControlTalking to an external server for instructions
TA0040ImpactDestruction, encryption, or disruption

Reading an event

A typical AlertKick eBPF event looks like:

Host:        api-prod-04
Process:     /usr/bin/cron -> /tmp/.x/runner (parent -> child)
User:        www-data (uid=33)
Tactics:     Persistence (TA0003), Defense Evasion (TA0005)
Techniques:  T1053.003 (Scheduled Task/Job: Cron),
             T1564.001 (Hide Artifacts: Hidden Files and Directories)
Verdict:     suspicious (AI)

The tactics narrow what the attacker’s trying to do; the techniques describe the specific method. T1053.003 is “Cron” specifically - useful to know when writing a follow-up rule that only fires on crontab modifications from web-server users.

How to use this during an incident

  1. Look at the tactic, not just the rule - a single rule firing tells you one thing happened. A cluster of events tagged “Discovery” -> “Lateral Movement” -> “Credential Access” on the same host inside ten minutes is the shape of an actual intrusion.
  2. Filter by technique to find related events - click the technique chip in the event detail to surface every other event on every host that matched the same technique. Helpful for confirming whether one machine is compromised or several.
  3. Cross-reference the MITRE site - every technique code links out to attack.mitre.org. The pages there have detection ideas, mitigations, and observed-in-the-wild examples that map cleanly to what you’re seeing in AlertKick.

What’s not tagged

Not every event gets a tactic. Things like “high CPU usage” or “disk full” are infrastructure signals, not attacker behaviour, and they intentionally don’t get a MITRE label. If you see an event with no tactics but a high AI verdict, it’s probably something the rule engine flagged for shape rather than for malicious intent - read the rule description for context.

Next steps

  • Configure the eBPF security policy on a host so events start flowing.
  • See [[escalation-policies]] for routing critical-tactic events to the on-call.
  • The [[consolidated-view]] guide explains how MITRE chips appear on the dashboard.