Comments 12
И теперь это логично приводит нас к последнему достижению безопасности Microsoft, известному как AppLocker
который хотя и работает, но эффект имеет только в версии enterprise 10 и не ниже ultimate для семерки. Вкусно, но бабла не стоит в таком объеме. Правда, если у кого есть enterprise, то он таки рулит.
Какое-то глупое решение, не стоит его советовать даже как пример для фичи.
Достаточно политиками задать выполнение только подписанных скриптов и подписывать свои рабочие скрипты.
Достаточно политиками задать выполнение только подписанных скриптов и подписывать свои рабочие скрипты.
Если хакеры ослабят свою философию, то они смогут запросто скачать, скажем, с помощью трояна удаленного доступа (RAT) — их собственную копию PowerShell.ехе. А затем запустить его напрямую, с легкостью избежав ограничений с разрешениями с локальным PowerShell.
Если они такое могут сделать, то почему они не могут скачать и запустить что-то еще — например свою программу — которая сделает все, что угодно?
Простите меня. Вся статья какая то полная непроглатываемая хрень.
Powershell сам по себе не дает юзерам админских прав в системе, и можно запускать миллион скриптов с байпассом и получить… ничего. Загрузить из интернетов вирусню или эксплойт под юзерскими правами можно чем угодно, и Powershell дает такую возможность наравне с нативными cmd/vbs, или любым скомпилированным на системе нативным кодом.
Имея шелл в инфраструктуре с админскими привилегиями уже становится абсолютно всеравно что использовать, все ограничено только личными предпочтениями злоумышленника.
Фокусирование на Powershell.exe абсолютно бесполезно, если не обращать внимания на cmd.exe и cscript.exe и множество других вещей.
зыю
Подписывание скриптов PS1 используется для исключения возможности подмены кода внутри скрипта размещенного в не полноценно ограниченной или контролируемой среде. Вы не можете менять код в нем, иначе подпись станет неверна, и не можете добавить байпас, поскольку не знаете пароля от доменной сервисной учетной записи из под которой запускается выполнение скрипта. А вот обеспечить такую защиту с cmd/bat/vbs у вас не получится.
Нытье про байпасы и set-executionpolicy возникает от незнания и непонимания как инструмент работает. Раз в квартал на хабре появляется очередной срыватель покровов, который по ощущением первый раз увидел Powershell менее месяца назад и бегло погуглил доказательства от таких же срывателей покровов в интернетах.
Powershell сам по себе не дает юзерам админских прав в системе, и можно запускать миллион скриптов с байпассом и получить… ничего. Загрузить из интернетов вирусню или эксплойт под юзерскими правами можно чем угодно, и Powershell дает такую возможность наравне с нативными cmd/vbs, или любым скомпилированным на системе нативным кодом.
Имея шелл в инфраструктуре с админскими привилегиями уже становится абсолютно всеравно что использовать, все ограничено только личными предпочтениями злоумышленника.
Фокусирование на Powershell.exe абсолютно бесполезно, если не обращать внимания на cmd.exe и cscript.exe и множество других вещей.
зыю
Подписывание скриптов PS1 используется для исключения возможности подмены кода внутри скрипта размещенного в не полноценно ограниченной или контролируемой среде. Вы не можете менять код в нем, иначе подпись станет неверна, и не можете добавить байпас, поскольку не знаете пароля от доменной сервисной учетной записи из под которой запускается выполнение скрипта. А вот обеспечить такую защиту с cmd/bat/vbs у вас не получится.
Нытье про байпасы и set-executionpolicy возникает от незнания и непонимания как инструмент работает. Раз в квартал на хабре появляется очередной срыватель покровов, который по ощущением первый раз увидел Powershell менее месяца назад и бегло погуглил доказательства от таких же срывателей покровов в интернетах.
UFO just landed and posted this here
Powershell сам по себе не дает юзерам админских прав в системе, и можно запускать миллион скриптов с байпассом и получить… ничего.
Шифровальщикам админские права не нужны, но главная угроза Powershell в обходе SRP, так как интерпретатор позволяет сделать свой шифровальщик в инлайн вызовах.
Чтобы запустить powershell со скриптом шифровальщиком, разве не надо сначала запустить что-то еще, что запустит это скрипт? А это что-то еще не может причинить сравнимый вред, например просто путем стирания данных?
Пользователь может притащить лаунчер на ярлыках или загрузчик из документа на JS/VBA. В любом случае лишняя защита не повредит.
SRP и AWL таки весьма специфичные решения, подходящие далеко не для всех инфраструктур. Я видел много попыток «энтузиастов» внедрить, но не видел ни одной выжившей реализации, и на мой взгляд это бесполезно потраченные трудочасы ИТ-специалиста если разговор идет о офисе, а не о терминалах/киосках/АСУТП.
В офисе проще и эффективнее работает стандартный комплекс мер по защите ПК и пользовательских данных и пока что я не видел, что бы шифровальщики, которые полагаются на широту охвата достигали каких либо результатов. Вернее видел, но не в подотчетной мне инфраструктуре.
Совсем другое дело в таргетированных атаках, и тут приходится держать не просто юзерскую и админскую учетку для себя, но и дробить админскую как минимум на три разных в плане прав, а то и о бастионном домене задумываться. Но такие атаки сложны и дороги, и врятли у меня в инфраструктуре есть настолько важная и ценная информация.
— Вот вроде проблема есть, но в тоже время если не сидеть сложа руки, острота проблемы не критична. Юзеры куда чаще файлы сами сносят или теряют, чем шифраторы добираются до их данных.
Такчто, ну дает PS возможность обойти SRP и AWL, ну и фиг с ним, поддержка этих решений сожрет трудочасов в сотни раз больше, чем время на возврат файлов из бэкапа или вытаскивание их из VSС/VSS. А перед этим должно случится еще множество «если» и «оказалось»
В офисе проще и эффективнее работает стандартный комплекс мер по защите ПК и пользовательских данных и пока что я не видел, что бы шифровальщики, которые полагаются на широту охвата достигали каких либо результатов. Вернее видел, но не в подотчетной мне инфраструктуре.
Совсем другое дело в таргетированных атаках, и тут приходится держать не просто юзерскую и админскую учетку для себя, но и дробить админскую как минимум на три разных в плане прав, а то и о бастионном домене задумываться. Но такие атаки сложны и дороги, и врятли у меня в инфраструктуре есть настолько важная и ценная информация.
— Вот вроде проблема есть, но в тоже время если не сидеть сложа руки, острота проблемы не критична. Юзеры куда чаще файлы сами сносят или теряют, чем шифраторы добираются до их данных.
Такчто, ну дает PS возможность обойти SRP и AWL, ну и фиг с ним, поддержка этих решений сожрет трудочасов в сотни раз больше, чем время на возврат файлов из бэкапа или вытаскивание их из VSС/VSS. А перед этим должно случится еще множество «если» и «оказалось»
С простым офисным людом вообще никаких проблем, один раз настроить path rules с исключениями по статьям Crypt32 и изредка добавлять hash rules для ПО на флешках или сетевых дисках.
А лаунчер я увидел у пришлых бухгалтеров на внешнем диске с варезом, не уверен как именно он обходил SRP, но работать перестал только после запрета виндовых интерпретаторов.
А лаунчер я увидел у пришлых бухгалтеров на внешнем диске с варезом, не уверен как именно он обходил SRP, но работать перестал только после запрета виндовых интерпретаторов.
А на JS/VBA нельзя написать шифровальщик?
Интересно было бы сформулировать правила, чтобы безопасность была бы примерно как на айпеде:
- Нельзя записывать и менять, то, что можно запустить
- Нельзя запускать, то, что пользователь может изменить.
Т.е. все скрипты и прочее должны или вообще не запускаться или не иметь возможности быть измененным пользователем.
Едиственное, это требует поддержки от всего ПО. Так как мы не знаем Shutuka.XYZ — это скрипт или файл с данными.
Sign up to leave a comment.
Отключение PowerShell и прочие особенности борьбы с Malware. Часть I