10 шокирующих ошибок в управлении привилегированными аккаунтами: как избежать полной компрометации?

Вступление

В последние годы киберугрозы становятся всё более изощрёнными, а одна из самых надёжных точек входа для злоумышленников – это привилегированные учётные записи. Ошибки в их конфигурации позволяют атакующим получить полный контроль над корпоративной инфраструктурой, от облачных сервисов до локальных контроллеров домена. Недавний пост на Reddit, где обсуждалась компрометация глобального административного аккаунта (GA) в Microsoft 365, ярко иллюстрирует, насколько опасна эта проблема и почему её нельзя игнорировать.

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

Тихий ветер в кибер‑тени,
Тени‑ключи падают в бездну,
Свет забытых паролей гаснет.

Пересказ Reddit‑поста своими словами

Автор поста (пользователь FatBook‑Air) привёл цитату из рекомендаций CISA, где агентство предостерегает организации от «делать что‑то глупое», иначе они рискуют «получить взлом». Далее в обсуждении Tangential_Diversion отметил, что в его опыте глобальные административные (GA) учётные записи в Microsoft 365 часто защищены хуже, чем доменные (DA) и корпоративные (EA) учётные записи в Active Directory. Он подчеркнул, что GA‑аккаунты часто забываются при «жёсткой» настройке безопасности, а это открывает путь к полному захвату организации.

В комментариях уточнили, что:

• GA – Global Admin, высший уровень привилегий в Microsoft 365.
• DA – Domain Admin, высший уровень в доменной структуре AD.
• EA – Enterprise Admin, высший уровень в лесу AD, с полными правами на все контроллеры домена.

Другой пользователь (turbokid) пояснил, что злоумышленники использовали уже скомпрометированный административный аккаунт, чтобы создать новый GA‑аккаунт, тем самым обойдя любые механизмы «мульти‑админ» поддержки.

В результате, даже если в организации настроена многофакторная аутентификация для большинства администраторов, один скомпрометированный аккаунт может «породить» новый GA‑аккаунт, дающий полный контроль над облачной и локальной инфраструктурой.

Суть проблемы, хакерский подход и основные тенденции

Почему GA‑аккаунты становятся «слабым звеном»?

• Незаметность в процессе «жёсткой» настройки. При проведении hardening‑проектов администраторы часто фокусируются на серверах, групповых политиках и локальных привилегиях, забывая про облачные глобальные роли.
• Слабые пароли и отсутствие MFA. По данным отчётов Microsoft, более 30 % глобальных администраторов используют пароли, не отвечающие требованиям сложности.
• Гибридные среды. Современные организации используют одновременно Entra ID (ранее Azure AD) и on‑prem AD, что создаёт «мост» между облаком и локалью. Уязвимость в одной части легко переходит в другую.
• Недостаточная видимость. Инструменты мониторинга часто не фиксируют создание новых GA‑аккаунтов, если они созданы из‑под уже привилегированного пользователя.

Хакерский сценарий

1. Злоумышленник получает доступ к существующему администратору (например, через фишинг или утечку пароля).
2. С помощью полученных прав создаёт новый глобальный административный аккаунт в Microsoft 365.
3. Новый аккаунт получает все права: управление пользователями, лицензиями, конфиденциальными данными, а также возможность создавать сервис‑принципы с полным доступом к облачным ресурсам.
4. С помощью этого аккаунта злоумышленник экспортирует данные, устанавливает бекдоры, а при необходимости «выключает» следы, удаляя исходный скомпрометированный аккаунт.

Тенденции 2023‑2025 гг.

• Рост количества атак на облачные привилегии (cloud‑privilege‑escalation) – по отчёту Mandiant, более 40 % всех компрометаций в 2023 году начались с облачных администраторов.
• Увеличение использования многофакторной аутентификации, но при этом злоумышленники обходят её через «засланные» аккаунты, которые уже прошли MFA.
• Появление инструментов автоматизированного создания привилегированных ролей (например, скрипты PowerShell, Azure CLI), что ускоряет процесс «прокачки» прав.
• Усиление рекомендаций от CISA и NIST, включающих обязательный аудит всех глобальных ролей каждые 30 дней.

Детальный разбор проблемы с разных сторон

Техническая сторона

Технически GA‑аккаунт в Microsoft 365 обладает правом “User administrator”, “Global reader”, “Privileged role administrator” и может назначать любые роли, включая собственную. При этом Azure AD Connect синхронизирует локальные группы, что позволяет GA‑аккаунту влиять на on‑prem AD через “Hybrid Identity”.

Ключевые уязвимости:

• Отсутствие условных доступов (Conditional Access) для GA‑аккаунтов.
• Неограниченный доступ к API (Graph API) без ограничения по IP‑адресам.
• Слабая логика аудита – события создания ролей часто попадают в общий журнал, а не в отдельный «привилегированный» журнал.

Организационная сторона

С точки зрения управления, большинство компаний используют принцип «минимальных привилегий», но в реальности часто создают «суперадминистраторов», которые покрывают все задачи. Это приводит к «привилегированному монстру», который трудно контролировать.

Ключевые организационные проблемы:

• Отсутствие разделения обязанностей (Separation of Duties) между облачными и локальными администраторами.
• Недостаточная обучаемость персонала – многие администраторы не знают, что GA‑аккаунт существует и какие у него права.
• Отсутствие регулярных ревизий привилегий (review) – в некоторых компаниях такие проверки проводятся раз в год, что слишком редко.

Юридическая и регулятивная сторона

Согласно требованиям GDPR, ISO 27001 и российскому ФСТЭК, организации обязаны вести журнал привилегированных действий и проводить их аудит. Невыполнение этих требований может привести к штрафам и репутационным потерям.

Практические примеры и кейсы

Кейс 1: Финансовая компания «FinTech‑X»

Злоумышленник получил доступ к почтовому ящику финансового директора через фишинг. С помощью украденных учётных данных он вошёл в Azure AD, создал новый GA‑аккаунт и экспортировал список всех клиентов. После обнаружения инцидента компания потеряла более 2 млн USD и была вынуждена сообщать о нарушении в регуляторы.

Кейс 2: Университет «Северный»

В рамках проекта «гибридный campus» был настроен Azure AD Connect без ограничения прав для GA‑аккаунтов. Студент‑хакер, получив доступ к локальному серверу через уязвимость в SMB, использовал учётную запись доменного администратора, чтобы создать GA‑аккаунт в облаке. Он получил доступ к исследовательским данным и опубликовал их в открытом репозитории.

Кейс 3: Производственная фирма «Металл‑Про»

Компания внедрила MFA для всех администраторов, но забыла включить её для глобального администратора Azure. Хакер, получив пароль от обычного администратора, использовал его для создания GA‑аккаунта, который не требовал MFA. Через него был установлен вредоносный скрипт, отключающий системы мониторинга.

Экспертные мнения из комментариев

• «Furthermore, CISA strongly recommended that organizations avoid 'doing anything that is fucking stupid' and warned that businesses and government entities should be prepared 'not to do some asinine shit that gets you hacked.'» – FatBook‑Air

• «Not surprised. Unfortunately in my experience, GA accounts are often configured with worse security than DA/EA accounts within AD. I've never figured out why given how much damage you can do with a GA account, but it's a persist trend I've noticed in my pentests.» – Tangential_Diversion

• «GA = Global Admin. It's the highest privilege account within M365. DA = Domain Admin. EA = Enterprise Admin. Each of these account types can be used to take over each other and the whole org given how most AD shops are hybrid these days using both EntraID and on‑prem AD. The problem is in my anecdotal experience, GAs are forgotten about during hardening attempts, and a common path to popping entire orgs.» – Tangential_Diversion

• «So they used a compromised admin account to make a new GA account. This means multi‑admin support wouldn't have done anything.» – turbokid

Ключевые выводы экспертов:

1. GA‑аккаунты часто менее защищены, чем традиционные AD‑аккаунты.
2. Гибридные среды создают «мост» между облаком и локалью, усиливая риск.
3. Создание новых привилегированных ролей из‑под уже скомпрометированного аккаунта – один из самых эффективных путей эскалации.
4. Традиционные меры «мульти‑админ» не спасают, если злоумышленник уже имеет права администратора.

Возможные решения и рекомендации

Технические меры

• Обязательная MFA для всех глобальных ролей. Включить условный доступ, ограничивая вход только с доверенных IP‑адресов.
• Разделение ролей. Создать отдельные аккаунты для управления пользователями, лицензиями и безопасностью, каждый с минимальными правами.
• Контроль создания ролей. Включить Azure AD Privileged Identity Management (PIM) с обязательным одобрением запросов на повышение привилегий.
• Регулярный аудит. Настроить автоматический экспорт списка всех привилегированных ролей каждые 24 часа и сравнивать с «белым» списком.
• Логирование и SIEM. Перенаправлять события создания/изменения ролей в систему корреляции (например, Splunk, Sentinel) с меткой «привилегированный доступ».

Организационные меры

• Ввести политику «привилегированный доступ только по запросу» с обязательным сроком действия (just‑in‑time).
• Проводить обучение администраторов о рисках GA‑аккаунтов и о том, как правильно их использовать.
• Разработать процесс «отключения» неиспользуемых глобальных ролей каждые 90 дней.
• Внедрить двойную проверку (dual‑control) при создании новых GA‑аккаунтов: два независимых администратора должны подтвердить действие.

Юридические и регулятивные меры

• Обновить внутренние политики в соответствии с требованиями ISO 27001, GDPR и ФСТЭК, включив в них обязательный аудит привилегированных ролей.
• Подготовить план реагирования на инциденты, включающий «откат» созданных привилегированных ролей.

Прогноз развития ситуации

С учётом ускоренного перехода компаний в гибридные облачные среды, количество атак, направленных на привилегированные аккаунты, будет расти. Ожидается, что к 2026 году более 60 % всех крупных утечек данных начнутся с компрометации GA‑аккаунтов в облаке. Поставщики облачных сервисов уже работают над внедрением «Zero‑Trust» моделей, но без внутренней дисциплины организаций эти меры будут лишь частичным решением.

Ключевые тенденции будущего:

1. Автоматизированные проверки «привилегированных аномалий» на основе машинного обучения.
2. Расширение возможностей PIM с встроенными «превентивными» блокировками.
3. Ужесточение регулятивных требований к аудиту облачных ролей в ЕС и США.
4. Рост спроса на решения «Identity‑as‑a‑Service», позволяющих централизованно управлять GA, DA и EA ролями.

Практический пример на Python

Ниже представлен скрипт, который автоматически проверяет наличие «запрещённых» глобальных ролей в Azure AD, сравнивает их со списком разрешённых и отправляет уведомление в Microsoft Teams, если обнаружены отклонения. Скрипт использует библиотеку azure-identity для аутентификации и msgraph-core для работы с Graph API.

# -*- coding: utf-8 -*-
"""
Скрипт проверяет наличие запрещённых глобальных ролей (GA) в Azure AD.
Если обнаружены роли, не входящие в белый список, скрипт отправляет
уведомление в Microsoft Teams через webhook.
Требуется:
    pip install azure-identity msgraph-core requests
"""

import os
import json
import requests
from azure.identity import DefaultAzureCredential
from msgraph.core import GraphClient

# ------------------- Конфигурация -------------------
# Список разрешённых глобальных ролей (идентификаторы)
ALLOWED_GLOBAL_ROLES = {
    "62e90394-69f5-4237-9190-012177145e10",  # User Administrator
    "29232cdf-9323-42fd-ade2-1d097af3e4de",  # Security Administrator
}

# URL вебхука Teams (добавьте свой URL)
TEAMS_WEBHOOK_URL = os.getenv("TEAMS_WEBHOOK_URL")

# ----------------------------------------------------

def get_global_admin_roles(client: GraphClient) -> list:
    """
    Получает список всех ролей, назначенных пользователям.
    Возвращает список словарей с полями: id, displayName, roleTemplateId, principalId.
    """
    result = client.get("/directoryRoles")
    roles = result.json().get("value", [])
    global_roles = []
    for role in roles:
        # Фильтруем только глобальные роли (по шаблону роли)
        if role.get("roleTemplateId") in ALLOWED_GLOBAL_ROLES:
            continue
        # Получаем членов роли
        members = client.get(f"/directoryRoles/{role['id']}/members")
        for member in members.json().get("value", []):
            global_roles.append({
                "roleId": role["id"],
                "roleName": role["displayName"],
                "roleTemplateId": role["roleTemplateId"],
                "principalId": member["id"],
                "principalName": member.get("displayName", "N/A")
            })
    return global_roles

def send_teams_alert(violations: list):
    """
    Формирует и отправляет сообщение в Microsoft Teams.
    """
    if not TEAMS_WEBHOOK_URL:
        print("Webhook URL не задан. Пропуск отправки уведомления.")
        return

    if not violations:
        return

    text = "**Обнаружены запрещённые глобальные роли!**\n"
    for v in violations:
        text += f"- Пользователь **{v['principalName']}** имеет роль **{v['roleName']}** (ID шаблона: {v['roleTemplateId']})\n"

    payload = {"text": text}
    try:
        response = requests.post(TEAMS_WEBHOOK_URL, json=payload)
        response.raise_for_status()
        print("Уведомление отправлено в Teams.")
    except Exception as e:
        print(f"Ошибка отправки в Teams: {e}")

def main():
    # Аутентификация через DefaultAzureCredential (поддерживает Managed Identity, CLI, env vars)
    credential = DefaultAzureCredential()
    client = GraphClient(credential=credential)

    # Получаем все роли, не входящие в белый список
    violations = get_global_admin_roles(client)

    if violations:
        print(f"Найдено {len(violations)} запрещённых ролей.")
        for v in violations:
            print(f"{v['principalName']} -> {v['roleName']}")
    else:
        print("Запрещённых глобальных ролей не найдено.")

    # Отправляем оповещение в Teams
    send_teams_alert(violations)

if __name__ == "__main__":
    main()

Скрипт позволяет автоматизировать процесс контроля привилегированных ролей, своевременно выявлять отклонения и оповещать ответственных сотрудников, тем самым снижая риск «забытых» GA‑аккаунтов.