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

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

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

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

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

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

Стъпка 1 Обратно DNS разрешаване с PowerShell

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

В нашия случай атакуващият започва да извършва мрежово разузнаване с помощта на скрипт на PowerShell, като последователно обикаля мрежовото IP адресно пространство, опитвайки се да определи дали даден IP разрешава към хост и ако е така, какво е мрежовото име на този хост.
Има много начини за изпълнение на тази задача, но с помощта на cmdlet Вземи-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 хост и целеви дял, можем да изпълним PowerShell скрипт, за да получим ACL. Можем да направим това от локалната машина, тъй като вече имаме права на локален администратор:

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

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

От него виждаме, че групата Domain Users има достъп само до листинга, но групата 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: Откриване на тази атака

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

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

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

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

Искате ли да знаете повече? Използвайте кода за отключване на "блог" за безплатен достъп до пълния Видеокурс за PowerShell и основи на Active Directory.

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