Начало истории
Понедельник, 9:45. Вторая неделя на должности IT-директора. Голова идёт кругом: план закупок на квартал, проект бюджета на следующий год, аудит безопасности, тендер на новые серверы 1С, длинный список невыполненных задач от предшественника и очередь желающих получить точный ответ — «когда наконец 1С начнёт нормально работать?».
В коридоре встречаю генерального директора.
— Слушай. Ко мне в личку пишут двое наших бывших сотрудников. Интересуются новостями из вчерашней корпоративной рассылки. Почему они её получают?
Групповые политики в AD — где-то на периферии. «Там же есть админ, он за этим следит.» Ставлю задачу начальнику техподдержки, чтобы срочно разобрались.
К обеду выяснилось, что аккаунты увольняемых сотрудников отключаются «ситуативно» — если кто‑то из сисадминов был свободен в момент подписания обходного. Раз в год проводилась одна «большая чистка» каталога AD. В остальное время почтовые клиенты на телефонах уволившихся продолжали получать внутренние рассылки и персональные сообщения адресату. За последний год через эти живые‑мёртвые ящики прошло немало конфиденциального: проект новой организационной структуры, информация об уволенных и нанятых сотрудниках, проекты коммерческих контрактов, запущённые на всеобщее обозрение случайным «Ответить всем».
Ничего не взломали. Никаких злоумышленников. Просто дисциплина офбординга не работала — и об этом я узнал случайно, потому что бывший сотрудник по привычке продолжал интересоваться жизнью в компании.
Однако в ходе разбирательства всплыла ещё более интересная деталь: аккаунты нескольких удалёнщиков, ушедших ещё в прошлом месяце, тоже были активны — и судя по логам, время от времени навещались бывшими владельцами. Это уже ситуация куда серьёзнее: корпоративная защита информации превращается в решето.
Январь 2024.
Компания по разработке систем безопасности подаёт в суд на бывшего инженера. Перед увольнением тот выкачал из корпоративного хранилища 50 ГБ исходного кода и проектной документации на новые разработки.
«Это моя интеллектуальная собственность.»
Через полгода материалы начали всплывать на профессиональных форумах и в открытых репозиториях.
Результат: Потеря технологического преимущества — ориентировочно минус 30% годовой выручки.
Иск от компании на $4 млн утонул в юридических тонкостях: доказательств когда и что было скачано — не сохранилось.
На первый взгляд ситуация выглядела как обычный организационный бардак. Но практика показывает, что именно такие истории чаще всего становятся началом гораздо более дорогих инцидентов.
По данным Ponemon Institute 2024: 74% компаний в США за последние два года столкнулись с insider data theft при увольнении. Средний ущерб — $15.4 млн. 89% случаев обнаружены постфактум — через 3–6 месяцев после ухода.
Наш первый кейс будет о двери, которую оставили открытой. Второй — о том, что вынесли, пока вход был свободный. Оба объединяет разрыв между HR и IT процессами. И в обоих случаях этот разрыв никто не мониторил.
Кейс №1: Active Directory как архив ошибок
Любая Active Directory старше двух лет — архив ошибок прошлого. Уволенные, но не отключённые. Тестовые аккаунты «на минуточку, потом удалю». Service accounts с паролями 2018 года на стикере, которого уже нет. Члены привилегированных групп, добавленные «временно» пятью администраторами назад.
Это не вина текущей IT-команды. Это мусор, который AD накапливает естественным путём.
Инструменты для аудита AD существуют — PingCastle, BloodHound, ADRecon. Все они дают данные. Ни один не отвечает на вопрос:
«Какие из этих находок актуальны для моей компании сегодня?»
Это работа ИБ-инженера, который регулярно разбирает таки случаи и составляет приоритизацию. В текущем штатном расписании такой позиции не предусмотрено. Специалист дорогой.
«Пока и так всё нормально»
Раз проблема есть, а специалиста нет — решаем привычным AI-способом.
Добавляем к нашей AISecurityPlatform ещё одного агента — AD Audit Agent. Его задача — регулярный запуск 7 проверок и возврат отчёта с «attack path hypotheses». Доступ — через закрытый чат в Telegram‑боте.
Семь проверок. Пять findings.
Пишу агенту команду: ad
🛡️ [CISO AD Audit] Запускаю 7 read-only проверок…
Через две минуты получаю отчёт с пятью наиболее опасными находками:
F1 (🔴 CRITICAL) — Account Lockout полностью отключён
Блокировка аккаунтов после неверного пароля — отключена.
Риск: Злоумышленник перебирает пароли без ограничений и без единого алерта.
MITRE T1110 — Password Spraying. С threshold = 0 атакующий с топ-100 списком корпоративных паролей гарантированно подберёт хотя бы один аккаунт из найденных.
F2 (🟠 HIGH) — t.testov (никогда не логинился, активен)
Аккаунт активен, но ни разу не использовался. Классический «забытый» — уволенный сотрудник или тестовый, которого не удалили. Готовая точка входа, которую мониторинг не замечает.
Это именно тот случай, с которого началась история с генеральным в понедельник.
F3 (🟠 HIGH) — Слабая минимальная длина пароля
Минимальная длина пароля — 7 символов. По актуальным стандартам минимум 12–14. Такой пароль взламывается офлайн за несколько часов.
F4 (🟠 HIGH) — Built-in Администратор — PasswordNeverExpires
Встроенный аккаунт «Администратор» — пароль никогда не меняется. Особенность Windows: этот аккаунт не блокируется при переборе паролей даже при включённой политике блокировки.
Уязвимость RID-500 quirk — известная фишка Windows, о которой многие senior’ы не знают. AD Agent вытащил её из тренировочных данных и связал с практической рекомендацией: Microsoft LAPS, переименовать аккаунт, break-glass usage policy.
F5 (🟡 MEDIUM) — USR1CV8 — non-expiring, без SPN
Сервисный аккаунт 1С работает по устаревшему протоколу аутентификации. Пароль не менялся, срок не ограничен. При компрометации сети — прямой доступ к базе 1С.
AI заметил противоречие в данных и сформировал гипотезу: нет SPN → auth через NTLM → возможен relay. Не описание факта — causal reasoning.
Attack Path: когда уязвимости перемножаются
В конце отчёта AD Audit Agent провёл дополнительное аналитическое упражнение и оценил, как найденные уязвимости вписываются в известные цепочки атаки.
Path 2: Подбор пароля → Администратор → полный контроль над доменом
F1 + F3 + F4 работают вместе: нет блокировки попыток + слабый пароль + пароль «Администратора» не истёк → злоумышленник перебирает пароли без риска блокировки → получает права администратора домена → доступ ко всей инфраструктуре.
F1 + F3 + F4 по отдельности — medium severity. Вместе — catastrophic. Каждый фактор усиливает следующий.
Path 3: Аккаунт 1С → перехват данных
Устаревший протокол аутентификации → перехват пароля в сети → пароль, который мог не меняться годами → полный доступ к 1С → финансовые данные и возможность ransomware.
В российских компаниях 1С — единая точка отказа для всего бизнеса. Компрометация даёт full visibility в финансовые потоки — и возможность их изменять.
ИБ-инженер ищет такие цепочки часами. AI находит за секунды.
Наш случай не уникален
Истории про «уволенный сотрудник в системе» — достаточно хорошо изученный класс security incidents:
Эдвард Сноуден, 2013 — подрядчик с расширенными привилегиями и доступом к закрытым данным. Результат многим хорошо известен.
Cisco, 2020 — умышленное уничтожение 456 виртуальных машин, что привело к отключению 16 000 аккаунтов.
Tesla, 2018 — бывший сотрудник Martin Tripp пытался нарушить работу конвейера изнутри.
Capital One, 2019 — бывшая сотрудница AWS использовала insider knowledge для атаки на клиентов банка.
Ежегодный отчёт Verizon DBIR последние пять лет ставит insider threat в топ-3 векторов утечек данных. У большинства организаций нет инструментов, чтобы этот вектор эффективно мониторить.
И каждая из этих историй начиналась с забытых учётных записей, которые кто‑то не отключил.
Кейс №2: О намерениях и действиях
AD Audit закрывает то, что уже нарушено. Но что делать в случае, когда ваш сотрудник начал не спеша готовить «запасной аэродром» и уход только зреет у него в голове? Или заявление уже написано — и есть две недели, чтобы «собрать всё необходимое» для комфортного онбординга на новом месте.
С точки зрения инфобеза его поведение предсказуемо. С большой долей вероятности, сотрудник выносит из вашей компании данные прямо сейчас.
Для таких ситуаций в корпорациях внедряют технологии UBA (User Behavior Analytics): система анализирует привычную активность и знает, что для каждого сотрудника считается обычным, а что может быть угрозой.
Представьте умного охранника, который знает каждого в лицо и по привычкам:
Маша из отдела продаж: 9:30, CRM, 15–20 звонков, запросы в 1С по клиентам и выручке, 18:00 выключает компьютер.
Петя из закупок: 8:00–17:00, открывает 1С раза два-три в день, обедает на рабочем месте.
И вот однажды охранник видит:
> «Маша. Вход в систему в 23:15. Открыла файловый архив бухгалтерии — туда никогда не заходила. Скопировала 14 папок. Ушла молча.»
> «Петя перенёс папку с результатами закупок на внешний носитель. В течение недели несколько раз отсутствовал на рабочем месте дольше обычного.»
В логике UBA — это набор сигналов: вход в нерабочее время, доступ к скрытому ресурсу \\server\, массовая загрузка файлов. Повод для более детального разбора.
Ну и классика: визиты на hh.ru или LinkedIn в рабочее время. Сотрудник, у которого в обычное время эти ресурсы — ноль запросов в неделю, вдруг появляется там 3–5 раз в день. По моей практике — один из самых надёжных ранних индикаторов. Не каждый посетитель hh.ru уходит сегодня, но тот, кто уходит, почти всегда заходил туда за 1–3 месяца до этого. В сочетании с другими паттернами — рост нехарактерной активности, повышенный интерес к папкам других отделов на сетевых дисках — это уверенный триггер для HR и ИБ.
Каждое действие по отдельности — формально легальное. Маша — сотрудник с пропуском, доступом и разрешением на удалёнку. Но в комбинации это паттерн, который нужно идентифицировать немедленно.
UBA — тот самый охранник для цифровой инфраструктуры. Без поддержки AI это не масштабируется: событий сотни тысяч в день. Никакой человек физически не успеет их интерпретировать.
Почему обычный SOC этого не делает
Парадокс: данные для UBA уже есть. Active Directory знает, кто когда логинился. EDR знает, что запускалось. Файловый сервер — кто что открывал. Прокси — куда уходил трафик.
Но никто не связывает всё это в профиль одного человека. SOC смотрит на отдельные алерты. Корреляция «один и тот же человек делает X необычных вещей за неделю» — отдельная работа, требующая отдельного инструмента.
Коммерческие UBA — Microsoft Purview Insider Risk Management, DTEX Systems — начинаются от $30 на сотрудника в месяц; в крупной компании это миллионы долларов в год. И всё равно генерируют тысячи алертов, которые кто-то должен разбирать.
Главная претензия CFO: платим миллионы за инструмент, но в реальной ситуации сигнал теряется в шуме из сотен других за тот же день.
Задача понятна .
Решение тоже.
Создаём AI-агента для агрегации алертов, их интерпретации и расстановки приоритетов реагирования.
Реализуем Insider Watch Agent: поведенческий журнал
В архитектуру AI SOC добавляем поведенческий слой из двух блоков:
«Реестр активности» — Python‑скрипт, который ежедневно считает по каждому сотруднику: время логинов, количество запущенных процессов, список хостов, обращения к внешним ресурсам, число высокоуровневых алертов.
«Опытный консультант» — AI‑агент на модели Claude Sonnet, который читает реестр и интерпретирует события:
«Активность выросла в 4 раза — обычно шум от автоматизации» — нормально.
«Активность выросла в 4 раза + логины в 2 часа ночи + впервые открыт ресурс HR$ + Яндекс Диск при baseline 0» — паттерн, эскалировать.
Тестируем логику работы
Чтобы проверить, работает ли система, симулировал уход с данными:
Создал «секретные» данные — 100 CSV-файлов с фейковыми клиентами в C:\Temp\TestExfil\
Заархивировал в .zip — типичный жест: «упакую, удобнее взять»
Загрузил на сторонний сервер через curl.exe — имитация выгрузки на личный сетевой диск
Удалил исходные файлы — чтобы не оставить следов; и одновременно второй сигнал (массовое удаление)
Каждое действие по отдельности — обычное. Все четыре за 6 секунд от одного пользователя — классический паттерн insider data theft.
Результат: AI распознал шаблон, но повёл себя сдержанно
Ответ агента:
«admin показывает рост от baseline и off-hours логоны в нерабочее время. Формально — паттерн риска для пользователя на departure list.
С учётом контекста: admin — operational account наших AI-агентов (SOAR, Purple Team, Egress probe). 4x spike без cloud DNS / новых хостов / роста high-severity alerts — вероятнее всего, friendly fire от наших же агентов, не активность человека.
Рекомендация: 🔶 Внимание, не эскалация. Проверить логи rule 67027 за 24 ч — если источник SOAR/Purple Team, закрыть как false positive.»
AI отфильтровал ложную тревогу, но не закрыл глаза — попросил подтверждения. Если это наш агент — закрывается за минуту. Если нет — есть зацепка.
Для сравнения — тот же сценарий при настоящем уходящем: Маша из продаж, в HR помечена «увольняется через 2 недели», запустила PowerShell и curl.exe (никогда раньше), массовое создание + удаление CSV, большой outbound POST:
🔴 CRITICAL — Маша «увольняемый» на departure list, day 10/14 — Spike activity 4× baseline — Новые процессы: PowerShell, curl.exe — Массовое создание + удаление файлов — Большой outbound POST (314 KB) к внешнему IP — Recommend: 🚨 ESCALATE — заморозить файловые операции, проверить рабочую машину вручную
Разница между двумя ответами — это и есть ценность UBA-системы. Не «ловит всё подряд», а точечно бьёт в реальные паттерны с учётом контекста
Два слоя — одна защита. Подводим итоги.
Реализованные внутри нашей AI платформы, AD Audit и Insider Watch — не взаимозаменяемые, а последовательные слои:
AD Audit — Полномочия уволенных, оставшихся в системе.
Insider Watch — Поведение уходящих прямо сейчас
Без первого: уволенный год назад всё ещё имеет активный аккаунт и может войти в любой момент. Без второго: сотрудник на notice period вынесет всё нужное за две недели, пока ему не отключили доступ.
Полная защита: AD Audit раз в неделю закрывает двери от предыдущих уходов, Insider Watch ежедневно наблюдает за теми, кто уходит сейчас.
Если вы пропустили начало Security серии,
В первой главе мы разбираем общие вопросы понимания возможностей AI, а также наш подход к созданию команды разработки на базе мультиагентной AI платформы.
Во второй мы учим AI рассуждать и доверяем ему управление SOAR, но решающее действие оставляем за собой.
В третей мы чуть не лишаемся доступа к собственной системе и подходим к границе, когда из‑за сбоя в цепочке рассуждений AI вместо помощи начинает выдумывать собственные правила.
Также у нас стартовал новый Data трек — AI в управлении бизнесом. В нем мы пытаемся разобраться, действительно ли AIEO скоро заменит CEO.
Первый выпуск о том, почему уже пора перестать страдать и сделать корпоративные системы по настоящему «интеллектуальными»