Шифровальщик пришёл по RDP с паролем из четырёх символов

MAATRIX

В пятницу вечером бухгалтер написала в чат, что не может открыть файлы на сетевом диске — вместо .xlsx там теперь .xlsx.locked, а на рабочем столе сервера лежит текстовый файл с требованием выкупа. К моменту, когда админ зашёл по RDP и увидел это своими глазами, шифровальщик уже закончил работу. Разбираем, как злоумышленник вообще оказался внутри, почему это не заметили раньше, и что нужно было настроить с самого начала, чтобы такого не случилось.

Что случилось

Сервер — Windows Server 2019, стоящий под 1С и файловым хранилищем небольшой компании (около 20 пользователей). RDP (порт 3389) был открыт наружу напрямую, без VPN — так исторически сложилось: удалённый бухгалтер и разъездной директор заходили на сервер через mstsc по внешнему IP, потому что «так проще» и «настраивать VPN было некогда».

В пятницу около 19:40 по местному времени на сервере запустился процесс, который за 40–50 минут (по меткам времени изменения файлов) прошёл по всем сетевым шарам и локальным дискам, зашифровал документы, базы 1С и бэкапы, лежавшие на том же сервере во втором разделе того же физического диска. На рабочем столе появилась записка с требованием выкупа в криптовалюте и почтой для связи.

Пострадали:

• Файловый архив компании (около 40 ГБ документов);
• Рабочая база 1С — сервер встал, попытки подключиться из клиента 1С зависали;
• Локальные бэкапы .bak, которые скрипт складывал в папку D:\Backup на том же сервере — они тоже оказались зашифрованы, потому что диск D был обычным вторым разделом того же физического накопителя, а не отдельным хранилищем.

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

Что показали логи и метрики

После инцидента подняли журналы Windows (Event Viewer) и журнал RDP-подключений. Картина сложилась быстро — данных оказалось достаточно, хотя аудит логона на сервере был настроен только частично (базовый уровень, без расширенного аудита процессов):

• Event ID 4625 (неудачный логон) — начиная примерно с середины месяца в журнале безопасности были тысячи записей о неудачных попытках входа по RDP с разных внешних IP, с интервалом от долей секунды до пары секунд между попытками. Классическая картина автоматического перебора паролей.
• Event ID 4624 (успешный логон), тип логона 10 (RemoteInteractive) — в ночь инцидента, около 19:15, есть успешный вход под локальной учётной записью с правами администратора, с внешнего IP, которого раньше в журнале не встречалось.
• Диспетчер задач и счётчики производительности (сохранились частично, через Performance Monitor, который на сервере был включён для мониторинга 1С) показали резкий скачок дисковой активности и загрузки CPU примерно с 19:40 — это совпадает с началом массового переименования файлов.
• Журнал брандмауэра Windows подтвердил, что входящие подключения на 3389/tcp принимались с любых адресов — правило было Allow Any, поставленное при первоначальной настройке сервера и с тех пор не тронутое.
• В реестре и списке локальных пользователей нашлась учётная запись support, созданная около полугода назад — предположительно, для разового удалённого доступа подрядчика по настройке 1С. Пароль у неё был короткий, вида qw12, и с тех пор не менялся и не удалялся.

Совпадение по времени было однозначным: успешный вход под support в 19:15 → пауза около 20–25 минут (видимо, разведка — злоумышленник смотрел, что на сервере, отключал защитник) → начало шифрования в 19:40.

Какие гипотезы отбросили

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

• Фишинговое письмо с вложением. Проверили почтовые ящики администраторов и бухгалтера за последние две недели — подозрительных вложений или писем с макросами не нашли. К тому же шифрование началось поздно вечером в пятницу, когда сотрудники уже не работали за компьютерами, а зловред, запущенный через макрос в Office, обычно проявляет себя вскоре после открытия файла в рабочее время.
• Уязвимость в 1С или в веб-сервере. На сервере был установлен веб-сервер для публикации 1С по HTTP, но порт был закрыт на уровне брандмауэра хостинга и не отвечал снаружи — проверили сканером портов уже после инцидента, подтвердили, что 80/443 наружу не торчали.
• Заражённая флешка или локальный физический доступ. Отбросили: сервер стоял в дата-центре хостинг-провайдера, физического доступа у сотрудников компании не было, а система входа в серверную логируется отдельно и в нужное время никто не заходил.
• Компрометация через антивирус или стороннее ПО с автообновлением. Проверили список установленного софта и логи Windows Update — ничего необычного не устанавливалось и не обновлялось в день инцидента.
• Инсайдер (кто-то из сотрудников). Учитывая, что вход был с внешнего IP, который не встречался раньше ни в одном логе, версия с инсайдером тоже отпала быстро — ни у кого из сотрудников не было причин заходить с незнакомого адреса под учётной записью support, о существовании которой большинство даже не знало.

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

В чём была реальная причина

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

1. RDP был открыт в интернет напрямую. Порт 3389 отвечал на подключения с любого IP-адреса. Это само по себе не катастрофа, если пароли надёжные и есть защита от перебора — но в сочетании со следующими пунктами стало ключевым фактором.
2. Учётная запись support с паролем в 4 символа. Полгода назад её создали «на один раз» для подрядчика, который настраивал 1С, и забыли удалить или сменить пароль. Пароль вида qw12 перебирается автоматическими инструментами (вроде тех же NLBrute или RDP-брутфорсеров, которые массово ходят по интернету и сканируют открытые 3389-е порты) за разумное время — коротким паролям банально не хватает энтропии, чтобы устоять против словарного или комбинаторного перебора.
3. Не было блокировки учётной записи после серии неудачных попыток. Политика блокировки (Account Lockout Policy) на сервере не была настроена — то есть атакующий мог перебирать пароли сколько угодно раз без риска, что учётная запись временно заблокируется.
4. Не было ограничения по IP и защиты от брутфорса на уровне сети. Ни fail2ban-подобного инструмента для Windows (RDPGuard, IPBan и аналоги), ни правил брандмауэра, ограничивающих доступ к 3389 конкретными адресами или VPN-подсетью — не стояло.
5. Локальные бэкапы лежали на том же диске, что и рабочие данные. Это не причина взлома, но именно это превратило инцидент из «неприятно, но у нас есть бэкап» в «данные потеряны», потому что шифровальщик добрался и до D:\Backup.

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

Что сделали сразу после инцидента

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

1. Отключили сервер от сети (не выключили физически, а именно отсоединили сетевой интерфейс) — чтобы исключить дальнейшую активность зловреда и возможную повторную связь с управляющим сервером атакующих.
2. Сняли снапшот диска как есть, до любых действий по восстановлению — на случай, если понадобится обращаться в полицию или к специалистам по форензике, и чтобы не потерять журналы событий, которые могли перезаписаться при перезагрузке.
3. Сменили все учётные данные, до которых теоретически могли дотянуться с этого сервера: пароль администратора домена (домена как такового не было, но локального администратора — точно), пароли к 1С, доступы к почте, которые могли быть сохранены в браузере на сервере.
4. Удалили учётную запись support и проверили список локальных пользователей и групп на предмет других «забытых» аккаунтов — нашли ещё один, тестовый, тоже с простым паролем, тоже удалили.
5. Восстанавливались не из локальных бэкапов (они были зашифрованы вместе со всем остальным), а из более старой копии, которая, к счастью, лежала в облачном хранилище отдельного провайдера — её делали раз в неделю по остаточному принципу, и она отставала от актуальных данных почти на семь дней. Часть данных за последнюю неделю восстановить не удалось.
6. Не платили выкуп. Помимо очевидных этических и юридических рисков, нет никакой гарантии, что после оплаты пришлют рабочий ключ расшифровки — это была осознанная договорённость с руководством компании сразу, чтобы не терять время на переговоры с атакующими в надежде на чудо.
7. Разворачивали сервер заново с нуля, а не пытались «вылечить» заражённую систему — это значительно надёжнее, чем гоняться за остатками зловреда на скомпрометированной машине.

Что изменили в инфраструктуре навсегда

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

• RDP закрыли от прямого доступа из интернета. Правило брандмауэра на 3389/tcp теперь разрешает подключения только с адресов VPN-подсети. Сам удалённый доступ сотрудников организовали через WireGuard: сначала человек поднимает VPN-туннель до сервера, и только внутри него открывается RDP. Это не делает пароли ненужными, но убирает сервер из зоны видимости массового сканирования портов — подробная схема разобрана в статье про безопасный доступ к RDP через WireGuard.
• Настроили Account Lockout Policy: блокировка учётной записи на 15 минут после 5 неудачных попыток входа подряд, счётчик сбрасывается через 15 минут. Это резко снижает эффективность автоматического перебора, даже если кто-то всё же доберётся до порта.
• Поставили защиту от брутфорса на уровне сервера — инструмент, который анализирует журнал безопасности и временно банит IP-адреса после серии неудачных попыток логона, аналог fail2ban для Windows. Логика и принципы настройки такой защиты в целом такие же, как описаны в статье про настройку защиты от брутфорса на VPS — только применительно к RDP-логам вместо SSH.
• Провели аудит локальных учётных записей и завели правило: любая временная или подрядчическая учётная запись создаётся с датой истечения (можно выставить прямо в свойствах пользователя в Windows — поле «Срок действия учётной записи») и попадает в список, который проверяют раз в месяц.
• Ввели политику паролей — минимум 12 символов, обязательное сочетание регистров, цифр и спецсимволов, запрет на переиспользование последних паролей. Отдельно включили многофакторную аутентификацию для удалённого доступа через сам VPN-клиент (сертификат + пароль), а не полагаются только на пароль учётной записи Windows.
• Разнесли бэкапы физически. Теперь основная копия делается ежедневно на отдельный сервер бэкапов в другом дата-центре, доступный только на запись по выделенным учётным данным (без прав на чтение и удаление старых копий с той стороны, откуда пишется бэкап) — это отдельная тема, но именно она спасает даже в сценарии, где шифровальщик добрался до продакшн-сервера полностью.
• Включили расширенный аудит событий безопасности (Advanced Audit Policy) — не только логоны, но и создание/изменение учётных записей, изменение групповых политик и правил брандмауэра, чтобы при следующем разборе не собирать картину по крупицам, а иметь полный журнал.
• Раз в квартал теперь делают короткий чек-лист по всем внешним серверам компании — сверяют список открытых портов, список локальных пользователей и актуальность паролей. Общий подход к такой проверке описан в чек-листе по укреплению защиты VPN-сервера — многие пункты оттуда применимы и к RDP-серверам без выделенного VPN-стека.

Частые вопросы