В работе любой ИТ-службы рано или поздно возникает необходимость передачи ИТ-объектов. Это может быть, как передача между подразделениями самой ИТ-службы, так и передача внешним подрядчикам на аутсорсинг. И в этот момент приходит понимание того, насколько в актуальном и полном объеме велась документация по этому самому объекту.
Далее речь пойдет о Windows Server. Первое, что мы проверяем, это доступы к этому самому объекту, то есть актуальность учетных данных в документации. Заходим под учетной записью администратора, смотрим какие есть еще учетные записи и для чего. Проверяем для них актуальность пар логин/пароль. Для обычных учетных записей достаточно запустить от их имени какое-нибудь приложение.
Рисунок 1 — Окно запуска приложения от имени пользователя
Далее в Диспетчере задач, во вкладке «Подробности» убеждаемся, что приложение запустилось под проверяемой нами учетной записью.
Рисунок 2 — Окно диспетчера задач
А что же делать в случае учетных записей вроде USR1CV8, которым разрешен вход в качестве службы или пакетного задания, и, по соображениям безопасности, запрещен локальный/сетевой вход в качестве пользователя? Если попытаться запустить от этой учетной записи приложение, то, ожидаемо, запуск будет заблокирован.
Рисунок 3 — Ошибка при попытке запустить приложение под служебным пользователем
А останавливать/запускать службы на рабочем сервере для этой задачи совершенно неприемлемо. Решение есть.
LSASS, хеши и mimikatz
В семействе операционных систем Windows есть служба Local Security Authority Subsystem Service (LSASS), которая отвечает за управление разными подсистемами аутентификации. В задачи службы входит проверка учетных данных локальных и доменных пользователей при различных сценариях запросов доступов к системе, генерация для активных сессий пользователей их ключей безопасности, работа с Security Support Provider (SSP) и прочее.
Чтобы пользователю не приходилось «каждые пять минут» вводить свой логин/пароль, процесс lsass.exe этой службы хранит в своей оперативной памяти NTLM-хеши паролей пользователей, которые уже прошли аутентификацию в системе. Таким образом, хеш пароля пользователя USR1CV8 попадает в память процесса lsass.exe при старте службы агента сервера 1С. Нам остается только прочитать хеш пароля и сравнить с хешем пароля, указанного в документации, без остановки службы агента сервера 1С.
В этом нам поможет утилита mimikatz. Mimikatz – это приложение с открытым исходным кодом, написанное в 2011 году французским программистом Бенджамином Делпи для демонстрации уязвимости протоколов аутентификации Windows. Работа над утилитой продолжается и по сей день, поэтому она работоспособна на современных версиях операционных систем.
Скачиваем последнюю актуальную версию утилиты mimikatz по ссылке: https://github.com/gentilkiwi/mimikatz/releases
Распаковываем, запускаем с правами локального администратора, проверяем наличие привилегий для доступа к памяти процесса lsass.exe командой privilege::debug.
Рисунок 4 — Результат проверки привилегий
Привилегий достаточно – извлекаем данные из процесса командой sekurlsa::logonPasswords full, в выгруженных данных ищем информацию по учетной записи USR1CV8: [Ctrl]+[F] – Что найти: usr1cv8 – «Найти далее».
Рисунок 5 — Окно поиска пользователя 1С
Находим учетную запись и NTLM-хеш ее актуального пароля:
Рисунок 6 — Отображение пользователя 1С и его NTLM-хеш пароля
Запускаем любой хеш-генератор, который умеет генерировать NTLM-хеш из текста, вставляем в него пароль учетной записи USR1CV8 из документации объекта, генерируем хеш пароля из документации. В интернете можно найти множество онлайн генераторов. Если не доверяете онлайн сервисам, можно загрузить генератор себе на компьютер.
Рисунок 7 — Генерирование хеша на основе пароля из документации
Сверяем хеш текущего пароля с хешем пароля из документации. Если хеши идентичны, то пароль в документации актуален.
Рисунок 8 — Сравнение хешей пароля
