Можно ли переопределить динамическое связывание во время загрузки Windows? - PullRequest
0 голосов
/ 20 марта 2019

Я аспирант, работаю над перехватом Windows API. Я знаю, что нелегко заменить Защищенную DLL в папке System32 модифицированной DLL. Но я искал, есть ли способ, с помощью которого я могу изменить / переопределить Windows Dynamic DLL Linker, чтобы я мог подключать Windows API глобально, без использования каких-либо других системных API?

Мое намерение состоит в том, чтобы профилировать скрипты Powershell в глобальном масштабе для любого византийского поведения монитора. Хуккинг был первой мыслью, которая пришла мне в голову.

Я искал ответы в Windows Internal Book (6-е издание), но не смог найти никакой теории, основанной на этом. Ссылка также будет оценена.

Спасибо.

1 Ответ

1 голос
/ 20 марта 2019

Можно использовать старую функцию под названием Detours.Есть раздел реестра AppInit_DLLs, который содержит список библиотек, которые загружаются в каждый процесс при запуске.Это используется, например, Антивирусом Sophos.Это действительно глобально, AFAIK.Каждый процесс проверяет это при создании процесса.Тем не менее, потенциально актуальное обсуждение здесь: Предотвращение загрузки файла DLL в мой процесс через MS Detours

Однако, если вы хотите отслеживать именно Powershell, и вы можете рассчитывать на PSv5 ивыше, Powershell предоставляет вам очень мощную встроенную функциональность для мониторинга и ограничения.Вам, вероятно, будет лучше, если вы воспользуетесь этим.

Абсолютный ne plus ultra документ озаглавлен Защита PowerShell в Enterprise и опубликован Австралийским центром кибербезопасности здесь .Я предполагаю, что они будут держать это там в течение долгого времени, будучи государственным органом, но даже если это пойдет не так, вы сможете найти копию с вашей поисковой системой по вашему выбору.Регулярно обновляется;на момент написания он показывает «март 2019» и содержит этого полезного участника:

Организации или лица, имеющие вопросы относительно этого совета, могут связаться с ACSC, отправив электронное письмо asd.assist на защита.gov.au или позвонив по номеру 1300 CYBER1 (1300 292 371).

В Австралийское управление сигналов, спасибо .Так как это австралийский номер, не забывайте держать телефон в перевернутом положении.

В духе СО, я дам вам точную информацию.В документе изложена последовательность достижимых шагов для перехода от низкого уровня к высокому уровню безопасности.Этапы:

  • Конфигурация по умолчанию
  • Белый список скриптов
  • Подписание кода для скриптов
  • PSv5
  • Центральная регистрация и транскрипция
  • Белый список на основе ролей
  • Укрепление WinRM
  • Ограниченные конечные точки

Весь документ состоит из 20 страниц, так что это не большие затраты времени.Но поскольку ваш вопрос, по-видимому, касается раздела Централизованное ведение журнала и транскрипции , вот соответствующий отрывок, демонстрирующий возможности:

  • Ведение журнала жизненного цикла двигателя: PowerShell регистрирует запуски прекращение хостов PowerShell.PowerShell версии 5.0 позволяет регистрировать аргументы командной строки, передаваемые хосту PowerShell, включая код PowerShell, передаваемый powershell.exe через командную строку.Ведение журнала жизненного цикла двигателя включено по умолчанию и находится в журналах приложений и служб \ Microsoft \ Windows \ PowerShell \ Operational.
  • Ведение журнала модулей / конвейеров: PowerShell версии 3.0 и более поздних может регистрировать события конвейера в событии WindowsЖурналы на основе модуля или на глобальной основе.Это можно установить с помощью групповой политики.
  • Отслеживание блокировки сценария: PowerShell версии 5.0 может регистрировать подробную информацию, включая код, который был запущен и выводится в журнал событий Windows.
  • Транскрипция: версия PowerShell5.0 допускает транскрипцию кода на всех хостах PowerShell и может контролироваться групповой политикой.Несмотря на то, что протоколы очень мощные, они не интегрируются в журналы событий Windows и должны управляться как на дисковых файлах.

Вот выдержка из приложения, относящегося к этому разделу:

Details of Group Policy settings to enforce appropriate logging for PowerShell based activities

Я не совсем уверен, куда вы идете с этим, но мне кажется, что эта статья может быть полезна для вас.

...