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

Короче, что в дайджесте?

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

  • Внешний периметр. Citrix NetScaler, MikroTik RouterOS и WordPress оказались в центре внимания из‑за сообщений об эксплуатации уязвимостей.

  • Фишинг и удалённый доступ. Исследователи массово описывали кампании против российских организаций, в которых использовались вредоносные рассылки, украденные VPN‑учётные записи и легитимные инструменты удалённого подключения.

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

  • Финансовые атаки. Android‑троян RedWing и FMVT RAT демонстрируют риски для мобильных устройств, бухгалтерских рабочих мест и систем дистанционного банковского обслуживания.

  • Готовность к инцидентам. Резервные копии, контроль клиентских данных и проверка доверенных интеграций остаются практическими задачами, а не формальностью.

  • План действий и приоритеты исправлений. Подготовили для вас таблицу с планом действий и рекомендации по срочности исправлений.

Дисклеймер

Публикация охватывает период с 1 по 30 сентября 2026 года и основана на доступных открытых источниках. Часть материалов представляет собой пересказы исследований, а некоторые сообщения не содержат полного технического разбора. Оценки UPS отражают состояние каталога на дату наблюдения и не восстанавливают историческую срочность на конец отчётного периода. Утверждения об эксплуатации, масштабе инцидентов и атрибуции необходимо оценивать с учётом подтверждающих данных. Для обоснованных решений о блокировках, реагировании и подтверждении компрометации следует сверять первичные бюллетени производителей, точные версии продуктов и локальные журналы организации. IP‑адреса, домены, DNS‑записи и сертификаты сами по себе не доказывают принадлежность инфраструктуры злоумышленникам или факт взлома конкретной компании.

Берегись, внешний периметр

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

В сентябре внимание привлекли три продукта: Citrix NetScaler, MikroTik RouterOS и WordPress Core.

  • По Citrix NetScaler в конце сентября были опубликованы данные об активной эксплуатации CVE-2026-88772 (CyberOK News, Google Cloud Threat Intelligence); вендорский и исследовательский контекст также указывают на CVE-2026-88771, а текущая оценка UPS относит обе записи к Emergency / IR.

  • Для MikroTik RouterOS в сентябре появилась публикация об атакующей цепочке CVE-2026-67279/CVE-2026-86060, а также уведомление НКЦКИ и соответствующие записи в каталогах уязвимостей.

  • В случае WordPress Core сообщалось о попытках эксплуатации CVE-2026-87902 (CyberOK News, Kaspersky, The Hacker News). Здесь важно искать не только сам факт использования WordPress, но и конкретные признаки атаки, включая попытки подключения локальных PHP‑файлов и записи временных файлов.

Что это значит для бизнеса?

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

Фишинг жив!

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

В сентябре исследователи описали несколько кампаний против российских организаций.

  • F6 исследовала Mimbrob против ВПК, IT‑компаний и военных;

  • BI.ZONE сообщила о LxBase RAT в массовых рассылках июля‑сентября против российских компаний.

  • Kaspersky описала активность NightEagle в инфраструктуре российских компаний с использованием скомпрометированных VPN‑учётных записей, GhostContainer на Exchange, Dev Tunnels и rdp2tcp;

  • Positive Technologies исследовала DENOmination Group, использовавшую цепочки на Deno, а Kaspersky также выделила Toy Ghouls с MQTT/Matrix‑бэкдорами.

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

Что это значит для бизнеса?

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

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

Разработчик, не спи!

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

Что это значит для бизнеса?

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

Банковские трояны: от телефона до бухгалтерского компьютера

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

  • В сентябре F6 описала Android‑троян RedWing, распространявшийся в России через поддельные приложения и видео, с удалённым управлением, перехватом SMS, оверлеями и проксированием.

  • Также F6 отдельно описывали троян удалённого доступа FMVT RAT, ориентированный на бухгалтерские рабочие места, считыватели смарт‑карт и операции дистанционного банковского обслуживания.

Что это значит для бизнеса?

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

В доступных материалах не перечислены конкретные банки, пострадавшие от RedWing или FMVT RAT, поэтому описанные угрозы следует рассматривать как основание для оценки собственных сценариев защиты, а не как подтверждение компрометации определённой организации.

Руки вверх: клиентские данные и вымогательство

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

  • В сентябре российское деловое СМИ со ссылкой на выступление руководителя крупного регионального медучреждения сообщило о кибератаке с требованием выкупа; данные на серверах, по этому сообщению, удалось восстановить благодаря резервному копированию. Это не раскрывает технический вектор атаки и не доказывает более широкую кампанию, но даёт практический сигнал для организаций с критичными медицинскими, кадровыми и финансовыми данными.

  • SecPost сначала пересказал заявление  злоумышленников крупной утечке у российской сети общественного питания, а затем сообщил о позиции компании: она признала кибератаку на ИТ‑систему, допустила попадание в открытый доступ части клиентских данных, указала на отсутствие платёжной информации в затронутом контуре, блокировку доступа атакующих и уведомление регулятора. Масштаб и состав утечки остаются заявлением сторон и не подтверждены независимым техническим разбором.

Что это значит для бизнеса?

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

А что делать? Приоритеты для ИБ‑команд

1. Выделить срочное окно для проверки внешне доступных систем.

Citrix NetScaler, MikroTik RouterOS, WordPress: для каждого продукта установите точную версию, доступность извне, наличие исправлений и признаки эксплуатации. Не присваивайте всем системам одинаковый приоритет: учитывайте бизнес‑критичность, достижимость уязвимой функции и наличие следов компрометации.

2. Искать следы проникновения.

Поручите SOC и администраторам почты/VPN/Exchange поиск следов до текущей даты или на доступную глубину журналов: фишинговые вложения, подозрительные VPN‑входы, туннели, RDP‑переходы и новые службы на серверах.

3. Проверить цепочку разработки и секреты.

Проведите инвентаризацию зависимостей, расширений редакторов и используемых пакетов. Сопоставьте их с конкретными вредоносными версиями и индикаторами из исследовательских материалов. Проверьте токены CI/CD, ключи публикации, доступы к репозиториям и облачные секреты. Если подтверждена компрометация, отзывайте и заменяйте именно затронутые секреты после проверки артефактов и возможного использования.

4. Усилить контроль доверенных каналов

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

5. Связать ИБ и антифрод

Для банков и компаний с ДБО объедините анализ событий на бухгалтерских станциях, мобильных устройствах и платёжных операциях. Проверьте сценарии выявления RedWing и FMVT RAT, а также необычной активности в системах удалённого доступа.

6. Проверить восстановление и реагирование на утечки

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

7. Как определить, что исправлять срочно

Чтобы определять срочность исправления уязвимостей, мы в СайберОК запустили открытый каталог уязвимостей cKEV Index. Система опирается на Urgent Patch Score (UPS) — методику приоритизации, благодаря которой уязвимость рассматривается как объект, который «созревает» во времени. Важна не только оценка, но и конкретные события: появился PoC, был собран готовый эксплойт или подтвердилось использование уязвимости в атаках.

  • Urgent Patch означает «исправить срочно»;

  • Emergency / IR — немедленно обновить систему и проверить возможный взлом.

  • Баллы (cKEV score) — компактное число для сортировки очереди, полученное из UPS‑сигналов. Чем выше — тем ближе к немедленному действию.

KEV подтверждает известную эксплуатацию, но итоговый приоритет зависит от конкретной инфраструктуры организации.

*Оценки приведены на дату сбора; историческое значение на конец отчётного периода не восстанавливалось. Отсутствие оценки не означает низкий риск.
*Оценки приведены на дату сбора; историческое значение на конец отчётного периода не восстанавливалось. Отсутствие оценки не означает низкий риск.

План действий

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

  • Метка P1 означает срочную задачу, которую нужно выполнять сразу, если условие относится к вам.

  • Метка P2 означает плановую задачу, которую выполняют в указанный срок.

  • При признаках проникновения сразу начинайте реагирование.

Приоритет

Направление / угроза

Условие

Срок

Ответственный

Что сделать

Как подтвердить выполнение

P1

Уязвимости внешнего периметра

Есть внешне доступные Citrix NetScaler ADC/Gateway, MikroTik RouterOS или WordPress с применимой уязвимой версией/конфигурацией либо признаки эксплуатации CVE-2026-88771, CVE-2026-88772, CVE-2026-67279, CVE-2026-86060 или CVE-2026-87902.

В течение 24 часов инвентаризировать системы и ограничить риск. Исправить или применить компенсирующую меру сразу после подтверждения применимости.

Владелец инфраструктуры совместно с SOC и владельцами сайтов

Инвентаризировать узлы и версии; проверить внешнюю доступность и конфигурацию; установить исправления или ограничить доступ; выполнить поиск следов эксплуатации, включая веб‑оболочки, новые учётные записи, подозрительные команды и изменения конфигурации.

Реестр проверенных узлов с версией, экспозицией и решением; статус патча/компенсирующей меры; сохранённые поисковые запросы и результаты проверки журналов за период возможной эксплуатации.

P2 → P1 при совпадении

Фишинг и удалённый доступ

Используются корпоративная почта, VPN, Exchange, RDP/WinRM или организация относится к отраслям, упомянутым в описанных российских кампаниях.

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

SOC; администраторы почты, VPN и AD; владелец реагирования на инциденты

Проверить фишинговые вложения, подозрительные VPN‑входы, туннели, Dev Tunnels/rdp2tcp, новые службы, Deno/Node‑процессы и нестандартные подключения к Exchange. Проверять период июль‑сентябрь 2026 года либо всю доступную глубину журналов.

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

P1

Вредоносные пакеты, расширения и артефакты разработки

В SBOM, lock‑файлах, кэше разработчиков, CI/CD или браузерной политике найдено точное совпадение с вредоносной версией пакета, расширением, скриптом или другим артефактом либо обнаружена связанная с ним несанкционированная активность.

В течение 48 часов после обнаружения совпадения.

AppSec/DevSecOps совместно с владельцами CI/CD и IAM

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

Выгрузка проверенных репозиториев и рабочих мест; точные совпавшие версии/ID расширений; список отозванных секретов с основанием; подтверждение чистой пересборки.

P2

Сторонние скрипты, виджеты и ClickFix

На публичных сайтах используются сторонние виджеты/маркетинговые скрипты или примерные домены из документации; есть устройства без агента EDR с доступом в интернет.

В течение 15 рабочих дней. Подозрительные текущие подключения разбирать без ожидания окончания срока.

Владельцы сайтов, сетевой мониторинг и SOC

Составить реестр сторонних скриптов и доменов; проверить неожиданные соединения с рабочих станций и устройств без EDR; настроить обнаружение ClickFix и запусков PowerShell/msiexec из браузера.

Реестр разрешённых сторонних доменов с владельцами; журнал исключений; результаты сетевого мониторинга неизвестных соединений; правила обнаружения браузерных запусков команд.

P2

RedWing, FMVT RAT и финансовое мошенничество

Организация использует ДБО, обслуживает клиентов банковских приложений или имеет бухгалтерские рабочие места со смарт‑картами/токенами.

В течение 10 рабочих дней проверить контроли. При подтверждённом заражении устройства или станции — немедленно реагировать.

Антифрод, SOC, владелец ДБО и руководитель бухгалтерии

Усилить обнаружение оверлеев, перехвата SMS, проксирования, необычных операций ДБО и компрометации бухгалтерских станций; определить порядок блокировки операций и перевыпуска средств доступа.

Согласованы признаки высокого риска; тестовые срабатывания доходят до ответственного подразделения; документирован маршрут блокировки операций и перевыпуска средств доступа.

P2

Резервное копирование и восстановление

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

В течение 20 рабочих дней. При признаках вымогательства или недоступности серверов — немедленно перейти к реагированию.

Владелец непрерывности бизнеса, ИТ‑эксплуатация, SOC и владельцы ключевых систем

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

Протокол тестового восстановления с фактическими RTO/RPO, перечнем систем и ответственными; подтверждено, что минимум одна копия недоступна для изменения из основной доменной среды.

P2

Доверенные почтовые, облачные и удалённые каналы

Есть внешние поставщики с правом отправки писем или удалённого доступа, устаревшие MX‑пересылки, разрешённые RMM‑инструменты, облачные формы входа или устройства без EDR.

В течение 10 рабочих дней обновить реестр доверенных каналов и правила проверки. Подозрительные текущие подключения расследовать сразу.

IAM, почтовая команда, SOC и владелец управления поставщиками

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

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

Не пытайтесь закрыть все угрозы сразу

Сентябрь показал, насколько разнообразными могут быть пути атаки. Но длинный список угроз сам по себе не помогает определить приоритеты. Для этого нужно ответить на три вопроса:

  • Есть ли у нас затронутая система или компонент?

  • Может ли атакующий добраться до него и есть ли признаки, что он уже это сделал?

  • Какие последствия будут для бизнеса, если атака удалась?

Ответы помогут отделить общие сигналы об угрозах от действительно срочных задач.