MITRE ATT&CK to jeden z najbardziej użytecznych modeli do opisu zachowań atakujących, zwłaszcza wtedy, gdy trzeba przełożyć sygnały z logów na konkretne wnioski o ryzyku. W polskich materiałach bywa też błędnie zapisywany jako mittre attack, ale sens pozostaje ten sam: chodzi o uporządkowanie technik, które przeciwnicy stosują w realnych kampaniach, i o użycie tej wiedzy do lepszej detekcji, threat huntingu oraz utwardzania środowiska. Dla zespołów pracujących na Linuksie jest to szczególnie praktyczne, bo wiele najważniejszych śladów zostaje w powłoce, SSH, usługach systemowych i logach audytowych.
Najważniejsze fakty o ATT&CK w praktyce obronnej
- ATT&CK to baza wiedzy o zachowaniu przeciwnika, a nie lista malware ani produkt bezpieczeństwa.
- Taktyka mówi, po co atakujący coś robi, technika pokazuje, jak to robi, a podtechnika doprecyzowuje szczegóły.
- Linux Matrix opisuje techniki spotykane na hostach z Linuksem, a Enterprise Matrix obejmuje też Windows, macOS, cloud, mobile i ICS.
- Największa wartość to detekcja, mapping incydentów, purple teaming i priorytetyzacja ryzyka.
- Na start lepiej wybrać kilka najważniejszych technik niż próbować pokryć wszystko naraz.
MITRE ATT&CK w praktyce to katalog zachowań przeciwnika
Ja traktuję ATT&CK przede wszystkim jako język obrony, nie jako encyklopedię zagrożeń. To ważne rozróżnienie, bo ten model nie odpowiada na pytanie „jaki to wirus?”, tylko „co zrobił przeciwnik, w jakiej kolejności i po czym to poznam”. Właśnie dlatego jest tak przydatny dla zespołów security, SOC-ów, red teamów i osób, które budują detekcję na Linuksie.
Według MITRE, ATT&CK opisuje techniki obserwowane w realnym świecie, a nie teoretyczne pomysły na atak. W wersji Enterprise skala jest dziś duża: 222 techniki i 475 podtechnik. To wystarcza, żeby dobrze pokazać złożoność kampanii, ale też uczciwie przypomina, że nikt nie „pokrywa wszystkiego” jedną regułą albo jednym narzędziem.
Najkrócej mówiąc, model rozbija zachowanie atakującego na cztery poziomy: taktika wyjaśnia cel, technika pokazuje sposób działania, podtechnika doprecyzowuje wariant, a procedura to już konkretne wykonanie widziane w incydencie. To właśnie ten ostatni poziom odróżnia suchą teorię od rzeczywistej analizy zdarzenia. Zanim jednak przejdę do wdrożenia na Linuksie, warto wiedzieć, jak czytać samą matrycę.
Jak czytać matrycę ATT&CK bez gubienia kontekstu
Matryca wygląda na początku trochę groźnie, ale po kilku minutach staje się czytelna. W górnym układzie masz taktyki, czyli cele atakującego, a pod nimi techniki, które pokazują możliwe sposoby realizacji tych celów. Dla Linuxa MITRE publikuje osobną matrycę, która skupia się na hostach z Linuksem i obecnie obejmuje 13 taktyk, od początkowego dostępu po wpływ na środowisko.
| Element | Co oznacza | Jak używam tego w praktyce |
|---|---|---|
| Taktyka | Cel działania przeciwnika | Pomaga zrozumieć, dlaczego zdarzenie miało miejsce |
| Technika | Sposób osiągnięcia celu | Służy do budowy reguł detekcji i scenariuszy testowych |
| Podtechnika | Bardziej szczegółowy wariant techniki | Ułatwia doprecyzowanie alertów bez ich nadmiernego rozmycia |
| Procedura | Konkretny sposób użyty w ataku | Pokazuje, jak technika wyglądała w danym incydencie |
Przy pracy z tą matrycą najważniejsze jest jedno: nie traktować jej jak katalogu nazw do odhaczenia. Jeśli widzę „Command and Scripting Interpreter”, nie myślę od razu o jednym konkretnym narzędziu. Myślę raczej o całej klasie zachowań: uruchomienie powłoki, skryptu, interpretera, a czasem także łańcucha poleceń, który zostawia ślady w procesach i logach. Gdy rozumiesz już strukturę, dużo łatwiej przejść do Linuxa i zobaczyć, które techniki trzeba obserwować w pierwszej kolejności.
Jak przełożyć ATT&CK na monitorowanie i detekcję na Linuksie
Na Linuksie największą wartość daje mi myślenie przez obserwacje, a nie przez same nazwy technik. Przykładowo, jeśli na serwerze pojawia się nieoczekiwane uruchomienie powłoki, nietypowe logowanie SSH, nowy timer systemd albo czyszczenie historii bash, to już mam materiał do mapowania na konkretną technikę. Nie trzeba od razu wiedzieć wszystkiego; ważne, żeby zebrać sygnały i ułożyć z nich sensowny obraz.
| Obszar | Na co patrzę | Dlaczego to ma znaczenie |
|---|---|---|
| Powłoka i skrypty |
bash, sh, python, perl, nietypowe łańcuchy poleceń |
Często to pierwszy ślad użycia techniki Command and Scripting Interpreter |
| Trwałość |
cron, timery systemd, modyfikacje usług, autostart |
Pokazuje, że atak nie kończy się na pierwszym logowaniu |
| Dostęp i eskalacja | SSH, sudo, konta współdzielone, nagłe zmiany uprawnień |
Pozwala wykryć przejęcie konta albo wejście na hosta przez legalny kanał |
| Ukrywanie śladów | Czyszczenie historii, usuwanie plików, ukryte binaria, nietypowe atrybuty plików | To częsty etap po uzyskaniu dostępu |
| Ruch danych | Archiwizacja danych, nietypowy outbound, transfer przez usługi webowe | Pomaga zauważyć etap przygotowania lub wyprowadzania informacji |
W praktyce zaczynam od źródeł, które naprawdę mam: sshd, sudo, auditd, journald, logi proxy, czasem EDR. Dopiero potem dobieram techniki. To odwrócenie kolejności jest kluczowe, bo inaczej kończysz z piękną tabelą, której nie da się obronić na żadnym realnym incydencie. Kiedy to masz, pozostaje już uporządkować mapping zdarzeń i nie zgubić się w szczegółach.
Jak mapować incydent albo threat intel do technik
Przy analizie incydentu nie próbuję na siłę dopasować wszystkiego do jednego rozpoznania. Najpierw zbieram fakty: proces, rodzica procesu, użytkownika, czas, host, ruch sieciowy i zmianę w plikach. Dopiero potem przypisuję to do techniki albo podtechniki. Jeśli mam tylko podejrzenie, zapisuję je jako hipotezę, nie jako pewnik. To oszczędza mnóstwo czasu i chroni przed błędnymi wnioskami.
- Opisuję obserwację możliwie konkretnie, bez interpretacji na wejściu.
- Oddzielam technikę od procedury, bo jedno zdarzenie może pasować do kilku wariantów.
- Sprawdzam, czy mam dowody w logach, czy tylko intuicję analityka.
- Przypisuję poziom pewności, zamiast tworzyć zbyt kategoryczne etykiety.
- Przekładam to na detekcję, hunting albo scenariusz testowy.
ATT&CK Navigator jest tu bardzo praktyczny, bo pozwala zaznaczać techniki i tworzyć własne warstwy dla konkretnego środowiska. Ja zwykle używam go nie po to, żeby zrobić ładny diagram, ale po to, żeby szybko zobaczyć, gdzie mam pokrycie, a gdzie nadal działam trochę „na wyczucie”. Jeśli ktoś pracuje w threat intelligence, ta sama logika pomaga w raportach i w ocenie, co z opisu kampanii naprawdę da się przełożyć na obronę. Właśnie dlatego warto też znać typowe błędy, bo one najczęściej psują cały proces.
Najczęstsze błędy, które zniekształcają obraz ryzyka
Największy problem widzę wtedy, gdy ATT&CK zaczyna być używany jak egzamin z pokrycia. Zespół próbuje „mieć wszystko”, zamiast chronić to, co naprawdę jest ryzykowne w danym środowisku. Na Linuksie to szczególnie zdradliwe, bo liczba możliwych technik jest duża, a nie każda ma takie samo znaczenie dla serwera WWW, klastra kontenerów czy hosta administracyjnego.
| Błąd | Skutek | Lepsze podejście |
|---|---|---|
| Traktowanie ATT&CK jak testu z pełnego pokrycia | Fałszywe poczucie bezpieczeństwa | Priorytetyzuj 10-15 technik najważniejszych dla twojego środowiska |
| Mapowanie bez dowodów | Szum analityczny i błędne etykiety | Opieraj się na procesach, logach, połączeniach i zmianach w systemie |
| Ignorowanie platformy | Reguły nietrafione dla Linuxa | Używaj Linux Matrix zamiast ogólnej matrycy, gdy bronisz hostów z Linuksem |
| Mylenie techniki z malware | Uboga analiza i słabe wnioski | Opisuj zachowanie, nie tylko nazwę próbki |
| Nieaktualizowanie mapy | Martwa dokumentacja | Wracaj do niej po zmianach w infrastrukturze i po większych incydentach |
Warto też pamiętać, że sama matryca nie jest pełnym opisem wszystkiego, co da się zrobić w ataku. Ona dokumentuje zaobserwowane zachowania, więc brak techniki w macierzy nie oznacza, że dana rzecz jest niemożliwa. Oznacza tylko tyle, że nie ma jej jeszcze dobrze opisanej w tym modelu albo nie jest kluczowa dla danego zakresu. Jeśli od tego zaczniesz, framework zacznie pracować na twoją obronę, a nie będzie tylko kolejną tabelą w dokumentacji.
Od jednorazowej mapy do codziennej obrony Linuxa
Gdybym miał wdrażać ATT&CK od zera, zacząłbym bardzo pragmatycznie: od źródeł logów, które już istnieją, i od kilku technik o największym wpływie na ryzyko. Na Linuksie zwykle da się to zrobić bez wielkiego budżetu, ale nie bez dyscypliny. Najwięcej daje regularność, a nie jednorazowy zryw.
- Wybierz na start 10-15 technik, które naprawdę pasują do twojego środowiska.
- Powiąż każdą z nich z jednym lub dwoma źródłami logów i jednym konkretnym wskaźnikiem.
- Sprawdzaj reguły po zmianach w infrastrukturze, a nie tylko po incydencie.
- Ćwicz scenariusze krótkimi, kontrolowanymi testami zamiast czekać na „prawdziwy” atak.
Jeżeli miałbym sprowadzić całą metodę do jednego zdania, powiedziałbym tak: ATT&CK działa wtedy, gdy łączy obserwację, priorytet i testowanie, a nie gdy jest tylko ładną macierzą na slajdzie. Na Linuksie to połączenie daje bardzo konkretny efekt, bo szybciej widać, co atakujący zrobił, czego jeszcze mógł spróbować i gdzie trzeba wzmocnić detekcję.
