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
| Code | Tactic | What it means in practice |
|---|---|---|
| TA0001 | Initial Access | First foothold - a successful exploit or stolen credential |
| TA0002 | Execution | Running attacker code on the host |
| TA0003 | Persistence | Surviving a reboot or a process kill |
| TA0004 | Privilege Escalation | Going from a regular user to root (or root to kernel) |
| TA0005 | Defense Evasion | Hiding from logging, AV, or auditing |
| TA0006 | Credential Access | Stealing passwords, keys, or session tokens |
| TA0007 | Discovery | Looking around - what’s installed, who’s logged in |
| TA0008 | Lateral Movement | Hopping from one host to another |
| TA0009 | Collection | Gathering files or data of interest |
| TA0010 | Exfiltration | Sending the collected data out |
| TA0011 | Command and Control | Talking to an external server for instructions |
| TA0040 | Impact | Destruction, 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
- 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.
- 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.
- 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.