- 2020 年以降、AnyDesk や TeamViewer といったリモートシステム管理ツール/デスクトップアクセスツールの人気が高まっています。こうしたソフトウェアには正しい使い道が数多くあるのですが、攻撃のコマンドアンドコントロールとして悪用する方法も見つかっています。
- 無許可のリモート管理ツールすべてを効果的にブロックする簡単な方法はありませんが、ポリシーと技術的な制御を組み合わせることでセキュリティを大幅に向上させることができます。
- 早期警告アラートを設定することで、技術的な制御を回避した可能性のあるリモート管理ソフトウェアのアクティビティを防御担当者に警告できます。
リモート管理/アクセスソフトウェアの問題
2020 年以降、コロナ禍による在宅勤務に伴い、AnyDesk や TeamViewer といったリモートシステム管理/アクセスツールの使用が爆発的に増加しました。
IT ヘルプデスク技術者がユーザーのリモートシステムを修復するために使用する場合でも、同僚同士がコラボレーション目的で使用する場合でも、これらのツールはほとんどの企業のデジタル機能で重要な役割を果たしています。ただし、この利便性には代償が伴います。これらのツールを使用すれば、攻撃者はシステムを完全にリモート制御できます。ツールのダウンロードとインストールは簡単であり、合法的なソフトウェアとみなされるので、検出が非常に困難になることがあります。
悪意のある目的でツールが使用されているかどうかを判別する作業はさらに複雑になります。多くの組織は「シャドー IT」との闘いに苦慮しています。個々のユーザーや積極的すぎる IT 担当者が、安全な用途で使用する目的で無許可のリモート管理ツールをインストールする可能性があるのです。
Talos インシデント対応チーム（Talos IR）は、攻撃者がこうした機会を実際に悪用しているのを目の当たりにしています。Talos は 2023 年第 3 四半期の四半期動向レポートで、「ランサムウェアおよびランサムウェア感染前のインシデント対応業務のすべてで AnyDesk が確認されており、ランサムウェアの攻撃チェーンにおける AnyDesk の役割が明確になっています」と報告しています。
AnyDesk は合法的なアプリケーションですが、こうしたツールの不正使用を防ぐことに重点を置いたセキュリティプログラムによって大きな価値が得られるということがわかります。このブログ記事では AnyDesk を取り上げていますが、他のリモート管理ツールも悪用のリスクにさらされています。導入された AnyDesk や類似のソフトウェアが正当な目的にのみ使用されるように、ポリシーの変更、技術的な対策、セキュリティアラートに関して管理者と防御担当者が打てる手がいくつかあります。
ポリシー変更の提案：承認済みのリモート管理ツールを 1 つ選択する
承認済みのリモート管理ソリューションを 1 つ（多くても 2 つ）採用すれば、徹底的にテストを行ったうえで、可能な限り安全な設定で導入できます。
可能な場合は、Active Directory や多要素認証（MFA）など、組織で導入している他のテクノロジーと統合することで、保護と検証が強化されます。承認済みのリモート管理ソリューションと、すでに構築されているセキュリティソリューションを連携させると、不正アクセスや不正使用に関する「早期警告」の検出とアラートの構築が容易になります。
組織で特定のソリューションを承認して推進しているのであれば、その他のリモート管理/アクセスツールはポリシーで明示的に禁止する必要があります。理想としては、これに加えて、ソフトウェアインベントリ監査を行い、組織の承認済み/未承認ソフトウェアに関するガイダンスを公開したほうがよいでしょう。このポリシーについてトレーニングを行い、一貫してポリシーを実施することで、環境内の「シャドー IT」によるノイズが減少し、ネットワーク防御担当者が真の異常の調査にもっと時間をかけられるようになります。
技術的な制御
これらのツールの不正使用を防ぐことには大きな価値がありますが、簡単なことではありません。まず、市販されているリモートアクセスツールの数が多いので、攻撃者が使用する可能性のあるすべてのツールに対処することは困難です。ツールの多くは頻繁に更新されるため、ハッシュ値で実行ファイルをブロックしてもさほど効果はありません。
また、多くの場合、実行ファイルの名前も変更されます。つまり、ファイル名でのブロックも役に立たないということです。
よく利用されるソリューションの多くは、一般的なポート（80 や 443 など）とプロトコルで動作するため、ファイアウォールでブロックすることは困難です。さらに、リモートアクセスツールの作成者は、頻繁に名前解決が行われるので中央管理サーバーの IP アドレスの公開を拒否することが多く、静的 IP アドレスブロックの効果にも限界があります。攻撃者が特定の環境でリモートアクセス/管理ツールを使用する機会を制限するには、アプローチと手法を組み合わせなければなりません。
DNS セキュリティ管理
無許可のリモート管理/アクセスソフトウェアのアクティビティを検出し、場合によってはブロックするための最も効果的な方法の 1 つは、これらのツールに関連付けられた DNS クエリを監査してブロックすることです。
DNS セキュリティに Cisco Umbrella が使用されている場合、不正なトラフィックに関連する DNS クエリを確認してブロックするのは非常に簡単です。
ネットワーク上にすでに存在する可能性のあるものを確認するには、Cisco Umbrella コンソールにログインし、[レポート（Reporting）] > [アプリケーションの検出（App Discovery）] > [未確認のアプリケーション（Unreviewed Apps）] の順に表示して「コラボレーション」と「IT サービス管理」カテゴリでフィルタ処理します。これは、予期しないリモート アクセス ソフトウェアを特定するための優れた開始点となります。
[このアプリケーションをブロック（Block this app）] をクリックするだけで、以降は、特定の結果に関連付けられた DNS リクエストをブロックできます。さらに積極的なアプローチをとりたい場合は、[ポリシー（Policies）] > [ポリシーコンポーネント（Policy Components）] > [アプリケーション設定（Application Settings）] で、ネットワーク上に表示されたかどうかに関係なく、現在 Cisco Umbrella によって分類されているすべてのアプリケーションを検索し、ポリシーでブロックできます。繰り返しになりますが、「コラボレーション」と「IT サービス管理」カテゴリは、ポリシーを確認する際の重点領域となります。
こうした技術的な制御には、いくつかの制限があります。まず注意しておくべき重要なポイントは、DNS クエリはセキュリティスタックによって評価された場合にのみ機能するということです。ホームユーザーのシステムからの DNS トラフィックが企業のネットワークを経由しない場合、アクティビティを把握することはできません。次に注意が必要な重要ポイントは、リモート管理ソフトウェアの中には、直接的なピアツーピア接続を確立できるものがあるということです。つまり、接続を開始する際に、簡単に特定できるドメインには DNS クエリが送信されない場合があります。
ファイアウォールによる制御
基本的な IP アドレスのブロックは、拡張性や信頼性は劣りますが、無許可のリモートソフトウェアの接続を防ぐのに役立ちます。一部のベンダーは、こうしたアクセスを制御するために利用できる中央管理サーバーの静的 IP アドレスをサポートサイトにリストしています。ただし、多くのベンダーの IP アドレスは定期的に変更されるため、この作業にも少々手間がかかります。
ファイアウォールでトラフィックをブロックするもう 1 つの効果的なアプローチは、ポート番号を指定するというものです。たとえば TeamViewer では、事実上ブロックすることのできないポート 443 への変更も可能ですが、ポート 5938 が優先的に使用されます。ポート 5938 をブロックしても接続は停止されませんが、アラートを適切に設定していれば、TeamViewer が接続しようとしていることを防御担当者に早期に警告できます。
ファイアウォールの中には、Cisco Umbrella の機能に似た、セッションコンテンツに関する追加機能を提供するものもあります。Cisco Meraki のようなファイアウォールでは、未承認のリモート管理ソフトウェアサイトへの接続を防ぐために許可/ブロック URL リストを設定できます。Cisco Meraki は、リモート管理/アクセスサイトのブロックに役立つコンテンツフィルタリング オプションを提供します。
無許可のリモート管理ソフトウェアの接続をファイアウォールで制御する場合、意図しない結果が生じる可能性があります。このことを考慮し、管理者は導入前に綿密なテストと試験運用を行う必要があります。
コンテンツ デリバリ ネットワーク（CDN）ノードやその他のクラウドコンピューティング共有リソースをブロックしてしまわないように、ブロックする前に IP アドレスがそのアプリケーション専用であることを確認してください。
最後に、無許可のリモート管理ソフトウェアの使用をブロックするには、ネットワーク セグメンテーションまたはマイクロセグメンテーションが役立ちます。たとえば、サーバーリソースをワークステーションリソースとは別に分類して整理することで、リモート管理ツールに関連付けられている可能性のあるトラフィックを含め、ファイアウォールですべての不要なトラフィックをブロックするための、よりカスタマイズされたオプションを設定できるようになります。グループポリシーの設定と統合することで、これをうまく実践している組織もあります。
ホストベースの制御
Windows Defender Application Control（WDAC）と AppLocker
この記事で取り上げた制御の中で、無許可のリモート管理/アクセスソフトウェアの実行に対してほぼ 100% の保護を提供できるのは、WDAC と AppLocker だけです。
事前に承認されたソフトウェアのみの実行を許可するという最も安全な設定では、ユーザーも攻撃者も、予期しない実行ファイルを実行することはできません。ただし、これには代償が伴います。承認済みのソフトウェアの基本メンテナンスの作業負荷が高くなる可能性があり、さらに、必要な場合にアプリケーションのインストールが許可されないと、ユーザー体験が大幅に制限されると考えられるからです。
WDAC と AppLocker ではポリシーに十分な柔軟性が提供されるので、ドメインコントローラなどの重要なサーバーのみをロックダウンすることで、より柔軟なユーザーシステムポリシーを実現している組織もあります。この方法では、単にリモートアクセス/管理ソフトウェアをブロックするだけでなく、ほとんどのマルウェアの実行も阻止できるため、大きなメリットがあります。
WDAC は現在、以前より設定が難しくなっていますが、機能が高度化しています。Microsoft 社では WDAC を AppLocker の代替製品と位置付けています。現時点では、AppLocker のセキュリティ更新プログラムは提供されていますが、新しい機能の更新はありません。
レジストリファイル名によるブロック
レジストリの「DisallowRun」キーを使用して、ファイル名でソフトウェアのリモート管理/アクセスをブロックすることができます。ただし、Talos IR では、インシデント対応時の封じ込め対策の場合を除き、この方法を推奨していません。予防策としては拡張性に乏しく、実行ファイルの名前を変更したり、レジストリを変更したりすることで簡単に回避できてしまうからです。
EDR によるブロック
最新のほぼすべての EDR はファイルハッシュをブロックできるので、リモート管理/アクセスソフトウェアのインストーラやインストールされた実行ファイルに関連付けられているハッシュをブロックすることが可能です。ただし、ファイル名 GPO のブロックと同様、どのソフトウェアでも新しいバージョンが配布される場合には新しいハッシュ値が設定されるため、事前対策としては拡張性や信頼性に欠けています。この措置は、インシデント対応時の封じ込めに限定したほうがよいでしょう。
一部の EDR ソリューションは、脆弱なソフトウェアや無許可のソフトウェアをブロックする機能を備えていますが、それらの機能に関する制限事項には重大な注意事項も含まれています。この記事を執筆するにあたり、実際に機能をテストしたわけではありませんが、完全を期すために上記の点をお伝えしておきます。
ホストベースのファイアウォール
ホストベースのファイアウォールルールの推奨事項は、上で説明したスタンドアロン ファイアウォールとほぼ同じです。在宅ワーカーが企業 VPN をオフにしている場合や、スプリットトンネル VPN 実装を使用している場合など、ユーザーが企業ネットワークの境界外をローミングすることを管理者が想定している場合に役立ちます。
管理者権限の制限
管理者権限を制限し、ほとんどのユーザーが職場のコンピュータでリモートアクセス/管理ソフトウェアのインストールなどの管理者操作を行えないようにします。これにより、最初の不正アクセス後に攻撃者がソフトウェアをインストールしようとしても、機能が制限されます。
最小権限の原則、つまり、ローカル管理者権限をロックし、ユーザーのドメインアカウントの権限を制限することが、標準的なベストプラクティスと考えられています。
NAC の制御
ネットワーク アクセス コントロール（NAC）ソリューションでは、リモート管理ソフトウェアの使用は直接ブロックされませんが、特定のエンドポイントをネットワークに許可する前に、他のすべての技術的な制御が適切に機能しているかどうかを確認できます。たとえば、デバイスが不正システムである場合や、EDR を備えていない場合、NAC はそのデバイスの接続を防止します。
NAC ソリューションのもう 1 つの利点は、カスタムルールを使用して、要件を満たさないバージョンのソフトウェアを制限できるということです。たとえば、Cisco ISE にはポスチャチェックがあります。これを使用して、承認済みのリモート管理ツールの承認されたバージョンのみがネットワーク上で許可されるようにし、承認済みのソリューションの古いバージョンを悪意のある目的でネットワークに導入するという脅威に直接対処できます。
アラートとフォレンジック
これらすべての制御を導入すると複雑になってしまうので、攻撃者が上に挙げた緩和策を回避する方法を見つけた場合のバックアップとして検出ルールを活用できます。こうした「トリップワイヤ」検出の可能性は無限であり、SOC や脅威ハンティングチームは継続的に改善策を考える必要がありますが、以下のとおり、いくつかのアイデアがあります。
一元的なログ収集
検出を成功させるための最初の前提条件は、一元的にログを集約することです。少なくとも、主要サーバーのファイアウォールログ、EDR アラート、および Windows イベントログを取り込む必要があります。
不審な文字列に対するセキュリティ情報イベント管理（SIEM）アラート
無許可のリモートアクセス/管理ソフトウェアの製品名（「AnyDesk」など）に関連付けられている文字列を検出したときに出されるシンプルなアラートを設定することは、他の方法ではブロックされなかった予期しない製品のインストールをプロアクティブに特定する効果的な方法です。
たとえば、メディア サービス インターフェイス（MSI）のインストールでは、ソフトウェア製品名を含むイベントエントリ 11707 が Windows アプリケーション イベントログに生成されます。これらのイベントログが SIEM に取り込まれて評価されている状態になると、アラートが発生し、インストールの可能性について SOC に警告します。このルールは、過剰な誤検出を避けるために調整する必要がありますが、早期検出を実現する貴重な方法になり得ます。
ファイアウォールが一意のポートをブロックした際の SIEM アラート
リモート管理/アクセストラフィックに関連するファイアウォールブロックに SOC の注意を向けるには、アラート機能を強化しなければならない場合があります。ファイアウォールは継続的にトラフィックをブロックし、通常は 1 時間あたり数千または数百万のパケットをドロップします。つまり、ファイアウォールルールがトラフィックをドロップするたびに SOC にアラートが送信されるようにはなっていません。特に、トラフィックをドロップするルールが、明示的に許可されていないすべてのトラフィックをブロックする「Implicit Deny」ルールである場合は、その都度アラートを受け取っても仕方ありません。ただし、内部ホストがリモートアクセス/管理ソフトウェア専用のポートを介して通信しようとした場合は、SOC の注意を要するかもしれません。
特定の主要ポート（TeamViewer に関連付けられている 5938 など）へのアウトバウンドトラフィックに関係するファイアウォール ブロック イベントに対してアラートを出す SIEM ルールの作成を検討できます。このアラートが出た場合、ネットワークブロックが意図したとおりに機能しているということになりますが、トラフィックの発信元のシステムを SOC が調査したほうがよいということにもなります。
リモート管理/アクセスソフトウェアを適切に保護するためには、かなりの労力が求められますが、攻撃者によって頻繁に使用されることを考慮すると、その労力はどうしても必要なものだと言えます。こうしたツールは、攻撃者の手に渡れば、既成の C2（コマンドアンドコントロール）メカニズムとして機能します。VPN ソリューションのセキュリティに投資する余裕がある場合は、無許可のリモート管理ソフトウェアのロックダウンにもリソースを投入したほうがよいでしょう。
本稿は 2024 年 04 月 02 日に Talos Group
のブログに投稿された「Adversaries are leveraging remote access tools now more than ever — here’s how to stop them
Authors