Средний

7 мин

3

Привет! На счету 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 рублей. Величину выкупа, к слову, хакеры обычно определяют, исходя из найденных данных о бизнес-показателях компании, а также примерно прикинув размер потенциального ущерба, который они могут причинить атакой.

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

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

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

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

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

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

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

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

Согласно статистике наших расследований, уязвимые сервисы на периметре организаций являются причиной более чем трети инцидентов. Остановимся на эксплуатации уязвимостей публично доступного сервиса / 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

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

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

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