EDR製品の見逃しを見逃さない!!カスタムルールの作成手法

• はじめに
• 背景
• EDR製品のカスタムアラート
  • カスタムアラートルールの作成
  • カスタムアラートルールの落とし穴
  • AteraAgentのカスタムアラートルールの作成方法紹介
• 最後に
• Appendix

はじめに

エンドポイントセキュリティの対策として、EDR（Endpoint Detection and Response）製品を導入している組織は多いのではないでしょうか。 EDR製品を導入することによって、既存の製品で対処できない攻撃に対して、怪しい挙動を監視し不審な兆候を検知するだけでなく、インシデント発生時にはそのログから調査を行うことができます。

しかし、EDR製品を導入しているからといって、当然ですがすべての攻撃に対応できるわけではありません。残念ながら最近の脅威アクターはEDR製品が導入されていることを前提に、EDR製品が「検知できない」あるいは「検知が困難」な攻撃をしてきます。 その手法の一つが、マルウェアではなく、正規の業務ツールを悪用する方法です。

本記事では、攻撃者によって使われる正規の業務ツールのひとつであるRMM（Remote Monitoring and Management）ツールの悪用と検知に焦点をあて、EDR製品の既存の検知ルールでは対応が難しい攻撃を、我々がどのようにカスタムアラート機能を活用し対策を講じているのか、その取り組みを紹介します。

RMM（Remote Monitoring and Management）ツールとは？

RMMツールは、IT管理者やマネージドサービスプロバイダー（MSP）が、組織のITシステムやネットワーク、デバイスをリモートで監視・管理するために使われるソフトウェアの一種です。物理的に端末にアクセスすることなく作業を行えるため、その利便性の高さから多くの組織で使われています。

背景

RMMツールは、保守・運用の現場において広く活用されています。さらに、コロナによるリモートワークの浸透により、通常の業務でもRMMツールが標準的に使われることがあります。しかし近年、APTアクターやランサムウェアアクターがRMMツールを悪用するケースが相次いで報告されています。このような攻撃手法は既にMITRE ATT&CKにおいても戦術の一つとして位置づけられています。 ¹

例えば、2026年2月に公開されたレポートにおいて、イランのAPTアクターと推察されるMuddyWaterの攻撃事例が報告されています。この攻撃者は、SyncroやAteraAgent、Remote Utilities、ConnectWise、SimpleHelpなどのRMMツールを悪用し、中東を主な標的として攻撃を行いました。² この例に限らず、他のAPTアクターにおいても、初期侵入の際に正規のRMMツールを悪用する事例が確認されています。

このRMMツールを悪用する傾向はAPTに限ったものではありません。 過去の事例として、2023年3月以降に出現したランサムウェアアクターであるCactusは、2024年4月までのわずか1年の間に100以上の組織を攻撃しており、その初期侵入・偵察においてAnydeskやSplashtop、SuperOpsなど複数のRMMツールを利用した事例が確認されています。³ RMMツールを悪用しているランサムウェアアクターはCactusだけではなく、BianLianやALPHV、Lockbitなど他にも多く存在しており、攻撃パターンも多岐にわたります。⁴

さらに、詐欺犯も RMMツールを悪用しています。テクニカルサポート詐欺や悪意のあるメールなどさまざまなソーシャルエンジニアリングの手法を駆使して標的にRMMツールをインストールさせ、MEGAなどのクラウドストレージ上でファイルを管理するためのオープンソースツールであるRcloneを遠隔で実行し窃取したデータをアップロードするケースも確認されています。 ⁵

これらの事例が示すように、RMMツールの悪用は特定の攻撃者や攻撃シナリオに限らず、さまざまな脅威で広く見られるようになっています。当社では対策のためRMMツールの悪用事例に関する情報を日々収集し、継続的に情報の整理を行っています。以下のRMMツールは我々が独自にリストアップしているものの一部になりますが、これら以外にもさまざまなツールが悪用されています。

• Action1
• AmmyyAdmin
• AnyDesk
• AteraAgent
• Bluetrait
• ConnectWise
• DWAgent
• Fleetdeck
• GotoHTTP
• LogMeIn
• MeshAgent
• NetSupport
• NinjaRMM（NinjaOne）
• PDQ Connect
• Quick Assist
• Remote Utilities
• RustDesk
• SimpleHelp
• Splashtop
• Sunlogin
• SupRemo
• Syncro
• TeamViewer
• ZohoAssist

ここで問題となるのは、これらのツールが本来、日常的に利用される正規ソフトウェアであるという点です。 そのため、RMMツールの動作をEDR製品の振る舞い検知の仕組みで捉えても、それが正規の利用か攻撃者による悪用かを判断することは極めて困難です。EDR製品が反応しないと、システム内への攻撃者の侵入を許してしまうことになり、そこを起点にサーバーなどの基幹システムが侵害されると、甚大なビジネスインパクトに繋がることが想定されます。

とはいえ、ビジネス上で許可している RMMツール以外が動作することは異常であり、なるべくならEDR製品で反応して一律にリスクあるソフトウェアとして停止して欲しいものです。その点から、 EDR製品のカスタムアラートルール機能を活用し、RMMツールの悪用を前提とした検知・停止の仕組みを検討しました。

EDR製品のカスタムアラート

我々はまず、EDR製品について深く理解することからはじめました。資料を読み漁りつつ検証を重ねることで、一部のEDR製品には検知ルールをユーザー自身でカスタマイズできる「カスタムアラート機能」が備わっていることがわかりました。基本的に既定の検知シグネチャやアラートルールはベンダーによってのみコントロールされており、ユーザー側で検知やブロックをすることはできません。しかし、この「カスタムアラート機能」はベンダーの検知シグネチャやアラートルールとは違い、ユーザーが独自に定義・作成した検知ルールを用いて脅威を検知・ブロックすることができるというものです。CrowdStrike FalconやMicrosoft Defender for Endpoint、SentinelOne、Cybereason EDRなどの代表的なEDR製品にはその機能があります。

ただし、各社製品によって、カスタマイズ性が大きく異なります。例えば、アラートの作成方法や条件指定の方法、対象・範囲（プロセス、ハッシュ、コマンドライン、通信先、ファイルパスなど）、複数条件の組み合わせが可能か、アラート発生時の応答操作で何ができるのかなどがあげられます。とはいえ、対象のEDR製品が持つカスタムアラート機能をフル活用することでデフォルトの検知ルールでは対応が難しいRMMツールを用いる攻撃に対抗することが可能になります。

カスタムアラートルールの作成

ではどうやってカスタムアラートルールを作成すれば良いのでしょうか。まずカスタムアラートルールを作成する際に、検知対象としたいRMMツールの挙動を把握する必要があります。

例えば、攻撃者は RMMツールをインストーラーを使ってインストールする必要があるのか、実行ファイル単体で動作するものなのか、実行時に引数を参照するのか、どのようなプロセス名になるのか、親子関係となるプロセスはあるのか、どのようなファイルやレジストリを操作するのか、どこに通信するのかなどさまざまな挙動に関する情報がカスタムアラートルールを作成するうえで重要となります。さらに、それらの情報をEDR製品がどのように取得できるか、という課題もあります。インストールされた端末上で対象のRMMツールを実行することで、RMMツールの挙動１つ１つがEDR製品によってどのような形式で認知され、ログに出力されるのか確認することができます。そのうえで、この出力結果からカスタムアラートルールを作成する際に使えそうな挙動について検討を行い、場合によっては複数条件の組み合わせも含めて検討する必要があります。

上記をふまえて実際にカスタムアラートルールを作成するにあたり、我々が特に意識した点を2つ紹介します。1点目は、検知対象の網羅性です。例えば、RMMツールの実行ファイル名や、ファイルパスを指定してカスタムアラートルールを作成したと仮定した場合、実行ファイル名やファイルパスが固定化されていて不変の場合はカスタムアラートルールを作成するうえで非常に有効な条件となります。一方で、「a.exe」などにリネームしても問題なく動作する場合はどうでしょうか。検知回避は容易であり、検知の抜け漏れにつながってしまいます。例えば、実行時の引数に固定値が使用されている場合、特定の通信先とだけ通信をする場合、インストール先のフォルダに製品名などの固定値が設定されている場合など、これらの値を条件として使用することで抜け漏れの少ないルールを作成することが可能です。

2点目は、誤検知の極小化です。固定値もしくは変動し難い値を使用してカスタムアラートルールを作成したとしても、選択した値がユニークなものでなく、他のプロセス・アプリケーションで頻繁に使用される値だった場合、大量の誤検知を引き起こす可能性があります。大量の誤検知アラートは業務影響だけでなく、日々アラートの監視を行うセキュリティオペレーターの監視負荷を高めるだけでなく、本来緊急で対応しなければならないアラートが誤検知アラートに埋もれてしまった結果、対応の遅延につながり、結果的に適切な対応ができなかったことから大きな損害を被ることも考えられます。

検知すべき対象を適切に検知し誤検知を起こさないためには、対象プログラムがどのような挙動をするか分析して、EDR製品のカスタムアラートルール機能に実装することが必要です。さらに何度も検証を繰り返すことで、初めてRMMツールを検知するためのカスタムアラートルールを作成することができます。

カスタムアラートルールの落とし穴

このようにしてEDR製品のカスタムアラートルールを作成し、その有効性を検証する中で、様々な落とし穴があることがわかりました。その一つが、検知されたプロセスが再実行されるように設定されている場合でした。

以下に具体例を示します。親プロセスと子プロセスがあり、親プロセスでは子プロセスの状態を監視し子プロセスが起動していなかった場合、子プロセスを起動させるように設定されていたと仮定します。そのうえで、子プロセスがカスタムアラートルールによって検知されるとどうなるでしょうか。まず、子プロセスを検知したアラートが発報されます。次に検知された子プロセスが停止されます。子プロセスが停止されたことを起因に親プロセスが再度子プロセスを起動します。これにより一連の子プロセス起動からカスタムアラートによる検知およびプロセスの停止までの処理が延々と繰り返されることになります。こういった事態に陥ってしまうと、短期間のうちに連続したアラートが大量に発生してしまいます。誤検知ではありませんが、このようなアラートの大量発生が起こってしまうと前述した通り、本来見るべきアラートがノイズに埋もれてしまい緊急で対応しなければならないアラートを見つけることが難しくなってしまいます。カスタムアラートルールを作成する際にはこういった事態を明確に避ける必要があります。

AteraAgentのカスタムアラートルールの作成方法紹介

上記のカスタムアラートルール作成において気を付けるべき点や作成時の落とし穴を考慮しつつ、RMMツールの一つであるAteraAgentを例に、カスタムアラートルールの作成手順を示します。繰り返しとなりますがカスタムアラートルールを作成するために、まずは検知対象となるAteraAgentの挙動の確認とEDR製品からのログの検知・出方を確認する必要があります。EDR製品が導入されたクライアント端末上でAteraAgentをインストールし実行することで、その挙動とEDR製品から出力されたログを確認し、どの値がカスタムアラートルールの条件として活用できるか、特徴の洗い出しを行います。

まずはAteraAgentのインストーラーの挙動とそのログを見てみましょう。以下のように「msiexec.exe」 を起動し引数にAteraAgentの「setup.msi」を指定してインストールのための処理を行っていることがわかります。

"C:\Windows\System32\msiexec.exe" /i
"C:\Users\adminuser\Desktop\AteraAgent\setup.msi" 

その後、msiexec.exeを親プロセスとして、インストール先のフォルダに設置された「AteraAgent.exe」を子プロセスとして実行します。なお、「msiexec.exe」の子プロセスとしてAteraAgent.exeが実行されるのはインストールされたタイミングのみで、インストール後はサービスプロセスとして登録され、「service.exe」の子プロセスとして実行されます。

"C:\Program Files (x86)\ATERA Networks\AteraAgent\AteraAgent.exe" /i /IntegratorLogin="test@outlook.com" /CompanyId="1" /IntegratorLoginUI="" /CompanyIdUI="" /FolderId="" /AccountId="001Q300000Hd8jTIAR" /AgentId="3f5c7deb-bb97-4b52-ab2f-d44e4cbdde35" 

「AteraAgent.exe」というファイル名や「ATERA Networks」、「AteraAgent」というディレクトリ名など一部のユニークな値を使用していることがわかります。これらの値を用いてカスタムアラートルールが作成できそうです。

次に、AteraAgentのファイルプロパティの [Recovery]タブを見てみましょう。サービスの起動失敗時に再起動を試みる設定になっています。

単純なカスタムアラートを作成し、該当プロセスをEDR製品で停止してしまった場合、前述したカスタムルールの落とし穴にはまってしまい、大量のアラートが延々と発生してしまう恐れがあることがわかりました。

これらを踏まえて、カスタムアラートルールを作成するための情報を整理してみましょう。

• 「AteraAgent.exe」、「ATERA Networks」、「AteraAgent」といった固有のファイル名、フォルダ名を使用している
• インストール時、AteraAgent.exeはmsiexec.exeの子プロセスとして起動される
• インストール後はサービスに登録されAteraAgent.exeはservice.exeの子プロセスとして起動される
• サービス起動失敗時には、再起動する設定になっている

これらの情報を考慮し、サービスとして起動するAteraAgentはアラートの大量発生を引き起こす可能性が高いため、検知対象外とし、まずはインストール時のAteraAgentを検知するカスタムアラートルールを作成します。

項目	値（正規表現）
検知トリガー	Proceess作成
ファイルパス	.*\AteraAgent.exe
親プロセス	.*\msiexec.exe

このルールを有効化することで、AteraAgentのインストール時に実行されるAteraAgent.exe を検知し停止することが可能となります。既にインストールされてしまったAteraAgentはアラートの大量発生を引き起こしてしまうため、検知対象にしたい場合にはまた別のアプローチが必要となりますが、今回は作成例ということもありインストール時にのみ検知できるような特別なカスタムアラートルールの作成方法をご紹介しました。このように慎重に１つ１つ、カスタムアラートルールを作成していくことによって、EDR製品のデフォルトルールで検知し難いRMMツールを用いた攻撃も検知・対策することが可能となります。

最後に

本記事ではEDR製品のデフォルト検知ルールでは対応し難い脅威であるRMMツールを用いた攻撃に絞って、ブルーチームとしてどう対応しているのか、その取り組みの一例を紹介しました。

我々がカスタムアラートルールを作成する際には、検証環境でRMMツールの挙動を確認し、操作ログから得られた挙動の不変箇所を抽出して検知方針の検討を行っています。「ルールを作ったら終わり」ではなく、その後も分析官がアラートの監視・継続的な評価・必要に応じてルールや運用の見直しを行っています。業務を止めないという点を最優先事項とし、ブルーチームとしてこのようなサイクルで脅威の検知を目指しています。

EDR製品に限らずセキュリティ製品には検知性能に揺らぎがあり、得意な分野もあれば苦手な分野もあります。一方で、製品によっては今回紹介したようなカスタムアラートルールのように、ある程度ユーザーの知見を検知のために反映できる機能があり、これらを有効活用することでその製品が苦手な分野を克服することが可能になります。また、環境にあわせたカスタムアラートルールを作成することで、さらに効果的に各製品を活用できるようになります。導入した製品の効果を高めていく、そういった姿勢もブルーチームの役割であるといえます。

近年はRMMツール以外にも、DFIR（Digital Forensics and Incident Response）ツールを悪用した攻撃が確認されています。EDR製品が見逃しがちな脅威は日々増加しており、攻撃者もさまざまな手法を用いて攻撃を行ってきています。もし高額な製品・サービスを使っているけれどカスタム機能を活かしきれていないという組織があれば、その性能を十二分に活かし対策につなげていただく機会となれば幸いです。

Appendix