Elastic Security Labsが確認した事実
Elastic Security Labsは10月12日、Apex Acceleratorを名乗るoperationの調査結果を公開しました。Apexは無料のAI credit、coding tool、security auditを提供するWeb3 acceleratorを装っていました。Elasticによると、このoperationは悪意あるnpm packageとbackdoor入りrepositoryを配布し、model trafficを攻撃者管理infraへroutingし、remote MCP serverを登録したうえで、WindowsとmacOSへmalwareを配信しました。ここまではElasticが報告した調査結果であり、以下はIneezaの本番運用分析です。
Elasticが特定したpackageは@apexacc/cliと@apexacc/auditです。前者は実際に動作するopen-source coding agentを再package化しており、追加されたbootstrap logicを隠しやすくしていました。後者は18個のsecurity-audit toolを掲げていましたが、Elasticは全18 toolが本来のscanを実行せず、hard-coded、入力整形、日付由来、またはrandomなreportを生成していたと報告しています。これは悪意ある依存関係であるだけでなく、security支援を求めるteamに提示された偽の保証layerでもあります。
有用なtoolでも敵対的control planeになり得る
Elasticによると、@apexacc/cliはOpenRouterとして表示されたrequestを攻撃者管理endpointへ転送しました。そのrequestにはprompt、conversation history、code snippet、tool outputが含まれ得ます。さらに、softwareは攻撃者管理のMCP serverを永続登録し、そのinstructionとtool definitionをagent contextへ追加しました。Elasticはroutingとcontrol surfaceを観測しましたが、悪意あるLLM responseへの差し替えは観測していないと明記しています。
Ineezaの分析: agentが「動く」ことの確認はsecurity testではありません。再package化されたtoolは実用機能を十分残し、functional reviewを通過しながら、機密contextの送信先やmodelが参照するtoolを変更できます。本番導入ではpackage digest、完全なdependency graph、実行binary、model endpoint、MCP registry、実効tool policyを一つのversion管理されたdeployment unitとしてattestすべきです。いずれか一つの変更でも承認を無効にする必要があります。
Package installと実行を別々にgateする
Elasticの調査では、packageのcommand entryがGitHub releaseからplatform別のexecutableをdownloadし、user home directoryへcacheしていました。bootstrap pathは攻撃者が選んだcommandを取得可能でした。Elasticによると、Windows pathはsecurity controlの弱体化を試み、macOS pathはCloudSyncD malwareを配信しました。開示されたWindows chainは最終的にsystem情報、browserとwallet関連データ、MCP関連fileなどのcredentialを収集し、外部送信する設計でした。
Ineezaの分析: lockfileとregistry allowlistが統制するのは最初のhopだけです。未申告のruntime downloadを拒否し、release artifactを承認済みhashで検証し、child process実行を制限し、agentのegressを指定modelとtool endpointへ限定する必要があります。wallet、signing access、本番credential、customer dataを持つdeveloper machineでは、信頼未確立のAI toolをambient secretのない分離環境と別identityで実行すべきです。
Security reportには独立したprovenanceが必要
Elasticが@apexacc/auditの全toolで偽の結果を確認した点は、smart contract teamにとって特に重要です。もっともらしいscoreやfindingは、実際にはanalyzerが一度も動いていなくても、release gate、投資判断のsignal、または本来必要なreviewを省略する根拠になり得ます。
Ineezaの分析: security evidenceには、正確なanalyzer、ruleset、入力commit、dependency state、実行環境、開始・終了時刻、raw artifact digestを記録すべきです。CIはreport生成toolから独立してprovenanceを検証する必要があります。高impactなcontractとwallet softwareでは、新しく導入したscannerのclean判定を、再現可能なstatic analysis、test evidence、deployment simulation、人によるreviewの代替にしてはいけません。
Incident responseではindicatorだけでなくtrustを入れ替える
Elasticは防御側向けにpackage、file、network、walletのindicatorを公開しました。これらは即時のhuntingに有用ですが、報告されたaccess pathは単一binaryを越えています。model traffic、agent configuration、MCP登録、local credential、browser data、wallet materialがすべて調査範囲に入り得ます。
Ineezaの分析: response teamは対象hostを隔離して証跡を保全し、永続化されたagent・MCP設定を削除し、既知のclean systemからcredentialをrotateすべきです。また、対象期間のmodel-provider log、tool call、codeとartifactのprovenance、wallet activity、deployment historyを確認する必要があります。workstationを再構築しても、そこに載っていたidentityとexecution pathを失効させなければ、攻撃者にとって最も価値あるaccessが残ります。
Ineezaの見解
Apex campaignが重要なのは、本番teamが別々に評価しがちな三つのtrust failure、すなわちsoftware supply chain、AI-agent control plane、Web3 security assuranceを一つに接続したためです。持続的な防御はend-to-endのadmission boundaryです。検証済みartifact、分離実行、明示的egress、固定されたmodel・MCP endpoint、provenance付きsecurity evidence、訓練済みのcredential・wallet responseが必要です。brandの信頼感や便利な機能は、このproof chainの代わりにはなりません。