Нещодавно команда безпеки Microsoft виявила атаку, спрямовану на корпоративні системи. 12 січня 2024 р. Microsoft ідентифікувала суб'єкта загрози як Midnight Blizzard, російську державну організацію, також відому як NOBELIUM.
Цікавими є кроки, пов'язані з атакою та використанням додатку OAuth для переходу від тестового до продуктивного тенанту. Нижче наведено високорівневі кроки від перебору паролів доступу до поштових скриньок у середовищі Microsoft:
Як видно з наведених вище дій, зловмисник використовує два основні компоненти: підбір паролів і використання зловмисного протоколу OAuth з підвищеним рівнем доступу до різних тенантів. Більш детально: Microsoft Actions Following Attack by Nation-State Actor Midnight Blizzard і Midnight Blizzard: Guidance for responders on nation-state attack | Microsoft Security Blog
Зверніть увагу: цей дослід не є аналогом атаки, яка була в Microsoft, оскільки не всі подробиці є публічно доступними, але дає уявлення про те, як працює потік від одного середовища розробки/тестування до продуктивного з використанням OAuth-додатків. Перехід від одного тенанту до іншого за допомогою OAuth-додатків. Коли читаємо звіт, Midnight Blizzard використовує початковий доступ (password spraying) до застарілого тестового OAuth-додатку, який мав підвищений доступ до корпоративного тенанту Microsoft.
Додаток з назвою Test OAuth масштабується на різні організації в якості підтримуваних типів облікових записів.
Додаток не узгоджено з додатком Directory,ReadWrite.All. Як ви можете бачити, статус відображає "Not granted for tenantname".
Коли додаток скомпрометовано за допомогою вбудованих ролей Application Administrator, можна додати додаткові облікові дані до додатку через скомпрометованого користувача.
За допомогою зібраних облікових даних можливо підтвердити особистість заявника через Service Principal. Оскільки додаток не надається для тенанту, немає жодних дозволів, на які було надано згоду. Тому неможливо виконати будь-які дії, такі як створення групи або користувачів, через зібраний Service Principal.
Для цієї демонстрації переходимо до продуктивного середовища, входимо в систему як адміністратор і даємо згоду на запитувані дозволи в тенанті через :
https://login.microsoftonline.com/common/adminconsent?client_id=<client ID of app from test tenant>
В результаті адміністратор може дати згоду на використання додатку:
Після вибору "Прийняти" у продуктовому тенанті буде створено додаток Service Principal/Enterprise та дозвіл API "Directory.ReadWrite.All", наданий у додатку, тепер є частиною цьогож тенанту. Оскільки адміністратор дав згоду на додаток, він призначається автоматично. Використовується той самий ідентифікатор додатка, який відображається в інших тенантах.
Продуктний тенант
Тестовий
Отже, тепер можна повторно використовувати додаток OAuth і включити дозволи. Тепер ми можемо автентифікуватися через той самий ідентифікатор додатку та облікові дані і вибрати цільового продуктивного тенанта.
Група створена у продуктивному тенанті, який має авторизацію за допомогою service principal, зібраного на попередніх кроках у першому тенанті. При наявності дозволу MS Graph API Application.ReadWrite.All можна створювати додаткові зловмисні OAuth-додатки у продуктивному середовищі тенанту та використовувати доступ на основі нових OAuth-додатків.
Згідно зі звітом від Microsoft, зловмисники створили нові OAuth-додатки у продуктивному тенанті з підвищеними/новими дозволами. У продуктивному тенанті відбулися зміни в OAuth-додатку, включаючи дозвіл AppRoleAssignment.ReadWrite.All. За допомогою дозволу Graph API у попередній версії можна додавати нові програми OAuth і надавати необхідні дозволи, наприклад, роль Office 365 Exchange Online full_access_as_app, яка надає доступ до всіх поштових скриньок.
Роль додатка AppRoleAssignment.ReadWrite.All MS Graph обходить процедуру отримання згоди. Це зроблено за замовчуванням, що дозволяє створювати нові додатки з усіма дозволами. Оскільки це дозволяє надавати будь-які дозволи лише для додатків, включно з RoleManagement.ReadWrite.Directory. Це може бути використано для надання будь-кому або додатку більш високих дозволів, включно з правами адміністратора.
Для обмеження ризику створення OAuth-додатків, у системі тенанту можна змінити/налаштувати такі параметри, щоб зменшити ризики. За замовчуванням будь-який користувач може створювати реєстрації додатків і погоджуватися з дозволами Microsoft Graph. Коли цей контроль посилено, можливість створювати реєстрації програм вимагає наявності наступних ролей:
Для обмеження області дії атаки важливо перевірити наступні моменти:
В Центрі адміністрування Microsoft 365 можна вимкнути згоду для програм. Якщо цей параметр вимкнено, адміністратори повинні надавати згоду програмам.
Перевірити, щоб наступні опції були встановлені у значення "Ні". Це означає, що звичайні користувачі не зможуть реєструвати програми/групи безпеки.
Для наступного параметра встановіть значення «Так». Значення «Так» обмежує доступ користувачів, які не є адміністративним особами, до порталу адміністрування Microsoft Entra. Особи, які не є адміністраторами, але є власниками груп або програм, не зможуть використовувати портал Azure для керування своїми ресурсами. Цей параметр не блокує доступ через PowerShell/ Graph API або інші клієнти.
Налаштування згоди користувача для додатків зі значенням "Do not allow user consent". У цьому випадку для всіх додатків буде потрібен адміністратор.
Налаштувати дозвіл для групи зі значенням "Do not allow group owner consent".
При вказаних вище налаштуваннях метод надання дозволів автоматично вимикається для користувачів. Щоб спростити процес схвалення додатків, рекомендується впровадити робочий процес згоди на додатки. Це забезпечить безпечний спосіб надання доступу до програм, які потребують дозволу адміністратора.
Коли користувач намагається отримати доступ до програми, але не може надати згоду, він може надіслати запит на схвалення адміністратора. Адміністратор повинен схвалити запит з відповідними дозволами.
Для всіх облікових записів адміністратора має бути увімкнено захист від фішингу. Оскільки MFA з захистом від фішингу захистить від першого рівня крадіжки особистих даних. Припинити вхід з некерованих пристроїв з привілейованими обліковими записами. Кожен адміністратор повинен мати доступ до хмарного середовища Microsoft зі спеціальних захищених пристроїв.
Важливо своєчасно виявляти та відстежувати потенційні зловмисні OAuth-додатки. Оскільки їх складно виявити, важливо проводити аудит поточного рівня привілеїв усіх ідентифікаторів, як для користувача, так і для service principals.
Більше деталей: Midnight Blizzard: Guidance for responders on nation-state attack | Microsoft Security Blog
Керування додатками в складі Defender for Cloud Apps можна використовувати на стадії визначення наявних додатків. Керування програмами дає уявлення про привілейовані та високопривілейовані додатки.
Прикладом може бути використання KQL для запиту, коли надання згоди ініціюється з full_access_as_app в Entra ID. - https://github.com/rootsecdev/Microsoft-Blue-Forest/blob/master/PurpleTeam/MidnightBlizzard.kql
Наступні оповіщення Microsoft Entra ID Protection можуть допомогти у виявленні атак Midnight Blizzard:
Сервіси з організації безпечного цифрового робочого місця від SoftwareOne дають змогу отримати додатковий захист без додаткових витрат на персонал.
Сервіси з організації безпечного цифрового робочого місця від SoftwareOne дають змогу отримати додатковий захист без додаткових витрат на персонал.
