Первый ransomware-инцидент на удалёнке: как Ryuk попал через домашний роутер без VPN

Несколько дней назад получили звонок от клиента, с которым работаем на аудите периметра: «у нас файлы зашифрованы, на рабочем столе записка, всё встало». Инцидент в разгар перевода команды на удалёнку, то есть в самый неудобный момент. Потушили, разобрали цепочку - фиксируем, пока детали свежие.

Что произошло

Клиент перевёл сотрудников на удалённую работу примерно неделю назад, в спешке, как большинство сейчас. Часть людей подключалась через корпоративный VPN, часть - и вот это ключевой момент - через прямой RDP на порту 3389, который был поднят «временно, на пару дней». Один из сотрудников бухгалтерии работал с домашнего ноутбука, роутер дома без какой-либо фильтрации, и никакого VPN.

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

Цепочка атаки

Разбирали по логам и артефактам на хостах. Вот как это выглядело по шагам:

[фишинговое письмо] -> [макрос в .doc] -> [загрузчик (TrickBot/Emotet-цепочка)]
      -> [lateral movement по сети] -> [шифрование файловых шар]

Точка входа - фишинг на домашний ящик. Сотрудник использовал личную почту параллельно с корпоративной, письмо пришло на личную. Антиспам корпоративного периметра его, соответственно, не видел. Word открыт на домашнем ноутбуке - там никакого EDR, только встроенный Windows Defender.

Домашняя машина как плацдарм. Ноутбук подключён к RDP на периметре клиента - прямой порт 3389, без VPN, без MFA. Загрузчик на домашнем ноутбуке получил доступ к сессии пользователя и через неё - к сетевым шарам, к которым у бухгалтера были права на запись. Пара сетевых дисков монтировалась автоматически при входе.

Lateral movement. Учётных данных домена у загрузчика сначала не было, но хватило и прав самого пользователя - бухгалтер имел запись на финансовые шары. Где-то на этом этапе сработало что-то, собравшее хеш из lsass - на этой машине был ещё один залогиненный пользователь с более широкими правами (чего, очевидно, не должно было быть, но на практике встречается постоянно).

Шифрование в ночное время. Ryuk традиционно ждёт - операторы проводят рекогносцировку, ищут бэкапы, оценивают масштаб. Шифрование началось примерно через 16-18 часов после первоначального компрометирования.

Почему бэкапы частично выжили

Клиент использует Veeam с репозиторием на отдельном хосте. Этот хост был в другом сегменте сети, и у бухгалтерской учётки прав на него не было совсем. Ryuk добрался до шар, но не до репозитория Veeam - повезло с сегментацией, которую делали ещё в прошлом году. Восстановление заняло несколько часов, потеря данных - примерно день (последняя успешная резервная копия была за сутки до инцидента).

Что было сделано неправильно - и это важнее всего

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

Первое - открытый RDP без VPN и MFA. Это мы разбирали ещё в феврале в контексте BlueKeep. Прямой порт 3389 на периметре - это не «временное решение», это работающий вектор атаки. На этом клиенте RD Gateway с MFA стоял в очереди, но до удалёнки руки не дошли. Когда удалёнка наступила внезапно, поставили «временно» - и вот результат.

Второе - домашний ноутбук как корпоративная рабочая станция без каких-либо контролей. Сотрудник работал с личного устройства. BYOD без политик - это в чистом виде неконтролируемая точка входа. Никакого EDR, никаких групповых политик по Office (запрет макросов из интернета не стоял).

Третье - избыточные права на файловые шары. Бухгалтер имел запись на несколько шар, которые для его работы нужны не были. Это не злой умысел - просто «дали права по запросу, а потом не убрали». Ransomware шифрует то, до чего может дотянуться.

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

Что сделали немедленно

В первые часы - изоляция поражённых машин, отключение от сети, оценка масштаба шифрования. Дальше - восстановление из Veeam для файловых серверов, принудительная смена паролей всех учёток домена (через kerberoast или pass-the-hash атаку могло утечь что угодно).

По периметру - закрыли прямой RDP немедленно, подняли RD Gateway с NPS и MFA по той же схеме, что описывали раньше, только уже без опции «завтра доделаем».

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

Что это меняет в нашем подходе к аудитам

Атаки Ryuk, Maze и Sodinokibi в последние недели активизировались - это не ощущение, это видно по числу публичных отчётов и по запросам, которые к нам приходят. Операторы этих семейств целенаправленно ищут незащищённые RDP и фишингуют удалённых сотрудников, которые работают в расслабленном домашнем окружении.

Из того, что добавляем в чеклист аудита по итогам этого инцидента:

• Проверка всех точек RDP-доступа - не только периметр, но и внутренние хосты с включённым RDP, которые вдруг оказываются достижимы с домашних сетей
• Политика Office по макросам - Block macros from internet в GPO, это делается за минуты и перекрывает огромный класс доставки вредоносного кода
• Аудит прав на файловые шары - кто имеет запись, на что, и нужно ли это реально
• Проверка того, что бэкап-репозиторий недостижим с обычных пользовательских учёток - это оказался спасительный момент в данном кейсе

Ryuk не новый. Но когда тысячи компаний одновременно второпях открывают RDP и переводят людей на домашние ноутбуки - атакующим не нужно ничего изобретать. Достаточно сканировать порт 3389 и слать письма про счета. Что они и делают.