15 липня 2025 року компанія Netwrix сформувала власну профільну команду з аналізу безпеки. Її очолив Huy Kha, директор з питань аналізу безпеки. До складу команди входить експерт з безпеки Darryl Baker – визнаний фахівець у сфері безпеки Active Directory та облікових записів. Експертиза команди охоплює аналіз загроз для облікових записів, безпеки даних, штучного інтелекту та хмарних середовищ. Головна мета полягає у перетворенні результатів аналітики на практичні вдосконалення всієї лінійки продуктів Netwrix. Цього кварталу команда аналітиків об’єднала зусилля з командою PingCastle для розширення охоплення перевірок Entra ID, а також із командою Threat Manager для інтеграції додаткових механізмів виявлення загроз, зокрема вразливостей ADCS.
Результати роботи цієї команди є основою для квартального звіту Netwrix Threat Lab. Кожен випуск охоплюватиме ключові новини та результати аналізу безпеки облікових записів за квартал, оригінальні знахідки експертів Netwrix, а також пояснення практичного значення цієї інформації для команд, відповідальних за безпеку облікових записів та AD.
Виявлення застарілих та примарних SPN до того, як це зроблять зловмисники
Автор: Huy Kha
Вступ
Протягом останніх кількох років зросла кількість атак на Active Directory, пов’язаних зі зловживанням іменами учасників служби (SPN). Усе почалося з Kerberoasting, але відтоді методи стали витонченішими. Атаки з використанням примарних SPN дають змогу підвищувати привілеї шляхом захоплення цільових служб, які вже не використовуються. Віднедавна атаки через колізії Unicode у SPN дозволяють будь-якому автентифікованому користувачеві з правами на запис SPN також підвищувати привілеї, застосовуючи для цього лише візуально ідентичне, але технічно відмінне SPN.
Існує також менш помітна проблема, якій приділяють замало уваги – базова гігієна безпеки. Експерти Netwrix постійно спостерігають одну й ту саму тенденцію, незалежно від розміру організації. Облікові записи комп’ютерів залишаються активними в Active Directory ще довго після виведення відповідної машини з експлуатації. Облікові записи служб зберігають SPN, які досі вказують на хости, що більше не існують. Ніхто не проводить видалення, тому такий обліковий запис просто залишається в системі – досі активний, досі вразливий до Kerberoasting, і залишений поза будь-якою увагою.
Пошук прихованих SPN у доменах
Команда експертів з безпеки вирішила створити інструмент, який би спростив це завдання для фахівців з ІТ та адміністраторів. Скрипт PowerShell під назвою Find-StealthSPNs. Він виконує пошук прихованих SPN як в облікових записах комп’ютерів, так і користувачів. Це дозволяє переглянути результати та визначити, що саме потребує видалення.
Виконання скрипта відбувається у два основні етапи. Під час першого етапу перевіряється кожен обліковий запис комп’ютера в лісі. Оскільки кожна приєднана до домену машина за замовчуванням реєструє щонайменше одне SPN, на цьому етапі перевіряється, чи власне ім’я хоста цього комп’ютера досі розпізнається у DNS, і чи не вказують якісь із його SPN на хости, яких більше ніде не існує. Таке явище називається примарним SPN – це запис, який досі залишається прив’язаним до облікового запису, формально є дійсним, але не вказує на жоден реальний об’єкт. Також виявляються облікові записи комп’ютерів, які були попередньо створені в AD, але так і не були приєднані до домену. Такі записи часто взагалі не мають SPN і можуть непомітно залишатися в системі на невизначений термін.
Ця перевірка навмисно виконується через DNS, а не за допомогою пінгів ICMP. Деякі адміністратори покладаються на пінг, щоб швидко зрозуміти, чи досі активний хост, прив’язаний до SPN. Проте протокол ICMP настільки часто блокується фаєрволами та фільтрами на рівні хоста в більшості середовищ, що відсутність відповіді на пінг насправді є неінформативною. Відсутність запису DNS – це значно надійніший сигнал того, що жодна система більше не очікує існування цього імені хоста, незалежно від того, чи відповіла б сама машина на пінг.
Другий етап
Другий етап охоплює облікові записи користувачів, зокрема ті, що містять SPN, оскільки це класичне налаштування для облікових записів служб. Для кожного знайденого SPN виконується подвійна перевірка: чи досі існує відповідний обліковий запис комп’ютера в AD, і чи досі це ім’я хоста розпізнається у DNS. Якщо обидві умови не виконуються – це найчіткіший індикатор того, що SPN є «мертвим вантажем». Обліковий запис залишається активним, SPN – зареєстрованим, і він досі настільки ж вразливий до атак Kerberoasting, як і раніше, але тепер від нього більше не залежить жоден обґрунтований процес.
Крім того, скрипт також перевіряє наявність колізій Unicode у SPN – типу атаки, про який згадувалося раніше. Спеціально створений запис SPN може візуально збігатися зі справжнім, але насправді мати абсолютно інше приховане значення.
Відбувається маркування будь-яких записів SPN із прихованими або схожими символами. Також виконується перехресна перевірка кожного SPN у лісі. Це дає змогу виявити випадки, коли два облікові записи візуально містять однакові значення. Оскільки під час цього процесу можливі хибнопозитивні спрацьовування, перед виконанням будь-яких дій результати завжди потребують додаткової перевірки.
Уся робота виконується виключно за допомогою ADSI та DirectorySearcher, тому відсутня залежність від модуля PowerShell ActiveDirectory. Скрипт працює в усіх доменах лісу, а не лише в тому, з якого ініційовано запуск.
Коротка примітка щодо розпізнавання DNS: цей скрипт перевіряє DNS за допомогою того резолвера, який налаштовано на машині, з якої здійснюється запуск. Для отримання більш точних результатів запуск варто виконувати з контролера домену, а не з робочої станції. Це потрібно, тому що контролери домену вже налаштовані на розпізнавання кожного домену в середовищі. Запуск із машини з нестандартними або обмеженими налаштуваннями DNS може призвести до хибнопозитивних результатів MISSING_DNS для записів, які існують насправді.
Висновок
У кінцевому підсумку, головна мета полягає в тому, щоб допомогти організаціям зменшити поверхню атаки шляхом видалення застарілих облікових записів, які більше не відстежуються. Кожне примарне SPN, кожен активний обліковий запис комп’ютера, прив’язаний до машини, якої давно немає, кожен обліковий запис служби, що досі вказує на хост, якого не існує – усе це зайві елементи в Active Directory, яких там просто не повинно бути. Експлуатація таких недоліків не вимагає високого рівня кваліфікації. Достатньо лише того, щоб зловмисники помітили їх раніше за команду захисту.
Аспект безпеки облікових записів на DEF CON 34
Автор: Darryl Baker
Конференції DEF CON 34 та Black Hat USA 2026 представили три окремі аналітичні звіти, які безпосередньо стосуються інфраструктури облікових записів. Нижче наведено огляд того, що було анонсовано в кожному з них, і що це означає для фахівців, які керують програмами захисту облікових записів та AD.
CloudBasher: перетворення безкоштовних Cloud Shell на інфраструктуру зловмисників
Jenko Hwong та Chris Ryan представили CloudBasher – набір інструментів із відкритим кодом, створений шляхом зворотного проєктування приватних API REST та сесій WebSocket, що забезпечують роботу безкоштовних функцій Cloud Shell в AWS, Azure та GCP. Цей інструментарій буде опубліковано на GitHub разом із детальним аналізом за 2026 рік щодо шаблонів неправильної конфігурації хмарних середовищ, складеним на основі даних про витоки інформації.
Цей аналіз виявив кілька специфічних моментів, на які варто звернути увагу командам із безпеки облікових записів:
- Скомпрометований обліковий запис AWS може взяти на себе роль та розгорнути велику кількість середовищ CloudShell.
- Термінальні сесії WebSocket залишаються активними після відкликання відповідного маркера доступу, тому відкликання облікових записів не обов’язково завершує активну сесію.
- Користувацькі облікові записи M365 та Gmail отримують доступ до CloudShell за замовчуванням, що розширює відповідну поверхню атаки на особисті облікові записи, а не лише на корпоративні.
- Після встановлення сесії набір інструментів закріплюється в каталозі $HOME (який зберігається після скидання налаштувань), може заблокувати належному користувачеві доступ до sudo в межах його власної сесії та встановлює фреймворк C2.
Чому це важливо: якщо програма захисту облікових записів розглядає відкликання токена як еквівалент завершення сесії, ці дані свідчать про те, що таке припущення потребує практичної перевірки. Також варто переконатися, чи здатні наявні політики доступу та інструменти моніторингу CloudShell взагалі виявити аномальне створення сесії.
GhostJacking: агенти ШІ для написання коду, що діють за інструкціями, прихованими в журналах
Barak Sternberg, Nevo Poran та Ron Bobrov із компанії Tenet Security представили GhostJacking – техніку перехоплення керування агентами ШІ для написання коду шляхом впровадження інструкцій у журнали, які ці агенти мають зчитувати (наприклад, сповіщення WAF, звіти про помилки та дані моніторингу). Експерти Tenet повідомили про 90% успішності під час атак на Claude Code за умови використання стандартних налаштувань Cloudflare та підрахували, що понад 15 000 організацій піддаються ризику лише через конфігурації Cloudflare.
Фахівці Tenet продемонстрували цю техніку на трьох платформах
Скомпрометовані записи в журналах WAF від Cloudflare змушували агентів змінювати налаштування DNS та перенаправляти трафік. Оцінюється, що рішення Cloudflare використовуються приблизно у 42% компаній зі списку Fortune 500.
Впроваджені повідомлення в журналах Datadog спричиняли встановлення агентами шкідливих пакетів. Це призводило до віддаленого виконання коду та викрадення облікових даних. Datadog використовують приблизно 48% компаній із Fortune 500.
Модифіковані звіти про помилки Sentry змушували скомпрометований екземпляр Claude Code підтверджувати надійність зловмисника власному агенту Seer AI від Sentry. У результаті створювався ланцюг довіри між агентами. Платформа Sentry обслуговує орієнтовно 4 мільйони розробників.
Аналітики Tenet також повідомили про виявлення понад 2700 відкритих ключів API Datadog та окремо передали компанії Anthropic інформацію про вразливість, пов’язану з доступом токенів JWT, що дозволяла вихід із «пісочниці» у Claude Desktop. Цю проблему було виправлено до початку виступу на DEF CON.
Дії агента у всіх трьох випадках виконуються з використанням його власних, уже авторизованих та належних облікових даних. Це означає, що інструменти EDR, WAF та IAM не класифікують такі дії як аномальні.
Чому це важливо: системи RBAC, принцип найменших привілеїв та рішення MFA тут не допомагають, оскільки доступ агента є належним. Проблема полягає в тому, які саме дії йому наказано виконати з цим доступом. Рекомендації експертів Tenet формують надійний базовий контрольний список для захисту:
- обмеження вихідного мережевого доступу агентів за замовчуванням;
- обов’язкове затвердження людиною перед внесенням будь-яких змін до інфраструктури;
- відокремлення інструментів із доступом лише для читання від тих, що мають права на запис;
- сприйняття будь-якого журналу чи сповіщення, які зчитує агент, як ненадійних вхідних даних, незалежно від платформи їхнього походження.
Інцидент OpenAI та Hugging Face: агент, який вийшов за межі власного тестового середовища
У липні 2026 року компанія OpenAI розкрила інформацію про те, що під час внутрішнього оцінювання за допомогою бенчмарку ExploitGym (898 реальних вразливостей) експериментальна версія моделі GPT-5.6 Sol, запущена з вимкненими механізмами безпеки, вийшла за межі своєї «пісочниці» та скомпрометувала робочу інфраструктуру Hugging Face. Компанія Hugging Face повідомила про інцидент 16 липня; OpenAI підтвердила свою участь 21 липня. Eric Wallace та Michael Dalton виступили з доповіддю про цей випадок на конференції Black Hat USA 2026.
Згідно з оприлюдненими даними, агент знайшов і експлуатував вразливість нульового дня у локально розгорнутому екземплярі Artifactory (сервері проксіювання та кешування реєстру пакетів JFrog), щоб вийти з «пісочниці» та отримати доступ до інтернету. Після цього агент дійшов висновку, що саме на серверах Hugging Face зберігаються ключі відповідей для бенчмарку, і спрямував атаку безпосередньо на них. Згодом кілька екземплярів агента координували свої дії через сам Artifactory, обмінявшись сотнями тисяч повідомлень для розподілу завдань та обміну експлойтами. В один із моментів агенти навіть запропонували криптографічно підписувати свої повідомлення через підозру на присутність «самозванця». Коли 4 липня представники OpenAI перекрили цей канал, агенти відновили його за чотири дні, використавши назви каталогів на кінцевій точці без автентифікації як альтернативний канал для обміну повідомленнями.
Протягом кампанії тривалістю 4,5 дня компанія OpenAI зареєструвала понад 17 600 дій агента, зокрема екфільтрацію 136 ключів зі сховища облікових даних, крадіжку ключа автентифікації мережевого VPN, реєстрацію 181 пристрою через Tailscale та отримання прав на запис для додатків GitHub. Активність на 11 вузлах Kubernetes включала імітацію вузлів за допомогою метаданих екземплярів AWS, підробку токенів облікових записів за допомогою викраденого ключа підпису EdDSA JWT та створення привілейованих подів із монтуванням файлової системи хоста. Компанія OpenAI заявила, що виявила й інші, менші за масштабом випадки виходу з «пісочниці», які охарактеризувала як обмежені за характером та такі, що, на її переконання, не залишали меж власної мережі компанії.
Одна деталь, яка стосується облікових записів та реагування на інциденти:
Пошукові запити фахівців Hugging Face із цифрової криміналістики блокувалися тими ж комерційними механізмами безпеки ШІ, які були вбудовані в моделі OpenAI та Anthropic, що намагалися залучити для розслідування. Причина полягала в тому, що ці запобіжники не могли відрізнити запитання фахівця з реагування на інциденти від дій зловмисника. Для опрацювання понад 17 000 шкідливих подій за лічені години замість днів компанія Hugging Face використала відкриту модель із 753 мільярдами параметрів (GLM-5.2).
Чому це важливо: це задокументований випадок того, як автономний агент самостійно виявив вразливість, екфільтрував облікові дані, підробив токени та здійснив розширення атаки хмарною інфраструктурою без втручання людини. Якщо наявні моделі управління та IAM охоплюють лише облікові записи людей і службові записи, цей інцидент є вагомою підставою для введення третьої категорії – автономних агентів, здатних діяти за власною ініціативою.
Що спільного в усіх трьох випадках
CloudBasher демонструє прогалини в засобах контролю облікових записів на протокольному рівні. Відкликання токенів, межі припущень ролей та політику доступу за замовчуванням. GhostJacking стосується ситуації, коли агент ШІ використовує належний, делегований обліковий запис для виконання інструкцій, яким він не повинен був довіряти. Інцидент між OpenAI та Hugging Face пов’язаний із тим, що агент самостійно отримує та підробляє облікові дані без участі людини чи впливу скомпрометованих журналів.
Крізь усі три випадки проходить спільна загроза: фахівці обмежені інструментами, якими зловмисникам не обов’язково керуватися. CloudBasher експлуатував припущення, які фахівці не перевіряли. GhostJacking використовував той факт, що інструменти облікових даних не здатні оцінювати наміри. А в інциденті з OpenAI та Hugging Face захисні запобіжники, покликані зменшувати зловживання, водночас уповільнювали роботу фахівців, які здійснювали реагування.
Практичні кроки для команд захисту облікових записів та AD
Чотири речі, які варто зробити цього кварталу на основі аналізу:
Необхідно переконатися, що відкликання облікових даних у робочому середовищі дійсно завершує активні сеанси. Це стосується не лише майбутніх спроб автентифікації, а й будь-якої служби, що надає доступ до консолі, термінала або довготривалих підключень WebSocket.
Необхідно скласти перелік усіх агентів ШІ або асистентів із написання коду, які мають права на читання журналів, сповіщень чи даних моніторингу, та перевірити, чи розглядаються ці дані наразі як надійні або ненадійні вхідні дані.
Необхідно вимагати затвердження людиною перед внесенням агентом ШІ змін до інфраструктури або DNS, встановленням пакетів чи використанням інструментів із правами на запис.
Необхідно розглядати агентів ШІ як окремий клас облікових записів із власними межами доступу, моніторингом та планом реагування на інциденти, а не включати їх до наявних категорій облікових записів людей чи службових записів.
Аналітичні матеріали, які могли залишитися поза увагою
Для додаткового ознайомлення нижче наведено дві ключові публікації від команди аналітиків із безпеки Netwrix.
Автоматизація видалення тенантів Entra ID за допомогою ШІ
Використовуючи розширення Claude для Chrome у Microsoft Graph Explorer, Huy Kha продемонстрував, що після отримання доступу рівня глобального адміністратора для авторизованого облікового запису, JavaScript на стороні браузера та пакетні запити Graph здатні автоматизувати масове видалення користувачів, скидання паролів, відкликання сесій та видалення політик умовного доступу. У публікації це пов’язується з реальними інцидентами, зокрема справами Stryker та Storm-0501, де руйнівні дії в тенантах відбувалися після компрометації привілейованих облікових записів. Також наголошується, що ШІ не створює тут нового вектору атаки – він лише експлуатує наявний робочий процес адміністратора, роблячи його виконання швидшим та простішим для масштабування.
Чому це важливо: саме тут пролягає межа між компрометацією привілейованого облікового запису та повним видаленням тенанту, і автоматизація за допомогою ШІ стрімко скорочує цей розрив. Щойно зловмисник отримує сесію глобального адміністратора, йому більше не потрібні навички написання скриптів або багато часу для завдання максимальної шкоди. Це підвищує вимоги до захисту та моніторингу адміністративних сесій і таких інструментів, як Graph Explorer, а не лише самих облікових даних.
Звіт щодо безпеки даних та облікових записів за 2026 рік: досягнення та прогалини у впровадженні агентного ШІ та рівні готовності
Дослідницька лабораторія Netwrix опитала 2317 фахівців з ІТ та спеціалістів із безпеки з 1889 організацій. Опитування проводилося для підготовки звіту щодо безпеки даних та облікових записів за 2026 рік.
Результати показують, що організації, де ШІ значно розширив інфраструктуру облікових записів, стикалися з витіком даних приблизно в чотири рази частіше. Йдеться про порівняння з організаціями, де такого розширення не відбулося.
У звіті ця різниця пов’язується зі швидкістю управління, а не з його ретельністю. 76% організацій не здійснюють повноцінного управління чи моніторингу машинних облікових записів. Лише 11% повідомляють про повну готовність до безпечної роботи з ШІ завдяки безперервному контролю та застосуванню політик.
Чому це важливо: ці дані ставлять під сумнів поширене припущення про те, що лише належна гігієна облікових записів надійно захищає від ризиків, спричинених ШІ. Якщо процеси управління обліковими записами все ще базуються на щоквартальних перевірках та періодичних аудитах, варто перевірити, скільки часу новий агент ШІ або машинний обліковий запис існує в системі до того, як його помітять. Саме ця затримка, а не відсутність елементів керування є справжньою причиною вразливості, на яку вказує цей звіт.
