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

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

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

Воздействуем на устройство SysmonDrv

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

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

Фейковый DosDevice

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

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

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

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

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

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

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

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

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

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

• Пер­вым парамет­ром (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.