「怪しいファイルが見つからないから、感染していない」とは限りません。
ファイルレスマルウェアは、マルウェア本体をディスクに直接保存せず、PowerShellなどの正規ツールに悪意あるコードを読み込ませて、メモリ上で実行するタイプです。

ファイルレス
マルウェアの概要と対策
ここでいう「ファイルレス」は、ファイルを一切使わないという意味ではありません。
攻撃の中心となるコードが、一般的な実行ファイルとして残りにくいのです。(侵入のきっかけとなるメールや文書が残る場合もあります。)
この記事では、ファイルレスマルウェアの特徴と問題点を整理します。
そのうえで、検知、ログ、認証情報、横展開という問題ごとに対策を見ていきます。
特に、横展開を止めるうえで重要な管理者権限の守り方を詳しく解説します。
ファイルレスマルウェアとは?
一般的なマルウェアは、実行ファイルやライブラリなどを端末に保存し、それを起動して動作します。
一方、ファイルレスマルウェアは、OSに標準搭載された機能や、すでに端末にある正規のツールを利用してコードを実行します。
代表的なものがPowerShellです。
PowerShellはWindowsの管理や自動化に使われる正規の機能ですが、攻撃者がコマンドの実行、追加コードの取得、認証情報へのアクセス、横展開に悪用することがあります。
WMI(Windows Management Instrumentation)も同様です。
WMIはWindowsのシステム情報を取得したり、管理操作を行ったりする仕組みです。
ローカルだけでなく、リモートのシステムに対する操作にも利用できるため、攻撃者によるコマンド実行や横展開に悪用されることがあります。
「完全にファイルがない」とは限らない
ファイルレスマルウェアに関して、「端末にファイルがまったく存在しない」と理解すると、実態を見誤ります。
最初の侵入に使われたメールの添付ファイル、Office文書、スクリプトが残ることもあります。
また、レジストリやタスクスケジューラなどに、再起動後も動作させる設定が残される場合もあります。
したがって、見るべきなのはファイルの有無だけではありません。
どのプロセスが何を起動したのか、どのアカウントが実行したのか、外部や社内のどこへ通信したのかを確認する必要があります。
「実行の中心部分がディスク上の通常の実行ファイルとして残りにくい」のです。
一般的なマルウェアとの違い
セキュリティ対策の世界では、「ファイルレス」として区別して考えることがあります。
| 観点 | 一般的なマルウェア | ファイルレス |
|---|---|---|
| 主な実行方法 | 実行ファイルなどを保存して起動 | メモリ上や正規ツールを利用して実行 |
| 調査の手がかり | ファイル、ハッシュ、保存場所 | プロセス、コマンド、ログ、通信 |
| 検知の考え方 | ファイルの特徴を調べる | 実行時の挙動を調べる |
| 痕跡 | ファイルとして残ることがある | 本体が通常のファイルとして残りにくい |
ファイルレスマルウェアの問題点と対策
ファイルレスマルウェアの問題は、「見つけにくい」ことだけではありません。
正規機能を悪用されるため判断が難しく、認証情報を足がかりに別の端末やサーバーへ広がる可能性もあります。
まず、問題点と対策の全体像を確認しましょう。
| 整理 | 問題点 | 主なリスク | 対策の考え方 |
|---|---|---|---|
| 1 | ウイルス対策ソフトで見つけにくい | 不正なスクリプトや正規ツールの悪用を見逃す | ファイルではなく挙動を監視する |
| 2 | 痕跡が少ない | 原因究明や被害範囲の特定が難しい | ログを十分に残し、改ざんされにくく保管する |
| 3 | 正規の機能を悪用される | 正常な管理操作と攻撃を区別しにくい | 実行者、親プロセス、コマンド、通信先を記録する |
| 4 | 認証情報や機密情報を盗まれる | アカウント乗っ取りや情報漏えいにつながる | MFA、認証情報保護、権限分離を行う |
| 5 | 横展開される | サーバー侵害、管理者権限の悪用、ランサムウェア被害につながる | 最小権限、ネットワーク分離、管理経路の保護、異常検知を行う |

1. ウイルス対策ソフトで見つけにくい問題への対策
ファイルレスマルウェアでは、攻撃者がPowerShellやWMIのような正規機能を使うため、ファイルの特徴だけを調べる対策では不十分になることがあります。
IPAも、ファイルレスマルウェアや未知のマルウェアへの対策として、端末の不審な挙動を監視するEDRが有効となる可能性を示しています。
対策の考え方は以下です。
- EDRなどでプロセスの挙動を監視する
- PowerShell、WMI、Script Hostなどの利用状況を記録する
- OfficeやブラウザからPowerShellが起動するなど、不自然な親子関係を検知する
- 外部サイトから取得したスクリプトの実行を制限する
- 使っていないスクリプト機能やマクロを無効化する
- アプリケーションの実行を許可リスト方式で制限する
PowerShellを一律に禁止すると、管理業務に支障が出る可能性があります。
業務上必要な利用を把握したうえで、実行者、親プロセス、コマンド、通信先を組み合わせて判断することが現実的です。
2. 痕跡が少ない問題への対策
攻撃の本体がファイルとして残りにくいと、感染後の調査が難しくなります。
いつ侵入されたのか、何が実行されたのか、どの情報が持ち出されたのか、ほかの端末に広がったのかを追跡できないためです。
そこで、端末だけでなく、複数の場所からログを集めます。
- Windowsのログオンとプロセス作成
- PowerShell
- WMI
- DNS
- プロキシ
- VPN
- ファイアウォール
- クラウドサービスの認証ログ
- ファイアウォールやEDRのアラート
- サーバー上の管理操作ログ
ログは、攻撃者が侵入後に削除・改ざんできないよう、別のログサーバーやSIEMに転送して保管することが重要です。
保存期間や取得項目は、定期的に見直しましょう。
3. 正規の機能を悪用される問題への対策
PowerShellやWMIは、管理者や開発者が日常的に使う正規の機能です。
そのため、「PowerShellが実行された」という事実だけでは、攻撃と断定できません。
判断には、誰が、いつ、どの端末から、どのようなコマンドを、どのプロセス経由で実行したのかという情報が必要です。
たとえば、管理者が管理専用端末から定められた手順で実行した操作と、一般利用者の端末で文書を開いた直後にPowerShellが起動したケースでは、意味が大きく異なります。
- 実行者を確認する
- 誰のアカウントで実行されたか
- そのユーザーに業務上の必要性があるか
- 通常とは異なる端末や時間帯からの操作ではないか
- 実行内容を確認する
- 難読化された長いコマンドではないか
- 外部サイトからコードを取得していないか
- メモリ上で別のプログラムを起動していないか
- 認証情報やブラウザデータにアクセスしていないか
- 実行経路を確認する
- メール添付ファイル → スクリプト
- Office → PowerShell
- ブラウザ → コマンドシェル
- 一般ユーザーのアプリ → 管理者用ツール
- 端末 → 複数のサーバーへの管理接続
「どのツールが使われたか」だけでなく、「誰が、何を、どの経路で実行したか」を確認することが対策の軸になります。
4. 認証情報や機密情報を盗まれる問題への対策
ファイルレス攻撃は、端末上で長く活動すること自体が目的とは限りません。
パスワード、認証トークン、VPNの認証情報、ブラウザに保存された情報、クラウドサービスのセッション情報などを盗み、次の攻撃につなげる場合があります。
対策の基本は、認証を強くし、盗まれた場合の被害を小さくすることです。
- 認証を強化する
- MFAを導入する
- 特に管理者アカウントでは、パスワードだけの認証を避ける
- 管理者用アカウントと一般利用アカウントを分ける
- 長期間使われていないアカウントを無効化する
- 退職者・異動者の権限を速やかに見直す
- 認証情報を端末に残しにくくする
- ブラウザへのパスワード保存を業務ルールに合わせて制限する
- 共有アカウントを避ける
- サービスアカウントのパスワードを定期的に更新する
- 秘密情報をソースコードやスクリプトに直接書かない
- 端末の認証情報保護機能を有効にする
- 盗まれた後を想定する
- 短時間で期限切れになるトークンを使う
- 端末や場所に応じたアクセス制御を行う
- 異常な国・地域・端末からのログインを検知する
- 重要操作には追加認証を要求する
認証情報は、盗まれないようにするだけでなく、盗まれても被害を限定できるようにします。
5. 横展開される問題への対策
横展開とは、最初に侵入した端末を足がかりに、社内の別の端末、ファイルサーバー、業務サーバー、クラウド環境へ移動することです。
攻撃者は、侵入した端末にある認証情報や接続履歴を調べ、アクセスできる範囲を広げようとします。
ここで重要なのは、最初からネットワーク全体の管理者権限を奪われるとは限らない点です。
一般利用者の権限でも、ファイルサーバーや業務システムへのアクセス権があれば、次の侵入の手がかりになります。
そのため、管理者権限を厳格に管理するだけでなく、一般端末から重要サーバーへ自由に到達できない構成にすることが必要です。

対策の中心は、最小権限、管理者アカウントの分離、ネットワーク分離、管理接続の制限です。
- 最小権限にする(ユーザーやサービスには、業務に必要な範囲だけ権限を与えます。)
- 一般ユーザーにローカル管理者権限を与えない
- サーバー管理権限を通常業務用アカウントに付与しない
- ファイルサーバーの閲覧権限を必要な部署に限定する
- 管理者権限をグループ単位で広く配布しない
- 使われていない管理者アカウントを削除、無効化する
- 管理者アカウントを分離する(管理者は、通常業務と管理作業で別のアカウントを使います。)
- 通常メール、Web閲覧用のアカウント
- サーバー管理専用アカウント
- ドメイン全体を管理する非常に強い権限のアカウント
- 特権IDを厳格に管理する(特権ID、つまり管理者権限を持つアカウントについては、次の管理が有効です。)
- 利用者を限定する
- 利用目的と承認者を明確にする
- 使用履歴を記録する
- 可能であれば一時的にだけ権限を付与する
- パスワードを保管庫で管理する
- 定期的に棚卸しする
- 共有管理者アカウントを避ける
- 管理経路を分離する(管理者が普段使うPCから、すべてのサーバーへ自由に接続できる状態は危険です。)
- 管理専用端末を用意する
- 管理用ネットワークを分ける
- 管理接続元を限定する
- サーバー間の不要な通信を遮断する
- インターネットから管理画面へ直接接続させない
- RDP、SSH、WinRMなどの管理プロトコルを接続元制限する
- ネットワークを分割する
- 管理者権限の利用を監視する
なぜ管理者権限が特に危険なのか
管理者権限を奪われると、攻撃者が複数の端末やサーバーに影響を広げやすくなります。
たとえば、セキュリティ設定の変更、管理者アカウントの追加、サーバー上のデータへのアクセス、ログやバックアップへの攻撃などにつながる可能性があります。
強い権限ほど被害の範囲を広げるリスクが高いため、利用者、端末、時間、接続先を限定する必要があります。
管理者権限と横展開を防ぐ方法
まず、一般利用者にローカル管理者権限を常時与えないようにします。
管理者は、メールやWeb閲覧に使う通常アカウントと、サーバー管理に使う特権アカウントを分けます。
特権アカウントでは、通常業務のメール閲覧やWeb閲覧を行わない運用が基本です。
次に、管理経路を限定します。
管理専用端末を用意し、管理用ネットワークを分け、RDP、SSH、WinRMなどの接続元を必要な端末に絞ります。
一般利用者の端末から、重要サーバーへ直接管理接続できない構成にすると、1台が侵害されたときの被害を抑えやすくなります。
さらに、管理者グループへの追加、新しい管理者アカウントの作成、短時間での複数サーバーへのログオン、普段と異なる端末からの管理操作を監視します。
管理者権限を取得されないことが第一ですが、取得を前提に異常を検知する設計も欠かせません。
対策を「予防」「検知」「被害限定」「復旧」で整理する
ファイルレスマルウェアへの対策は、侵入を完全に防ぐ一つの方法に依存しないことが大切です。
侵入前、侵入後、被害発生後のそれぞれで、役割の異なる対策を組み合わせます。
| 段階 | 主な対策 |
|---|---|
| 予防 | 最小権限、多要素認証、アカウント分離、OSやアプリの更新、不要なマクロやスクリプトの制限 |
| 検知 | EDR、PowerShellやWMIのログ、異常な認証、管理者グループの変更、社内の不自然な通信の監視 |
| 被害限定 | ネットワーク分離、管理経路の制限、サーバー間通信の絞り込み、バックアップの分離 |
| 復旧 | 端末の隔離、認証情報の無効化と変更、管理者セッションの失効、原因調査、クリーンなバックアップからの復旧 |
この整理で大切なのは、検知と被害限定を予防と同じくらい重視することです。
高度な攻撃をすべて入口で止めるのは簡単ではありません。
侵入されても管理者権限へ進ませず、重要サーバーへ到達させず、早期に隔離できる設計が現実的な防御になります。
企業が確認したいチェックリスト
最後に、実際の運用で確認したい項目をまとめます。
すべてを一度に導入する必要はありません。
まずは、管理者権限を持つアカウントと、そのアカウントが接続できる端末やサーバーを把握するところから始めると、優先順位をつけやすくなります。
アカウントと権限
- 一般利用者に不要な管理者権限を与えていない
- 通常業務用アカウントと管理用アカウントを分けている
- 特権アカウントの利用者と利用目的を把握している
- 管理者グループの変更を記録し、通知できる
- 重要アカウントに多要素認証を設定している
端末と実行制御
- EDRなどで端末の挙動を監視している
- PowerShellやWMIの実行ログを取得している
- Officeマクロや不要なスクリプトの実行を制限している
- OS、ブラウザ、Office、セキュリティ製品を更新している
- 文書やブラウザから不自然なプロセスが起動していないか確認できる
ネットワークとサーバー
- 一般端末から重要サーバーへの接続を必要最小限にしている
- 管理用ネットワークや管理専用端末を分けている
- RDP、SSH、WinRMなどの接続元を制限している
- バックアップを通常の攻撃経路から分離している
- 短時間に複数のサーバーへ接続する動きを検知できる
監視と復旧
- 端末だけでなくログサーバーやSIEMにもログを保存している
- VPN、クラウド、DNS、プロキシのログを確認できる
- 端末隔離と認証情報変更の手順が決まっている
- 侵害が疑われる管理者セッションを失効できる
- クリーンなバックアップから復旧できることを定期的に確認している
まとめ: ファイルを探すだけでは、攻撃の全体像は見えない
ファイルレスマルウェアは、「ファイルがないマルウェア」ではありません。
攻撃の中心となるコードが、通常の実行ファイルとしてディスクに残りにくいマルウェアです。
そのため、ファイルの有無だけを確認しても、安全とは判断できません。

必要なのは、プロセスの親子関係、実行者、コマンド、認証、通信先を組み合わせて見ることです。
EDRやログ監視は検知を助けますが、それだけで完結するものではありません。
多要素認証、最小権限、アカウント分離、ネットワーク分離を組み合わせることが重要です。
特に横展開への備えでは、管理者権限を必要な人、端末、時間に限定することが出発点になります。
一般端末から重要サーバーへ自由に到達できないようにし、管理者権限の利用と異常な接続を監視します。
この積み重ねが、1台の侵害を組織全体の被害へ広げないための現実的な対策です。

ご意見やご感想などお聞かせください! コメント機能です。