Всем привет. Сегодня рассмотрим вариант запуска mimikatz на Windows 10. Mimikatz — инструмент, реализующий функционал Windows Credentials Editor и позволяющий извлечь аутентификационные данные залогинившегося в системе пользователя в открытом виде.
В ходе пентеста полезно иметь штуку, которая сдампит пароли юзеров, но сейчас даже встроенный в винду стандартный Windows Defender становится проблемой и может помешать нашим грандиозным планам.
Замечу, что этот способ подходит и для других антивирусных продуктов (Virustotal ДО и ПОСЛЕ тоже так считает), которые проводят статичный анализ бинарников по сигнатурам.
Так что хоть и данный способ вряд ли поможет вам против EDR решений, но легко поможет обойти Windows Defender.
Раньше его можно было обойти изменением слов в файле с mimikatz на mimidogz, удалением пары строк в метаданных и баннеров. Сейчас же это стало сложнее, но все же возможно.
За идею всего этого действа выражаю благодарность человеку с ником ippsec.
В данной статье мы будем использовать:
- Windows 10 с включенным Windows Defender (с обновленными базами)
- Mimikatz
- Visual Studio
- HxD (hex редактор)
Копируя mimikatz на компьютер жертвы, мы ожидаемо видим такой алерт.
Далее мы проведем серию манипуляций, чтобы Defender перестал видеть тут угрозу.
Первым делом, найдем и заменим слова mimikatz. Заменим mimikatz например на thunt (заменить можно на что угодно), а MIMIKATZ на THUNT. Выглядит это примерно вот так.
Следом отредактируем в Visual Studio файл mimikatz\mimikatz\mimikatz.rc (который после нашей замены теперь thunt.rc), заменяя mimikatz и gentilkiwi на что угодно, также не забудем заменить mimikatz.ico на любую другую иконку. Жмем «пересобрать решение» (или rebuild solution) и получаем нашу обновленную версию mimikatz. Скопируем на компьютер жертвы, иии…алерт. Давайте узнаем, на что срабатывает Defender. Самый простой способ это копировать бинарник с разным размером до первого срабатывания антивируса.
Для начала скопируем половину и скопируем на машину с Windows 10.
head –c 600000 mimikatz.exe > hunt.exe
Defender молчит, уже неплохо. Экспериментируя, найдем первое срабатывание. У меня это выглядело так:
head -c 900000 mimikatz.exe > hunt.exe – не сработал
head -c 950000 mimikatz.exe > hunt.exe – сработал
head -c 920000 mimikatz.exe > hunt.exe – не сработал
head -c 930000 mimikatz.exe > hunt.exe – не сработал
head -c 940000 mimikatz.exe > hunt.exe – сработал
head -c 935000 mimikatz.exe > hunt.exe – не сработал
head -c 937000 mimikatz.exe > hunt.exe – сработал
head -c 936000 mimikatz.exe > hunt.exe – не сработал
head -c 936500 mimikatz.exe > hunt.exe – сработал
head -c 936400 mimikatz.exe > hunt.exe – сработал
head -c 936300 mimikatz.exe > hunt.exe – сработал
head -c 936200 mimikatz.exe > hunt.exe – не сработал
Откроем hunt.exe в hex редакторе и смотрим, на что может сработать Defender. Глаз уцепился за строку KiwiAndRegistryTools.
Поиграемся со случайным капсом — стало KiWIAnDReGiSTrYToOlS, сохраним и скопируем. Тишина, а это значит, что мы угадали. Теперь найдем все вхождения этих строк в коде, заменим и пересоберем наш проект. Для проверки выполним head -c 936300 mimikatz.exe > hunt.exe. В прошлый раз Defender сработал, сейчас нет. Движемся дальше.
Таким не хитрым способом, добавляя все больше строк в наш hunt.exe, были обнаружены слова-триггеры — wdigest.dll, isBase64InterceptOutput, isBase64InterceptInput, multirdp, logonPasswords, credman. Меняя их случайным капсом, я добивался того, что Defender перестал на них ругаться.
Но не может же быть все так легко, подумал Defender и сработал на функции, которые импортируются и чувствительны к регистру. Это функции, которые вызываются из библиотеки netapi32.dll.
- I_NetServerAuthenticate2
- I_NetServerReqChallenge
- I_NetServerTrustPasswordsGet
Если мы взглянем на netapi32.dll (C:\windows\system32\netapi32.dll), то мы увидим, что каждой функции присвоен номер.
Изменим вызов функции с вида
windows.netapi32.I_NetServerTrustPasswordsGet(args)
на
windows.netapi32[62](args)
Для этого нам надо заменить mimikatz\lib\x64\netapi32.min.lib. Создадим файл netapi32.def и запишем туда следующие строки:
LIBRARY netapi32.dll
EXPORTS
I_NetServerAuthenticate2 @ 59
I_NetServerReqChallenge @ 65
I_NetServerTrustPasswordsGet @ 62
Сохраняем и выполним команду (не забудьте на всякий случай сделать бэкап оригинала netapi32.min.lib)
lib /DEF:netapi32.def /OUT:netapi32.min.lib
В очередной раз пересоберем проект и скопируем то, что у нас получилось. Defender молчит. Запустим получившейся mimikatz с правами администратора.
Успех. Таким образом mimikatz запущен и Windows Defender не сработал, чего мы и добивались. Пароли, явки и хеши выданы.
Подводные камни
Ожидание:
* Username : thunt
* Domain : DESKTOP-JJRBJJA
* Password : Xp3#2!^&qrizc
Реальность:
* Username : thunt
* Domain : DESKTOP-JJRBJJA
* Password : (null)
Ситуация в жизни несколько отличается от лабораторных условий. Возможно, для просмотра пароля вам придется поработать с реестром. Например, включить или создать ключ UseLogonCredential (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest). Но и с этим могут возникнуть проблемы, т.к. при перезагрузке ключи могут выставляться обратно.
Может быть и ещё хуже, если в случае запуска на одной из последних версии Windows 10, вместо пароля в plain-text вы увидите вот такое:
* Password : _TBAL_{68EDDCF5-0AEB-4C28-A770-AF5302ECA3C9}
Все дело в механизме TBAL, который является наследником Automatic Restart Sign-On (ARSO). Теперь, когда запрашивается TBAL, lsasrv проверяет является ли аккаунт локальным или MS аккаунтом, и исходя из этого, использует msv1_0 или cloudAP, чтобы сохранить все необходимое для возобновления сессии пользователя. После чего механизму autologon выставляется захардкоженный пароль _TBAL_{68EDDCF5-0AEB-4C28-A770-AF5302ECA3C9}.
Тем не менее в лабораторных условиях мы получили пароль пользователя, а в боевой обстановке как минимум можем получить хеши.