Як слідкувати за кіберзловмисником: 3 шляхи використання Red Team з 2024 року

Незахищені облікові дані залишаються популярною проблемою. Red Team (і супротивникам) набагато легше вдертися в будинок, коли ключі від нього лежать під килимком. Ось причини чому ця проблема все ще існує:

• Команди не мають доступу до спеціального рішення для керування паролями, тому вони використовують спільну електронну таблицю для спільних облікових даних (наприклад, спільний зовнішній обліковий запис для виставлення рахунків).
• Адміністраторам потрібно регулярно виконувати одне й те саме завдання на різних хостах, тому вони зберігають сценарії PowerShell у спільному сховищі, звідки його можна швидко витягти та запустити. Сценарії містять їхні суворо закодовані облікові дані замість того, щоб запитувати облікові дані.
• Резервні копії розгорнутого коду, зокрема внутрішніх веб-серверів, зберігаються у спільній папці команди розробників, до якої має доступ будь-який авторизований користувач. Код використовує жорстко закодовані значення для облікових даних або ключів, а не змінні значення, розкриваючи секрети відкритим текстом.
• Окремі користувачі створюють резервні копії своїх папок «Робочий стіл» або «Документи» на спільному диску і мають неприємну звичку додавати до них файл «passwords.txt» або «reminders.docx».

SharePoint – це одне з тих місць, де облікові дані можуть випадково потрапити у загальний доступ. Якщо компанія використовує Microsoft Teams, то файли, до яких надається спільний доступ у «каналах» (а не в індивідуальних прямих повідомленнях), можуть потрапити у доступ до усієї команди через їхню пов’язану природу. Їх можна знайти на вкладці «Файли» в папці «Вкладення». Хтось може поділитися конфіденційним файлом, що містить облікові дані, думаючи, що він обмежений певною групою в додатку Teams, але насправді цей файл може бути доступний будь-кому в SharePoint якщо не є заблокованим належним чином.

Тож де були знайдені ці облікові дані? Як можна здогадатися з наведених вище прикладів, головними джерелами цього року були SharePoint, мережеві файлові ресурси та сховища коду. Інструменти для управління процесами, такі як Jira, також отримали почесну згадку, оскільки люди (правильно) оновлювали питання для управління проектами, але включали конфігурації або паролі як частину оновлень. Інші місця, де часто ховають облікові дані, включають історії розгортання (Azure, Jenkins тощо) та runbooks (Azure, Terraform, Ansible тощо).

Потенційні заходи щодо зниження незахищеності облікових даних

Керування обліковими записами спочатку може здаватися надто складним, але з часом воно може стати більш керованим. CrowdStrike пропонує такі заходи:

• Впровадження підходящого (і безпечного) рішення для керування паролями
• Виконання регулярного сканування мережевих ресурсів і SharePoint за допомогою таких інструментів, як Snaffler
• Проведення навчання користувачів, особливо розробників та ІТ-персоналу, які мають тенденцію писати скрипти або код із вбудованими обліковими даними службових облікових записів
• Використання функції маскування секретів в автоматизації (наприклад, сховища в Ansible)
• Огляд коду перед фіксацією та доповнення цього огляду за допомогою пошукових систем репозиторіїв, таких як TruffleHog

Ці кроки не є повним вирішенням незахищеності, оскільки облікові дані не слід зберігати у вигляді відкритого тексту, необхідно переглянути налаштування доступу до спільних мережевих ресурсів. Великі вбудовані групи, такі як Authenticated Users, часто мають доступ до більшої кількості ресурсів, ніж передбачалося, оскільки використання ресурсів з часом змінюється або вони швидко налаштовуються. Інструмент Snaffler також можна використовувати для виявлення спільних ресурсів, не копаючись у файлах для швидшого виявлення.

Ті, хто зловживає AD CS майже миттєво шкодують про це, оскільки шляхи атаки, які часто називають короткими назвами пронумерованих варіантів ескалації (ESC1, ESC4 тощо), можуть призвести до негайної компрометації домену за певних обставин. І це, на жаль, трапляється дуже часто.

Як випливає з назви, AD CS керує додаванням криптографічних сертифікатів і інфраструктури відкритих ключів (PKI) в середовище Active Directory. У поєднанні з криптографією відкритих ключів для початкової автентифікації (PKINIT) ці сертифікати можна використовувати з Kerberos для автентифікації в якості основного користувача без пароля.

Навіть якщо PKINIT не ввімкнено в середовищі, сертифікати все одно часто можна використовувати для автентифікації в інших протоколах, як от Lightweight Directory Access Protocol (LDAP) через TLS. Але це може призвести до вторинних атак, таких як налаштування обмеженого делегування на основі ресурсів (Resource-based Constrained Delegation).

З усіх шляхів ескалації, які CrowdStrike спостерігав у своїх операціях, ESC1, ESC4 і ESC8 були найпоширенішими зловмисниками.

ESC1

Цей шлях атаки включає налаштування, які дозволяють зловмиснику вимагати сертифікат з додатково вказаним ідентифікатором, що дозволяє йому видавати себе за цільовий обліковий запис. Вразливою комбінацією налаштувань для цього шляху атаки є:

• Великі вбудовані групи (зазвичай користувачі домену, комп’ютери домену або автентифіковані користувачі) можуть реєструватися за допомогою шаблону та центру сертифікації
• Схвалення менеджером відключено, хоча це не є вирішальним фактором при наявності невеликої соціальної інженерії або везіння (наприклад, неуважні менеджери)
• Бажаний шаблон увімкнено
• Розширене використання ключа (Extended Key Usage, EKU) встановлено на значення, яке дозволяє певну форму автентифікації Kerberos (наприклад, автентифікацію клієнта), EKU вказує «Будь-яка мета», або EKU взагалі відсутній
• Шаблон сертифіката має позначку ENROLLEE_SUPPLIES_SUBJECT, який дозволяє запитувачу вказати додаткового параметр при запиті сертифіката

Коли ці умови виконано, користувач може вказати ім’я адміністратора домену або контролера домену і отримати повну автентифікацію Kerberos, навіть не знаючи їхнього пароля.

Якщо використовувати інструмент Certipy з відкритим вихідним кодом для збору даних AD CS, шаблон, показаний нижче, буде вразливим до ESC1.

Варто зазначити, що якщо сертифікат не може вимагатися цими великими вбудованими групами, то він все одно може забезпечити шлях (хоча і трохи довший) до ескалації привілеїв домену. Це станеться якщо параметри, які не належать до рівня 0, можуть зареєструватися у вразливому шаблоні. Наприклад, часто помітні окремі сервери з можливістю реєстрації за допомогою вразливих шаблонів, які зловживали цим дозволом для компрометації домену після отримання локальних адміністративних привілеїв на цьому сервері.

Пом’якшення наслідків: Щоб захиститися від ESC1, необхідно переконатися, що шаблони сертифікатів не містять прапорця ENROLLEE_SUPPLIES_SUBJECT. Якщо для інших розгорнутих технологій абсолютно необхідно, щоб інші суб’єкти надавали альтернативне ім’я суб’єкта, треба пересвідчитись, що дозволи на реєстрацію заблоковані тільки для інших високопривілейованих груп, таких як адміністратори доменів і контролери доменів. Якщо це також не є можливим, варто розглянути можливість вимагати схвалення запитів менеджером, щоб виявити нелегітимне використання.

Також, доцільно переглянути шаблони, в яких вказано «Будь-яка мета» або взагалі відсутня EKU. Як правило, «Будь-яка мета» та відсутні EKU мають бути скориговані таким чином, щоб підтримувати лише обмежений набір застосувань, необхідних для цього сертифіката.

ESC4

Шаблони сертифікатів є об’єктами Active Directory, як і все інше в цьому середовищі, і ESC4 зловживає неправильно налаштованими записами контролю доступу (ACE) в цих шаблонах. Маючи можливість змінювати шаблон, зловмисник може навмисно зробити його вразливим, використовуючи налаштування, описані вище для ESC1.

При повторному використанні Certipy наведений нижче шаблон буде вразливим до ESC4.

Пом’якшення наслідків: ESC4 використовує більш традиційний підхід. Оскільки власники шаблонів/автори зможуть підвищити статус до адміністратора домену, модифікувавши шаблон, потрібно переглянути дозволи на об’єкти шаблону та обмежити права власності та інші дозволи на запис до адміністраторів домену, де це можливо. Такі інструменти, як Certipy, можуть допомогти ідентифікувати цих власників, так само як і традиційні інструменти дослідження Active Directory, такі як BloodHound.

ESC8

Замість того, щоб зловживати шаблоном, ESC8 зловживає можливістю веб-реєстрації на самих центрах сертифікації. Служба веб-реєстрації в ЦС дозволяє користувачам виконувати завдання з сертифікатами у веб-інтерфейсі користувача ЦС, звертаючись до кінцевої точки http(s)://ca-name.example.com/certsrv.

Не дивлячись на те, що це може бути корисно для користувачів, які не мають технічної підготовки, такою функціональністю також можна зловживати за допомогою атак на переадресацію NTLM.

Підписання SMB і LDAP є варіантами захисту, які можуть запобігти ретрансляційним атакам NTLM на відповідні служби, але ESC8 націлений на службу HTTP, що не захищена цими засобами контролю.

Після успішного завершення процесу автентифікації через зловмисника-посередника, зловмисник може використовувати отриманий сеанс з такими інструментами, як Certipy або ntlmrelayx. Це робиться з метою автоматичного запиту сертифікату для будь-якого шаблону, який може використовувати жертва і може призвести до таких наслідків, як автентифікація під обліковим записом жертви або використання інших вразливих шаблонів, недоступних широкому загалу. Якщо жертва є контролером домену, зазвичай невдовзі після цього відбувається повна компрометація домену.

Пом’якшення наслідків: Для ESC8 варто розглянути можливість повного видалення служби веб-реєстрації. Якщо ця служба все ще потрібна, Microsoft надала додатковий захист за допомогою розширеного захисту для автентифікації (EPA). Також необхідно вимагати HTTPS для доступу до кінцевої точки веб-реєстрації, щоб примусово створити тунель TLS, і також, щоб обмежити передачу облікових даних, можна вимкнути автентифікацію NTLM для інформаційних служб Інтернету (IIS) на центрі сертифікації. Для отримання додаткової інформації про ці кроки захисту необхідно звернутися до документації Microsoft.

Протокол автентифікації NTLM використовує потік викликів і відповідей, у якому хеш пароля облікового запису використовується для шифрування числа, яке використовується лише один раз («nonce»). Клієнт отримує одноразовий номер, шифрує його за допомогою хешу пароля облікового запису (хеш NT) і повертає до служби. Нарешті, служба надсилає ім’я користувача, одноразовий номер і зашифровану відповідь клієнта на контролер домену. Контролер домену отримує хеш пароля для наданого імені користувача, шифрує сам nonce і порівнює його із зашифрованим значенням служби. Якщо все збігається, обліковий запис успішно пройшов автентифікацію.

За допомогою ретрансляційної атаки NTLM зловмисник опиняється в центрі процесу, де він може перехопити та/або навмисно змусити автентифікацію, а потім перенаправити її в потрібне місце. Як правило, для цього потрібен доступ до порту 445 і низка тунелів. Порт 445 автоматично зв’язується обліковим записом SYSTEM під час запуску для хостів Windows, що робить локальний адміністративний доступ обов’язковою умовою для більшості релейних атак NTLM у середовищі з інтенсивним використанням Windows.

У сценарії примусу сервер-жертва змушений пройти автентифікацію на скомпрометованому хості. Однак зловмисник перехоплює перший крок автентифікації та замість цього надсилає його на цільовий сервер або службу, ініціюючи там автентифікацію. Зловмисник-посередник керує рештою потоку NTLM вперед-назад до його завершення. Після завершення потоку зловмисник контролює автентифікований сеанс.

Надмірні дозволи в Active Directory є ще однією вічною проблемою, яку може бути важко повністю усунути в складних середовищах через велику кількість рухомих частин. Ця проблема складна ще й тому, що вона часто виникає з різних причин, таких як недостатня кількість політик або їх недотримання, а також постійна боротьба між доцільністю та безпекою.

CrowdStrike Professional Services Red Team часто стикається з неправильно налаштованими, забутими або об’єктами з надмірним дозволом, які дають нам можливість перестрибувати, пропускати і перестрибувати до контролю над середовищем.

Облікові записи з надмірним дозволом

Ця помилка з’являлася в більшості середовищ, які були протестовані командою CrowdStrike. Службові облікові записи, які є членами адміністраторів домену або еквівалентних груп, є однією з найбільших проблем. А проблема полягає в тому, що службові облікові записи часто занадто поширюються в середовищі для виконання своєї роботи. Крім того, вони становлять найбільшу частку облікових даних, які були знайдені в незахищених місцях. Навіть якщо їх не можна знайти у файлообміннику, то облікові дані потенційно можна отримати через Kerberoasting або з реєстру хоста – якщо обліковий запис працює як служба на цьому хості.

Однак небезпечними можуть бути не лише права адміністрування домену – ми можемо використовувати службові облікові записи як сходинку до статусу локального адміністратора на серверах, які містять інші шляхи.

Іншими основними гравцями є облікові записи адміністраторів служби підтримки, які можуть в кінцевому підсумку скомпрометувати домен. Часто видно вкладені членства в групах Active Directory, які ведуть до вбудованої групи адміністраторів домену або облікових записів з можливістю змінювати інші принципи, що може скомпрометувати домен.

Недостатня багаторівневість облікових записів

Не вдаючись у подробиці, активи в мережі часто можна представити у вигляді рівнів, де рівень 0 – це сам домен і особи, які можуть працювати з ним (наприклад, адміністратори домену та контролери домену). Рівень 1 часто включає більшість інших серверів та їхніх адміністраторів, рівень 2 – це, як правило, адміністратори служби підтримки та допоміжна інфраструктура, а рівень 3 охоплює все інше.

Хоча багато компаній все краще відокремлюють адміністративні облікові записи від звичайних облікових записів користувачів, CrowdStrike Professional Services Red Team часто виявляє, що для адміністраторів не існує подальшого поділу на рівні, особливо між рівнями 0 і 1/2. Це означає, що облікові записи з повним контролем над доменом входять на робочі станції та файлові сервери, де їхні облікові дані потенційно доступні в LSASS, або залишають застарілі RDP-сесії, які можуть бути перехоплені. Це складніше та більш помітно при експлуатації, але все ж таки це є проблемою.

Неправильно налаштовані та забуті права контролю доступу

Ще одна поширена знахідка Red Team – це група користувачів домену, яка має такі права доступу, як AllExtendedRights, WriteDacl або GenericAll на кількох комп’ютерних об’єктах, а іноді навіть на інших користувачах.

Що ще гірше, комп’ютерні об’єкти можуть не відповідати серверу, який доступний через мережу. Але якщо об’єкт не було видалено з Active Directory, зловмисники можуть зловживати цими дозволами, щоб заволодіти ним. Це може призвести до наступних атак для отримання доступу до чогось іншого або реєстрації в AD CS, таких як ланцюговий контроль доступу.

Два найпоширеніших шляхи для неправильно налаштованих ACE на комп’ютерних об’єктах – це тіньові облікові дані і обмежене делегування на основі ресурсів (RBCD), якими можна зловживати, коли користувачі домену мають права AllExtendedRights, GenericAll, GenericWrite, WriteDacl або Owner на комп’ютерному об’єкті.

Перший варіант, тіньові облікові дані, вимагає одного з двох сценаріїв: 1) PKINIT увімкнений для аутентифікації або 2) наявність TLS з LDAP. Зловмисник записує нові облікові дані в атрибут msDS-KeyCredentialLink об’єкта, додаючи механізм безпарольної автентифікації для цього обʼєкта.

RBCD трохи складніший. Протокол автентифікації Kerberos використовує квитки для отримання доступу до служб у всьому середовищі. Якщо користувач хоче отримати доступ до веб-сервера, він отримує службовий квиток для HTTP-сервісу і надсилає його. Однак, якщо цій службі потрібен доступ до внутрішньої бази даних, щоб отримати інформацію для користувача, наданий службовий квиток не покриває цього. Таким чином, виявляється проблема подвійного переходу.

Спочатку Microsoft вирішила цю проблему, запровадивши необмежене делегування. При такому налаштуванні користувач надсилає переадресований квиток видачі квитків (TGT) на додаток до службового квитка. Потім веб-сервер (у цьому прикладі) міг запросити службовий квиток від імені користувача, щоб отримати доступ до внутрішньої бази даних. Але у чому проблема? TGT – це все одно, що мати пароль користувача для всього, що використовує аутентифікацію Kerberos. Тому скомпрометований сервер призведе до компрометації всіх користувачів, які отримують до нього доступ.

Далі – обмежене делегування. Microsoft додала Service for User to Self (S4U2Self) і Service for User to Proxy (S4U2Proxy). Тепер служба може запитувати квиток на обслуговування для будь-якого користувача в середовищі або для себе (S4U2Self), або для визначеного списку служб (S4U2Proxy). Цей список складається з імен об’єктів служб (SPN), які зберігаються в атрибуті msDS-AllowedToDelegateTo об’єкта. Цей варіант кращий, але все ще має свої недоліки.

І, нарешті, RBCD. З RBCD парадигма змінюється: back-end має список сервісів, які можуть йому делегувати, і ці сервіси зберігаються як SPN в атрибуті msDS-AllowedToActOnBehalfOfOtherIdentity. Front-end-сервіс все ще використовує S4U2Proxy і все ще може запитувати службовий квиток від імені будь-якого незахищеного користувача, але тільки якщо back-end-сервіс дозволяє це робити. Це крок вперед, тому що тепер ціль (back-end) повинна бути скомпрометована першою.

Введіть неправильно налаштовані ACE. За допомогою чогось на кшталт GenericWrite над іншим об’єктом, у цьому випадку головним чином обліковими записами комп’ютера, обліковий запис може змінити атрибут msDS-AllowedToActOnBehalfOfOtherIdentity, щоб додати SPN, яким він керує. Цей SPN може виникнути внаслідок іншої атаки (наприклад, Kerberoasting), з іншого контрольованого комп’ютера або через зловживання квотою облікового запису комп’ютера за замовчуванням, яка дозволяє будь-якому користувачеві додати 10 об’єктів комп’ютера без запитань. Ці комп’ютерні об’єкти завжди постачаються з SPN.

Після того, як властивість було змінено, зловмисник може використовувати S4U2Proxy для запиту квитка служби для адміністратора до служби HOST цілі, отримуючи адміністративний доступ через комп’ютер.

Потенційні засоби пом’якшення надмірних дозволів

Одним із найважливіших кроків є регулярна перевірка середовища Active Directory на наявність неправильно налаштованих елементів. Інструмент з відкритим вихідним кодом BloodHound чудово справляється з цим, беручи дані з AD Explorer або власного джерела даних і розміщуючи їх у базі даних та на графіку з можливістю пошуку. Це може значно полегшити пошук порівняно з самостійним переглядом Active Directory.

Ключові області, на які варто звернути увагу:

• GenericAll, GenericWrite, AllExtendedRights і WriteDacl для непривілейованих користувачів або груп над іншим об’єктом: нормальних причин небагато, тому варто переглянути ці права для непривілейованих користувачів
• Кілька рівнів вкладених груп, які можуть призвести до ненавмисних дозволів
• Об’єкти Active Directory: зокрема комп’ютери, які більше не існують у мережі, але не були повністю видалені з Active Directory

Ще один нетехнічний підхід полягає в тому, щоб мати жорсткі політики та процедури щодо створення та знищення об’єктів Active Directory. Це гарантує, що для об’єктів не буде налаштовано шаблон за замовчуванням, включаючи дозволи, які їм не потрібні, або вони не залишаться позаду під час виведення з експлуатації. Облікові записи служби адміністратора домену не можна надавати без законної потреби.

З технічної сторони необхідно добре використовувати вбудовану групу захищених користувачів в Active Directory. Це допоможе запобігти делегуванню цих користувачів, як під час атаки RBCD, і кешуванню їхніх облікових даних, де б вони не входили. Такий підхід буде особливо корисним для адміністраторів домену та будь-яких конфіденційних адміністраторів рівня 1. Але потрібно пам’ятати, що це може вплинути на функціональність, тому слід переконатися, що всі наслідки зрозумілі, перш ніж застосовувати це. Також можливо окремо позначити облікові записи як «конфіденційні», але такий варіант застосовуватиме лише захист делегування.

Хоча спеціалісти регулярно стикаються (і зловживають) іншими речами, як-от слабкою реалізацією SCCM або відсутністю підпису LDAP, усунення цих трьох проблем значно покращить загальний стан безпеки корпоративної мережі та змусить Red Team (або справжніх зловмисників) сидіти прямо та напружитися, щоб копати глибше.