Привет! На счету Jet CSIRT с 2023 по 2025 год более 100 крупных расследований ИБ‑инцидентов — мы помогали российским компаниям правильно реагировать на них и ликвидировать последствия. У нас накопилось довольно много полезной статистики по теме, так что мы решили оформить это в большое исследование и выложить в открытый доступ. Там много цифр, статистики и практических ИБ‑рекомендаций — рассказываем о ключевых результатах.

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

Небольшая вводная

Одно из ключевых свойств для бизнеса в плане ИБ (да и ИТ в целом) — это его непрерывность, возможность работать без сбоев 24*7. Потому что простой любого крупного интернет‑маркетплейса, например, это миллионные убытки. А то и миллиардные, зависит от маркетплейса и длительности простоя. Раньше сами подходы к обеспечению непрерывности формировались с учётом того, что главная угроза для бизнеса — какие‑то проблемы с железом или человеческие ошибки. Кибератаки тоже рассматривались как риск, но в плане «кто‑то получит доступ к инфре и узнает секретные данные».

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

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

  1. Атаки с использованием программ‑вымогателей. Блокируют доступ к ИТ‑сервисам, вызывают простои бизнеса, недовольство пользователей.

  2. Атаки, направленные на уничтожение данных (вайперы). Ведут к критическому и (в идеале для злоумышленника) необратимому повреждению ИТ‑активов.

  3. DDoS‑атаки, масштаб которых кладёт ключевые ИТ‑сервисы на долгое время.

По нашим данным, на сегодня порядка 76% всех кибератак — это шифрование и разрушение инфраструктуры.

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

Кого и зачем чаще всего атакуют

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

На 2023–2025 топ выглядел так.

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

Почему‑то часто думают, что какая‑то успешная атака — это довольно быстрое действие. Будто нашли какую‑то уязвимость или удачный момент, и быстро в формате марш‑броска провели атаку.

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

  1. Хакеры получают первоначальный доступ к инфраструктуре. Тут им совсем необязательно сразу же начинать вредить и выдавать своё присутствие.

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

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

  4. Осуществляют горизонтальное перемещение по инфре.

  5. Используют легитимные системные инструменты.

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

Группировок, которые активно целятся на отечественные компании, за эти пару лет мы насчитали несколько десятков, но вот тех, кто показывает устойчивую активность и часто фигурирует в ИБ‑сводках, заметно меньше — вот они.

По нашей статистике, более 90% расследованных инцидентов были рассчитаны на получение выкупа, разброс которого был достаточно велик — от 500 000 до 500 000 000 рублей. Величину выкупа, к слову, хакеры обычно определяют, исходя из найденных данных о бизнес‑показателях компании, а также примерно прикинув размер потенциального ущерба, который они могут причинить атакой.

Реалии таковы, что финальная инстанция в плане принятия решения о взаимодействии с хакерами — это владелец бизнеса, а не ИТ‑команда или служба ИБ. Именно бизнес решает, договариваться и платить, или же пытаться отбиться и восстановиться.

И тут стоит понимать, что попытка пойти на поводу у преступников и заплатить выкуп — это не гарантия, что система восстановится, потому что есть риски:

  • нет гарантий, что компании на самом деле дадут инструменты для расшифровки данных и их восстановления;

  • даже если и дадут — не факт, что инструмент расшифрует или восстановит все данные (прикол в том, что даже сами хакеры не могут быть в этом наверняка уверены);

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

  • заплатили один раз = дали стимул повторять такое, чтобы к компании пришли ещё раз за повторной выплатой.

Тактики и техники

А вот тот самый обещанный список тактик и техник, который мы собрали на основе ретроспективного анализа.

Тактики

Техники

Получение доступа в инфраструктуру / Initial Access

Т1190

Эксплуатация уязвимостей публично доступного сервиса / Exploit Public‑Facing Application

Т1133

Внешние службы удаленного доступа / External Remote Services

Т1078

Существующие учетные данные / Valid Accounts

Т1566

Фишинг/ Phishing

Т1199

Доверительные отношения / Trusted Relationship

Выполнение / Execution

T1059

Интерпретаторы командной строки и сценариев / Command and Scripting Interpreter

T1072

Средства развертывания ПО / Software Deployment Tools

Закрепление / Persistence

T1543

Создание или изменение службы / Create or Modify System Process

T1098

Манипуляции с учетными записями / Account Manipulation

T1112

Изменения в реестре / Modify Registry

T1053

Создание, изменение задач / Scheduled Task/Job

T1505

Компонент серверного ПО (веб‑шелл) / Server Software Component (WebShell, IIS Components)

T1197

Задания BITS / BITS Jobs

Повышение привилегий (Privilege Escalation)

T1134

Манипулирование токенами доступа / Access Token Manipulation

T1068

Эксплуатация уязвимостей для повышения привилегий / Exploitation for Privilege Escalation

T1078

Существующие учетные данные / Valid Accounts

Доступ к учетным данным (Credential Access)

T1003

Дамп учетных данных/Credential Dumping

T1110

Подбор учетных данных / Brute Force

T1555

Использование данных из хранилищ паролей / Credentials from Password Stores

T1558

Кража тикетов Kerberos / Steal or Forge Kerberos Tickets

T1552

Небезопасное хранение паролей / Unsecured Credentials

Организация управления (Command and Control)

T1219

ПО для удаленного доступа / Remote Access Tools

T1572

Туннелирование протокола / Protocol Tunneling

Т1090

Прокси / Proxy

Деструктивные воздействия

T1486

Шифрование данных / Data Encrypted for Impact

T1485

Уничтожение данных / Data Destruction

Согласно статистике наших расследований, уязвимые сервисы на периметре организаций являются причиной более чем трети инцидентов. Остановимся на эксплуатации уязвимостей публично доступного сервиса / Exploit Public‑Facing Application. Рассмотрим ее на примере REACT2SHELL.

Много шума в конце года наделала и критическая уязвимость в React Server Components CVE-2025-55182 (React2Shell, рейтинг CVSS 10.0), которая позволяет удаленно выполнять код без аутентификации.

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

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

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

С точки зрения поиска следов компрометации ключевой идентификатор — специфический заголовок Next‑Action или rsc‑action‑id в логах реверс‑прокси:

grep -rE «next-action|rsc-action-id» /var/log/nginx/access.log

Также можно искать подозрительные команды:

grep -E ‘wget|curl|bash|sh|python|nc’ /var/log/nginx/access.log

Более ста тысяч серверов остаются уязвимы к React2Shell.

Уязвимость присутствует в версиях 19.0, 19.1.0, 19.1.1 и 19.2.0 следующих пакетов: reactserver‑dom‑webpack react‑server‑dom‑parcel react‑server‑dom‑turbopack.

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

Теперь про обнаружение. Выявление специфических заголовков в логах реверс‑прокси все же будет свидетельствовать в первую очередь о попытке эксплуатации, но не о самой эксплуатации уязвимости. Для обнаружения самого факта эксплуатации необходимо в рамках мониторинга отслеживать процессы, порождаемые веб‑сервисом. В первую очередь нас интересуют командные интерпретаторы. Без обогащения c никсами на стандартном auditd, конечно, такое правило не сделать — имя родительского процесса не логируется. Зато может отслеживать текущую директорию и пользователя:

logsource:

product: linux

service: auditd

detection:

selection_syscall:

type: ‘SYSCALL’

syscall: ‘execve’

uid: 33 # www-data

comm:

— ‘sh’

— ‘bash’

— ‘dash’

selection_cwd:

cwd|contains:

— ‘/var/www/’

— ‘/tmp/’

condition: selection_syscall and selection_cwd

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

В следующей статье расскажем про восстановление после инцидентов, если они всё‑таки случились.

Спойлер — парадигма успела смениться с «Что делать, если компанию взломают?» на «Что делать, когда компанию взломают?».

Комментарии (0)