Remote Desktop Protocol：タイムゾーンバイアスの使い方

** 本記事は、Remote Desktop Protocol: How to Use Time Zone Bias の翻訳です。最新の情報は英語記事をご覧ください。**

侵害された既知のユーザーに基づいて探す方法であれ、特定のユーザーに関連するマルウェア保護や EDR 保護からのアラートに基づいて探す方法であれ、大半の防御者は、疑わしい RDP のラテラルムーブメントを発見して精査する方法を熟知しています。何かが異常だという気付きの次は、実際に何が異常なのかを調べる段階です。

ログを調べてアカウント操作のタイムスタンプを確認することは、不審な動作を発見する典型的な方法です。たとえば、通常営業時間中に Sage サーバーにしかアクセスしない本社の James なる人物が、午前 3 時にドメインコントローラーに接続している場合などです。しかし、ログインについて知るべきことはさらにあります。アクティビティが発生した時間だけでなく、アクティビティが発生したタイムゾーンです。これはバイアスと呼ばれ、Microsoft OS の最新バージョン (Windows 10 / Server 2016 以降) でキャプチャされます。イベントID 104 は、Microsoft Windows Remote Desktop Services RDP Core TS Operational イベントログで確認できます。

防御者が確認する事項

名前から予想されるように、このイベントログでは、接続を行ったマシンの UTC からのタイムゾーンバイアスが記録されます。おそらく、ユーザーが通常ログインするタイムゾーンは予めわかっているはずであり、そのゾーンからの逸脱を確認することで、不審な RDP 接続を特定できます。というのも、本来の場所からの接続ではないためです。

先程の James を再度例に挙げ、ロンドンを拠点としているとしましょう。あなたは年の初めに不審な活動を調査しているとします。1 月あるいは 2 月時点での James のタイムゾーンバイアスは UTC±0 です。したがって、James が何らかの理由で RDP を使用してネットワークに接続している場合、彼のログイン時に表示されるクライアントのタイムゾーンバイアスは [0] になります。突然、[-8] や [6] など、普段の James のものと異なるクライアントのタイムゾーンバイアスが表示された場合、その接続が不審な RDP 接続となります。少なくとも、James が旅行中であったり、マシンが盗まれたりしたのではないかという疑念を抱きます。

たとえば、MFA の有効性を認識していたにもかかわらず、有効化を怠っていたため、あるユーザーの認証情報がフィッシングされ、攻撃者が VPN にログインし、RDP を使ってデバイスへのアクセスを獲得したとします。このようなアクセスイベントの際に、攻撃者のマシンのタイムゾーンが表示されるようになります。

魔法のようにすべてに答えてくれる単一のクエリは存在せず、このクエリも例外ではありません。たとえば、攻撃者は多くの場合、幅広いタイムゾーンにあるさまざまなマシンをホスティングしており、物理的にその場所にいるかどうかはわかりません。それでも、多くの場合そのユーザーの普段のタイムゾーンとは異なります。

もう 1 つの潜在的な弱点は誤検出です。「普段」のタイムゾーンがどれであるかを見分けるのが難しいような組織運営をしている場合、シグナルとノイズの違いを特定するのが難しくなる可能性があります。さらに、偽陰性 (見逃し) の可能性もあります。イベントは攻撃者のマシンのタイムゾーンを記録するので、攻撃者はそのマシンのタイムゾーンを変更することで、データを取り繕うことができます。とはいえ、イベント 104 は監視する価値のあるイベントであり、用いるべき防御ツールキットの1つです。

タイムゾーンバイアスと Live Discover

イベント 104 はもちろん、サポートされている最新の Microsoft システム (Windows 10/Server 2016 以降) を調査する人であれば誰でも利用できます。本記事の最終セクションは、ソフォスの Live Discover を使用して調査を行う方向けです。(ただし、以下で説明するクエリはソフォスの Github でも公開しますので、どなたでも入手できます。)ソフォスの YouTube チャンネルでも以下のクエリおよびその結果のデモ動画をご覧いただけます。

OS クエリを実行し、Live Discover でタイムゾーンバイアス情報を出力するには、以下のクエリを使用してください。

SELECT 

    strftime('%Y-%m-%dT%H:%M:%SZ',datetime) AS Datetime, 

    source, 

    eventid, 

    JSON_EXTRACT(data, '$.EventData.TimezoneBiasHour') AS TimezoneBiasHour 

FROM sophos_windows_events 

WHERE 

    source = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'  

    AND eventid IN (104) 

クエリの出力は、図 1 のようになります。

図 1: 1 人のユーザーが 90 秒間の間に 8 つのタイムゾーンをテレポートで移動する方法が開発されたのでなければ、違和感のある結果

上の画像の左側には、エンドポイント名が表示されています。2 件のイベントのどちらのエントリにも共通です。日付/時刻情報が UTC で表示され、2 件のイベントが約 1 分半間隔で発生したことを示しています。ソースはこのイベントを発見した場所であり、次の列に 104 と表示されています。さらに右側には、その結果が示されています。最初のイベントは UTC±0 で発生し、2番目のイベントは UTC+8 で発生していました。

図 2: UTC +8 は確かに魅力的な地域ですが、ロンドンを拠点とする James の近辺でないことは確かです。(地図画像提供: nationsgeo.com)

環境内のすべてのデバイスでこのクエリを実行することをお勧めします。RDP Core TS Operational イベントログに、通常とは異なるタイムゾーンバイアスのエントリがあるかどうかを確認してください。

Remote Desktop Protocol：記事一覧

パート 1：イントロダクション ([本記事]、動画)
パート 2：公開されている RDP の危険性 (記事、動画)
パート 3：調査でのクエリ活用 (記事、動画)
パート 4：タイムゾーンバイアスの使い方 (記事、動画)
パート 5：外部 RDP クエリの実行 (記事、動画)
パート 6：4624_4625 ログインクエリの実行 (記事、動画)
GitHub のクエリリポジトリ: SophosRapidResponse/OSQuery
スクリプトのリポジトリ: sophoslabs/video-transcripts
Youtube のプレイリスト: Remote Desktop Protocol: The Series