PowerShell в роли инструмента для пентеста: скрипты и примеры от Varonis

[aliend]

В моей практике имеется курьезный случай, когда сотрудники информационной безопасности "продавили" принудительную установку PS последней версии на все серверы (2008 R2) и рабочие станции (7), мотивируя это в том числе и наличием "расширенного аудита командной строки" powershell. В то время мои администраторы легко обходились без PS, но инфобезы не могли воплотить в жизнь результаты очередного своего курса повышения квалификации. Вопрос — зачем в инфраструктуре разворачивать возможный backdoor — остался без вразумительного ответа. Вот такой вот насильственный прогресс.

[Varonis]

Интересная история, спасибо, что поделились!

[tualantin]

И в 2008R2 и уж тем более в 7, powershell стоит по умолчанию, так что по вашей логике бэкдор уже есть. А наличие аудита введенных команд и скриптов это азбука ИБ.

[aliend]

Версия PS из коробки (2, если не ошибаюсь) в WS2008R2/7 как раз и не позволяла делать все эти веселые трюки, описанные в статье. Поправьте меня, если ошибаюсь.

[tualantin]

v2 без проблем использует весь арсенал .NET, VBscipt, Wscript, WMI и т.д., а там уже дело техники т.е. все веселье доступно и в ней.

[Varonis]

2008R2 действительно шёл с PS version 2, только его поддержка заканчивается уже в январе 2020 года и в связи с этим в корпоративном сегменте использоваться, скорее всего, больше не будет.

[The_Kf]

И правильно говорили — действительно для аудита безопасности — полезная штука. Особенно, если журналы в он-лайн режиме выгружать.

[rrust]

повершелл мне нравится, особенно тем что в C# прогу можно интегрировать Powershell и наоборот. Что на Powershell можно реализовать полноценный GUI на Winforms или WPF и тогда для юзера вообще не видно разницы между C# .exe и .PS1
Я конечно не спец, но вообще так можно подумать, что это повершелл виноват в том, что юзер может что-то случайно скачать и запустить из интернета. И вообще то, что не остаются на диске файлы начального загрузчика, ничего принципиально не меняет. Если уж юзер каким-то образом был спровоцирован что-то скачать и запустить, то запрет повершелла или других скриптовых языков никак не помешает зловреду поселиться в системе и собирать доступные данные из AD/LDAP.
Вот отсутствие админских прав у юзера сильно мешает дальнейшей атаке на сеть. Остается ждать админских прав. А настоящее счастье будет если после получения админских прав на компе, залогинится чел с правами на сервера или даже на домен. Вот ограничение юзерских прав, разделение юзерских и админских аккаунтов, чтобы использовать юзерские аккаунты для работы на юзерских компах, а админских аккаунтов для работы на серверах и ни в коем случае на юзерском компе, может дать больший эффект для защиты конторы.

[Neveil]

К сожалению, для Applocker требуется Windows Enterprise, а SRP очень сложно правильно настроить без ложных срабатываний. Ситуация усугубляется невозможностью рекурсивных правил по маске с работой обычных правил по пути к папке.

[Sanctuary_s]

Опечатка в

New-ObjectSystem.Net.WebClient

Пробел нужен. :)

[Varonis]

спасибо, исправили!

[enrichment]

get-ChildItem | ? {$_.length –gt 10000000 | % {write-host$_.length $_.name -separator "`t`t"}

Не хватает пробела и "}" :-)

[Sanctuary_s]

Да и вообще по «канонам» лучше не сокращать так адово все.

Get-ChildItem -Path | Where-Object -FilterScript {$_.Length –gt 10000000} | ForEach-Object -Process {Write-Host $_.Length $_.Name -Separator "`t`t"}

Также удобнее. :)