Только представьте: ваш сервер управления корпоративными смартфонами директоров уже неделю тихо сливает их геолокацию и переписку. А вы узнаете об этом из новостей о патчах, которые выпустили слишком поздно. Да, это снова Ivanti. И это снова больно.
В феврале 2026-го Ivanti экстренно закрыла две дыры нулевого дня в своем Endpoint Manager Mobile.
Уже после того, как хакеры вовсю их использовали. Мне, как специалисту, работавшему с десятками таких инцидентов, это кажется ужасно знакомым сценарием. Чувствуете дежавю? И я тоже. Это не первый и, увы, не последний раз, когда надежный, казалось бы, вендор ставит своих клиентов перед фактом: ваша защита уже взломана, пока вы спали.
И знаете, что самое неприятное? В российской реальности, с её 152-ФЗ и требованиями ФСТЭК по защите персональных данных, последствия таких атак — не просто техногенная авария. Это миллионные штрафы, репутационные потери и реальные угрозы бизнесу. Но давайте по порядку.
Что на этот раз произошло на самом деле?
Если отбросить сухие идентификаторы CVE-2026-1281 и CVE-2026-1340, суть проста до безобразия. Ошибки в EPMM (тот самый Endpoint Manager Mobile) позволяли любому, у кого есть доступ к серверу извне, выполнить на нём свой код. Без пароля. Без ключа. Просто отправить хитромудрый запрос.
Уровень опасности — 9.8 из 10. Это не просто «опасно».
Это практически открытая дверь с табличкой «Добро пожаловать».
На практике эксплуатация таких уязвимостей выглядит как тихая, методичная работа. Атакующий не ломает дверь с плеча — он использует мастер-ключ, который забыл в замке сам производитель. После получения удалённого выполнения кода (RCE) начинается самое интересное: движение по сети, поиск учётных записей, повышение привилегий. В результате злоумышленник получает не просто доступ к серверу. Он получает ключи от королевства мобильных устройств.
А в этом королевстве хранится всё: логины и пароли администраторов, персональные данные пользователей, списки устройств. Номера телефонов топ-менеджеров, история их перемещений по GPS, которую EPMM честно собирал для контроля. Представьте, что этим располагает не ваш отдел ИБ, а кто-то на стороне. Становится не по себе, правда?
Почему это особенно больно бьёт по российским компаниям?
Скажу честно: на Западе уже давно выработался рефлекс — не выставлять такие системы в интернет. Используют VPN, выделенные каналы, нулевое доверие. У нас же, по моим наблюдениям, до сих пор можно найти банки или крупных ритейлеров, у которых EPMM или его аналоги торчат в сети с белым IP «для удобства подключения мобильных сотрудников». Это как оставить ключи от сейфа на видном месте в подъезде. Удобно? Да. Безопасно? Абсолютно нет.
К слову, мы как-то проводили внешнее пентестирование для одного холдинга. Нашли их сервер управления мобильными устройствами за 20 минут стандартными средствами разведки. Он был доступен из любой точки мира. И это не единичный случай, а, увы, система.
Как понять, что вас уже атаковали через уязвимости в Ivanti?
И вот здесь начинается настоящая детективная история, которая часто раздражает практиков. Ivanti, как и многие вендоры после факта взлома, не предоставляет чётких, готовых к использованию индикаторов компрометации. Мол, инцидентов мало, данных недостаточно. Знакомая отмазка, не находите?
Нам, специалистам по реагированию на инциденты, приходится действовать по старинке, как сыщикам. Ivanti даёт лишь общие ориентиры, и их нужно уметь читать.
Первое, с чего стоит начать — журналы веб-сервера Apache.
Присмотритесь к запросам к компонентам In-House Application Distribution и Android File Transfer Configuration. В норме они возвращают код 200. Если же вы видите лавину ошибок 404 на эти же пути — это тревожный звоночек. Так часто проявляются неудачные попытки подобрать payload для эксплуатации.
Второй момент — любые GET-запросы, в параметрах которых мелькают команды bash.
В нормальной работе такого быть не должно. Это почти стопроцентный признак попытки выполнить код.
Третий маркер — файлы.
Появление в неположенных местах JAR или WAR архивов — это как обнаружение чужого отмычка в вашей двери. Такие файлы часто являются веб-шеллами, обратными оболочками, которые обеспечивают хакеру постоянный доступ. Они могут маскироваться под системные компоненты, поэтому смотреть нужно внимательно.
И, наконец, сетевая активность.
Запомните раз и навсегда: EPMM в штатном режиме не инициирует исходящие соединения в интернет. Никакие. Если ваш межсевой экран или система обнаружения вторжений (IDS) зафиксировали такие попытки — бейте в набат. Скорее всего, у вас уже живёт зловред, который пытается «позвонить домой» или скачать следующий этап атаки.
Личный кейс из практики SOC-аналитика
Однажды к нам поступил запрос от клиента из финансового сектора: «Подозрительная активность на сервере EPMM». Смотрели логи — вроде чисто. Но смущала одна деталь: периодические всплески нагрузки в ночное время, когда мобильные устройства сотрудников должны были спать. Глубокий анализ памяти и дискового пространства выявил скрытый процесс, который маскировался под системную службу java. Оказалось, это был замаскированный веб-шелл, установленный через ту самую уязвимость в Android File Transfer. Хакеры почти месяц выгружали данные, прежде чем мы их нашли. И знаете, что их спасло? Только то, что сервер был сегментирован в отдельном VLAN и не имел прямого доступа к ядру сети. Это урок: сегментация — не пустой звук.
Что делать, если обнаружили компрометацию?
Не надейся на лучшее, готовься к худшему.
Американское CISA ещё в ходе предыдущих эпидемий с Ivanti выпускало жёсткие предупреждения: такие уязвимости — идеальный инструмент для закладки глубоких и тихих бэкдоров. Поэтому рекомендации самого Ivanti звучат радикально, но я с ними полностью согласен, исходя из горького опыта.
Если вы нашли признаки взлома — забудьте про ручное «лечение».
Не пытайтесь почистить файлы, удалить шеллы и успокоиться. Это проигрышная стратегия. Злоумышленник, получивший права администратора, мог сделать что угодно: изменить логи, установить скрытые руткиты, создать скрытые учётные записи. Вы будете играть с ним в прятки, а он уже давно выиграл.
Единственный правильный путь — полное восстановление из ЗАВЕДОМО ЧИСТОЙ резервной копии. Причём копии, созданной ДО момента предполагаемого взлома. После восстановления — немедленная установка всех актуальных патчей. Если чистой резервной копии нет (а такое, поверьте, бывает сплошь и рядом), то вариант один: разворачивайте новый сервер EPMM с нуля, на чистой ОС, с новыми сертификатами и паролями, и переносите данные. Да, это долго и больно. Но это единственный способ быть уверенным.
10 правил 2026 года, чтобы не стать жертвой «нулёвок» в корпоративном ПО
- Забудьте про «белый IP для удобства». Никакие системы управления не должны светиться в интернете. Только через VPN или выделенные защищённые каналы. Это аксиома.
- Патчи — не когда есть время, а сразу. Включите автоматическое отслеживание уязвимостей (vulnerability management) для всего парка, особенно для периферийных систем вроде EPMM. Задержка в сутки — уже риск.
- Сегментируйте сети безжалостно. Сервер управления мобильными устройствами не должен иметь прямой доступ к домену, файловым хранилищам или базам данных. Ограничивайте его общение правилами межсетевого экрана до минимума.
- Ведите охоту за угрозами (Threat Hunting) целенаправленно. Не ждите алертов. Регулярно ищите аномалии в логах EPMM, странные процессы, нехарактерные исходящие соединения. Это как проверять проводку в доме: всё тихо, пока не начнёт искрить.
- Готовьте «последний чистый образ». Имейте всегда под рукой эталонный, полностью настроенный и обновлённый образ виртуальной машины для критичных систем. Чтобы в случае компрометации развернуть её за час, а не за два дня.
- Настройте двустороннюю аутентификацию (2FA) везде, где это возможно. Даже если злоумышленник получит доступ к интерфейсу, без одноразового кода он будет сильно ограничен.
- Усильте мониторинг именно журналов приложений, а не только системных. Логи Apache, Tomcat, самих Java-приложений — именно там остаются следы попыток эксплуатации уязвимостей.
- Проводите регулярные учения по восстановлению. Уверены, что ваша резервная копия EPMM рабочая? А что процесс её восстановления отлажен? Проверьте. Прямо в следующем квартале.
- Требуйте от вендоров прозрачности. Если поставщик, вроде Ivanti, столкнулся с инцидентами нулевого дня, у вас как у клиента должно быть право на полный отчёт: как их обнаружили, какие системы затронуты, какие конкретно IOCs (индикаторы компрометации) можно искать.
- Инвестируйте не только в технологии, но и в экспертизу. Самый дорогой EDR или SIEM бесполезен, если ваша команда не умеет расследовать сложные инциденты. Обучение, наставничество, привлечение внешних специалистов CTI — это не затраты, это страховка.
══════
Нужна помощь?
Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП
Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!
══════
FAQ: 10 вопросов, которые мне чаще всего задают после таких инцидентов
- У нас небольшая компания, на нас тоже могут охотиться через Ivanti?
Абсолютно. Атаки часто носят массовый, сканирующий характер. Ваш доступный из интернета сервер попадет в паутину автоматических сканеров, которые ищут именно CVE-2026-1281. Размер не имеет значения. - Мы вовремя установили патч от Ivanti. Мы в безопасности?
Скорее всего, да. Но если сервер был доступен извне в период между появлением уязвимости в дикой природе и установкой патча, я бы рекомендовал провести углублённую проверку на компрометацию. На всякий случай. - Какие ещё системы, кроме EPMM, находятся в группе риска таких атак?
Любые системы управления (Endpoint Management, MDM), системы удалённого доступа (VPN, RDP-шлюзы), веб-интерфейсы сетевого оборудования. Всё, что имеет веб-интерфейс и выходит в интернет. - Хватит ли штатного антивируса на сервере EPMM для защиты?
Честно? Нет. Антивирус плохо детектирует эксплуатацию уязвимостей и целенаправленные веб-шеллы. Нужен EDR (Endpoint Detection and Response) с возможностью поведенческого анализа. - Как соответствовать требованиям 152-ФЗ, если вендор подвёл?
Регулятору не интересны ваши оправдания. Ваша задача — доказать, что вы предприняли все меры: следили за уязвимостями, вовремя обновляли, имели план восстановления. Документируйте ВСЁ. - Мы нашли подозрительный JAR-файл. Что делать первым делом?
Изолируйте сервер от сети (но не выключайте, чтобы сохранить артефакты в памяти), сделайте полный образ диска и дамп памяти для расследования, и начинайте процесс восстановления из чистой копии. Расследование поручите экспертам. - Почему так сложно найти готовые индикаторы компрометации (IOC)?
Потому что каждый хакер, каждый кластер использует свои уникальные инструменты и методики. Готовые хэши файлов или IP-адреса быстро меняются. Нужно искать не конкретные метки, а аномалии и тактики (TTPs). - Обязательно ли нанимать внешних специалистов для расследования?
Если в вашей команде нет опытных IR (Incident Response) инженеров, которые разбираются в веб-шеллах и анализе памяти, — то да, обязательно. Самостоятельное «лечение» часто только усугубляет ситуацию. - Каков главный урок из истории с Ivanti?
Нельзя слепо доверять даже именитым вендорам. Ваша безопасность — это ваша ответственность. Принцип нулевого доверия (Zero Trust) — не модное слово, а необходимость. - Что будет дальше? Такие атаки участятся?
Однозначно. Атаки на цепочки поставок и корпоративное программное обеспечение — это тренд, потому что он эффективен. Взломав одного вендора, можно получить доступ к тысячам его клиентов. Это бизнес с огромной рентабельностью для злоумышленников.
В итоге, что мы имеем?
Историю не про злых хакеров и не про плохого вендора. Историю про нашу общую беспечность и веру в «установил и забыл». Безопасность — это процесс, ежедневная рутина из мониторинга, обновлений и проверок. Скучно? Да. Но именно эта скучная работа спасает бизнес, когда приходит час X, как это случилось с Ivanti.
Вы готовы к тому, что следующая новость о критическом обновлении будет касаться именно вашей инфраструктуры? Или вы предпочитаете действовать на опережение?
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]