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 にフラグを立てられることなくコードが実行されます。
素晴らしい！コード実行ができました。さて、次は？
被害者に XLL をダウンロードさせて実行させるための pretext（偽装）は、組織と配信方法によって大きく異なります。テーマとしては、従業員の給与データ、スキルセットに基づく報酬計算ツール、プロジェクトに関する情報、イベントの参加者名簿などが考えられます。どんな餌であれ、約束したものを実際に被害者に提供できれば、攻撃ははるかに効果的になります。フォロースルーがなければ、被害者は疑念を抱き、ドキュメントをセキュリティチームに報告する可能性があり、攻撃者はすぐに露見し、ターゲットシステムへのアクセスを制限される可能性があります。
XLL だけでは、コードの実行が完了した後、空白の Excel ウィンドウが残るだけです。被害者が探している Excel スプレッドシートを提供できればはるかに良いでしょう。
XLSX をバイト配列として XLL 内に埋め込むことができます。XLL が実行されると、XLSX が XLL の隣にディスクにドロップされ、その後開かれます。XLSX には XLL と同じ名前を付け、拡張子のみを異なるものにします。
XLL は C で記述されているため、以前の記事「Payload Capabilities in C」で説明した機能、特に自己削除機能を取り入れることができます。これら 2 つのテクニックを組み合わせることで、XLL がディスクから削除され、代わりに同じ名前の XLSX がドロップされます。注意深く見ない限り、最初から XLSX があったように見えます。
残念ながら、XLL が削除され XLSX がドロップされる場所は appdata\temp\local フォルダであり、元の ZIP ではありません。これに対処するために、XLSX のみを含む 2 番目の ZIP を作成し、それも XLL 内のバイト配列として読み込むことができます。実行時に、前述のアクションに加えて、XLL は元の ZIP ファイルを c:\users\victim\Downloads\ 内で見つけようとし、それを削除して、XLSX のみを含む 2 番目の ZIP をその場所にドロップすることができます。ユーザーが元の ZIP を別の場所や別の名前で保存した場合、これは失敗する可能性がありますが、ほとんどの場合、自動的にユーザーのダウンロードフォルダにドロップされるはずです。
このスクリーンショットでは、下のペインに appdata\local\temp に作成された temp フォルダが表示され、XLL とドロップされた XLSX が含まれています。上のペインは、XLL が開かれた元のファイルエクスプローラーウィンドウを示しています。下のペインで、XLL のサイズが 0 であることに注意してください。これは、実行中に自己削除されたためですが、上のペインが閉じられるまで、XLL ファイルは appdata\local\temp の場所から完全には消えません。被害者が再度 XLL をクリックしても、今は不活性であり、実際には存在しません。
同様に、被害者がファイルエクスプローラーで開かれた ZIP をバックアウトする（閉じるか別のフォルダに移動する）とすぐに、spreadsheet.zip をクリックすると、test フォルダに importantdoc.xlsx が含まれていることがわかります。つまり、XLL はディスク上の両方の場所で削除され、無害な XLSX に置き換えられています。
この GIF は、MDE トライアル VM での XLL のダウンロードと実行を示しています。なぜか Excel がここでは 2 つのインスタンスを開いています。自宅のコンピュータでは 1 つだけだったので、なぜ異なるのかはわかりません。
いつものように、「MDE は何を検出するのか？」と尋ねます。
これをターゲット上で実行し、TestMachine11 でビーコンを受信したことを証明する簡単なスクリーンショットです。
まず、アラートはゼロです。
タイムライン/イベントログは何をキャプチャしているのでしょうか？
うわっ。正直なところ、キーロギング、暗号化、復号化の資格情報アラートがどこから来ているのかわかりません。私のコードはそのようなことは一切行っていません。私たちのアクションは確かにこのように並べると怪しく見えますが、MDE が単一のエンドポイントからどれだけのデータを収集するか、ましてや組織が EDR に接続している数百、数千、あるいは数十万のエンドポイントからどれだけのデータを収集するかを改めて指摘しておきます。実際のアラートが発生しなければ、おそらく大丈夫でしょう。
おそらく多くの方が待ち望んでいた瞬間です。私が開発した XLL ランナーのコードサンプルを提供します。ただし、トレードクラフトのセクションで説明した部分のみに限定します。コードを実際に XLL に組み込み、ランナーの残りの部分と一緒に実装するのは読者の責任です。いつものように、害を及ぼさないこと、組織に対してフィッシングの許可を得ていることなどを守ってください。
ファイルを取り込み、スニペットで定義されたバイト配列にコピーできる 16 進数を生成するプログラムのソースコードを含めています。これを、ユーザーに提示する XLSX と、同じ XLSX を含むフォルダを含む ZIP ファイルの両方に使用し、それぞれのバイト配列に保存します。このコードを次のようにコンパイルします。``` gcc -o ingestfile ingestfile.c
MingWを使用してKaliマシン上でXLLをコンパイルする際に問題が発生したため、ここにコマンドを投稿しようと思いました：
**x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
コンパイル後、新しいフォルダを作成し、そのフォルダにXLLをコピーします。その後、次を使用してzip圧縮します：```
zip -r <myzipname>.zip <foldername>/
Note that in order for the tradecraft outlined in this post to work, you are going to need to match some variables in the code snippet to what you name the XLL and the zip file.
With the dominance of Office Macro's coming to a close, XLL's present an attractive option for phishing campaigns. With some creativity they can be used in conjunction with other techniques to bypass many layers of defenses implemented by organizations and security teams. Thank you for reading and I hope you learned something useful!