Эта страница является переводом. Авторитетным считается текст английской версии. Читать на английском
llm-abuse · agent-harness · deepseek-harness · api-key-abuse · mcp · fofa · bug-bounty-automation · model-endpoint
Злоупотребление DeepSeek Harness: автономный агент раскрывает хост своего оператора
Оператор похищает ресурсы инференса у доступной из интернета OpenAI-совместимой конечной точки модели, направляя на неё кодовый агент DeepSeek Harness с открытым исходным кодом; цикл автоматического подтверждения вызовов инструментов этого агента затем выполнил вызовы инструментов конечной точки на собственной рабочей станции Windows оператора и отправил вывод обратно.
Автор Davis Zheng·
TLP:CLEAR. Разрешено к публичному распространению. Зафиксировано сетью honeypot-сенсоров Kinryū Labs. Индикаторы ниже приведены в обезвреженном виде.
Продолжение нашего более раннего отчёта DeepSeek Harness против похищенного LLM-шлюза: вызовы инструментов выполняются у вызывающей стороны.
Краткая сводка
- 492,150символов в одном отправленном промпте
- 86уникальных выводов команд с хоста вызывающей стороны
- 11ходов агента за пять минут
- 3хоста с одним и тем же агентным harness
Три адреса в Китае и Гонконге обращались к доступной из интернета OpenAI-совместимой конечной точке модели с 20 по 23 сентября 2026 года, используя кодовый агент DeepSeek Harness с открытым исходным кодом под user agent deepseek-harness/0.1.5-rc.2. Два гонконгских адреса используют общий API-ключ; третий совпадает только по публичному user agent. 23 сентября сессия из одиннадцати ходов с 182.91.103[.]32 выполнила вызовы инструментов конечной точки на собственной рабочей станции Windows и отправила вывод обратно.
Harness подтверждал вызовы инструментов автоматически, поэтому конечная точка читала файлы и списки каталогов с рабочей станции оператора. В возвращённом config.toml задано permission_mode = "always-approve" при yolo = false, поэтому каждый вызов инструмента, который выдавала удалённая конечная точка, выполнялся без подтверждения человеком. Когда harness в таком режиме направлен на конечную точку, которую оператор не контролирует, конечная точка выдаёт команды, выполняющиеся на клиентском хосте.
Если вы эксплуатируете OpenAI-совместимую конечную точку модели, проверяйте bearer-токены на /v1/chat/completions и настройте оповещение на любой ключ, отсутствующий в реестре выданных ключей. Если вы используете агентный harness, не допускайте автоматического подтверждения при работе с любой конечной точкой модели, которую вы не контролируете.
Ключевые выводы
- Оператор направил агент DeepSeek Harness с открытым исходным кодом на открытую OpenAI-совместимую конечную точку, и его клиент выполнил вызовы инструментов этой конечной точки на собственной машине, вернув вывод. В трёх сессиях с 182.91.103[.]32 насчитывается 279 отправок результатов инструментов, из них 86 уникальных при 92 различных идентификаторах вызовов инструментов, а их содержимое представляет собой списки объектов PowerShell и содержимое файлов с корнем C:\Users\cheng. То же поведение в меньшем объёме наблюдается с 203.175.15[.]28 и 103.85.74[.]25, с семью и пятью отправками результатов соответственно. Высокая уверенность.
- В возвращённом config.toml задано permission_mode = "always-approve" при yolo = false, поэтому harness выполнял каждый вызов инструмента без подтверждения человеком; именно это автоматическое подтверждение превратило рабочую станцию оператора в объект сбора данных. Один из возвращённых файлов представляет собой собственный config.toml оператора, в котором задано permission_mode = "always-approve" при yolo = false, поэтому каждый вызов инструмента, выданный удалённой конечной точкой, выполнялся без подтверждения человеком. Высокая уверенность.
- Оператор с наибольшей вероятностью является китаеязычным исследователем уязвимостей, автоматизирующим работу по программам bug bounty и аудиту исходного кода. Возвращённый AGENTS.md объявляет идентичность агента как авторизованного исследователя, занимающегося поиском уязвимостей SRC методом чёрного ящика и аудитом 0day методом белого ящика, запрещает ему спрашивать, продолжать ли работу, а его конфигурация регистрирует MCP-сервер поиска активов FOFA и браузерный MCP Playwright. Средняя уверенность.
- Два гонконгских адреса используют общий учётный материал и связаны на этом основании; адрес China Unicom совпадает только по публичному user agent harness, поэтому принадлежность его тому же оператору не установлена. User agent harness появляется ровно из трёх источников в трёх /24 в активности с 20 по 23 сентября 2026 года. Низкая уверенность.
- Мы трактуем эти одноразовые строки как проверку оператором того, требует ли конечная точка аутентификации вообще, прежде чем задействовать против неё полноценный harness; наблюдаемая последовательность: сначала три строки, затем длинная сессия. Перед длинной сессией тот же адрес предъявлял одноразовые ключи 141414, 41414141 и sk-14141242…, а в одной более ранней сессии поместил строку sk-1234 в поле модели, а не в поле ключа. Затем он перешёл к пятиминутной агентной сессии из одиннадцати ходов. Средняя уверенность.
Хронология
- 2026-09-20 12:22 UTC203.175.15[.]28 перечисляет модели через python-requests/2.28.1, уже аутентифицировавшись общим API-ключом; ключ был получен до этого запроса
- 2026-09-20 12:34 UTC103.85.74[.]25 из той же гонконгской хостинговой организации предъявляет идентичный ключ
- 2026-09-21 11:26 UTCПервое появление user agent deepseek-harness/0.1.5-rc.2 в этом наборе адресов
- 2026-09-23 17:40 UTC182.91.103[.]32 отправляет два коротких проверочных промпта на китайском под другим клиентом с одноразовым ключом
- 2026-09-23 18:05 UTCПервая сессия DeepSeek Harness с 182.91.103[.]32; клиент начинает возвращать локально выполненные результаты инструментов
- 2026-09-23 18:23 UTCОткрывается сессия из одиннадцати ходов, её первый промпт длиной 44,402 символа
- 2026-09-23 18:23 UTCКлиент отправляет обратно список содержимого собственного рабочего каталога, полученный через PowerShell
- 2026-09-23 18:24 UTCКлиент отправляет обратно полный текст своего файла операционных правил и вскоре после этого конфигурацию harness
- 2026-09-23 18:27 UTCНа ходе 10 поле модели переключается с glm-5.2 на deepseek-chat, а на ходе 11 обратно
- 2026-09-23 18:28 UTCОдиннадцатый и последний ход сессии; дальнейших обращений с этого адреса в зафиксированной активности нет
Сессия по порядку
12:22:32 GET /v1/models User-Agent: python-requests/2.28.1 Authorization: Bearer sk-0af475b8…
17:40:10 [user] 图片背景是什么颜色
18:05:08 [system] You are an AI agent powered by DeepSeek Harness. You are a coding agent powered by the glm-5.2 model.
18:23:39 FullName Length Mode C:\Users\cheng\Desktop\clown-src-6k-skill\bin d----- C:\Users\cheng\Desktop\clown-src-6k-skill\mcp-servers d----- C:\Users\cheng\Desktop\clown-src-6k-skill\AGENTS.md 5517 ------ C:\Users\cheng\Desktop\clown-src-6k-skill\config.toml 1044 ------ C:\Users\cheng\Desktop\clown-src-6k-skill\给朋友的提示词.txt 4370 ------
18:24:21 C:\Users\cheng\.dsh --- Name ---- dsh-purge node_modules plugins profiles sessions staging storages .anonymous-user-id .credentials.yaml .env catalog-cache.json desktop-config.json desktop.log prompt-inject.md settings.yaml
18:24:59 [path]C:\Users\cheng\Desktop\clown-src-6k-skill\AGENTS.md[/path] 1: # 全局 Agent 规则(永久) 3: - **语言**:始终中文回复 4: - **身份**:授权安全研究员 = **黑盒 SRC 挖洞** + **白盒 0day 审计** 5: - **思路**:理解业务/代码意图,找认知盲区;不空扫、不误报、不堆低危 48: - 一种子剩余挖完才换种 ≠ 任务结束;**禁止问「要不要继续」**
18:25:57 [path]C:\Users\cheng\Desktop\clown-src-6k-skill\config.toml[/path] [ui] permission_mode = "always-approve" yolo = false [mcp_servers.playwright] args = ['C:\Users\USER\.grok\bin\playwright-dual-slot.mjs'] [mcp_servers.fofa] command = 'C:\Users\USER\.local\bin\uv.exe' args = ["run", "--directory", 'C:\Users\USER\.grok\mcp-servers\fofa_MCP', "python", "fofa.py"] [models] default = "grok-4.6" default_reasoning_effort = "xhigh"
Ключ, предъявленный из Гонконга
Это два адреса, которые мы отслеживали в предыдущем отчёте 20 и 21 сентября: 203.175.15[.]28 впервые предъявил общий API-ключ в 12:22:32 UTC 20 сентября, а 103.85.74[.]25 предъявил его двенадцатью минутами позже. Новым является третий адрес, описанный ниже.
Сессии с 182.91.103[.]32
23 сентября появляется третий адрес, 182.91.103[.]32 в CHINA UNICOM China169 Backbone. Сначала он отправляет два коротких проверочных промпта на китайском под другим клиентом, один из них 图片背景是什么颜色, затем открывает три сессии harness между 2026-09-23T18:05:00Z и 2026-09-23T18:28:00Z. Предъявляемые им ключи представляют собой одноразовые строки: 141414, 41414141 и sk-14141242…, при этом в более ранней сессии в поле модели было вписано sk-1234. Мы трактуем эти строки как проверку оператором того, требует ли конечная точка аутентификации вообще, прежде чем задействовать против неё полноценный harness. В журналах порядок таков: сначала три одноразовые строки, затем длинная сессия.
Первая из трёх сессий открывается собственным системным промптом harness: [system] You are an AI agent powered by DeepSeek Harness. You are a coding agent powered by the glm-5.2 model. Последняя сессия продолжалась одиннадцать ходов с 2026-09-23T18:23:10.2Z по 2026-09-23T18:28:08.8Z, с интервалами между ходами от 0.2 с до 90 с. За эти ходы контекст вырос с 44,402 до 492,150 символов, а поле модели переключилось на deepseek-chat на ходе 10 и обратно на ходе 11.
Таблица 1: локальное выполнение команд сосредоточено на адресе China Unicom Отправки результатов инструментов, выполненные каждым клиентом, по активности с 20 по 23 сентября 2026 года. Подсчёт уникальных значений исключает дубликаты, возникающие, когда harness повторно пересылает историю разговора на каждом ходе, поэтому 86 означает число реальных локальных выполнений на рабочей станции за 182.91.103[.]32, а 279 означает общий объём отправок.
| Адрес | Организация | Первое наблюдение | Предъявленные учётные данные | Отправки результатов инструментов |
|---|---|---|---|---|
| 203.175.15[.]28 | Гонконгский хостинг | 2026-09-20T12:22:32Z | общий API-ключ | 7 отправок всего |
| 103.85.74[.]25 | Гонконгский хостинг, та же организация, что и у 203.175.15[.]28 | через 12 мин после первого обращения | тот же общий API-ключ | 5 отправок всего |
| 182.91.103[.]32 | CHINA UNICOM China169 Backbone, AS4837 | 2026-09-23, сессии harness с 18:05Z | 141414, 41414141, sk-14141242… | 279 всего, 86 уникальных, 92 идентификатора вызовов |
Результаты принадлежат собственной рабочей станции оператора
Список содержимого рабочего каталога, полученный через Get-ChildItem, вернулся целиком:
FullName Length Mode C:\Users\cheng\Desktop\clown-src-6k-skill\bin d----- C:\Users\cheng\Desktop\clown-src-6k-skill\mcp-servers d----- C:\Users\cheng\Desktop\clown-src-6k-skill\AGENTS.md 5517 ------ C:\Users\cheng\Desktop\clown-src-6k-skill\config.toml 1044 ------ C:\Users\cheng\Desktop\clown-src-6k-skill\给朋友的提示词.txt 4370 ------
Клиент также вернул список содержимого домашнего каталога самого harness:
C:\Users\cheng\.dsh --- Name ---- dsh-purge node_modules plugins profiles sessions staging storages .anonymous-user-id .credentials.yaml .env catalog-cache.json desktop-config.json desktop.log prompt-inject.md settings.yaml
Целые файлы тоже вернулись. AGENTS.md задаёт операционные правила агента: он фиксирует язык агента как китайский и его идентичность как авторизованного исследователя безопасности, занимающегося поиском уязвимостей по программам bug bounty методом чёрного ящика и аудитом 0day методом белого ящика, а также запрещает агенту спрашивать, следует ли продолжать.
[path]C:\Users\cheng\Desktop\clown-src-6k-skill\AGENTS.md[/path] 1: # 全局 Agent 规则(永久) 3: - **语言**:始终中文回复 4: - **身份**:授权安全研究员 = **黑盒 SRC 挖洞** + **白盒 0day 审计** 5: - **思路**:理解业务/代码意图,找认知盲区;不空扫、不误报、不堆低危 48: - 一种子剩余挖完才换种 ≠ 任务结束;**禁止问「要不要继续」**
config.toml регистрирует MCP-сервер поиска активов FOFA, запускаемый через uv, и браузерный MCP Playwright, а по умолчанию использует grok-4.6 с уровнем рассуждений xhigh. Загружаемый им набор правил ссылается на ~/.grok/rules/, тогда как реальные файлы лежат в C:\Users\cheng\.dsh\, а эти сессии объявляют glm-5.2 и deepseek-chat, то есть набор переносился между разными harness и моделями по мере изменения доступа. Мы трактуем оператора как китаеязычного исследователя уязвимостей, автоматизирующего работу по программам bug bounty и аудиту исходного кода, и придерживаемся этой характеристики со средней уверенностью.
Тактика работы
Оператор выполняет проверку ключа и перечисление моделей под одним инструментом, а сессии harness под другим. Первое выполняется под python-requests/2.28.1, второе под реальным опубликованным harness, при этом присутствует и более старая настольная сборка, DeepSeek-Harness-Desktop/0.1.3-max. Мы трактуем это разделение как привычку того, кто делает это регулярно. В терминах ATT&CK это T1588.002, Obtain Capabilities: Tool, применительно к harness, наряду с T1078, Valid Accounts, применительно к учётным данным, предъявленным конечной точке.
Два гонконгских адреса установили, до чего можно дотянуться через эту конечную точку, ещё до того, как с адреса China Unicom пришли контексты размером в полмегабайта, и мы с низкой уверенностью полагаем, что за всеми тремя адресами стоит один оператор. Ключ был проверен с 203.175.15[.]28 20 сентября, каталог из двенадцати моделей был просмотрен в отдельной сессии с 103.85.74[.]25, трафик с user agent harness из этого набора адресов появляется с 21 сентября, а полноценные сессии harness пришли с 182.91.103[.]32 23 сентября. Мы не можем сказать, как оператор использовал доступ в период с 20 по 23 сентября.
Ключи разделяются по адресам. Выданный ключ sk-0af475b8… появляется только в гонконгских сессиях 20 сентября, а с 182.91.103[.]32 появляются только одноразовые строки 141414, 41414141 и sk-14141242…, в том числе в сессии из одиннадцати ходов, в ходе которой выполнялись команды на рабочей станции. Вопрос о том, стоит ли за обоими наборами адресов один оператор, оценивается с низкой уверенностью по причине, указанной выше.
Набор правил в AGENTS.md рассчитан на работу большого объёма без участия человека. Помимо запрета спрашивать, продолжать ли работу, возвращённые правила не ограничивают размер очереди отправных точек и ведут обнаружение активов из FOFA, T1596, Search Open Technical Databases. Эти правила описывают массовый поиск уязвимостей по программам bug bounty, организованный как автоматический конвейер. Мы трактуем этот конвейер как причину, по которой оператору нужен инференс, за который он не платит.
Harness автоматически подтверждал каждый вызов инструмента с конечной точки, которую оператор не контролировал, поэтому конечная точка выполнила сбор системной информации, T1082, против собственного хоста оператора. Набор правил кочует между разными harness и названиями моделей, поэтому блокировка user agent или строки модели не остановит этого оператора надолго.
Как мы это проверяли
Мы можем исключить два альтернативных объяснения. Интервалы между ходами от 0.2 с до 90 с и поле модели, переключившееся на deepseek-chat на ходе 10 и обратно на ходе 11, не соответствуют тому, что даёт фиксированный скрипт повтора, а безобидное интернет-исследование или сканер поставщика не отправляли бы обратно содержимое собственного каталога рабочего стола и домашнего каталога harness. Общий API-ключ связывает два гонконгских хоста между собой, но user agent harness принадлежит общедоступному программному обеспечению, поэтому принадлежность 182.91.103[.]32 тому же оператору не установлена, и мы не знаем, почему сессия из одиннадцати ходов оказалась последним трафиком с этого адреса. Считает ли оператор, что некоторая область авторизации покрывает эту конечную точку, мы не проверяли; набор правил утверждает статус авторизованного исследователя перед собственной моделью, что является приёмом промпт-инжиниринга.
| Объяснение | Проверка | Результат | Вердикт |
|---|---|---|---|
| Фиксированный скрипт повтора, а не живой агентный цикл | Метки времени по ходам, размеры промптов и поля модели для сессии из одиннадцати ходов, плюс количество уникальных идентификаторов вызовов инструментов | Одиннадцать ходов с 18:23:10.2Z по 18:28:08.8Z с интервалами от 0.2 с до 90 с; контекст вырос с 44,402 до 492,150 символов; поле модели сменилось на deepseek-chat на ходе 10 и обратно на ходе 11; 92 уникальных идентификатора вызовов инструментов дали 86 уникальных результатов | Опровергнуто |
| Безобидное сканирование интернета или поставщик сканера с необычным user agent | Внешняя репутация источника в сопоставлении с содержимым, которое вернул клиент | VirusTotal показывает 0 вредоносных вердиктов из 91 движка для 182.91.103[.]32; клиент вернул собственный набор правил bug bounty, конфигурацию FOFA MCP и список содержимого домашнего каталога, чего не носит с собой ни один поисковый краулер | Опровергнуто |
| Общий общедоступный инструментарий со множеством независимых пользователей, то есть адреса не связаны | Подсчитано число уникальных источников, предъявляющих user agent harness, и источников, предъявляющих каждый из двух ключей | User agent появляется из 3 источников в 3 /24 в 2 организациях в активности с 20 по 23 сентября 2026 года, но один и тот же API-ключ используют ровно два гонконгских хоста в одной организации, а ключ 41414141 уникален для 182.91.103[.]32 | Неопределённо |
| Оператор прервался, потому что конечная точка дала сбой | Порядок событий в сессии из одиннадцати ходов и после её последнего хода | Сессия из одиннадцати ходов идёт до 18:28:08.8Z, и после 18:28 адрес не отправлял дальнейших запросов; причина по имеющимся данным не известна | Неопределённо |
| Авторизованное тестирование на проникновение, областью которого, по мнению оператора, охвачена эта конечная точка | Сопровождается ли трафик каким-либо маркером авторизации, контактной строкой или ссылкой на область работ | Ни в одном событии с этого адреса не встречается контактный адрес, ссылка на область работ или заголовок авторизации; набор правил утверждает перед собственной моделью контекст авторизованного исследователя и предписывает ей не требовать доказательств авторизации, что является приёмом промпт-инжиниринга, а не свидетельством наличия области работ | Не проверялось |
В цифрах
Показатели рассчитаны по имеющимся данным и по результатам обогащающих запросов.
- Связи по VirusTotal. Адрес относится к CHINA UNICOM China169 Backbone в CN. Ни один движок не помечает сам адрес (0/91). VirusTotal не содержит пассивного DNS для этого адреса: не зафиксировано ничего, что бы на него указывало.
- Встречалось ранее. Наш отчёт DeepSeek Harness против похищенного LLM-шлюза: вызовы инструментов выполняются у вызывающей стороны имеет общие индикаторы
203.175.15[.]28,103.85.74[.]25.
Индикаторы компрометации
Приведённые ниже 3 сетевых индикатора обезврежены; пути даны в том виде, в каком наблюдались.
Сетевые
| Индикатор | Контекст |
|---|---|
182.91.103[.]32 | агентные сессии DeepSeek Harness; 279 отправок результатов инструментов с собственного хоста |
203.175.15[.]28 | тот же user agent harness плюс проверка ключа через python-requests; использует тот же похищенный ключ |
103.85.74[.]25 | тот же user agent harness и тот же похищенный ключ; перечислил двенадцать имён моделей |
Артефакты на хосте
| Индикатор | Контекст |
|---|---|
sk-0af475b8… | API-ключ, повторно используемый двумя из трёх адресов; получен до самого раннего зафиксированного обращения |
deepseek-harness/0.1.5-rc.2 (+https://github.com/deepseek-ai/deepseek-harness) | user agent клиента, 3 источника в период с 20 по 23 сентября 2026 года; более ранний вариант DeepSeek-Harness-Desktop/0.1.3-max из того же набора |
C:\Users\[user]\.dsh\rules\*.md | артефакт рабочей станции оператора; наблюдался как C:\Users\cheng.dsh\rules\researcher-blackbox-whitebox.md и playwright-browser-mcp.md в возвращённом выводе инструментов |
C:\Users\[user]\Desktop\clown-src-6k-skill\ | упакованное дерево навыков оператора для поиска уязвимостей, перечисленное в возвращённом выводе PowerShell |
cheng | имя учётной записи Windows на рабочей станции оператора, раскрытое в каждом возвращённом пути |
41414141 | одноразовый ключ, использованный для сессии harness из одиннадцати ходов; уникален для 182.91.103[.]32 во всей зафиксированной активности |
Обнаружение
Sigma
Агентный harness, обращающийся к неодобренной конечной точке completions (кандидат).
title: Agent harness calling an unapproved model completions endpoint
status: experimental
description: Detects an AI coding-agent harness sending chat completions to a model endpoint outside the approved host list. Requires proxy logging of the request URI and user agent; request bodies are usually not logged, so this rule keys on client identity and destination only.
logsource:
category: proxy
detection:
selection:
cs-uri-stem|endswith: '/v1/chat/completions'
cs-user-agent|contains:
- 'deepseek-harness/'
- 'DeepSeek-Harness-Desktop/'
filter_approved:
cs-host:
- 'api.deepseek.com'
- 'api.openai.com'
- 'api.anthropic.com'
condition: selection and not filter_approved
falsepositives:
- Developers legitimately using a self-hosted or third-party model endpoint absent from the approved host list
- Internal evaluation harnesses pointed at staging endpoints
level: high
Логика обнаружения
- Приём неизвестного bearer-ключа OpenAI-совместимой конечной точкой (сетевое, кандидат). На любой доступной из интернета OpenAI-совместимой конечной точке фиксируйте предъявленный bearer-ключ по каждому запросу и оповещайте, когда ключ, отсутствующий в реестре выданных ключей, получает ответ, отличный от 401, либо когда один ключ предъявляется более чем из одной автономной системы в течение часа. В описанной активности один и тот же ключ появлялся с двух хостов одной хостинговой организации, а три очевидно одноразовых ключа (141414, 41414141, sk-14141242…) использовались последовательно, чтобы проверить, требуется ли аутентификация вообще.
- Агентный harness, настроенный на автоматическое подтверждение вызовов инструментов при работе с внешней конечной точкой (хостовое, кандидат). На рабочих станциях разработчиков и исследователей помечайте конфигурационные файлы агентных harness, в которых режим автоматического подтверждения сочетается с базовым URL вне списка одобренных организацией хостов моделей. Конкретно: любой TOML или YAML в каталоге пользовательского профиля, содержащий permission_mode = “always-approve” (или эквивалентную настройку yolo либо auto-approve) вместе с пользовательским api base. Такой клиент выполнит любой вызов инструмента, который выдаст удалённая конечная точка, без участия человека.
- Вывод локальной файловой системы, отправленный в результатах инструментов chat-completion (поведенческое, кандидат). На эксплуатируемой вами конечной точке модели оповещайте, когда входящий запрос chat-completion содержит сообщения с ролью tool, чьё содержимое соответствует шаблонам хостовых артефактов: абсолютные пути Windows (^[A-Z]:\Users\), заголовки таблиц PowerShell вида ‘FullName … Length Mode’ или списки каталогов, содержащие .env либо .credentials. Легитимный трафик кодовых ассистентов действительно содержит содержимое файлов, поэтому настраивайте пороги по каждому арендатору; сигналом здесь является то, что отправляющий клиент не известен реестру ключей.
Меры по устранению
- Поместите любую доступную из интернета OpenAI-совместимую конечную точку за аутентификацию, которая действительно проверяется: отклоняйте неизвестные bearer-ключи ответом 401, а не обслуживайте их, и регистрируйте каждый выданный ключ с владельцем и сроком действия.
- Проверьте административные интерфейсы конечных точек моделей на предмет выпуска ключей без аутентификации и отзовите каждый ключ, который нельзя связать с известным владельцем. В описанной активности используемый ключ был уже действителен на момент самого раннего зафиксированного запроса (2026-09-20T12:22:32Z), и то, как он был получен, данными не подтверждается.
- Настройте агентные harness так, чтобы они требовали подтверждения выполнения инструментов, когда конечная точка модели отсутствует в списке одобренных хостов; рассматривайте сочетание permission_mode = “always-approve” с пользовательским базовым URL как запрещённое на любой машине, где хранятся учётные данные.
- Оповещайте об исходящем трафике с рабочих станций разработчиков к /v1/chat/completions на хостах вне списка одобренных поставщиков моделей, с привязкой к user agent агентных harness.
- Рассматривайте ответы модели как недоверенный ввод для слоя инструментов: конечная точка, которую вы не контролируете, может выдавать вызовы инструментов, а harness, который их выполняет, предоставляет ей доступ на чтение к рабочей станции.
Сопоставление с MITRE ATT&CK
| Тактика | Техника | Наблюдение |
|---|---|---|
| Уклонение от защиты | T1078 Valid Accounts | Два адреса аутентифицировались одним и тем же API-ключом, который уже находился у оператора на момент первого зафиксированного запроса |
| Развитие ресурсов | T1588.002 Obtain Capabilities: Tool | Оператор использует публичный агент DeepSeek Harness, браузерный MCP-сервер Playwright и MCP-сервер поиска активов FOFA, все зарегистрированы в возвращённом config.toml |
| Разведка | T1596 Search Open Technical Databases | config.toml регистрирует MCP-сервер FOFA с тремя наборами слотов для учётных данных, а набор правил описывает рабочий процесс с очередью отправных точек, управляемый результатами FOFA |
| Обнаружение | T1082 System Information Discovery | Обратное направление: собственный клиент оператора выполнил перечисление каталогов и файлов локально по указанию недоверенной конечной точки и отправил обратно 86 уникальных выводов |
Источники
- DeepSeek Harness (агентный harness с открытым исходным кодом, упомянутый в user agent клиента)
- OWASP Top 10 for Large Language Model Applications
Методология и примечания аналитиков
Имеющиеся данные ограничены запросами и ответами, которыми обменивались с одной доступной из интернета OpenAI-совместимой конечной точкой модели, и охватывают активность с 20 по 23 сентября 2026 года; что оператор делал вне этой конечной точки, не известно. API-ключ уже находился у оператора на момент самого раннего зафиксированного запроса, поэтому административный захват, в результате которого он появился, произошёл до всего наблюдаемого здесь, и его механика данными не подтверждается. Сведения о рабочей станции представляют собой только то, что клиент оператора сам решил вернуть; ни один хост не исследовался, и ничего не собиралось сверх того, что было отправлено на конечную точку. Ни один поставщик не имеет детектирования ни по одному из трёх адресов, и ни один из них не классифицирован как сканер, поэтому ничто в этом выводе не подтверждается вне описанного здесь трафика.
Остаётся открытым:
- Когда и каким запросом был впервые получен общий API-ключ.
- На какие другие открытые конечные точки моделей эта сборка harness направлена в настоящее время.
- Как оператор использовал доступ в период между проверкой ключа 20 сентября и сессиями harness с 182.91.103[.]32 23 сентября, с учётом того, что трафик с user agent harness из этого набора адресов появляется с 21 сентября.
Вопросы или исправления: contact@kinryu.sh.