Для большинства внутренних сетей самых разных компаний компрометация домена по причине злоупотребления привилегированными доменными учетными записями, пожалуй, самая распространенная. Иными словами, висящие налево и направо сессии доменного админа сильно упрощают работу потенциального нарушителя. Ведь как только один такой сервер или рабочая станция будет скомпрометирован до компрометации домена, а значит и всей внутренней инфраструктуры, останется лишь шаг. И именно об этом последнем шаге мы и поговорим.
Думаю, большинство, увидев администратора домена в списке сессий очередного скомпрометированного хоста поспешит расчехлить mimikatz и будет несомненно право. Но мы рассмотрим уже достаточно частые ситуации, когда lsass.exe защищен антивирусом либо же и вовсе перед нами lsaIso.exe с аппаратной изоляцией адресного пространства. Автор mimikatz почти сразу предложил известное решение. Но оно потребует перелогон админа, а значит это не совсем 0-click метод, зависящий от удачного стечения обстоятельств.
На самом деле нам не так уж и нужен пароль администратора домена, и в каждом из перечисленных ниже способов мы захватим контроллер домена без пароля.
Мы, атакующий – это зеленая сессия, наша цель, администратор домена – красная сессия. В этом примере мы лишь локальный администратор, чьи привилегии ограничены только данной системой, а администратор домена имеет такие же привилегии, но почти на каждом ПК. Однако в пределах данного ПК наши права будут равны, а значит мы можем сделать многое в отношении данной учетной записи. Все что будет происходить в пределах данного ПК лишь горизонтальная эскалация привилегий (админ -> админ), но в масштабах домена - вертикальная (локальный админ -> доменный админ).
Tokens
Самый популярный способ поиметь смежную сессию — это манипуляция токенами. Токены могут быть использованы для смены текущего пользователя. Сменить контекст безопасности вполне легитимная для ОС Windows функция и она не потребует ввода пароля. Всё что нам потребуется это привилегия SeImpersonatePrivilege, которая считай уже у нас в кармане, т.к. мы локальный администратор. Далее мы используем базовый функционал системы (WinAPI), так что такой трюк можно считать полностью легитимным. Запустить любой процесс от имени учетной записи из другой сессии можно, например, такими функциями:
Весь необходимый нам функционал уже реализован в хорошо известном инструменте incognito.exe и одноименном расширении для meterpreter.
И так, в списке доступных токенов видим нашу цель:
Создаем произвольный процесс, изменив пользовательский контекст по токену:
Сессия смежного пользователя – администратора домена успешно получена. И, что вполне ожидаемо, доступ к контроллеру так же получен.
Shellcodes
Способ с токенами несомненно красивый и действенный. Но на мой взгляд не на 100% очевидный для понимания. Какая-то магия с WinAPI и вы получаете возможность выполнять код от имени другого пользователя. Куда более наглядным примером легкодоступности смежных пользовательских сессий может быть их взаимный доступ к памяти друг друга, предоставляемый опять-таки посредством стандартных WinAPI. С помощью всего 4 функций мы можем внедрять произвольный код в другие контексты:
Данный функционал вновь уже реализован, как минимум в meterpreter, когда вы делаете migrate. Так же инъекции кода возможны с помощью powershell.
Теперь о том, какой код нам внедрять. Мы внедрим в процесс доменного админа вызов древней встроенной команды Windows, умеющий удаленно запускать код. А в качестве самого кода, активируем бэкдор в winlogon:
Пора внедрить наш код в админский контекст, используя для этого, например, его процесс explorer.exe:
И внезапно на контроллере домена мы видим вот это:
Данный пример, по-моему, идеально описывает абсурдность развития защитных мер.
Сперва мы извлекали креды из памяти lsass.exe. Антивирусы стали бороться с этим, мы научились дампить память lsass.exe и извлекать пароли уже из дампа. Тогда Microsoft убрал вообще lsass.exe, заменив его lsaIso.exe так чтоб ни каких mimikatz. В ответ на это мы получаем сессию без всяческого пароля. И что забавно, сделать так мы могли с самого начала.
Мы вновь скомпрометировали контроллер домена без использования какого бы то ни было пароля. Дальше последует извлечение krbtgt и возможность стать любым пользователем, и опять же без использования пароля.
Debug
Еще нагляднее метода с впрыском шеллкода в смежный процесс я бы назвал ручное внедрение кода в него. Сделать это можно, например, с помощью отладчика, который предоставляет нам возможность писать что угодно в память процесса и приостанавливать/возобновлять исполнение. Этот метод хорош тем, что при желании реализовать его можно исключительно средствами Microsoft. Что ещё лучше, всё можно сделать даже прямо из командной строки:
В качестве примера более наглядно это можно показать с помощью графического x96dbg:
Мы просто открыли память процесса доменного админа и внедрили туда вызов netcat, который и дал нам админский шелл.
Однажды данный способ сильно выручил, когда буйный антивирус удалял весь левый софт.
Execution hijack
Все три описанных выше способа объединяет то, что они используют низкий уровень разграничения привилегий между сессиями. Но может встретиться ситуация, когда ни токены, ни внедрения кода в запущенные процессы другого пользователя не сработают. В таком случае у нас есть ещё один козырь.
Даже если системой нам запрещено напрямую вмешиваться в работу процессов других пользователей, то реестр нам, как локальным администраторам, изменять не запрещено. Так, с помощью реестра мы можем задействовать встроенный механизм ОС Windows по перехвату запуска программ:
И это вновь позволит нам вмешаться в смежную пользовательскую сессию.
Тут нам правда потребуется угадать какое ПО будет запущено нашей целью – администратором домена. Но в большинстве случаев это может оказаться «chrome.exe», «mmc.exe» или что-то в этом роде.
В качестве полезной нагрузки используем, например, bat-файл. Теперь все что мы включим в него будет выполнено в контексте нужного нам пользователя, как только он запустит соответствующую программу:
В данном примере для наглядности мы использовали netcat, предоставившего нам интерактивную сессию. Альтернативой может быть просто пара команд на добавления той или иной учетной записи в администраторы домена и последующая его компрометация.
Уверен представленные способы не единственные. Но даже их достаточно для наглядности того, что если злоумышленник добрался до привилегированной сессии, то обратный отсчет уже пошел. А распространенные организационные недочеты в виде повторного использования паролей и крайне доверительное отношение рабочих станций друг к другу в инфраструктуре Active Directory практически даже не потребуют наличия серьезных уязвимостей в ПО, для достижения этих самых хостов. Наконец возможность выполнить весь необходимый минимум pivoting от любой, даже непривилегированной учетной записи, делает вполне реальным полную цепочку компрометации всей внутренней инфраструктуры даже внешнему нарушителю, пробившему сетевой периметр компании.