CyberSecrets

Права на добавление дочерних объектов в OU

2026-08-14T07:15:00.009Z

Права CreateChild на OU позволяют создавать объекты в этой OU и в зависимости от настроек наследования в других дочерних OU. С правами CreateChild была связана уязвимость BadSuccessor (CVE-2025-53779), в которой эти права использовались для создания объекта dMSA. Но на своей практике я не встречал контроллеры домена на Windows Server 2025, да и сама уязвимость уже имеет патч.

BloodHound не показывает таких связей, но можно воспользоваться ADACLScanner и посмотреть какие группы и пользователи имеют права CreateChild на OU.

Я пошел другим путем и написал скрипт Find-CreateChildACE.ps1, который находит все OU в домене и извлекает права CreateChild для типов объектов компьютер, пользователь или любой. И в результате составляет Cypher запросы для добавления новой связи CanCreateChild.

После использовании скрипта и добавления информации в BloodHound можно выполнять Cypher запросы:

MATCH p=(m:User)-[r:CanCreateChild]->(n) RETURN p

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

Сценариев использования прав CreateChild не так много, например, вы обнаружили, что группе доменных компьютеров разрешен доступ на сервер с правами локального администратора, а MachineAccountQuota равен 0, но у вас есть учетная запись с правами CreateChild на OU. Вы можете создать объект компьютер в этой OU и использовать ее для получения доступа.

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

Создаем объект компьютер в OU с помощью ADSI:

$ou = [ADSI]"LDAP://OU=Resources,OU=Company,DC=domain,DC=local"
$newComp = $ou.Create("computer", "CN=comp")
$newComp.Put("sAMAccountName", "comp$")
$newComp.Put("userAccountControl", 4096)
$newComp.SetInfo()

Этими командами мы создаем объект компьютер, но мы не знаем от него пароля. Если попытаться добавить команду на установку пароля сразу при создании появится ошибка, что такого объекта не существует. Так что установим пароль следующими командами:

$newComp.SetPassword("NewSecurePassword123!")
$newComp.SetInfo()

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

При установке пароля или изменении атрибутов может возникнуть ошибка об отсутствии прав на объект. Так как мы являемся владельцем объекта у нас есть права на изменение прав доступа. Так же воспользуемся ADSI:

$comp = [ADSI]"LDAP://CN=comp,OU=Resources,OU=Company,DC=domain,DC=local"
$comp.psbase.Options.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl
$secDescriptor = $comp.psbase.ObjectSecurity
$IdentityReference = (New-Object System.Security.Principal.NTAccount("svc_backup")).Translate([System.Security.Principal.SecurityIdentifier])
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($IdentityReference,"GenericAll","Allow")
$secDescriptor.AddAccessRule($ace)
$comp.psbase.CommitChanges()

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

#внутрянка

#activedirectory

Маркировка путей компрометации в BloodHound

2026-07-23T07:04:45.107Z

При проведении пентеста Active Directory мы часто сталкиваемся с задачей наглядно показать заказчику, какие именно цепочки атаки использовались от исходной точки до администратора домена. BloodHound отлично визуализирует граф атак, но по умолчанию не даёт возможности «запомнить» конкретные ребра, которые мы использовали в своей атаке. А ведь именно эти ребра — ключевые шаги, которые мы хотим продемонстрировать в отчете: чтобы заказчик видел не просто абстрактные пути, а реальную цепочку действий, которую мы воспроизвели.

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

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

MATCH p=AllShortestPaths((m:Group {name:"AUTHENTICATED USERS@DOMAIN.LOCAL"})-[*]->(n:Domain {name:"DOMAIN.LOCAL"}))
WHERE ALL(x IN relationships(p) WHERE x.is_traversable = TRUE)
WITH p, relationships(p) AS rels
UNWIND rels AS rel
SET rel.is_killchain = TRUE

В этом запросе используется is_traversable = TRUE, чтобы не перечислять все проходимые ребра. Затем используем функцию UNWIND, чтобы получить из пути все связи и с помощью SET устанавливаем значения для нового свойства.

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

MATCH p=(n)-[r]->(m) WHERE r.is_killchain = TRUE RETURN p

Результат запроса

Мы можем экспортировать полученный граф в виде изображения для вставки в отчет. Вместе с описанием каждого шага (например, «пользователь A входит в группу B», «группа B имеет право на компьютер C» и т.д.) получается наглядная иллюстрация всей цепочки атаки. Это значительно упрощает общение с заказчиком: он видит не просто список уязвимостей, а конкретный сценарий, который мы воспроизвели, и понимает, какие меры нужно принять для закрытия каждого шага.

При желании мы можем расширить набор свойств — добавить, например, killchain_order для нумерации шагов или killchain_description с кратким пояснением, что делает каждый шаг. Это делает отчет еще более информативным и профессиональным.

Таким образом, простое пользовательское свойство превращает BloodHound из инструмента разведки в полноценное средство документирования и демонстрации путей атак, что особенно ценно при подготовке отчетов для клиентов.

#bloodhound

#внутрянка

#cypher

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

2026-07-09T08:32:30.360Z

Если в GPO на добавление членов в локальные группы через Group Policy Preferences не указан SID, то это позволяет выполнить технику GPP Hijacking и получить привилегии той локальной группы, которая указана в GPO. Подробнее можно почитать в статье.

Для реализации этой техники нам требуется возможность изменять атрибут samaccountname у пользователя или группы, компьютеры не подходят так как уже реализована защита от noPac. По условию задачи у нас есть такая учетная запись USER-456.

Однако, прежде чем менять атрибут нам необходимо заполучить саму учетную запись USER-456. В условии задачи ничего не сказано про ADCS и отключении PKINIT, предполагаем, что ADCS есть и выполняем технику ShadowCredentials. В отдельном окне запрашиваем TGT билет Kerberos для учетной записи USER-456.

Если PKINIT нет, тогда можно выполнить технику таргетированного Kerberoasting или ASReproasting.
В случае успешного получения любых учетных данных для пользователя USER-456, мы меняем samaccountname на ws_admin_ws-567. Параметр %ComputerName% принимает название машины и если в домене нет такого samaccountname для пользователя или группы, то мы получим права локального администратора на этом хосте после обновления групповых политик.

Получаем доступ на хост WS-567 с правами локального администратора. Делаем дамп TGT билета Kerberos для учетной записи ADM_PETROV, выполняем технику Pass-the-Ticket и получаем привилегии SERVER ADMINS. Задача решена.

Для поиска GPO, которые потенциально подвержены технике GPP Hijacking я написал простой скрипт.

Результат поиска GPPHijacking в GPO

#внутрянка

#задачи

Задача для собеседования #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.

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