1. 安全運(yùn)營里的真實(shí)痛點(diǎn)告警太多、攻擊鏈看不清安全運(yùn)營中心SOC每天面對(duì)的現(xiàn)實(shí)是EDR、防火墻、郵件網(wǎng)關(guān)、身份系統(tǒng)各吐各的告警一個(gè)勒索軟件事件可能在 6 個(gè)索引里留下 40 條獨(dú)立告警但值班分析師看到的只是「PowerShell 編碼命令執(zhí)行」「LSASS 訪問」「卷影副本刪除」三條互不相干的記錄。Elastic Security 的 Attack Discovery 功能解決的正是這個(gè)問題——它把多條安全告警喂給 LLM讓模型自動(dòng)識(shí)別跨告警的攻擊鏈輸出帶時(shí)間線和 MITRE 戰(zhàn)術(shù)映射的敘述性報(bào)告。但這里有個(gè)很多人踩過的坑Attack Discovery 不是裝好就自動(dòng)跑的后臺(tái)服務(wù)。你在 Kibana 里配好了 AI Connector、測(cè)試返回 pong、許可證也正常索引.alerts-security.attack.discovery.alerts-default卻始終是 0 條文檔。原因很簡單——調(diào)度Schedule是獨(dú)立對(duì)象不顯式創(chuàng)建就永遠(yuǎn)不會(huì)觸發(fā) LLM 分析。這篇內(nèi)容面向做安全運(yùn)營、想把攻擊鏈分析流程自動(dòng)化的工程師。我會(huì)用 Claude Code 配合 Elastic AI Agent Builder MCP把「創(chuàng)建調(diào)度 → 立即觸發(fā) → 查詢攻擊鏈 → 溯源原始告警」整條鏈路走通同時(shí)給出 TaoToken 統(tǒng)一 Key/API 通道的配置片段讓模型調(diào)用走同一個(gè)入口省去在多個(gè) provider 之間來回切換的麻煩。適合誰手上已有 Elastic 9.x 集群、想讓 Claude Code 直接對(duì)話式操作 Elastic Security、又不想每次翻 API 文檔的人。整個(gè)流程的核心只有三步創(chuàng)建調(diào)度、手動(dòng)觸發(fā)、用 ES|QL 查結(jié)果并關(guān)聯(lián)原始告警。下面按可跟做的順序展開。2. TaoToken 前置準(zhǔn)備統(tǒng)一 Key 與 API 通道在動(dòng)手配 MCP 之前先把模型調(diào)用這一層理順。Claude Code 本身要調(diào)模型Elastic Attack Discovery 背后的 Connector 也要調(diào)模型如果兩邊各配一套 Key、各記一個(gè) Base URL排障時(shí)很容易搞混是誰的憑證失效了。我的做法是統(tǒng)一走 TaoToken 的 API 通道一個(gè) Key、一個(gè) Base URLClaude Code 和 Elastic Connector 都指向它。官網(wǎng)入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端點(diǎn)是 https://taotoken.net/api 這個(gè)不加 UTM直接作為 Base URL 用。注冊(cè)后在控制臺(tái)的 API Keys 頁面生成一個(gè) Key形如sk-開頭的一串字符復(fù)制下來先存到環(huán)境變量里別直接寫進(jìn)配置文件提交到倉庫。export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api這里要區(qū)分兩個(gè)概念很多人第一次配會(huì)混。Claude Code 用的 Base URL是給 Anthropic 兼容協(xié)議用的通常要在后面拼上版本路徑Elastic Connector 用的 Base URL是 OpenAI 兼容協(xié)議走/v1這一層。兩者指向同一個(gè)域名只是路徑不同。你可以在 TaoToken 的模型對(duì)話頁面先驗(yàn)證 Key 是否可用再往下配。關(guān)于模型選擇Claude Code 側(cè)我一般用 claude-sonnet 系列做代碼和工具調(diào)用Elastic Attack Discovery 側(cè)的 Connector 可以用同一通道下的其他模型比如 qwen 系列或 gpt 系列因?yàn)?Attack Discovery 對(duì)模型的要求是「能讀懂多條告警并做歸納」不一定非要最強(qiáng)的編碼模型。統(tǒng)一通道的好處是賬單和限流在一個(gè)地方看出問題只查一處。注意Key 只存在服務(wù)端環(huán)境變量或密鑰管理里不要寫進(jìn) MCP 的 JSON 配置明文后提交 Git。下面示例里我用${TAOTOKEN_API_KEY}占位實(shí)際運(yùn)行時(shí)由 shell 展開。配好之后建議先做一次最小連通性測(cè)試確認(rèn) Key 和 Base URL 都對(duì)再進(jìn)入 MCP 配置環(huán)節(jié)。測(cè)試命令用 curl 打一個(gè)模型列表或最小對(duì)話請(qǐng)求即可返回 200 且結(jié)構(gòu)正常就說明通道沒問題。這一步花兩分鐘能省掉后面「到底是 MCP 配錯(cuò)了還是 Key 失效了」的反復(fù)排查。3. 可復(fù)制配置MCP 服務(wù)端與 Claude Code 客戶端這一節(jié)是全文最需要照著抄的部分。Elastic AI Agent Builder MCP 的本質(zhì)是把 Elastic 的 API 能力包裝成 MCP 工具讓 Claude Code 能通過對(duì)話調(diào)用。配置分兩處MCP 服務(wù)端的啟動(dòng)參數(shù)以及 Claude Code 客戶端的settings.json或 MCP 注冊(cè)配置。先看 MCP 服務(wù)端。Elastic 官方提供了 MCP server 的啟動(dòng)方式核心是三個(gè)環(huán)境變量Elasticsearch 地址、認(rèn)證信息、以及是否跳過自簽名證書校驗(yàn)本地或測(cè)試集群常見。如果你用的是 9.x 自建集群且證書是自簽的ELASTICSEARCH_INSECUREtrue必須開否則連接會(huì)直接失敗。# MCP 服務(wù)端啟動(dòng)參數(shù)示例按你的集群地址替換 export ELASTICSEARCH_URLhttps://localhost:9200 export ELASTICSEARCH_USERNAMEelastic export ELASTICSEARCH_PASSWORD你的密碼 export ELASTICSEARCH_INSECUREtrue # 自簽名證書時(shí)開啟 export KIBANA_URLhttp://localhost:5601然后是 Claude Code 客戶端的 MCP 注冊(cè)配置。Claude Code 讀取的配置文件通常在用戶目錄下的.claude/settings.json或項(xiàng)目級(jí).mcp.json具體路徑以你本地版本為準(zhǔn)。下面這段是可直接復(fù)制的 JSON 片段注意command和args要指向你實(shí)際安裝的 MCP server 入口env里把上面那些變量帶進(jìn)去同時(shí)把 TaoToken 的 Key 和 Base URL 也注入保證 MCP 內(nèi)部若需要調(diào)模型時(shí)走統(tǒng)一通道。{ mcpServers: { elastic-agent-builder: { command: npx, args: [-y, elastic/mcp-server-elasticsearch], env: { ELASTICSEARCH_URL: https://localhost:9200, ELASTICSEARCH_USERNAME: elastic, ELASTICSEARCH_PASSWORD: ${ELASTIC_PASSWORD}, ELASTICSEARCH_INSECURE: true, KIBANA_URL: http://localhost:5601, OPENAI_BASE_URL: https://taotoken.net/api/v1, OPENAI_API_KEY: ${TAOTOKEN_API_KEY} } } } }如果你用的是 Cline 或 CC Switch 這類客戶端來管理 MCP配置結(jié)構(gòu)大同小異關(guān)鍵是三件套齊全Base URL、Key、Model ID。Base URL 填https://taotoken.net/api/v1Key 填你的sk-憑證Model ID 填你在 TaoToken 控制臺(tái)看到的模型標(biāo)識(shí)比如claude-sonnet-4-6或qwen3.5-plus。三件套缺一個(gè)調(diào)用就會(huì)報(bào) 401 或 model not found。Elastic 側(cè)的 AI Connector 也要配一份因?yàn)?Attack Discovery 的調(diào)度參數(shù)里要引用connectorId。在 Kibana 里創(chuàng)建 Connector 時(shí)選 OpenAI 類型Base URL 同樣填 TaoToken 的/v1地址Key 填同一個(gè)模型填你選定的 Model ID。創(chuàng)建完記下返回的 connector id后面創(chuàng)建調(diào)度要用。# 驗(yàn)證 Connector 是否可用把 ID 換成你的 curl -sk -u elastic:${ELASTIC_PASSWORD} \ -X POST http://localhost:5601/api/actions/connector/${CONNECTOR_ID}/_execute \ -H kbn-xsrf: true -H Content-Type: application/json \ -d {params:{subAction:invokeAI,subActionParams:{messages:[{role:user,content:ping}]}}}返回里帶status:ok和模型回復(fù)內(nèi)容說明 Connector 通了。這一步不通后面創(chuàng)建調(diào)度也是白搭因?yàn)?Attack Discovery 觸發(fā)時(shí)會(huì)用這個(gè) Connector 去調(diào)模型。4. 驗(yàn)證請(qǐng)求與成功結(jié)果從創(chuàng)建調(diào)度到攻擊鏈查詢配置通了之后進(jìn)入真正的攻擊鏈分析流程。我按實(shí)際操作順序走一遍每步都給命令和預(yù)期返回結(jié)構(gòu)。第一步確認(rèn) Attack Discovery 索引狀態(tài)。先看索引存不存在、有多少文檔。如果 count 為 0說明從未運(yùn)行過這是后面要?jiǎng)?chuàng)建調(diào)度的信號(hào)。curl -sk -u elastic:${ELASTIC_PASSWORD} \ https://localhost:9200/.alerts-security.attack.discovery.alerts-default/_count # 預(yù)期{count:0,_shards:{...}}第二步創(chuàng)建 Attack Discovery 調(diào)度。這是整個(gè)流程的關(guān)鍵不創(chuàng)建就永遠(yuǎn)不會(huì)有結(jié)果。參數(shù)里alerts_index_pattern指向原始告警索引api_config引用上一步的 Connectorsize控制喂給 LLM 的告警條數(shù)建議 100~200太大容易超 Token 限制start/end是分析時(shí)間窗。curl -sk -u elastic:${ELASTIC_PASSWORD} \ -X POST http://localhost:5601/api/attack_discovery/schedules \ -H kbn-xsrf: true -H Content-Type: application/json \ -d { name: 每日安全攻擊分析, enabled: true, params: { alerts_index_pattern: .alerts-security.alerts-default, api_config: { actionTypeId: .gen-ai, connectorId: ${CONNECTOR_ID}, model: qwen3.5-plus, provider: OpenAI }, size: 100, start: now-30d, end: now }, schedule: {interval: 24h}, actions: [] } # 預(yù)期返回含 id:schedule-id記下來第三步立即觸發(fā)一次。不想等 24 小時(shí)調(diào)度周期用_run_soon手動(dòng)跑。注意這個(gè)接口需要x-elastic-internal-origin頭否則會(huì)被拒。curl -sk -u elastic:${ELASTIC_PASSWORD} \ -X POST http://localhost:5601/internal/alerting/rule/${SCHEDULE_ID}/_run_soon \ -H kbn-xsrf: true -H x-elastic-internal-origin: Kibana # 預(yù)期Rule is already running 或觸發(fā)成功提示第四步查詢攻擊鏈結(jié)果。分析完成后用 ES|QL 查 open 狀態(tài)的攻擊發(fā)現(xiàn)。返回結(jié)構(gòu)里重點(diǎn)看title、summary_markdown、details_markdown、mitre_attack_tactics四個(gè)字段。FROM .alerts-security.attack.discovery.alerts-default METADATA _id | WHERE timestamp NOW() - 24 hours AND kibana.alert.workflow_status open | KEEP _id, kibana.alert.attack_discovery.title, kibana.alert.attack_discovery.summary_markdown, kibana.alert.attack_discovery.details_markdown, kibana.alert.attack_discovery.mitre_attack_tactics | SORT timestamp DESC | LIMIT 20一次成功的返回會(huì)長這樣title是「Ransomware Attack Chain」這類歸納名details_markdown里是帶時(shí)間戳的攻擊步驟敘述比如「WINWORD.EXE 派生 powershell.exe 執(zhí)行編碼命令 → 建立 C2 連接 → rundll32 轉(zhuǎn)儲(chǔ) LSASS 憑證 → vssadmin 刪除卷影副本 → 批量加密文件 → 投放勒索信」。mitre_attack_tactics會(huì)映射到 Execution、Credential Access、Impact 等戰(zhàn)術(shù)。第五步溯源原始告警。拿到攻擊發(fā)現(xiàn)后用_id關(guān)聯(lián)回原始告警索引還原完整時(shí)間線。這一步是把 LLM 的歸納落回可驗(yàn)證的原始證據(jù)。FROM .alerts-security.alerts-default METADATA _id | WHERE _id IN (D11_kJ0Bb_T067uw3Wd2, Dl1_kJ0Bb_T067uw3Wd2) | KEEP _id, kibana.alert.original_time, kibana.alert.rule.name, host.name, user.name, process.name, process.command_line, process.parent.name | SORT kibana.alert.original_time ASC預(yù)期返回是按時(shí)間升序的告警序列process.parent.name能拼出進(jìn)程父子樹process.command_line里能看到編碼命令和 C2 地址。到這一步一條從「告警太多」到「攻擊鏈清晰」的閉環(huán)就走完了。5. 常見報(bào)錯(cuò)排查401、local proxy failed、reading choices實(shí)操中卡住的地方基本集中在幾個(gè)固定報(bào)錯(cuò)上我按出現(xiàn)頻率排一下每個(gè)都給定位思路。401 Unauthorized。兩種可能TaoToken 的 Key 失效或沒注入或者 Elastic 的認(rèn)證信息錯(cuò)了。先分清是哪一層——如果 Claude Code 對(duì)話時(shí)直接報(bào) 401查OPENAI_API_KEY環(huán)境變量是否被 shell 正確展開${TAOTOKEN_API_KEY}在 JSON 里不會(huì)自動(dòng)展開要確認(rèn)客戶端支持變量替換否則直接寫值但別提交。如果是創(chuàng)建調(diào)度時(shí)報(bào) 401查elastic用戶密碼和 Connector 的 Key。用前面那條_execute測(cè)試命令單獨(dú)驗(yàn)證 Connector能快速定位。local proxy failed。這個(gè)報(bào)錯(cuò)通常出現(xiàn)在 MCP 客戶端連不上 MCP server 時(shí)本質(zhì)是本地進(jìn)程沒起來或端口不通。檢查command和args指向的包是否已安裝npx -y首次運(yùn)行會(huì)下載網(wǎng)絡(luò)慢時(shí)會(huì)超時(shí)以及ELASTICSEARCH_URL是否可達(dá)。自建集群如果開了自簽名證書但沒設(shè)ELASTICSEARCH_INSECUREtrue連接會(huì)在 TLS 握手階段失敗表現(xiàn)也類似代理失敗。用curl -sk先手動(dòng)打一下 ES 的根路徑確認(rèn)網(wǎng)絡(luò)層通。reading choices 相關(guān)報(bào)錯(cuò)。這類錯(cuò)誤一般來自模型返回結(jié)構(gòu)不符合預(yù)期常見于 Base URL 拼錯(cuò)比如漏了/v1導(dǎo)致請(qǐng)求打到了非 OpenAI 兼容端點(diǎn)返回的是 HTML 或錯(cuò)誤 JSON解析choices字段時(shí)就崩了。核對(duì) Base URL 是否為https://taotoken.net/api/v1Model ID 是否在 TaoToken 控制臺(tái)存在。另外size設(shè)太大導(dǎo)致上下文超限時(shí)也可能在解析階段報(bào)錯(cuò)把size降到 100 再試。OAuth 相關(guān)報(bào)錯(cuò)。如果你用的客戶端默認(rèn)走 OAuth 流程而你的通道是 API Key 模式會(huì)提示授權(quán)失敗。在客戶端配置里顯式指定 API Key 認(rèn)證方式別讓它自動(dòng)探測(cè)。CC Switch 這類工具里通常有「認(rèn)證方式」下拉選 API Key 并填三件套。調(diào)度創(chuàng)建成功但索引仍為 0。檢查調(diào)度是否enabled: true以及_run_soon是否真的觸發(fā)了。有時(shí)返回「Rule is already running」是因?yàn)樯弦淮芜€在跑等幾分鐘再查。另外確認(rèn)alerts_index_pattern指向的索引里確實(shí)有數(shù)據(jù)空告警喂給 LLM 也不會(huì)有輸出。報(bào)錯(cuò)最可能原因快速驗(yàn)證401Key 未注入/失效單獨(dú)跑_execute測(cè)試local proxy failedMCP server 未啟動(dòng)/證書curl -sk打 ES 根路徑reading choicesBase URL 缺/v1核對(duì)端點(diǎn)與 Model IDOAuth 失敗認(rèn)證方式選錯(cuò)客戶端改 API Key 模式6. 把流程固化成日常調(diào)度參數(shù)與后續(xù)動(dòng)作跑通一次之后真正有價(jià)值的是把它變成日常運(yùn)營的一部分。調(diào)度參數(shù)里schedule.interval建議按告警量設(shè)告警多的環(huán)境用1h或6h少的用24h足夠size控制在 100~200既能讓 LLM 看到足夠上下文又不至于超 Token。actions字段可以配置分析完成后的通知比如寫入 Elastic Cases 或推送到協(xié)作工具這樣分析師不用盯著索引等結(jié)果。我自己的習(xí)慣是保留一份調(diào)度管理 API 的速查方便隨時(shí)查狀態(tài)、改參數(shù)、臨時(shí)觸發(fā)。常用的就幾個(gè)GET /api/attack_discovery/schedules/_find列所有調(diào)度POST .../_run_soon手動(dòng)觸發(fā)PUT改參數(shù)DELETE清理廢棄調(diào)度。配合 Claude Code 的對(duì)話能力這些操作可以直接用自然語言描述讓模型生成命令省去翻文檔。需要提醒的是Attack Discovery 的輸出是 LLM 歸納結(jié)果details_markdown里的時(shí)間線和進(jìn)程關(guān)系要回到原始告警用 ES|QL 驗(yàn)證別直接當(dāng)結(jié)論用。把「LLM 歸納 原始證據(jù)溯源」當(dāng)成固定動(dòng)作分析質(zhì)量才穩(wěn)得住。如果你想把模型調(diào)用和 MCP 配置再簡化可以從 API Keys 頁面統(tǒng)一管理憑證https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入細(xì)節(jié)看文檔https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。長期做編碼和 Agent 類任務(wù)的話Coding Plan 能把額度集中管理https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。先把調(diào)度建起來、觸發(fā)一次、查到第一條攻擊鏈?zhǔn)Ｏ碌木褪钦{(diào)參數(shù)和接通知了。