Весной 2014 года директор по технической инфраструктуре Columbia Sportswear уволился и ушёл к ИТ-подрядчику. А в каталоге компании остался сотрудник Джефф Мэннинг, которого никогда не существовало. Под этой учётной записью бывший директор заходил в сеть ещё больше двух лет — по данным иска компании, больше 700 раз — и читал корпоративную почту, прежде всего тех, кто отвечал за закупку ИТ-оборудования. Обнаружили его случайно, при обновлении почтовой системы.

Это типовая «закладка», и при классическом подходе к аудиту, построенном на журналах событий, её появление может остаться незаметным для службы безопасности. В этой статье я расскажу, почему нельзя доверять журналам аудита и на что обратить внимание при защите служб каталогов.

Невидимые изменения в службах каталогов

История первая — про тех, кто знает инфраструктуру изнутри. Майкл Липер почти четырнадцать лет проработал в Columbia Sportswear и дорос до директора по технической инфраструктуре. Перед уходом он завёл в каталоге учётную запись jmanning для несуществующего сотрудника Джеффа Мэннинга с доступом по VPN и к виртуальным рабочим столам, а заодно расширил права сервисной учётной записи svcmon, которой давно никто не пользовался. Собственная учётная запись ему после этого была не нужна. Дальше — больше двух лет чтения почты ИТ-специалистов, отвечавших за закупки: подрядчику, где Липер стал техническим директором, очень помогало знать, что бывший работодатель собирается покупать. «Джеффа Мэннинга» нашли летом 2016 года, случайно, при обновлении почтовой системы. В декабре 2017-го Липер получил три года пробации и 400 часов общественных работ — без тюрьмы (DOJ; BleepingComputer; DataBreaches.net).

Та же техника, только грубее. Сотрудник службы поддержки производителя сапог Lucchese держал про запас «потайную» учётную запись администратора elplaser — по имени она выглядела как офисный лазерный принтер. 1 сентября 2016 года в 10:30 ему объявили об увольнении, а в 11:30 он под «принтером» остановил почтовый сервер и сервер приложений, удалил системные файлы и сменил пароли коллегам. Три сотни рабочих фабрики отправили по домам; сервер приложений пришлось собирать заново. Полтора года тюрьмы (DOJ; CNews).

В России сюжет тот же, разве что без громких приговоров. В апреле 2026 года ГК «Солар» описала атаку на российскую госорганизацию — по данным СМИ, медицинскую: злоумышленники больше полугода входили в сеть по корпоративному VPN под учётными записями давно уволенных сотрудников, которые никто не удалил. Служба ИБ замечала отдельные инциденты и устраняла их последствия, но учётные записи бывших сотрудников так и не удалила — и атакующие возвращались снова и снова. Полную картину восстановить не удалось: журналы VPN хранились всего несколько дней («Солар»; SecurityLab). По оценке экспертно-аналитического центра InfoWatch, около 25 % нарушений, которые в российских компаниях совершили уволившиеся или уволенные сотрудники, длились несколько месяцев — их просто не замечали (InfoWatch).

История вторая — про тех, кто снаружи и никуда не спешит. В сеть гостиничного оператора Starwood злоумышленники проникли в июле 2014 года: веб-шелл, затем средства удалённого управления и Mimikatz для сбора учётных данных из памяти серверов. Marriott купила Starwood в 2016 году и унаследовала атакующих вместе с инфраструктурой. Первое оповещение, относящееся к атаке, сработало только 7 сентября 2018 года — на подозрительный запрос к таблице с профилями гостей. Четыре года внутри, 339 млн записей о гостях. Британский регулятор ICO, разбирая инцидент, среди причин назвал недостаточный мониторинг привилегированных учётных записей и оштрафовал Marriott на 18,4 млн фунтов (ICO, Penalty Notice; Marriott).

В феврале 2024 года CISA, АНБ и ФБР выпустили совместный бюллетень о группировке Volt Typhoon, которую американские ведомства связывают с госструктурами КНР. Интересна в нём не атрибуция, а метод. Почти никакого вредоносного ПО — только штатные средства Windows и легитимные учётные данные. Копирование базы Active Directory (файла NTDS.dit) с контроллеров домена через теневые копии тома — то есть все учётные данные домена разом. И выборочная очистка журналов событий Windows, чтобы не оставлять следов. В некоторых сетях критической инфраструктуры США группировка сохраняла доступ не менее пяти лет (CISA, AA24-038A; Microsoft).

Российская статистика говорит о том же. По данным Positive Technologies за 2024–2025 годы, медианное время от начала инцидента до обнаружения — 9 дней, а самый долгий расследованный инцидент длился почти 3,5 года. В каждой пятой компании (21 %) злоумышленники скомпрометировали хотя бы один контроллер домена, годом ранее — почти в каждой третьей, а в одном проекте нашли сразу 11 скомпрометированных контроллеров (Positive Technologies, 2024–2025; Positive Technologies, 2023–2024). Solar 4RAYS в 2024 году выяснила, что группировка Cloud Atlas находилась в сети атакованной российской организации больше двух лет. В другом расследовании атакующие 19 месяцев медленно расползались по сегменту сети, не подключённому к мониторингу, и удаляли свои инструменты после использования — заметили их, только когда они добрались до сегмента под наблюдением (Solar 4RAYS, «Хроники DFIR»; Solar 4RAYS, Erudite Mogwai). Годы внутри — и никто не заметил!

Вопрос, который стоит задать: как так вышло, что за месяцы и годы в журналах не осталось ничего, за что можно зацепиться?

И сразу проверка лично для вас. Представьте: один из ваших администраторов домена прямо сейчас заводит своего «Джеффа Мэннинга» и очищает журнал безопасности. Останется ли у вас источник, по которому вы через полгода восстановите, что именно он сделал? Если уверенного «Да» нет — статья ровно об этом.

Инциденты обходятся дорого

Злоумышленник или обиженный администратор с действующей учётной записью — бомба замедленного действия: рано или поздно она взрывается — финансовым и репутационным ущербом. Marriott заплатила 18,4 млн фунтов штрафа одному только британскому регулятору — за атаку, которую за четыре года никто не заметил. Глобально IBM оценивает средний ущерб от утечки данных в 4,99 млн долларов — рекорд за всё время наблюдений, а среднее время «обнаружить и локализовать» выросло до 247 дней, впервые за пять лет (IBM, Cost of a Data Breach Report 2026; Help Net Security). Mandiant в M-Trends 2026 приводит медиану времени присутствия злоумышленника в мире — 14 дней против 11 годом ранее, а для кибершпионажа (и связанных с КНДР инцидентов с «ИТ-работниками») — 122 дня (Mandiant / Google Cloud, M-Trends 2026).

И это только инциденты, про которые мы знаем. «Закладка», которой ни разу не воспользовались, в такую статистику не попадает вообще — её нет ни в одном отчёте, потому что её никто не обнаружил.

Ключи от королевства и невидимки

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

А ведь служба каталогов — это ключи от королевства. Кто контролирует Active Directory, тот контролирует аутентификацию, доступ к файловым ресурсам, к почте, к бизнес-системам — ко всему. Именно поэтому она — главная цель злоумышленников: Volt Typhoon уносила с контроллеров домена всю базу учётных данных, Липер завёл в каталоге «сотрудника», а в каждой пятой компании из расследований Positive Technologies контроллер домена оказался скомпрометирован. Во многих случаях именно изменения в службе каталогов позволяют закрепиться в системе и безнаказанно копировать данные.

Слабое звено — сам источник данных

Классический SIEM работает по событиям. Кто-то добавил sIDHistory — сработало событие 4765. Изменили членство в группе — 4728, 4732, 4756. Модель понятная: собрали журналы, написали правила корреляции, поймали аномалию.

Проблема в самой природе события. Событие — это не само изменение в системе, а лишь запись о нём, которую делает подсистема аудита операционной системы. И делает она эту запись только при двух условиях: если аудит нужной операции заранее включён и если сама подсистема в тот момент отработала штатно. А значит:

• аудит можно не включить (многие нужные категории по умолчанию выключены);

• журнал можно переполнить и заставить перезаписаться — размер по умолчанию невелик;

• журнал можно очистить (wevtutil cl Security) или подделать метки времени;

• само событие может не сгенерироваться, если операция прошла в обход стандартного пути.

Это не теория. Positive Technologies в отчёте за 2024–2025 годы отмечает частичное или полное удаление злоумышленниками системных журналов — и штатными средствами, и специальными утилитами, подмену временных меток файлов и отключение антивирусов общедоступными инструментами. Volt Typhoon выборочно чистила журналы событий Windows, Erudite Mogwai удаляла свои инструменты после использования, а в госорганизации из отчёта «Солара» журналы VPN и без чьей-либо помощи жили всего несколько дней.

То есть источник, на который опирается SIEM, находится под контролем ровно того, за кем мы наблюдаем. Сотрудник службы безопасности смотрит на картинку со «скомпрометированной камеры», и на этой картинке никаких следов взлома — а в этот момент злоумышленники копируют всё ценное наружу. Чем не «Матрица»: на экране — спокойный привычный мир, а настоящая реальность спрятана за ним и совсем не такая уютная.

Отсюда вывод: нужна своя красная таблетка — источник, который фиксирует не «сообщение о факте», а сам факт: состояние каталога и его изменение.

DCShadow: изменение, которого не было

Отдельно стоит разобрать DCShadow — приём, который дальше в статье встретится не раз. Он показателен тем, что событие не очищают задним числом, а с самого начала не дают ему появиться.

Идея в том, чтобы изменить каталог не как администратор, а как контроллер домена. Обычная правка объекта на контроллере — это локальная запись (originating write), и именно она порождает события аудита: 5136 об изменении объекта, 4765 о добавлении sIDHistory и так далее. DCShadow (модуль Mimikatz lsadump::dcshadow, техника MITRE ATT&CK T1207) идёт другим путём. Имея права администратора домена, он на короткое время регистрирует в разделе конфигурации леса поддельный контроллер домена: создаёт объект nTDSDSA, дописывает нужные имена участников-служб (SPN) и атрибуты репликации — ровно то, по чему остальные контроллеры домена узнают «своего». После этого он инициирует репликацию и «отдаёт» подготовленное изменение — например, дописанный sIDHistory — как будто оно возникло на этом новом контроллере. Настоящие контроллеры принимают правку как штатную входящую репликацию от доверенного узла, а не как чью-то локальную запись. Закончив, атакующий удаляет следы поддельного контроллера из конфигурации (Netwrix; Picus Security).

Ключевое следствие для аудита: на контроллерах домена изменение приходит как репликация, а не как локальная запись — а значит, обычных событий аудита изменений каталога (того же 5136) для него не возникает вовсе. Чистить журнал не приходится: записи в нём просто не появляется. При этом версия и метаданные изменённого атрибута всё равно обновляются на всех контроллерах — иначе реплики разошлись бы. Поэтому DCShadow невидим для аудита по событиям и виден для аудита по состоянию каталога — а это ровно то различие, вокруг которого построена статья.

Надёжный аудит служб каталогов

Журналам аудита, как мы выяснили, доверять нельзя. Что же тогда делать администратору? Оттолкнуться от одного факта: любое действие в каталоге — это изменение самого каталога. «Джефф Мэннинг» — это новый объект, дописанный sIDHistory — новое значение атрибута. Запись в журнале об этом можно не создать или стереть, а само изменение — нет: оно лежит в базе и никуда из неё не денется. Значит, подозрительные следы можно искать прямо там — в объектах и атрибутах.

Почему изменение нельзя спрятать так же легко, как событие? Служба каталогов — это база данных с репликацией с несколькими хозяевами (multi-master replication): запись может внести любой контроллер домена. Любое изменение атрибута должно разойтись на остальные контроллеры домена, иначе их реплики рассинхронизируются. И вот на этом уровне остаются следы, которые убрать несопоставимо труднее, чем строчку в журнале.

Какие источники данных позволяют увидеть эти следы на уровне репликации? Их два.

Метаданные репликации

Для каждого атрибута каждого объекта контроллер домена хранит версию, метку времени последнего изменения и идентификатор того контроллера, где изменение возникло. Посмотреть можно встроенной утилитой repadmin (пример на условном стенде):

repadmin /showobjmeta DC01 "CN=jmanning,CN=Users,DC=corp,DC=local"

В выводе по строке sIDHistory будет видно: версия атрибута выросла, значит его меняли, вот когда и вот откуда. Даже если журнал безопасности вычищен подчистую, версия атрибута в метаданных останется — стереть её, не сломав репликацию, гораздо сложнее.

Метаданные репликации объекта jmanning: sIDHistory меняли — версия 2, вот когда (2026-09-03) и откуда (DC02); остальные атрибуты остались на версии 1 с даты создания. Данные стенда синтетические.

DirSync

Это элемент управления LDAP (LDAP control, LDAP_SERVER_DIRSYNC_OID), по которому контроллер домена отдаёт добавочный поток изменений с момента прошлого запроса. Клиент хранит cookie — маркер состояния синхронизации — и при следующем обращении получает только то, что изменилось. Механизм создавался для служб синхронизации, но для аудита он идеален: вы получаете реальный перечень изменений каталога независимо от того, включён аудит или нет.

Разница принципиальная — она в источнике данных. Классический SIEM оперирует производными артефактами — записями аудита, которые ещё требовалось сгенерировать и сохранить, то есть косвенными свидетельствами о событии. DirSync и метаданные репликации опираются на первичный источник — фактическое состояние объектов каталога и историю их изменений на уровне базы данных. В первом случае аналитик исследует свидетельства о том, что нечто произошло; во втором — само изменение объекта, зафиксированное службой каталогов.

Коротко, чем три источника отличаются по надёжности:

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

Как это выглядит на примере SID History

Закладка не обязана быть посторонней учётной записью. Есть вариант неприятнее — теневое повышение привилегий через атрибут sIDHistory.

Закрепим теорию практикой

Проверим сказанное на тестовом стенде. Понадобится PowerShell-модуль ActiveDirectoryFever (лицензия MIT) — он реализует оба источника, о которых шла речь: Get-ADDirSyncChange вычитывает изменения каталога через DirSync и хранит cookie между запусками; Get-ADUsnNumberUpdate отслеживает изменения по порядковому номеру обновления (USN, атрибут uSNChanged); Test-ADDomainControllerReplication и Test-ADDomainControllerDiagnostic — обёртки над repadmin и dcdiag.

Сценарий воспроизводит скрытое повышение привилегий при отключённом аудите и состоит из пяти шагов.

1. Зафиксировать исходное состояние. Первый вызов Get-ADDirSyncChange сохраняет cookie DirSync; далее инструмент возвращает только изменения, произошедшие после этой точки.

2. Отключить аудит (действие нарушителя). Команда wevtutil sl Security /e:false отключает журнал безопасности — новые события в SIEM больше не поступают.

3. Внести изменение в каталог (действие нарушителя). Команда Add-ADGroupMember -Identity "Domain Admins" -Members bobafett добавляет рядовую учётную запись в группу администраторов домена.

4. Проверить журнал и SIEM. Изменение должно было породить событие 4728 (добавление участника в привилегированную группу). Журнал отключён, поэтому Get-WinEvent по фильтру 4728 возвращает пустой результат — для SIEM изменения нет.

5. Запросить изменения из базы каталога. Повторный вызов Get-ADDirSyncChange считывает изменения от сохранённого cookie и возвращает добавление участника в группу Domain Admins — то, чего нет в журнале.

Журнал безопасности отключён и по фильтру 4728 пуст, но Get-ADDirSyncChange через DirSync показывает добавление пользователя в Domain Admins. Данные стенда синтетические.

В выводе инструмента присутствуют все атрибуты изменения: время, объект (CN=Domain Admins), тип операции (MEMBER-ADD) и добавленный участник. Журнал пуст, но факт изменения зафиксирован: версия и метаданные атрибута member реплицировались на все контроллеры домена, и удалить их оттуда несопоставимо труднее, чем запись в журнале.

Гигиена каталога и сокращение поверхности атаки

Надёжный источник данных решает лишь половину задачи. Вторая половина — знать, какие состояния службы каталогов являются подозрительными сами по себе. Для проверки состояния каталога можно применять бесплатные утилиты, например Purple Knight. Ниже приведены десять проверок, которые рекомендуется выполнять регулярно.

1. Права репликации каталога (DCSync) у нештатных субъектов. Расширенные права DS-Replication-Get-Changes и DS-Replication-Get-Changes-All на корне домена должны быть назначены только контроллерам домена и группам Domain Admins и Enterprise Admins. Наличие этих прав у иного субъекта позволяет выгрузить хеши паролей всех учётных записей, включая krbtgt, и сформировать поддельный билет Kerberos (Golden Ticket). (adsecurity: DCSync; MITRE T1003.006)

2. Изменения списков управления доступом на корне домена и на объекте AdminSDHolder. Список управления доступом объекта AdminSDHolder периодически копируется механизмом SDProp на все привилегированные объекты каталога. Нестандартная запись в этом списке или включённое наследование предоставляют нарушителю устойчивые права на привилегированные учётные записи, которые сохраняются даже после исключения его учётной записи из привилегированных групп. (adsecurity: AdminSDHolder & SDProp; Microsoft: Protected Accounts and Groups)

3. Значение атрибута sIDHistory вне процедур миграции. Непустой атрибут sIDHistory у рядовой учётной записи предоставляет ей права всех перечисленных в нём идентификаторов безопасности. Особую опасность представляет идентификатор привилегированной группы или SID другого домена, добавленный без выполнения миграции. (adsecurity: SID History; MITRE T1134.005)

4. Учётные записи с постоянными привилегиями. Необходимо контролировать число членов групп Domain Admins, Enterprise Admins и Schema Admins и исключать из них учётные записи, которым такие права не требуются. Отдельного внимания заслуживают компьютерные учётные записи и внешние субъекты безопасности (Foreign Security Principal) в составе этих групп. (Microsoft: привилегированные группы; Microsoft: наименьшие привилегии)

5. Опасные права в списках управления доступом (ACL) на объектах каталога. Права GenericAll, WriteDacl, WriteOwner, ForceChangePassword или право на запись атрибута member, назначенные нештатному субъекту на привилегированной учётной записи, группе или на корне домена, позволяют нарушителю сбросить пароль, добавить себя в группу или сменить владельца объекта, то есть скрытно повысить привилегии и закрепиться. (SpecterOps: An ACE Up the Sleeve; harmj0y: Abusing AD Permissions with PowerView)

6. Небезопасное делегирование Kerberos. Флаг TRUSTED_FOR_DELEGATION (неограниченное делегирование), заполненный атрибут msDS-AllowedToDelegateTo (ограниченное делегирование) и атрибут msDS-AllowedToActOnBehalfOfOtherIdentity (ресурсное делегирование, RBCD) позволяют выполнить олицетворение (impersonation) вплоть до учётной записи контроллера домена. (Elad Shamir: Wagging the Dog (RBCD); harmj0y: Another Word on Delegation)

7. Имена субъектов-служб (SPN) у пользовательских учётных записей (Kerberoasting). Непустой атрибут servicePrincipalName у обычной пользовательской учётной записи (кроме gMSA) позволяет любому субъекту домена запросить сервисный билет и подобрать пароль в автономном режиме, особенно при использовании алгоритма RC4. (adsecurity: Kerberoast; harmj0y: Kerberoasting без Mimikatz)

8. Срок действия пароля учётной записи krbtgt. Пароль krbtgt шифрует все билеты Kerberos в домене, поэтому его редкая смена создаёт предпосылку для атаки Golden Ticket. Необходимо контролировать значение атрибута pwdLastSet и менять пароль по регламенту, а после компрометации — дважды подряд. (adsecurity: Golden Ticket; Microsoft: сброс пароля krbtgt)

9. Опасные значения атрибута userAccountControl. Флаги DONT_EXPIRE_PASSWD (пароль без срока действия), PASSWD_NOTREQD (пароль не требуется), DONT_REQ_PREAUTH (отключена предварительная аутентификация Kerberos, что открывает атаку AS-REP Roasting) и ENCRYPTED_TEXT_PWD_ALLOWED (обратимое шифрование пароля) приводят к долгоживущим, пустым или фактически открытым паролям. (Microsoft: флаги userAccountControl; harmj0y: Roasting AS-REPs)

10. Отключённые и неиспользуемые учётные записи. Заблокированная, но не удалённая учётная запись остаётся плацдармом для нарушителя, а незаблокированная учётная запись уволенного сотрудника — готовой точкой входа, как в госорганизации из отчёта «Солара». Необходимо контролировать значение атрибута LastLogonTimestamp и своевременно отключать и удалять неактивные учётные записи. (MITRE T1078: Valid Accounts; Microsoft: неактивные учётные записи)

Тот же Purple Knight содержит свыше 180 индикаторов — от постороннего sIDHistory до небезопасного делегирования и устаревших протоколов.

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

Сократите поверхность атаки с помощью PAM

Надёжный аудит отвечает на вопрос, что уже произошло. Однако предпочтительнее не допустить инцидент вовсе. Обе истории из начала статьи объединяет общая причина: у отдельных субъектов слишком долго сохранялись постоянные права администратора. Липер смог завести «Джеффа Мэннинга», поскольку отвечал за ИТ-инфраструктуру и обладал соответствующими полномочиями; группировка Volt Typhoon и нарушители в сети Starwood годами действовали на легитимных учётных данных с высокими привилегиями.

Сократить поверхность атаки помогает управление привилегированным доступом (privileged access management, PAM). Его задача — отказаться от постоянных привилегий в пользу предоставления доступа по требованию.

• Предоставление доступа по требованию (just-in-time, JIT). Права администратора выдаются не бессрочно, а под конкретную задачу и на ограниченное время, после чего автоматически отзываются. Постоянная учётная запись администратора домена, которую можно скрытно клонировать через sIDHistory, при таком подходе отсутствует.

• Многофакторная аутентификация при повышении привилегий. Даже при компрометации пароля нарушитель не получит привилегии без второго фактора аутентификации.

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

PAM не заменяет аудит службы каталогов, а дополняет его: аудит фиксирует уже внесённые изменения, а PAM сокращает интервал, в течение которого изменение вообще возможно. Совместно они обеспечивают и обнаружение, и предотвращение.

Выводы

Только на событиях в журналах надёжный аудит не построить. Аудит службы каталогов стоит строить на «низкоуровневых источниках»: DirSync, метаданные репликации, USN. В дополнение обязательна регулярная проверка «подозрительных по своей природе» состояний — например, неактивных учётных записей, sIDHistory в домене без миграции, подозрительных учётных записей с членством в привилегированных группах. И параллельно — сокращение самих постоянных привилегий через PAM с доступом по требованию и вторым фактором, чтобы у злоумышленника было меньше шансов закрепиться.

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

Всё описанное — про оборону и обнаружение. Реальные случаи приведены по открытым материалам судов, регуляторов и отчётам исследователей; техники атак — концептуально и со ссылками на публичные разборы. Проверяйте их только на своих стендах и в рамках закона.

Иллюстрации к статье сгенерированы нейросетью (ChatGPT).

Источники