Ostorlabと手動ペンテストの比較：より多くのクリティカルな検出結果、より短い時間、より低いコスト

Ostorlabは、テスターがアプリケーションの挙動を調査し、攻撃仮説を立て、テストを実行し、影響を検証する必要のあるペネトレーションテスト（ペンテスト）の作業を自動化します。手動ペンテストを購入するアプリケーションセキュリティ（AppSec）チームにとっての比較の焦点は、同じスコープでOstorlabがより多くのクリティカルな脆弱性を見つけ、結果をより早く提供し、評価コストを削減できるかです。

当社チームの報告では、完了したすべての直接比較の概念実証（PoC）において、Ostorlabは並行して実施した手動ペンテストより多くのクリティカルな脆弱性を発見し、より早くテストを完了し、コストは10分の1から40分の1でした。 完了した比較には、モバイルアプリ、Webアプリ、ソースコード、Active Directoryのテストが含まれます。

Ostorlabと手動ペンテスト：報告されたPoCの結果

これらは、評価したスコープとアクセス条件における当社チームの案件結果です。独立したベンチマークでも、別のアプリケーションに対する保証でもありません。本記事では、比較対象の件数、対応付けた検出結果の数、評価期間、項目別のコスト内訳を公開していません。そのため、報告されたコスト範囲は自社の総削減額の予測ではありません。自社のスコープで比較する際は、セットアップ、人間によるレビュー、再テスト、エンジニアリング工数を含める必要があります。

技術事例では、Ostorlabの結果を支える調査と検証の作業を説明します。あるモバイル評価では、エージェントがFlutterのiOSバイナリから認証情報を抽出し、許可されたAPIオーディエンスをテストして、ID管理APIへのアクセスを実証しました。企業向けアプリケーションの評価では、クライアントシークレットなしで管理用トークンを取得し、それを使って、提供されたサーバー側コードを実行する機能に到達しました。いずれも、顧客がペンテスターに依頼する調査作業の例です。

比較を支える技術的エビデンス

以下の匿名化された例は、Ostorlabの検出結果の記録と実行履歴に基づきます。プラットフォームが何を調査し、何を確認したかを示します。特定の人間のテスターが見逃した検出結果を特定するものでも、集計した比較結果を独立して裏付けるものでもありません。顧客単位のスコアカードや監査者のレポートは、本記事では公開していません。

モバイル認証情報の事例と、シークレット不要のトークンからサーバー実行に至るチェーンを事例1〜3で詳しく説明します。追加の技術的エビデンスでは、登録、署名、ログを取り上げます。内部テストを検討する読者向けに、別のADラボの例も掲載していますが、これは顧客比較のエビデンスではありません。コード抜粋には合成値を使い、記録された顧客の通信を再現するのではなく、報告された仕組みを説明します。

相談の前に成果物を確認するには、Webのサンプルレポートまたはモバイルのサンプルレポートをご覧ください。

事例1：漏えいしたモバイル認証情報がテナント管理APIに到達

Ostorlabは、Auth0のマシン間認証情報を使ってAPIアクセストークンを取得する、Flutter製のiOSアプリを評価しました。コンパイル済みバイナリには、FlutterのDART_DEFINES機構を通じてビルド時に渡されたclient_idとclient_secretが含まれていました。評価では、これらの認証情報が有効か、どのAPIにアクセスできるかをテストしました。

期待される境界 ：マシン間認証情報は、そのサービスに必要な一つのオーディエンスと操作群にスコープを限定すべきです。配布するクライアントに埋め込まれた認証情報は秘密ではなく、ビルドを入手できる誰もが取得できます。そのため、認証情報が現在も有効か、ほかの何に対して認証できるかの両方を調べました。

調査 ：エージェントはMach-Oバイナリから認証情報を抽出し、テナントの/oauth/tokenエンドポイントにトークンを要求しました。リクエストはHTTP 200で成功し、署名付きJWTが返りました。一方、偽の認証情報ではHTTP 401が返りました。トークンにはread:TSCスコープとクライアントクレデンシャルグラントが含まれ、その署名鍵はテナントのJWKSエンドポイントまで追跡できました。

最初の検出結果の重大度は「高」でした。記録には「修正・検証済み」とも記載されていますが、本事例で利用できる資料には修正や再テストの時系列が記録されていません。このラベルだけでは、認証情報がローテーションされたことや、アクセス権が削除されたことは確認できません。

アプリが使用するAPIを超えたアクセスを評価するため、Ostorlabは同じトークンエンドポイントに対して38個の候補オーディエンス向けのトークン要求を送信しました。この要求のオーディエンスは、アクセスを要求するAPIを指定します。テナントのManagement APIオーディエンス向けの要求ではHTTP 200が返り、update:users、delete:users、create:users、create:client_credentialsを含む8つのスコープを持つトークンが発行されました。Management APIへの1回の非破壊的なGETで、メールアドレス、電話番号、最終IP、ログインの挙動を含む1,000件のユーザーディレクトリの最初のページが返りました。評価ではこの読み取りを実証しましたが、トークンのユーザー作成、更新、削除の権限は使用していません。

トークンエンドポイントは、内部サービスとManagement APIの両オーディエンスで、抽出されたクライアント認証情報を受け入れました。その後のディレクトリへのリクエストで、Management API経由の読み取りアクセスを確認しました。

説明用HTTPシーケンス：ホスト、クライアント、トークンの値は合成値です。

# The credential is extracted from the mobile binary.
POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=AUDIENCE_A
# Article outcome: a read:TSC token for the internal service.

POST /oauth/token HTTP/1.1
Host: tenant.example.invalid
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=MOBILE_CLIENT&client_secret=EXTRACTED_SECRET&audience=MANAGEMENT_API
# Article outcome: a token with eight management scopes.

GET /api/v2/users?per_page=100 HTTP/1.1
Host: tenant.example.invalid
Authorization: Bearer FAKE_MANAGEMENT_TOKEN

# Article outcome: the first page of a 1,000-record directory.

評価結果 ：抽出した認証情報で、内部サービスとManagement APIのトークンを取得できました。ディレクトリの読み取りで個人情報へのアクセスを確認しましたが、管理用の書き込み権限は未テストです。そのため、修復の検証はアプリが呼び出すAPIだけでなく、クライアントに許可されたオーディエンス全体を対象にする必要があります。利用可能な記録には、2つの検出結果の間でどの修正が試みられたかは記載されていません。

Ostorlabが自動化した作業 ：この評価では、バイナリ解析、有効な認証情報の検証、オーディエンスの列挙、制御されたAPI読み取りを組み合わせました。手動で調査するテスターも、同じ手順を実行してつなぎ合わせる必要があります。Ostorlabは、アプリが呼び出すAPIを超えて認証情報で利用できるアクセスを確認し、AppSecチームに優先順位付けできる検証済みの露出と、より広い再テストの要件を示しました。

修復の方向性 ：クライアントからシークレットを削除し、ローテーションします。クライアントに許可されたオーディエンスとスコープを見直し、テナント管理用の認証情報とクライアント向けサービスの認証情報を分離します。脆弱な構成で発行されたトークンを無効化します。再テストでは、アプリが呼び出すオーディエンスだけでなく、クライアントの認可範囲全体を列挙する必要があります。

この事例の詳しい解説は、Agentic Deep Scanのケーススタディをご覧ください。

事例2：シークレット不要のトークン要求から管理アクセスへ

企業向けアプリケーションの評価で、Ostorlabはクライアントシークレットなしで管理用トークンを発行するIDサービスの構成を発見しました。調査では、そのトークンが使用可能であることを確認しました。保護されたディレクトリ操作がトークンを受け入れ、数百件の組織プロファイルを返しました。返された有効期限の情報から、トークンが短いセッションを大幅に超えて有効であり続ける可能性があり、アクセスの持続リスクが高まることが分かりました。

期待される境界 ：管理アクセスを要求するクライアントは、そのアクセスに必要なIDと権限を証明する必要があります。発行するトークンのオーディエンス、スコープ、有効期間も適切に制限すべきです。発行と利用は別々のセキュリティ判断であるため、テストでは両方を調べました。

調査 ：OstorlabはクライアントIDと管理用スコープを使い、クライアントシークレットなしでトークン要求を送信しました。IDサービスはBearerトークンを返しました。Ostorlabは返されたトークンのクレームを調べ、保護されたディレクトリ操作に使用し、組織プロファイルを取得しました。

発行と受け入れは別のチェックです。評価では、シークレット不要のトークン要求が、保護されたディレクトリ操作に受け入れられる認証情報を生成することを実証し、両方を確認しました。

説明用HTTPシーケンス：ルート、フィールド値、トークンのプレースホルダーは合成値です。

# Request shape is illustrative; the article omits routes and exact fields.
POST /example/token HTTP/1.1
Host: identity.example.invalid
Content-Type: application/x-www-form-urlencoded

client_id=DEMO_CLIENT&scope=DEMO_ADMIN_SCOPE
# No client_secret and no client-authentication header.
# Article outcome: an administrative bearer token was issued.

GET /example/protected-directory HTTP/1.1
Host: directory.example.invalid
Authorization: Bearer FAKE_ISSUED_TOKEN

# Article outcome: protected access returned organizational profiles.
# Synthetic request shape; this is not a literal captured exchange.

評価結果 ：クライアントシークレットなしでのトークン発行と、保護されたディレクトリ操作によるそのトークンの受け入れを実証しました。ディレクトリ要求には、提供された管理者認証情報ではなく、テストした発行経路で取得したトークンを使用しました。これにより、IDサービスの構成ミスと不正なAPIアクセスのつながりが確認されました。

修復の方向性 ：クライアントの認証要件と許可されたグラント種別を見直し、スコープとオーディエンスを制限し、目的に合うよう有効期間を短縮します。また、脆弱な構成で発行された認証情報を適切に無効化します。再テストでは、新たな発行の試行と、すでに発行された認証情報の扱いの両方を確認する必要があります。

修復の再テストでは、トークンエンドポイントでのクライアント認証と、保護されたAPIでの認可という両方の制御を検証する必要があります。

事例3：連携機能が提供されたサーバーコードを実行

同じ企業向けアプリケーションの評価で、Ostorlabは事例2の管理用トークンを使い、ベンダー提供のIAMモジュールにある認証が必要な連携機能に到達しました。この機能はカスタムC#を受け入れ、アプリケーションサーバープロセス内でコンパイルしました。制御された時間計測テスト、サブプロセス実行、ホスト診断、外向きネットワークチェックにより、アプリケーションのIISアプリケーションプールの実行IDでの実行を実証しました。このアカウントはBUILTIN\Administratorsのメンバーであり、SeDebugPrivilegeとSeImpersonatePrivilegeを保持していました。

期待される境界 ：拡張機能には、誰が実行可能なコードを提供できるか、どこで実行されるか、どの権限を与えるかという明確な信頼モデルが必要です。連携設定画面へのアクセスだけでは、特権アプリケーションプロセス内で提供コードを実行する際の適切な信頼境界にはなりません。

調査 ：エージェントは機能が想定するインターフェースに従って調査しました。そのインターフェースを実装したプローブを書き、ペイロードがコンパイルと型チェックを通過してからコンストラクターが実行されるようにしました。アプリケーションはRoslynでソースをプロセス内コンパイルし、生成されたアセンブリをAssemblyLoadContext.Default.LoadFromStream()で読み込み、Activator.CreateInstance()でインスタンスを生成していました。

通常のリクエストでベースラインを確立しました。コンストラクターペイロードには制御された遅延を入れました。記録された応答時間は指定した段階に従い、ベースラインの約122 msに対して、2秒、5秒、10秒のプローブではそれぞれ約2.13 s、5.14 s、10.15 sでした。繰り返したプローブも同じパターンを示しました。追加テストでは、サブプロセスの実行、コードを実行するID、テスターが管理するホストへの外向きDNSおよびTCP接続を記録しました。

連携機能は、提供されたC#をサーバープロセス内でコンパイルし、インスタンス化しました。段階的に指定した遅延はコンストラクター実行を裏付け、別のサブプロセステスト、ホスト診断、外向き通信チェックが追加の影響を確認しました。

説明用C#プローブ：許可されたテスト環境の連携インターフェースに合わせて調整してください。

using System;
using System.Threading;

public sealed class IntegrationProbe
{
    // Implements the interface the integration feature expects.
    public IntegrationProbe()
    {
        Thread.Sleep(2000);
        Console.WriteLine(Environment.UserName);
    }
}

// Compare baseline with 2, 5, and 10 second constructor delays.
// This snippet illustrates timing and identity diagnostics only.
// The article reports subprocess execution and egress from separate tests.

陰性対照 ：エージェントは、インスタンス化前の型チェックを強制する、同系統の別の連携エンドポイントもテストしました。同じプローブはコンパイルまたはインスタンス化の前に拒否され、応答時間への影響もありませんでした。この対照テストにより、2つの連携エンドポイントが提供コードの実行前に異なる検証を適用していることが分かりました。

評価結果 ：時間計測テストはコンストラクター実行を実証しました。別途行ったサブプロセス、ID、外向き通信のテストは、実行権限とネットワークアクセスを確認しました。連携エンドポイントには認証が必要で、事例2で取得したトークンがその認証に使われました。実証された流れは、シークレット不要のトークン発行、管理APIアクセス、認証を経たサーバー側コード実行です。

修復の方向性 ：信頼できない連携を特権アプリケーションプロセスの外に置きます。

• OSが強制する適切なセキュリティ境界を持つ別のワーカーを使います。回収可能なAssemblyLoadContextはアセンブリのアンロードを支援しますが、セキュリティサンドボックスではありません。Microsoftは、読み込みの分離とプロセスのセキュリティ境界の違いを説明しています。
• ワーカーに低権限のID、制限されたシークレットアクセス、外向き通信の許可リストを設定
• 連携を作成または変更できる主体を制限
• 認可、プロセスの実行ID、保護リソースへのアクセス、禁止された外向き通信を再テストします。連携の実行が意図された機能なら、コンパイルの成功だけでは修正の失敗を意味しません。

Ostorlabが自動化した作業 ：事例2と3では、エージェントは一つの検出結果で得た認証情報を別のテストに引き継ぎ、連携インターフェースに適合するプローブを作り、時間計測の結果を比較し、プロセスの権限とネットワークアクセスを確認する必要がありました。これは評価内での攻撃チェーン調査と影響検証です。手動ペンテストとの比較では、どちらの提供者が完全な経路を発見し実証したかと、それに要した時間とコストを評価する必要があります。

手動ペンテストと並行してOstorlabを実行

Ostorlabと手動ペンテストの提供者に、同等の対象、アカウント、アクセス、許可された操作を与えます。これにより、同じ条件で調査と検証済みの検出結果を比較できます。可能であれば、代表的なステージング環境と専用のテストアカウントから始めます。本番環境でのテストが必要な場合は、実行前にアプリケーション所有者と、許可する操作、データアクセス、トラフィック制限、インシデントのエスカレーションについて合意します。アプリで接続先が見つかっても、そのIDプロバイダーや分析サービスのテストが自動的に許可されるわけではありません。

評価のスコープを決める際には、次の運用計画を使用します。

これらは評価チームと確認する案件ごとの決定事項です。すべての操作が自動的に承認されたり、元に戻されたりするという約束ではありません。

スコープと操作の制御

10月のプラットフォーム更新では、スコープのガイダンス、ファイアウォールの除外対象、トラフィック制御、監視、要求された操作の承認を説明しています。スコープの許可リストはエージェントを誘導しますが、厳密なネットワーク境界ではありません。ファイアウォールの除外設定は、指定したアドレスとネットワークをブロックします。監視では、スコープからの逸脱検知と任意のシャットダウンを追加できます。

承認設定は、エージェントが判断を求めた操作を制御します。「確認する、返答がなければブロック」は、要求された操作を判断待ちにしますが、すべてのツール呼び出し前に人間のレビューを求めるものではありません。運用担当者は案件に合わせてこれらの設定を構成する必要があります。

実行枠と停止条件

実行枠には曜日、時間、タイムゾーンを指定します。枠外で作成されたスキャンは待機し、一時停止可能なスキャンは終了時刻に一時停止して、次の枠で再開します。一時停止できないスキャンは終了時刻を過ぎても完了まで続きます。終了時刻を運用上の停止期限とみなす前に、選択したスキャン種別の動作を確認してください。繰り返しスケジュールには、別途、最終停止条件も必要です。

対応するスケジュール動作は、実行枠のドキュメントを参照してください。これらのスクリーンショットは公開ドキュメントに掲載されたプラットフォームの例であり、匿名化された評価で取得したエビデンスではありません。

調査のエビデンスと引き継ぎを比較

検出結果の件数は、チームがその内容を検証できる場合にのみ有用です。手動評価の提供者が示す裏付けとOstorlabの調査記録を、それぞれが悪用可能性と影響をどう確認したかも含めて比較します。OstorlabのAI Pentest分析ビューは、計画とタスクを、記録されたツール名、引数、出力、タイムスタンプに結び付けます。重要な検出結果について、最初の仮説から影響を確認するレスポンスまで調べてください。レポートでは、ソースの追跡、成功した実行時テスト、阻止された攻撃段階を区別できる必要があります。

引き継ぎでは、開始時の権限、再現した影響、成功しなかった分岐、未実施のチェック、修正案を明示すべきです。根本原因や攻撃チェーンの重複を整理したうえで、独立した検証済みの検出結果を数えます。未テストの仮説を、確定したクリティカルな脆弱性として数えてはいけません。

実行記録は、運用担当者によるクリーンアップの検証にも役立ちます。確認したあるWeb評価では、サポートセッションを作成し、確認し、失効させ、再確認してログアウトを確かめたことが記録されていました。変更した構成、アップロードしたファイル、発行した認証情報にも同じ厳密さを適用します。未解決の残存物を明示的に記録し、責任者を割り当ててください。操作の記録は、その操作を元に戻すこととは異なります。

修復まで比較の対象を広げる

比較には、検出結果を検証済みの修正につなげるための作業も含めるべきです。Ostorlabは、個別の修正推奨と、対応するリポジトリ連携を通じて提供するコード変更案により、検出結果を修復へ進められます。開発者は既存のプルリクエストのワークフローで差分をレビューし、必要なチェックを実行して、追加テストで変更後のアプリケーションが元の問題を解決したかを評価します。

修正案は、評価で特定した制御に対処する必要があります。登録の検出結果にはレコードの所有権チェックが、認証情報を含むログにはログ記録とシリアライズの呼び出し箇所の変更が、シークレット不要のトークンにはトークン発行と後段の認可の見直しが必要です。

次の表は、各事例から導いた修復と再テストの基準です。特定のパッチが作成済みまたはマージ済みであると主張するものではありません。

• Ostorlab Autofixは、個別の修正推奨、プルリクエストを通じた変更、追加の検証ワークフローに対応しています。
• ソースコードテストは、影響を受ける経路とコードの変更履歴を修復に結び付けます。

生成されたパッチも、エンジニアリングのレビューと適切なテストを経ます。クローズの判断には追加評価のエビデンスを使います。差分の提案やビルドの成功だけでは、悪用可能な経路の除去は確認できません。

このワークフローを、手動ペンテストに含まれる修復と再テストのサービスと比較してください。開発者が検出結果を再現し、修正案を実装し、元のアクセス経路や実行経路が阻止されたことを検証できるかを、チームに必要な工数とともに記録します。

自社の手動ペンテスト提供者とOstorlabを測定・比較

報告されたPoC結果、すなわち検証済みのクリティカルな検出結果の増加、テスト時間の短縮、評価コストの削減を、検証すべき命題として使います。有用な比較は、同じビルド、対象、アカウント、ソースアクセス、権限、除外対象から始まります。評価期間に合意し、テスト中の変更の扱いを決めます。未完了の案件や制限を結果から外さずに記録してください。

PoCを承認する前に、含まれる作業、使用量の上限、超過時の条件、再テストの許容量、顧客が行う準備を示す項目別見積もりを求めます。スコープとアクセスを確認してから納品日に合意します。その条件と実際の工数を使い、当社の完了済みPoCで報告された評価コストの優位性が、自社チームの総コストの低減につながるかを判断してください。

既存のペンテストを置き換える前に確認する事項

Ostorlabは自社のテスト計画でどの役割を担うか？ 最初に並行評価を行い、認証済みワークフローのテスト、アプリとAPIをまたぐ調査、変更後の再テストなど、自社のスコープでどのアプリケーションテスト作業を引き継げるかを判断します。スコープ、ビジネス上の意図、異論のある検出結果、運用判断、修正の受け入れには引き続き人間が責任を持ちます。合意した対象外の活動には、専門家のテストを残します。検出結果、納品、コスト、保証の要件から、現在の手動評価のどの程度をOstorlabに置き換えられるか判断してください。

ソースコードの提供は必要か？ Ostorlabは、モバイルのビルド、Webアプリ、API、ソースコードのテストに対応しています。モバイル認証情報の事例は配布されたバイナリから始まり、署名とログの例ではソースアクセスを使用しました。評価方式を明確に合意してください。ソースだけのレビューでは実際のバックエンドの挙動は実証できず、実行時だけのテストでは、ソースを併用した評価とは可視性が異なります。

自社チームは何を準備する必要があるか？ ビルドまたは対象URL、許可されたサービス、ロール別のテストアカウント、代表的なテストデータ、関連するAPIやワークフローのドキュメントを提供します。ログイン後のフローについては、必要な多要素認証（MFA）やワンタイムパスワード（OTP）のテスト設定を評価チームと調整します。アプリケーション所有者、運用担当者、再現と再テストを担当するエンジニアリングの連絡先を指定します。スコープを決める際に準備工数を確認してください。

コード、認証情報、エビデンスはどこに渡るか？ セキュリティチームと調達チームで、Trust Centerとオンプレミススキャンの選択肢を確認します。機密資料を提供する前に、選んだ配備方式、モデルプロバイダー、データフロー、保持期間、アクセス制御を確認してください。すべての配備方式が同じ扱いであると想定してはいけません。

レポートは外部から求められる保証要件を満たすか？ 評価を求める相手とサンプルレポートを確認してください。既存の評価契約を変更する前に、必要なスコープ、手法、テスターの資格や独立性、人間によるレビュー、レポート、再テストのエビデンスを確認します。提案されるサービスに含まれる人間による検証と承認を、Ostorlabに明示してもらってください。技術的な検出結果だけで、すべての保証要件での受け入れが確定するわけではありません。

次回の手動ペンテストとOstorlabを比較

Ostorlabが報告する手動ペンテストに対する優位性は、より多くのクリティカルな検出結果、より短いテスト時間、より低い評価コストです。各事例は、APIをまたぐ認証情報の調査、IDと実行の弱点をつなぐ攻撃チェーン、記録されたテストによる影響検証など、プラットフォームが実施できる技術作業を示しています。自社アプリでの比較では、これらの能力が現在のペンテストの結果と費用対効果を改善するかを確認すべきです。

代表的なアプリケーション一つ、その接続先API、既存の手動ペンテストのスコープをご用意ください。スコープの相談で次の項目に合意します。

1. 入力 ：ビルドまたはURL、テストアカウントとロール、対象に含める場合のソースアクセス、ドキュメント、権限、除外対象
2. 成果物 ：再現された検出結果とエビデンスの限界を記載したレポート、調査記録へのアクセス、修復案、合意したクリーンアップと再テストの引き継ぎ
3. 成功基準 ：検証済みの検出結果と重複、利用可能な成果物の納品時間、総コスト、エンジニアリング工数。両提供者に同じ定義を適用
4. 確約事項 ：テスト開始前のスコープの文書化、運用計画、納品日、項目別見積もり、責任者の指定

Ostorlabと手動ペンテストの比較PoCを予約 し、自社アプリケーションに対する同等のスコープ、成功基準、取引条件に合意してください。先にエビデンスの形式を確認したい場合は、Webのサンプルレポートまたはモバイルのサンプルレポートからご覧ください。

追加の技術的エビデンス

以下では、登録の認可、モバイルの署名、モバイルのログ、別のActive Directoryラボ評価を記録します。各節でテスト方法、観察された結果、なお必要な検証を説明します。

登録の所有権：不正な読み取りと書き込み。有効化は阻止されたまま

セルフサービス登録の評価で、Ostorlabはレコードの取得からパスワードの作成に至るワークフローを追跡しました。匿名セッションが、別の主体に属するテスター管理のレコードを取得し、使用可能なCSRFトークンを得て、その登録に対するパスワード作成要求を送信できました。成功レスポンスと永続化されたレコードのバージョン変更が、不正な書き込みを記録していました。

期待される境界 ：ワークフローは、呼び出し元が変更対象の特定の登録に対して操作できることを確認する必要があります。CSRFトークンが答えるのは、リクエストが期待されるブラウザーセッションのトークンを持つかという別の問いです。トークンを持っていても、リクエストで指定されたレコードの所有権は証明されません。

調査 ：エージェントは、テスト用に作成したレコードに対して、匿名のゲストセッションを含む異なる主体の挙動を比較しました。他者の登録を取得し、セッションのCSRFハンドルを取得して、そのレコードを対象にパスワード作成要求を送信し、レコードを再度読み取って結果の状態を調べました。

CSRF検証とレコード認可は別々の問いに答えます。独自のCSRFトークンを持つゲストセッションが、他者のテスト登録を読み取り、変更できましたが、有効化とログインの段階は完了していません。

説明用HTTPシーケンス：両主体と登録はテスターの管理下にあります。

# Session A does not own test enrollment B.
GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Obtain FAKE_CSRF_A through the public enrollment flow.
POST /example/enrollments/TEST_RECORD_B/password HTTP/1.1
Cookie: guest=FAKE_SESSION_A
X-CSRF-Token: FAKE_CSRF_A
Content-Type: application/json

{"password":"SYNTHETIC_TEST_PASSWORD"}

GET /example/enrollments/TEST_RECORD_B HTTP/1.1
Cookie: guest=FAKE_SESSION_A

# Article: write accepted; record version changed on readback.
# Final activation and login did not complete.

手順	エビデンス	評価した境界
非所有者のセッションからテスト登録を読み取る	レコード取得の成功レスポンス	レコードの機密性と所有権チェック。
ゲストセッションのCSRFトークンを取得	公開フローを通じてトークンを取得可能	匿名の呼び出し元による有効なリクエストトークンの取得可能性。
他者のテストレコードに対してパスワード作成を送信	作成の成功レスポンス	状態変更操作の認可。
レコードを再度読み取る	永続化されたバージョン変更	初回レスポンスを超えて持続する影響。
最終的な有効化とログインを試行	この段階は未完了	実証された攻撃経路の限界。

エビデンスが実証する内容 ：評価では、主体をまたぐレコードアクセスと、テスト登録への認証情報の事前設定を確認しました。チェーンが停止した地点も記録しました。評価した配備環境では、最終的な有効化とログインの段階が阻止されたままだったため、本事例は有効なユーザーアカウントの乗っ取りが完了したとは主張していません。

修復の方向性 ：各登録操作を、認可された主体、または意図的に設計した狭いスコープの登録用ケイパビリティに結び付けます。読み取りと書き込みの両方で、その結び付きを確認します。レコード、呼び出し元、変更するIDフィールドの関係を検証します。回帰テストには、所有者、別の認証済みユーザー、匿名セッション、有効なCSRFトークンと誤ったレコードの組み合わせを含めるべきです。

登録の欠陥は認可の不備でした。アプリケーションは、有効なCSRFトークンを持つリクエストを受け入れる際に、そのセッションが指定レコードにアクセスまたは変更できるかを検証していませんでした。

モバイル署名：復元可能な鍵。バックエンドでの受け入れは未テスト

モバイルのソースコードPoCで、Ostorlabは2つの埋め込みバイト配列から再構成される、アプリケーション全体で共通のHMAC署名鍵を追跡しました。署名対象はタイムスタンプと固定のアプリケーションマーカーであり、メソッド、パス、リクエスト本文は署名入力に含まれていませんでした。これはソースレベルの検出結果であり、バックエンドが署名を受け入れることの実証には、引き続き実行時テストが必要でした。

期待される境界 ：リクエスト署名が証明できるのは、その鍵と署名メッセージが表す属性だけです。そのため、クライアントが鍵をどのように取得し、どのリクエスト要素が署名処理に含まれるのかを正確に調べました。

調査 ：エージェントは、再構成関数からAPIリクエストビルダーまで追跡しました。共有シークレットの復元に必要な両方の配列が、クライアントとともに配布されていました。API層は、その再構成された値を使ってタイムスタンプとアプリケーションマーカーに署名し、署名をリクエストヘッダーに設定していました。

配布されたクライアントには、共有鍵の再構成に必要な情報が含まれていました。追跡した署名はタイムスタンプと固定マーカーを対象にしていましたが、メソッド、パス、本文は署名入力に含まれていませんでした。バックエンドの挙動は未テストです。

説明用の疑似コード：再構成とHMACのヘルパーは、元の実装の代わりに使用しています。

// Both embedded arrays are distributed with the client.
const sharedKey = reconstructKey(embeddedArrayA, embeddedArrayB);

// Simplified representation of the traced signing inputs.
const signedInput = timestamp + APP_MARKER;
const signature = hmac(sharedKey, signedInput);

headers["X-Example-Signature"] = signature;

// request.method is absent from signedInput.
// request.path is absent from signedInput.
// request.body is absent from signedInput.
// The reconstruction algorithm and header name are illustrative.
// Backend acceptance was not established by the source review.

ソースの追跡	コードが裏付けるセキュリティ上の帰結
再構成用の両配列がクライアントに存在	難読化は共有鍵の復元を防いでいなかった。
リクエストビルダーが共有鍵を使用	追跡した呼び出し箇所で同じ署名用情報を再利用していた。
HMACにタイムスタンプと固定マーカーを入力	これらの値は署名対象だった。
メソッド、パス、本文が署名入力に不在	署名はこれらのリクエスト要素を結び付けていなかった。

エビデンスが実証する内容 ：レビューでは、復元可能な署名用情報と署名メッセージの構成を確認しました。Bearer認証や、バックエンドのすべての所有権チェックをバイパスできることは確認していません。バックエンドはこのソースアーカイブに含まれないため、その点は追加の実行時評価で検証すべき内容でした。

修復の方向性 ：すべてのクライアントのインストール先に配布するシークレットに置く信頼を見直します。署名のセキュリティ上の目的、署名が表すID、結び付けるリクエスト内容、サーバー側の鮮度チェックを明確にします。サーバーではユーザーとオブジェクトの認可を明示的に維持します。根本的な設計を修正しながら、適切な移行の一環として露出した署名用情報をローテーションします。

ソースのエビデンスは、鍵の再構成コードと署名対象フィールドを特定しています。バックエンドがどのように署名を検証するか、ほかの制御が不正なリクエストを防ぐかを判断するには、引き続き実行時テストが必要です。

モバイルのログ：マスキング漏れを再現。実際の送信は未検証

別のAndroid評価で、OstorlabはOpenIDの結果から、アプリケーションのログ記録、マスキング関数、テレメトリのシリアライズまで認証値を追跡しました。ローカルでの再現により、認識されないフィールド名や文字列形式では、認証情報形式の値がフィルターを通過して残ることが分かりました。記録では、漏えい経路と未実施の実行時チェックを特定しました。

期待される境界 ：認証情報は、ログに入る前に除外するか、安全に秘匿化すべきです。フィルターは、構造化フィールドと文字列表現を含め、アプリケーションが実際に使用するシリアライズに対応する必要があります。

調査 ：ソースには認証成功時の経路でのログ記録がありました。ある呼び出し箇所ではCookie値を含むヘッダーマップをシリアライズし、別の箇所では認証結果を文字列として記録していました。マスキング関数は、特定のJSONに似た形式で、定義されたフィールド群を認識していました。認証情報を含む文字列は、その名前または形式に該当しませんでした。

ローカルでの再現には陽性対照も含めました。認識される認可とリフレッシュトークンのフィールドはマスクされましたが、問題のCookieとコード形式の文字列は残りました。この違いにより、それ以外では機能しているマスキング機構の具体的な漏れを確認しました。

同じフィルターが、認識する認可とリフレッシュトークンのフィールドをマスクする一方で、Cookieマップと認証結果の文字列を見逃していました。ソースの追跡はテレメトリのシリアライズまで到達しましたが、実際の認証情報の送信とリプレイは観察していません。

ローカルで実行可能な例：合成認証情報と簡略化したマスキングルールを使用します。

const mask = text => text.replace(
  /("(?:authorization|refresh_token)"\s*:\s*")[^"]*"/gi,
  '$1[REDACTED]"'
);

const known = '{"authorization":"FAKE_BEARER"}';
const refresh = '{"refresh_token":"FAKE_REFRESH"}';
const cookie = '{Cookie=FAKE_COOKIE}';
const result = 'AuthResult(code=FAKE_AUTH_CODE)';

if (mask(known).includes("FAKE_BEARER")) throw Error("control");
if (mask(refresh).includes("FAKE_REFRESH")) throw Error("control");
if (!mask(cookie).includes("FAKE_COOKIE")) throw Error("gap");
if (!mask(result).includes("FAKE_AUTH_CODE")) throw Error("gap");

// The known fields are masked; the cookie and code survive.
// This reproduces the failure class, not the original filter.

Ostorlabはさらに、生成されたメッセージをログ用ソフトウェア開発キット（SDK）のシリアライズ経路まで追跡しました。実行時のトラフィックキャプチャと認証情報のリプレイは未実施のため、本記事は実際の認証情報の持ち出しを観察したことや、セッション乗っ取りが完了したことを示していません。

修復の方向性 ：可能な箇所では認証情報を含むログ文を削除し、構造化属性、シリアライズされたヘッダー、オブジェクトの文字列表現のすべてで一貫した秘匿化を行います。エラー時だけでなく、認証成功時の経路もテストします。回帰テストでは合成シークレットを使い、キューに入ったログイベントにも、その送信形式にもシークレットが含まれないことを確認します。

評価では、認証ログの呼び出し箇所、マスキングルールが対象外にしている形式、シリアライズ経路を特定しています。これらの箇所から、認証情報の秘匿化に必要なコード変更と回帰テストが定まります。

別のADラボ：ACLから証明書へのチェーンと未解決のクリーンアップ

Active Directoryのラボ評価で、エージェントは低権限のドメインユーザーから開始し、ディレクトリのアクセス制御範囲を列挙しました。ユーザー、グループ、コンピューター、ドメインルートにわたる3,002行のアクセス制御リスト（ACL）をレビューしました。その結果、一般ユーザーが認証局のサービスアカウントの所有権を取得できる、継承されていないWriteOwnerアクセス制御エントリ（ACE）を特定しました。これは、対象データ全体で、非Tier-0の主体にTier-0オブジェクトの制御を与える唯一のACEでした。

認証局（CA）のサービスアカウントはCert Publishersのメンバーで、証明書テンプレートに対するGenericAllを持ち、RC4によるKerberoastingが可能でした。

証明書テンプレートのGenericAll付与がESC4の条件でした。これによりエージェントは、別の主体として証明書を要求する前に、テンプレートのセキュリティ設定を変更できました。サービスアカウントのWriteOwnerACEは、そのテンプレート制御経路への別の侵入口でした。Cert Publishersへの所属とRC4によるKerberoastingの可能性は追加の露出であり、ESC4の段階の前提条件ではありませんでした。

期待される境界 ：CAのサービスアカウントとその証明書テンプレートはTier-0オブジェクトです。一般ユーザーが所有すべきではなく、テンプレートのACLはCAとディレクトリ管理者に制限し、すべての発行を記録して失効可能にすべきです。CAアカウントへのWriteOwnerACEは、通常の権限委任ではありません。

調査 ：エージェントはサービスアカウントの所有権を奪い、随意アクセス制御リスト（DACL）を書き換えて自身にGenericAllを与え、アカウントを制御しました。テンプレートを変更して登録を許可し、管理者として証明書を要求して、その証明書で認証し、krbtgtを複製しました。その後、ゴールデンチケットを偽造しました。誤って発行された管理者証明書は失効されないままでした。

継承されていない一つのACEが、一般ユーザーにCAサービスアカウントの所有権を与えていました。エージェントはその所有権からESC4テンプレートを経由し、証明書とドメイン複製につながるチェーンを構築しました。

説明用の実行疑似コード：名前は合成値で、実際のツール構文ではありません。

# Lab: ordinary user -> CA service account -> template -> certificate -> DCSync.
# Names and values are synthetic.

ace = read_ace(target="svc-ca", trustee="user-a")
# One non-inherited WriteOwner ACE in 3,002 ACL rows.

seize_owner(target="svc-ca", as="user-a")
grant_generic_all(target="svc-ca", to="user-a")
reset_secret(target="svc-ca")

template = modify_template("CorpAuthTemplate", enroll="svc-ca")
cert = request_certificate(template, subject="Administrator")
session = authenticate_with(cert)
replicate_krbtgt(session)
forge_golden_ticket()

# The misissued administrator certificate was not revoked.

手順	エビデンス	評価した境界
ディレクトリ全体のACLを列挙	3,002行。CAサービスアカウントに対して、一般ユーザー向けの継承されていないWriteOwnerACEが一つ存在	Tier-0オブジェクトが一般ユーザーから分離されていたか。
所有権を奪取してDACLを書き換え	所有権の奪取とGenericAll付与を実環境で再現。書き込みはバイト単位で一致する状態にロールバック	ACEが存在するだけでなく、悪用可能だったか。
CAサービスアカウントを制御	アカウントはCert Publishersのメンバーで、テンプレートに対するGenericAllを保持	サービスアカウントの権限が証明書発行に及んだか。
テンプレートを変更して証明書を要求	ESC4の条件。管理者証明書を発行	テンプレートのACLが特権主体としての登録を防いだか。
証明書で認証してkrbtgtを複製	ドメイン複製とゴールデンチケット	証明書認証がドメインコントローラーの権限に到達したか。
失効を確認	誤発行された管理者証明書は未失効のまま	組織が認証情報を無効にできたか。

エビデンスが実証する内容 ：ACLの乗っ取りを実環境で再現し、アカウントの権限がCAの使用するテンプレートに及ぶことを確認しました。証明書と複製の段階は、エージェントのクリティカルなチェーンとして記録されています。評価終了時点でも誤発行された証明書は失効していませんでした。これはラボ評価であり、顧客の結果でも比較ベンチマークでもありません。未失効の証明書は未解決のクリーンアップ項目であり、復元完了のエビデンスではありません。同等の案件では、責任者を指定して証明書を失効させ、結果を検証してから、クリーンアップの完了を受け入れる必要があります。

評価結果 ：CAサービスアカウントを制御することで、管理者証明書を要求できるよう変更可能な証明書テンプレートにアクセスできました。記録されたシーケンスは、最初のACLの構成ミスを、証明書認証とドメイン複製につなげました。このラボでは、自動評価と手動評価の性能を比較していません。

修復の方向性 ：このACEを削除し、Tier-0オブジェクトの継承されていない権限付与をすべて見直します。CAサービスアカウントを一般的な管理作業から分離し、テンプレートのACLをCAとディレクトリ管理者に制限し、サービスアカウントのRC4を無効化します。テンプレート変更と証明書発行には承認とログ記録を必須とし、誤発行の証明書を失効させ、krbtgtを2回ローテーションします。再テストでは、低権限ユーザーがCAアカウントを所有したりテンプレートを変更したりできないこと、DCSyncが失敗すること、ローテーション後に偽造チケットが拒否されることを検証すべきです。

内部テストのレポートには、開始時のID、影響を受けるACL、取得した権限、検証結果、成功しなかったテスト、残存物を記載すべきです。管理者はこの情報を使って検出結果を再現し、権限委任を修復し、許可されたスコープ内でクリーンアップを検証します。