Атаки на Active Directory (AD) можуть відбуватися швидко. Ви маєте бути швидше. Як тільки зловмисник використовує обліковий запис користувача AD, ваші шанси знайти його зменшуються. Вони можуть отримати повсюдний доступ навіть доступ адміністратора. Вони можуть переміщатися по системах непоміченими і виконувати код так, якби вони були ймовірним користувачем. Коли ви розумієте, що щось не так, часто буває вже пізно: шкоди завдано. Зловмисник вивів дані, заразив системи чи запустив програму-вимагач. Вам залишається лише розгрібати наслідки.
У цьому блозі розглядається, як за допомогою моніторингу мережі можна зловити зловмисників, які атакують середовища Active Directory. Найкращі методи виявлення дозволяють виявити зловмисників на ранніх стадіях, скорочуючи при цьому кількість помилкових спрацьовувань. З цієї причини потрібно зосередитися на затриманні зловмисників на стадії розвідки, яка є ранньою частиною будь-якої атаки.
Розвідка LDAP
За замовчуванням будь-який звичайний користувач AD у домені має дозволи на читання LDAP для цього домену. Таким чином, зловмисник, який скомпрометував користувача домену (користувача, який не входить до групи з високими привілеями, такої як адміністратори домену), зможе виконати розвідку домену для зіставлення об’єктів домену. Розвідка є ключовою частиною будь-якої атаки на AD, оскільки вона дозволяє зловмисникові скласти карту жертви. Потім вони можуть використовувати ці дані для латерального переміщення та підвищення привілеїв. Зосередимося на наступних атрибутах LDAP, щоб упіймати зловмисника на етапі розвідки:
UserAccountControl
Атрибут UserAccountControl AD визначає конфігурацію певних параметрів облікового запису. Наприклад: UserAccountControl може вказувати на вимкнені облікові записи або облікові записи, які не потребують попередньої автентифікації Kerberos під час входу до системи.
Наступний список містить усі можливі опції для UserAccountControl:
Image Source: Microsoft
Зосередимося на LDAP-запитах, у яких зловмисники шукають наступні прапорці властивостей UserAccountControl:
PASSWD_NOTREQD, DONT_REQ_PREAUTH, TRUSTED_FOR_DELEGATION, ENCRYPTED_TEXT_PWD_ALLOWED.
PASSWD_NOTREQD
Коли обліковий запис користувача AD має прапорець PASSWD_NOTREQD, це означає, що для входу до нього не потрібний пароль. Зловмисники шукатимуть такі облікові записи без пароля. Мета зловмисника – просунутися доменом і скомпрометувати облікові записи домену. Чим швидше вони досягнуть цієї мети, тим менша ймовірність того, що їх виявлять на цій ранній стадії атаки. Вхід до цих типів облікових записів AD прискорює час проникнення, оскільки відпадає необхідність пошуку пароля облікового запису.
Зазначимо наступний LDAP-запит як підозрілий:
DONT_REQ_PREAUTH
Коли обліковий запис користувача AD має прапорець DONT_REQ_PREAUTH, зловмисник може запросити зашифрований Ticket Granting Ticket (TGT) для користувача без пароля. TGT підписується паролем цільового користувача, що дає змогу зловмиснику спробувати перебрати пароль в автономному режимі. Цей тип атаки відомий як As-Rep Roasting (MITRE T1558.004).
Зазначимо наступний LDAP-запит як підозрілий:
TRUSTED_FOR_DELEGATION
Якщо для облікового запису комп’ютера AD встановлено прапорець TRUSTED_FOR_DELEGATION, комп’ютер зберігає квиток Ticket Granting Ticket. Зловмисник, якому вдасться скомпрометувати обліковий запис комп’ютера, зможе скинути квитки KERBEROS TGT для всіх користувачів, що ввійшли в систему. Крім того, зловмисники можуть використовувати різні техніки для примусової автентифікації облікового записукомп’ютера-жертви з метою наступного скидання квитків KERBEROS TGT.
Зазначимо наступний LDAP-запит як підозрілий:
ENCRYPTED_TEXT_PWD_ALLOWED
Коли для облікового запису користувача AD встановлено прапорець ENCRYPTED_TEXT_PWD_ALLOWED, зловмисник, який скомпрометував базу даних AD, отримує доступ до пароля облікового запису користувача у вигляді відкритого тексту. Зазвичай, такі паролі зберігаються у форматі хеша NTLM. Доступ до відкритого тексту прискорює атаку, оскільки відпадає потреба у переборі пароля.
Зазначимо наступний LDAP-запит як підозрілий:
Service Principal Name
Обліковий запис служби
Обліковий запис служби – це обліковий запис користувача AD, створений для запуску певної служби або програми.
Наприклад, якщо служба SQL потребує доступу до ресурсів у домені, можна створити обліковий запис служби з правом доступу до ресурсів і використовувати його.
AD використовується атрибут service principal name (SPN) для того, щоб розрізняти різні служби.
Для кожного облікового запису служби буде визначено SPN, який представляє конкретну службу, для якої він був створений.
KERBEROS Service Tickets
Після автентифікації Kerberos будь-який користувач може запросити у контролера домену Kerberos (KDC) доступ до будь-якої служби в домені. Служба ідентифікується за допомогою SPN.
Коли обліковий запис запитує про доступ до служби в домені, KDC повертає клієнтові квиток служби. Квиток служби шифрується за допомогою хеша пароля запитаного об’єкта домену, на якому розміщено службу. Наприклад, при підключенні за допомогою SSH до комп’ютера домену квиток служби шифрується хешем комп’ютера домену, на якому розташована служба SSH. Зловмисник, який одержав квиток на послугу, може спробувати перебрати хешований пароль в автономному режимі.
Пароль машинного облікового запису задається випадковим чином і має довжину 120 символів, в той час як паролі облікових записів користувачів зазвичай коротші і часто слідують передбачуваним шаблонам. Це робить спробу зламування пароля користувача швидше і простіше, ніж спроба зламування пароля облікового запису машини.
KERBEROASTING ATTACK
Той факт, що в обліковому записі сервісу налаштований SPN, а також те, що будь-який користувач може запросити квиток на сервіс у домені, дозволяє зловмиснику, скомпрометував низькопривілейованого користувача домену, знайти користувачів сервісу, запросити для них квиток на сервіс і перебрати їх пароль в автономному режимі. Ця атака відома як “KERBEROASTING” (MITRE T1558.003).
Приклад підозрілого LDAP-запиту:
Паролі у відкритому тексті
Наступні атрибути LDAP можуть містити паролі у вигляді відкритого тексту:
UnixUserPassword
UnixUserPassword – це атрибут LDAP для систем на базі UNIX. Зловмисник може перерахувати домен для користувачів з налаштованим UnixUserPassword, оскільки його можна зберегти у форматі відкритого тексту.
Приклад підозрілого LDAP-запиту:
Опис
Погано конфігуроване середовище Active Directory може містити пароль в описі:
Відзначатимемо запити LDAP, які шукають пароль в описі, наприклад:
NT-Security-Descriptor
Active Directory використовує список управління доступом (ACL) для авторизації облікових записів.
Знання ACL облікових записів в AD дозволить зловмисникам планувати свої атаки для латерального переміщення та підвищення привілеїв у домені. Цей інструмент з відкритим вихідним кодом використовує аналіз ACL для складання карти можливих атак на цей домен:
AD зберігає ACL об’єкта в LDAP-атрибуті ‘nTSecurityDescriptor’.
‘nTSecurityDescriptor’ ділиться на 4 частини:
- Власник – власник об’єкту
- Group SID (Security identifier) – група, пов’язана з об’єктом.
- DACL – список дозволів/заборон для об’єкта:
- SACL – аудит дозволів для об’єкта:
– Зловмисник, який скомпрометував низькопривілейованого користувача AD, не матиме дозволу на частину SACL дескриптора безпеки. DACL є найважливішою частиною дескриптора з погляду зловмисника, оскільки вона визначає дозволені дії, які об’єкт може виконувати у домені. Щоб отримати частину DACL у дескрипторі безпеки за допомогою LDAP, зловмисник повинен вказати, яка частина дескриптора його цікавить. LDAP використовує елемент управління під назвою ‘LDAP_SERVER_SD_FLAGS_OID’, який контролює, яку частину дескриптора можна отримати.
Наступні прапорці описують різні можливі дескриптори:
Image Source: Microsoft
Щоб зловити зловмисника, який виконує аналіз ACL за допомогою LDAP, відстежуватимемо запити на об’єкт nTSecurityDescriptor з одним із LDAP_SERVER_SD_FLAGS_OID. Наприклад, можна виявити зловмисника, який запитує лише DACL:
Висновок
Суб’єкти загроз постійно вдосконалюються, постійно створюючи нові методи отримання доступу до конфіденційної інформації. Розвідка є ключовою частиною будь-якої атаки AD. Без відображення об’єктів AD та їх з’єднань зловмисникам буде складно скомпрометувати домен. Застосування правил виявлення допомагає зловити зловмисників на ранній стадії, поки збитків ще не завдано. Щоб убезпечити свою організацію, переконайтеся, що ваші системи знаходяться в актуальному стані і що ви встановили автоматизовану систему виявлення, таку як Fidelis Elevate, для проактивного захисту від кіберзагроз та активних атак.
Дізнатись більше про платформу Fidelis Elevate.
Джерело: How to Spot and Stop Active Directory Attacks Faster
