lightbulbs in combat
セキュリティ運用

** 本記事は、RD Web Access abuse: Fighting back の翻訳です。最新の情報は英語記事をご覧ください。**

2024 年に入ってから Sophos X-Ops の MDR (Managed Detection and Response) チームは、多要素認証 (MFA) 保護を導入していない Microsoft リモートデスクトップ Web アクセスのポータルが公開されていたために初期アクセスの経路に悪用されたインシデントに複数対応してきました。本記事では、このようなポータルが悪用された場合に何が起きるのかを概説します。そして、ソフォスの調査がどのように行っているかを解説し、同様の事態に遭遇する可能性のある組織に向けて推奨事項および緩和策をご紹介します。

RD Web Access ポータルとは

Microsoft リモートデスクトップサービスのアーキテクチャは、複数の異なるロールで構成されています (図 1 参照)。

A screen capture showing six distinct roles within the RDA architecture

図 1: 公開されている Remote デスクトップサービス (RDS) ホストにインストールされているロールの例

  • リモートデスクトップ接続ブローカー (RD Connection Broker) ロールは、RD Session Host サーバーファームへのリモートデスクトップ着信接続を管理し、接続を適切なホストにルーティングします。
  • リモートデスクトップゲートウェイ (RD Gateway) ロールは、パブリックネットワーク上のユーザーに、RDS クラスタ内でホストされている Windows デスクトップとアプリケーションへのアクセスを許可する役割を担っています。このロールは多くの場合、後述する RD Web Access ロールと同じホストにインストールされます。
  • リモートデスクトップライセンシング (RD Licensing) ロールは、ユーザーライセンスを管理し、仮想デスクトップ/アプリケーションをホストする RD Session Host サーバーへの接続をユーザーに許可します。
  • 最後に、リモートデスクトップ Web Access (RD Web Access) ログインポータルは、ユーザー (そしてこの調査では攻撃者) が認証し、最終的にリモートデスクトップセッションホスト (RD Session Host) に到達するための手段です。攻撃者はこの時点でシステム内部へのアクセスを達成しているため、RD Session Host を起点にしてさまざまな活動を開始することができます。(MITRE ATT&CK の T1133「初期アクセスと外部リモートサービス」に該当します。)

本記事では、RD Gateway、RD Web Access、および RD Session Host のロールに焦点を当てます。リモートデスクトッププロトコル (RDP) がどのように悪用される可能性があるのか、また攻撃者が用いる手法については、今年初めに公開した RDP に関するシリーズ記事を参照してください。

RD Web Access が悪用されると何が起こるか?

RD Web Access のホストがインターネットに公開されていると、ユーザーは自分のドメイン認証情報を使ってログインし、RD Session Host や、どこからでも重要なビジネスリソースにアクセスできる仮想アプリケーションにアクセスできるようになります。これらのサーバーが適切に保護されていない状態でインターネットに公開されている場合、攻撃者によって悪用され、環境内にアクセスされる可能性があります。ログインポータルの多くは、ユーザー認証情報の入手を目的としたブルートフォース攻撃を受け、盗まれたユーザー認証情報はログイン、常駐化、権限昇格、さらには環境内でのラテラルムーブメントに使用されます。

The default login page as described in text図 2: RD Web Access ポータルのデフォルトのログインページ

認証に成功すると、公開されている RD Session Host または仮想アプリケーションに接続するオプションが表示されます。★仮想アプリケーションにしか接続できない場合、攻撃者がホスト上でコードを実行するには、含まれるアプリケーションから「ブレークアウト」する必要があります。

A screen showing that the service has just one published app, and that's Calc

図 3: 公開されている仮想アプリケーションが 1 つだけ表示される RD Web ポータル

図 3 の例は、1 件のアプリケーション (Windows の電卓) だけが表示されている RD Web ポータルです。ユーザーがこのアプリケーションを選択すると、電卓アプリケーションを起動するように事前に設定された .RDP ファイルがダウンロードされます。この場合、公開されている RD Session Host に接続するオプションがないため、攻撃者の目標は、電卓アプリケーションをホストしているリモートサーバー上でコードを実行する方法を特定することになります。

MDR が確認した手法の 1 つは、組み込みの Windows アクセシビリティ機能を利用してコマンドプロンプトにアクセスするという方法です。電卓アプリケーションのウィンドウがフォーカスされているとき、攻撃者はキーボードの Shift キーを5回押すと、固定キー (Sticky Keys) プロンプトを表示させることができます。このプロンプトはリモートの RD Session Host から読み込まれます。固定キープロンプトの中には、アクセシビリティオプションのコントロールパネル項目を起動するオプションがあります。このオプションを選択すると、大抵の場合 Windows エクスプローラーのウィンドウでクラシック表示のコントロールパネルが読み込まれます。攻撃者は Windows エクスプローラーの検索バーから「cmd.exe」と入力して Enter キーを押すだけで、RD Session Host 上の対話型コマンドプロンプトがロードされ、目的のアクションを開始することができます。

RD Session Host に接続するオプションが表示された場合、攻撃者はグラフィカルな UI の対話型リモートデスクトップセッションに直接ログインし、そこからさらに目的を達成することができます。RD Web Access ホストからいずれかのセッションホストへの直接接続が確立されると、RD Web Access ホストは攻撃者のマシンから RD Session Host への接続のプロキシとして機能しますが、認証ログには RD Web Access ホストからの対話型 RDP ログオンが記録されます。

本記事のために MDR が分析した 5 件の RD Web Access インシデントのうち 4 件において、MDR チームは攻撃の発見段階での検出に対応しました。この検出は、攻撃者が「nltest / domain_trusts」コマンドを実行し、標的上に Active Directory の信頼関係が存在するかどうかを列挙しようとしたことによってトリガーされたものです。(5 番目のインシデントもこの動作によってトリガーされたものでしたが、最初に検出されたのは別のイベントでした。)攻撃者は多くの場合、アクセスに成功した環境とその基盤となっている Active Directory ドメインインフラストラクチャの詳細を把握する目的で検索コマンドを実行します。

A screen capture showing various logged commands

図 4: 接続に成功した後の検出コマンドの例

これらのインシデントを調査した結果、RD Web Access ポータルを提供する IIS プロセスに対して継続的なブルートフォース攻撃が試みられていたことが確認されました。

A screen capture showing a number of brute-force attempts against IIS

図 5: RDWebAccess IIS プロセスに対するブルートフォース攻撃の例

インシデント対応のトリアージ段階において、MDR チームは脅威を可能な限り迅速に封じ込めるため、影響を受けるユーザーを無効化し、アクティブセッションを切断する適切な措置を講じます。複数のアカウントに侵害の痕跡が見られる場合、MDR は RD Web Access ホストも隔離して、最終的にその初期アクセス経路からの環境へのさらなるアクセスを阻止します。MDR チームは、調査プロセスを支援するために数多くのクエリを使用します。その多くを以下の「調査ガイド」の項に記載しています。

調査ガイド

この項では、RD Web Access の悪用が疑われる場合に調査担当者が使用できるクエリをいくつか紹介します。この項に記載されているクエリは、Sophos MDR チームが開発したものであり、Sophos Central ポータルの Threat Analysis Center -> Live Discover で実行できます。現在 Sophos Central を使用されていない場合は、一般的なアドバイスを実行してください。ただし、使用するテクノロジに応じてプロセスを実行する必要があります。

OSINT を利用して、公開されている RD Web Access ポータルを特定する

外部の攻撃対象領域を確認すると、インターネットに公開されている多数のサービスが見つかることがあります。以下の Shodan 検索を実行すると、公開されている RDWeb サーバーが特定できます。

hostname:<insert company domain name here> path=/RDWeb/

Live Query を使用して RD Gateway サーバーを特定する

RD Gateway サーバーは、「TSGateway」という名前の Remote Desktop Gateway サービスがあるかどうかで特定することができます。これはエンドポイントクエリであるため、Sophos Central Live Discover 内ですべてのオンラインサーバーを選択して、RD Gateway ロールがインストールされているホストを確認する必要があります。

SELECT
    name,
    display_name,
    start_type,
    path,
    status
FROM services
WHERE name = 'TSGateway'

RD Gateway のログを確認する

管理対象のホストが RD Gateway ロールを実行していることが判明した場合には、Sophos Central Live Discover を介して以下のクエリを実行し、RD Gateway の Windows イベントログから最新の接続イベントを取得します。これらのログは、影響を受けるユーザーの接続イベントと切断イベントを返し、セッションに接続したリモートソース IP アドレスを明らかにします。送信元 IP アドレスが判明したら、ネットワーク境界で当該の IP アドレスをブロックすることを強くお勧めします。これはエンドポイントクエリであるため、先ほどのクエリ (「Live Query を使用して RD Gateway サーバーを特定する」) で表示された、RD Gateway ロールを実行しているホストのみを選択する必要があります。

SELECT
strftime('%Y-%m-%d %H:%M:%S',swe.datetime) AS Datetime,
swe.time,
swe.eventid AS EventID,
CASE 
WHEN eventid = 200 THEN 'Client Connected' 
WHEN eventid = 303 THEN 'Client Disconnected'
END AS Description,
JSON_EXTRACT(swe.data, '$.UserData.Username') AS Username,
JSON_EXTRACT(swe.data, '$.UserData.AuthType') AS AuthType,
JSON_EXTRACT(swe.data, '$.UserData.IpAddress') AS IpAddress,
JSON_EXTRACT(swe.data, '$.UserData.Resource') AS Resource,
JSON_EXTRACT(swe.data, '$.UserData.BytesReceived') AS BytesReceived,
JSON_EXTRACT(swe.data, '$.UserData.BytesTransfered') AS BytesTransfered,
JSON_EXTRACT(swe.data, '$.UserData.SessionDuration') AS SessionDuration,
JSON_EXTRACT(swe.data, '$.UserData.ConnectionProtocol') AS ConnectionProtocol
FROM sophos_windows_events as swe
WHERE source = 'Microsoft-Windows-TerminalServices-Gateway/Operational'
AND eventid IN (200,303)
AND swe.time > $$starttime$$
--AND swe.time > )$$starttime$$ AND swe.time < $$endtime$$
ORDER BY swe.time

クエリの最後に表示されている日付/時間範囲の情報に注目してください。これは、調査の時間枠に合わせて調整する必要があります。Sophos Central の GUI では、日付変数タイプを使用して選択できます。カレンダーをクリックして開始時刻と終了時刻を選択してください。

IIS ログを確認する

デフォルトでは、IIS は UTC でログを書き込み、「YYYY-MM-DD hh:mm:ss」の形式を使用します。以下の grep パターンでは、分と秒を意図的に除外しているため、ログインイベントに関連する 1 時間分のログが取得されます。また、「file.path」値を更新して、確認したい IIS ログの日付を反映させる必要があります。この形式は YYMMDD (たとえば、2024 年 2 月 23 日は 240223) です。

先ほどのクエリを実行し、RD Gateway のイベントログから成功したログインのタイムスタンプを特定した後は、以下のクエリを変更して、周辺の IIS ログを取得することができます。これにより、IIS のログイン時刻と、攻撃者が Web ポータルに接続している間にクリックした可能性のあるデータが判明します。送信元 IP アドレスは先ほどのクエリの結果からわかっているので、この情報を「grep.pattern」フィルタとして使用して、そのアドレスを含むすべての IIS ログを表示することもできます。これはエンドポイントクエリであるため、Sophos Central Live Discover 内で特定のホストを選択する必要があります。

SELECT grep.*
FROM file
CROSS JOIN grep ON (grep.path = file.path)
WHERE
file.path LIKE 'C:\inetpub\Logs\LogFiles\W3SVC%\u_exYYMMDD.log'
AND grep.pattern = 'YYYY-MM-DD hh: '

ブルートフォース攻撃の痕跡を確認する

RD Web ポータルに対するブルートフォースの試行は、図 5 (上図、前項) に示すように、Windows IIS プロセス w3wp.exe へのログインイベントをフィルタリングすることで確認できます。これは Sophos Central のデータレイククエリです。RD Gateway のログを確認するためのクエリ (上記) と同様に、クエリを絞り込むための時間範囲オプションは GUI から設定できます。

SELECT
meta_hostname, date_format(from_unixtime(CAST(event_timestamps AS bigint)), '%Y-%m-%d %H:%i:%S') AS event_timestamp, eventid, subject_username, subject_domain, target_username, target_domain, target_logon_id, subject_logon_id, logon_type, logon_process, authentication_package, transmitted_services, key_length, name, remote_address, remote_port, description, provider_name, source
FROM
xdr_data
WHERE
event_timestamps NOT LIKE '%,%'
AND 
query_name IN ('windows_event_successful_logon','windows_event_invalid_logon')
AND name LIKE '%w3wp.exe%'
AND meta_hostname = '$$hostname$$'

Windows レジストリによる RD Web 公開アプリケーションの一覧表示

Windows レジストリを確認して、公開されているアプリケーションやセッションホストの一覧と、それらの一覧に含まれる項目の権限制限を取得します。これはエンドポイントクエリであるため、Sophos Central Live Discover 内で特定のホストを選択する必要があります。

SELECT path, data, type, strftime('%Y-%m-%d %H:%M:%S',datetime(mtime,'unixepoch')) AS modified_time
FROM registry
WHERE path LIKE 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\%%'

環境全体で侵害を受けたアカウントの履歴を確認する

侵害されたアカウントが RD Web ポータルからログインしていることが確認できたら、次のクエリを使用してユーザーアクティビティを調査することができます。この結果に基づいて、攻撃者がネットワーク内の他のホストに移動したかどうかを検出できます。これは Sophos Central データレイククエリです。クエリの最後から 2 行目に完全なユーザー名を入力する必要があることに注意してください。

SELECT
 meta_hostname,
 date_format(from_unixtime(time), '%Y-%m-%d %H:%i:%s') as date_time,
 username, cmdline, name, path, sophos_pid, parent_name,parent_cmdline,parent_path, parent_sophos_pid, uid, gid,file_size, sha1, sha256
 FROM
 xdr_ext_data
 WHERE
 query_name = 'running_processes_windows_sophos'
 AND username = '$$username$$'
 ORDER BY date_time DESC

侵害されたアカウントに関する情報を収集する

次の Sophos Central データレイククエリを使用して、侵害されたアカウントに関する詳細情報を取得できます。

SELECT
meta_hostname,uid, gid, username, description, directory, shell, type, uuid
FROM
xdr_data
WHERE
query_name = 'user_accounts'
AND username = ‘$$username$$’

上記のクエリと併せて、これらの PowerShell コマンドを使用すれば、ドメインまたはローカルユーザーを調査して、最後に変更されたパスワード、有効化されたアカウントなどのユーザーアカウントのプロパティを取得することができます。先ほどのクエリと同様に、クエリの最後から2行目に完全なユーザー名を入力する必要があることに注意してください。

MDR が実行する対応アクション

公開されている RD Web Access ホストが関係しているインシデントでは、ラテラルムーブメントが実行される前に、脅威を無効化するための迅速な対応が求められます。そこで Sophos MDR チームは、侵害されたシステムを可能な限り迅速に封じ込めるために、以下の対応措置を共通して実行します。

  • RD Gateway を含む影響を受けたホストを隔離し、公開されているログインポータルに対する認証の試行を停止する
  • ポータルへの不正ログインに使用された送信元 IP アドレスを記録し、ブロックする
  • 影響を受けたドメインユーザーを無効にする
  • Sophos Central で悪意のある実行ハッシュをブロックする
  • Sophos Central 内にアプリケーションコントロールポリシーを導入し、一般的に悪用されているツールの実行を制限する
  • SophosLabs に悪意のある未知のファイルを送信して分類し、新しい検出を作成する。

推奨事項と緩和策

RD Web Access は、ユーザーがリモートからビジネスリソースに接続する手段として便利ですが、公開されているシステムの攻撃対象領域を縮小する上で実施すべき重要な推奨事項がいくつかあります。以下の 3 つのアクションを攻撃前に実行することで、攻撃の影響を緩和できる可能性があります。

  • 多要素認証がすべてのドメインユーザーに対して導入されていることを確認する。
  • 公開されているアプリケーションと RD Session Host の構成を見直し、承認された項目のみが公開され、それにアクセスすることが想定されているユーザーのみに公開されていることを確認する。cmd.exe と PowerShell へのアクセスを必要としないユーザーのアクセスを拒否するグループポリシーオブジェクトの作成を検討する。
  • 可能であれば、ログインポータルへのインターネットアクセスを、承認された送信元 IP アドレスに限定する。

上記の推奨事項と緩和策を導入できず、RDS クラスタを引き続き使用する必要がある場合は、多要素認証を有効にして、VPN で RD Web Access ポータルを保護することを検討してください。これを実行することで、ポータルがインターネットに直接さらされなくなるため、公開されているアプリケーションの攻撃対象が縮小されます。

結論

これまでに RD Web Access の悪用がどの程度広まっているのか、あるいはどのような攻撃者 (攻撃グループ) がこの手法を選択しているのかについては、本記事の範囲外ですが、インターネットに接続している保護されていないリモートデスクトップアクセスは、多要素認証が有効化されていないシステムと同様に、誤った選択であることに間違いありません。本記事は、攻撃を受けた被害者を貶めるためのものではありません。上記のような侵入を調査する方法についての情報を提供し、読者の皆様がセキュリティのベストプラクティスに従って、このような状況を回避できることを期待しています。

コメントを残す

Your email address will not be published. Required fields are marked *