проблема 0x00
Продолжая вышеизложенное, после отслеживания и изучения собственных вызовов компонента запланированной задачи мы умело объединили COM, UAC и ITaskService, чтобы успешно найти новый обход UAC или поговорить о новой поверхности атаки.
Теперь давайте продолжим расширять наше мышление. Оглядываясь на первую статью, мы подтвердили в начале исследования, что суть программы запланированных задач — это интерфейс RPC, использующий XML в качестве носителя данных. По словам Microsoft, RPC используется для «вызовов между процессами, независимо от того, находятся ли процессы на одном хосте».
Таким образом, запланированные задачи, основанные на протоколе RPC, по своей сути пригодны для горизонтального перемещения.
Конечно, это не новая технология, мы, как те, кто не умер внезапно в начале августа, еще раз поигрались с `atexec`, `schtasks` и даже более старым `at.exe`. Все эти методы без исключения используют интерфейс RPC компонента запланированной задачи для бокового перемещения. Среди известных методов использования мы можем завершить эхо, выполняя команды удаленно, записывая файлы и, наконец, читая общий каталог; или напрямую выходить в Интернет с помощью многих безфайловых средств.
В реальном бою они в той или иной степени столкнутся с некоторыми проблемами. Например, методы файлового эха могут столкнуться со многими нетрадиционными средами, такими как недоступные общие ресурсы и несовместимые протоколы SMB. Помимо ограничений окружающей среды, в конфронтационных средах они часто сталкиваются с «известными» угрозами: известной угрозой. Известные методы или методы атаки должны иметь соответствующие обнаружение.
Это далее приводит к очень практической проблеме:
Будь то инструменты, оружие или платформы, независимо от того, насколько идеально они работают в теоретической среде, их может быть не так легко использовать в практических условиях.
Исследование новых методов всегда является первой темой противостояния. Теперь, исходя из потребностей реальной боевой обстановки , мы нашли для себя новую тему: как добиться более стабильного горизонтального смещения эхо-сигнала/обнаружения окружения?
0x01 Мышление
Исследования безопасности никогда не направлены на решение проблем вслепую. Здесь наша конечная цель — изучить относительно лучшую технологию бокового движения (при определенных обстоятельствах).Технические проблемы часто можно легко разложить на несколько последовательных шагов, поэтому мы можем продолжать их совершенствовать:
Каковы этапы латерального движения? Какие технологии задействованы на каждом этапе? Каковы плюсы и минусы каждой технической детали?
Размышление в этом направлении позволит выявить следующие технические детали:
Боковое движение требует подключения к цели, которое проявляется в виде протокола на сетевом уровне, поэтому первая подзадача:
Какой протокол используется?
Протокол несет сервисы, а неуязвимое боковое перемещение по сути является злоупотреблением сервисными функциями, поэтому вторую подзадачу можно декомпозировать:
Какие функции, предоставляемые самой службой, мы можем использовать для получения разрешений на выполнение?
После успешного получения разрешений на выполнение в реальных боевых условиях часто требуется обратная связь по результатам.Мы получаем третий подвопрос:
Может ли сама служба возвращать результаты напрямую? Если его не поддержат, какие дополнительные меры необходимы?
Наконец, существует непреходящая старая проблема в реальной боевой обстановке:
Есть ли какие-либо известные особенности приведенной выше реализации?
Объединение вышеперечисленных этапов — это полный процесс, который мы ожидаем выполнить. Эту идею можно сравнить с «цепочкой десериализации/ROP». Мы рассматриваем весь шаг как «цепочку», любая реализация на каждом этапе рассматривается как независимый и подключаемый «гаджет», а точка конфронтации рассматривается как «черный список». в сочетании с известными знаниями легко получить такую простую и несовершенную таблицу:
Послушайте, разведка угроз и исследования в области безопасности взаимосвязаны, а Интернет и конфронтация также связаны.
Учитывая, что мы рассматриваем плановые задачи, возникает вопрос: могут ли плановые задачи это сделать?
Опираясь на результаты исследований двух наших предыдущих статей, нетрудно ответить на этот вопрос:
1.`MS-TSCH` основан на `RPC`, не может быть закрыт и доступ разрешен в большинстве случаев.
2.`ExecAction` обеспечивает неограниченное выполнение команд. После записи файлов и реестра `ComHandlerAction` обеспечивает неограниченное выполнение кода.
3. Протокол использует кодировку UTF-16 для передачи «полного» определения XML клиенту «как есть». Элемент `Description` может размещать любое `строковое` содержимое без ограничений.
4. Уровень трафика может перехватывать пакеты подтверждения только через UUID, а прямая тревога/блокировка может повлиять на управление сервером; все цепочки процессов на уровне хоста занесены в белый список; ExecAction не поддерживает перенаправление вывода, поэтому сообщение «нет файла» ` требуется метод; для `ComHandlerAction` требуются безфайловые средства или другие средства `записи в файлы` и `реестр`.
Таким образом, в нашу таблицу можно добавить следующие два элемента рядом:
Учитывая сложность, бесфайловый ExecAction явно лучше, чем ComHandlerAction, который требует большой реализации.
Поэтому наша проблема естественным образом трансформируется из «латерального движения» в «меры противодействия бесфайловым атакам».
Использование этой технологии, которая существует уже не менее десяти лет, очень зрело, а методы преобразования очень разнообразны, а это означает, что у нас есть много гладких методов внедрения. В текущем сценарии нам необходимо использовать бесфайловые атаки для выполнения команд или обнаружения информации, а затем в качестве возврата изменить информацию о запланированном задании.
По-видимому, это могут сделать различные бесфайловые атаки на основе сценариев, такие как mshta, различные формы sct и xslt, cmd и PowerShell.
Во-первых, исключите `cmd`; во-вторых, учтите, что первые несколько технологий, основанных на хостинге сценариев Windows («Хостинг сценариев Windows»), должны инициировать запросы http или smb к внешнему миру, и приземление файла может легко вызвать некоторые ненужные проблемы. Поэтому PowerShell, реализующий полные функции сценариев через командную строку, стал первым выбором.
реализация 0x02
Как только технические моменты будут подтверждены, реализовать это не составит труда.
Прежде всего, мы обращаемся к содержанию первых двух глав. Независимо от того, копируем ли мы пример `MSDN`, сами компилируем `IDL`, используем `C# Interop` и т. д., мы можем напрямую подключиться к удаленной цели. Все, что мы нужно указать при использовании RPC Correct `Binding` и вызвать `RpcBindingSetAuthInfoEx`:
С++
_SEC_WINNT_AUTH_IDENTITY identity = { 0 };
LPWSTR domain = L"ROOT";
LPWSTR username = L"administrator";
LPWSTR password = L"P@ssw0rd";
identity.Domain = (unsigned short*)domain;
identity.DomainLength = lstrlenW(domain);
identity.Flags = SEC_WINNT_AUTH_IDENTITY_UNICODE;
identity.User = (unsigned short*)username;
identity.UserLength = lstrlenW(username);
identity.Password = (unsigned short*)password;
identity.PasswordLength = lstrlenW(password);
RpcBindingSetAuthInfoExW(hBinding, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_AUTHN_WINNT, &identity, 0, (RPC_SECURITY_QOS*)&qos);
Или укажите учетные данные при вызове `ITaskService::Connect`:
С++
pService->Connect(_variant_t(L"Target"), _variant_t(L"administrator"),_variant_t(L"ROOT"), _variant_t("P@ssw0rd"));
(Осознали ли вы преимущества «абстракции» и «прозрачности»?)
Во-вторых, PowerShell предоставляет полную объектную модель для запланированных задач и предоставляет для операций ряд командлетов, таких как Get-ScheduledTask и Set-ScheduledTask. Нам даже не нужно обращаться к msdn, мы можем написать такой сценарий, просто основываясь на справочной документации локального командлета:
PowerShell
$task=Get-ScheduledTask -TaskName TestTask -TaskPath \;
$task.Description=(iex $task.Description|out-string);
Set-ScheduledTask $task;
В этом сценарии мы получаем объект удаленного управления через Get-ScheduledTask и выполняем команду, сохраненную в описании, через iex. Учитывая, что все возвращаемые данные из PowerShell являются объектами, мы используем out-string для результата. преобразуется в читаемую строку и, наконец, сохраняется.
Один из ключевых моментов гаджет-мышления заключается в том, что если гаджет правильный и логика подключения гаджетов правильная, то и конечный результат должен быть правильным. Итак, нам просто нужно создать запланированную задачу, установить содержимое элемента `/Task/RegistrationInfo/Description` XML` для команды, которая будет выполнена, установить имя `TestTask` и указать командную строку. к приведенной выше команде PowerShell, запустите это запланированное задание, и результатом команды станет «Описание».
Наконец, просто прочитайте содержимое XML и сопоставьте его с содержимым «Описание».
С#
var xd=new XmlDocument();
xd.LoadXml(task.Xml);
Console.WriteLine(xd.SelectSingleNode("/*[local-name()='Task']/*[local-name()='RegistrationInfo']/*[local-name()='Description']").InnerText);
0x03 Полировка
Благодаря описанному выше процессу от обдумывания до реализации у нас есть исполняемый и эффективный технический прототип, который мы затем доработаем, чтобы приблизить его к статусу реального «оружия».
Во-первых, мы используем ExecAction для создания запланированной задачи, а это означает, что нам нужно использовать командную строку для передачи параметров, поэтому лучше всего использовать -EncodedCommand. На самом деле это не имеет ничего общего с `opsec`, основная цель - решить ряд проблем, которые могут вызвать экранирование.
На уровне сопоставления мы знаем, что логика обработки параметров PowerShell заключается в выполнении сопоставления без учета регистра на основе префикса, поэтому на самом деле, в дополнение к общим `-e` и `-enc`, `-EncodedCommand` также имеет что-то вроде следующих Десятки тысяч способов записи:
Баш
-eN
-eNCo
-Encode
....
Запланированное задание выполняется в фоновом режиме, поэтому лучше всего добавить -NonInteractive. Аналогично, этот параметр также имеет десятки тысяч способов записи:
Баш
-nonInt
-nOnInTe
....
В принципе, этого достаточно, чтобы справиться с некоторыми традиционными методами защиты без лексического анализа.
Далее, поскольку мы движемся вбок, мы не можем определить время выполнения команды в целевой среде, поэтому нужно добавить опрос.
Условие завершения опроса не должно "умно" напрямую определять, было ли изменено описание. На самом деле это не бесполезно, но эквивалентно бесконечному циклу в случае "ошибки сценария".
Объект IRegisteredTask предоставляет свойство State, которое представляет текущий статус задачи. После завершения задачи оно изменится с «Выполняется» на «Готово», поэтому вам нужно всего лишь опросить, чтобы прочитать статус задачи.
С#
while (task.State != TaskState.Ready)
{
task = folder.GetTask(taskname);
Thread.Sleep(1000);
}
Кроме того, есть несколько дополнительных методов `opsec`, которые являются вишенкой на торте, потому что в команде нет общих (я специально имею в виду `выполнение загрузки`, которое многими правилами рассматривается как единственное злоупотребление Powershell`) сильных функций. контента, поэтому с ним почти нет необходимости иметь дело.
Аналогично ни одно антивирусное ПО не будет сканировать атрибут «Описание» плана задачи (будь то «Объект», «Память» или «Xml»), поэтому достаточно не обрабатывать его по умолчанию.
Конечно, это все последующие действия. Когда этот метод уловит некоторые «сильные особенности», тогда мы займемся iex и закодируем возврат и команду, что станет новой точкой противостояния, ожидающей, чтобы ее добыли.
Наконец, не забывайте, что «iex» на самом деле выполняет сценарий PowerShell, так что это «удаленный PowerShell» (вспомним «WinRM»), что означает, что мы можем не только выполнять «программы командной строки»:
Вы также можете выполнить произвольные «командлеты»:
Еще более сложные `скрипты`:
Это означает, что все, что может делать .Net, мы можем выполнять «удаленно», «без файлов» и «необнаружимо». При дальнейших модификациях мы можем даже создать по-настоящему интерактивный удаленный PowerShell на базе MS-TSCH.
(Почему там написано, что может быть ошибка скрипта? Вот она)
0x04 Отражение
На этом контент, связанный с запланированными задачами, в основном закончен. Далее мы выходим за рамки запланированных задач и рассматриваем имеющиеся у нас решения с точки зрения сценариев применения. С одной стороны, сделайте простое резюме, с другой – подумайте, как его разумно использовать.
В сценарии бокового движения, помимо уязвимостей и запланированных задач, наиболее классическими и полезными технологиями являются PsExec и WMI.
Почему PsExec выдерживает испытание временем? В дополнение к opsec, введенному сигнатурой Microsoft, существует также протокол SMB, который должен быть включен по умолчанию в доменной среде, который реализует характеристики сочетания горизонтального сдвига и эха одного протокола, поэтому в течение длительного времени Используется в качестве первого выбора для проникновения во внутреннюю сеть. Даже сейчас самомодифицированная версия PsExec, основанная на Impacket или API, все еще может сыграть хорошую роль.
Почему позже оно было изменено на WmiExec? Поскольку служба WMI также включена по умолчанию, и практически нет возможности ее выключения, цель повторения того же протокола все равно может быть достигнута с помощью stdregprov, что делает его первым выбором для обхода на основе DCOM. протокол.
Теперь у нас есть дополнительная технологическая опция «Taskexec на основе RPC».
Да, это всего лишь техническое дополнение, а не замена.
Почему?
Потому что каждая технология атаки должна иметь различную область применения/требования к среде, а также должны иметь различные сильные характеристики.
Все методы «необнаружимого» обхода («обхода»)/эскейпа («уклонение») претендуют на необнаружимость, но они просто не улавливают сильных особенностей.
«Надежные сигнатуры» означают возможность обнаружения и отслеживания.
Но ни один продукт не осмеливается претендовать на 100% обнаружение определенной технологии и ее вариантов.
Ни один продукт не может быть на 100% свободен от человеческого мнения/обработки.
А для тестирования и отслеживания нужны «люди».
Более того, для проверки автоматизированных результатов и их обработки также нужны люди.
Прежде чем мы перейдем от «людей-рыболовов» к «людям-рыбакам», практически невозможно предвидеть крупномасштабное коммерческое использование ИИ, который сможет заменить искусственный интеллект в этом сценарии.
Поэтому в реальном бою любая альтернатива — это приспособление, ведущее к успеху. Если копнуть глубже, то невыбранные методы реализации, такие как «mshta», «sct», «ComHandler» и т. д., перечисленные в исходном 0x01, также являются альтернативами, и все они находятся в процессе достижения цели «бокового перемещения на основе план задач` Гаджеты доступны в формате .
Даже рекомбинируя эти альтернативы, можно получить массу других полезных «цепочек».
Содержимое, описанное в этой статье, представляет собой более крупный гаджет в более широкой поведенческой цепочке «Противостояние-Проникновение в интранет-Домен-RPC».
0x05 Сводка
Это третья статья в этой серии. Мы начинаем со сценария применения, затем проводим технико-экономическое обоснование, затем проводим эксперименты с прототипами на основе проанализированного содержания и, наконец, объединяем практический опыт для оттачивания нового инструмента бокового движения.
Сражаться с другими — это бесконечное удовольствие. Исследование безопасности — это, по сути, игра между людьми. С чисто технической точки зрения, каждый «проработанный» и «освоенный» технический момент должен стать нашим «резервом гаджетов» в сочетании с нашим долгосрочным накоплением. «Опыт» — это используется для «динамического» создания разумной «Цепи» в процессе, которая в конечном итоге будет реализована в реальном бою.
Практическое применение должно представлять собой органичное сочетание знаний.Не существует техники абсолютного успеха раз и навсегда, но накопление и понимание знаний может облегчить нам задачу.
Конечно, если вам просто нравится безмозглый 12345, то просто сделайте вид, что я ничего не говорил.
Код в статье можно найти на Github . На этот раз это прототип без подводных камней и его можно использовать напрямую, но некоторые функции лучше модифицировать самостоятельно, чтобы предотвратить сбои.
Опять же, я надеюсь, что эта статья вдохновит вас не только на технические моменты.
Продолжая вышеизложенное, после отслеживания и изучения собственных вызовов компонента запланированной задачи мы умело объединили COM, UAC и ITaskService, чтобы успешно найти новый обход UAC или поговорить о новой поверхности атаки.
Теперь давайте продолжим расширять наше мышление. Оглядываясь на первую статью, мы подтвердили в начале исследования, что суть программы запланированных задач — это интерфейс RPC, использующий XML в качестве носителя данных. По словам Microsoft, RPC используется для «вызовов между процессами, независимо от того, находятся ли процессы на одном хосте».
Таким образом, запланированные задачи, основанные на протоколе RPC, по своей сути пригодны для горизонтального перемещения.
Конечно, это не новая технология, мы, как те, кто не умер внезапно в начале августа, еще раз поигрались с `atexec`, `schtasks` и даже более старым `at.exe`. Все эти методы без исключения используют интерфейс RPC компонента запланированной задачи для бокового перемещения. Среди известных методов использования мы можем завершить эхо, выполняя команды удаленно, записывая файлы и, наконец, читая общий каталог; или напрямую выходить в Интернет с помощью многих безфайловых средств.
В реальном бою они в той или иной степени столкнутся с некоторыми проблемами. Например, методы файлового эха могут столкнуться со многими нетрадиционными средами, такими как недоступные общие ресурсы и несовместимые протоколы SMB. Помимо ограничений окружающей среды, в конфронтационных средах они часто сталкиваются с «известными» угрозами: известной угрозой. Известные методы или методы атаки должны иметь соответствующие обнаружение.
Это далее приводит к очень практической проблеме:
Будь то инструменты, оружие или платформы, независимо от того, насколько идеально они работают в теоретической среде, их может быть не так легко использовать в практических условиях.
Исследование новых методов всегда является первой темой противостояния. Теперь, исходя из потребностей реальной боевой обстановки , мы нашли для себя новую тему: как добиться более стабильного горизонтального смещения эхо-сигнала/обнаружения окружения?
0x01 Мышление
Исследования безопасности никогда не направлены на решение проблем вслепую. Здесь наша конечная цель — изучить относительно лучшую технологию бокового движения (при определенных обстоятельствах).Технические проблемы часто можно легко разложить на несколько последовательных шагов, поэтому мы можем продолжать их совершенствовать:
Каковы этапы латерального движения? Какие технологии задействованы на каждом этапе? Каковы плюсы и минусы каждой технической детали?
Размышление в этом направлении позволит выявить следующие технические детали:
Боковое движение требует подключения к цели, которое проявляется в виде протокола на сетевом уровне, поэтому первая подзадача:
Какой протокол используется?
Протокол несет сервисы, а неуязвимое боковое перемещение по сути является злоупотреблением сервисными функциями, поэтому вторую подзадачу можно декомпозировать:
Какие функции, предоставляемые самой службой, мы можем использовать для получения разрешений на выполнение?
После успешного получения разрешений на выполнение в реальных боевых условиях часто требуется обратная связь по результатам.Мы получаем третий подвопрос:
Может ли сама служба возвращать результаты напрямую? Если его не поддержат, какие дополнительные меры необходимы?
Наконец, существует непреходящая старая проблема в реальной боевой обстановке:
Есть ли какие-либо известные особенности приведенной выше реализации?
Объединение вышеперечисленных этапов — это полный процесс, который мы ожидаем выполнить. Эту идею можно сравнить с «цепочкой десериализации/ROP». Мы рассматриваем весь шаг как «цепочку», любая реализация на каждом этапе рассматривается как независимый и подключаемый «гаджет», а точка конфронтации рассматривается как «черный список». в сочетании с известными знаниями легко получить такую простую и несовершенную таблицу:
| протокол | Служить | осуществлять | возвращаться | Точка противостояния |
| СМБ | АТСВЦ | Заказ | Обмен файлами | перенаправление cmd /c, посадка файла |
| СМБ | СРВСВЦ | Служить | Обмен файлами | перенаправление cmd /c, посадка файла |
| RPC/DCOM | WMI | команда/служба | Обмен файлами/регистрация | перенаправление cmd/c, зависимость SMB, UUID трафика |
Послушайте, разведка угроз и исследования в области безопасности взаимосвязаны, а Интернет и конфронтация также связаны.
Учитывая, что мы рассматриваем плановые задачи, возникает вопрос: могут ли плановые задачи это сделать?
Опираясь на результаты исследований двух наших предыдущих статей, нетрудно ответить на этот вопрос:
1.`MS-TSCH` основан на `RPC`, не может быть закрыт и доступ разрешен в большинстве случаев.
2.`ExecAction` обеспечивает неограниченное выполнение команд. После записи файлов и реестра `ComHandlerAction` обеспечивает неограниченное выполнение кода.
3. Протокол использует кодировку UTF-16 для передачи «полного» определения XML клиенту «как есть». Элемент `Description` может размещать любое `строковое` содержимое без ограничений.
4. Уровень трафика может перехватывать пакеты подтверждения только через UUID, а прямая тревога/блокировка может повлиять на управление сервером; все цепочки процессов на уровне хоста занесены в белый список; ExecAction не поддерживает перенаправление вывода, поэтому сообщение «нет файла» ` требуется метод; для `ComHandlerAction` требуются безфайловые средства или другие средства `записи в файлы` и `реестр`.
Таким образом, в нашу таблицу можно добавить следующие два элемента рядом:
| протокол | Служить | осуществлять | возвращаться | Точка противостояния |
| ПКП | ТТГ | Заказ | собственный протокол | UUID трафика, обнаружение бесфайловых атак |
| ПКП | ТТГ | Заказ | собственный протокол | Реализованы UUID трафика и реестр файлов. |
Учитывая сложность, бесфайловый ExecAction явно лучше, чем ComHandlerAction, который требует большой реализации.
Поэтому наша проблема естественным образом трансформируется из «латерального движения» в «меры противодействия бесфайловым атакам».
Использование этой технологии, которая существует уже не менее десяти лет, очень зрело, а методы преобразования очень разнообразны, а это означает, что у нас есть много гладких методов внедрения. В текущем сценарии нам необходимо использовать бесфайловые атаки для выполнения команд или обнаружения информации, а затем в качестве возврата изменить информацию о запланированном задании.
По-видимому, это могут сделать различные бесфайловые атаки на основе сценариев, такие как mshta, различные формы sct и xslt, cmd и PowerShell.
Во-первых, исключите `cmd`; во-вторых, учтите, что первые несколько технологий, основанных на хостинге сценариев Windows («Хостинг сценариев Windows»), должны инициировать запросы http или smb к внешнему миру, и приземление файла может легко вызвать некоторые ненужные проблемы. Поэтому PowerShell, реализующий полные функции сценариев через командную строку, стал первым выбором.
реализация 0x02
Как только технические моменты будут подтверждены, реализовать это не составит труда.
Прежде всего, мы обращаемся к содержанию первых двух глав. Независимо от того, копируем ли мы пример `MSDN`, сами компилируем `IDL`, используем `C# Interop` и т. д., мы можем напрямую подключиться к удаленной цели. Все, что мы нужно указать при использовании RPC Correct `Binding` и вызвать `RpcBindingSetAuthInfoEx`:
С++
_SEC_WINNT_AUTH_IDENTITY identity = { 0 };
LPWSTR domain = L"ROOT";
LPWSTR username = L"administrator";
LPWSTR password = L"P@ssw0rd";
identity.Domain = (unsigned short*)domain;
identity.DomainLength = lstrlenW(domain);
identity.Flags = SEC_WINNT_AUTH_IDENTITY_UNICODE;
identity.User = (unsigned short*)username;
identity.UserLength = lstrlenW(username);
identity.Password = (unsigned short*)password;
identity.PasswordLength = lstrlenW(password);
RpcBindingSetAuthInfoExW(hBinding, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_AUTHN_WINNT, &identity, 0, (RPC_SECURITY_QOS*)&qos);
Или укажите учетные данные при вызове `ITaskService::Connect`:
С++
pService->Connect(_variant_t(L"Target"), _variant_t(L"administrator"),_variant_t(L"ROOT"), _variant_t("P@ssw0rd"));
(Осознали ли вы преимущества «абстракции» и «прозрачности»?)
Во-вторых, PowerShell предоставляет полную объектную модель для запланированных задач и предоставляет для операций ряд командлетов, таких как Get-ScheduledTask и Set-ScheduledTask. Нам даже не нужно обращаться к msdn, мы можем написать такой сценарий, просто основываясь на справочной документации локального командлета:
PowerShell
$task=Get-ScheduledTask -TaskName TestTask -TaskPath \;
$task.Description=(iex $task.Description|out-string);
Set-ScheduledTask $task;
В этом сценарии мы получаем объект удаленного управления через Get-ScheduledTask и выполняем команду, сохраненную в описании, через iex. Учитывая, что все возвращаемые данные из PowerShell являются объектами, мы используем out-string для результата. преобразуется в читаемую строку и, наконец, сохраняется.
Один из ключевых моментов гаджет-мышления заключается в том, что если гаджет правильный и логика подключения гаджетов правильная, то и конечный результат должен быть правильным. Итак, нам просто нужно создать запланированную задачу, установить содержимое элемента `/Task/RegistrationInfo/Description` XML` для команды, которая будет выполнена, установить имя `TestTask` и указать командную строку. к приведенной выше команде PowerShell, запустите это запланированное задание, и результатом команды станет «Описание».
Наконец, просто прочитайте содержимое XML и сопоставьте его с содержимым «Описание».
С#
var xd=new XmlDocument();
xd.LoadXml(task.Xml);
Console.WriteLine(xd.SelectSingleNode("/*[local-name()='Task']/*[local-name()='RegistrationInfo']/*[local-name()='Description']").InnerText);
0x03 Полировка
Благодаря описанному выше процессу от обдумывания до реализации у нас есть исполняемый и эффективный технический прототип, который мы затем доработаем, чтобы приблизить его к статусу реального «оружия».
Во-первых, мы используем ExecAction для создания запланированной задачи, а это означает, что нам нужно использовать командную строку для передачи параметров, поэтому лучше всего использовать -EncodedCommand. На самом деле это не имеет ничего общего с `opsec`, основная цель - решить ряд проблем, которые могут вызвать экранирование.
На уровне сопоставления мы знаем, что логика обработки параметров PowerShell заключается в выполнении сопоставления без учета регистра на основе префикса, поэтому на самом деле, в дополнение к общим `-e` и `-enc`, `-EncodedCommand` также имеет что-то вроде следующих Десятки тысяч способов записи:
Баш
-eN
-eNCo
-Encode
....
Запланированное задание выполняется в фоновом режиме, поэтому лучше всего добавить -NonInteractive. Аналогично, этот параметр также имеет десятки тысяч способов записи:
Баш
-nonInt
-nOnInTe
....
В принципе, этого достаточно, чтобы справиться с некоторыми традиционными методами защиты без лексического анализа.
Далее, поскольку мы движемся вбок, мы не можем определить время выполнения команды в целевой среде, поэтому нужно добавить опрос.
Условие завершения опроса не должно "умно" напрямую определять, было ли изменено описание. На самом деле это не бесполезно, но эквивалентно бесконечному циклу в случае "ошибки сценария".
Объект IRegisteredTask предоставляет свойство State, которое представляет текущий статус задачи. После завершения задачи оно изменится с «Выполняется» на «Готово», поэтому вам нужно всего лишь опросить, чтобы прочитать статус задачи.
С#
while (task.State != TaskState.Ready)
{
task = folder.GetTask(taskname);
Thread.Sleep(1000);
}
Кроме того, есть несколько дополнительных методов `opsec`, которые являются вишенкой на торте, потому что в команде нет общих (я специально имею в виду `выполнение загрузки`, которое многими правилами рассматривается как единственное злоупотребление Powershell`) сильных функций. контента, поэтому с ним почти нет необходимости иметь дело.
Аналогично ни одно антивирусное ПО не будет сканировать атрибут «Описание» плана задачи (будь то «Объект», «Память» или «Xml»), поэтому достаточно не обрабатывать его по умолчанию.
Конечно, это все последующие действия. Когда этот метод уловит некоторые «сильные особенности», тогда мы займемся iex и закодируем возврат и команду, что станет новой точкой противостояния, ожидающей, чтобы ее добыли.
Наконец, не забывайте, что «iex» на самом деле выполняет сценарий PowerShell, так что это «удаленный PowerShell» (вспомним «WinRM»), что означает, что мы можем не только выполнять «программы командной строки»:
Вы также можете выполнить произвольные «командлеты»:
Еще более сложные `скрипты`:
Это означает, что все, что может делать .Net, мы можем выполнять «удаленно», «без файлов» и «необнаружимо». При дальнейших модификациях мы можем даже создать по-настоящему интерактивный удаленный PowerShell на базе MS-TSCH.
(Почему там написано, что может быть ошибка скрипта? Вот она)
0x04 Отражение
На этом контент, связанный с запланированными задачами, в основном закончен. Далее мы выходим за рамки запланированных задач и рассматриваем имеющиеся у нас решения с точки зрения сценариев применения. С одной стороны, сделайте простое резюме, с другой – подумайте, как его разумно использовать.
В сценарии бокового движения, помимо уязвимостей и запланированных задач, наиболее классическими и полезными технологиями являются PsExec и WMI.
Почему PsExec выдерживает испытание временем? В дополнение к opsec, введенному сигнатурой Microsoft, существует также протокол SMB, который должен быть включен по умолчанию в доменной среде, который реализует характеристики сочетания горизонтального сдвига и эха одного протокола, поэтому в течение длительного времени Используется в качестве первого выбора для проникновения во внутреннюю сеть. Даже сейчас самомодифицированная версия PsExec, основанная на Impacket или API, все еще может сыграть хорошую роль.
Почему позже оно было изменено на WmiExec? Поскольку служба WMI также включена по умолчанию, и практически нет возможности ее выключения, цель повторения того же протокола все равно может быть достигнута с помощью stdregprov, что делает его первым выбором для обхода на основе DCOM. протокол.
Теперь у нас есть дополнительная технологическая опция «Taskexec на основе RPC».
Да, это всего лишь техническое дополнение, а не замена.
Почему?
Потому что каждая технология атаки должна иметь различную область применения/требования к среде, а также должны иметь различные сильные характеристики.
Все методы «необнаружимого» обхода («обхода»)/эскейпа («уклонение») претендуют на необнаружимость, но они просто не улавливают сильных особенностей.
«Надежные сигнатуры» означают возможность обнаружения и отслеживания.
Но ни один продукт не осмеливается претендовать на 100% обнаружение определенной технологии и ее вариантов.
Ни один продукт не может быть на 100% свободен от человеческого мнения/обработки.
А для тестирования и отслеживания нужны «люди».
Более того, для проверки автоматизированных результатов и их обработки также нужны люди.
Прежде чем мы перейдем от «людей-рыболовов» к «людям-рыбакам», практически невозможно предвидеть крупномасштабное коммерческое использование ИИ, который сможет заменить искусственный интеллект в этом сценарии.
Поэтому в реальном бою любая альтернатива — это приспособление, ведущее к успеху. Если копнуть глубже, то невыбранные методы реализации, такие как «mshta», «sct», «ComHandler» и т. д., перечисленные в исходном 0x01, также являются альтернативами, и все они находятся в процессе достижения цели «бокового перемещения на основе план задач` Гаджеты доступны в формате .
Даже рекомбинируя эти альтернативы, можно получить массу других полезных «цепочек».
Содержимое, описанное в этой статье, представляет собой более крупный гаджет в более широкой поведенческой цепочке «Противостояние-Проникновение в интранет-Домен-RPC».
0x05 Сводка
Это третья статья в этой серии. Мы начинаем со сценария применения, затем проводим технико-экономическое обоснование, затем проводим эксперименты с прототипами на основе проанализированного содержания и, наконец, объединяем практический опыт для оттачивания нового инструмента бокового движения.
Сражаться с другими — это бесконечное удовольствие. Исследование безопасности — это, по сути, игра между людьми. С чисто технической точки зрения, каждый «проработанный» и «освоенный» технический момент должен стать нашим «резервом гаджетов» в сочетании с нашим долгосрочным накоплением. «Опыт» — это используется для «динамического» создания разумной «Цепи» в процессе, которая в конечном итоге будет реализована в реальном бою.
Практическое применение должно представлять собой органичное сочетание знаний.Не существует техники абсолютного успеха раз и навсегда, но накопление и понимание знаний может облегчить нам задачу.
Конечно, если вам просто нравится безмозглый 12345, то просто сделайте вид, что я ничего не говорил.
Код в статье можно найти на Github . На этот раз это прототип без подводных камней и его можно использовать напрямую, но некоторые функции лучше модифицировать самостоятельно, чтобы предотвратить сбои.
Опять же, я надеюсь, что эта статья вдохновит вас не только на технические моменты.