Фишинг остается одной из самых частых причин компрометации корпоративной инфраструктуры. Несмотря на фильтры, обученных пользователей и защиту на конечных точках, такие атаки регулярно достигают цели и приводят к инцидентам.
На первый взгляд кажется, что все просто: вредоносное письмо нужно обнаружить и удалить. На практике же процесс выглядит иначе.
Проблема не в том, чтобы найти отдельное письмо — а в том, чтобы успеть остановить атаку до того, как она развернется. Для этого реагирование должно работать иначе: быстро, массово и без привязки к ручным действиям.
В этой статье разберем, как можно выстроить такой процесс — от первого сигнала до автоматического применения решения ко всей рассылке, чтобы фишинг не успевал превращаться в инцидент даже без сложных систем оркестрации.
Скорость атаки vs скорость реакции
Представим типичный сценарий: фишинговое письмо приходит на почту в 10:03. Уже через пару минут находится тот, кто открывает ссылку, не колеблясь, — пока другие сомневаются или просто игнорируют письмо. Этого достаточно, чтобы опередить любую команду реагирования.
К тому моменту, когда появляется первый сигнал (пользователь нажал «Сообщить о фишинге» или сработала защита на конечной точке) атака уже развивается. Через некоторое время инцидент доходит до аналитика, начинается проверка и принимается решение — но это уже середина процесса, а не его начало.
Фишинг почти никогда не ограничивается одним письмом. Обычно это рассылка, одновременно достигающая десятков сотрудников. Пока одно письмо разбирается вручную, его копии продолжают находиться в почтовых ящиках других сотрудников.
В результате возникает разрыв между скоростью атаки и скоростью реагирования. Пользователю достаточно нескольких минут, чтобы совершить ошибку, тогда как защите требуется значительно больше времени для обнаружения и обработки инцидента. Именно этот разрыв определяет последствия.
Поэтому задача уже не просто находить фишинг. Важно научиться реагировать на него так же быстро и массово, как он распространяется.
Если реагирование должно быть быстрым и масштабируемым, его нельзя строить вокруг ручных действий. Любой процесс, в котором ключевое решение принимает человек, упирается во время: нужно увидеть сигнал, открыть тикет, разобраться, принять решение. Даже хорошо настроенный SOC не способен делать это за секунды.
Отсюда простая мысль: реагирование на фишинг должно работать как непрерывный поток, а не как последовательность ручных шагов.
Вместо привычной модели «получили сигнал → разобрали → удалили письмо» появляется другой подход. Любое подозрительное письмо проходит через несколько автоматизированных этапов: сначала фиксируется сигнал, затем письмо изолируется, после этого проводится анализ, на основе которого принимается решение, и только потом оно применяется ко всей инфраструктуре.
Эти этапы не зависят от человека и не требуют ручного запуска — сигнал сам становится триггером, запускающим всю цепочку.
В более зрелом виде такую логику реализуют через SOAR или похожие системы оркестрации, но дело не в выборе конкретного инструмента. Аналогичная схема может быть собрана из простых компонентов: API почтовой системы, нескольких внешних сервисов проверки и небольшого слоя логики, который связывает их вместе.
Главная идея в том, что система перестает «разбирать письма» по отдельности и начинает обрабатывать инциденты как поток. Если одно и то же письмо получили несколько сотрудников, оно рассматривается как единая сущность — и решение применяется сразу ко всем экземплярам.
На практике такая схема может выглядеть как полностью связанный автоматизированный процесс. Например, фишинговая рассылка попадает в почтовые ящики сотрудников, после чего один из защитных механизмов — почтовый шлюз, EDR или пользовательская жалоба — формирует событие о подозрительном письме. Информация об этом автоматически отправляется в SIEM, где событие коррелируется с другими сигналами: количеством получателей, репутацией домена, наличием похожих писем или активностью на конечных точках.
После этого SIEM передает инцидент в SOAR-платформу, которая запускает заранее подготовленный сценарий реагирования. SOAR через API почтовой системы находит все экземпляры подозрительного письма и массово перемещает их в карантин, чтобы сотрудники больше не могли взаимодействовать с вложениями или ссылками. Одновременно система может заблокировать связанные домены или URL на уровне почтовой защиты, прокси или DNS-фильтрации.
Но на этом автоматизация не заканчивается. SOAR может дополнительно обогащать инцидент данными о пользователях, получивших фишинговое письмо: подразделение, уровень доступа, предыдущие случаи взаимодействия с подозрительными сообщениями или результаты прошлых проверок на фишинг. Эти данные позволяют не только реагировать на текущую атаку, но и снижать вероятность повторных инцидентов.
Например, сотрудники, попавшие в такую рассылку или взаимодействовавшие с письмом, могут автоматически добавляться в сценарий дополнительного обучения через корпоративную платформу awareness-тренингов. Им назначаются короткие курсы, тесты или симуляции фишинговых атак, направленные на повышение внимательности к подобным сообщениям. В результате процесс перестает ограничиваться только техническим устранением угрозы и начинает работать как замкнутый цикл: обнаружение, изоляция, нейтрализация и последующее снижение риска через обучение пользователей.
Такой подход меняет не только скорость, но и сам характер действий. Вместо точечных реакций появляется массовая: письмо либо безопасно возвращается пользователю, либо исчезает из всех почтовых ящиков одновременно. Разница между ручным и автоматизированным подходом становится особенно заметна в момент массовых рассылок. Пока ручное реагирование пытается последовательно разбирать отдельные письма и инциденты, автоматизированный процесс работает сразу со всей атакой как с единым событием. На практике это меняет не только скорость реакции, но и саму модель работы.
Чтобы это стало возможным, процесс нужно разбить на четкие этапы. Каждый из них решает свою задачу, но вместе они обеспечивают быстрое и контролируемое устранение угрозы.
От сценария к процессу
Начало процесса — детекция, момент, когда система впервые фиксирует подозрительное письмо. На практике сигнал появляется хаотично: пересылка письма в ИБ, вопрос в чате «это нормально?», иногда создается тикет, иногда нет. Именно такие обращения чаще всего становятся первыми индикаторами проблемы.
Почтовые фильтры, конечно, отсекают часть откровенного мусора, но полностью на них полагаться нельзя: фишинговые письма регулярно проходят мимо базовых проверок, особенно если атака адаптирована под компанию.
Иногда сигнал поступает не от пользователя, а от систем защиты на конечных точках. Например, если сотрудник уже перешел по ссылке или открыл вложение, это фиксируется как подозрительная активность. В таких случаях становится ясно, что письмо было опаснее, чем казалось изначально.
На практике «единой точки детекции» обычно нет. Сигналы приходят из разных источников, в разное время и с разной степенью надежности. Задача системы — не угадывать идеально, а уметь реагировать на любой из сигналов. Как только появляется хоть какой-то индикатор, он автоматически запускает следующий этап — изоляцию письма.
Первый импульс многих команд — сразу удалить подозрительное письмо. Казалось бы, это логично: меньше риска, что пользователь попадется на фишинг. Но такой подход быстро оборачивается проблемами. Во-первых, ошибки неизбежны: даже очевидное на первый взгляд письмо может оказаться легитимным. Автоматическое удаление в этом случае создает риск для бизнеса — можно потерять важную информацию или нарушить коммуникацию. Во-вторых, удаление уничтожает «тело» инцидента: заголовки, метаданные и ссылки исчезают, лишая аналитиков возможности провести расследование и понять источник атаки.
Поэтому на практике используют более безопасный подход — карантин. Письмо временно убирается из доступа, но не исчезает окончательно. Реализация может быть разной: встроенные механизмы почтовой системы, правила на шлюзе или простое перемещение через API в отдельную папку. Даже скрипт, который автоматически забирает письмо и помещает его в хранилище, уже решает задачу.
Для пользователя это обычно выглядит как «письмо пропало» или «не дошло», что не идеально, но такой компромисс безопаснее, чем оставить потенциальный фишинг в ящике.
Главная идея карантина проста: при малейшем подозрении письмо временно изолируется, чтобы система могла оценить его безопасность. Это дает необходимое время для анализа — этапа, цель которого понять, что это за письмо и насколько оно опасно. Без такой изоляции автоматизация либо становится слишком агрессивной и мешает работе, либо слишком медленной и пропускает атаки. При этом сам анализ не требует «магии»: это тот же разбор, который обычно проводит специалист вручную, просто разложенный на последовательные и повторяемые шаги.
Почти любой фишинг использует URL: ссылки ведут на поддельные страницы, запускают загрузку файлов или выполняют редиректы. На этапе анализа из письма извлекаются все ссылки и проверяются по доступным источникам — публичным сервисам, внутренним спискам или накопленным данным. Даже базовая проверка позволяет выявить подозрительные признаки: новый или ранее встречавшийся домен, аномалии в репутации.
Далее оцениваются вложения, если они есть. В идеале их отправляют в sandbox для анализа поведения, но на практике это не всегда быстро и доступно. Более простой вариант — проверка хешей по известным базам или хотя бы учет наличия вложения как дополнительного риска.
Особое внимание уделяется отправителю: насколько домен похож на легитимный, проходят ли проверки SPF и DKIM, встречался ли адрес в компании ранее. Часто уже на этом этапе становится понятно, что письмо «маскируется» под что-то знакомое.
Ни один из этих признаков сам по себе не дает окончательного ответа. Подозрительный домен не гарантирует фишинг, а чистый результат проверки не делает письмо безопасным. Поэтому решение принимается на основе комбинации факторов. Например, можно использовать простое правило: «есть внешняя ссылка + новый домен + вложение = высокий риск». Задача анализа — быть не идеальным, а быстрым и предсказуемым. Ошибки все равно будут, но если система в большинстве случаев правильно отделяет явный фишинг от безопасных писем, она существенно экономит время. Так формируется приближенный вердикт: письмо скорее опасное или скорее безопасное. Этого достаточно, чтобы перейти к следующему этапу — применению решения.
На этапе применения решения проявляется разница между ручной и автоматизированной обработкой. В привычной модели аналитик проверяет каждое письмо по отдельности, решая: удалить, проигнорировать или эскалировать. Даже если это копии одной фишинговой рассылки, обработку приходится повторять для каждого экземпляра, что занимает много времени.
Автоматизация меняет подход: письмо рассматривается не как единичный объект, а как часть рассылки. Если оно дошло до нескольких пользователей, система применяет решение сразу ко всем его копиям.
Если анализ показывает, что письмо явно вредоносное, реакция должна быть быстрой и масштабной: оно удаляется из почтовых ящиков всех получателей, при необходимости блокируются связанные ссылки или домены, а пользователи получают короткое уведомление о фишинге. В этот момент угроза фактически «гасится» целиком, а не по отдельным случаям.
Если ситуация менее однозначная, письмо остается на ручной разбор. Автоматизация не обязана принимать решения в 100% случаев — ее задача фильтровать очевидные угрозы и экономить время аналитиков.
Если письмо выглядит безопасным, оно возвращается пользователю. Это важно: иначе система мешает работе, и люди начинают искать обходные пути или теряют доверие к почте.
В итоге схема проста, но эффективна: сначала подозрительное письмо изолируется, затем быстро оценивается, а дальше массово удаляется, передается на ручной разбор или возвращается пользователю. Ключевое здесь — скорость и масштаб. Решение применяется сразу ко всей рассылке, что сокращает время реакции с десяти минут до практически мгновенного действия.
Но на этом процесс не заканчивается. Каждый инцидент становится источником данных для улучшения логики реагирования. Если результат анализа просто удаляется, система остается статичной и постоянно сталкивается с повторяющимися сценариями.
Чтобы этого избежать, результаты разбора сохраняются и используются для будущих проверок. Например, вредоносный домен или URL добавляется во внутренний список блокировки — следующая подобная попытка либо блокируется сразу, либо распознается быстрее. Аналогично учитываются повторяющиеся признаки: домены отправителей, похожие адреса (например, имитирующие известные компании), темы писем и характерные шаблоны рассылки. Даже если адреса каждый раз разные, такие совпадения позволяют быстрее распознавать и обрабатывать похожие атаки в будущем.
Даже простое логирование инцидентов дает ценную информацию: какие типы фишинга встречаются чаще, какие проверки реально помогают, а какие почти не дают результата. Это формирует базу для доработки правил и повышения эффективности процесса. Со временем система смещается от реакции к предсказуемости: она не становится идеальной, но начинает быстрее и точнее обрабатывать повторяющиеся сценарии. При этом важно понимать реальную картину — описанный процесс логичен, но чаще встречается как целевая архитектура, чем как готовое решение «из коробки». На практике возникает вопрос: сколько из этого реально внедрить без сложных систем и больших бюджетов? Ответ: больше, чем кажется.
Даже в базовом варианте можно собрать рабочий процесс, покрывающий значительную часть сценариев. Например, письма, которые пользователи пересылают в ИБ, можно автоматически забирать через API почтовой системы, извлекать из них ссылки, делать внешние проверки и принимать простое решение на основе правил.
Такая логика не требует сложной оркестрации: достаточно небольшого сервиса или скрипта, который последовательно выполняет эти шаги. Если результат явно указывает на фишинг, то письмо удаляется у всех получателей. Если нет — остается на ручной разбор.
Да, это не идеальная система: нет сложных сценариев, корреляции десятков источников или гибкой настройки процессов. Но даже такой упрощенный вариант закрывает самый болезненный участок — массовые и очевидные атаки, на которые раньше тратилось время аналитиков.
Именно здесь проходит граница между простой автоматизацией и полноценным SOAR. SOAR становится необходим, когда количество источников, проверок и действий растет: появляются десятки интеграций, сложные ветвления логики, необходимость отслеживать состояние инцидентов и управлять ими централизованно. До этого момента достаточно более простых решений.
Важно понимать ограничения: ложные срабатывания неизбежны. Но в автоматизации они предсказуемы и отлавливаются при отладке. Худшее, что случится — письмо уйдет в карантин, откуда его легко вернуть. Здесь нет идеального баланса, только компромисс между скоростью, точностью и влиянием на пользователей. И это не страшно, потому что цена ошибки — не пропущенная атака.
Что меняется на практике
Автоматизация не заменяет аналитика полностью — она снимает рутину и освобождает время для более сложных задач. В результате трансформируется сама роль: вместо постоянного ручного разбора потока писем фокус смещается на действительно важные и нетипичные инциденты. При этом фишинг никуда не исчезает, меняется другое — кто контролирует скорость. В ручной модели атака почти всегда оказывается быстрее: пользователю достаточно одного клика, тогда как защите требуется значительно больше времени, чтобы среагировать, и именно этот разрыв превращает массовую рассылку в инцидент.
Автоматизация не делает систему идеальной — ошибки и неточности остаются. Но она меняет критически важное — время реакции и масштаб действий. Сигнал превращается в действие за секунды, а письмо перестает рассматриваться как единичный случай — решение применяется сразу ко всей рассылке. В результате фишинг перестает быть набором отдельных инцидентов и превращается в поток событий, который система обрабатывает автоматически — быстро, массово и предсказуемо. Ключевая граница зрелости проходит не в качестве анализа отдельных писем, а в способности быстро остановить атаку целиком.
Когда реакция начинает работать быстрее пользователя, фишинг перестает быть кризисом. Он становится фоновым шумом, который система гасит до того, как он успевает превратиться в проблему.
Автор:
Никита Ваулин, инженер направления автоматизации ИБ, УЦСБ