Детект на связи. Учимся обнаруживать следы атак на EDR

Как извес­тно, в нед­рах средств монито­рин­га для Windows лежат два основных механиз­ма, которые поз­воля­ют им фун­кци­они­ровать: под­систе­ма Event Tracing for Windows и ядер­ная под­дер­жка, реали­зован­ная в виде драй­веров.

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

Детектим атаки на драйвер

Обнаруживаем манипуляции с Security Descriptor

Бу­дем счи­тать, что пер­вая связ­ка тех­ник, которую уда­лось поэкс­плу­ати­ровать нашим пен­тесте­рам, — манипу­ляция дес­крип­тором безопас­ности объ­екта, плав­но перехо­дящая в манипу­ляцию хен­длом. Вкрат­це напом­ню, как это про­исхо­дило.

1. Основная часть событий, которую Sysmon пишет в свой жур­нал, пос­тупа­ет от драй­вера SysmonDrv. Для это­го сам драй­вер соз­дает ком­муника­цион­ное устрой­ство \\Device\SysmonDrv. Это объ­ект ядра, а у объ­екта ядра есть дес­крип­тор безопас­ности (security descriptor, SD), который явно опре­деля­ет, кому мож­но получить дос­туп к это­му устрой­ству, а кому нет.
2. Ата­кующий меня­ет этот дес­крип­тор таким обра­зом, что­бы про­цес­су Sysmon64.exe, работа­юще­му от име­ни учет­ной записи Local System, было отка­зано в пре­дос­тавле­нии дос­тупа к устрой­ству.
3. Одна­ко на момент манипу­ляций с SD у про­цес­са Sysmon64.exe уже есть откры­тый хендл устрой­ства с пра­вами чте­ния, который необ­ходимо обно­вить.
4. Для это­го он дела­ет вызов DuplicateHandle с парамет­ром DUPLICATE_CLOSE_SOURCE и таким обра­зом копиру­ет хендл объ­екта \\Device\SysmonDrv из про­цес­са Sysmon64.exe в собс­твен­ный вре­донос­ный про­цесс с пос­леду­ющим зак­рыти­ем хен­дла‑источни­ка, зас­тавляя тем самым Sysmon64.exe пов­торно зап­росить хендл ком­муника­цион­ного устрой­ства.

Да­вай на это пос­мотрим с позиции детек­та. Пер­вым делом вре­донос­ный про­цесс вызыва­ет CreateFile() (с парамет­ром WRITE_DAC), что­бы получить хендл объ­екта \\.\SysmonDrv. Пос­ле это­го дер­гает фун­кцию SetSecurityInfo(), которая уста­нав­лива­ет новый спи­сок DACL. В этот момент дол­жно быть сге­нери­рова­но два события: EventID 4656 — зап­рос хен­дла объ­екта и EventID 4663 — попыт­ка выпол­нения опе­рации с объ­ектом (при усло­вии, что нас­тро­ен аудит объ­ектов ядра).

Мож­но было бы детек­тить такую активность на осно­ве перечис­ленных событий. Одна­ко у это­го под­хода есть сущес­твен­ный недос­таток: события 4656 и 4663 генери­руют­ся слиш­ком час­то. Поэто­му мы пой­дем дру­гим путем.

Под­систе­ма безопас­ности Windows может генери­ровать события, которые пря­мо сви­детель­ству­ют об изме­нении спис­ка DACL (но тут тоже есть нес­коль­ко под­водных кам­ней, о которых я рас­ска­жу даль­ше). Давай сна­чала пос­мотрим на это событие, а потом погово­рим о том, как же его заполу­чить. Итак, меня­ем спи­сок DACL.

От­кры­ваем жур­нал Security и видим сле­дующее.

Со­бытие EventID 4670 говорит нам о том, что вре­донос­ный про­цесс, запущен­ный от име­ни адми­нис­тра­тора, изме­нил DACL для объ­екта \\Device\SysmonDrv. При­чем отоб­ража­ются как ста­рые, так и новые раз­решения для объ­екта. Отлично, напишем усло­вие фор­мирова­ния алер­та на язы­ке eXtraction and Processing:

Пол­ный текст пра­вила (с вари­ациями детек­та на осно­ве EventID 4656 и EventID 4663) мож­но пос­мотреть в репози­тории Open XP Rules.

Для Elastic SIEM детект име­ет сле­дующий вид.