Около 46% случаев, когда в логах инфостилеров всплывают корпоративные учётные данные, связаны с вероятно личными или неуправляемыми устройствами. Это плохая новость для компаний, которые всё ещё думают об инфостилерах как о проблеме «утёк пароль — сменили пароль». На практике логи инфостилеров всё чаще содержат не только логины и пароли, но и действующие cookies сессий, а значит злоумышленник может обойти MFA и зайти в сервис почти без шума.
Об этом сообщает BleepingComputer, пересказывая материал Flare о том, как командам безопасности разбирать такие инциденты без лишней паники и без опасной самоуспокоенности. Сценарий, который там описан, выглядит буднично и именно поэтому неприятен: у сотрудника заражается личный компьютер, например Vidar, в логе оказываются корпоративный e-mail, пароль от SaaS-приложения, браузерные cookies и другие сохранённые артефакты доступа. После этого вопрос уже не в том, менять ли пароль, а в том, не использует ли кто-то украденную сессию прямо сейчас.
Это важный сдвиг в самой логике защиты. Раньше компрометация учётки часто сводилась к проверке пароля и событий входа. Теперь в игру входят артефакты, которые не требуют нового логина: cookies, сохранённые VPN-конфигурации, автозаполнение, SSH-ключи, системная информация, данные кошельков. Для SOC это означает неприятную, но честную мысль: пароль может быть уже не самым опасным содержимым лога. Если инфостилер успел снять аутентифицированную сессию, у атакующего появляется шанс пройти мимо экрана MFA, как будто его там и не было.
Flare отдельно подчёркивает масштаб проблемы. По оценке компании, компрометация учётных данных и сессий для крупных продуктивных SaaS- и cloud-сервисов растёт примерно на 29% в год. Ещё одна деталь, которая хорошо описывает рынок: около 90% таких логов теперь появляются в Telegram, а не только на форумах и маркетплейсах дарквеба. Публичные каналы выкладывают примеры, приватные подписки торгуют более свежими наборами. Для защитников это означает неприятный дисбаланс: им нужно проверять весь поток, а злоумышленнику нужен один рабочий доступ к Entra ID, Okta, Google Cloud Identity, VPN или внутреннему RDP.
Отсюда и главный практический совет: одинаково маркировать все срабатывания как «утечка учётки сотрудника» бессмысленно. Один кейс может быть старым паролем от потребительского сайта из полугодового лога. Другой — свежей корпоративной учёткой с активной сессией в провайдере идентификации. Формально оба инцидента выглядят похоже, по факту это разный уровень угрозы. Flare предлагает сначала смотреть на то, что именно было украдено: корпоративные домены и поддомены, identity provider, session cookies, VPN/RDP-доступ, cloud-консоли. Особенно внимательно — на SSO. Компрометация одной учётки в Microsoft Entra ID или Okta может открыть дверь сразу в несколько связанных сервисов, а не в один почтовый ящик.
В статье есть здравая рамка для первых минут после обнаружения. Задача первых 60 секунд не в том, чтобы провести полное расследование, а в том, чтобы понять срочность реакции. Аналитик должен быстро ответить на несколько вопросов: когда произошло заражение, с какого устройства собран лог, сколько там корпоративных учётных данных, есть ли среди них аутентифицированные сессии. Затем добавляется бизнес-контекст. Доступ к testserver.company.com и доступ к finance.company.com — это не одна и та же история. Учётка стажёра из маркетинга и администратор с доступом к identity provider, облачной консоли и production-инфраструктуре — тоже не одно и то же. В примере Flare связка корпоративной identity-учётки и cookies сессии получает критический приоритет с целевым временем реакции меньше часа. VPN или RDP плюс несколько корпоративных учёток — высокий риск из-за потенциала для бокового перемещения.
Дальше начинается уже не теоретическая, а очень операционная работа. Нужно проверить, не использовались ли украденные данные: были ли успешные или неуспешные входы, появились ли необычные географии, новые устройства, незнакомые IP-адреса, доступ к ресурсам вне обычного профиля пользователя. Отдельный вопрос — живо ли украденное вообще. Пароль уже сменили? Сессия истекла? Учётная запись всё ещё активна? Если на этом этапе команда ограничится только сбросом пароля, можно получить опасную иллюзию, что инцидент закрыт, хотя у атакующего останется рабочая сессия и спокойное окно для дальнейших действий.
Для разработчиков, DevOps и IT-руководителей тут тоже есть неприятный, но полезный вывод. Логи инфостилеров — это не сюжет исключительно для отдела ИБ. Они бьют по тем практикам, которые бизнес любит за удобство: BYOD, входы в корпоративные SaaS с домашних машин, широкая федерация через SSO, длинные пользовательские сессии, слабый контроль над жизненным циклом cookies. Если компания активно использует облачные сервисы и одновременно закрывает глаза на то, с каких устройств туда ходят сотрудники, она фактически расширяет внешний периметр до каждого домашнего браузера. А домашний браузер, как показывает статистика Flare, часто и становится местом, где всё ломается.
Из этого следует довольно приземлённый вывод: мониторинг логов инфостилеров постепенно превращается из nice-to-have в часть identity security. Недостаточно знать, что пароль «утёк где-то там». Нужно понимать, к каким системам вёл этот доступ, действительны ли ещё сессии, и нет ли уже признаков захвата аккаунта — от странных скачиваний до привязки новых MFA-устройств. Для компаний, живущих на связке SaaS, SSO и распределённых команд, вопрос уже не в том, появятся ли их сотрудники в таких логах, а в том, успеет ли защита отреагировать быстрее, чем чужая сессия станет чужим инцидентом.