必要だったのは管理者アカウント1つだけでした

2026年3月11日水曜日。79か国のStrykerのオフィスで従業員がPCの電源を入れると、中身は空でした。ログイン画面はロゴに置き換わっていました。社用ノートPC、社用スマートフォン、そして同社のBYODプログラムに登録されていた私物端末まで、すべてが一夜のうちに同時に消去されました。ランサムウェアもマルウェアのシグネチャも、エンドポイント検知ツールが捉えられるものは何もありませんでした。

攻撃者は親イランのハクティビスト集団Handalaです。彼らはStryker自身のIT管理インフラを武器に変えました。

実際に何が起きたのか

この攻撃の核心は、高度なエクスプロイトでもゼロデイ脆弱性でもなく、はるかに単純で、はるかにありふれたものでした。管理者アカウントが1つ侵害され、そのアカウントがMicrosoft Intuneにアクセスできたのです。

BleepingComputerの報道によると、UTCの5時から8時のあいだにおよそ8万台の端末が消去されました。Handalaは、79か国にわたる同社のグローバル業務で使われていたサーバーやモバイル端末を含め、その数は20万台を超えたと主張しています。すべては正規の管理コンソール1つを通じて実行されました。

この攻撃が成功した理由

このインシデントの根底には構造的な問題があり、それはStrykerに固有のものではありません。ほとんどの企業に当てはまります。

多くの組織は、管理作業と日常業務を、同じ端末で同じユーザーIDのもとに問題なく共存できる活動として扱っています。IT管理者はメールに返信し、Webを見て、ときにはリンクをクリックし、同じセッション、同じ端末からクラウドインフラを管理し、アクセス変更を承認し、今回のように、端末群全体を消去できる権限を持つデバイス管理コンソールに触れます。

そこが攻撃面です。日常の業務コンテキストと特権的な管理コンテキストが、同じエンドポイントと同じIDを共有しているなら、そのエンドポイントの侵害は、そのIDが到達できるすべての侵害を自動的に意味します。フィッシング、インフォスティーラーによる認証情報の窃取、Adversary-in-the-Middle（AiTM）によるセッショントークンの窃取。そのすべてが、環境内で最も強力な制御への直通経路になります。特権昇格は必要ありません。攻撃者はすでにそこにあるものを使うだけです。

Strykerの場合、そのアクセス先には、6大陸の端末を管理するIntuneテナントが含まれていました。

CISAが動いた

攻撃の規模と大胆さは、異例の反応を引き起こしました。米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁であるCISAが、侵害されたデバイス管理プラットフォームのリスクを正面から扱うガイダンスを公表したのです。同庁はこの攻撃経路を認識していることを確認したうえで、組織に具体的な対応を求めました。端末の消去のようなリスクの高いIntune機能について、実行前に第二の管理者の承認を必須にすることです。

これは稀で、かつ重要なシグナルです。連邦のセキュリティ当局が具体的なインシデントの直後に的を絞ったガイダンスを出すとき、メッセージは明確です。これは例外的なケースではありません。これはパターンであり、他の組織も同じリスクにさらされている可能性が高いということです。

分離は贅沢ではなく、制御そのものです

Strykerへの攻撃は、フラットな特権モデルがどれほどの規模の被害を招きうるかをはっきりと示しました。攻撃者は脆弱性の連鎖をたどって特権を昇格させる必要がありませんでした。あるレイヤーで認証情報かセッショントークンを手に入れ、そのレイヤーだけで、破滅的で、グローバルで、取り返しのつかない損害を与えるのに十分だと気づいたのです。

この問題に対するアーキテクチャ上の答えには名前があります。Microsoft Enterprise Access Model（EAM）です。その中核となる原則は階層化された管理です。特権操作は専用のアカウントと専用の端末で行い、日常の業務コンテキストから厳格に分離します。この最小権限のアプローチにより、侵害された業務用アカウントは管理レイヤーに到達できず、侵害された管理アカウントはコントロールプレーンの操作を実行できません。これはクラウド専用の環境にも、Entra ID経由でオンプレミスのActive Directoryとつながるハイブリッド構成にも等しく当てはまります。ハイブリッド構成では、過剰な権限を持つアカウント1つが、いまなおクラウドとドメインを橋渡ししてしまいます。

考え方は単純です。管理作業は管理用の端末で行う。Microsoft 365テナント、Intune環境、Azureインフラの管理に使うIDは、メールを読んだりTeams会議に参加したりするIDと決して同じにしない。管理セッションに使う端末は、堅牢化され、制限され、攻撃面を生み出す通常のWebブラウジングや業務コンテキストから隔離する。ラテラルムーブメントは構造的に難しくなります。横に移る経路がそもそも存在しないからです。

二つの防御レイヤー

この脅威モデルに正しく対処するには、二つのレイヤーで同時に取り組む必要があります。管理レイヤーとその認証情報に誰が触れられるかを守ること、そしてその管理レイヤー自体がどのように構成され運用されるかを堅牢化することです。この二つは同じ問題ではなく、どちらも重要です。

Managed Red Tenant：管理コンテキストを守る

第一のレイヤーは、特権アクセスを完全に隔離することです。それが当社のManaged Red Tenantの狙いです。

Managed Red Tenantは、完全に隔離されたクラウドベースの管理環境を提供します。特権操作専用に使われる専用のMicrosoft Entraテナント、すなわち「Red Tenant」です。管理用のIDはここに存在します。管理用の端末はここで管理されます。通常の業務環境からは何も流れ込みません。

最も重要なロール、たとえばグローバル管理者のようにコントロールプレーンへのアクセスを持つロールには、「Clean Keyboard」というアプローチを実装します。専用ハードウェアと堅牢化されたポリシーを備え、日常の業務コンテキストとの接点を一切持たない物理的なPrivileged Admin Workstation（PAW）です。コントロールプレーンより下の管理ロールには、Red Tenant内の堅牢化されたAzure Virtual Desktop基盤上に構築したスケーラブルなVirtual Access Workstation（VAW）を提供します。アクセス経路そのものもMicrosoft Entra Private Accessで保護され、セッションが確立される前にゼロトラストネットワークアクセスと条件付きアクセスのポリシーが適用されます。

Microsoft Entra Internet Accessは管理セッションからのパブリックなインターネットアクセスをブロックし、接続先を特権インターフェイスと認可されたテナント環境に厳しく限定します。Universal Conditional Access Evaluationにより、ほぼリアルタイムでのセッション失効が可能です。つまり、失効した認証情報が有効なセッションとして生き延びることはありません。

Managed Red Tenantは当社のCloud Security Operations Center（CSOC）が24時間365日で監視し、管理権限とアクセスパターンに的を絞った専用の検知を用意しています。この環境で攻撃者が何らかの方法で認証情報を侵害したとしても、グローバルな端末群に対してワイプコマンドを実行するための3時間を、気づかれないまま使うことはできません。

これはIntune管理者のようなロールで特に重要です。彼らはクライアントを保護する方法は知っていますが、特権管理ワークステーションを守るには別のスキルが要ります。Enterprise Access Architecture、ID堅牢化、ゼロトラストの制御です。これらは通常セキュリティチームの領域です。Managed Red Tenantはこの負担をすべて引き受けます。Intune管理者は、自らセキュリティワークステーションの専門家になることなく、専門的に管理され一貫して堅牢化されたワークステーションを手にできます。これは組織内のあらゆる高特権ロールに当てはまります。

Managed Intune：管理レイヤー自体を保護する

第二のレイヤーは、Strykerへの攻撃で武器として使われたツールであるIntuneそのものを、最高水準のセキュリティで構成し、運用し、継続的に保守することです。それを担うのが当社のManaged Intuneサービスです。

この種のインシデントから得られる重要な示唆の一つは、組織が有機的に膨らんだIntune環境を引き継いでいることが多いという点です。ポリシーの上にポリシーが積み重なり、監査しにくい手作業のポータル変更が加わり、セキュリティベースラインはMicrosoft自身の進化する推奨に追いついていません。構成のドリフトが悪用可能な穴を生むのは、まさにこうした環境です。

Microsoftは最近Microsoft Intuneのセキュリティ確保に関するベストプラクティスを公開しました。Microsoft自身も、Intuneの堅牢化を業界全体で明示的に取り組むべきテーマと捉えているというシグナルです。当社のManaged Intuneサービスはこれらの原則に基づいており、Microsoftの推奨事項をベースラインの一部として実装しています。

当社のManaged Intuneサービスはglueckkanja Intune Foundationを基盤としています。実績があり継続的に保守されるデバイス管理のベストプラクティス群を、Terraformと自社のTerraProviderで完全にコードとして展開します。あらゆる変更は自動化され、バージョン管理され、監査可能です。意図した設定と実際の設定のずれを突いて攻撃者が悪用できるような、文書化されていないクリック操作の構成は存在しません。

セキュリティの観点では、ゼロトラスト、App Protection Policies、エンドポイントセキュリティの構成が、Windows、macOS、iOS、Androidを通じて設計上一貫して適用されることを意味します。一度きりの展開ではなく、Microsoft自身のセキュリティガイダンスを追随しながら継続的に強制され、常に更新されるベースラインとしてです。

重要なのは、Managed Intuneが現代のエンドポイント管理に求められる運用の成熟度を体現している点です。継続的なコンプライアンス監視、構造化された変更ガバナンス、定期的なサービスレビュー。これらはオプションの追加機能ではなく、当たり前の運用です。ただし、Intuneの構成を守るのは半分にすぎません。コンソールにアクセスする管理者が保護されていない端末から作業していれば、管理レイヤーは依然として露出したままです。まさにここで、Managed Red Tenantがモデルを完成させます。

すべての構成はIntune Foundationを基盤にコードとして展開されるため、ピアレビューによる厳格な四つの目の原則、追加の自動検証、制御されたデプロイパイプラインを徹底しています。これにより、Intune Foundationの範囲内で管理外のポータル変更が生じる余地をなくし、すべての端末にわたって一貫性があり、監査可能で、安全なベースラインを確保します。

管理アクセスはGDAPとAzure Lighthouseによる最小権限モデルで制御し、責任範囲を明確に定義したうえで、お客様テナントへのアクセスを厳しく限定します。これにより、特権操作に伴う攻撃面が大きく減ります。

破壊的な操作を含む端末レベルのアクションは、お客様の責任範囲に残ります。その実行は組織固有のプロセスや内部のガバナンスフレームワークと密接に結びついているためです。MicrosoftとCISAは、こうしたアクションを追加の保護策で守ること、たとえばIntuneのマルチ管理者承認の制御を使うことを推奨しています。

居心地の悪い問い

Strykerへの攻撃はMicrosoft Intuneへの告発ではありません。Intuneは設計どおりに振る舞いました。認証された管理者から受け取ったコマンドを実行しただけです。失敗はツールにあったのではありません。誰がそのツールに、どのコンテキストから、どの程度の認可で到達できるのかという制御が欠けていたことにあります。

これはガバナンスとアーキテクチャの問題です。そして、今日Microsoft 365を運用している大半の組織に同じ問題が存在します。

自社の管理者が、日常業務に使うのと同じ端末とIDでIntune、Entra ID、Azureにアクセスしているなら、そしてIntune環境が構造化され自動化された運用モデルではなく、長年の手作業によるポータル変更の積み重ねで膨らんでいるなら、3月11日にStrykerが抱えていたのと同じ構造的リスクを抱えています。問われるのは、その弱点を塞ぐ前に攻撃者が見つけるかどうかです。

Managed Red Tenantは特権とIDのレイヤーに対応します。Managed Intuneは構成と運用のレイヤーに対応します。この二つが揃って、Strykerへの攻撃を可能にした2つの穴を塞ぎます。

いずれかのサービスが自社の現在の環境にどう当てはまるのか、あるいは具体的な弱点がどこにあるのかを知りたい場合は、ぜひご相談ください。

Strykerのインシデントがそもそもなぜ起こりえたのかを掘り下げる記事も、近く公開する予定です。

関連情報

• CISA: Securing Cloud Business Applications
• Microsoft: Microsoft Intuneのセキュリティ確保に関するベストプラクティス
• TechCrunch: ハッカーによるStryker端末の大量消去を受け、CISAが企業にMicrosoft Intuneシステムの保護を要請
• Azure MarketplaceのManaged Red Tenant