Na początku sierpnia 2014 r Microsoft (Sysinternals) udostępnił nowe narzędzie analityczne: Sysmon. Czas skrobnąć kilka słów o tym potworze..
Wprowadzenie
Sysmon to zestaw sterownik (sysmon.sys) + usługa (sysmon.exe), które służą do monitorowania niektórych aktywności w systemie:
- start procesu (Process Create);
- zmiana czasu utworzenia pliku (File creation time change);
- połączenia sieciowe (Network connection);
- usunięcie pliku (File delete);
- zmiana zawartości schowka (Clipboard change)
+ dodatkowe związane z pracą usługi (Sysmon service state, error report)
przy czym w wersji dostępnej publicznie tylko trzy pierwsze są aktywne.
Wybór właśnie tych spośród milionów dostępnych w systemie nie jest przypadkowy i wiąże się ściśle z tym, o czym Mark Russinovich mówił pod koniec września w ramach prezentacji Sysmona na Defrag Tools - wsparciem w walce z malware. Sterownik skrupulatnie zbiera te zdarzenia, aby następnie usługa mogła wrzucić je do wspólnego kotła ETW i zapisać w dzienniku zdarzeń.
Rys 1. Ustawienia logu Sysmona
W zasadzie pozostaje nam podłączenie się do tego żródełka i wyciągnięcie z niego tego, co nas interesuje.
CreateProcess
O tym zdarzeniu pisałem już na blogu wielokrotnie. Pokazałem jak zebrać interesujące nas informacje podczas startu windowsów debugując system w trybie jądra oraz włączając logowanie odpowiednich zdarzeń w NT Kernel Loggerze. Teraz, dzięki Sysmonowi mamy możliwość zebrania tych informacji w ramach sesji ETW w user mode, więc nie musimy już blokować sesji kernel (w Windows 7 mamy w danym momencie dostępną tylko jedną, w Windows 8/8.1 - osiem) aby otrzymać te zdarzenia, dostając dodatkowo sumiennie wyliczony przez sterownik skrót pliku obrazu tworzonego procesu oraz wiele innych ciekawych informacji.
W zasobach sysmon.exe można znaleźć plik zawierający manifest ETW, który możemy zapisać jako sysmon.man, a następnie z jego pomocą przygotować odpowiedni parser.
Rys 2. Zasoby w sysmon.exe
Mając odpowiedni parser możemy stworzyć własną sesję i samodzielnie podpiąć się do strumienia zdarzeń przepływających przez ETW, oczywiście wybierając to, co dla nas jest najciekawsze. W tym celu sięgamy do biblioteki Microsoft.Diagnostics.Tracing.TraceEvent.dll, a reszta to już z górki.
using (sysmonUserSession =new TraceEventSession("ZineNetSysmonEventsSession"))
{
sysmonUserSession.EnableProvider(SysmonTraceEventParser.ProviderGuid, TraceEventLevel.Always);
var sysmonSession =new SysmonTraceEventParser(sysmonUserSession.Source);
sysmonSession.SysmonTaskProcessCreate += sysmonSession_SysmonTaskProcessCreate;
sysmonUserSession.Source.Process();
}
W funkcji obsługującej napływające pięknie przeparsowane zdarzenia możemy pokusić się o sięgnięcie do bazy ‘lubianych’ skrótów oraz poddać program weryfikacji pod kątem ewentualnego podpisu. Oczywiście możemy też zrobić tysiąc innych rzeczy, wedle własnego uznania, w tym np. utłuc niechciany proces ;)
Niech przykładem będzie napisany przeze mnie mały toolik, który dostępny jest tu: [KLIK]. (Oczywiście wymaga zainstalowanego i chodzącego Sysmona ;))
Do dyspozycji mamy następujące właściwości:
UtcTime: 2014-10-17 19:16
ProcessGuid: {000006b2-6af0-5441-0000-00106ccc4501}
ProcessId: 7316
Image: C:\Program Files (x86)\Google\Update\GoogleUpdate.exe
CommandLine: "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /ua /installsource scheduler
User: ZARZĄDZANIE NT\SYSTEM
LogonGuid: {000006b2-4736-5441-0000-0020e7030000}
LogonId: 0x3e7
TerminalSessionId: 0
IntegrityLevel: System
HashType: MD5
Hash: 506708142BC63DABA64F2D3AD1DCD5BF
ParentProcessGuid: {000006b2-473e-5441-0000-0010db180200}
ParentProcessId: 1648
ParentImage: C:\Windows\system32\taskeng.exe
ParentCommandLine: taskeng.exe {18D2B821-85A2-4D84-9A91-62B9E7ADEDA2} S-1-5-18:NT AUTHORITY\System:Service:
Prawdziwa kopalnia wiedzy! Guidy dają nam gwarancję sensownego identyfikowania procesów (identyfikatory wracają do puli dostępnych po zakończeniu procesu!) oraz wiązania go z procesem macierzystym. Mamy na widelcu proces macierzysty, wszystkie parametry startowe (command line) zarówno samego procesu, jak i jego rodzica, a także id sesji, usera oraz oczywiście skrót pliku obrazu. Czego chcieć więcej? :)
Łyżka dziegciu
Niestety, pomimo zapewnień Marka Russinovicha o kilkunastomiesięcznym przetestowaniu sysmona w wewnętrznej sieci Microsoft, pierwsza wersja nie jest pozbawiona wad. Poniżej te najważniejsze:
1. Windows XP. To nie jest martwy system, niestety. Większość narzędzi sysinternals działa bez problemu na Windows XP, jednak nie sysmon. Na stronie poświęconej narzędziu możemy znaleźć wzmiankę dającą płonną nadzieję - ‘w systemach Vista i nowszych zdarzenia zapisywane są do logu w ramach dziennika aplikacji i usług/Microsoft/Windows/Sysmon/Operational, a we wcześniejszych systemach do logu systemowego. No cóż, jakoś zapomniało się o brakujących eksportach w ntoskrnl.exe, które importowane są w sysmon.sys i sterownik po prostu nie działa :( (a instaluje się!)
Rys 3. Brakujące eksporty na Windows XP
2. UtcTime. Dlaczego, ach dlaczego informacje zapisywane są w postaci łańcucha znaków, a czas podawany z dokładnością minutową? Na tych 16 bajtach można zmieścić wiek wszechświata zapisany z naprawdę dużą precyzją :) Rozumiem, że zdarzenia pojawiają się w ETW z pewnym opóźnieniem (ok. 4-5 sek), jednak czas zapisywany jest przez driver w momencie tworzenia, więc można pokusić się o większą precyzję.
3. Instalacja z konta systemowego: czasem sterownik zapisywany jest do c:\windows\temp i pomimo zgłoszenia, że wszystko ok, po prostu nie działa. Jest 68 kB log, a w nim pustka. Pozostaje walka z ręczną deinstalacją i ponowną instalacją.
4. Zdarzenia trafiają do logu mocno niedeterministycznie, więc należy liczyć się z tym, że wpis o procesie macierzystym pojawi się po potomku.
5. Log domyślnie ma rozmiar 64MB, a każdy z wpisów ok. 1 kB. Wygląda więc na to, że zmieści się cała masa zdarzeń i nic nie zgubimy. Nic bardziej mylnego - wystarczy jeden instalator, który wykona całą masę operacji na plikach i zostaniemy z jednym zdarzeniem create process z ostatnich kilku dni - zdarzenia file creation time change trafiają do tego samego logu, co create process i network connection.
6. Niestety najgorsze przed nami. Sysmon w nieco ponad 5% przetestowanych przeze mnie przypadków (przy sumie ok. 1 mln zdarzeń create process) podaje błędny guid dla parent process. Okazuje się, że czasem następuje przekłamanie w guidach - w części tych przypadków na podstawie innych właściwości byłem w stanie powiązać proces z jego rodzicem, jednak w wielu pozostałych nie byłem w stanie tego zrobić. Wygląda to na błąd w sterowniku, ale przyznaję, że nie przyglądałem się bliżej.
Podsuma
Czy pomimo tych wszystkich niedoskonałości warto korzystać z sysmona? Ależ oczywiście, że tak! Wpływ na wydajność systemu jest praktycznie pomijalny. Dostarcza całą masę informacji do zbiornika w user sessions, a to, że czasem jest problem z określeniem parenta to drobiazg - można tę informację znaleźć gdzie indziej, lub po prostu jej nie potrzebować - czy musimy mieć online’owy graf procesów? :) Zapychanie logu to już zupełnie pomijalna sprawa - poza zabawą w powiększanie logu w ramach eventlogu, lub jego centralizacją, wystarczy skorzystać z mojej przykładowej aplikacji i samemu kolekcjonować interesujące nas zdarzenia, bez obawy o ich zgubienie, lub nadpisanie.