Mini-SOAR: wzbogacanie alertów i threat hunting dla SOC

Mini-SOAR to mój projekt typu SOAR do wzbogacania alertów w SIEM. Silnik wykonuje za analityka pierwsze, powtarzalne kroki analizy alertów Windows: zbiera kontekst i wcześniejsze zachowania konta, a wynik dopisuje prosto do alertu. Dzięki temu decyzję można podjąć szybciej, bez wychodzenia z alertu.

Zanim analityk podejmie decyzję, przy większości alertów w SOC musi ręcznie sprawdzić to samo:

• czyje to konto;
• skąd było logowanie;
• czy wcześniej były nieudane próby;
• czy to dzieje się codziennie albo działo się już wcześniej.

To powolna, powtarzalna praca, a każdy analityk robi ją trochę inaczej.

1. 1

   Faza 1 - samodzielnie

   Pierwszą wersję silnika napisałem samodzielnie: architekturę, parser alertów, integrację z SIEM, zbieranie kontekstu, silnik korelacji z większością modułów analizy, reguły Sigma, obsługę zaległości i stan w SQLite.

2. 2

   Faza 2 - z agentem AI (Claude Code)

   Następnie zleciłem agentowi AI (Claude Code) audyt kodu i dalej rozwijałem projekt z jego pomocą. Zdefiniowałem wymagania i logikę detekcji, podejmowałem decyzje triage, weryfikowałem wyniki na prawdziwej pracy SOC i prowadziłem pilot; agent wprowadzał zmiany pod moim kierunkiem, z testami i przeglądem na każdym etapie. W tej fazie powstały analizator, threat hunting, przypisanie sesji VPN i telemetria pilota.

Źródła

alerty i zdarzenia Windows/AD z SIEM opartego na OpenSearch oraz logi bramy VPN

Detekcja

moduły analizy dla poszczególnych typów zdarzeń, reguły SigmaHQ (pySigma) i mapowanie do MITRE ATT&CK

Uruchamianie i stan

timery systemd; stan, ponowienia i obsługa zaległości w SQLite

Dostęp analityka

wszystkie wyniki są w SIEM, bezpośrednio przy alertach; osobno uruchamia się tylko analizator użytkowników, skryptem w PowerShell

Testy

ponad 700 testów jednostkowych na danych syntetycznych, wykonywanych w kilka sekund

1. 1

   Wzbogacanie alertów co 90 sekund

   Dla każdego nowego alertu silnik zbiera kontekst i uruchamia moduł analizy dopasowany do typu zdarzenia, np. blokady konta, uwierzytelnień NTLM na kontrolerach domeny, nocnych logowań kont uprzywilejowanych, zmian w grupach i kontach, instalacji usług, czyszczenia logu audytu czy awarii aplikacji. Do tego sprawdza alert regułami SigmaHQ. Do alertu trafia skala ryzyka z uzasadnieniem, zalecany krok, techniki MITRE ATT&CK i link do surowych zdarzeń z gotowym filtrem.

2. 2

   Threat hunting co godzinę

   Raz na godzinę silnik przeszukuje aktywność wszystkich kont: password spraying, Kerberoasting, DCSync, ryzykowne flagi kont i wrażliwe zmiany w katalogu. Powtarzające się wykrycie jest dopisywane do pierwszego dokumentu, żeby nie tworzyć nowego alertu co godzinę.

3. 3

   Przypisanie sesji VPN

   Logi bramy VPN pokazują, kto miał dany adres VPN w chwili zdarzenia. Logowanie z cudzej sesji VPN jest oznaczane jako podejrzane, a własna sesja konta zmniejsza szum. Raport konta pokazuje też jego sesje VPN i sprawdza nowy kraj, nowego dostawcę i impossible travel.

4. 4

   Analizator użytkowników

   Skrypt w PowerShell tworzy interaktywny raport HTML dla konta albo typu zdarzenia. Porównuje aktywność z normą tego samego konta i sprawdza hipotezy, m.in. zgadywanie hasła, przejęcie konta, Kerberoasting, DCSync i ruch boczny, każdą z odnośnikiem do MITRE ATT&CK i checklistą dla L1. GUID-y z AD, maski dostępu i flagi kont są tłumaczone na zrozumiały język, a każdy element raportu działa jak filtr.

Silnik tylko dopisuje informacje

Nie edytuje prawdziwych logów, tylko dopisuje informacje do wygenerowanych alertów. Niczego nie blokuje ani nie wyłącza, decyzja o reakcji zawsze zostaje u analityka.

Najpierw pilot

Przed wdrożeniem wyniki trafiały do osobnego indeksu testowego, a pilot zbierał pełną telemetrię. Dzięki temu narzędzie dało się ocenić na prawdziwej pracy, bez zmieniania produkcyjnych alertów.

Jedno wykrycie, jeden dokument

Powtarzające się wykrycie z huntingu nie tworzy nowego alertu co godzinę, tylko jest dopisywane do pierwszego dokumentu.

Stan w SQLite, harmonogram w systemd

Stan, ponowienia i obsługa zaległości są w SQLite, a uruchomienia planują timery systemd.

Rozwój bez danych produkcyjnych

Nowe funkcje powstawały na danych syntetycznych i zanonimizowanych, a na prawdziwym SIEM były sprawdzane tylko zagregowanymi liczbami.

• Nazwy plików i logi nie zawierają danych osobowych, a raport może odczytać tylko jego właściciel.
• Zdalna analiza idzie przez ograniczone polecenie SSH z walidacją argumentów i dziennikiem dostępu.
• Dostęp mają tylko konta z białej listy, z dozwolonych adresów IP i wyłącznie z sieci wewnętrznej.
• Przy rozwoju nigdy nie były używane dane produkcyjne.

1. 1

   Najpierw zasady

   Plik z zasadami projektu wyznacza agentowi granice: nigdy nie czyta sekretów, logów, baz danych ani surowych odpowiedzi SIEM i pracuje na danych syntetycznych. Commity, uruchomienia na SIEM i jakiekolwiek zmiany w systemach wymagają mojej wyraźnej zgody. Dostęp agenta do wrażliwych danych był też zablokowany konfiguracją środowiska i uprawnieniami, nie tylko zapisem w zasadach.

2. 2

   Audyt, potem plan

   „Jesteś głównym inżynierem odpowiedzialnym za audyt, stabilizację i bezpieczny refaktoring istniejącego, produkcyjnego mini-SOAR. Poznaj repozytorium, wypisz ryzyka i zaproponuj plan w etapach. Nie przepisuj go od nowa.”

   Ten sam prompt dostały dwa modele; porównałem ich audyty i połączyłem je w jeden plan.

3. 3

   Przegląd przed kodem

   „Daj przegląd następnego zadania: problem, jak kod działa teraz, warianty z ich plusami i minusami, pliki, których dotyczy, i testy. Jeszcze nie implementuj.”

   Po wyborze wariantu: „Wprowadź go, uruchom testy, pokaż zmiany.”

4. 4

   Moduł analizy dla reguły z SIEM

   „Mamy nową regułę w SIEM: [opis pominięty]. Jakiego kontekstu potrzebuje analityk L2, żeby ocenić taki alert? Zbuduj moduł analizy, przetestuj go na danych syntetycznych, a potem uruchom na indeksie testowym.”

   Opis i definicja reguły zostały pominięte.

5. 5

   Mierz, nie czytaj

   „Uruchom raport pilota i powiedz, jak nam idzie. Tylko liczby i kategorie, bez treści alertów.”

6. 6

   Przeglądy oparte na dowodach

   „Zrób rzetelny audyt modułu, ale jako błąd zgłoś tylko to, co potwierdza nieudany test, przypadek syntetyczny albo liczby z uruchomienia. Pomysły na ulepszenia trzymaj osobno.”

7. 7

   Uwagi z codziennego użycia

   Krótkie uwagi z codziennej pracy z raportami, głównie o wygodzie i czytelności, trafiały do agenta jako kolejne zadania.

• Po pilocie silnik działa produkcyjnie od 09.2026 i obsługuje wszystkie alerty Windows: dopisuje kontekst albo wykrycia tam, gdzie ma coś do dodania. Jest skalibrowany pod logi środowiska, żeby nie wprowadzał szumu.
• Z wyników korzysta cały zespół SOC.
• Alert Windows jest obsłużony w ciągu ok. 2 minut od zdarzenia (mediana), przy 99,9% uptime.