All
SaaS管理
デバイス管理
セキュリティ対策
脅威・インシデント
IT基盤・インフラ
情シス業務・組織形成
AI / テクノロジー
プロダクト
イベントレポート
その他
ガバナンス

新着記事

もっと見る

>

>

トロイの木馬とは?Trojanの意味や感染経路・初動対応

トロイの木馬とは?Trojanの意味や感染経路・初動対応

トロイの木馬とは?Trojanの意味や感染経路・初動対応

トロイの木馬とは?Trojanの意味や感染経路・初動対応

公開日

最終更新日

この記事は、意味や読み方を知りたい一般の方と、初動対応を担う企業の情シスの両方に向けて、感染の見分け方と対応手順を説明します。

一般利用者の結論

  • 意味:トロイの木馬(Trojan horse)は、無害なソフトやファイルを装って侵入するマルウェアです。

  • 表記:Trojanは「トロジャン」とも表記します。

  • ブラウザに警告が出ただけでは、感染したとは判断できません。

  • 画面の指示でコマンドを実行した、ファイルを起動した、第三者に遠隔操作を許可した場合は、端末をネットワークから隔離します。

  • パスワードや認証コードを入力した場合は、安全な別の端末からアカウントの保護を始めます。

意味や読み方を知りたい方は、最初の章と感染の切り分け表から読めます。企業の情報システム部門(情シス)、セキュリティ担当者、SaaS管理者は、後半の比較表と初動対応手順を使えます。ClickFixによる実行誘導、ブラウザの認証情報窃取、ログイン済みセッションの悪用まで扱い、端末の駆除だけで対応を終えないための判断材料を整理します。

トロイの木馬の特徴や感染経路とともに、端末のネットワーク隔離やアカウントセッション切断といった初動対応の手順を解説するインフォグラフィック。

トロイの木馬とは

トロイの木馬とは、無害なソフトやファイルに見せかけて侵入する悪意あるプログラムで、目的は亜種により異なり、情報窃取、遠隔操作、追加マルウェアの導入などに使われます。

本記事のポイント

  • 英語のTrojan horseが「トロイの木馬」にあたり、略してTrojanとも呼びます。

  • 偽装を特徴とするマルウェアで、自己増殖するかどうかは分類の必須条件ではありません。

  • 警告画面の表示だけでは感染を断定せず、ファイル実行、コマンド入力、遠隔操作の有無で初動を分けます。

  • 感染を疑った企業では、端末隔離、管理者によるセッション切断、証拠保全の順で対応します。

英語Trojanの意味と語源

英語のtrojan horseの意味は「トロイの木馬」で、Trojanには「トロイの」「トロイ人」という意味があります。IT分野では、その略称を悪意あるプログラムの分類名として使います。

名称は、トロイア戦争の木馬の逸話に由来します。アイ・オー・データ機器の解説も、トロイア戦争に由来する名称として紹介しています。外から見える姿と、内部で実行する処理が異なる点を押さえると、IT用語の意味を理解しやすくなります。

読み方と複数形の意味

trojanは、日本語では「トロジャン」「トロージャン」とも表記します。「トロイとは何か」をセキュリティの文脈で尋ねる場合は、通常、このマルウェアを指します。

trojansは複数形で、IT文脈では複数のマルウェアを指します。読み方は「トロージャンズ」に近くなりますが、一般の英文では「トロイ人たち」やチーム名などを指す場合もあります。例えば「This file is a Trojan.」は「このファイルはトロイの木馬です」という意味です。英単語の意味と、端末での検知結果は分けて読みます。

ウイルスやワームとの分類上の違い

マルウェアはウイルス、ワーム、トロイの木馬を含む悪質なコードの総称で、それぞれ分類が異なります。IPAが公開するNIST SP 800-83(2005年11月版)の日本語訳は、マルウェアの例としてウイルス、ワーム、トロイの木馬などを挙げています。

分類

分類で着目する特徴

主な影響

トロイの木馬

正常なプログラムなどへの偽装

認証情報窃取、遠隔操作、追加感染

ウイルス

他のファイルなどへの感染・自己複製

ファイル改変、感染範囲の拡大

ワーム

ネットワーク経由の自律的な拡散

端末・サーバーへの急速な感染拡大

ランサムウェア

暗号化や情報窃取を使った金銭要求

業務停止、情報漏えい、復旧対応

この表の分類は完全な排他関係ではありません。偽装して侵入したプログラムが、認証情報を盗み、別のマルウェアを呼び込み、その後の暗号化につながる場合があります。情シスは分類名だけで判断せず、端末上の処理とアクセス先を追跡します。

実務分類とコンピュータウイルス対策基準の違い

実務上の分類と基準上の定義は目的が異なるため、「トロイの木馬はすべて同じ基準に該当する」と一括りにはしません。

経済産業省のコンピュータウイルス対策基準は、自己伝染機能、潜伏機能、発病機能のいずれかを持つものをコンピュータウイルスと定義しています。社内手順では、広義の「ウイルス感染」という連絡を受け付けたうえで、調査担当者が実際の挙動を分類すると、利用者への説明と技術調査を両立できます。

表記揺れと検知名の読み取り

名称の綴りだけでは感染の有無や危険度を判断できないため、警告を出した製品と検知対象を合わせて読みます。

「トロイ木馬」などの表記揺れも同じ語を指し、英語の基本表記はTrojanです。ログやメールに検知名の一部しか残っていない場合は、管理コンソールで検知名・対象ファイル・処理結果を照合し、特定できなければ通常の検知として調査します。

「dummy trojan」のdummyは、一般にダミーや模擬物を意味します。ただし、その文字列があることと、対象ファイルが安全であることは別です。テスト用と判断する場合は、管理者が実施した試験の記録、配布元、対象ファイルが一致しているかで判断し、一致しなければ通常の検知として扱います。

▶ 関連記事: スマホがマルウェア感染したら?情シス向け・社用端末とBYODの症状別対処と復旧手順

偽警告と実感染の切り分け

感染を疑ったときは、警告の強い言葉ではなく、自分が実行した操作と端末・アカウントの記録で対応を分けます。

一般利用者向けのクイック判定

画面を見ただけの場合と、指示に従って操作した場合では、最初に取る行動が異なります。

起きたこと

判断

最初の行動

ブラウザに感染警告や電話番号が出ただけ

表示だけでは端末感染の証拠になりません

電話・支払い・ソフト導入をせず、追加操作を止めます

ファイルをダウンロードしたが実行していない

ダウンロードと実行を区別します

ファイルを開かず、管理者に保存場所と取得元を伝えます

コマンドを貼り付けて実行した

端末侵害の可能性を前提に扱います

ネットワークを隔離し、実行時刻を記録します

遠隔操作を許可した

第三者が端末を操作した範囲の調査対象です

通信を切り、別端末から管理者へ連絡します

パスワードや認証コードを入力した

端末感染とは別にアカウント侵害を疑います

安全な端末からアカウント保護を開始します

セキュリティ製品がファイルや挙動を検知した

検知名、処理結果、対象端末の確認が必要です

検知画面を保存し、隔離済みかを管理者へ伝えます

個人利用の端末では、実行や遠隔操作をした場合に通信を切り、信頼できるサポート窓口へ相談します。勤務先の端末では、私物のUSBメモリにファイルを移したり、独自に駆除ソフトを追加したりせず、社内の連絡先へ状況を伝えます。会社の管理者が遠隔隔離できる場合は、その指示に従います。

感染時に現れる症状と無症状のリスク

動作の遅さは感染の手掛かりになりますが、症状がないことも安全の証明にはなりません。

調査のきっかけには、見覚えのないプロセス、セキュリティ設定の変更、不審な外部通信、勝手なソフトの追加、身に覚えのないログイン通知などがあります。更新処理や正規の管理ツールでも似た現象が起きるため、利用者は自己判断でプロセスを削除せず、いつから何が変わったかを記録します。

情報窃取を目的とするプログラムは、利用者の作業を妨げずに動く場合があります。そのため、企業では端末の見た目に加え、メール転送設定、クラウドの外部共有、認証履歴の変化も調査します。異常なログインがあれば、端末で検知がなくてもアカウント側の対応を先に進めます。

本物の検知通知とWeb上の表示の違い

通知の発信元を調べる際は、警告内のリンクではなく、普段使っているセキュリティ製品の画面を直接開きます。

管理対象のPCなら、管理者は製品の管理コンソールで端末名、検知時刻、対象ファイル、処理結果を照合します。該当する記録があれば、その検知を起点に調査します。記録がなく、Webページだけが警告している場合は、表示内容を感染の根拠にはしません。ただし、同時に実行操作をしていれば、検知記録の有無にかかわらず隔離対象です。

「駆除しました」という通知があっても、盗まれた情報まで元に戻ったとは判断できません。プログラムが遮断される前に認証情報へアクセスしていないか、端末以外で不正利用が起きていないかを管理者が調べます。

偽警告対策と本記事の対象範囲

偽警告への対応とマルウェア感染後の対応は分け、ファイル実行や遠隔操作があれば後者へ移ります。

サポート詐欺は、警告の表示自体より、その後にソフトを導入させたり認証情報を入力させたりする誘導に注意します。本記事ではマルウェアの挙動と組織の初動を扱い、警告画面の閉じ方などは専用記事にまとめています。

▶ 関連記事: EDRとアンチウイルスの違いとは?IPSとの比較と選定ポイント

警告画面の表示や操作内容に応じた初動の切り分けフローです。

▲ 警告画面の表示や操作内容に応じた初動の切り分けフローです。

最新の感染経路と警戒すべき攻撃手口

添付ファイルだけでなく、Web画面でコマンドを実行させるClickFix、正規ツールの悪用、不正アプリも侵入口になります。

ClickFixと偽の操作指示

ClickFixは、偽CAPTCHAや偽Windows Update画面などを使い、利用者自身にコマンドを実行させる手口です。

攻撃画面は「人間であることを確認する」「更新エラーを直す」などの理由を示し、WindowsキーとRを押す、クリップボードの文字列を貼り付ける、PowerShellを起動するといった操作へ誘導します。通常のWeb閲覧から、OS上の処理を実行させる段階へ移った点を見逃さないようにします。

社内教育では「知らない添付ファイルを開かない」に加え、「Web、チャット、電話の指示でコマンドを貼り付けない」と具体的に伝えます。業務上の実行が必要な場合は、利用者が内容を自己判断せず、社内の依頼記録と管理者の承認を通します。

ClickFixを想定した端末検知

端末側では、単一のファイル名より、コマンド実行から外部通信へ進む一連の動作を調査します。

エンドポイントの検知・対応を担うEDRでは、実行されたコマンド、親子プロセス、通信先、後続ファイルの作成を関連付けます。PowerShellから外部のスクリプトを取得して実行した形跡や、難読化された長いコマンドは調査対象にします。ただし、管理作業にも似た処理があるため、文字列一つで遮断せず、利用者、端末、依頼記録を合わせて判断します。

Windowsの「ファイル名を指定して実行」から起動した場合は、ブラウザが直接の親プロセスとして現れるとは限りません。ブラウザ履歴、実行時刻、プロセス記録を時系列で照合すると、Web上の誘導と端末上の処理を結び付けやすくなります。

メール添付と返信を装う誘導

取引先の名前や返信らしい件名があっても、それだけで添付ファイルを信頼しません。

NTT東日本の解説では、2022年に急増したEmotetについて、過去の送受信メールのタイトルに「Re:」を付けて送信する機能を取り上げています。これは2022年時点の事例であり、現在は配布方法や対策状況が変化している可能性があります。ここから参照できるのは、見慣れた文脈が不正ファイルの実行を促す材料になる点です。

請求書、契約書、採用資料などを日常的に受け取る部署では、例外的な解凍操作、保護機能の解除、追加ソフト導入を要求されたときに、メールとは別の経路で送信者へ照会します。送信者が否定した場合は開封を止め、肯定した場合も社内の検査経路を通します。

PowerShellとWindows標準ツールの悪用

PowerShellやWMIなどの正規機能は、業務用途を残しながら利用者と実行範囲を制限します。

wscript、mshta、rundll32なども、攻撃に悪用され得るWindowsの機能です。正規機能を利用する攻撃をLiving off the Landと呼び、LOLBASはそのように悪用され得るバイナリやスクリプトなどを整理する文脈で使われます。正規署名があるという理由だけで、実行内容まで安全と判断しません。

制御を強める前に、プロセス作成ログとPowerShellのスクリプトブロックログを取得します。管理スクリプトの用途と所有者が分かれば、許可対象を整理して制限を適用します。Constrained Language Modeを使う場合も、業務ツールへの影響を検証し、アプリケーション制御などと組み合わせて適用範囲を決めます。

遠隔操作ソフトとサポート詐欺

遠隔操作ソフトは、製品名ではなく、誰がどの目的で接続を許可したかで利用の正当性を判断します。

AnyDesk、LogMeIn Rescue、TeamViewer、UltraViewerなどの製品を端末上で見つけた場合も、存在するだけでマルウェアとは断定しません。会社が許可した支援か、利用者が警告画面の指示で入れたものかを、導入履歴と支援チケットで照合します。依頼記録がなく第三者の接続を許可した場合は、操作された範囲を調べます。

社内の遠隔支援では、許可製品、接続担当部署、承認手順、操作ログの保存先を定めます。利用者には「正規製品だから入れてよい」ではなく、「社内の窓口で照合できる依頼だけを受ける」と伝えます。

モバイル端末と開発環境の侵入口

スマートフォンと開発端末は、PCと同じ設定を一律に当てるのではなく、保存する情報と実行できるアプリに合わせて管理します。

モバイルでは、SMSやQRコードからの偽サイト誘導、提供元不明アプリの導入を防ぐ設定を優先します。開発端末では、不審なパッケージ、拡張機能、サンプルコードの実行が、SSH鍵やAPIトークンへのアクセスにつながらないよう、検証環境と業務用の認証情報を分離します。導入元が承認済みなら管理対象へ登録し、出所が不明なら業務端末上で試さず隔離した検証環境で扱います。

▶ 関連記事: トロイの木馬 警告 消し方と本物との見分け方!無視して大丈夫なケースと偽警告対処法

情報窃取型トロイとMFA突破の条件

情報窃取型トロイに対応するときは、パスワード変更に加え、ID基盤と各SaaSでセッション・リフレッシュトークンを失効させます。

インフォスティーラーの窃取対象

インフォスティーラーは、端末に保存された認証情報やログイン状態を維持する情報を盗むマルウェアです。

Lumma Stealer、RedLineなどの名称で扱われる情報窃取型マルウェアへの対策では、ブラウザの保存パスワード、Cookie、認証関連データ、暗号資産ウォレット、開発用シークレットなどを調査対象にします。具体的な窃取範囲は亜種や実行条件で異なるため、名称だけから「すべて盗まれた」「何も盗まれていない」と判断しません。

端末に保存された情報へアクセスできる条件は、OS、ブラウザの保護方式、実行権限などで変わります。管理者は検知されたプロセスのアクセス先と利用者の業務範囲を照合し、失効させる認証情報の優先順位を決めます。管理者権限や経理業務に使う情報が含まれるなら、一般的な端末復旧より先にアカウントを封じ込めます。

Cookie窃取とセッション再利用

攻撃者が悪用するのはログイン状態を示すセッション情報やトークンであり、利用者のブラウザからCookieを削除するだけでは対応が完了しません。

Cookieには、サービスによってセッション識別子などが保存されます。一方、リフレッシュトークンは、利用者が毎回認証情報を入力せずに新しいアクセストークンを取得するための情報で、Cookieと同じものではありません。保存場所や扱いはサービスごとに異なります。

攻撃者が別の環境へ情報をコピーした場合、元のブラウザ内のデータを消しても、そのコピーまで消えるわけではありません。管理者は安全な別端末から、ID基盤であるIdPと各SaaSの管理画面を使い、セッション無効化とリフレッシュトークンの即時失効を実行します。サービス側の失効処理が既発行のアクセストークンへ反映されるまでの動作も把握し、反映待ちの間にアクセス制限をかける必要があるかを判断します。

MFAを回避される条件と保護の限界

多要素認証であるMFAを設定していても、認証済みセッションが再利用できる条件では不正アクセスが成立する場合があります。

これは、攻撃者が毎回MFAの認証処理そのものを破ることとは異なります。ログイン後の状態を示す情報が利用可能で、サービスが追加の端末確認や再認証を要求しない場合に、盗用セッションを受け入れてしまう可能性があります。端末自体を遠隔操作された場合も、正当な利用者のセッションをその場で悪用され得ます。

重要SaaSが端末状態を評価できるなら、管理済み端末からの利用に制限します。トークン保護や継続的なアクセス評価を利用できる環境では、対応する認証経路へ適用します。こうした制御を利用できないサービスでは、管理者IDの分離、権限最小化、重要操作時の再認証、監査ログの監視へ配分を寄せます。

初期侵入から横展開への連鎖

トロイの木馬の調査では、最初に感染した端末から、別端末や管理者アカウントへ侵害が広がっていないかを追います。

CybereasonはQbotの解説で、不審メールの添付ファイルから感染し、Mimikatzによるパスワード窃取やCobalt Strikeによる横展開へ進む例を取り上げています。このように、最初のマルウェアと最終的な被害を起こすツールが異なる場合があります。

感染した利用者が管理者権限を使った履歴があれば、特権アカウントの認証記録を優先して調べます。共有フォルダやVPNへ接続していれば、その接続先を調査範囲へ加えます。一方、利用履歴がないシステムまで一律に停止するのではなく、接続記録と権限を根拠に範囲を広げます。

ブラウザと開発用認証情報の管理

ブラウザや開発端末に認証情報を保存する場合は、漏えい後に誰が失効できるかまで決めます。

企業向けパスワード管理ツールへ移す場合は、共有範囲、利用者の認証、監査記録、復旧手順を合わせて設定します。保存先を変えるだけで端末感染の影響が消えるとは扱いません。ロック解除中の操作や、管理者権限を持つ利用者の侵害も想定します。

APIキー、個人アクセストークン、SSH鍵は、可能なら短期の認証情報や用途別の権限へ移します。移行できない場合は、所有者、用途、接続先、失効権限者を台帳に残します。漏えい時に再発行できるなら直ちに交換し、交換に業務停止を伴うなら接続元制限を先にかけて切り替えます。

▶ 関連記事: EDRとは?EPPとの違いやコスト・選び方を解説

国内統計と企業事例から見る被害規模

予算や対応計画を作る際は、トロイの木馬、不正アクセス、ランサムウェアの統計を同じ母集団として扱わず、自社の事故シナリオに合う数値を使います。

IPA調査の対象と侵入手口

IPAの2024年度調査からは、マルウェア検知に加えて脆弱性対策と認証情報保護へ対応を配分する判断材料を得られます。

IPAが2025年2月14日に公表した調査では、不正アクセス被害を受けた企業419社が挙げた手口として、「脆弱性を突かれた」が48.0%、「ID・パスワードをだまし取られた」が36.8%、「取引先やグループ会社等を経由して侵入」が19.8%でした。これらは、このマルウェアに限った感染経路の数値ではありません。

IPA調査の数値

対象・条件

運用への反映

脆弱性悪用48.0%

不正アクセス被害企業419社の回答

VPNや公開機器の更新を端末対策と並行します

ID・パスワード詐取36.8%

同じ被害企業群の回答

認証情報の入力先とログイン履歴を調べます

取引先などを経由19.8%

同じ被害企業群の回答

委託先接続と共有アカウントを管理します

ウイルス対策ソフト導入80.0%

対策の必要性を感じる企業2,203社

導入済みかに加え、検知後の対応担当を決めます

手口の割合を合計して「全体の感染率」とする使い方はしません。また、対策ソフトの導入率と被害率は、対象や設問が異なるため単純には比較できません。経営説明では数値の横に対象企業群と質問内容を添え、製品導入の有無だけで安全性を結論付けないようにします。

エモテット被害の損害額と内部工数

被害額を予算へ反映する際は、報告された個別金額と平均値を区別します。

IPAの2024年度中小企業調査報告書は、IPA自身の集計ではなく文献調査として、日本ネットワークセキュリティ協会(JNSA)の「インシデント損害額調査レポート 別紙「被害組織調査」」(2024年2月)を引用し、エモテット感染組織の被害額の平均値を1,030万円、事故対応に要した内部工数の平均を2.9人月と載せています。同じ表には、被害金額を2,000万円以上と回答した組織がある一方で、数十万円以下の組織もあること、大企業や団体の回答も含むことが添えられています。1,030万円を、マルウェア被害全般や中小企業だけの平均額として引用しません。

警察への被害報告件数、企業アンケートの平均被害額、損害額調査の掲載値は、それぞれ集計対象も費用の数え方も異なります。ランサムウェアの損害額と、エモテットなど別のマルウェアの損害額を同じ欄へまとめると、必要な予算を見誤ります。社内資料では「被害の種類」「対象」「金額に含む費用」「内部工数」を分けて記載します。

たとえば、外部調査費だけを見積もると、社内の端末回収、再設定、取引先への説明、通常業務の遅れが抜けます。経営者が予算を判断する場面では、情報システム部門の支出と、事業部門の停止・対応工数を別項目にして積み上げます。

ソフトバンクの大規模端末導入

大規模な導入事例では、導入規模ではなく、自社に必要な配布・監視・隔離の設計を確認します。

ソフトバンクが2025年5月に公開した自社の導入事例では、社員のPCがマルウェアに感染すると別のPCへ横展開される状況に対処するため、検証後に約6万ユーザーへCybereasonを一括導入したと説明しています。導入規模として読み取れる数値は約6万ユーザーで、端末台数ではありません。この規模自体を、検知率や費用対効果の数値へ置き換えません。

同じ製品を検討する企業でも、導入規模だけを根拠に運用方式を合わせる必要はありません。情シスは、配布に失敗した端末の追跡、業務ソフトとの競合、端末隔離の承認者、在宅勤務PCへの対応を自社条件で検証します。導入規模の数字は参考にしつつ、自社で測れる成果を「管理対象への適用率」「未対応アラートの滞留」「隔離までの時間」に分けます。

EPP・EDR・MDRの比較と費用の考え方

対策製品を選ぶ前に、侵入防止、侵入後の調査、監視担当の不足のうち、自社で埋めるべき範囲を決めます。

侵入防止と侵入後対応の役割比較

EPPは主に感染を防ぐ機能、EDRは端末の挙動を記録して検知・対応する機能で、両者を補完して使います。

NTTセキュリティ・ジャパンの解説も、EPPによる脅威のブロックと、すり抜けた脅威に対するEDRの検知・対応を分けています。製品によって両方の機能をまとめて提供するため、名称だけで重複や不足を判断しません。

区分

主な役割

社内に残る作業

注意点

EPP

不正ファイルや挙動の実行防止

ポリシー設定、例外承認、検知結果の確認

侵入後の調査機能は構成によって異なります

EDR

端末の挙動記録、検知、調査、隔離

アラート分析、隔離判断、影響範囲調査

通知を受けるだけでは対応が進みません

MDR

外部専門家による監視・検知・対応支援

連絡受付、業務判断、社内調整

隔離権限と支援範囲を契約で揃えます

メールセキュリティ

添付ファイルやURLなどの検査

配送例外、誤検知、取引先との調整

Webや開発環境からの侵入は別途対策します

MDRは、製品そのものではなく、監視や対応を外部へ委ねるサービスの区分です。SOCは、セキュリティの監視・分析を行う組織や拠点を指します。SOCサービスという名前でも、通知だけで終わる契約と、端末隔離まで担う契約があるため、担当する行為を契約書で揃えます。

対応OSと既存製品の互換性

製品を入れ替える場合は、対応OSと業務ソフトの互換性を少数の代表端末で試します。

既存のアンチウイルスを削除する前に、新しい契約に侵入防止機能が含まれるか、既存製品との併用条件は何かを整理します。名前にEDRが付くことだけを理由に、防御機能まで備わると判断しません。逆に、機能が重なる製品を無計画に同居させると、性能低下や誤検知の調整が増える場合があります。

検証対象には、通常の事務PCに加え、会計端末、開発端末、リモート接続端末など用途の違うPCを含めます。配布、再起動、アップデート、隔離、解除を試し、問題が出なければ段階的に対象を広げます。サーバーはPCと同じ条件とみなさず、停止できる時間帯と除外設定の影響を別に扱います。

モバイル管理との役割分担

スマートフォンを保護する場合は、PC向けEDRの導入率とは別に、モバイルの管理状態を測ります。

MDMは端末の設定やOS更新を管理する仕組みで、MAMは業務アプリと業務データを管理する仕組みです。Mobile Threat Defenseは、モバイル端末で脅威を検知する対策を指します。端末所有者と管理可能な範囲が明確なら、それに合わせて組み合わせます。

会社所有端末なら、OS更新、画面ロック、アプリ導入元の制限を管理対象にします。私物端末を業務利用するBYODでは、会社データを扱うアプリを限定し、個人領域を過度に監視しない設計にします。端末全体を管理できない場合は、重要SaaSへのアクセス条件を厳しくし、扱えるデータを制限します。

同じ条件で揃える見積項目

費用は端末単価だけで比べず、初期設定、監視、ログ保存、緊急対応を同じ範囲に揃えて計算します。

見積項目

揃える条件

条件が異なる場合の扱い

対象ライセンス

PC、サーバー、対応OS、最低契約数

対象外の端末に必要な別契約を加算します

初期導入

配布、ポリシー設定、既存製品の撤去

社内作業なら担当者の工数を別計上します

監視

営業時間内か24時間か、通知方法

対象外時間帯を社内で担えるか判断します

ログ保存

保存期間、検索、外部への出力

追加保存が必要なら保管費を加えます

事故対応

隔離、調査、報告書、現地支援

契約外対応の単価と手配先を別に確保します

試算用に1端末当たり月額1,000〜2,000円と仮定する場合、50端末の端末費用は月額5万〜10万円です。これは計算例であり、特定製品の現行料金や監視込みの相場を示すものではありません。実際の予算では、各社から得た同条件の見積額へ置き換えます。料金非公開の項目は要問合せとして残し、安価な項目だけで総額を判断しません。

導入前検証の合否基準

検証では、検知できるかに加え、担当者が通知を受けて対応を完了できるかを試します。

テスト端末で安全な検証方法を使い、管理コンソールへの反映、通知先への到達、隔離操作、解除、記録の保存まで実施します。自社で定めた応答時間内に担当者へつながるなら本番展開へ進み、つながらない場合は通知経路や外部支援範囲を修正します。機能が動いたという結果と、社内で運用できたという結果を分けて残します。

EPP・EDR・MDRにおける主な役割と運用上の留意点の比較です。

▲ EPP・EDR・MDRにおける主な役割と運用上の留意点の比較です。

導入後に起きやすい失敗と回避策

製品導入後の失敗を減らすには、通知の受け手、隔離の権限、例外設定の期限、復旧の責任者を稼働前に決めます。

アラートの放置と担当不在

アラートが届いても判断者が不在なら、検知から封じ込めへ進めません。

共通メールボックスに通知を送るだけでは、誰かが読んだのか、担当を引き受けたのかが残りません。情シスは受信、担当割当、初期判断、対応完了の状態をチケットで追います。営業時間外に対応できないなら、その時間帯の連絡を担う外部サービスを契約するか、事前に定めた高リスク条件で隔離する運用を検証します。

隔離によって業務停止が起きる端末では、技術担当だけで判断しないよう、業務責任者の連絡先と代行者を登録します。ただし、連絡が取れない間に被害が広がる事態を避けるため、隔離を先行できる条件も経営側と合意しておきます。

誤検知を理由とした過大な除外

誤検知への対応では、広いフォルダやプロセスを恒久的に除外せず、対象と期限を絞ります。

業務が止まるたびに「このフォルダ全体を除外する」と設定すると、攻撃者が処理を隠せる範囲が増えます。担当者は誤検知の対象、発生条件、業務影響を記録し、ファイル、署名、ハッシュ、実行条件など、製品で利用できる単位で限定します。暫定設定には所有者と見直し日を付けます。

同じ例外が繰り返し必要になる場合は、業務ソフト側の更新や運用変更も検討します。例外を適用した端末で追加のログ監視が可能なら補完し、できない場合は扱うデータや接続先を制限します。

MFAとパスワード変更への過信

MFAの有無やパスワード変更の完了だけを、事故対応の終了条件にはしません。

端末が侵害されたまま新しい認証情報を入力すると、再び窃取される可能性があります。感染端末ではログインを繰り返さず、安全な端末で管理者がアカウントを保護します。初動対応で実施した失効作業と、不審なアプリ連携の解除結果を、一件の対応記録へまとめます。

また、MFAを再登録する場合は、本人確認を済ませた利用者に対して実施します。攻撃者が登録した認証手段が残っていれば、正規利用者のパスワードだけを変更してもアクセス経路を排除できません。登録済み認証手段と復旧先の変更履歴も調査対象に含めます。

正規ツールの一律禁止

管理ツールの制限は、正当な用途と代替手順を把握してから段階的に適用します。

PowerShellや遠隔操作ソフトを一律に止めると、端末の更新、設定修正、在宅勤務者への支援まで滞る場合があります。利用部門が例外を求めて個別の回避策を使い始めると、かえって管理対象が見えなくなります。情シスは既存の利用をログと担当者への聞き取りで整理し、承認済み用途へ制限します。

代替手段がある部署から制御を適用し、代替がない業務では実行者、時間帯、接続元を絞ります。例外を残す場合も、申請者の退職や業務終了に合わせて自動的に見直せる期限を設定します。

バックアップの存在だけによる復旧判断

バックアップは、取り出して使える状態へ戻す試験まで実施して初めて、復旧計画へ組み込めます。

本番環境と同じ認証情報で削除できるバックアップは、侵害時に同時に失う可能性があります。管理者は保存先だけでなく、削除権限、保管世代、変更できない期間の設定、復元先を整理します。復元試験ではファイルが戻るかに加え、アプリケーションが正常に起動し、必要な利用者が業務を再開できるかを測ります。

復元に必要な設定情報やライセンスが感染端末にしか残っていない場合は、その不足を先に解消します。バックアップの取得成功率と、実際の復旧時間を別々に管理すると、復旧予定を希望的な日程で決めずに済みます。

初期化の先行と証跡の消失

感染端末を急いで初期化すると、侵入経路や情報窃取の範囲を調べる材料を失う場合があります。

再構築が必要な場合でも、調査担当者がログや必要な証跡を確保してから作業を開始します。業務継続が急務なら、元の端末を調査用に保管し、別の管理済み端末で業務を再開する方法を検討します。証拠保全の完了と業務再開を同じ作業にまとめないことで、調査を中断せずに代替手段を用意できます。

情シス向けの対策ロードマップ

着手順に迷う企業は、最初の30日で資産と権限を整理し、その後に検知・監視と復旧訓練を実装します。

最初の30日間の資産整理

最初の30日間は、守る対象と管理者を一覧にし、未管理の端末・アカウントを減らします。

情シスは端末台帳、契約台帳、ID基盤、端末管理ツールの情報を突き合わせます。端末名だけでなく、利用者、業務、OS、管理状態、最終接続、管理者権限を記録します。所有者が不明な端末は、すぐに削除するのではなく、利用部門と接続履歴を調べ、必要性がなければ管理手順に沿って廃止します。

SaaSでは管理者、共有ID、退職者、長期未使用アカウントを抽出します。所有者を特定できれば権限と継続利用を見直し、特定できなければ業務影響を確認して一時停止します。公開VPNやリモートアクセス機器も台帳へ含め、更新責任者がいない機器は外部接続の継続可否から判断します。

30日から90日までの検知整備

次の段階では、重要端末と重要SaaSから、侵害の時系列を追える記録を揃えます。

期間の目安

担当

実施内容

完了条件

開始から30日

情シス・各業務責任者

端末、ID、公開資産の棚卸し

各対象に所有者と管理責任者がある状態

30〜60日

情シス・SaaS管理者

端末検知と主要監査ログの取得

必要な記録を端末・ID単位で検索できる状態

60〜90日

情シス・外部監視担当

通知、隔離、セッション切断の訓練

担当者が手順に沿って実施できる状態

運用開始後

業務責任者・復旧担当

復元試験と手順の更新

実測した復旧時間と未解決事項を記録した状態

これは社内計画の例であり、製品の標準導入期間ではありません。重大な脆弱性や進行中の侵害がある場合は、表の期間を待たずに封じ込めと修正を優先します。すでに資産台帳が整っている企業は、棚卸しを繰り返すのではなく、通知と対応の訓練から始めます。

ログ取得と保存の設計

ログは取得量を増やす前に、事故時に答えたい質問から保存対象を決めます。

「誰がログインしたか」にはID基盤とSaaSの認証ログ、「何を実行したか」には端末ログ、「何を持ち出したか」には外部共有やダウンロードの監査ログを使います。各ログで利用者名や時刻の表記が異なる場合は、共通のIDとタイムゾーンへ対応付けます。

APIで安定して取得できるログは自動収集し、APIを使えないサービスは定期的な出力と事故時の退避手順を定めます。保存期間は一律の数字にせず、調査に必要な期間、契約、容量を踏まえて決めます。管理者が日常的に削除できる場所だけに置かず、記録の改変権限も分けます。

外部支援と社内判断の分担

監視や調査を外部へ委ねる場合も、業務停止と対外説明の判断者は社内に残します。

外部支援先へ渡す項目は、監視対象、連絡先、優先度、隔離可能な端末、作業承認の条件です。管理者端末は即時隔離できても、製造や医療など停止影響の大きいシステムでは別の判断が必要になる場合があります。対象ごとの例外を契約と運用手順に反映します。

夜間に社内担当者へつながらない場合は、代行者と、連絡不能時に支援先が実行できる行為を決めます。通知だけの契約なら、隔離と調査を担う別の担当を確保します。支援先が判断できない情報、たとえば重要顧客への連絡や生産停止の影響は、業務責任者が平時から整理して渡します。

担当者別のセルフチェック

未実施の項目には担当者と期限を付け、管理者ID、端末隔離、バックアップ復元に関わる不足から対応します。

  • 情シス:全PC、サーバー、業務スマホに所有者と管理責任者が登録されています。

  • ID管理者:管理者IDと一般利用者IDを分離し、不要な権限を削除しています。

  • SaaS管理者:不審なログイン、転送設定、外部共有の変更を追跡できます。

  • 端末管理者:端末隔離と解除を実機で試しています。

  • ヘルプデスク:コマンド実行や遠隔操作の相談を受ける窓口を周知しています。

  • 復旧担当:本番と分離したバックアップから復元を試しています。

  • 業務責任者:代替端末や代替業務の開始条件を決めています。

  • 経営・法務:顧客、取引先、関係機関への連絡判断者を決めています。

未実施の数だけで危険度を点数化しません。管理者権限を保護できていない、隔離手段がない、バックアップを戻せないといった業務継続に直結する不足を先に解消します。完了した項目も、担当者の異動や契約変更があれば手順を更新します。

感染が疑われるときの初動対応

感染が疑われた企業は、ネットワーク隔離、管理者によるセッション切断、証拠保全の順で動き、駆除や初期化は調査担当者と調整してから実施します。

最初の60分の行動

最初の60分は、感染の確定を待たず、被害の拡大を止めながら調査材料を残します。

時間の目安

担当

実施内容

直後〜10分

利用者・端末管理者

EDRで隔離、または有線LAN・Wi-Fi・VPNを切断し、社内窓口へ連絡します

10〜20分

ID・SaaS管理者

安全な別端末で対象アカウントを保護し、IdPと各SaaSの管理画面からセッション無効化とリフレッシュトークン失効を実行します。反映時間はサービスごとに異なるため、反映が確認できるまでアクセス制限を併用します

20〜40分

調査担当者

端末情報、検知内容、認証履歴、必要な揮発情報を保全します

40〜60分

対応責任者・業務責任者

影響範囲、追加隔離、外部支援、代替業務の開始を判断します

時間は社内訓練用の目安で、待機時間ではありません。明らかな不正利用が進行しているなら、管理者は隔離とアカウント停止を並行します。電源を切るとメモリ上の情報が失われるため、原則として不用意に再起動せず、調査担当者の判断に従います。ただし、破壊的な処理が継続し通信隔離だけで止められない場合は、被害抑制を優先する判断も対応責任者が行います。

管理者によるセッションとトークンの強制失効

アカウントの封じ込めは、安全な別端末からIdPと各SaaSの管理機能を使って実行します。

  1. 対象利用者と、端末で使われた管理者IDを特定します。

  2. 不正利用が続く場合は、必要に応じてアカウントを一時停止します。

  3. 管理者がセッション無効化とリフレッシュトークン失効を実行します。

  4. パスワード、APIキー、開発用トークンなど、漏えい範囲に応じた認証情報を交換します。

  5. 不審な認証手段、復旧先、メール転送、アプリ連携を解除します。

  6. 失効後のアクセス記録を調べ、遮断が反映されたかを追跡します。

IdPでサインアウトしても、すべてのSaaSのローカルセッションが同時に消えるとは限りません。連携先ごとに管理操作を行い、残るセッションがあればそのサービス側で切断します。ブラウザのCookie削除は端末内の処理にすぎず、この管理者操作の代わりにはしません。

証拠保全とログ退避

証拠は利用者の記憶に頼らず、発生時刻と取得元が分かる形で保存します。

利用者は画面の写真、表示されたURL、実行した操作、電話やチャットの相手を記録します。コマンドを実行した場合も、再実行して再現せず、残っている表示や履歴を担当者へ渡します。管理者はEDRの検知詳細、プロセスツリー、通信先、メールヘッダー、ブラウザ履歴、認証ログを退避します。

メモリ取得やディスクの保全が必要なら、手順を理解した調査担当者が実施します。保全物には取得者、取得日時、端末名、取得方法を記録し、権限を絞った保存先で管理します。調査用コピーを作れる場合は、原本を保持してコピーを分析します。ログの時刻が異なるときは、タイムゾーンと端末の時刻ずれも記録します。

影響範囲の調査と対外連絡

調査範囲は、感染端末が利用したID、接続先、共有情報を根拠に広げます。

メールでは不審な送信、転送ルール、代理権限を調べます。クラウドストレージでは大量取得、外部共有、公開リンクの作成を追跡します。外部アプリへアクセス権を与えるOAuth同意が不審に追加されていれば、その権限と操作履歴も調査します。VPNや社内サーバーへ接続していれば、接続先での操作記録を関連付けます。

取引先へのなりすまし送信が確認された場合は、受信者へ、対象メールと依頼する対応を具体的に伝えます。公表や報告の判断では、確認済みの事実、影響する可能性のある範囲、調査中の事項を分け、経営、法務、個人情報保護、広報の担当者が内容を揃えます。感染経路や漏えい件数を推測で断定しません。

駆除・再構築と業務再開の条件

業務再開は、端末を起動できるかではなく、攻撃者のアクセス経路を排除できたかで判断します。

保全が済んだ端末は、調査結果に応じて駆除または再構築します。侵害範囲を十分に絞れない場合は、信頼できる構成から再構築する方法を検討します。復元するデータは、暗号化や改変前の世代を選び、必要な検査を済ませてから管理済みの環境へ戻します。

再開条件には、脆弱性の修正、必要な認証情報の交換、不要な権限と連携の解除、監視の復旧を含めます。再構築した端末で不審な通信がないかを追い、再発した場合は端末だけでなくIdP、SaaS、配布基盤の設定へ調査を戻します。対応記録には、実施済みの処置、未解決事項、残る制限、次の判断者を残します。

▶ 関連記事: PCがウイルス感染した時の対処法は?確認手順と駆除の流れを解説

感染が疑われる発生直後60分間における初動対応の標準手順です。

▲ 感染が疑われる発生直後60分間における初動対応の標準手順です。

まとめ

トロイの木馬は、正常なソフトや業務ファイルを装い、情報窃取や遠隔操作へつなげるマルウェアです。警告画面の言葉だけで感染を判断せず、実行した操作と端末・アカウントの記録を調べます。

明日着手するなら、端末隔離の担当者と、主要SaaSのセッションを切断できる管理者を一覧にします。感染を疑った際は、ネットワーク隔離、セッション・リフレッシュトークン失効、証拠保全を進め、調査前の初期化を避けます。

本記事の内容に誤り等がございましたら、こちらからご連絡ください。

監修

Admina Team

情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。