Ослепить Sysmon. Выводим мониторинг из строя максимально незаметно

Sysmon Internals

Сра­зу ого­ворюсь, что тех­ники, опи­сан­ные в этой статье, тре­буют, что­бы у ата­кующе­го были адми­нис­тра­тив­ные при­виле­гии. Кто‑то ска­жет: зачем же нам углублять­ся во внут­рянку Windows, если с пра­вами адми­на мож­но оста­новить служ­бу Sysmon или вооб­ще уда­лить ее? Ответ прост. Во‑пер­вых, при реали­зации тра­дици­онных тех­ник, таких как оста­нов­ка служ­бы, завер­шение про­цес­са или пол­ное уда­ление Sysmon, штат­ный аудит Windows сфор­миру­ет мас­су событий (начиная с EventID 4689 в жур­нале Security и закан­чивая событи­ем EventID 1 в жур­нале System от про­вай­дера FilterManager). Во‑вто­рых, это прос­то полез­ное упражне­ние: мы дол­жны как мож­но глуб­же раз­бирать­ся в под­систе­ме безопас­ности любимой ОС, что­бы понимать тех­ники, которы­ми поль­зуют­ся хакеры.

Как уже говори­лось в статье «Sysmon для безопас­ника», Sysmon — это инс­тру­мент, пред­назна­чен­ный для углублен­ного монито­рин­га активнос­ти, про­исхо­дящей в сис­теме, который поз­воля­ет сущес­твен­но рас­ширить штат­ный аудит ОС Windows.

Вот как его работа выг­лядит изнутри.

Пер­вая коман­да (search <ServicePattern>) ищет зарегис­три­рован­ные в сис­теме служ­бы и драй­веры с помощью Win32-фун­кции EnumServicesStatus(). Вид­но, что в сис­теме дей­ству­ют две сущ­ности: служ­ба режима поль­зовате­ля — Sysmon64 и драй­вер SysmonDrv. Обе сущ­ности запус­кают­ся авто­мати­чес­ки при стар­те сис­темы (поле StartType). Эту информа­цию мы получа­ем с помощью коман­ды show all <ServiceName>, которая пос­ледова­тель­но вызыва­ет QueryServiceStatus() (для получе­ния текуще­го ста­туса работы — запуще­на или оста­нов­лена) и QueryServiceConfig() (для получе­ния оставшей­ся информа­ции).

Ло­гич­но пред­положить, что события (или часть событий), которые пишет служ­ба Sysmon64 в жур­нал Microsoft-Windows-Sysmon\Operational, фор­миру­ются модулем ядра SysmonDrv, а для вза­имо­дей­ствия служ­бы и драй­вера дол­жно быть ком­муника­цион­ное устрой­ство (device). Что­бы про­верить это, пос­мотрим на спи­сок хен­длов, откры­тых служ­бой Sysmon64 (про­цес­сом Sysmon64.exe).

По­лучим иден­тифика­тор про­цес­са Sysmon64.exe (search name <ProcessPattern>).

Ко­ман­да search name <ProcessPattern> работа­ет через вызов CreateToolhelp32Snapshot(): фун­кции Process32First() и Process32Next().

Пос­ле того как мы получим ID про­цес­са, пос­мотрим спи­сок его хен­длов.

Из вывода вид­но, что у про­цес­са Sysmon64.exe есть нес­коль­ко откры­тых хен­длов на устрой­ства. Обра­ти вни­мание на устрой­ство \Device\SysmonDrv, одно­имен­ное драй­веру. Ско­рее все­го, имен­но с помощью это­го устрой­ства служ­ба режима поль­зовате­ля Sysmon64 получа­ет информа­цию от драй­вера и впос­ледс­твии фор­миру­ет события ауди­та.

Ко­ман­да show handles <PID> <Type> реали­зует вызов NtQueryInformationProcess() с парамет­ром ProcessHandleInformation.

Пер­вый параметр (ProcessHandle) — дес­крип­тор про­цес­са, хен­длы которо­го мы хотим уви­деть. Его мож­но получить при помощи фун­кции OpenProcess() с парамет­ром PROCESS_QUERY_INFORMATION.

ProcessInformationClass — это харак­тер зап­рашива­емой информа­ции. В нашем слу­чае этот параметр равен ProcessHandleInformation, то есть мы хотим получить информа­цию о хен­длах про­цес­са.

Сле­дующим идет ProcessInformation, ука­затель на память, в которую будет помещен резуль­тат нашего зап­роса — PPROCESS_HANDLE_SNAPSHOT_INFORMATION, то есть ука­затель на струк­туру, содер­жащую спи­сок всех хен­длов и их количес­тво.

Чет­вертый и пятый парамет­ры ука­зыва­ют раз­мер име­ющей­ся и тре­буемой памяти, в которую помеща­ется воз­вра­щаемый фун­кци­ей резуль­тат.

Закрытие хендла через дубликат

Ес­ли наши пред­положе­ния вер­ны, то, что­бы Sysmon перес­тал фор­мировать события ауди­та, ата­кующий может зас­тавить про­цесс Sysmon64.exe зак­рыть хендл на это устрой­ство.