Използване на PowerShell за повишаване на привилегиите на локалните акаунти

Повишението на привилегиите е използването на текущите права на акаунта от злодеи, за да получат допълнителен, обикновено по-висок ниво на достъп в системата. Въпреки че повишението на привилегиите може да е резултат от експлоатация на уязвимости нулев ден или работа на първокласни хакери, извършващи целенасочена атака, или от добре прикрита злонамерена програма, по-често това се случва поради неправилна настройка на компютъра или акаунта. Разширявайки атаката, злодеите използват редица отделни уязвимости, което в съвкупност може да доведе до катастрофално изтичане на данни.

Защо потребителите не трябва да имат права на локален администратор?

Ако сте специалист по сигурността, може да ви се стори очевидно, че потребителите не трябва да имат права на локален администратор, тъй като това:

• Прави техните акаунти по-уязвими на различни атаки
• Прави тези атаки много по-сериозни

За съжаление, за много организации това все още е много спорен въпрос и понякога е придружен от бурни дискусии (вижте например, моят ръководител казва, че всички потребители трябва да бъдат локални администратори). Не навлизайки в детайли на тази дискусия, ние считаме, че злодеят е получил права на локален администратор на изследваната система: или чрез експлойт, или защото машините не са били адекватно защитени.

Стъпка 1. Обратно разрешаване на DNS имена чрез PowerShell

По подразбиране PowerShell е инсталиран на много локални работни станции и на повечето Windows сървъри. И макар да не е без преувеличение, той се счита за невероятно полезен инструмент за автоматизация и управление, в равна степен той може да се превърне в почти невидима fileless-малваре (програма за хакване, която не оставя следи от атаката).

В нашия случай злодеят започва да изпълнява мрежова рекогносцировка с помощта на PowerShell скрипт, последователно перебирайки IP адресното пространство на мрежата, опитвайки се да определи дали определен IP се разрешава на узел, и ако да, какво е мрежовото име на този узел.
Съществуват много начини за изпълнение на тази задача, но използването на команди Get-ADComputer — надежден вариант, тъй като предоставя наистина богат набор от данни за всеки възел:

 import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}

Ако скоростта на работа в големи мрежи предизвиква проблеми, може да се използва обратен системен DNS повик:

[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName

Този метод за изброяване на възли в мрежата е много популярен, тъй като повечето мрежи не използват модел за сигурност с нулево доверие и не проследяват вътрешните DNS заявки за подозрителни изблици на активност.

Стъпка 2: Избор на цел

Краен резултат от тази стъпка е получаването на списък с имена на хостове на сървъри и работни станции, който може да бъде използван за продължаване на атаката.

Съдейки по името, сървърът ‘HUB-FILER’ изглежда като добра цел, тъй като с времето файловите сървъри обикновено натрупват голямо количество мрежови папки и прекалено много достъп до тях от широк кръг лица.

Прегледът с помощта на Windows Explorer ни позволява да определим дали съществува отворена обща папка, но нашата текуща учетна запись не може да получи достъп до нея (вероятно имаме права само за изброяване).

Стъпка 3: Изучаване на ACL

Сега на нашия хост HUB-FILER и целевата обща папка share можем да стартираме PowerShell скрипт за получаване на списък с ACL. Можем да го направим от локалната машина, тъй като вече имаме права на локален администратор:

(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto

Резултат от изпълнението:

От него виждаме, че групата Потребители на домейна има достъп само за изброяване, но групата Helpdesk има и права за промяна.

Стъпка 4: Идентификация на Учетните Записи

Стартирайки Get-ADGroupMember, ще можем да получим всички членове на тази група:

Get-ADGroupMember -identity Helpdesk

В този списък виждаме учетната запись на компютър, която вече сме идентифицирали и до която вече сме получили достъп:

Стъпка 5: Използваме PSExec за работа от учетната запись на компютъра

PsExec от Microsoft Sysinternals позволява изпълнението на команди в контекста на системната учетна запись SYSTEM@HUB-SHAREPOINT, която, както знаем, е член на целевата група Helpdesk. Тоест, достатъчно е да изпълним:

PsExec.exe -s -i cmd.exe

След това имате пълен достъп до целевата папка HUB-FILERshareHR, тъй като работите в контекста на акаунта на компютъра HUB-SHAREPOINT. С този достъп данните могат да бъдат копирани на преносимо устройство за съхранение или по друг начин извлечени и предадени през мрежата.

Стъпка 6: Откритие на тази атака

Тази конкретна уязвимост в конфигурацията на правата на акаунтите (компютърни акаунти, които се свързват с общи мрежови папки вместо потребителски акаунти или служебни профили) може да бъде открита. Въпреки това, без правилни инструменти, това е много трудно.

За да открием и предотвратим тази категория атаки, можем да използваме DatAdvantage за идентифициране на групи с компютърни акаунти в тях, и след това да ограничим достъпа до тях. DatAlert идва едно стъпало по-напред и позволява да създадем уведомление специално за подобен сценарий.

На екрана по-долу е показано потребителско уведомление, което ще сработи при всеки достъп на компютърен акаунт до данни на наблюдавания сървър.

Следващите стъпки с помощта на PowerShell

Искате ли да научите повече? Използвайте кода за отключване „blog“ за безплатен достъп до пълния видеокурс по PowerShell и Основи на Active Directory.

Източник: habr.com