古いフレームワークに新しいコツを教示：Windows UI Automation の危険性
編集・協力：Tricia Howard
エグゼクティブサマリー
Akamai のセキュリティリサーチャー Tomer Peled 氏は、Microsoft の UI Automation フレームワークを使用および悪用する新たな方法を模索し、エンドポイントの検出と応答（EDR）を回避する攻撃手法を発見しました。
この手法を利用するためには、ユーザーが UI Automation を使用するプログラムの実行に確信を持っていることが必要です。これにより、ステルスコマンドが実行される可能性があり、機微な情報の収集や、フィッシング Web サイトへのブラウザーのリダイレクトが行われることがあります。
この手法の検出は、EDR など、いくつかの方法では困難です。この手法に対してテストした EDR テクノロジーはすべて 、悪性アクティビティを見つけることができませんでした。
この手法は、オペレーティングシステム XP 以上を搭載したすべての Windows エンドポイントで使用が可能です。
このブログの投稿では、UI Automation フレームワーク（それを活用する可能性のある攻撃を含む）を使用（悪用）する方法についてすべて記載し、検討対象の不正ベクトルそれぞれについてコンセプトの証明（PoC）を提示します。また、検知オプションと緩和オプションも記載します。
はじめに
生活のために物書きをしている人の中には、読み上げソフトウェアと文法チェックソフトウェアを愛している人がいます。生活のためにセキュリティ調査を行っている人の中には、物を分解して、それについて書くのが好きな人がいます。このようなライティングアシスタントの広告を見た数か月後、私たちは見つけることができた内容を試してみたり、確認したりすることにしました。
具体的には、アプリケーションが別のアプリケーションのユーザーインターフェース（UI）をリモートで操作する方法を把握しようとしました。私たちの発見は、XP がまだ稼働していると知ったことと同様に衝撃的でした。これは、UI Automation フレームワークという非常に古いフレームワークによって処理されます。
このフレームワークは、障がい者のコンピューター使用を簡単にする方法として、Windows XP の時代に考案されました。これには高度な権限が与えられ、テキストの拡大、大音量でのテキストの読み上げ、さらにはクリックのシミュレーション（状況による）などの動作を支援しました。この UI Automation を実行するためには、画面に表示されるほぼすべての UI 要素を操作する権限が必要ですが、意図した目的を考慮すれば意味があります。このテクノロジーは、それが実行できる、または実行できないと伝えられたことだけを実行します。
私たちはこのことから、攻撃側が UI Automation を悪用した場合に発生する可能性のある影響を把握する調査を開始しました。
攻撃側は、UI Automation を悪用して、データの窃取、インターネット閲覧の操作、コマンドの実行、さらには WhatsApp や Slack などのチャットアプリケーションからメッセージの読み取りと書き込みを行う可能性があることがわかりました。これらはすべて、テストしたすべての EDR ベンダーでは検出されませんでした。
このブログ投稿では、このフレームワークの仕組みから機能を悪用する方法まで、このフレームワークについて知っておくべきすべての情報を記載します。検知オプションと 緩和 オプションをブルーチームのメンバーの結論とします。
COM 経由の UI Automation の操作
UI Automation フレームワーク（UIA）は、コンポーネントオブジェクトモデル（COM）をプロセス間通信（IPC）メカニズムとして活用して、他のアプリケーションの要素と対話します。
COM は Microsoft が設計したフレームワークで、 記述またはコンパイルに使用される言語を問わずさまざまなプログラムが相互に通信できるようにするものです。COM フレームワークを使用すると、開発者は COM オブジェクトというコンポーネントを作成できます。これらのオブジェクトは、Windows エンドポイントに、その名前、汎用一意識別子（UUID）、およびロジックとその他の設定可能な値を含むバイナリと共に登録されます。
UIA ユーザーと対話するためには、CUIAutomation クラス UUID および UIAutomation インターフェース UUID を使用して、関数「CoCreateInstance」を呼び出し、COM オブジェクトを作成します。次の表を参照してください。
CUIAutomation UUID |
ff48dba4-60ef-4201-aa87-54103eef594e |
UIAutomation インターフェース UUID |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
COM オブジェクトの作成時に、システムはレジストリーで指定された DLL をロードします。ここでは「UIAutomationCore.dll」です。
このどれかは、もうご存じではないでしょうか？観察眼の鋭い読者は、これらすべてが、 MS-RPCの広範な当社の検査と類似していることに気づくと思います。COM は RPC を基盤として使用しているため、類似性があるのです。
UI Automation — Hello World
攻撃側がこのフレームワークを悪用する方法に入る前に、一般的に UIA と対話する方法（C++ を使用）を確認しておくとよいでしょう。これにより、このフレームワークの実装で問題が発生する箇所を把握するための背景知識が得られます。UIA との対話方法については、当社の GitHubをご確認ください。
UIA オブジェクトが作成されると、その DLL がユーザーのアプリケーションと、UI 要素を持つ他のすべてのプロセスにロードされます。
リモートプロセス UI 変更のイベントハンドラーを追加するまで、他には何も発生しません。次の例は、現在ユーザーに開かれているツールチップの変更に対してハンドラーを設定する方法を示しています。
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
これが完了すると、UIA は当社のアプリケーションと通信するリモートプロセスで「サーバー」を開きます（図 1）。これらの間で転送されるデータは、リモートプロセスのすべての UI 要素に関する情報です。
図 1：UI 要素を持つすべてのプロセスに UIA dll がロードされている
Microsoft のドキュメントによると、UIA が想定する標準ハンドラーは次のハンドラープロトタイプです。
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
（開くか、他の方法によって）UI の前面に移動したアプリケーションを正確に特定するために、関数「sender.get_CurrentName」をハンドラー内から呼び出します。これで、どのアプリケーションがフォーカスされているか特定できるようになったので、アプリケーションへの読み取り／書き込みを試みることができます。
そのためには、すべてのエレメント（ 送信側 要素の子孫）を繰り返し処理して、UI 値を読み取ったり、テキスト値を変更したり、呼び出し可能な要素を取得して「呼び出し」関数を呼び出して、読み取り／書き込みをしたい要素を検索する必要があります（図 2）。
図 2：エレメントを高レベルで検索および操作するプロセス
UI Automation を悪用して悪性アクティビティを発生させる
最後のセクションで、 どのようにして UIA を悪用するか説明しましたので、次は、悪用によって発生する可能性のある悪性アクティビティについて説明します。これらを説明する最善の方法は、例を通じて説明することです。次の 3 つの例があります。
- メッセージの読み取りと書き込み
- 機微な情報の窃盗
- コマンドの実行
メッセージの読み取りと書き込み
すべてのメッセージングアプリケーションには、UIA を使用してアクセスできるさまざまなタイプの UI 要素を含むグラフィカル・ユーザー・インターフェース（GUI）があります。図 3 は、Slack の GUI の例ですが、見慣れたものではないでしょうか。
図 3：一般的な Slack
GUI 内で使用可能なアクションは、会話の選択（背後にボタンとして実装されている）からメッセージ（テキストブロック）の読み取りまで、多岐にわたります。そのため、操作できることが数多くあります。
攻撃側が、このようなアプリケーションの UI ウィンドウに「接続」できるようになると、必要な会話をクリックして（UI ボタン要素を使用）入力することをシミュレートできます。ここから、会話を読むか、データを窃取するか、メッセージの書き込みを担当する UI 要素を見つけるか、TextArea 要素内のテキストの値を変更して、送信ボタンのクリックをシミュレートするかを選択できます。
もちろん、この種の操作は画面にも反映され、攻撃側に多くのチャンスが残されます。ステルス手法では、現在開かれている会話から読み取りのみ行い、長期にわたってデータを収集します（図 4）。
図 4：Slack からのメッセージの読み取り
受動的なアプローチを取らずにステルス性を維持する別のオプションは、UIA のキャッシュメカニズムを使用することです。現在画面に表示され操作できる UI 要素に加えて、さらに多くの要素が事前にロードされ、キャッシュに置かれます。また、画面に表示されていないメッセージを読み取ったり、画面に反映させずにテキストボックスを設定してメッセージを送信したりするなど、これらの要素を操作することもできます。
このブログ投稿が立ち上がる前に確認できませんでしたが、キャッシュメカニズムによって、コンピューターがロックされている間にこれらの要素を操作できる場合もあり、これにより、荒っぽい操作をしながら、ユーザーがまったく気づかないようにできます。
機微な情報の窃盗
さらに損害が大きくなる場合の一つとして、UIA を使用（悪用）してクレジットカード情報を盗むことを考ました。
ユーザーがオンライン販売者に入った後、攻撃側はハンドラを設定して、プログラムによって UI 要素の変更をリスンできます。変更が行われると（つまり、クレジットカード情報が入力されると）、攻撃側は UI 要素からテキストを取得して後で窃取することができます（図 5）。
図 5：ブラウザーからクレジットカード情報を取得する
コマンドの実行
ブラウザーでの他の一般的な攻撃経路として、フィッシングやブラウザーのリダイレクトによるものがあります。
firefox/chrome/edge UI ウィンドウを除去することによって、攻撃者は単にそれらのウィンドウの 検索バー の UI 要素を検索し、その値を攻撃者が必要な値に設定して、クリックをシミュレートします （図 6）。ステルス性を増加させるために、現在表示されている Web ページが更新または変更されるのを待ち、別の Web サイトへの変更に気付きにくいようにします。
これにより、攻撃側は、攻撃側の制御下にある悪性サイトにユーザーをリダイレクトできます。その結果、ブラウザーの悪用（ ブラウザー悪用フレームワーク［BeEF］）、ドライブバイ攻撃、正規サイトの偽サイトによるフィッシングや資格情報収集など、実質的に無限の可能性があります。
図 6：ユーザーを BeEF にリダイレクト
UI Automation の潜在的な影響
これまでのセクションで検討した攻撃は、数十年にわたりさまざまな実装が行われ、ほとんどの防御ツールで、攻撃を検知して対応する方法が知られています。
ただし、上記で説明したすべての事項は、UI Automation の 機能 と見なされています。これは、アプリケーションの本来の目的に戻ることになります。これらの権限レベルは、それらの機能を使用するために存在しなければなりません。これが、UIA が Defender をバイパスできる理由で、アプリケーションは通常から逸脱したものは何も検出しません。実際、テストした EDR では、これらの動作を悪性の動作と認識できませんでしたが、これも同じ理由によると考えられます。バグではなく機能として表示されているものがあれば、マシンのロジックはその機能に従います。
これにより、このフレームワークは攻撃側に非常に利益の出やすい可能性があります。このため、この攻撃ベクトルに対処するためには、より高い認知度が重要であると私たちは考えています。
さらなる調査
DCOM を介した UIA
分散 COM（DCOM）は、マシン間で COM オブジェクトをリモートで呼び出す方法です。理論的には、DCOM を介して UIA にリモートアクセスすることが可能であり、これにより、フィッシングやローカルアクセスを必要とせずに、これまでに説明したすべての攻撃を実行できるようになります。
当社の分析の一環として、UIA の COM オブジェクトがデフォルトで DCOM を許可するように構成されていないことがわかりました。これにより誤った設定を排除して、潜在的攻撃力を大幅に低減できます。
UIA 自体は DCOM では利用できませんが、関連するUIAutomationCrossBitnessHook COM／DCOM オブジェクトを見つけました。このオブジェクトには、リモートアクティベーションとリモート実行の権限は必要ありません。
その DLL を元に戻すことによって、インターフェースに UI マネージャーを設定する関数と、それを設定解除する関数の 2 つの関数が含まれていることがわかりました。この DLL には他のリモート機能がないようなので、データの読み取りや書き込みには使用できませんでしたが、将来的に優れた研究対象になる可能性があります。
UIA 名前付きパイプ
この投稿の前半で、UIA がリモートプロセスで「サーバー」を開くと述べました。この裏では、これらのサーバーとクライアントは、名前付きパイプを使用して実装されています。命名規則では、固定文字列 UIA_PIPE の後に、プロセス ID と他の識別子が続きます（図 7）。
図 7：攻撃側アプリケーション内の UI 名前付きパイプ
今度は、これには次のような恐ろしさが生まれます。名前付きパイプはリモート接続を受け入れることができます。この場合、攻撃側がネットワーク上で UI 要素を操作できる可能性があるため、非常に危険です。しかし、リモートサーバーから接続しようとすると、 ACCESS_DENIED エラーに遭遇しました。
これは、Microsoft がフラグ PIPE_REJECT_REMOTE_CLIENTS を、名前付きパイプを作成する際に設定したためです。つまり、リモートから UIA にこれらのパイプを介してアクセスすることはできませんが、ローカルなら利用できます。これらのパイプは列挙して（プロセス ID や識別子の推測は不要）アクセスできます。これは、この分析の一部ではありませんが、何らかの特権の昇格攻撃や偽装を容易にする可能性があります。
検知と緩和
Microsoft は、 このフレームワークが、上位の特権アプリケーションと対話すべきでないことを認識しました。したがって、デフォルトでは、UI Automation フレームワークを使用するアプリケーションは、中程度の信頼レベルで実行され、高度な特権プロセスにアクセスすることは許されていません。これは、キー requestedExecutionLevel.uiAccess を TRUE に設定したマニフェストファイルを持つ署名付きアプリケーションを使用してバイパスできます。
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
検知に関しては、管理者は UIAutomationCore.dllの使用を監視できます。これが以前は不明だったプロセスにロードされている場合は、懸念について正当な理由が挙げられることが必要です。
同様に、ネットワーク管理者は、UIA によってエンドポイントで開かれた名前付きパイプを、その使用の別の指標として監視できます。これは、次の osquery を使用して実行できます。
SELECT DISTINCT pid, name, proc.path FROM process_memory_map AS pmm JOIN processes AS proc USING(pid) WHERE pmm.path LIKE '%uiautomationcore.dll'
次をロードするプロセス： UIAutomationCore.dll
WITH uia_pipes AS (SELECT name AS pipe_name, SUBSTR(name, 10, INSTR(SUBSTR(name, 10), '_')-1) AS pid FROM pipes WHERE name LIKE 'UIA_PIPE_%' ) SELECT DISTINCT pid, name AS process_name, path, pipe_name FROM uia_pipes JOIN processes USING(pid)
UI Automation の名前付きパイプを開いたプロセス
結論
この分析は、善意のために作成されたテクノロジーがどのようにして悪性の目的でハイジャックされるかを示す、不運な例です。UI Automation フレームワークは障害のあるユーザーに役立ちますが、攻撃側がスパイウェアを模倣する機会にもなります。
UIA の悪用は他の攻撃よりも困難な可能性がありますが、EDR がそれを検知できないという事実から、UIA は非常に魅力あるアタックサーフェスとなる可能性があります。攻撃側への魅力度を小さくするために、Microsoft は UIA にいくつかの制限を設けていますが、攻撃側は、しかるべきスキルを持ってそれを巧みに利用できます。私たちは、このブログを投稿することによって、この攻撃手法に対する認知度を高め、ブルーチームのメンバーをこのような攻撃ベクトルから防御する手助けになることを望んでいます。
