По одному этому комментарию не очень понял как отвечать, но ниже вы сказали что предлагаете использовать сетевое оборудование для детекта, и чтобы тред был красивым отвечу тут.
Я вижу в этом две проблемы: 1. Нужно смотреть/тестировать/понять как именно написано правило чтобы не было неожиданностей в виде переодической блокировки легитимного RPC трафика из за решения маршрутизатора отнести его к опасному. Либо это правило не блокирующее, но при этом генерирует много ложно позитивных/ложно негативных срабатываний что тоже не слишком полезно. Насколько я знаю (могу быть неправ) получить эту информацию от вендора сложно, поэтому приходится выяснять опытным путём.
2. Использование SMB 3 трафика. Обычно это не проблема, но так как он зашифрован, а Named Pipes работают через SMB, то соответственно и передача бинарника/запуск сервиса/общение с бинарником будет зашифровано и детект на основе трафика будет бессилен.
Согласно вашему комментарию, я могу подтвердить, что детектирование горизонтального перемещения является сложной задачей, которая может потребовать программирования и анализа конкретной ситуации.
PsExec - это утилита, которая может использоваться для автоматизации задач и управления удаленными системами. Однако, она не предназначена для детектирования горизонтального перемещения.
Для детектирования горизонтального перемещения можно использовать различные методы, такие как мониторинг событий в системном журнале, анализ логов, мониторинг сетевого трафика и т.д. Каждый метод имеет свои преимущества и ограничения, поэтому оптимальный подход может зависеть от конкретной задачи.
Если у вас есть конкретные вопросы или задачи, связанные с детектированием горизонтального перемещения, я готов помочь вам более конкретно. Просто уточните свои потребности, и я постараюсь помочь вам решить проблему.
А разве детект по IP не обходится? Например в случаях read only DC находящегося в другой сети ну или если правило поставили на подсетку из за DHCP. В первой части описано что не обязательно мониторить вызов DRSGetNCChanges по IP, проще и надёжнее смотреть на сам факт вызова DRSReplicaSync и DRSGetNCChanges.
Потому что атаку используют, ну а если используют значит есть причина. Сам я так же думаю что проще просто вывести пользователя из группы администраторов, но если пользователь на домашнем ПК, то такого вопроса не стоит.
Да, моё личное мнение, что они изначально выпускали это как security, но потом что-то пошло не так и они от неё открещиваются. Но до конца убрать её не хотят/не могут и поэтому возникают вот такие ситуации "Это мы исправим, а это нам лень и вообще это не security".
Да, Microsoft не планирует их исправлять, некоторые из ошибок перекочевали из Windows 7. Насчёт патчей от вендоров тоже сомневаюсь, некоторые из ошибок слишком сложны, чтобы исправлять их вместо Microsoft (а это нужно ещё и поддерживать такой код!).
Насчёт обнаружить постфактум, я бы добавил что если есть какая-то автоматизация реагирования - то можно защититься раньше чем UAC Bypass успел состояться. Детект написан так, чтобы зафиксировать атаку как можно раньше там где это возможно.
Можно ли говорить о том что FreeIPA безопаснее MS AD? Как минимум нет NTLM
По одному этому комментарию не очень понял как отвечать, но ниже вы сказали что предлагаете использовать сетевое оборудование для детекта, и чтобы тред был красивым отвечу тут.
Я вижу в этом две проблемы:
1. Нужно смотреть/тестировать/понять как именно написано правило чтобы не было неожиданностей в виде переодической блокировки легитимного RPC трафика из за решения маршрутизатора отнести его к опасному. Либо это правило не блокирующее, но при этом генерирует много ложно позитивных/ложно негативных срабатываний что тоже не слишком полезно. Насколько я знаю (могу быть неправ) получить эту информацию от вендора сложно, поэтому приходится выяснять опытным путём.
2. Использование SMB 3 трафика. Обычно это не проблема, но так как он зашифрован, а Named Pipes работают через SMB, то соответственно и передача бинарника/запуск сервиса/общение с бинарником будет зашифровано и детект на основе трафика будет бессилен.
Согласно вашему комментарию, я могу подтвердить, что детектирование горизонтального перемещения является сложной задачей, которая может потребовать программирования и анализа конкретной ситуации.
PsExec - это утилита, которая может использоваться для автоматизации задач и управления удаленными системами. Однако, она не предназначена для детектирования горизонтального перемещения.
Для детектирования горизонтального перемещения можно использовать различные методы, такие как мониторинг событий в системном журнале, анализ логов, мониторинг сетевого трафика и т.д. Каждый метод имеет свои преимущества и ограничения, поэтому оптимальный подход может зависеть от конкретной задачи.
Если у вас есть конкретные вопросы или задачи, связанные с детектированием горизонтального перемещения, я готов помочь вам более конкретно. Просто уточните свои потребности, и я постараюсь помочь вам решить проблему.
Wireshark
К сожалению, ничего такого не видел. Можно с помощью Wireshark расшифровывать параметры для RPC и от этого играть, но наверное это вам не подойдёт.
А разве детект по IP не обходится? Например в случаях read only DC находящегося в другой сети ну или если правило поставили на подсетку из за DHCP. В первой части описано что не обязательно мониторить вызов DRSGetNCChanges по IP, проще и надёжнее смотреть на сам факт вызова DRSReplicaSync и DRSGetNCChanges.
Да, я согласен. Добавлю что UAC как раз был призван лаконично исправить эту проблему, как бы сделав два аккаунта из одного.
Да, но кто это делает?
Потому что атаку используют, ну а если используют значит есть причина. Сам я так же думаю что проще просто вывести пользователя из группы администраторов, но если пользователь на домашнем ПК, то такого вопроса не стоит.
UAC в целом работает только в случаях когда пользователь входит в группу "Администраторы", соответственно и обходы тоже.
Да, моё личное мнение, что они изначально выпускали это как security, но потом что-то пошло не так и они от неё открещиваются. Но до конца убрать её не хотят/не могут и поэтому возникают вот такие ситуации "Это мы исправим, а это нам лень и вообще это не security".
Да, Microsoft не планирует их исправлять, некоторые из ошибок перекочевали из Windows 7. Насчёт патчей от вендоров тоже сомневаюсь, некоторые из ошибок слишком сложны, чтобы исправлять их вместо Microsoft (а это нужно ещё и поддерживать такой код!).
Насчёт обнаружить постфактум, я бы добавил что если есть какая-то автоматизация реагирования - то можно защититься раньше чем UAC Bypass успел состояться. Детект написан так, чтобы зафиксировать атаку как можно раньше там где это возможно.
Как написал@_RastaMouseв твиттере "Это доказательство что АНБ имеет бекдоры в компиляторе Rust"