В SOC прилетел тикет средней критичности: учётка бухгалтера аутентифицировалась на контроллере домена в 2:47 ночи и запустила PsExec. DLP молчал - формально пользователь работал с файлами, доступными по роли. SIEM выдал единственный алерт: аномальное время логина. На разборе выяснилось - credentials увели через целевой фишинг, атакующий поднял RDP-туннель и четыре дня собирал финансовую отчётность перед эксфильтрацией на Dropbox. По классификации - compromised insider. По артефактам - kill chain, неотличимый от APT. По бюджету реагирования - 40 человеко-часов и полный пересмотр модели привилегированного доступа.
После этого кейса я перестал ловить все типы инсайдерских угроз одним detection-правилом и начал строить отдельные модели под каждую категорию.
Зачем пентестеру разбираться в типологии инсайдеров
Инсайдерские угрозы - не только задача blue team. На red team assessment-ах сценарий "compromised employee" или "disgruntled admin" часто становится основной моделью угроз, под которую заказчик запрашивает тестирование. Понимание TTPs каждого типа инсайдера определяет качество симуляции и релевантность отчёта.По данным Ponemon Institute / Proofpoint (Cost of Insider Risks Global Report 2023), 83% организаций зафиксировали минимум один инсайдерский инцидент, а средняя годовая стоимость - $16,2 млн. Исследование Exabeam ещё жёстче: 64% ИБ-специалистов считают внутренние угрозы информационной безопасности опаснее внешних. 42% называют злонамеренных инсайдеров главной проблемой, 22% - скомпрометированных. И при этом только 44% организаций используют UEBA - основной инструмент обнаружения инсайдерских угроз. Разрыв между масштабом проблемы и зрелостью детекции - огромный.
Три типа инсайдеров: malicious, negligent и compromised
Русскоязычные источники обычно делят инсайдеров на "умышленных" и "случайных". Бинарная классификация не отражает реальность: инцидент со скомпрометированным бухгалтером из вступления не вписывается ни в одну из этих категорий. Методология CERT Insider Threat Center и отчёты Proofpoint выделяют три категории - каждая с собственной мотивацией, kill chain и набором индикаторов.
Злонамеренный инсайдер (malicious insider)
Злонамеренный инсайдер - сотрудник или подрядчик, который сознательно использует легитимный доступ для нанесения ущерба: кража интеллектуальной собственности, саботаж систем, передача данных конкурентам. По данным CERT Insider Threat Database, финансовая выгода - один из основных мотивов malicious insider наряду с местью, идеологией и корпоративным шпионажем.Кейс Rippling vs Deel (март 2025): по материалам иска, описанного Exabeam, компания Deel внедрила сотрудника в штат Rippling под видом менеджера по комплаенсу. За четыре месяца он получил доступ к ценовым стратегиям, клиентским спискам и внутренним данным через Slack, Salesforce и Google Drive. Стандартные средства мониторинга не поймали ничего - поведенческого анализа аномальных поисковых запросов просто не было.
MITRE ATT&CK маппинг для malicious insider:
- Valid Accounts (T1078) - использование собственных легитимных credentials
- Data from Information Repositories (T1213) - массовое скачивание из SharePoint, Confluence
- Email Collection (T1114) - выгрузка почтовых ящиков через OWA или EWS
- Exfiltration over USB (T1052.001) - копирование на внешние носители
- Indicator Removal (T1070) - удаление логов, очистка истории
- Data Destruction (T1485) - саботаж: удаление баз, шифрование файлов
Небрежный инсайдер (negligent insider)
Небрежный инсайдер не имеет злого умысла. Утечка данных происходит из-за ошибок: клик по фишинговой ссылке, отправка файла не тому адресату, слабый пароль, потеря ноутбука с незашифрованным диском.Пример из отчёта Exabeam: в сентябре 2023 года сотрудник Verizon получил неавторизованный доступ к файлу с персональными данными более 63 000 человек - имена, адреса, номера Social Security, данные о компенсациях и членстве в профсоюзах. Verizon подтвердил инцидент как неавторизованный доступ изнутри, а не внешнюю компрометацию. Злого умысла не нашли, но последствия - как от целенаправленной атаки.
Отдельный вектор - GenAI. По данным Exabeam, 76% организаций зафиксировали несанкционированное использование GenAI-инструментов сотрудниками. Копирование конфиденциальных данных в ChatGPT или Claude для "быстрого анализа" - прямой канал утечки, который не покрывается классическими DLP-политиками. И это сейчас, пожалуй, самый быстрорастущий вектор negligent insider.
MITRE ATT&CK маппинг для negligent insider:
- Valid Accounts (T1078) - слабые пароли, shared credentials, отсутствие MFA
- Data from Removable Media (T1025) - неконтролируемое копирование на USB
- Data from Local System (T1005) - хранение конфиденциальных файлов в открытых каталогах
Скомпрометированный инсайдер (compromised insider)
Скомпрометированный инсайдер - легитимный пользователь, учётные данные которого захвачены внешним атакующим. С точки зрения SIEM и DLP активность выглядит как стандартная работа сотрудника. Именно это делает обнаружение инсайдерских угроз этого типа самой сложной задачей.Контекст из IBM X-Force Threat Intelligence Index 2025: infostealers - 32% от всего обнаруженного malware в 2024 году. Это основной вектор получения credentials для последующего использования скомпрометированных аккаунтов. Цепочка: infostealer на рабочей станции -> кража cookies и паролей из браузера -> продажа credentials через Initial Access Broker -> атакующий входит под легитимным аккаунтом. Чистая, красивая, почти невидимая цепочка.
Техники компрометации, описанные Exabeam:
- Pass-the-hash - использование NTLM-хэша для аутентификации без знания plaintext-пароля; типично для SMB, WMI, WinRM lateral movement (для RDP применимо только при Restricted Admin Mode)
- Фишинг - целевая доставка вредоносных ссылок или вложений
- Malware/infostealer - кража credentials через шпионское ПО
- Social engineering - получение учётных данных через звонки от имени IT-поддержки
- Valid Accounts (T1078) - украденные credentials
- Data from Local System (T1005), Data from Information Repositories (T1213)
- Indicator Removal (T1070) - зачистка следов внешним атакующим
Kill chain инсайдерской атаки в MITRE ATT&CK
Каждый тип инсайдера проходит собственную версию kill chain. Negligent insider не имеет осознанной последовательности шагов - инцидент происходит ситуативно. Для malicious и compromised типов цепочка выглядит так:| Этап | Malicious insider | Compromised insider |
|---|---|---|
| Initial Access | T1078 - собственные credentials | T1078 - украденные credentials |
| Recon | Знание инфраструктуры из рабочих процессов | Разведка через AD, SharePoint, Confluence |
| Collection | T1213, T1114, T1005 - точечный доступ к известным ресурсам | T1005, T1213 - массовый доступ с поиском ценных данных |
| Staging | Архивирование, шифрование перед выносом | Staging через temp-каталоги, staging-серверы |
| Exfiltration | T1052.001 (USB), личное облако, email | C2-канал, облачные хранилища, DNS-туннелирование |
| Cover Tracks | T1070 - удаление логов, очистка Recycle Bin | T1070 - зачистка Event Log, удаление артефактов |
| Impact | T1485 - Data Destruction при саботаже | Редко - цель: данные, а не разрушение |
Ключевая разница между malicious и compromised insider проявляется на этапах recon и exfiltration. Злонамеренный инсайдер уже знает, где лежат ценные данные, и выбирает канал эксфильтрации с низким профилем - USB, распечатка, отправка мелкими порциями. Внешний атакующий, контролирующий скомпрометированный аккаунт, тратит время на разведку, генерирует больше запросов к хранилищам и чаще использует сетевые каналы вывода данных.
Именно эта разница даёт detection-возможность: аномально высокое число обращений к SharePoint/Confluence от аккаунта, который раньше обращался к 2–3 сайтам, - сигнал compromised insider. Malicious insider так не палится - он и так знает, куда лезть.
Индикаторы инсайдерских угроз: от поведенческих аномалий до артефактов в SIEM
Поведенческие индикаторы и роль UEBA
UEBA-системы (Securonix, Varonis DatAdvantage, Microsoft Sentinel UEBA module) строят baseline нормальной активности для каждого пользователя и сущности. Отклонения от baseline формируют risk score. Конкретные индикаторы, на которые строятся detection rules:Для malicious insider:
- Резкий рост объёма скачиваемых файлов за 2–4 недели до увольнения - корреляция с HR-системой (статус "на увольнении", дисциплинарное взыскание)
- Доступ к ресурсам за пределами роли: engineer заходит в финансовые папки
- Подключение личных USB-накопителей после длительного перерыва
- Мониторинг действий сотрудников фиксирует активность в нерабочее время без исторического паттерна ночной работы
- Отправка файлов с чувствительной классификацией на внешние email-адреса
- Загрузка данных в неутверждённые GenAI-сервисы или облачные хранилища
- Множественные неудачные попытки доступа к ресурсам без прав
- Логин из нетипичной геолокации или с нового устройства
- Spike запросов к SharePoint в 2:00–5:00 при отсутствии исторического паттерна
- Одновременные сессии из разных подсетей (VPN + офисная сеть)
- NTLM-аутентификация с хостов/аккаунтов, где исторически использовался Kerberos (Event 4624 Logon Type 3 + Authentication Package NTLM) - возможный, но не самодостаточный индикатор pass-the-hash: одиночное событие 4624/Type 3/NTLM штатно для legacy-сценариев и доступа по IP. Для PtH-индикации нужна фильтрация по
LogonProcessName=NtLmSsp, корреляция с отсутствием соответствующего 4776 на DC и Kerberos TGS-запроса, плюс сравнение с baseline
Технические индикаторы: detection logic для SIEM
Ниже - примеры detection-запросов для Microsoft Sentinel (KQL). Для Splunk логика аналогична, меняется синтаксис.Аномальный доступ к хранилищам перед увольнением (malicious insider):
Код:
let termination_list = HR_TerminationNotice
| where NoticeDate > ago(30d)
| project UserPrincipalName;
OfficeActivity
| where Operation in ("FileDownloaded","FileSyncDownloadedFull")
| where UserPrincipalName in (termination_list)
| summarize FileCount=count(), UniqueFiles=dcount(SourceFileName)
by UserPrincipalName, bin(TimeGenerated, 1d)
| where FileCount > 50 // FileSize недоступен в OfficeActivity; для объёмов используйте CloudAppEvents
Код:
// NB: Non-interactive sign-ins хранятся в AADNonInteractiveUserSignInLogs - отдельная таблица
SigninLogs
| where ResultType == 0
| where TimeGenerated > ago(1d)
| extend City = tolower(tostring(LocationDetails.city))
| join kind=anti (
SigninLogs | where TimeGenerated between(ago(90d)..ago(1d))
| where ResultType == 0
| extend City = tolower(tostring(LocationDetails.city))
| distinct UserPrincipalName, City
) on UserPrincipalName, City
| project TimeGenerated, UserPrincipalName, City, IPAddressОграничения: оба запроса дают false positive при командировках и remote-работе из новых локаций. Без корреляции с HR-данными (командировки, отпуска) и без настроенного baseline UEBA ложные срабатывания сделают правила бесполезными. В Elastic 8.x+ аналогичная логика реализуется через ML-job'ы anomaly detection, а не статические запросы. В CrowdStrike Falcon insider-сценарии покрываются модулем Identity Protection. В Securonix скоринг строится через dynamic peer-group analysis - поведение пользователя сравнивается с его ролевой группой (все бухгалтеры, все инженеры).
Модель риска инсайдера: скоринг и приоритизация
Модель риска инсайдера строится на пересечении трёх осей. Подход основан на методологии CERT Insider Threat Database и адаптирован под реальные SIEM-развёртывания:| Ось | Источник данных | Пример |
|---|---|---|
| Предрасположенность (Predisposition) | HR-система, performance reviews | Дисциплинарное взыскание, отказ в повышении, статус «на испытательном» |
| Техническая возможность (Capability) | IAM, PAM, AD-группы | Привилегированный доступ к SQL-серверу с клиентской базой, права Domain Admin |
| Аномальное поведение (Behavior) | UEBA, SIEM, DLP | Spike в скачиваниях, ночные логины, подключение USB |
Risk score = f(Predisposition, Capability, Behavior). Сотрудник в процессе увольнения (Predisposition = высокая), с правами на финансовую БД (Capability = высокая), который за неделю скачал 2 ГБ из CRM (Behavior = аномальное) - его score выше, чем у developer'а с аналогичными объёмами, но без HR-факторов. Три оси вместе - работают. По отдельности - шум.
Управление привилегированным доступом (PAM) напрямую влияет на ось Capability. Принцип минимальных привилегий сужает blast radius: даже если malicious insider решит действовать, его возможности ограничены ролью. Just-in-time access (временное повышение привилегий по запросу) добавляет аудитируемый сигнал в SIEM - каждый запрос на elevated access становится событием, которое можно коррелировать с остальными аномалиями.
В Securonix risk score рассчитывается через weighted peer-group analysis. В Microsoft Sentinel - через Fusion rules и anomaly ML-models. В Varonis - через threat models, привязанные к файловой активности и правам доступа. Выбор платформы определяет точность скоринга, но сам подход - три оси - работает в любом стеке.
Red team симуляция insider-сценариев: что тестировать
Если хочется потренировать сборку цепочки от легитимных credentials до эксфильтрации на практике, а не на продакшене заказчика - задачи из категории web и pwn на HackerLab.pro (https://hackerlab.pro) дают тот же набор примитивов (credential reuse, lateral movement, data extraction), только в контролируемой среде.
На практике insider threat программа часто сводится к DLP. Ставят агент на рабочие станции, настраивают политики на регулярные выражения - номера паспортов, ИНН, ключевые слова "конфиденциально". И на этом всё.
DLP ловит negligent insider (случайную отправку файла не тому адресату) и плохо подготовленного malicious insider (пересылку документа с меткой). Но против compromised insider DLP полностью слеп: там нет аномального контента - есть аномальное поведение. Пока в SOC нет автоматической корреляции "статус сотрудника в HR + изменение паттерна доступа + spike в объёмах скачивания", insider threat программа существует только на бумаге.
По данным Exabeam, 88% организаций заявляют о наличии insider threat программы, но большинство из них - неформальные, недофинансированные, без visibility across systems. 74% ИБ-руководителей считают, что топ-менеджмент недооценивает insider risk. Пока бюджет на UEBA не появится в строке расходов наравне с EDR и NGFW, обнаружение инсайдерских угроз будет оставаться реактивным - разбором инцидента постфактум, а не превентивным детектом.
Проверьте свою инфраструктуру: возьмите low-priv учётку из любого отдела, запустите запрос к SharePoint из нетипичной подсети в 3 ночи и посмотрите, через сколько минут прилетит алерт. Если не прилетит - у вас та же проблема, что и у 56% организаций без UEBA.
Последнее редактирование модератором:
