В простейшем случае могу порекомендовать посмотреть настройки протокола в Wireshark (Edit-> Preferences...)
Можно поменять порты на нестандартные для того, чтобы Wireshark мог увидеть LDAP и можно было использовать стандартные фильтры. Если используется инкапсуляция в какой-то совсем нестандартный протокол, то можно попробовать написать свой плагин) https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html.
Если у злоумышленника есть админские права то он и так все сделает. В идеальном мире у пользователя нет админских прав и нет доступа в каталог, где сохраняются ключи. Все попытки обращения к файлам в каталоге должны мониториться и передаваться в SIEM/EDR.
Мы говорим о рабочих компах, соответственно если сотруднику для работы СБП и прочие платежные системы не требуются то запрещаем ему это оргмерами (политика безопасности организации) и техмерами (блокировка доступов к сайтам платежных систем на уровне МЭ). Если сотруднику для работы нужны платежные системы и без HTTPS никак, то для защиты от потенциального прослушивания нерадивыми админами должен использоваться второй фактор, передающий данные по другому каналу (например приложение на смартфоне в котором нужно нажать кнопочку для подтверждения второго фактора).
В случае самостоятельной сборки устройства на базе платы Teensy/Arduino можно прикрутить к примеру датчик движения. Если использовать Raspberry можно вообще камеру поставить.
При использовании RubberDuck/Teensy подобных устройств, проблема в том, что мы не можем получить на устройство обратную связь. То есть мы не знаем что сейчас делает пользователь. Единственное, что умеют BadUSB устройства это считывать нажатие клавиши Caps. Поэтому обычно после выполнения скетча специально "нажимается" Caps, для того, чтобы устройство могло считать его состояние и убедиться в том, что скрипт успешно выполнился.
Собственно условие по немногострочности кода является частью представленного в статье подхода. Меньше код в одном сервисе легче его править менять переписывать. Понятно что это не догма и существуют другие подходы, где размер кода значительно больше.
Спасибо, исправил.
В простейшем случае могу порекомендовать посмотреть настройки протокола в Wireshark (Edit-> Preferences...)
Можно поменять порты на нестандартные для того, чтобы Wireshark мог увидеть LDAP и можно было использовать стандартные фильтры. Если используется инкапсуляция в какой-то совсем нестандартный протокол, то можно попробовать написать свой плагин) https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html.
Если у злоумышленника есть админские права то он и так все сделает. В идеальном мире у пользователя нет админских прав и нет доступа в каталог, где сохраняются ключи. Все попытки обращения к файлам в каталоге должны мониториться и передаваться в SIEM/EDR.
Мы говорим о рабочих компах, соответственно если сотруднику для работы СБП и прочие платежные системы не требуются то запрещаем ему это оргмерами (политика безопасности организации) и техмерами (блокировка доступов к сайтам платежных систем на уровне МЭ). Если сотруднику для работы нужны платежные системы и без HTTPS никак, то для защиты от потенциального прослушивания нерадивыми админами должен использоваться второй фактор, передающий данные по другому каналу (например приложение на смартфоне в котором нужно нажать кнопочку для подтверждения второго фактора).
В случае самостоятельной сборки устройства на базе платы Teensy/Arduino можно прикрутить к примеру датчик движения. Если использовать Raspberry можно вообще камеру поставить.
При пентесте их обычно используют совместно с социнженерией, проще говоря отвлекают пользователя во время работы скетча.
При использовании RubberDuck/Teensy подобных устройств, проблема в том, что мы не можем получить на устройство обратную связь. То есть мы не знаем что сейчас делает пользователь. Единственное, что умеют BadUSB устройства это считывать нажатие клавиши Caps. Поэтому обычно после выполнения скетча специально "нажимается" Caps, для того, чтобы устройство могло считать его состояние и убедиться в том, что скрипт успешно выполнился.
Здравствуйте. Про окно была статья ранее https://habr.com/ru/companies/otus/articles/879054/
Здравствуйте. Спасибо за замечания. По тексту внесены правки.
Спасибо за замечания. Исходники поправил.
При отраженной DLL UAC уже никак помешать не сможет, потому, что мы создаем новый поток от имени пользовательского процесса.
По подмене DLL могу предложить эту статью от коллег
https://habr.com/ru/companies/otus/articles/497306/
А как же бюджет? Лучше конечно всем дать железки помощнее, только как правило на это денег не хватает, поэтому и появляются такие компромиссы.
Собственно условие по немногострочности кода является частью представленного в статье подхода. Меньше код в одном сервисе легче его править менять переписывать. Понятно что это не догма и существуют другие подходы, где размер кода значительно больше.