モバイルアプリケーションのスキャンは、本来シンプルなはずです。アプリを入手し、アクセスを用意し、スキャンを実行し、検出結果を修正するだけです。
しかし大企業では、そううまくはいきません。各ステップが別々のチームに依存することがあります。アクセス、承認、修復が絡むと、1回のスキャンがすぐに調整の課題に変わります。
今週は、テクノロジーと再現可能なワークフローによって、テストと修復にまたがるこうした依存関係をどう減らせるかを見ていきます。
ほかにも、企業のシステムに到達したClaudeモデル、自律型AIによる悪用、テナントをまたぐAzureのリスク、XCSSETによるサプライチェーン攻撃、ミネソタ州の水道システムへのサイバー攻撃、Androidアプリのトラフィックを調べるためのPCAPdroid、不審なITヘルプデスクのメッセージなどを取り上げます。
この号の内容
🌡️ 脅威レベル：厳重警戒
⚡ ニュース：押さえておきたい5つのセキュリティニュース
🔎 ディープダイブ：エンタープライズのセキュリティスキャンの背後にある組織的な課題
🎣 これはフィッシング？
🔬 技術研究：GoPhishの作成用エンドポイントがリソースの所有権を移転し得た仕組み
🛠️ 今週のツール：PCAPdroid
👤 今週の人物：Emanuele Faranda
📅 今週のイベント：next.app devCon 2026
📚 今週の本：Practical Reverse Engineering
😅 今週のミーム
❓ 最後にひとつ質問
では、始めましょう。
今週の話題に入る前に、現在の脅威レベルを確認しておきましょう。
🌡️脅威レベル
⚡ ニュース
AnthropicのAIモデルが社内テスト中に実在する企業のシステムにアクセス
Anthropicは、運用上のミスで意図せずインターネットへのアクセスが許可された結果、社内のサイバーセキュリティ評価中に3つのClaudeモデルが実在する企業のシステムにアクセスしたことを明らかにしました。モデルが用いたのは新しいエクスプロイトではなく、脆弱な認証情報、公開されたエンドポイント、誰でもアクセスできるサービスといったおなじみの手法でした。同社はインシデントの調査中、サイバー評価を一時停止しました。この件は、AIのテスト環境を本番インフラから隔離することの重要性を浮き彫りにしています。
Anthropic：3つのAIモデルが、意図しないインターネットアクセスを通じて社内テスト環境から企業のシステムへと向かう。
自律型AIが脆弱性の発見から悪用の成功にまで到達
Unit 42は、中国語を話す脅威アクターがHermes Agentフレームワークを通じてDeepSeekを使い、人間の関与を限定したまま標的を列挙し、公開エクスプロイトを探し出し、攻撃を開始していたことを報告しました。研究者は、Citrix NetScalerの3つの標的からのデータ窃取と、Marimo notebookの11のエンドポイントでのコマンド実行を確認しています。防御側は、インターネットに公開されたインフラ全体で、既知の脆弱性がより速く自動的に悪用される事態に備える必要があります。
自律型AIによる悪用：AIエージェントが標的を発見し、公開エクスプロイトを見つけ、3つのNetScalerの標的と11のMarimoエンドポイントを攻撃する。
Azureの1つのクエリチェーンで、顧客テナントをまたいでデータベースが開かれ得た
WizはCosmosEscapeを公表しました。Azure Cosmos DBのGremlin APIに存在した脆弱性チェーンで、現在は修復済みです。報告によれば、クエリのサンドボックスから脱出すると、顧客アカウントのキーを取得できるプラットフォーム全体のシークレットが露出し、テナントをまたいだ完全な読み書きアクセスが可能になるおそれがありました。Microsoftは、顧客への影響を示すエビデンスは見つからなかったとしています。この事例は、共有のクラウドゲートウェイとコントロールプレーンのシークレットに、とりわけ強固な隔離が必要な理由を示しています。
CosmosEscape：Gremlin APIのクエリがサンドボックスから脱出し、顧客テナントをまたいだアクセスを可能にし得るプラットフォームのシークレットを露出させる。
XCSSETが、汚染されたXcodeプロジェクトをmacOSのサプライチェーン経路に変える
Unit 42はXCSSET v40を分析しました。侵害されたXcodeプロジェクトを通じて開発者を狙う、macOSマルウェアの更新版です。このモジュール型フレームワークは大部分をメモリ上で実行でき、macOSの環境設定を通じて永続化し、セキュリティ制御を妨害し、ブラウザーを乗っ取るコンポーネントを配布できます。開発者のワークステーションには署名用の資産や本番環境の認証情報が置かれていることが多いため、不審なプロジェクトのビルドは、孤立したエンドポイントの感染ではなく、サプライチェーンのインシデントの可能性があるものとして扱うべきです。
XCSSET：マルウェアが侵害されたXcodeプロジェクトから開発者のワークステーションを経由し、署名用の資産と本番ビルドへと向かう。
ミネソタ州の30以上の水道システムが組織的なサイバー攻撃を受ける
当局は、ミネソタ州の30以上の水道システムに影響した攻撃を調査しています。その中には、ある施設の運転制御を一時的に妨害したインシデントも含まれます。水質への大きな影響は報告されておらず、イランの関与の可能性が懸念されているものの、攻撃者の特定には至っていません。これらのインシデントは、インターネットに接続された制御技術（OT）を持つ小規模な公益事業者がさらされている状況を浮き彫りにしています。不要な外部アクセスを取り除き、検証済みの手動運転を維持することが、引き続き欠かせない防御策です。
ミネソタ州の水道システム：外部からの攻撃が30以上の水道システムに到達し、1件の制御妨害を引き起こすが、手動運転は引き続き可能。
🔎 ディープダイブ：
エンタープライズのセキュリティスキャンの背後にある組織的な課題
セキュリティチームがモバイルアプリケーションをスキャンしたいとします。
書類の上では、モバイルアプリケーションのスキャンはシンプルです。
アプリケーションを入手する
必要なアクセスを用意する
スキャンを開始する
検出結果を修復する
小規模な組織なら、本当にそれだけで済むこともあります。スキャンを依頼した人は通常、適切な担当者に連絡を取り、必要なものを入手し、テストを完了し、修正できる人に検出結果を渡せます。
そのため、セキュリティテストのスケールとは、同じプロセスをより多くのアプリケーションで繰り返すことだと考えがちです。
しかし大企業では、その前提が崩れます。
企業は、異なる環境とリリースサイクルにまたがる何百ものアプリケーションをテストします。アプリケーションごとに、次のような独自の要件があることがあります。
IDチームからのテスト用認証情報
ネットワークチームからのVPNアクセス
インフラチームまたはセキュリティチームによるIPの許可リスト登録
WAFの設定変更
シールディングなどのモバイル保護への対応
スキャンの実行と検出結果の修復に必要なものは、複数のチームに分散していることがよくあります。セキュリティチームは、スキャンを進める前に、各チームの適切な担当者を見つけて協力しなければなりません。脆弱性が見つかれば、責任を持つチームが再び関与し、レビューと修正を行う必要があります。
4つのシンプルなステップに見えたものが、すぐに調整の課題になります。
そこで本当の問いはこうです。
すべてのスキャンが複数のチームに依存しているとき、セキュリティテストをどうスケールさせるのか？
エンタープライズ環境に合わせて機能するテクノロジー
自動化は明らかな答えに思えます。スキャンを自動で実行できれば、セキュリティテストはスケールさせやすくなるはずです。
しかし、スキャンのたびに複数のチームが下準備をしなければならない場合や、検出結果のたびに理解、割り当て、検証のための手作業が増える場合、テストは本当の意味でスケーラブルとは言えません。
それでも誰かが、認証情報を用意し、ネットワークアクセスを開放し、IPを許可リストに登録し、WAFのルールを変更し、あるいはアプリケーションのシールディングを解除する必要があるかもしれません。スキャナーは自動化されていても、その周りのプロセスは自動化されていないのです。
スキャンの後も、アプリケーションチームが検出結果を修復するには、明確なエビデンス、コンテキスト、ガイダンスが必要です。
アプリケーションによっては、テクノロジーは認証付きのテストに対応し、プライベートな環境に接続し、ネットワークの制約の中で動作し、あるいはアプリケーションのシールディングや改ざん防止制御などの保護を回避する必要があるかもしれません。
検出結果が出たら、エビデンスと修復ガイダンスを提供して対応しやすくし、修正が適用されたら再テストを支援すべきです。
一定のアクセスや人間による判断は、引き続き必要かもしれません。しかしテクノロジーは、スキャンと修復のサイクルのたびに他のチームに同じ作業を生まないよう、エンタープライズ環境に適応すべきです。
組織的な依存関係を減らす
より優れたテクノロジーは、スキャンのたびに他のチームに求められる作業を減らせます。しかし、その関与を完全になくすことはできません。
大企業では、こうした依存関係はチーム間の力学によっても左右されます。各チームにはそれぞれの優先事項、期限、承認プロセスがあります。セキュリティチームにとって緊急の依頼が、他のチームでも同じように緊急に扱われるとは限りません。
プロセスが個人的な関係や度重なるエスカレーションに頼っていると、進捗は、誰が誰を知っているか、誰なら依頼を前に進められるかに左右されかねません。
スケーラブルなワークフローは、次のことを満たすべきです。
アプリケーションごとに、誰がアクセスと承認を提供するのかを明確にする
スキャンの前と最中に、依頼を処理しエスカレーションするための一貫したプロセスをつくる
検出結果を、修正の責任を持つチームに振り分ける
明確なエビデンスと修復ガイダンスを提供する
手作業での度重なるフォローアップなしに進捗を追跡する
各チームは自らの責任を引き続き担いますが、プロセスはもはや個人的な関係にも、セキュリティチームがスキャンのたびに同じ調整プロセスを組み立て直すことにも依存しません。
スケーラブルなセキュリティテストへの道
セキュリティテストのスケールとは、チームから責任を取り上げることではありません。
チーム間の不要な摩擦を取り除くことです。
そのためには、エンタープライズ環境にあるアクセス制御や保護と連携して機能できるテクノロジーと、テスト、修復、検証の責任を明確かつ再現可能にするワークフローが必要です。
1回のスキャンを実行してその検出結果を修正するだけなら、対応できるかもしれません。スケールの本当の試金石は、同じプロセスが、毎回作り直すことなく次の100のアプリケーションでも機能するかどうかです。
🎣 これはフィッシング？
TeamsでIT Helpdeskから次のメッセージが届きました。次にどうしますか。
🔬 技術研究
GoPhishの作成用エンドポイントがリソースの所有権を移転し得た仕組み
GoPhishは、セキュリティチームがフィッシングのシミュレーションを実施するために使うオープンソースのプラットフォームです。受信者グループ、メールテンプレート、ランディングページ、送信プロファイル、キャンペーンの結果を管理します。
当社が2026年7月に実施したソースコード評価でレビューしたバージョンのGoPhishでは、一部の作成用エンドポイントが既存のリソースを更新し、その所有権を別のユーザーに移転できました。
この問題は、明らかな認可チェックの欠如が1つあったことで生じたものではありません。一見普通の3つの挙動が組み合わさったときに現れました。
エンドポイントがリクエストからidを受け取った
サーバーが現在のユーザーを所有者として割り当てた
データベース操作が、既存のidを更新として扱った
リソースの乗っ取りはどのように機能したか
該当するコードは次のパターンに従っていました。
resource.UserId = currentUserID
db.Save(&resource)重要なのはSaveです。
リソースに既存のIDがない場合、データベースは新しいレコードを作成します。しかし、リクエストにすでに存在するIDが含まれていると、同じ操作がそのレコードを更新してしまうことがあります。
互いのリソースにアクセスできてはならない2人のGoPhishユーザーを考えてみましょう。
ユーザーAが受信者グループを作成します。次にユーザーBが、ユーザーAのグループのIDを含む作成リクエストを送ります。
アプリケーションはユーザーBを所有者として割り当て、オブジェクトを保存します。そのIDはすでに存在するため、データベースは新しいレコードを作成するのではなく、元のレコードを更新します。
リクエストは作成のように見えました。結果は所有権の移転でした。
このパターンは、受信者グループ、メールテンプレート、ランディングページ、SMTPプロファイルに影響しました。グループの場合、既存の受信者との関連付けが移転後も残ることがあり、新しい所有者がグループとその標的にアクセスできるようになりました。
その他のリソースタイプについて確認された影響は、権限のない乗っ取りと改変であり、必ずしも以前の内容へのアクセスではありません。
エンドポイントは「作成」と言っていますが、データベースは既存のIDを見て更新を実行します。
アクセスチェックがこれを防げなかった理由
一部の読み取りと削除の操作は、すでにリソースのIDとその所有者の両方を確認していました。
そのため、アクセス制御のモデルは安全に見えることがあります。ユーザーは自分のリソースしか取得も削除もできない、と。
しかし認可は、リソースがどのように作成・更新されるかも守らなければなりません。
書き込みの経路が既存のIDを受け入れ、保存前に所有者を置き換えてしまうなら、読み取りと削除の操作に適用された保護を迂回できます。攻撃者は他人のリソースを直接取得するわけではありません。まずアプリケーションに、それを自分のものとして扱わせるのです。
だからこそ、これを安全でないオブジェクト直接参照（IDOR）としてだけ説明すると、問題の一部を見逃すことになります。より根本的な問題は、アプリケーションが作成と変更を明確に分けていなかったことです。
この問題はどのように発見されたか
この検出結果は、コントローラーだけを見てもわかりませんでした。
レビューでは、リクエストを複数の層にわたって追跡する必要がありました。
POST request
↓
Client-controlled resource ID
↓
Current user assigned as owner
↓
Database Save operation
↓
Existing record updated Agentic Deep Scanはリポジトリ全体にわたってこのパターンを特定するのに役立ちましたが、結果が採用されたのは、経路全体を手動でレビューし、2人の合成ユーザーを使ってローカルで再現した後でした。
この区別が重要です。疑わしいデータベース呼び出しが、自動的に脆弱性になるわけではありません。本当の問いは、ユーザーが制御するデータが、セキュリティ境界を越える条件のもとでそこに到達できるかどうかです。
防止するには
作成操作と更新操作には、異なるルールが必要です。
作成リクエストでリソースIDや所有権のフィールドを受け付けない
リソースを作成するときは、明示的な挿入操作を使う
更新するときは、リソースIDと現在の所有者の両方を必須にする
作成、セルフサービスでの更新、管理者による変更で、リクエストの構造を分ける
すべてのリソースタイプを、2人の異なるユーザーでテストする
有用な回帰テストはシンプルです。
ユーザーAがリソースを作成する
ユーザーBが、ユーザーAのリソースIDを含む作成リクエストを送信する
アプリケーションはそのリクエストを拒否しなければならない
元の所有者、内容、関連するレコードは変更されないままでなければならない
セキュリティチームが学べること
フレームワークやORMのヘルパーは、Saveのような便利な関数の裏に、重要なセキュリティ上の判断を隠してしまうことがあります。
ルートの名前は「create」かもしれません。APIドキュメントでも「create」と説明されているかもしれません。しかし、実際に何が起きるかを決めるのはデータベースです。
アクセス制御をレビューするときは、ユーザーが他人のレコードを読み取ったり削除したりできるかどうかだけを問わないでください。
作成の経路が黙って更新の経路に変わり得ないか、そしてその更新でデータの所有者を変えられないかも問うべきです。
バージョンに関する注記：この研究は、2026年7月にレビューしたGoPhishのソースと設定について記述したものです。現在のバージョンについての記述ではなく、その時点の評価のスナップショットとして扱ってください。
🛠️ 今週のツール
PCAPdroid
Androidアプリのネットワークトラフィックを調べるには、root化した端末か、複雑なテスト環境が必要です。
いつもそうとは限りません。
PCAPdroidを使えば、セキュリティチームはroot化せずにAndroid上で直接そのトラフィックをキャプチャできます。ユーザーやセキュリティチームが画面上では見られない接続を明らかにするのに役立ちます。
PCAPdroidの仕組み
PCAPdroidはローカルVPNを使い、トラフィックを端末内にとどめたまま観測します。アナリストは端末全体を監視することも、1つのアプリケーションに絞ることもできます。
キャプチャを開始すると、PCAPdroidはアプリがどのサーバーに接続しているか、いつ接続が発生するか、どれだけのデータがやり取りされているかを表示します。これにより、未知のサービス、古いサーバー、バックグラウンドの接続を見つけやすくなります。
キャプチャはWiresharkで開いて詳しく調べることもできます。追加の設定を行えば、PCAPdroidは暗号化されたトラフィックの内容を表示できる場合もありますが、すべてのアプリで機能するわけではありません。
簡単な例
ある企業が、自社のAndroidアプリに新しい分析ツールを追加したとします。
アップデートをリリースする前に、アナリストがPCAPdroidでそのアプリを選択し、キャプチャを開始します。サインインし、さまざまな画面を開いてから、アプリを放置します。
ほとんどの接続は、自社のAPIと想定どおりの分析サービスに向かっています。ところが、サインイン後に別のドメインが現れ、アプリがバックグラウンドにある間もトラフィックを受け取り続けています。
その接続は正当なものかもしれません。しかしチームは、その存在、始まるタイミング、調査すべき場所を把握できるようになりました。
代わりにならないもの
PCAPdroidが示すのはネットワーク上の活動だけです。安全でないストレージ、脆弱な認証など、トラフィックに現れない問題は見つけられません。
キャプチャには機微な情報が含まれることもあるため、許可されたテスト用端末で作成し、慎重に扱う必要があります。
👏 今週の人物
Emanuele Faranda
今週は、Emanuele Farandaを紹介します。PCAPdroidを開発した独立系開発者です。
Androidアプリのネットワークトラフィックをキャプチャするには、root化した端末や複雑なテスト環境が必要になることがよくあります。Emanueleはこのプロセスを簡単にするためにPCAPdroidを開発し、root化せずにAndroid上で直接アプリの接続を監視できるようにしました。
このプロジェクトは、セキュリティ研究者、開発者、プライバシーを重視するユーザーが、アプリがどのサーバーと通信しているかを確認し、トラフィックを調べ、キャプチャをエクスポートしてWiresharkでさらに分析するのに役立っています。
彼の仕事には、TLSトラフィックの復号を追加するPCAPdroid-mitmや、PCAPdroidのroot不要のキャプチャを支えるネットワークコンポーネントのzdtunもあります。
Androidのトラフィック解析をより身近なものにし、これらのツールをオープンソースプロジェクトとして保守し続けている功績により、Emanuele Farandaを今週の人物に選びました。
📅 今週のイベント
next.app devCon 2026
仕事がモバイル開発とアプリケーションセキュリティの間にあるなら、next.app devConは予定に入れておく価値があります。
このイベントは8つの開発者カンファレンスを1つにまとめたもので、droidCon、flutterCon、swiftCon、reactCon、そしてモバイルアプリケーションセキュリティ専門のカンファレンスであるmasConが含まれます。
3日間にわたり、Android、iOS、クロスプラットフォーム開発、エージェント型コーディング、エンジニアリングリーダーシップ、そしてモバイルセキュリティに関する技術講演とワークショップが行われます。
AppSecチームにとって、この組み合わせは有益です。masConはモバイルアプリケーションの保護に焦点を当て、他のカンファレンスでは、それらのアプリケーションがどのように作られているか、開発者がどのツールやフレームワークを採用しているかがわかります。
📍 CityCube Berlin、ドイツ
📅 2026年10月7〜9日
📚 今週の本
Practical Reverse Engineering
著：Bruce Dang、Alexandre Gazet、Elias Bachaalany、Sébastien Josse
ソースコードが見えないとき、ソフトウェアが何をしているのかをどう理解すればよいのでしょうか。
『Practical Reverse Engineering』は、アナリストがx86、x64、ARMにまたがってコンパイル済みのソフトウェアをどう調べるかを解説しています。Windowsカーネル、ドライバー、デバッグ、コードの難読化、解析に使われるツールも扱っています。
実践的なウォークスルーと演習を通じて、マルウェアの調査、ソフトウェアの保護の理解、なじみのないプログラムの検証に必要な低レイヤーの知識を身につけられます。
リバースエンジニアリングツールを実行するだけでなく、その下で何が起きているかを理解したいセキュリティ研究者やエンジニアにとって有益な一冊です。
😅 今週のミーム
自社のセキュリティテストのプロセスが、スキャンの前後に複数のチームに依存しているとしたら、自動化で簡素化できるのが作業の一部だけの場合、どうやってスケールさせますか。
The Breach Brief、Ostorlabチーム