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

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

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

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

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

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

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

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

Посмотрим.

Что есть 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.

Предотвращение возможности получения 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, поэтому переопределять прямо в ней я не буду, все равно параметр будет перекрыт доменной политикой. Результат будет выглядеть так:

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

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

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

Продолжим.

Mimikatz – получаем доступ к различной аутентификационной информации

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

Этот список может включать в себя следующие пункты:

  • Plaintext – пароль в открытом виде.
  • WDigest – пароль после CHAP / MD5-преобразования.
  • LM-hash – хэш для старого LanManager.
  • NTLM-hash – хэш для NTLM и Kerberos.

Mimikatz выгружает хэши и учётные данные из работающего lsass командой lsadump::lsa /name:Administrator /inject:

Mimikatz выгружает хэшиMimikatz выгружает хэши
(кликните для увеличения до 673 px на 853 px)
Учебный центр Advanced Traininginfo@atraining.ru

Много выгрузил, да.

Начнём с возможности, которая есть на современных ОС, и которую проще всего сразу начать использовать на домашних и standalone-системах.

Защита LSASS от подключений со стороны сторонних модулей

Начиная с Windows 8.1 и Windows Server 2012 R2, появляется дополнительная возможность для защиты. Эта защита реализуется как специальный параметр для сервиса LSASS – если включаясь LSASS увидит этот параметр, то будет разрешать прямое взаимодействие с собой (например, чтение своей памяти) не просто процессам с нужным уровнем доступа (работающим от системной учётной записи), но и обязательно подписанным со стороны Microsoft. Не просто подписанным, а как у криптографических модулей – специальной подписью вендора.

Включается этот режим просто – в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa создаётся значение RunAsPPL типа DWORD32 и выставляется в единицу.

При успешной обработке в System-журнале от лица WinInit будет событие:

LSASS.exe was started as a protected process with level: 4

Работая в защищённом режиме LSASS не будет подгружать неподписанные плагины. Если у вас они и не используются, то это эффективно отключит принципиальную возможность даже получив права LocalSystem добраться до оперативной памяти процесса LSA. Но будьте внимательны, если у вас используются:

  • Самописные фильтры паролей – например, для задания особых критериев сложности и проверки “чтобы в паролях не встречались логины и имена”;
  • Криптомодули, нужные для обработки какой-то специфичной авторизации – например, Kerberos на гос.криптографии;
  • Сторонние драйверы смарт-карт, добавляющие какой-то специфичный функционал;

Всем им после включения этого режима надо быть или подписанными Microsoft, или они не будут загружаться, а в логах будут события 3033 и 3036.

Впрочем, чаще всего расширения LSA не используются, так что данная мера является нужной и эффективной. Но действовать она, ещё раз, будет только у 8.1+ и 2012 R2+.

Теперь поговорим про то, как избавиться от факта существования ненужных хэшей.

Сокращаем число хранящихся вариантов учётных данных

LM-хэш

Про то, как избавиться от старого LM-хэша, я написал в отдельной статье про LM и NTLM, поэтому повторяться не буду.

WDigest

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

В современных системах – Windows 8.1+ и Windows Server 2012 R2+ – это уже работает само по себе, а вот в предыдущих версиях надо предпринять определённые действия – добавить в ключ реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest значение UseLogonCredential типа DWORD32 и выставить его в нуль.

Если даже дайджест иногда и будет требоваться, то просто у пользователя будет чаще запрашиваться информация для логина – то есть данная настройка отключает именно кэширование в RAM, а не весь механизм digest. HTTP-ресурсы, которым нужен именно такой метод, продолжат быть доступны.

Если вы опасаетесь, что есть некая система, проводящая аутентификацию, последовательно согласовывая методы, и эта система может так “досогласоваться” до WDigest – то в том же ключе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest есть значение Negotiate, тоже DWORD32, которое можно явно выставить в нуль и тогда никакие вариации negotiate не будут при переборе методов использовать WDigest.

Обратимое шифрование

В Active Directory хранение CHAP-like данных (по сути – зашифрованных plaintext-паролей) реализуется через дополнительный атрибут у security principal’а. Можно в явном виде сказать, чтобы такое никогда не делалось – для этого есть настройка в групповой политике:

Выключаем reversible encryptionВыключаем reversible encryption
(кликните для увеличения до 805 px на 578 px)
Учебный центр Advanced Traininginfo@atraining.ru

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

Результат – сильно сокращённое “поголовье” неиспользуемых и уязвимых способов представления аутентификационной информации.

Автоочистка кэша только что ушедших учётных записей

Если security principal прекратил свой сеанс на системе, то его учётные данные живут ещё некоторое время. Это не ошибка – это надо для сценариев “запустил операцию и отключился”.

Время, на протяжении которого в оперативной памяти lsass живут учётные данные только что завершивших сеанс учётных записей, можно настраивать.

В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ есть параметр TokenLeakDetectDelaySecs, опять же типа DWORD32. Выставление его в малое значение (например, 10 секунд) отсечёт возможность атак класса “взломали файловый или RDP-сервер и забрали из процесса lsass все данные всех подключавшихся, а теперь можно в офлайне NTLM-хэши попробовать атаковать”.

Теперь про ошибочные предположения о mimikatz.

Mimikatz – Golden или Silver Ticket для Kerberos

Абонемент – это очень хорошо. Тут самое место для рекламы нашего абонемента на посещение онлайн-курсов и вебинаров, а также доступу к архиву всех записей – Knowledge Assurance – но вот нельзя сказать, что Knowledge Assurance предоставляет возможность добавления произвольных SID в TGT, плюс выставление огромного срока жизни у билетов.

Данному механизму подделки kerberos tickets – уже несколько лет, его детальное описание опубликовано в 2014 году.

Некоторыми “экспертами” ошибочно декларируется, что вирус Petya.A(lco) умеет “ломать домены Active Directory через дыру Golden Ticket”.

Это не так – и не дыра это, и не Active Directory, и вирус этого не делает, а mimikatz может попробовать.

Правда для этого нужно выполнение следующего списка условий:

  • Нужно знать пароль от RID 502, учётной записи krbtgt, доступной на каком-нибудь из не-RODC (потому что на RODC у каждого свой krbtgt).
  • Нужны права локального администратора на DC.
  • Должна отсутствовать преаутентификация Kerberos.

Как видите, не всё так однозначно – в частности то, зачем что-то ломать, если ты админ на контроллере домена.

Противодействие этой атаке также достаточно тривиально – дважды (именно дважды, чтобы произошла инвалидация тикетов) сделать reset password у доменного krbtgt, выставив оный на произвольный стойкий пароль, а также использовать FAST (который Kerberos Armoring, защищает фазу преаутентификации и ошибочно считается возможностью Windows Server 2012, хотя может использоваться и на Windows Server 2008). Ну и не давать права админа на DC кому попало, да.

Теперь немножко про панацеи.

Использование Protected Users

Один из показательных моментов во всей шумихе вокруг Petya.A(lco) – это быстрый поиск панацеи. Притом почему-то в расчёт не берутся действительно быстрые и простые методы – например, корректно раздавать права внутри домена и ставить критические патчи через разумное время после их выхода. Проще же ждать золотую пулю, которая решит все вопросы. На эту должность в данном случае “экспертные сообщества” спешно назначили методику “просто добавить всех пользователей в Protected Users и не париться”.

Про то, что именно делает группа Protected Users – фактически, включает целую пачку и ранее существовавших защитных технологий – есть в статье про LM и NTLM – у каждой из этих технологий есть свои плюсы и минусы, побочные действия и особенности, поэтому сам подход “разово нажать специальную кнопку Сделать Всё Хорошо” в данном случае показателен.

Ситуация в том, что суммарное время на разгребание последствий после подобных быстрых действий обычно превышает то, которое тратится на последовательное улучшение защиты домена. Безусловно понятно что те, кто не разбираются в технологиях, будут искать поверхностное решение “что там надо нажать, какой скрипт на повершелле скачать и запустить, чтобы всё норм стало” – и в этом им помогут такие же, но по факту будет затрачено больше времени и сил, а знания как отсутствовали, так и продолжат отсутствовать. Ведь от подобных методов ни понимания технологий, ни навыков – больше не становится. Отсюда и все рассказы вида “просто домен в 2012 R2 надо переключить и вопрос решён” и подобное.

Будьте умнее – изучайте технологии не поверхностно, а серьёзно. Это банально эффективнее с точки зрения затрат времени и результирующего личного комфорта.

Потому что в данном случае, например, при грамотной настройке политик (не-выдаче debug-привилегии всем админам) можно уже лет этак 18 подряд как не давать никакой возможности для описываемой атаки через mimikatz.

Удач!

Возможно, вам будет также интересно почитать эти статьи с нашей Knowledge Base

Ruslan V. Karmanov