Sysmon – szczegółowe monitorowanie aktywności w Windows
Sysmon (System Monitor) to narzędzie firmy Microsoft z pakietu Sysinternals, przeznaczone do rejestrowania szczegółowych zdarzeń systemowych w Windows. W odróżnieniu od Zabbixa nie służy przede wszystkim do monitorowania wydajności, lecz do widoczności bezpieczeństwa i analizy zachowania systemu.
Najprościej:
Zabbix → Czy Windows działa poprawnie?
Sysmon → Co dokładnie dzieje się w Windows?
Wazuh → Czy to może być zagrożenie?
Gdzie Sysmon pasuje w architekturze?
WINDOWS
|
Sysmon
|
Windows Event Log
|
+-----------+-----------+
| | |
Wazuh Elastic Graylog
| | |
+-----------+-----------+
|
Security Analysis
Sysmon sam w sobie nie jest SIEM-em. Jego głównym zadaniem jest generowanie szczegółowej telemetrii.
Co rejestruje Sysmon?
W zależności od konfiguracji może rejestrować m.in.:
- uruchamianie procesów,
- połączenia sieciowe,
- ładowanie sterowników,
- zmiany plików,
- operacje na rejestrze,
- tworzenie procesów zdalnych,
- PowerShell,
- WMI,
- DNS,
- dostęp do określonych plików,
- zmianę wartości skrótów plików.
Czyli zamiast:
"Na komputerze coś się wydarzyło"
możemy dostać:
Process:
powershell.exe
Parent:
winword.exe
CommandLine:
powershell.exe -enc ...
User:
DOMAIN\user
I to jest ogromna różnica z punktu widzenia analizy bezpieczeństwa.
Event ID 1 – Process Creation
Jednym z najbardziej znanych zdarzeń Sysmona jest:
Event ID 1
Process Create
Przykład:
WINWORD.EXE
|
v
powershell.exe
|
v
cmd.exe
|
v
whoami.exe
Sysmon może pomóc zobaczyć taki łańcuch procesów.
To jest bardzo istotne podczas analizy podejrzanego zachowania.
Parent Process
Jedną z najcenniejszych informacji jest proces nadrzędny.
Przykładowo:
explorer.exe
|
v
powershell.exe
jest czymś zupełnie innym niż:
winword.exe
|
v
powershell.exe
Drugi przypadek może wymagać dokładniejszego sprawdzenia.
Sysmon pozwala budować process trees.
Command Line
Sysmon może rejestrować linię poleceń procesu.
Przykład:
powershell.exe
-NoProfile
-ExecutionPolicy Bypass
-Command ...
Dzięki temu analityk nie widzi tylko:
powershell.exe
ale również tego, jak został uruchomiony.
Event ID 3 – Network Connection
Sysmon może również rejestrować połączenia sieciowe.
Przykład:
Process
|
+--> powershell.exe
|
+--> 185.x.x.x:443
Możemy otrzymać informacje takie jak:
Source IP
Destination IP
Destination Port
Protocol
Process
Process ID
To pozwala powiązać proces z ruchem sieciowym.
Dlaczego połączenie procesu i sieci jest ważne?
Sam log:
192.168.1.10 → 8.8.8.8:443
niewiele mówi.
Ale:
powershell.exe
|
v
192.168.1.10 → suspicious-ip:443
jest już znacznie bardziej interesujący.
Możemy wtedy zadać pytanie:
Dlaczego PowerShell komunikuje się z tym adresem?
Event ID 22 – DNS Query
Sysmon może rejestrować zapytania DNS.
Przykład:
powershell.exe
|
v
DNS Query
|
v
example-domain.com
Możemy dzięki temu powiązać:
Process
+
DNS request
+
Network connection
To bardzo przydatne podczas analizy incydentów.
Event ID 11 – File Create
Sysmon może również rejestrować tworzenie plików.
Przykład:
powershell.exe
|
v
C:\Users\User\AppData\Temp\payload.exe
Możemy następnie sprawdzić:
Who created it?
Which process?
Where?
When?
What hash?
Hash pliku
Sysmon może obliczać hashe plików, zależnie od konfiguracji.
Przykład:
payload.exe
|
+--> SHA256
+--> MD5
Dzięki temu możemy porównywać artefakty z bazami threat intelligence lub analizować, czy ten sam plik występuje na wielu hostach.
Event ID 13 – Registry Value Set
Sysmon może również monitorować wybrane zmiany rejestru.
Przykładowo:
Registry
|
+--> Run
+--> RunOnce
+--> inne monitorowane lokalizacje
Możemy wykrywać podejrzane zmiany konfiguracji.
Persistence
Jednym z zastosowań Sysmona jest analiza mechanizmów persistence.
Przykładowo:
Malware
|
v
Registry Modification
|
v
Startup
|
v
Persistence
Sysmon dostarcza wtedy telemetrię, która może być analizowana przez SIEM.
Sysmon + PowerShell
To bardzo ważne połączenie.
User
|
v
WINWORD.EXE
|
v
PowerShell
|
+--> Network
|
+--> File
|
+--> Registry
Sysmon może dostarczyć wiele elementów tego łańcucha.
Dlatego jest często wykorzystywany w środowiskach, gdzie bezpieczeństwo Windows jest istotne.
Sysmon + Wazuh
To jeden z najbardziej logicznych zestawów.
Windows
|
Sysmon
|
Windows Event Log
|
Wazuh Agent
|
v
Wazuh
|
v
Security Detection
Role są różne:
Sysmon
→ generuje szczegółową telemetrię
Wazuh
→ analizuje dane i generuje detekcje/alerty
Sysmon + Elastic
Również bardzo popularna architektura:
Windows
|
Sysmon
|
Event Log
|
Elastic Agent
|
v
Elastic
|
v
Kibana
W Kibanie możemy następnie analizować:
Process Creation
Network Connections
DNS
Files
Registry
Sysmon + Graylog
Można również centralizować dane:
Windows
|
Sysmon
|
Event Log
|
Graylog Collector / Agent
|
v
Graylog
Daje to możliwość przeszukiwania zdarzeń Sysmona razem z innymi logami infrastruktury.
Sysmon + Fluent Bit
I tutaj mamy ciekawą relację z poprzednim tematem.
Fluent Bit może pełnić rolę collectora, natomiast Sysmon generuje dane:
Windows
|
Sysmon
|
Event Log
|
Fluent Bit
|
v
Backend
Czyli:
Sysmon → telemetry
Fluent Bit → transport
Backend → storage/analysis
Sysmon + OpenTelemetry
W szerszej architekturze telemetrycznej możemy również rozważyć wykorzystanie OpenTelemetry jako warstwy transportowej/normalizacyjnej.
Ale tutaj warto zachować właściwe role:
Sysmon
→ Windows security telemetry
OpenTelemetry
→ telemetry collection/transport standard
Elastic/Loki/etc.
→ backend
Sysmon nie jest zamiennikiem OTel.
Sysmon vs Windows Event Log
To też ważne.
Windows Event Log to mechanizm systemu Windows do rejestrowania zdarzeń.
Sysmon dostarcza dodatkową, znacznie bardziej szczegółową telemetrię bezpieczeństwa.
Możemy więc myśleć:
Windows
|
+--> Standard Event Logs
|
+--> Sysmon Events
|
+--------> SIEM
Sysmon vs Zabbix
To zupełnie różne zastosowania:
Zabbix:
CPU = 95%
RAM = 90%
Disk = 92%
Sysmon:
WINWORD.EXE
|
v
powershell.exe
|
v
network connection
Czyli:
Zabbix monitoruje stan infrastruktury.
Sysmon monitoruje zachowanie Windows.
Sysmon vs Wazuh
Jeszcze ważniejsze:
Sysmon
→ sensor / telemetry
Wazuh
→ security monitoring / detection
To dlatego bardzo sensowne jest używanie ich razem.
Sysmon
|
v
Detailed Events
|
v
Wazuh
|
v
Alerts
Sysmon vs EDR
Sysmon nie jest pełnoprawnym EDR.
EDR zwykle oferuje znacznie szerszy zestaw funkcji:
Endpoint
|
+--> Telemetry
+--> Detection
+--> Response
+--> Investigation
+--> Isolation
Sysmon przede wszystkim dostarcza telemetrię.
Dlatego:
Sysmon ≠ EDR
ale może być bardzo wartościowym źródłem danych dla systemów security.
Konfiguracja Sysmona
To jedna z najważniejszych rzeczy.
Nie należy bezmyślnie włączać wszystkiego na wszystkich komputerach.
Możemy doprowadzić do sytuacji:
1000 endpoints
×
dużo eventów
=
ogromna ilość danych
Dlatego konfiguracja powinna być dostosowana do celu.
Przykładowo możemy skoncentrować się na:
Process Creation
Network Connections
DNS
File Creation
Registry
PowerShell
i odpowiednio filtrować zdarzenia.
Dlaczego filtrowanie jest ważne?
Załóżmy:
10 000 events/minute
Po odpowiednim filtrowaniu:
500 relevant events/minute
Dostajemy:
mniej storage
mniej noise
mniej alert fatigue
łatwiejszy threat hunting
To jest bardzo ważne w produkcyjnym SOC.
Sysmon i MITRE ATT&CK
Sysmon jest często wykorzystywany jako źródło danych do mapowania aktywności na techniki MITRE ATT&CK.
Przykładowo:
Process Creation
|
v
Execution
Network Connection
|
v
Command and Control
Registry Modification
|
v
Persistence
Sam Sysmon nie mówi automatycznie „to jest atak”. Dostarcza dane, które mogą zostać wykorzystane do takiej analizy.
Przykładowy łańcuch ataku
Możemy mieć:
Malicious Document
|
v
WINWORD.EXE
|
v
PowerShell
|
v
Network Connection
|
v
File Creation
|
v
Persistence
Sysmon może dostarczyć dużą część telemetrii potrzebnej do odtworzenia takiego łańcucha.
Następnie Wazuh, Elastic lub inny system analityczny może te dane korelować.
Sysmon w dużej architekturze
Po dodaniu Sysmona nasz stos zaczyna wyglądać naprawdę sensownie:
WINDOWS ENDPOINTS
|
Sysmon
|
Windows Event Logs
|
+-------------+-------------+
| | |
Wazuh Elastic Graylog
| | |
+-------------+-------------+
|
Security Analysis
LINUX ENDPOINTS
|
+--------------+--------------+
| | |
auditd journald eBPF
| | |
+--------------+--------------+
|
Logs / Telemetry
Network:
NETWORK
|
+------------+------------+
| |
Suricata Zeek
| |
+------------+------------+
|
Security
Infrastructure:
Servers / Switches / Firewall
|
Zabbix
|
Infrastructure Health
A pełny obraz
IT ENVIRONMENT
|
+-------------------------+-------------------------+
| | |
Windows Linux Network
| | |
Sysmon auditd/journald Suricata/Zeek
| | |
+-------------------------+-------------------------+
|
Security Data
|
+---------------+---------------+
| | |
Wazuh Elastic Graylog
| | |
+---------------+---------------+
|
Security Analysis
OBSERVABILITY
|
+--------+--------+
| |
OpenTelemetry Fluent Bit
| |
+--------+--------+
|
Prometheus / Loki / Tempo
|
Grafana
INFRASTRUCTURE
|
Zabbix
Najważniejsze rozróżnienie
Całą serię można teraz zapamiętać bardzo prosto:
Zabbix → Czy infrastruktura działa?
Prometheus → Jakie mamy metryki?
OpenTelemetry → Jak zbieramy telemetrykę?
Fluent Bit → Jak zbieramy/przesyłamy logi?
Loki → Gdzie trzymamy logi?
Tempo → Gdzie trzymamy traces?
Grafana → Jak to wizualizujemy?
Graylog → Centralne log management
Elastic → Search / analytics / SIEM
Wazuh → Security monitoring
Sysmon → Co dzieje się na Windows?
auditd → Co dzieje się na Linux?
Suricata → Co dzieje się w ruchu sieciowym?
Zeek → Jak analizować zachowanie sieci?
Sysmon jest więc jednym z najciekawszych „sensorów” w środowisku Windows. Sam nie zastępuje SIEM, EDR ani Wazuha — jego największą wartością jest dostarczanie szczegółowej telemetrii, dzięki której można później odtworzyć co uruchomiono, przez jaki proces, z jakimi parametrami, jakie pliki powstały i z czym komputer się komunikował.
Ostatnie doniesienia z Rosji pokazują, ze tamtejsza wyszukiwarka Yandex w minionych dniach usunęła z indeksu kilkaset stron internetowych. Dlaczego? Właściciele Czytaj dalej
Jak Steam Workshop umożliwia użytkownikom tworzenie i udostępnianie modyfikacji do gier Steam to jedna z najbardziej popularnych platform dystrybucji gier, Czytaj dalej
