Подозрительная активность в корпоративной сети: мониторинг, обнаружение, реагирование

Одно уведомление в SIEM — это ещё не атака. Но иногда события складываются в четкую картину: кто-то зашёл с непривычного места, потом резко выросла его активность, пошёл странный трафик и попытки доступа к системам не по его роли.

Мониторинг событий безопасности компании нужен, чтобы увидеть связи между разрозненными событиями. Индикаторы компрометации IoC помогут отличить обычный рабочий шум от действий взломщика.

SOC проверяет признаки атаки и запускает реагирование по регламенту.

О том, как в целом выстроить процесс защиты и собрать команду реагирования, мы подробно рассказали в нашей предыдущей статье

Признаки подозрительной активности в ИТ-инфраструктуре и сети компании

Подозрительная активность в сети организации — отклонение от нормального поведения пользователя, устройства или сервиса, которое не укладывается в рабочий сценарий и похоже на этап атаки или подготовку к утечке.

Часто атака на компанию начинается с компрометации сотрудников. Подробнее о том, как распознать подозрительную активность в соцсетях и защитить личные аккаунты, мы рассказали в нашей предыдущей статье.

Обычная активность vs подозрительная активность

Таблица ниже поможет быстро сравнить норму и аномалию, чтобы не терять время на спорные трактовки. Она особенно полезна на этапе первичного SIEM-анализа, когда нужно понять, что перед вами: рабочая ситуация или аномальный трафик.

Методы мониторинга трафика — в нашем гайде

Индикаторы компрометации IoC — это технические следы, которые остаются после действий атакующего. В корпоративной среде они редко выглядят как очевидные сигналы. Чаще подозрительная активность в сети проявляется цепочкой: странный вход → нетипичные подключения → аномальный трафик → операции с данными.

Как выстроить мониторинг сети так, чтобы видеть аномальный трафик и подозрительные соединения, описали в отдельном материале

SIEM-анализ связывает эти события, чтобы понимать, где атака уже закрепилась, а где её можно остановить.

Как работает SIEM-анализ, читайте в нашем разборе.

Мониторинг аутентификации: защита от брутфорса и взлома учетных записей

Почти любая атака начинается с доступа. Мониторинг событий ИБ по аутентификации даёт самые ранние сигналы, особенно если SOC видит их в динамике, а не как единичное событие. Типовые IoC в этой зоне выглядят так:

• серия неуспешных попыток входа по одной учётке (классический брутфорс);
• password spraying: одна и та же попытка пароля по большому числу пользователей;
• успешный вход после длинной серии ошибок;
• Impossible Travel (географическая аномалия входа): вход из региона, где сотрудник физически не может находиться;
• вход в нерабочее время с нового устройства или нового клиента.

Такие события редко бывают случайными. Если SIEM-анализ подтверждает повторяемость и связь событий по одному IP-адресу, ситуацию нужно разбирать как инцидент кибербезопасности.

Привилегированные учётные записи и управление доступом (PAM)

Активность обычного пользователя и активность под админской учёткой — разные уровни риска. Учётки типа admin/root, сервисные аккаунты и технические доступы дают атакующему рычаги управления инфраструктурой, поэтому мониторинг событий ИБ по ним должен быть жёстче.

В этом месте подключается PAM — управление доступом. Оно помогает отделить штатные привилегированные операции от подозрительных, а SIEM-анализ подсветит отклонения. Для таких учёток критичны:

• входы вне регламентного окна;
• неожиданные подключения к серверам, которые не входят в зону ответственности;
• резкие изменения прав, групп и политик без заявки;
• нетипичные команды и массовые административные действия.

Если скомпрометировали привилегированную учётку, заблокируйте доступ, сбросьте токены и пароли, проверьте последние административные действия и соседние хосты.

Lateral Movement: как обнаружить горизонтальное перемещение в корпоративной сети

Lateral Movement отличает корпоративный инцидент от бытового взлома. После первого доступа атакующий почти всегда пытается пройти глубже: от рабочей станции к серверам, контроллерам домена, системам с базами данных и бэкапам. На этом шаге появляются IoC, которые хорошо видно и в SOC, и по сетевой картине.

Признаки lateral movement часто проявляются так:

• нетипичные RDP-подключения между хостами;
• попытки доступа по SMB к ресурсам, которыми пользователь обычно не пользуется;
• рост числа внутренних соединений и новый аномальный трафик внутри сегмента.

Как выглядит атака APT в корпоративной сети и почему она почти всегда включает lateral movement — в нашем разборе.

Если пропустить этот этап, злоумышленник успеет перейти на серверы и получить доступ к общим папкам, базам и резервным копиям. Тогда простая изоляция одного ПК уже не поможет — придётся останавливать сегменты сети и разбирать компрометацию сразу на нескольких узлах.

Мониторинг безопасности данных: предотвращение утечек и выгрузок

Финальная цель большинства атак — доступ к данным. Мониторинг событий ИБ должен видеть не только проникновение, но и подготовку к выгрузке информации. IoC в работе с данными часто выглядят легитимно, потому что атакующий использует обычные протоколы и штатные права.

Сигналы, которые требуют проверки и технического разбора инцидента по логам и артефактам на хосте:

• массовое чтение файлов и каталогов, не связанных с задачами пользователя;
• создание архивов и пакетов данных перед отправкой;
• резкий рост исходящего объёма и аномальный трафик на внешние адреса, часто поверх HTTPS.

Сочетание аномальной аутентификации и признаков горизонтального перемещения Lateral Movement подтверждает переход инцидента в активную фазу. Этот сценарий похож на развитие атаки, возможно злоумышленник приступил к поиску целевых активов для выгрузки или развертывания программ-шифровальщиков.

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

UEBA и MITRE ATT&CK: как читать поведение и собирать цепочку атаки

Не все атаки оставляют классические индикаторы компрометации. Часть сценариев выглядит как легитимная работа: вход под реальной учёткой, штатные инструменты администратора, обычный HTTPS-трафик. Мониторинг должен смотреть не только на отдельные события, но и на поведение пользователей, хостов и сервисов.

UEBA (User and Entity Behavior Analytics) решает эту задачу через анализ отклонений от нормы. Система сравнивает текущие действия с привычным профилем активности и подсвечивает аномалии: нетипичные входы, резкий рост обращений к данным, необычные маршруты доступа. SOC использует такие сигналы как повод проверить цепочку событий и понять, где начинается атака и куда она движется дальше.

Что такое UEBA и как поведенческая аналитика снижает ложные тревоги, читайте в отдельном материале.

MITRE ATT&CK помогает описывать эту цепочку в терминах техник злоумышленника. Вместо разрозненных событий вы получаете понятный сценарий, который можно подтвердить через SIEM-анализ и технические следы в логах.

Техники MITRE ATT&CK и признаки в логах

UEBA замечает, что поведение пользователя или устройства стало нетипичным. MITRE ATT&CK помогает понять, на какой этап атаки это похоже. SIEM связывает события в логах и показывает, что происходило.

Борьба с ложными срабатываниями «False Positive» в SIEM

В реальной эксплуатации мониторинг почти всегда даёт поток уведомлений, среди которых много шума. SIEM-анализ фиксирует отклонения, но не всегда понимает контекст: что стало причиной события и кто его инициировал. В результате SOC получает сотни однотипных уведомлений, а команда тратит время на разбор того, что не относится к атаке.

Проблема ложных срабатываний опасна не количеством. Она снижает доверие к мониторингу и мешает заметить реальную угрозу на фоне обычной активности в сети.

Типовые причины ложных срабатываний в корпоративной сети

Ложные срабатывания чаще всего возникают из-за нормальных изменений в инфраструктуре, которые выглядят как атака в логах и трафике:

• обновления софта и патчи, которые запускают массовые подключения и скачивания;
• админские скрипты и регламентные задачи, похожие на автоматизированную активность;
• легитимный VPN и смена IP-адресов, из-за которых срабатывают правила по географии и устройствам;
• внедрение новых сервисов и интеграций, которые создают неизвестные направления трафика;
• ошибки в правилах корреляции, когда SIEM-анализ объединяет несвязанные события в одну тревогу.

Если учитывать такие сценарии, мониторинг даст меньше ложных тревог, а разбор инцидентов пойдет быстрее:

Риски Shadow IT и BYOD: устранение «слепых зон» безопасности

Shadow IT — любые личные сервисы и инструменты, которые сотрудники используют для работы без согласования с ИТ и ИБ. BYOD — Bring Your Own Device — частный случай Shadow IT, когда в корпоративную сеть компании попадают личные ноутбуки и телефоны. Для бизнеса это один из самых сложных источников риска: устройства часто работают без корпоративных агентов защиты, поэтому команда ИБ теряет часть видимости и контроля.

Проблема не в самом факте BYOD. Проблема в том, что личное устройство становится слепой зоной: подозрительные действия с него выглядят как легитимный трафик пользователя, а его обращения к корпоративным сервисам и документам фиксируются частично

Типовые признаки Shadow IT и BYOD в компании:

• подключение к корпоративной сети устройств, которых нет в инвентаризации;
• доступ к рабочим данным через личные облака, почту и мессенджеры;
• использование личных VPN и прокси, которые меняют маршрут и источник трафика;
• попытки обойти корпоративный прокси или DNS-контроль.

Если компания допускает BYOD, заранее задайте правила: какие устройства можно подключать, какие данные разрешено обрабатывать, какие каналы передачи запрещены. Так вы сократите слепые зоны и снизите риск утечек через Shadow IT.

Системы мониторинга и инструменты для анализа событий ИБ

Подозрительная активность в сети заметна, когда события из разных систем сходятся в одну картину:

1. Логи и телеметрия показывают, что происходило.
2. SIEM связывает это в цепочку.
3. Аналитик проверяет версию атаки и доводит разбор до понятного результата.

Ниже краткая карта инструментов, которая поможет закрыть сеть, хосты, учётные записи и данные.

SIEM, EDR, NTA и DLP: что контролирует каждый класс средств

SIEM собирает логи из инфраструктуры и строит корреляции. На этом уровне SIEM-анализ показывает цепочки: вход → действия → попытки доступа → подозрительный трафик.

UEBA фиксирует отклонения от нормы в поведении пользователей и устройств. Полезно, когда атакующий работает тихо и использует легитимные доступы.

EDR фиксирует события на рабочих станциях и серверах: процессы, команды, попытки закрепления и выключения защиты. Эти данные часто нужны для форензики.

NTA (Network Traffic Analysis) анализирует сетевой трафик и помогает находить аномалии по направлениям, объёмам и обычным сценариям обмена данными. Важно, если атака маскируется под обычный HTTPS.

DLP (Data Loss Prevention) контролирует операции с данными: копирование, выгрузку, пересылку и попытки вынести информацию через почту, облака и мессенджеры.

Какие каналы утечки встречаются чаще всего и как их закрывать, разобрали в отдельной статье.

Аналитики SOC (Security Operations Center) связывают сигналы из SIEM и других источников, отсекают шум, подтверждают инцидент и запускают реагирование. Если отдельного SOC нет, эти задачи берёт на себя ИБ-специалист или дежурная смена ИТ — важно, чтобы роль была назначена и процесс работал.

Итог: управляемый цикл: обнаружение → проверка → реагирование → разбор причин.

Алгоритм реагирования на инциденты ИБ: пошаговый чек-лист

Реагирование начинается с проверки контекста. Специалисту ИБ нужно сопоставить аномалию, которую зафиксировал мониторинг, с бизнес-процессами. Валидация события поможет отличить рядовой сбой от целевой атаки и вовремя изолировать угрозу.

Далее надо соблюдать строгую последовательность: локализовать угрозу, провести сбор данных для форензики  — сбора цифровых доказательств — и только потом восстанавливать систему. Это критично, так как без фиксации состояния оперативной памяти и сетевых артефактов вы не сможете определить точку входа и закрыть уязвимость, и это приведет к повторной атаке в ближайшие часы

Дадим базовый чек-лист, который подходит для большинства сценариев.

Чек-лист реагирования на подозрительную активность в сети

1) Триаж (первичная оценка)

Определите масштаб: какие учётные записи, хосты и сегменты сети затронуты. Проверьте событие по нескольким источникам (SIEM, EDR, сетевые логи), чтобы отсечь ложное срабатывание.
Зафиксируйте ответственных и уведомите заинтересованных лиц: службу ИБ, ИТ, владельца сервиса, руководство по критичным системам.

2) Изоляция и сдерживание

Ограничьте распространение: изолируйте скомпрометированный хост, временно заблокируйте подозрительную учётку, перекройте опасные направления трафика на межсетевом экране. Действуйте точечно, чтобы сократить простой бизнеса.

Как межсетевой экран помогает локализовать атаку и ограничить трафик, читайте в разборе.

3) Сбор артефактов для форензики

До внесения изменений сохраните технические следы: логи, телеметрию процессов, список активных соединений, дамп оперативной памяти.
Не перезагружать и не выключать хост. Дамп памяти снимают на «горячую», иначе пропадут ключи, сессии и следы активности в RAM.

4) Устранение причины (Eradication)

Ликвидируйте точку входа и следы закрепления:

• принудительно смените пароли и ключи, отзовите токены сессий;
• исправьте избыточные права доступа;
• закройте уязвимость в ПО или опасное правило на периметре;
• проверьте persistence: планировщик задач, автозагрузку, службы, новые учётные записи админов, сторонние SSH-ключи, подозрительные агенты/скрипты.

5) Восстановление и контроль (Recovery)

Верните сервисы в работу только после очистки системы или восстановления из доверенного образа. Включите усиленный мониторинг минимум на 72 часа и проверьте, что подозрительная активность не повторяется.

6) Post-Incident Activity — работа над ошибками

Оформите отчёт «post-mortem»: что произошло, где была точка входа, почему сработали или не сработали средства защиты, что нужно изменить в SIEM-правилах, доступах, сегментации и регламентах. Зафиксируйте задачи и сроки, иначе инцидент повторится тем же способом.

Как управлять скоростью защиты —  регламенты и метрики

Регламенты реагирования и метрики MTTD/MTTR — это способ управлять рисками и скоростью восстановления бизнеса.

Без чётких правил информационная безопасность предприятия будет под угрозой: команда будет паниковать и путаться. Чтобы в критических случаях не терять времени, нужен  регламент, который зафиксирует следующее:

• Ответственность: кто разрешает изоляцию сервера или блокировку пользователя.
• Форензику: кто собирает артефакты для расследования до того, как они будут затерты.
• Коммуникации: кто и в какие сроки уведомляет руководство и бизнес‑подразделения.
• Исправление: кто устраняет первопричину — уязвимость или ошибку настройки.

Метрики: MTTD и MTTR

MTTD и MTTR показывают, насколько быстро команда обнаруживает атаку и сдерживает инцидент:

• MTTD (Mean Time To Detect) — среднее время от начала атаки до обнаружения. Показывает эффективность мониторинга и качество правил корреляции в SIEM.
• MTTR (Mean Time To Respond) — среднее время от обнаружения до первых мер сдерживания: изоляции хоста, блокировки учётной записи, ограничения опасного трафика. Показывает скорость реакции команды.

Обычно эти данные автоматически собирают IRP/SOAR-системы или продвинутые SIEM. Если их нет, метрики считаются вручную на основе журнала инцидентов (время атаки по логам vs время закрытия тикета).

Формулы расчёта:

• MTTD = Σ(время обнаружения − время начала атаки по логам) / кол-во инцидентов
• MTTR = Σ(время первых мер − время обнаружения) / кол-во инцидентов

Полное устранение причины и восстановление сервисов обычно считают отдельно (например, MTTF/MTTRec). Эти этапы зависят от масштаба инцидента и сложности инфраструктуры.

Как читать показатели — пример отчета

Зачем это бизнесу? Руководство видит, что MTTR снизился в три раза и понимает: инвестиции в мониторинг — это реальное сокращение времени простоя компании.

Чек-лист: готов ли мониторинг:

• [✓] SIEM выявляет Lateral Movement и аномальную аутентификацию.
• [✓] Определены критичные активы и нормальная активность для них.
• Регламент ИБ описывает роли и действия при подтверждении атаки.
• MTTD/MTTR считают и анализируют минимум раз в месяц.

Использование MTTD и MTTR помогает выполнять требования ГосСОПКА и ФСТЭК России в части контроля сроков реагирования. Инцидент должен быть не только зафиксирован, но и локализован в установленные сроки. Регулярный замер метрик подтвердит готовность компании к отражению атак и даст прозрачную отчетность при проверках.

FAQ: Часто задаваемые вопросы

Как отличить подозрительную активность в сети от «шума» SIEM?

Проверьте, складываются ли события в цепочку. Одиночное оповещение часто бывает ошибкой, но реальный инцидент всегда оставляет серию следов: вход в систему → нетипичные сетевые подключения → попытка повысить права → манипуляции с данными. Аналитик должен связать алерты по времени, хосту и учетной записи — повторяемая связка почти всегда указывает на атаку.

Почему аномальный трафик часто маскируется под обычный HTTPS (порт 443)?

Хакеры используют шифрование, чтобы спрятать команды управления и выгрузку данных внутри стандартного веб-трафика, который обычно не блокируется. Чтобы обнаружить угрозу, мониторинг должен анализировать косвенные признаки: обращения к редким доменам, нетипичные объемы исходящих данных, длительность сессий и частоту запросов («маячки»).

Что делать при обнаружении подозрительной активности: базовый порядок?

Соблюдайте строгий алгоритм:

1. Триаж (подтверждение инцидента).
2. Изоляция (блокировка учетки или хоста).
3. Форензика (сбор дампов и логов для расследования).
4. Устранение причины (смена паролей, закрытие уязвимости).
5. Восстановление. Такой порядок позволяет локализовать ущерб, сохранить улики и исключить повторный взлом.

Главное

Подозрительная активность в сети — признак этапа атаки. Оценку нужно строить на корреляции сигналов: аномальная аутентификация, нетипичные сетевые соединения, операции с данными. Одиночное событие редко даёт полную картину: решает последовательность действий.

Индикаторы компрометации (IoC) дают результат в связке с индикаторами атаки (IoA) и анализом поведения. Статические IoC — списки IP, домены, хеши файлов — быстро устаревают и часто не отражают реальный сценарий. Инцидент подтверждается через IoA, когда цепочка действий по одной учётной записи или хосту совпадает с техниками из MITRE ATT&CK.

Мониторинг должен показывать трассировку инцидента, а не поток уведомлений. Для быстрого триажа система должна отвечать на четыре вопроса: кто инициировал активность, какой был вектор доступа, какие системы затронуты, какой объём данных оказался под риском.

SIEM-анализ связывает разрозненные логи в приоритизированные сценарии. Корреляция по времени, учётным записям и активам выделяет критичные векторы: компрометацию привилегированных учётных записей, горизонтальное перемещение (Lateral Movement), подготовку к выгрузке данных.

Реагирование на инциденты ИБ начинается с фиксации цифровых следов до восстановления. Сначала выполняют изоляцию и сдерживание, затем собирают артефакты для расследования. Устранение причины без анализа следов часто приводит к повторной компрометации через ту же точку входа.