Krótki przewodnik po MITRE ATT&CK dla początkujących: jak mapować zachowania napastnika

Po co w ogóle MITRE ATT&CK przy incydentach i atakach

MITRE ATT&CK jako model TTP, a nie kolejna lista IOC

MITRE ATT&CK to usystematyzowana baza wiedzy o tym, jak realni napastnicy faktycznie działają w środowiskach IT. Skupia się na TTP – Tactics, Techniques, Procedures – czyli na sposobach działania, a nie tylko na pojedynczych wskaźnikach kompromitacji (IOC), które szybko się dezaktualizują.

IOC, jak adresy IP, hashe plików czy domeny C2, są użyteczne, ale bardzo łatwe do zmiany. Zmiana infrastruktury lub kompilacja nowej wersji malware’u i połowa sygnatur ląduje w koszu. Techniki działania (TTP) są dla atakujących znacznie „droższe” do zmiany – wymagają nowych narzędzi, procedur, testów, często zmiany całego „playbooka” grupy.

MITRE ATT&CK porządkuje te techniki w spójną matrycę, która pozwala opisywać atak nie w stylu: „widzieliśmy IP X i Y”, ale raczej: „napastnik użył technik T1566 (phishing), T1059 (Command and Scripting Interpreter) oraz T1021 (Remote Services)”. Taki opis jest zrozumiały, porównywalny i przydatny zarówno dla SOC, jak i dla zarządu.

Dlaczego sam AV, EDR i „czarna magia SOC‑u” przestają wystarczać

Tradycyjne podejście oparte na antywirusie, firewallu i „jak będzie głośno, to SOC coś znajdzie” jest za słabe w momencie, gdy napastnik używa legalnych narzędzi systemowych: PowerShell, WMI, RDP, narzędzi administracyjnych. Duża część nowoczesnych ataków opiera się na koncepcji living off the land – czyli wykorzystywaniu tego, co już jest w systemie.

EDR i nowoczesne systemy ochrony potrafią wiele, ale bez modelu, do którego można wszystko przyłożyć, analitycy toną w alertach. MITRE ATT&CK dostarcza takiego modelu: pozwala ocenić, czy organizacja wykrywa najważniejsze techniki, a także zrozumieć, czy incydent jest „pojedynczym strzałem”, czy elementem szerszej kampanii.

Zamiast reagować ad hoc na każdy alert, zespół bezpieczeństwa może zaplanować pokrycie kluczowych taktyk i technik, a następnie systematycznie łatać luki w detekcjach. To nie jest już „czarna magia SOC‑u”, tylko proces oparty na wspólnym słowniku.

Wspólny język między SOC, zespołem bezpieczeństwa i zarządem

MITRE ATT&CK stało się de facto standardem komunikacji w cyberbezpieczeństwie. Te same identyfikatory technik pojawiają się w:

• raportach APT i ransomware od firm z branży (np. „grupa używa T1059, T1047, T1021”),
• raportach z testów penetracyjnych i red teamu,
• opisach funkcji narzędzi (np. pokrycie ATT&CK przez EDR),
• wewnętrznych raportach po incydentach.

Dla zarządu oznacza to, że da się przedstawić poziom bezpieczeństwa w sposób porównywalny z rynkiem: „Nasze detekcje pokrywają X% najczęściej używanych technik w raportach branżowych”. Zamiast abstrakcyjnych „poprawiliśmy bezpieczeństwo o 30%”, pojawia się konkretny wskaźnik oparty na ATT&CK.

Zespół audytu wewnętrznego może wówczas oceniać stan bezpieczeństwa nie tylko na podstawie istnienia procedur, lecz także na bazie realnego pokrycia technik: czy organizacja wykryje nietypowe użycie PowerShella, nieautoryzowane logowania RDP czy exfiltrację danych kanałem HTTP.

Kluczowe korzyści z używania MITRE ATT&CK przy incydentach

Regularne korzystanie z matrycy MITRE ATT&CK przynosi kilka bardzo konkretnych efektów:

• spójna analiza incydentów – każdy większy incydent może być opisany jako ciąg taktyk i technik, co ułatwia porównanie z innymi przypadkami,
• lepsze decyzje inwestycyjne – można jasno wskazać, jakie techniki są niewykrywane i które źródła logów lub narzędzia trzeba wzmocnić,
• lepsze priorytety – zamiast dłubać przy egzotycznych scenariuszach, zespół skupia się na technikach, które najczęściej pojawiają się w atakach na podobne organizacje,
• sprawniejsza komunikacja – raport „wykryto T1566, T1059, T1027, T1041” jest krótki, a jednocześnie bardzo treściwy dla kogoś, kto zna matrycę.

Dzięki temu MITRE ATT&CK staje się nie tylko narzędziem dla SOC, ale także podstawą strategii bezpieczeństwa w szerszym ujęciu.

Podstawowe pojęcia: taktyki, techniki, TTP i inne „magiczne skróty”

IOC vs TTP – dlaczego samo IOC to przepis na powtórkę ataku

IOC (Indicators of Compromise) to ślady konkretnej kampanii lub narzędzia: adres IP serwera C2, hash pliku malware, domena phishingowa. Są potrzebne, ale bardzo kruche – jedna zmiana po stronie atakującego i IOC przestaje być aktualny.

TTP (Tactics, Techniques, Procedures) opisuje jak napastnik działa, niezależnie od konkretnych IOC. Przykłady:

• „używa PowerShell do pobrania i uruchomienia payloadu” – technika T1059.001,
• „ruch boczny przy użyciu RDP” – T1021.001,
• „zbiera hasła z pamięci LSASS” – T1003.001.

Organizacja, która opiera obronę tylko na IOC, jest zawsze o krok za napastnikiem. Organizacja, która projektuje detekcje pod kątem TTP, reaguje na sam wzorzec zachowania, a nie na pojedynczy artefakt.

Taktyka, technika i podtechnika – trzy poziomy szczegółowości

MITRE ATT&CK dzieli działania napastnika na trzy główne poziomy:

• Taktyka – odpowiada na pytanie „po co”. To cel na danym etapie ataku, np. Initial Access, Execution, Lateral Movement, Exfiltration.
• Technika – odpowiada na pytanie „w jaki sposób”. To konkretny sposób osiągnięcia celu, np. Spearphishing Attachment, Remote Services, Command and Scripting Interpreter.
• Podtechnika – uszczegóławia technikę, np. T1059.001 (PowerShell) jako podtechnika T1059.

Taktyki są prezentowane jako kolumny w matrycy, techniki to „kafle” w tych kolumnach, a podtechniki są rozwijane jako elementy dodatkowe. Dzięki temu można opowiadać o ataku na różnym poziomie szczegółowości – od prezentacji dla zarządu („wykonano kilka kroków w taktykach Initial Access i Exfiltration”) po szczegółową analizę dla SOC.

Czym są TTP i jak ATT&CK je porządkuje

Termin TTP obejmuje trzy elementy:

• Tactics – ogólne cele,
• Techniques – sposoby realizacji celów,
• Procedures – konkretne implementacje technik, czyli „jak dokładnie napastnik to robi”.

MITRE ATT&CK opisuje taktyki i techniki w uporządkowany sposób, a procedury pojawiają się w przykładach użycia. Przy każdej technice znajdują się odniesienia do konkretnych grup APT lub rodzin malware, które ją stosują. Dzięki temu można zbudować mapę powiązań: scenariusze ataku → techniki → narzędzia → grupy.

Dla SOC oznacza to, że z jednego incydentu można „przeskoczyć” do informacji o typowych zachowaniach tej samej grupy atakującej i sprawdzić, które techniki mogły zostać użyte, ale jeszcze nie zostały wykryte w logach.

Rodziny matryc: Enterprise, Mobile, ICS – co jest istotne dla SOC

MITRE utrzymuje kilka odrębnych matryc:

• Enterprise ATT&CK – dla środowisk korporacyjnych (Windows, Linux, macOS, poczta, usługi sieciowe, chmura),
• Mobile ATT&CK – techniki ataków na urządzenia mobilne,
• ICS ATT&CK – dla systemów przemysłowych i OT.

Dla typowego SOC i zespołu Blue Team najważniejsza jest Enterprise ATT&CK, bo obejmuje większość codziennych scenariuszy incydentów: phishing, ransomware, ataki na AD, ruch boczny, kradzież danych z serwerów plików i systemów biznesowych.

Mobile i ICS mają znaczenie głównie w organizacjach, które rzeczywiście zarządzają taką infrastrukturą: operatorzy telekomunikacyjni, przemysł, energetyka, logistyka. W wielu środowiskach korporacyjnych i administracji publicznej wystarczy skupić się na matrycy Enterprise i konsekwentnie ją ogarniać (co i tak jest sporym wyzwaniem).

Jak czytać matrycę MITRE ATT&CK bez bólu głowy

Struktura matrycy: kolumny, kafelki i identyfikatory

Matryca MITRE ATT&CK wygląda trochę jak plansza do gry strategicznej, ale po chwili oswajania staje się bardzo intuicyjna. Najważniejsze elementy:

• Kolumny – każda kolumna to jedna taktyka, np. Initial Access, Execution, Persistence, Privilege Escalation, Lateral Movement, Exfiltration.
• Kafelki – każdy kafelek w kolumnie to technika, oznaczona identyfikatorem w formie Txxxx (np. T1059). Po rozwinięciu mogą być widoczne podtechniki T1059.001, T1059.003 itd.
• Identyfikator techniki – stały numer (TID), który pozwala jednoznacznie odwołać się do techniki w raportach, regułach SIEM, dokumentacji czy playbookach.

Korzystając z matrycy, najpierw wybiera się odpowiednią rodzinę (najczęściej Enterprise), a potem patrzy się na techniki w kontekście konkretnej taktyki. Dzięki temu analityk nie gubi się w kilkuset technikach, tylko filtruje je w zależności od etapu ataku.

Co znajduje się w karcie techniki ATT&CK

Po kliknięciu konkretnej techniki w matrycy wyświetla się jej szczegółowa karta. Najważniejsze elementy, z których korzysta SOC i zespół bezpieczeństwa:

• Opis – zwięzłe wyjaśnienie, na czym polega technika i dlaczego jest używana.
• Przykłady użycia – odwołania do realnych grup APT, kampanii lub narzędzi, które stosują tę technikę.
• Indicators / Data Sources – jakie artefakty i logi mogą pokazać ślady użycia techniki (np. Windows Event Logs, PowerShell logs, WMI activity).
• Detection – sugestie, jak wykrywać technikę: na co zwracać uwagę, jakie warunki mogą być podejrzane.
• Mitigations – propozycje środków obronnych: konfiguracja systemu, polityki, segmentacja, ograniczenia uprawnień.

Te sekcje są w praktyce gotowym szkieletem do zbudowania detekcji w SIEM/EDR oraz listy kontrolnej do oceny, czy organizacja ma realne szanse wyłapać dane zachowanie.

Przykład techniki: T1059 Command and Scripting Interpreter

Technika T1059 to klasyk, który pojawia się w ogromnej liczbie incydentów. Obejmuje użycie interpreterów poleceń i języków skryptowych do wykonywania złośliwego kodu, np.:

• PowerShell (T1059.001),
• Windows Command Shell (T1059.003),
• Python (T1059.006),
• Bash (T1059.004).

W praktyce może to wyglądać tak:

• użytkownik klika link w phishingu i uruchamia makro,
• makro wykonuje skrypt PowerShell, który pobiera payload z internetu i uruchamia go w pamięci,
• napastnik zdalnie wydaje kolejne polecenia przez PowerShell Remoting.

Dla SOC kluczowe są sekcje „Data Sources” i „Detection” w tej technice. Pokazują, że do sensownej detekcji potrzeba m.in. logów Script Block Logging, Process Creation, a także korelacji nietypowych argumentów linii komend (np. długie polecenia Base64, parametry -EncodedCommand, użycie Invoke-Expression).

Jak ocenić, czy technika jest istotna dla konkretnej organizacji

Nie każda technika MITRE ATT&CK jest warta takiego samego wysiłku w każdej firmie. Szybka ocena przydatności może bazować na kilku pytaniach:

• Czy używamy technologii, której dotyczy technika? Jeśli organizacja nie ma Linuxa na stacjach roboczych, techniki specyficzne dla tego systemu nie są priorytetem.
• Czy technika pojawia się często w raportach o atakach na naszą branżę? Raporty threat intelligence coraz częściej opisują ataki właśnie identyfikatorami ATT&CK.

Jak priorytetyzować techniki: ryzyko vs. wysiłek

Matryca ATT&CK kusi, żeby „pokryć wszystko”. To prosta droga do rozproszenia zasobów SOC na dziesiątki średnio istotnych tematów. Sensowniejsze podejście to mały, pragmatyczny scoring technik.

Podstawowy model może opierać się na trzech osiach:

• Prawdopodobieństwo – jak często technika pojawia się:
  • w incydentach z własnego środowiska,
  • w raportach threat intel dla danej branży,
  • w publicznych raportach dużych vendorów (kraje/regiony, wektor początkowy).
• Impact – co technika umożliwia napastnikowi:
  • eskalacja uprawnień na kontrolerze domeny,
  • masowe szyfrowanie dysków,
  • dostęp do wrażliwych danych biznesowych.
• Wysiłek wdrożenia detekcji – ile realnie kosztuje:
  • zbieranie wymaganych logów (licencje, storage),
  • konfiguracja źródeł danych (np. audit policy w AD),
  • utrzymanie reguł (fałszywe alarmy, tunning).

Prosty arkusz z kolumnami „Prawdopodobieństwo 1–5”, „Impact 1–5”, „Wysiłek 1–5” i wyliczonym priorytetem typu (Prawdopodobieństwo * Impact) / Wysiłek uporządkuje listę technik szybciej niż trzygodzinna narada na Teamsach.

Scenariusz ataku krok po kroku: mapowanie łańcucha zdarzeń na ATT&CK

Od pierwszego alarmu do mapy taktyk

Klucz do sensownego używania ATT&CK przy incydentach: każde istotne zdarzenie próbować osadzić w łańcuchu ataku. Nie patrzeć na pojedynczy alert, tylko zadać pytanie: „na jakim etapie jestem i co było przed oraz po tym zdarzeniu?”.

Typowy prosty scenariusz (ransomware na stacji roboczej):

1. Użytkownik otwiera załącznik z fakturą i uruchamia makro.
2. Makro startuje PowerShell z parametrem -EncodedCommand.
3. PowerShell pobiera plik z serwera w chmurze i uruchamia go w pamięci.
4. Payload próbuje:
   • zebrać hasła z LSASS,
   • rozszerzyć uprawnienia,
   • zaszyfrować pliki lokalne i sieciowe.

Mapowanie na ATT&CK może wyglądać następująco:

• Initial Access: T1566.001 Spearphishing Attachment – mail z fakturą.
• Execution: T1204.002 User Execution: Malicious File – użytkownik otwiera dokument.
• Execution: T1059.001 PowerShell – makro uruchamia skrypt.
• Defense Evasion: T1140 Deobfuscate/Decode Files or Information – dekodowanie komendy.
• Credential Access: T1003.001 LSASS Memory – próby wyciągnięcia haseł.
• Impact: T1486 Data Encrypted for Impact – szyfrowanie danych.

Jak praktycznie zbierać „łańcuch ATT&CK” przy incydencie

Przy analizie incydentu przydaje się prosty szablon, który analityk uzupełnia „na bieżąco”, zamiast trzymać wszystko w głowie. Może to być zwykły dokument albo formularz w narzędziu ticketowym.

Przykładowe pola:

• Krok – kolejny numer zdarzenia.
• Opis zdarzenia – co faktycznie widzimy w logach/telemetrii.
• Taktyka – wybrana z listy ATT&CK.
• Technika / Podtechnika – TID, jeśli jest znany.
• Źródło danych – z jakich logów/telemetrii pochodzi informacja.
• Niepewność – np. „pewne / prawdopodobne / hipotetyczne”.

Dla części kroków identyfikator techniki może być tylko przybliżony – to normalne. Ważniejsze, żeby mieć w ogóle szkic łańcucha: pierwsze wejście, wykonanie kodu, ruch boczny, eskalacja, exfiltracja, wpływ.

Identyfikacja „brakujących kroków” na podstawie ATT&CK

Kiedy łańcuch jest wstępnie zmapowany, pojawia się bardzo przydatne pytanie: „czego tu brakuje?”. ATT&CK działa trochę jak lista kontrolna.

Przykład: widać, że napastnik zdobył uprawnienia administratora domeny i wyłączył backupy, ale nie ma logów świadczących o tym, jak dokładnie doszło do eskalacji:

• w matrycy w taktyce Privilege Escalation analityk zaznacza typowe techniki dla AD (np. T1068, T1134, T1078),
• sprawdza, z których źródeł danych istnieją logi (event logi zabezpieczeń, EDR, kontroler domeny),
• zadaje konkretne pytania: „czy mamy logi z DC z tego okresu?”, „czy zbieramy Directory Service Changes?”, „czy są zdarzenia modyfikacji członkostwa w grupie Domain Admins?”.

To podejście prowadzi do dość brutalnej, ale potrzebnej konkluzji: jeśli jakiejś techniki nie da się nawet spróbować odtworzyć, to zabezpieczenia są tam w praktyce „na wiarę”.

MITRE ATT&CK w praktyce analizy incydentów

Standaryzacja opisu incydentów

Bez wspólnego języka raporty z incydentów szybko zamieniają się w opowieści „kto, kiedy, jak kliknął”. ATT&CK pozwala narzucić prosty, powtarzalny szkielet.

Raport może mieć np. sekcję „Użyte techniki ATT&CK”, w której znajdują się:

• lista TID wraz z taktykami,
• ocena, czy dana technika została:
  • wykorzystana (potwierdzona w logach),
  • prawdopodobnie wykorzystana (wnioskowana na podstawie innych kroków),
  • niezaobserwowana, ale możliwa (na podstawie typowego tradecraftu danej grupy).

Dodatkowo opłaca się dodać krótką tabelę:

Porównywanie incydentów między sobą

Jeśli każdy większy incydent kończy się listą technik ATT&CK, po kilku miesiącach zaczyna się rysować wzór. Można wtedy policzyć bardzo konkretne rzeczy:

• które techniki występują najczęściej,
• z którymi taktykami SOC radzi sobie dobrze (szybka detekcja),
• gdzie napastnicy mają najwięcej „ciszy operacyjnej” (długi czas od użycia techniki do wykrycia).

Nawet prosty pivot w Excelu lub dashboard w SIEM, gdzie oś X to techniki, oś Y to liczba incydentów, a kolor oznacza branżę/segment infrastruktury, potrafi bardzo przekonująco uzasadnić budżet na logi z określonych systemów. ASCII-art w prezentacjach dla zarządu działa gorzej.

Wykorzystanie ATT&CK do identyfikacji luk w logowaniu

ATT&CK ma sekcję Data Sources dla każdej techniki. To darmowa lista kontrolna: „jakie logi są potrzebne, żeby mieć choć cień szansy na detekcję?”.

Praktyczne podejście:

1. Wybór kilkunastu technik o wysokim priorytecie (na podstawie incydentów i threat intel).
2. Dla każdej techniki stworzenie tabeli:
   • Data Source (np. Process Creation, File Creation, Authentication Logs),
   • czy zbierane? (tak/nie/częściowo),
   • z jakich systemów (serwery, stacje robocze, DC, chmura),
   • retencja (ile dni/tygodni).
3. Oznaczenie luk typu:
   • „nie logujemy procesów na serwerach plików”,
   • „logi PowerShell nie są włączone na stacjach”,
   • „brak logów z bramki VPN”.

Tak przygotowana mapa „Data Sources vs. Techniki” jest jednocześnie planem działań dla zespołu odpowiedzialnego za logowanie. Łatwiej rozmawia się o włączeniu audytu Directory Service Access, gdy można pokazać konkretną listę technik, których bez tego nie da się zobaczyć.

Łączenie ATT&CK z playbookami reakcji

Kiedy playbooki reakcji opierają się na opisach typu „jeśli malware na stacji – odetnij sieć, przeskanuj, przywróć z backupu”, to każda niestandardowa sytuacja kończy się telefonem „a co teraz?”. ATT&CK umożliwia bardziej modułowe podejście.

Playbook może mieć strukturę:

• Wejście – wykryta technika (TID) i kontekst (np. host, użytkownik, zakres).
• Kroki detekcyjne – jak szybko potwierdzić, że technika rzeczywiście została użyta (jakie dodatkowe logi sprawdzić).
• Kroki ograniczające – jakie natychmiastowe działania minimalizują efekt (odłączenie hosta, reset sesji, blokada konta).
• Kontrola szkód – jakie inne techniki zwykle towarzyszą tej technice i co trzeba zweryfikować (np. dla T1059 często sprawdzić T1105 – Ingress Tool Transfer).

To pozwala na coś, czego SOC naprawdę potrzebuje: mniej „sztuki i improwizacji”, więcej powtarzalnych procesów, które można potem usprawnić i zautomatyzować.

Budowanie detekcji i reguł w SIEM/EDR na podstawie ATT&CK

Od techniki do konkretnej reguły: prosty workflow

Proces budowania detekcji z wykorzystaniem ATT&CK da się ustandaryzować. Jeden cykl może wyglądać tak:

1. Wybór techniki – np. T1059.001 PowerShell.
2. Analiza karty techniki:
   • Data Sources,
   • Detection,
   • przykładowe procedury grup APT.
3. Inwentaryzacja logów – co mamy, czego brakuje, jakie są ograniczenia (np. limit długości argumentów w logach).
4. Wzorce anomalii – co w danym środowisku jest „dziwne” dla tej techniki (np. użycie PowerShell w nocy przez użytkowników biurowych).
5. Implementacja reguły SIEM/EDR – zapis w konkretnym języku (KQL, SPL, własny DSL vendora EDR).
6. Testy – symulacja ataku (np. za pomocą Atomic Red Team) i ocena jakości alarmów.

Przykład: reguły na T1059.001 w praktyce

Dla T1059.001 typowe detekcje na poziomie SIEM mogą obejmować m.in.:

• proces powershell.exe z podejrzanymi argumentami linii poleceń:
  • -EncodedCommand,
  • Invoke-Expression,
  • ciągi Base64 powyżej określonej długości,
  • bezpośrednie odwołania do DownloadString, Invoke-WebRequest, IEX.
• uruchomienie PowerShell z nieoczekiwanych lokalizacji (np. z k