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 katalogów tymczasowych lub użytkownika).
• PowerShell jako proces potomny aplikacji, dla której nie jest to normalne (np. Excel, Word, Outlook).

W EDR można to rozszerzyć o:

• wykrycie PowerShell w trybie in-memory z wyłączonym profilowaniem,
• procesy potomne PowerShell uruchamiające narzędzia typowe dla red teamów (Mimikatz, Rubeus, itp.).

Ważne, aby reguły podzielić na poziomy:

Priorytetyzacja detekcji: poziomy reguł

Reguły oparte o ATT&CK szybko mnożą się w SIEM/EDR. Bez sensownej kategoryzacji kończy się to lawiną alertów „wysokiego ryzyka”, które wszyscy ignorują. Prosty podział pomaga utrzymać porządek:

• Poziom 1 – reguły informacyjne:
  lekkie sygnały, często pojedynczy warunek. Służą raczej do kontekstu niż do podnoszenia incydentów:
  • „Uruchomiono PowerShell na serwerze plików” – ciekawostka, nie tragedia.
  • „Nowy proces rundll32.exe z nietypowej ścieżki” – dobry kandydat do korelacji z innymi zdarzeniami.
• Poziom 2 – podejrzane zachowanie:
  kombinacja kilku warunków, większa precyzja:
  • „PowerShell z -EncodedCommand uruchomiony z Worda na stacji biurowej”.
  • „cmd.exe wywołany przez proces przeglądarki + zapis pliku wykonywalnego do katalogu użytkownika”.
• Poziom 3 – wysoka pewność nadużycia:
  sygnały, które prawie zawsze oznaczają incydent:
  • „PowerShell pobiera skrypt z zewnętrznego URL i natychmiast uruchamia nowy proces z pamięci”.
  • „lsass.exe otwierany z uprawnieniami debug przez proces spoza listy dozwolonych narzędzi”.

To, co jest poziomem 2 lub 3, różni się między środowiskami. W jednej firmie PowerShell w nocy będzie dramatem, w innej – zwykłym utrzymaniem. Dlatego przy projektowaniu reguł opłaca się opierać na realnych wzorcach użycia, a nie na „internetowych listach złośliwych komend”.

Mapowanie istniejących reguł na ATT&CK

W wielu organizacjach SIEM ma już setki reguł napisanych „po staremu”: pod konkretny IOC, sygnaturę, produkt. ATT&CK pomaga je uporządkować.

Praktyczne podejście do refaktoryzacji:

1. Eksport listy reguł z SIEM/EDR (nazwa, opis, logika, kategorie).
2. Dla każdej reguły przypisanie:
   • co najmniej jednej techniki (TID),
   • taktyki (np. Credential Access, Exfiltration),
   • poziomu reguły (L1/L2/L3 z poprzedniego podpunktu).
3. Zbudowanie prostego widoku:
   • technika → liczba reguł,
   • taktyka → pokrycie (są reguły / brak reguł),
   • produkt → w którym systemie detekcja jest najmocniejsza.

W praktyce często okazuje się, że:

• Initial Access jest „przeregulowany” (10 reguł na phishing, 0 na lateral movement),
• dla tej samej techniki istnieją trzy podobne reguły w różnych produktach, z których dwie można spokojnie wyłączyć,
• całe taktyki (np. Impact) są praktycznie puste.

Taki przegląd to nie tylko porządkowanie bałaganu. To też dobry argument w dyskusji, czy naprawdę potrzebny jest kolejny produkt bezpieczeństwa, jeśli połowy jego sygnałów nikt nie mapuje ani nie koreluje.

Łączenie ATT&CK z MITRE D3FEND i kontrolami bezpieczeństwa

ATT&CK mówi „co robi napastnik”. MITRE D3FEND (osobny projekt) opisuje z kolei przeciwdziałania na określone techniki. Oba modele można powiązać przy budowaniu detekcji i zabezpieczeń.

Prosty schemat dla jednej techniki:

1. T1059.001 PowerShell – identyfikacja techniki i jej wariantów.
2. Sprawdzenie w D3FEND, jakie rodzaje obrony są sugerowane:
   • proces monitoring,
   • script analysis,
   • execution prevention / allowlisting.
3. Przypisanie do istniejących lub planowanych kontroli:
   • EDR z blokowaniem „untrusted script” → prewencja,
   • logowanie zdarzeń PowerShell → detekcja,
   • wdrożone AppLocker / WDAC → ograniczenie powierzchni.

Efekt uboczny jest bardzo pożądany: zamiast luźnej listy reguł i polityk mamy ślad „technika → detekcje → prewencja → brakujące elementy”. Audytorzy lubią takie mapy prawie tak samo jak tabele w Excelu.

ATT&CK w threat huntingu: szukanie problemów zanim wybuchną

Threat hunting oparty o hipotezy ATT&CK

Polowanie bez planu kończy się przeklikiwaniem logów „aż coś wpadnie w oko”. ATT&CK pomaga przerobić to na sensowny proces w oparciu o hipotezy.

Schemat jednego cyklu polowania:

1. Wybór taktyki lub techniki – np. Lateral Movement i T1021.001 (RDP).
2. Formułowanie hipotezy:
   • „Jeśli w naszej sieci działa przeciwnik, może używać RDP do ruchu bocznego poza godzinami pracy użytkowników biznesowych”.
3. Przekład na zapytania:
   • wyszukaj logowania RDP na hosty serwerowe z kont użytkowników biurowych,
   • zawęź do nietypowych godzin lub nietypowych par źródło–cel,
   • połącz z informacjami o nowych lokalnych administratorach na tych hostach (Privilege Escalation).
4. Analiza wyników – klasyfikacja: „oczekiwane administrowanie”, „dziwne, ale wyjaśnione”, „prawdopodobny incydent”.
5. Udoskonalenie detekcji – z dobrego zapytania huntingowego często da się wyprowadzić regułę SIEM (np. L2).

Po kilku takich cyklach powstaje mała „biblioteka” hipotez, które można powtarzać co miesiąc lub po większych zmianach w infrastrukturze.

Dobór technik do polowania: nie zaczynaj od całej matrycy

Atakujący nie używają wszystkich technik naraz, więc zespół huntingowy też nie musi. Rozsądny start to niewielki, ale przemyślany zakres:

• Top techniki z incydentów – to, co już się przytrafiło, ma największą szansę się powtórzyć.
• Techniki „must have” z threat intelligence – powtarzające się w opisach kampanii na naszą branżę.
• Techniki „słabo pokryte logami” – polowanie na obszarach, gdzie wiemy, że mamy luki (nawet jeśli to bardziej test dojrzałości logowania niż hunting).

Z tego zbiera się mały zestaw, np. 10–20 technik. Dla każdej z nich można zdefiniować przynajmniej jedno zapytanie huntingowe i jeden scenariusz „co robię, jeśli znajdę coś dziwnego”.

Przykład zestawu polowań ATT&CK dla Windows AD

Dla środowiska domenowego Windows sensowny, „startowy” pakiet może wyglądać tak:

• Credential Access:
  • T1003.001 – LSASS Memory:
    • zapytania o procesy próbujące otwierać lsass.exe z nietypowych lokalizacji,
    • EDR: alerty na narzędzia typu Mimikatz / comsvcs.dll injection.
  • T1110 – Brute Force:
    • wzorce wielu nieudanych logowań na konto serwisowe,
    • rozproszone próby logowania z wielu hostów do jednego konta.
• Lateral Movement:
  • T1021.001 – Remote Services: RDP:
    • RDP z hostów użytkowników na serwery, gdzie normalnie logują się tylko admini,
    • RDP między serwerami aplikacyjnymi a DC (często antywzorzec).
  • T1075 / T1550.002 – Pass-the-Hash / Kerberos:
    • nietypowe użycie biletów Kerberos (np. wiele serwisów z tego samego biletu),
    • logi wskazujące na użycie złamanych/odtworzonych biletów (np. Golden Ticket artefakty).
• Persistence / Privilege Escalation:
  • T1136 – Account Creation:
    • nowe konta lokalne admin w serwerach należących do domeny,
    • tworzenie kont w AD w godzinach nocnych lub przez nietypowe narzędzia.
  • T1053 – Scheduled Task / Job:
    • zadania uruchamiane przez konta użytkowników spoza IT,
    • zadania z komendami typu powershell.exe -EncodedCommand.

Każdy taki „bundle” huntingowy można opisać w prostym dokumencie: techniki, zapytania, wymagane źródła danych, oczekiwane falszywe alarmy i kroki eskalacji.

Od huntingu do stałej detekcji

Dobre polowania nie powinny być jednorazowym „eventem”. Jeśli hipoteza się sprawdziła (znaleziono anomalie, które jednak okazały się legalne), to:

• warto opisać, na czym polega „normalność” – np. konkretne konta administracyjne, harmonogram zadań, zakres adresów źródłowych,
• na tej podstawie zbudować regułę, która ignoruje te znane, zatwierdzone przypadki, a sygnalizuje wszystko, co nowe.

Przykład:

• W huntingu na T1021.001 wychodzi, że admini logują się RDP z trzech konkretnych jump hostów.
• Na tej bazie powstaje reguła: „RDP na serwery produkcyjne z innego hosta niż te trzy” → alert L2.

Po kilku miesiącach takiego podejścia rośnie nie tylko jakość detekcji, ale też wiedza o tym, co w ogóle jest „normalnym” zachowaniem w sieci. To trochę przy okazji rozwiązuje problem „nasza sieć jest za duża, żeby ją znać”.

Threat hunting w oparciu o grupy przeciwników (threat intel & ATT&CK)

ATT&CK ma sekcję Groups, gdzie opisane są znane grupy i używane przez nie techniki. To bardzo wygodny punkt startu, jeśli organizacja pracuje z threat intelligence.

Przykładowy workflow:

1. Otrzymany raport TI wskazuje na aktywność grupy X w sektorze, do którego należy organizacja.
2. W bazie ATT&CK sprawdzane są techniki tej grupy:
   • lista technik, ich częstotliwość, powtarzające się wzorce (np. preferowany wektor wejścia + ruch boczny + exfiltracja).
3. Dla top 5–10 technik budowane są konkretne hipotezy huntingowe:
   • „Jeśli grupa X używa T1041 (Exfiltration Over C2 Channel), zobaczmy nietypowe wyjścia HTTPS do hostów spoza listy ‘zaufane SaaS’ z serwerów DB”.
   • „Jeśli używają T1505 (Server-Side Component), sprawdźmy nowe lub zmodyfikowane DLL w katalogach aplikacji webowych”.
4. Po polowaniu wybrane zapytania awansują do reguł detekcyjnych.

Duża zaleta: nie poluje się na losowe artefakty z feedów IOC, tylko na konkretne zachowania operacyjne (TTP), które są mniej wrażliwe na drobne zmiany w infrastrukturze przeciwnika.

ATT&CK a capacity planning SOC

Threat hunting i rozbudowa detekcji mają jeszcze jeden, często pomijany efekt: pomagają zaplanować, ilu ludzi i jakich kompetencji SOC realnie potrzebuje.

Jeśli lista używanych technik ATT&CK rośnie, a wraz z nią:

• liczba hipotez huntingowych,
• liczba reguł L2/L3 w SIEM/EDR,
• liczba playbooków powiązanych z technikami,

to da się policzyć chociażby:

• ile czasu zajmuje obsługa alertów na daną technikę,
• ile cykli huntingowych można wykonać miesięcznie przy obecnym zespole,
• gdzie automatyzacja (SOAR) przyniesie największy zysk – np. przy technikach, gdzie 90% przypadków kończy się tą samą decyzją.

Innymi słowy, ATT&CK to nie tylko zabawka dla analityków. Dobrze utrzymana mapa technik, detekcji i playbooków bardzo ułatwia rozmowy o budżecie i zasobach. A to już język, który rozumie nie tylko SOC, ale i zarząd.

Najczęściej zadawane pytania (FAQ)

Co to jest MITRE ATT&CK i do czego służy przy analizie incydentów?

MITRE ATT&CK to publiczna baza wiedzy opisująca, jak realni napastnicy działają w środowiskach IT. Zamiast skupiać się na pojedynczych wskaźnikach kompromitacji (IOC), porządkuje zachowania atakujących w postaci taktyk, technik i podtechnik – czyli TTP (Tactics, Techniques, Procedures).

W praktyce służy do opisywania i analizowania incydentów w spójny sposób. Zamiast raportu „widoczny złośliwy IP i podejrzany plik”, analityk może powiedzieć: „wykorzystano T1566 (phishing) i T1059 (Command and Scripting Interpreter)”, co jest zrozumiałe dla innych zespołów bezpieczeństwa, dostawców narzędzi i zarządu.

Jaka jest różnica między IOC a TTP i dlaczego MITRE ATT&CK stawia na TTP?

IOC (Indicators of Compromise) to konkretne ślady ataku: adresy IP, domeny C2, hashe plików, nazwy procesów. Są przydatne, ale bardzo łatwo je zmienić – napastnik podmienia infrastrukturę albo kompiluje nową wersję malware i stare IOC nadają się głównie do prezentacji, a nie do obrony.

TTP opisują sposób działania: użycie PowerShella do pobrania payloadu (T1059.001), ruch boczny RDP (T1021.001), kradzież haseł z LSASS (T1003.001). To znacznie trudniejsze do „przebudowania” po stronie atakującego, bo wymaga zmiany narzędzi, procedur i całego playbooka. MITRE ATT&CK skupia się właśnie na tych wzorcach zachowania, dzięki czemu obrona jest mniej podatna na kosmetyczne zmiany po stronie przeciwnika.

Dlaczego sam antywirus i EDR nie wystarczą bez MITRE ATT&CK?

Nowoczesne ataki często opierają się na „living off the land” – wykorzystywaniu wbudowanych narzędzi systemowych, takich jak PowerShell, WMI czy RDP. Antywirus czy EDR widzi wtedy stos alertów na temat legalnych procesów, ale bez dobrego modelu trudno ocenić, które z nich składają się na rzeczywisty scenariusz ataku.

MITRE ATT&CK dostarcza takiego modelu. Pozwala przypisać alerty do konkretnych technik, zobaczyć, które taktyki są już „uruchomione” (np. Initial Access, Lateral Movement, Exfiltration) i ocenić, czy to pojedynczy incydent, czy część szerszej kampanii. Innymi słowy: EDR generuje dane, a ATT&CK nadaje im sens.

Jak zacząć mapować incydenty na techniki MITRE ATT&CK w SOC?

Najprościej wystartować od ręcznego mapowania kilku realnych incydentów. Przy każdym kroku ataku zadać pytanie: „co napastnik chciał osiągnąć?” (taktyka) i „jak to zrobił technicznie?” (technika). Następnie znaleźć odpowiadające im identyfikatory w matrycy ATT&CK i zapisać je w raporcie z incydentu.

Kolejny krok to powiązanie istniejących reguł detekcji (w SIEM, EDR, NDR) z konkretnymi technikami ATT&CK. Dzięki temu widać, które techniki są pokryte, a które wymagają nowych reguł czy dodatkowych źródeł logów. W wielu organizacjach pomaga proste podejście: „zmapujmy top 20 technik z raportów branżowych i sprawdźmy, co realnie wykrywamy”.

Co daje MITRE ATT&CK z punktu widzenia zarządu i audytu, a nie tylko SOC?

Dla zarządu MITRE ATT&CK to sposób na sprowadzenie bezpieczeństwa do mierzalnych wskaźników. Zamiast ogólników typu „podnieśliśmy poziom cyberbezpieczeństwa”, można pokazać np. procent pokrycia najczęściej używanych technik czy postęp w domykaniu luk w konkretnych taktykach (Initial Access, Credential Access itd.).

Dla audytu wewnętrznego i zewnętrznego ATT&CK jest punktem odniesienia do oceny realnych zdolności detekcyjnych. Można sprawdzić nie tylko, czy istnieje procedura, ale czy organizacja faktycznie potrafi wykryć nietypowe użycie PowerShella, nieautoryzowane logowania RDP czy exfiltrację danych przez HTTP. Krótko mówiąc: mniej checklist, więcej realnego obrazu ryzyka.

Czym różnią się matryce Enterprise, Mobile i ICS i którą wybrać na początek?

MITRE utrzymuje kilka osobnych matryc: Enterprise (środowiska korporacyjne – Windows, Linux, macOS, chmura, poczta), Mobile (ataki na urządzenia mobilne) oraz ICS (systemy przemysłowe i OT). Każda z nich zawiera inne techniki, dopasowane do specyfiki danego środowiska.

Dla typowego SOC w firmie lub administracji publicznej punktem startowym jest Enterprise ATT&CK. Obejmuje phishing, ransomware, ataki na Active Directory, ruch boczny i kradzież danych z serwerów – czyli codzienny chleb większości zespołów bezpieczeństwa. Mobile i ICS mają sens głównie tam, gdzie naprawdę zarządza się taką infrastrukturą, np. w telekomach, energetyce czy przemyśle.

Jak MITRE ATT&CK pomaga w podejmowaniu decyzji o inwestycjach w bezpieczeństwo?

Mapując incydenty i reguły detekcji do technik ATT&CK, widać wyraźnie, które obszary są chronione, a które są „ślepe”. Jeśli organizacja regularnie obserwuje ataki z użyciem określonych technik (np. T1566 – phishing, T1021 – Remote Services), a nie ma odpowiednich logów czy detekcji, łatwo uzasadnić potrzebę nowych narzędzi lub rozbudowy istniejących.

To przekłada się na konkretne decyzje: czy zainwestować w lepsze logowanie PowerShella, rozbudowę EDR, czy może w monitoring ruchu sieciowego. Zamiast kupować „coś, co poprawi bezpieczeństwo”, można świadomie adresować brakujące techniki i mierzyć, jak nowa inwestycja zwiększa pokrycie ATT&CK.

Bibliografia

• MITRE ATT&CK: Design and Philosophy. MITRE Corporation (2020) – Opis założeń ATT&CK, TTP, taktyk, technik i podtechnik
• MITRE ATT&CK for Enterprise (Matrix and Technique Descriptions). MITRE Corporation – Oficjalne opisy technik, taktyk i identyfikatorów Txxxx
• NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Zalecenia dot. obsługi incydentów i analizy ataków