#認証情報

マルウェアがAIを使う、と聞くと自動でフィッシング文面を作るような話を想像しがちだが、今回のVOLTAは少し違う。盗み出した情報をもとに、次に誰をどう深掘りするかをLLMに判断させている。しかも、その判断材料はパスワードやCookieだけではない。住所や勤務先、購入履歴、SlackやDiscordの痕跡までまとめて、被害者の「価値」を順位づけする。攻撃の自動化というより、犯罪の現場に査定担当を置いたような構図だと思う。AIの使い道が派手な生成ではなく、こうした裏方の作業に寄ってきたことが、いま取り上げる理由でもある。 Cisco Talosが追ったVOLTAは、自らを「VOLTA-AUTODOXER」と名乗る自己削除型のWindows向けinfostealerだ。まず通常のstealerと同じように、Chromium系ブラウザの保存パスワードやCookie、支払いカード、暗号資産ウォレットのseed phrase、Discord・Telegram・Steam・Robloxのセッション、Microsoft OAuth token、SSHやクラウドの認証情報、Wi-Fiプロファイル、スクリ

Northflankのステータスページには、サービス障害の案内に加えて、かなり切迫したSecurity incidentの更新が並びました。単なる遅延や一時停止の話ではなく、利用者が保存していたAI API keysや環境変数が不正利用された可能性を前提に、すぐに全秘密情報を回転させるよう呼びかけているのが特徴です。しかも、対象は一部の機能ではなく、platform全体の複数コンポーネントにMajor outageが付く状態でした。クラウド基盤を使う人にとっては、「止まった」以上に「保管していた認証情報が危ないかもしれない」という点が重いニュースです。 Northflankのステータスページでは、まず「Experiencing partial outage」として一部障害が示されたあと、Security incidentが「Identified」、さらに「Major outage」へと整理されていました。更新は2026年10月30日UTCの同じ日に何度も行われ、最初の時点では「Users have reported unauthorised use of AI API keys sup

読んでまず思ったのは、「鍵は“見せない仕組み”に預けても、結局はどこかで守る責任が残るんだな」ということでした。OpenCode Console は、ユーザーが OpenAI や Anthropic、Google の API key を預けておき、チーム内で直接キーを見せずに使えるのが売りだったわけですが、その“預け先”がやられると話は一気に変わります。便利さと引き換えに、守るべき面がひとつ増える。これは分かりやすいのに、実際には軽く見られがちな落とし穴だと思います。 特に引っかかったのは、`delete` しただけではダメで、provider 側で `revoke` しないと止まらない点です。ここは地味ですがかなり重要で、API key が bearer credential だという性質がそのまま効いてくる。つまり、誰かがコピーを持ってしまえば、その人が正規の持ち主みたいに課金付きのリクエストを飛ばせてしまう。セキュリティ事故の話で「漏れたかもしれない」で終わらず、「その後にどう止血するか」が本体なんだと改めて感じました。 もうひとつ、この記事で少し気になったのは、OpenCode

OpenCode の X 投稿は、セキュリティ侵害が起きたことを自ら公表する内容だった。しかも単なる不具合報告ではなく、large scale distillation attack に関連した breach だとしている点が重い。AI 開発や coding agent の周辺では、モデルの挙動や内部情報を抜き取ろうとする攻撃への警戒が高まっているが、今回の投稿はその現実味を一段と強く見せた。しかも影響を受けたのが OpenCode Console users の 1.4% と、割合は小さく見えても無視できない規模だった。 OpenCode は、前夜にセキュリティ侵害があったと X で明かした。原因として挙げたのは「large scale distillation attack」で、これが OpenCode Console の利用者の 1.4% に影響したという。ここでいう distillation attack は、一般に AI モデルの出力や挙動を大量に集めて模倣や再現を狙う行為を指す文脈で使われることが多い。つまり、単なるアカウント乗っ取りや一般的な情報漏えいではなく、AI サー

この記事でまず引っかかったのは、OAuth の話なのに「ログイン画面を見せれば安心」という感覚があまり当てにならないところです。ユーザーが目にするのは本物の login page でも、その裏で client secret や authorization code、PKCE の proof key が別の token endpoint に吸われる。見た目が正しいことと、通信の行き先が正しいことは別物だと、あらためて突きつけられた感じがしました。 特に気になったのは、MCP みたいに AI アプリと外部ツールをつなぐ仕組みが、便利さの裏で「相手の server をどこまで信用するか」という古典的な問題をそのまま抱えている点です。しかも machine-to-machine の provider だと、人が操作しなくても成立してしまう。これ、単なる実装ミスというより、AI 周辺の連携機能が増えるほど攻撃面も増える、という嫌な予感を強める話だと思います。 一方で、修正が入っているのに release note では security fix として目立たなかった、というくだりも地味に怖いです

この記事を読んでまず思ったのは、「また新しい安全対策の話か」と身構えたら、実はかなり根っこを突いていた、ということだった。MCP(Model Context Protocol)の話になると、つい認証や暗号化のような“わかりやすい防御”に目が行く。でも著者たちは、そこだけを見ていても足りないと言っている。むしろ問題は、AI agentにどこまで権限を渡すのか、渡した後にどう縛るのか、という設計そのものにある。これはかなり筋がいい指摘だと思う。 特に引っかかったのは、standing credentials、つまり長く生きる認証情報の扱いだ。人間の操作なら多少の過剰権限は「まあこの人は経理だから」で済むこともある。でも agent は一度つなぐと、速い・広い・止まらない。その動きに、昔ながらの「とりあえず強い鍵を渡しておく」運用を持ち込むのは危ない。便利だからこそ雑に広い権限を渡しがちで、その雑さが一気に事故になる、という感覚はよくわかる。 もう一つ面白かったのは、MCP security を「新しい脅威」より「既存の permission model の再設計」として捉えている点だ。派手

まず驚いたのは、攻撃者がClaudeそのものを直接どうこうしたというより、利用者のPCに入ったinfostealer malware（保存済みパスワードやcookieを抜くタイプのマルウェア）を踏み台にしている点だった。AIサービスの話なのに、結局いちばん弱いのはブラウザと端末側、といういつもの現実に戻ってくる。少し拍子抜けでもあるし、妙に腑に落ちる話でもある。 それにしても、usage limitsを「勝手に使い切られる」という被害の見え方が地味に嫌だ。金額の大きな決済不正よりも、最初はただ「なんかクォータの減りが早いな」で済まされかねない。しかもAnthropicはセッションをログアウトさせ、支払い情報まで外した。守りとしては筋が通っているけれど、正規ユーザーからすると一気に“自分のアカウントが信用できない状態”に落ちる。ここはかなり強い対応だと思う。 記事を読んでいて、AIアカウントの保護が「強いパスワード」だけでは全然足りないことも改めて見えた。cookieや保存ログインを抜かれたら、本人確認をすり抜けてそのまま入られる。結局、怪しいdownloadや非公式アプリを避ける、端末

認証を突破して中身を盗む話かと思ったら、もっと地味でいやらしい手口だった。Claudeのセッションを盗んで、本人になりすまして使い切る。しかもパスワードや2FAを毎回突破する必要すらない、というのが妙に生々しい。 ここで引っかかったのは、被害が「情報漏えい」だけで終わらないことだ。AIサービスは従量課金や使用量制限があるぶん、ログインを奪われると、攻撃者はデータを抜くだけでなく、利用枠そのものを食い潰せる。つまり被害の形が、昔ながらの「盗む」から「浪費させる」に少し変わっている。これは利用者にとってかなり嫌な変化だと思う。 もうひとつ、Anthropicが「Claudeが原因ではない」と強く釘を刺しているのも印象に残った。たぶん誤解されやすいんだろう。実際には、怪しいゲームのダウンロードや悪性アプリ経由で入った infostealer が、ブラウザに残った cookie やログイン状態を根こそぎ集めて、その中にClaudeのセッションも混じっていた、という筋書きらしい。AIの問題に見えて、根はかなり古典的なマルウェア被害だ。 だから対処も派手さはない。サインアウトさせるだけでは足りず、

この記事を読んでまず思ったのは、「パッケージを入れるだけでここまでやられるのか」という、かなり素朴で、それでいて重い怖さでした。npm の malware というだけなら珍しくないのですが、今回は単に credential を抜くだけで終わらず、感染した package からさらに別の package へ広がっていく“worm”になっている。しかも開発者の手元だけでなく CI 環境まで狙っているので、被害の入口がかなり広い。ライブラリを `install` した瞬間の lifecycle script がこんなに危ないのだと、あらためて突きつけられます。 特に引っかかったのは、「署名や provenance があるから安心、とはならない」点です。GitHub Actions の正規の release workflow を通っていて、OpenID Connect や SLSA の provenance まで付いていたとある。でも、それでも中身が安全だとは言えなかった。ここはかなり厄介で、いまの開発現場が頼っている“信頼の見え方”が、攻撃者の動き方と相性が悪いのだと思います。証明書や ba