CyberSecrets

Задача для собеседования #7

2026-07-02T07:49:48.911Z

Задача с несколькими входящими данными, на мой взгляд достаточно интересная.

Сценарий

После сбора информации обнаружилось, что группа AUTHENTICATED USERS имеет права GenericWrite на пользователя USER-456. Сам пользователь не обладает никакими значимыми правами и доступами.

Изучение групповых политик показало, что существует групповая политика WS LOCAL ADMIN с интересной записью.

Сама политика применяется WS LOCAL ADMIN к OU WORKSTATION, в которую входит рабочая станция WS-567. На этой рабочей станции есть сессия пользователя ADM_PETROV, входящего в группу SERVER ADMINS.

Дополнительные условия

Есть доменная учетная запись PENTESTER.
На всех хостах в сети установлены последние обновления.
Настройки по умолчанию.
Уровень домена – 2016.

Цель

Получить привилегии группы SERVER ADMINS.

Tag_Tier_Zero и не только

2026-06-25T07:49:14.230Z

Добавление меток (label) или определенных свойств узлам позволяют группировать узлы по общему признаку и использовать их в запросах Cypher вместо общего перечисления. Так, например, для всех рабочих станций можно добавить метку "Workstation", а для всех серверов "Server" и в зависимости от потребностей использовать эти метки в запросах.

Эволюция таких меток в BloodHound была следующей: в BloodHound Legacy использовались свойства "n.highvalue" для определения узлов с высокими привилегиями "n.owned" – скомпрометированный узел, в BloodHound CE начали использовать свойство "n.system_tag", в которой прописывались метки "admin_tier_0" для привилегированных групп и "owned" для скомпрометированных. С конца июля 2026 года будет использоваться только метки "Tag_Tier_Zero" и "Tag_Owned". Это связанно с тем, что индексированные метки работают быстрее.

Если вы следите за обновлениями BloodHound CE учитывайте это в своих собственных Cypher запросах. Можно использовать универсальный подход в запросах:

((n:Tag_Tier_Zero) OR COALESCE(n.system_tags, '') CONTAINS 'admin_tier_0' OR n.highvalue = TRUE)

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

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

Добавим новые метки "Tag_Tier_One" и "Tag_Tier_Two", но для начала добавим новые индексы:

CREATE INDEX IF NOT EXISTS FOR (n:Tag_Tier_One) ON (n.objectid);
CREATE INDEX IF NOT EXISTS FOR (n:Tag_Tier_One) ON (n.name);
CREATE INDEX IF NOT EXISTS FOR (n:Tag_Tier_Two) ON (n.objectid);
CREATE INDEX IF NOT EXISTS FOR (n:Tag_Tier_Two) ON (n.name);

Итак, метки определены теперь нужно найти объекты, на которые можно эти метки установить. Делаем запрос на поиск всех групп, у которых в имени есть ADMIN, но исключаем "Tag_Tier_Zero" и выводим имя и описание:

MATCH (g:Group) WHERE g.name CONTAINS 'ADMIN'
AND NOT ((g:Tag_Tier_Zero) OR COALESCE(g.system_tags, '') CONTAINS 'admin_tier_0' OR g.highvalue = TRUE)
RETURN g.name, g.description

Поле description может нам помочь определить к какому уровню относится та или иная группа. А так по имени определяем уровень и устанавливаем новую метку, например мы нашли две группы SERVER_ADMINS и WORKSTATION_ADMINS.

MATCH (g1:Group) WHERE g1.name STARTS WITH 'SERVER_ADMINS' SET g:Tag_Tier_One
MATCH (g2:Group) WHERE g2.name STARTS WITH 'WORKSTATION_ADMINS' SET g:Tag_Tier_Two

Добавим членам группы SERVER_ADMINS ту же метку.

MATCH (u:Base)-[r:MemberOf*1..]->(g:Tag_Tier_One) SET u: Tag_Tier_One

Теперь можно использовать эти метки при построении путей, включать или исключать. Например, мы хотим посмотреть есть ли у нас короткие пути от группы доменных пользователей до группы доменных администраторов минуя все "Tag_Tier_One" узлы:

MATCH p=AllShortestPaths((m:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[*]->(n:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}))
WHERE ALL(x IN relationships(p) WHERE x.is_traversable = TRUE)
AND NONE(x in nodes(p) WHERE x:Tag_Tier_One)
RETURN p

В этом запросе используется is_traversable = TRUE, чтобы не перечислять все проходимые ребра.

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

#bloodhound

#внутрянка

#cypher

Фильтрация локальных групп в BloodHound

2026-06-11T07:07:33.087Z

В статье мы определили, что есть проходимые и непроходимые связи. Ребра локальных групп LocalToComputer и MemberOfLocalGroup являются непроходимыми. Исключая их мы можем потерять интересные маршруты. Исправим эту ситуацию.

Добавим к нашему запросу, состоящему из проходимых ребер, эти два ребра:

MATCH p=AllShortestPaths((m:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[r: AddMember|AddSelf|AdminTo|…|WriteSPN|LocalToComputer|MemberOfLocalGroup*1..]->(n:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}))
RETURN p

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

MATCH (c)-[r:MemberOfLocalGroup]->(b) WHERE b.objectid =~ '(?i).*(-568|-545)' WITH collect (b) AS excludeGroup
MATCH p=AllShortestPaths((m:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[r: AddMember|AddSelf|AdminTo|…|WriteSPN|LocalToComputer|MemberOfLocalGroup*1..]->(n:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}))
WHERE NONE(x in nodes(p) WHERE x IN excludeGroup)
RETURN p

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

В результате мы получим более эксплуатируемых граф.

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

Если вы используете свойство is_traversable, то нам нужно добавить условие, что в запросе могут быть ребра LocalToComputer и MemberOfLocalGroup. И мы все также исключаем узлы с локальными группами из запроса.

MATCH (c)-[r:MemberOfLocalGroup]->(b) WHERE b.objectid =~ '(?i).*(-568|-545)' WITH collect (b) AS excludeGroup
MATCH p=AllShortestPaths((m:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[*]->(n:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"})) 
WHERE ANY(x IN relationships(p) WHERE x.is_traversable = TRUE OR type(x) = "LocalToComputer" OR type(x) = "MemberOfLocalGroup") 
AND NONE(x in nodes(p) WHERE x IN excludeGroup)
RETURN p

Таким образом добавление непроходимых ребер для локальных групп и фильтрация по этим группам могут предоставить интересные маршруты для проведения работ.

Создаем локальные боксы Vagrant для GOAD

2026-06-04T08:02:38.308Z

Я много слышал про GOAD, но никогда не разворачивал. И вот решил посмотреть, что это такое в живую. Однако существует проблема Hashicorp запрещает доступ к образам с российских IP адресов. У меня нет возможности выкачивать несколько гигабайт через VPN, однако есть возможность скачать приложения vagrant и packer. Сегодня я расскажу, как с помощью них можно создать локальные боксы Vagrant для GOAD.

У меня локальная лаборатория на Windows с использованием VirtualBox в качестве гипервизора. Но техника будет работать и для VMWare со своими особенностями. Для самого GOAD я использовал WSL, но сейчас он нам не нужен. Скачиваем и устанавливаем приложение Vagrant с официального сайта. Клонируем GOAD из репозитория. Скачиваем Packer с официального сайте Hashicorp и распаковываем исполняемый файл в «\GOAD\packer\vagrant\».

Для взаимодействия Packer с приложениями Vagrant и VirtualBox необходимо установить плагины:

.\packer.exe plugins install github.com/hashicorp/virtualbox .\packer plugins install github.com/hashicorp/vagrant

Для Vagrant тоже нужно установить несколько плагинов, возможно, не все они требуются для Packer, но для GOAD точно нужны:

vagrant-reload
micromachine
vagrant-vbguest
nori
winrm
winrm-fs
winrm-elevated

Чтобы не обращаться к сайту Hahicorp для установки плагинов пойдем на сайт https://rubygems.org и скачаем локально все необходимые плагины. Теперь чтобы установить плагины нужно выполнить команду для каждого файла:

vagrant.exe plugin install --plugin-clean-sources <plugin_name>.gem

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

vagrant.exe plugin list

Список установленных плагинов Vagrant

Мы готовы к созданию боксов.

Авторы GOAD предоставили все необходимые конфигурационные файлы в «\GOAD\packer\vagrant\» осталось только запастись терпением. В GOAD в основном используется Windows Server 2019 поэтому начну с него. Необходимо выполнить команду:

.\packer.exe build --only=virtualbox-iso windows_2019.json

Packer самостоятельно скачает образ Windows Server 2019 и запустит автоматическую настройку. Если во время загрузки происходит обрыв связи, то можно открыть файл «windows_2019.json» внизу файла будет ссылка на загрузку и можно скачать образ обычным способом и тогда запуск команды немного измениться. Я специально переименовал ISO файл чтобы он был короче.

.\packer.exe build --only=virtualbox-iso --var iso_url=Windows_Server_2019.iso windows_2019.json

Если вы хотите использовать собственные ISO файлы нужно прописать ключи в «Autounattend.xml» в директории «answer_files», там есть целый блок, описывающий как это сделать. Но ознакомительной версии Windows достаточно для лаборатории.

Дожидаемся, когда завершится процесс сборки бокса, у меня со всеми обновлениями заняло около двух часов. Теперь необходимо добавить бокс в локальное хранилище Vagrant. Чтобы не менять конфигурационный файлы для лабораторий имя бокса взято из файла «GOAD\ad\<lab>\providers\virtualbox». Хотя для некоторых лабораторий придется менять Vagrantfile чтобы установить версию "0" иначе будут попытки скачать бокс из Интернета.

vagrant.exe box add /path/to/file.box --name "StefanScherer/windows_2019"

Чтобы проверить, что наш бокс попал в локальное выполним команду:

vagrant.exe box list

Локальное хранилище боксов Vagrant

Локальное хранилище находиться в профиле пользователя в директории «vagrant.d»

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

Еще раз повторюсь для VMWare будет таже самая история, но нужен другой плагин Packer для взаимодействия c VMWare и в команде build измениться название гипервизора.

Решение задачки #6

2026-05-28T07:35:05.235Z

Итак, у нас есть доменная учетная запись PENTESTER, с помощью которой мы можем обращаться к контроллеру домена. Есть сервисная учетная запись учетная запись SVC_SQL с SPN, и мы можем выполнить технику "Kerberoasting". Однако по условиям задачи на эту учетную запись установлен сложный пароль и перебор пароля если и возможен, то займет много времени.

Так же мы видим, что группа доменных компьютеров владеет сервером SRV-SQL-01. Это означает, что владелец объекта может назначать любые права для объекта SRV-SQL-01. Но для этого требуется учетная запись компьютера.

По условию задачи все настройки установлены по умолчанию. А значит создаем объект компьютер и с помощью него назначаем себе любые привилегии на SRV-SQL-01. Для удобства "GenericAll".

Назначив права, нам необходимо получить доступ на хост. Выбираем технику между "Shadow Credentials" и "RBCD". Пароль сбросить мы не можем так, как в этом случае машина «выпадет» из домена.

После получения доступа на хост с правами локального администратора, делаем дамп LSA и извлекаем из него секреты. В результате мы получим пароль от сервисной учетной записи SVC_SQL в открытом виде. И таким образом у нас есть права доменного администратора.

Задача для собеседования #6

2026-05-21T09:49:22.256Z

Простой сценарий на понимание как работают службы в Windows.

Сценарий

В ходе сбора информации мы обнаружили, что есть сервисная учетная запись SVC_SQL от имени, которой запускается служба MsSQL на сервере SRV-SQL-01. Сама учетная запись SVC_SQL является членом группы DOMAIN ADMINS и у нее есть SPN. Так же было обнаружено, что доменная группа DOMAIN COMPUTERS является владельцем сервера SRV-SQL-01.

Дополнительные условия

Есть доменная учетная запись PENTESTER.
Сложный пароль для сервисной учетной записи SVC_SQL.
На всех хостах в сети установлены последние обновления.
Настройки по умолчанию.
Уровень домена – 2016.

Цель

Получить привилегии доменного администратора.

Решение будет через пару дней.

Проходимые и непроходимые связи в BloodHound

2026-05-12T07:48:53.168Z

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

В этом случае надо фильтровать связи в самом Cypher запросе при построении коротких путей. Рассмотрим два варианта Cypher запросов. В перовом варианте указываем все интересующие связи в квадратных скобках и в конце добавляем бесконечное число прыжков:

MATCH p=AllshortestPaths((c:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[r:GenericAll|GenericWrite|DCSync|...*1..]->(v:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"})) RETURN p

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

MATCH p=AllshortestPaths((c:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[*]->(v:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"})) WHERE NONE(x IN relationships(p) WHERE type(x)='CrossForestTrust' OR type(x)='DelegatedEnrollmentAgent' OR ...) RETURN p

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

Разработчики BloodHound разделяют ребра (связи) графа на два типа: проходимые (traversable) и непроходимые (non-traversable). Первый тип позволяет захватывать конечный узел в графе, второй тип – это связи, которые могут не предоставлять захват конечного узла в графе.

Зная какие связи являются проходимыми к ним можно добавить свойство is_traversable и установить значение TRUE. Чтобы не писать вручную каждый Cypher запрос напишем простой ps-скрипт, который сгенерирует нам Cypher запросы на добавление свойства для каждой связи:

$relationships = @("AbuseTGTDelegation","ADCSESC1","ADCSESC10a","ADCSESC10b","ADCSESC13","ADCSESC3","ADCSESC4","ADCSESC6a","ADCSESC6b","ADCSESC9a","ADCSESC9b","AddAllowedToAct","AddKeyCredentialLink","AddMember","AddSelf","AdminTo","AllExtendedRights","AllowedToAct","AllowedToDelegate","CanPSRemote","CanRDP","ClaimSpecialIdentity","CoerceAndRelayNTLMToADCS","CoerceAndRelayNTLMToLDAP","CoerceAndRelayNTLMToLDAPS","CoerceAndRelayNTLMToSMB","CoerceToTGT","Contains","CrossForestTrust","DCFor","DCSync","DumpSMSAPassword","ExecuteDCOM","ForceChangePassword","GenericAll","GenericWrite","GoldenCert","GPLink","HasSIDHistory","HasSession","HasTrustKeys","ManageCA","ManageCertificates","MemberOf","Owns","OwnsLimitedRights","ReadGMSAPassword","ReadLAPSPassword","SameForestTrust","SpoofSIDHistory","SQLAdmin","SyncedToADUser","SyncedToEntraUser","SyncLAPSPassword","WriteAccountRestrictions","WriteDacl","WriteGPLink","WriteOwner","WriteOwnerLimitedRights","WriteSPN")

foreach($relationship in $relationships){

Write-Host "MATCH(m)-[r:$relationship]->(n) SET r.is_traversable = TRUE;"

}

После выполнения вставим все эти запросы в базу neo4j через browser neo4j.

Название свойства is_traversable взято из документации по OpenGraph, но в самом BloodHound CE данное свойство не используется, и запросы строятся перечислением всех проходимых связей.

Теперь чтобы воспользоваться новым свойством связи изменим наш поиск коротких путей на:

MATCH p=AllshortestPaths((c:Group {name:"DOMAIN USERS@DOMAIN.LOCAL"})-[*]->(v:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"})) WHERE ALL(x IN relationships(p) WHERE x.is_traversable = TRUE) RETURN p

В этом запросе мы просто говорим neo4j, что у всех связей в пути должно быть свойство is_traversable в значении TRUE.

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

Аналогично можно сделать с непроходимыми связями просто изменив набор на непроходимые связи и поставить значение свойства is_traversable в FALSE.

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