Добиваем мониторинг. Как работают продвинутые атаки на Sysmon

Содержание статьи

• Фейковый DosDevice
• Подмена хендла SysmonDrv
• Манипуляции с ETW
• Изменяем параметры отбора событий провайдера

По­лучив дос­туп к взло­ман­ной сис­теме, ата­кующий пер­вым делом реали­зует тех­ники ук­лонения от обна­руже­ния, которые поз­воля­ют осла­бить монито­ринг безопас­ности инфраструк­туры и, как следс­твие, дей­ство­вать мак­сималь­но незамет­но.

Се­год­ня давай раз­берем ряд тех­ник, которые помога­ют зло­умыш­ленни­кам обой­ти рас­ширен­ный монито­ринг. В качес­тве подопыт­ного инс­тру­мен­та будем исполь­зовать Sysmon.

warning

Статья име­ет озна­коми­тель­ный харак­тер и пред­назна­чена для спе­циалис­тов по безопас­ности, про­водя­щих тес­тирова­ние в рам­ках кон­трак­та. Автор и редак­ция не несут ответс­твен­ности за любой вред, при­чинен­ный с при­мене­нием изло­жен­ной информа­ции. Рас­простра­нение вре­донос­ных прог­рамм, наруше­ние работы сис­тем и наруше­ние тай­ны перепис­ки прес­леду­ются по закону.

Эта статья логичес­ки делит­ся на две час­ти — по источни­кам информа­ции, на осно­ве которых Sysmon фор­миру­ет свои события. В пер­вой мы пос­мотрим, как мож­но нарушить вза­имо­дей­ствие меж­ду драй­вером SysmonDrv и служ­бой Sysmon64, во вто­рой — погово­рим о воз­дей­ствии на под­систе­му ETW. Итак, поеха­ли!

Воздействуем на \DeviceSysmonDrv

В моем пре­дыду­щем матери­але я рас­ска­зывал о том, как осле­пить рас­ширен­ный монито­ринг, манипу­лируя с дес­крип­тором безопас­ности объ­екта ком­муника­цион­ного устрой­ства \DeviceSysmonDrv и про­воци­руя Sysmon на пов­торное откры­тие хен­дла это­го устрой­ства (вызов DuplicateHandle() с опци­ей DUPLICATE_CLOSE_SOURCE).

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

Фейковый DosDevice

Суть этой тех­ники зак­люча­ется в том, что­бы соз­дать сим­воличес­кую ссыл­ку (сим­линк) на ком­муника­цион­ное устрой­ство \DeviceSysmonDrv рань­ше, чем это сде­лает драй­вер Sysmon. Успешная экс­плу­ата­ция поз­волит ата­кующе­му под­менить объ­ект ком­муника­цион­ного устрой­ства и тем самым осле­пить Sysmon. Про­цесс режима поль­зовате­ля Sysmon64.exe не смо­жет получать никакую информа­цию и, как следс­твие, не будет фор­мировать события.

Для понима­ния работы этой тех­ники давай вспом­ним, как работа­ет инс­тру­мент Sysmon. В его сос­тав вхо­дят два ком­понен­та:

Драй­вер SysmonDrv в про­цес­се сво­ей ини­циали­зации соз­дает ком­муника­цион­ное устрой­ство \DeviceSysmonDrv, что­бы служ­ба Sysmon64 мог­ла получать от него информа­цию. Одна­ко здесь сущес­тву­ет неболь­шая осо­бен­ность: поль­зователь­ские при­ложе­ния не могут нап­рямую вза­имо­дей­ство­вать с девай­сами. Для этой цели в сис­теме соз­дает­ся сим­воличес­кая ссыл­ка, через которую и про­исхо­дит все «обще­ние». Вот как это выг­лядит в WinObj.

А что будет, если ата­кующий попыта­ется под­менить эту ссыл­ку? Давай пос­мотрим.

В сис­теме сущес­тву­ет спе­циаль­ный вызов DefineDosDevice, который поз­воля­ет соз­давать (и пере­опре­делять) сим­воличес­кие ссыл­ки на устрой­ства:

BOOL DefineDosDeviceW( [in] DWORD dwFlags, [in] LPCWSTR lpDeviceName, [in, optional] LPCWSTR lpTargetPath);

• В парамет­ре dwFlags переда­ются фла­ги, кон­тро­лиру­ющие работу фун­кции. Ука­жем DDD_NO_BROADCAST_SYSTEM, что будет озна­чать «не сооб­щать никому об изме­нении».
• Во вто­ром парамет­ре (lpDeviceName) ука­зыва­ем имя сим­линка — SysmonDrv, а в треть­ем (lpTargetPath) — фей­ковый путь к устрой­ству (??Devicefakedrv).

Бла­года­ря фун­кции мы можем под­менить сим­линк SysmonDrv.

Од­нако это нуж­но успеть сде­лать до того момен­та, как про­цесс Sysmon64.exe ее откро­ет. Для это­го вре­донос­ный про­цесс FakeDosDevice.exe дол­жен быть зарегис­три­рован в качес­тве служ­бы, а у сер­виса Sysmon64 в зависи­мос­тях дол­жна быть ука­зана ссыл­ка на него.

Для регис­тра­ции служб есть спе­циаль­ная фун­кция CreateService:

SC_HANDLE CreateServiceA( [in] SC_HANDLE hSCManager, [in] LPCSTR lpServiceName, [in, optional] LPCSTR lpDisplayName, [in] DWORD dwDesiredAccess, [in] DWORD dwServiceType, [in] DWORD dwStartType, [in] DWORD dwErrorControl, [in, optional] LPCSTR lpBinaryPathName, [in, optional] LPCSTR lpLoadOrderGroup, [out, optional] LPDWORD lpdwTagId, [in, optional] LPCSTR lpDependencies, [in, optional] LPCSTR lpServiceStartName, [in, optional] LPCSTR lpPassword);

• Пер­вым парамет­ром (hSCManager) переда­ется хендл базы дан­ных дис­петче­ра управле­ния служ­бами. Его мож­но получить с помощью фун­кции OpenSCManager.
• Вто­рой (lpServiceName) и тре­тий (lpDisplayName) парамет­ры при­нима­ют имя регис­три­руемой служ­бы. Уста­новим их рав­ными FakeDosDevice.
• Так как вызов CreateService воз­вра­щает хендл на соз­данную служ­бу, с которым мож­но работать даль­ше, а сама служ­ба — это объ­ект ядра, в чет­вертом парамет­ре (dwDesiredAccess) переда­ется зап­рашива­емый дос­туп.
• Да­лее мы ука­зыва­ем тип служ­бы — SERVICE_WIN32_OWN_PROCESS (параметр dwServiceType).
• С помощью парамет­ра dwStartType ука­зыва­ем тип авто­запус­ка. В нашем слу­чае он равен SERVICE_AUTO_START.
• В парамет­ре dwErrorControl переда­ется уро­вень кри­тич­ности и дей­ствие в слу­чае ошиб­ки (SERVICE_ERROR_NORMAL).
• В кон­це (lpBinaryPathName) ука­зыва­ем путь к исполня­емо­му фай­лу FakeDosDevice.exe, получа­емый динами­чес­ки с помощью фун­кции QueryFullProcessImageName.
• Ос­тавши­еся парамет­ры уста­новим в NULL.

Итак, служ­бу FakeDosDevice мы зарегис­три­рова­ли. Теперь ее нуж­но добавить в зависи­мос­ти Sysmon64. Если в сис­теме сто­ит Sysmon вер­сии 15 и выше, то штат­ными средс­тва­ми это сде­лать не получит­ся, пос­коль­ку он работа­ет как Protected Process.

Источник: xakep.ru