Эффективное получение хеша паролей в Windows. Часть 5

Logon-сессии

В logon-сессиях Windows сохраняет информацию о любых успешных входах в систему. Информация включает в себя имя пользователя, имя рабочей группы или домена, а также LM/NT-хеши паролей.

Вне зависимости от того, как именно легитимный пользователь заходит в систему: интерактивно или удаленно через RDP – в любом случае, локальная подсистема безопасности (Local Security System - LSA) сохраняет учетные данные пользователей в памяти.

Ниже представлена модель входа и аутентификации в Windows NT:

Модель входа и аутентификации в Windows NT

Аналогичные данные сохраняются и для процессов, “запускаемых от имени…” (Run As) и служб, выполняющихся в контексте определенного пользователя. Пароли служб сохраняются в незашифрованном виде, и могут быть получены из секретов LSA.

Тем не менее, при аутентификации по сети (например, по протоколам SMB или HTTP) logon-сессии сохраняться не будут, поскольку NT/LM-хеши в действительности не передаются на сервер ¬– для аутентификации используется механизм типа “запрос-ответ”.

Система хранит в памяти конфиденциальную информацию пользователей для того, чтобы использовать технологию единого доступа (Single Sign-On (SSO)). Технология SSO широко применяется в сетях Windows, и в особенности внутри доменов. SSO позволяет пользователю единожды аутентифицироваться в системе и получить доступ к разделяемым ресурсам, (принтеры, HTTP-прокси и.т.п.) без необходимости повторного ввода своих учетных данных: Windows воспользуется хранимой в памяти информацией (имя пользователя, домен/рабочая группа, хеши паролей) и прозрачно для пользователя аутентифицирует его.

Механизм SSO функционирует благодаря тому, что сегодня практически все сервисы Windows (исключением является подключение по RDP) наряду с аутентификацией по паролю поддерживают аутентификацию по NT/LM-хешам.

Получение logon-сессий

Logon-сессии можно получить, при условии, что у вас есть доступ к командной строке с административными правами. Существует два метода получения logon-сессий: внедрение кода в процесс lsass.exe и чтение памяти LSASS.

Следующие утилиты помогают слить logon-сессии: msvctl от TrueCrypt идеально подходит для 32-битных Windows XP/2003. Последняя версия gsecdump сольет logon-сессии в независимости от версии и архитектуры Windows. Из недавних разработок TrueSec стоит также отметить lslsass: утилита была спроектирована специально для систем Windows Vista и выше. Lslsass безупречно работает как на 32-x, так и на 64-x разрядных системах.

Самые известные утилиты для управления logon-сессиями Windows – это Windows Credentials Editor (WCE) и ее предшественница Pass-the-Hash Toolkit (PTK). Обе утилиты представляют собой результат плодотворной работы основателя компании Amplia Security Хернана Очоа (Hernan Ochoa). По своим разработкам он сделал несколько презентаций, среди которых:

• “Pass-The-Hash Toolkit для Windows: реализация и использование”, представленная на конференции по безопасности Hack In The Box в Малазии в конце 2008 года. Презентация проливает свет на историю и механизмы работы пост-эксплойтов, и в частности на атаку передачи хеша (“Pass-The-Hash”) и реализацию атаки в утилите Pass-The-Hash Toolkit.
• “Принципы работы WCE”, представленная на конференции RootedCon в начале 2011 года в Мадриде. В презентации поясняются механизмы, которые лежат в основе работы WCE, а также то, как Windows хранит в памяти учетные данные пользователей в системах до и после Windows Vista.
• “Реализация пост-эксплойтов с помощью WCE” – презентация представлена в июле 2011 года. Если вы впервые слышите о logon-сессиях и атаке передачи хеша, то я рекомендую вам начать свое знакомство с ними именно с этой простой и понятной презентации с примерами. Также можете почитать FAQ-страничку WCE.

Из двух утилит я по ряду причин предпочитаю WCE: во-первых, WCE – это самостоятельный EXE-файл; во-вторых, WCE безопаснее, поскольку не приводит к падению процесса LSASS при чтении памяти; и в-третьих, утилита работает на всех версиях и архитектурах Windows.

Специально для целей статьи я установил Windows Server 2003 Service Pack 2 со всеми обновлениями (NetBIOS-имя w2k3r2), и произвел следующие действия:

• Локальный пользователь Administrator интерактивно зашел на консоль. Длина пароля пользователя Administrator – 15 символов.
• Два локальных пользователя inquis и foobar подключились к системе по RDP. Первый пользователь подключился через mstsc, а второй через rdesktop. 
• Запущено несколько сервисов СУБД IBM DB2 в контексте локального администратора db2admin.

Утилита lslsass была намеренно исключена из эксперимента, так как она работает только на системах Windows Vista и выше.

Все тестируемые утилиты удачно слили logon-сессии. Ниже показан результат работы Windows Credential Editor:

C:\>wce.exe –l

WCE v1.2 (Windows Credentials Editor) - (c) 2010,2011 Amplia Security - by
Hernan Ochoa (hernan@ampliasecurity.com)
Use -h for help.
Administrator:W2K3R2:00000000000000000000000000000000:237599E85CF684A67
85A12ACD2E24E5C
inquis:W2K3R2:0AC9A586623764E16591BB5472A3AD4A:89F411F435A93044E2E8AA4CEDF
E0FBA
foobar:W2K3R2:87DCEB9223BE0E08FD8E74C8CEB3053A:33D807D89B36ACDF2FAB42A361D
E0B91
db2admin:W2K3R2:3AE6CCCE2A2A253F93E28745B8BF4BA6:35CCBA9168B1D5CA6093B4B7D
56C619B
W2K3R2$:WORKGROUP:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D
7E0C089C0

Мы получили имя пользователя, имя домена/рабочей группы и LM/NT-хеши. Результаты тестируемых утилит и утилит для получения хеша из SAM очень похожи, за исключением того, что тестируемые утилиты могут отобразить учетные данные не только локальных, но и доменных пользователей тоже.

Следующий скриншот также подтверждает удачность атаки:

Получение logon-сессий с помощью Windows Credential Editor (WCE) на Windows Server 2003 R2

(Administrator имеет доступ к консоли, два пользователя подключены удаленно по RDP и один процесс выполняется в контексте локального пользователя)

Во время проведения эксперимента я понял, что независимо от того, как именно завершаются сессии, logon-сессии все равно остаются в памяти. Например, неважно как вы закроете RDP-соединение: нажмёте X в левом верхнем углу RDP-клиента или выйдете из системы через меню “ПУСК” – logon-сессия все равно останется в памяти. Подобные вещи происходят и в Windows Server 2008 R2 Enterprise Service Pack 1. В системах Windows Vista и выше logon-сессии стираются из памяти спустя пару минут после выхода пользователя из системы.

Вышеописанное поведение продемонстрировано на следующем скриншоте:

Получение logon-сессии после отключения от RDP пользователя foobar: его logon-сессия осталась в памяти

Получение logon-сессии после принудительного отключения от RDP пользователя foobar: его logon-сессия осталась в памяти

Logon-сессия db2admin также осталась в памяти, несмотря на то, что соответствующий сервис был остановлен.

Какие угрозы влечет за собой получение logon-сессии

Ситуация сейчас такая же, как и при получении секретов LSA и информации из кэшированных входов в домен: вы получили права Local System на системе, входящей в один или несколько доменов, и вы хотите взять под контроль весь домен (домены). Никакой информации об учетных данных доменных пользователей из секретов LSA и из кэша вам узнать не удалось.

Тогда попробуйте слить logon-сессии. Если вам удастся получить logon-сессию доменного администратора, то вы победили: осталось только использовать полученную logon-сессию, чтобы выдать себя за администратора и получить доступ к командной строке. Такая атака также известна, как “pass-the-hash” (“передача хеша”) или кража logon-сессии.

В командной строке наберите следующее:

C:\>wce.exe -s ::: -c cmd.exe

В новом открывшемся окне командной строки подключитесь по SMB (например, с помощью утилиты PsExec компании Sysinternals) к корневому контроллеру домена. Система, скорее всего, успешно аутентифицирует вас как администратора домена, потому что, по сути, вы предоставили учетные данные именно этого пользователя.

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

Помимо WCE есть и другие утилиты, способные провести атаку передачи хеша: например, msvctl и RunhAsh от TrueSec. Все новые утилиты я добавил в таблицу. Буду рад вашим отзывам и предложениям!