octoberfest7/xll_phishing
XLLフィッシングの手口
マイクロソフトによる最近の発表で、インターネット（メールおよびWebダウンロード）から取得したドキュメント内のマクロがブロックされるようになったことを受け、攻撃者はユーザーによるアクセス（UDA）を獲得するための他の手段を積極的に模索し始めています。フィッシングによるアクセス方法を検討する際には、いくつかの要素を比較検討する必要があります。
これらが主要な質問ですが、もちろん他にもあります。これらの要素が互いに影響し合うことで、状況はさらに複雑になります。たとえば、クライアントが実行可能ファイルや DLL のダウンロードを禁止する Web プロキシを導入している場合、ペイロードをコンテナ（ZIP、ISO など）の中に隠す必要があるかもしれません。そうすると、後々の検知に関してさらなる問題が発生する可能性があります。より強固な防御には、より複雑なテクニックの組み合わせが必要です。
この記事では、架空の標的組織を想定して書かれています。この組織は、メールフィルタリングルール、特定のファイルタイプのダウンロード禁止、エンドポイントでのアプリケーションホワイトリスティング、EDR ソリューションとしての Microsoft Defender for Endpoint など、いくつかの防御策を導入しています。
実際の組織では、これらの防御策がまったく採用されていない場合もあれば、一部またはさらに多くの防御策が採用されている場合もあり、それによって本調査で概説するテクニックが単純化されたり複雑化されたりします。いつものことですが、標的をよく知ることが重要です。
XLL は、Microsoft Excel 専用に作られた DLL です。一見しただけでは、通常の Excel ドキュメントと非常によく似ています。
XLL は、クライアントネットワークで非常によく見られるソフトウェアである Microsoft Excel によって実行されるため、UDA にとって非常に魅力的な選択肢です。さらに、Excel によって実行されるため、信頼されたアプリケーション（Excel）が実行するということで、ペイロードはほぼ間違いなくアプリケーションホワイトリスティングルールを回避できます。XLL は C、C++、または C# で記述でき、VBA マクロよりもはるかに柔軟性とパワー（そして正気度）を提供するため、さらに望ましい選択肢となります。
もちろん欠点もあります。XLL の正当な用途は非常に少ないため、組織がメールと Web ダウンロードの両方でそのファイル拡張子のダウンロードをブロックするのは、非常に簡単なチェック項目のはずです。残念ながら、多くの組織は時代に遅れており、そのため XLL はしばらくの間、フィッシングの有効な手段であり続けるでしょう。
XLL 内でコードを実行するために使用できるさまざまなイベントがありますが、最も注目すべきは xlAutoOpen です。完全なリストはこちらで確認できます。
XLL をダブルクリックすると、ユーザーは次の画面を目にします。
この単一のダイアログボックスだけが、ユーザーとコード実行の間にある障壁です。かなり薄いソーシャルエンジニアリングで、コード実行はほぼ確実です。
念頭に置くべきことは、XLL は実行可能ファイルであり、アーキテクチャ固有であるということです。つまり、標的を知っている必要があります。標的組織が使用する Microsoft Office/Excel のバージョンによって、（通常は）ペイロードをどのアーキテクチャ用にビルドするかが決まります。
Office のバージョンにはかなり明確な区切りがあり、目安として使用できます。
Office 2016 以前：x86
Office 2019 以降：x64
各製品に別のアーキテクチャをインストールすることも可能ですが、これらがデフォルトでインストールされるアーキテクチャであり、ほとんどの場合、XLL をどのアーキテクチャでロールするかを決定する信頼できる方法となるはずです。もちろん、フィッシングキャンペーンで使用する配信方法や pretext によっては、両方のバージョンを提供し、被害者が自分のシステムに適したバージョンを選択できるようにすることも可能です。
本調査で構築された XLL ペイロードは、edparcell によるこのプロジェクトに基づいています。彼のリポジトリには、Visual Studio で XLL を始めるための良い手順が記載されており、私はそのコードを悪意のある XLL ファイルを開発するための出発点として使用しました。
彼のリポジトリからの注目すべき変更点は、独自の XLL プロジェクトを作成したい場合、最新の Excel SDK をダウンロードし、README に記載されている SDK の 2010 バージョンではなく、このバージョンを使用して以前にリンクしたリポジトリの指示に従う必要があることです。
UDA の文脈では、ペイロードの配信は重要な考慮事項です。ここでは主に 2 つの方法に焦点を当てます。
ファイルを添付するか、ファイルをダウンロードできる Web サイトへのリンクを含めるかのいずれかで、メールは UDA プロセスの重要な部分です。長年にわたり、多くの組織（およびメールプロバイダー）は成熟し、悪意のある添付ファイルからユーザーと組織を保護するためのルールを強化してきました。効果はさまざまですが、組織は現在、以下のことが可能になっています。
組織のメールルールを調査することは、エンゲージメントの重要な部分になり得ますが、レッドチーム作戦が進行中であり、情報が積極的に収集されていることを明らかにしないように、常に注意を払う必要があります。
この記事の目的上、標的組織は強固なメール添付ルールを採用しており、XLL ペイロードの配信を防止しているものと仮定します。そこで、Web 配信に目を向けます。
この攻撃ベクトルでもメールは使用されますが、添付ファイルを送信する代わりに、Web サイトへのリンクを送信するために使用されます。許可されるファイルダウンロードタイプを制御する Web プロキシルールやネットワーク対策は、メール添付に関して実施されているものとは異なる場合があります。この記事の目的上、組織は Web からの実行可能ファイル（MZ ヘッダ）のダウンロードを防止しているものと仮定します。この場合、パッカー/コンテナを検討する価値があります。
前提としては、実行可能ファイルを別のファイルタイプの中に隠して、組織のポリシーを通り抜けられるかもしれないということです。ここでの主要な考慮事項は、ファイルタイプのネイティブサポートです。たとえば 7Z ファイルは、サードパーティ製ソフトウェアをインストールしないと Windows で開くことができないため、良い選択肢ではありません。ZIP、ISO、IMG などの形式は Windows でネイティブサポートされているため魅力的な選択肢であり、さらに被害者にとってほとんど手間がかからないという利点もあります。
しかし、組織は残念ながら ISO と IMG の Web からのダウンロードをブロックしています。さらに、データ損失防止（DLP）を導入しているため、ユーザーは外部ストレージデバイスをマウントできず、ISO と IMG はそれに該当します。
幸いなことに、組織は MZ ヘッダを持つファイルのダウンロードを防止しているものの、実行可能ファイルを含む zip ファイルのダウンロードは許可しています。これらの zip ファイルはマルウェアに対して積極的にスキャンされ、パスワード保護された zip ファイルについてはユーザーにパスワードの入力を求められますが、実行可能ファイルが zip されているため、MZ ファイルに対する全体的な拒否ルールによってブロックされることはありません。
Zip ファイルは、XLL ペイロードのコンテナとして選択されました。その理由は以下の通りです。
便利なことに、Windows で ZIP ファイルをダブルクリックすると、ファイルエクスプローラーでその zip ファイルが開きます。
不便なことに、zip の場所から XLL ファイルをダブルクリックすると、Windows Defender がトリガーされます。edparcell の悪意のあるコードを含まない標準のプロジェクトを使用した場合でも同様です。
Windows Defender のアラートを見ると、単なる一般的な "Wacatac" アラートです。
しかし、何か奇妙なことがあります。悪意があると識別されたファイルは、c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip\ にありました。ダブルクリックした場所である C:\users\user\Downloads\ZippedXLL\ ではありません。ProcessExplorer で Excel のインスタンスを確認すると、Excel が実際に XLL を appdata\local\temp から実行しており、元の ZIP ファイルからではありません。
これは ZIP ファイルに関連する問題であり、XLL 固有の問題ではないようです。ZIP 内から TXT ファイルをメモ帳で開くと、TXT ファイルも appdata\local\temp にコピーされ、そこから開かれます。この場所からテキストファイルを開くことは問題ありませんが、Defender はこの場所でのあらゆる種類の実際のコード実行を悪意のあるものとして識別するようです。
ユーザーが ZIP ファイルから XLL を抽出してから実行すれば、問題なく実行されます。しかし、ユーザーがそうすることを保証する方法はなく、抽出しなかった場合に AV/EDR を発動させるリスクを負うわけにはいきません。それに、ZIP をダブルクリックしてから XLL をダブルクリックする方がはるかに簡単であり、被害者は ZIP を抽出する手間をかけるよりも、その簡単な操作を完了する傾向があります。
この問題により、XLL とは異なるペイロードタイプを検討し始めました。VSTO（Visual Studio Templates for Office）を調べ始めました。この記事を強くお勧めします：https://medium.com/@airlockdigital/make-phishing-great-again-vsto-office-files-are-the-new-macro-nightmare-e09fcadef010
VSTO は最終的に DLL を呼び出します。この DLL は、すべてを開始する .XLSX とローカルに配置することも、.XLSX が http/https 経由でダウンロードするリモートにホストすることもできます。ローカルオプションには実際の利点はなく（実際、VSTO 攻撃に関連するファイルがさらに増えるなどの欠点があります）、リモートオプションは残念ながらコード署名証明書が必要か、リモートの場所が信頼できるネットワークである必要があります。有効なコード署名証明書を持っていないため、VSTO は、XLL ペイロードが直面しているこのシナリオの問題を軽減できません。
どうやら八方塞がりのようです。XLL 自体の実行は問題ありませんが、組織のポリシーにより、XLL をメール添付や Web ダウンロードで被害者に直接配信することはできません。XLL はコンテナ内にパッケージ化する必要がありますが、DLP のため ISO、IMG、VHD などの形式は使用できません。被害者はサードパーティ製ソフトウェアなしでコンテナをネイティブに開くことができる必要があり、ZIP が唯一の選択肢となります。しかし、前述のとおり、ZIP フォルダから XLL を実行すると、appdata\local\temp にコピーされて実行され、AV がフラグを立てます。
何時間もブレインストーミングとテストを行い、VSTO のうさぎ穴に落ち、考えられるすべての選択肢を探りましたが、最終的に、バカげているがうまくいくかもしれない方法を試してみることにしました。
今回は、フォルダを作成し、その中に XLL を配置してから、フォルダを zip 化しました。
フォルダをクリックすると、XLL ファイルが表示されます。
XLL をダブルクリックすると、Excel からアドインプロンプトが表示されます。XLL は依然として appdata\local\temp にコピーされていますが、作成した追加のフォルダにより、もう 1 つのレイヤーが存在することに注意してください。
有効にするをクリックすると、Defender にフラグを立てられることなくコードが実行されます。
