Mimikatz: предлагает сдаться? Часть 1

[bga68comp]

За месяц до атаки Petya.A наши админы ИТ-инфраструктуры, как дети, бегали, кричали и смеялись, что нашли потрясающую уязвимость Windows...
Только админы информационной безопасности устало отмахивались и про себя думали "Боже, какие дети!!!" потому, что это не уязвимость...
"Получение debug-привилегии mimikatz – это не взлом Windows, не несанкционированный доступ – это использование default-настройки времён 1999 года, т.е. стартового релиза Windows 2000. Возможность проведения таких действий – это проблема не ОС, а квалификации администраторов и инженеров."

Хотел об этом написать, но пока я думал, толковые ребята уже написали почти то, что я хотел

Привожу без сокращений:
Оригинал: https://www.atraining.ru/mimikatz-lsa-protection/

Mimikatz предлагает сдаться

Разбираем очередное всёпропальческое-админское на тему утилиты mimikatz

В процессе недавней атаки вируса-вымогателя Пети достаточно много внимания было уделено новому, со времён WannaCry, payload’у этого вируса. Действительно, новый зловред оперировал для захвата власти на локальных хостах не одной, а целым набором уязвимостей – касающихся не только ОС Windows, но и, к примеру, пакета Microsoft Office.

Особое внимание привлёк один из компонентов – т.н. mimikatz.

Этому модулю приписываются воистину чудодейственные возможности, заставляющие вспомнить золотые времена линукссообществ для умственно одарённых старшеклассников, с экспертным мнением вида:

любую венду кароч одним пакетом кладёт прорубает любой файервол если только не под линем работает

Реакция админствующего Windows-сообщества, исповедующего религию всё по дефолту развернуть как в MS рассказывают и пусть работает, сидим да не паримся, а если что – так всё надо просто перенакатить с нуля, или ты самый умный что ли?, впрочем, благодаря околонулевому пониманию матчасти, тоже особо не отличалась:

Экспертное коммьюнити предлагает всё переустановить с нуля, а потом ещё раз переустановить с нуля
(кликните для увеличения до 400 px на 400 px)

Мимикац предлагает сдаться?

Посмотрим.

Что есть mimikatz

Несмотря на фонетичность названия, наводящую на мысль о вороватых представителях либеральной оппозиции и котиках (хотя у оных представителей отношения с мимимишными котиками сложные, мягко выражаясь), mimikatz к перечисленным никак не относится. Это модульный инструмент для доступа к ряду API Windows-систем, разработанный Benjamin Delpy. Актуальная версия mimikatz доступна на гитхабе, а начиналось всё давно, ещё в 2007 году – с утилит kdll / kdllpipe.

Мы будем рассматривать доступную на момент написания статьи версию 2.1.1 и ограничимся в проработке вопроса именно тем функционалом, который применяет вирус Petya.A(lco). То есть не будем писать учебник по применению mimikatz.

Техническая сторона тестирования

Проверяться всё будет на Windows Server 2008 R2 с оговорками про новый функционал более старших версий ОС. Ряд мер, безусловно, будет применим и на Windows Server 2003. Для демонстрации я подниму “нулЁвый, дефолтный” лес Active Directory с одним доменом, поэтому все настройки в плане политик безопасности точно будут “по умолчанию”. Используемый бинарник mimikatz – 64х битовый, билд 20170618, доступен для загрузки с нашей CDN.

Mimikatz – захват привилегии debug

Для выполнения части своих действий mimikatz проводит “захват” привилегии debug. Благодаря этому он может получать низкоуровневый доступ к процессам, запускаемым от системных учётных записей (LocalSystem, он же SYSTEM, в NT 5.1 расщепившийся на варианты LocalService / NetworkService).

В интерфейсе это действие выполняется командой privilege::debug, в случае успешного завершения выводится Privilege '20' OK, в случае неудачи – Remark: ERROR kuhl_m_privilege_simple ; RtlAdjustPrivilege (20) c0000061.

Mimikatz получает debug-привилегию
(кликните для увеличения до 676 px на 337 px)

Предотвращение возможности получения debug

По умолчанию что в локальной политике безопасности, что например в Default Domain Controllers Policy привилегия debug выдаётся группе BUILTIN\Administrators. Выдаётся – это значит, что процесс, запускаемый в сеансе пользователя, в маркере которого есть SID этой группы, может запросить “хочу отладку” и получить этот бит в строку “привилегии” своего маркера доступа (в случае наличия UAC – а в классическом варианте этот бит появляется в маркере сразу после процедуры logon).

Это абсолютно вредная настройка “по умолчанию”, т.к. фактически привилегия debug обычными приложениями не используется. Более того, даже разработчикам она нужна в исключительно редких случаях – потому что даже отладку приложений, запускаемых от своей учётной записи, на платформе Windows ведут без debug privilege. То есть разработку прикладных или managed code-приложений можно без проблем проводить и без данной привилегии. Она нужна – ещё раз – только в сценарии “конкретному пользователю нужна возможность отладки системных процессов”.

Более того – даже если она нужна программисту, именно для отладки системного сервиса, но на другом узле – есть вариант kernel Secure Mode debugging, при котором программист может проводить отладку, но на системе, с которой подключается, данную привилегию не получает.

Решаем ситуацию просто – в групповой политике (если домен) или локальной (если речь о standalone-системе) добавляем свежесозданную группу, членство в которой будет обозначать, что данной явно указанной учётной записи можно пользоваться такой привилегией. Ни на какую работу никакого ПО это не повлияет в принципе – нет штатного бизнес-ПО, которое не может делать свои задачи без попутной отладки ядра NT. Зато вот администраторов – что локальных, что доменных – которым права выданы по логике “а давайте гендира сделаем enterprise adminом, а то вдруг у него что-нибудь не заработает” – достаточно.

На скриншоте – локальная политика на DC, поэтому переопределять прямо в ней я не буду, все равно параметр будет перекрыт доменной политикой. Результат будет выглядеть так:

Ограничение debug-привилегии на локальном хосте через членство в явно указанной доменной группе
(кликните для увеличения до 1268 px на 633 px)

Теперь mimikatz получить debug-привилегию не может:

Защитили debug-привилегию от mimikatz и не только
(кликните для увеличения до 674 px на 336 px)

При этом мы остались и локальным администратором, и участником групп Domain Admins и Enterprise Admins. Мы можем выполнять все те же самые (любые) задачи с Active Directory.

Получение debug-привилегии mimikatz – это не взлом Windows, не несанкционированный доступ – это использование default-настройки времён 1999 года, т.е. стартового релиза Windows 2000. Возможность проведения таких действий – это проблема не ОС, а квалификации администраторов и инженеров. Скажите спасибо покупным сертификациям и дампам, авторизованным курсам с лабами “последовательно по бумажке команды вводишь и кликаешь где надо”, и “экспертному коммьюнити”, которое предлагает во всех случаях поставить последнюю винду и ждать, что всё самонастроится-самоналадится, “вот-вот, наверное, скоро, того и гляди, патч выпустят”.

Продолжим.

Часть 2