Dentの最新版を表示したり、問題を報告したりするには、 https://github.com/Tylous/Dent を参照してください。
Dent
このフレームワークで使用されている技術について詳しく知りたい場合は、この記事を参照してください。
このフレームワークは、Microsoft Defender Advanced Threat Protectionの攻撃表面領域縮小（ASR）ルールの脆弱性を悪用し、検出や防止されることなくシェルコードを実行するコードを生成します。ASRは防御の最前線として設計されており、一連のルールに違反するアクションに基づいてイベントを検出します。これらのルールは、攻撃者の戦術、技術、手順（TTP）に関連することが多いエンドポイント上の特定の動作指標に焦点を当てています。これらのルールは、Microsoft Officeスイートに重点を置いており、これはエンドポイントへのリモート足がかりを確立するための一般的な攻撃ベクトルです。ルールベースの制御の多くは、通常の業務運用とは異なるネットワークベースまたはプロセスベースの動作指標に焦点を当てています。これらのルールは、システムの初期侵害、または組織に深刻な影響を与える可能性のある技術（例：資格情報の漏洩やランサムウェア）に焦点を当てています。これらは一般的な攻撃表面の大部分をカバーし、資産を侵害するために使用される既知の技術を妨害することに重点を置いています。
Dentは、これらの制限的な制御をバイパスし、Microsoft Defender Advanced Threat Protectionセンサーによってブロックされたり効果的に検出されたりすることなく、エンドポイント上でペイロードを実行するために、いくつかの脆弱性を利用します。上記の記事は、開示後もMicrosoft Defender Advanced Threat Protectionに依然として存在する脆弱性について概説しています。
最初のステップはいつものようにリポジトリをクローンし、ビルドすることです。
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
「誰かを長く英雄と呼べば、彼らはそれを信じる。彼らはそうなる。
彼らには選択肢がない。あなたを怪物と呼ばせれば、あなたは怪物になる。」
./Dentの使用法:
-C string
COMオブジェクトの名前。
-N string
ディスクに書き込まれるXLLペイロードの名前。
-O string
出力ファイルの名前。 (デフォルト "output.txt")
-P string
COMオブジェクトのDLLへのパス。 (パスの周りに\\を使用するか、''を使用)
-U string
base64エンコードされたXLLペイロードがホストされているURL。
-show
ターミナルにスクリプトを表示します。
このフレームワークは、Microsoft Defender Advanced Threat Protectionの脆弱性や欠陥を悪用することを目的としているため、実際のペイロード/インプラントは生成しません。これらを生成するには、公開されている多数のツールを使用できますが、すべての研究、開発、テストはScareCrowを使用して行われました。Microsoft Defender Advanced Threat Protectionは、テレメトリにユーザーランドフックを使用せず、代わりにカーネルコールバックなどのさまざまな他のメカニズムを利用します。テストの結果、このフレームワークはシェルコードを実行するためにMicrosoft Defender Advanced Threat Protectionをバイパスするのに非常に効果的です。
リリース時点では、現在2つの技術があります。これらの脆弱性を異なる方法で利用するさまざまな技術を定期的に追加していく予定ですので、今後の情報をお待ちください。
COMオブジェクトは、アプリケーションがシステムにインストールされるときに作成されることがよくあります。作成されると、任意のアプリケーションやスクリプトから呼び出すことができますが、これが唯一の作成方法ではありません。WindowsレジストリのHKEY_CLASSES_ROOTセクションにレジストリキーを変更/作成することで、システム上のシェルコードを指すCOMオブジェクトを作成できます。つまり、COMを利用できる任意のアプリケーションやスクリプトがそれを呼び出し、シェルコードを実行できるということです。
これは、CoCreateInstance API関数の動作方法により機能します。CoCreateInstanceは、CLSID（特定のCOMクラスオブジェクトを識別するために使用されるグローバルに一意な識別子）に基づいてCOMオブジェクトを作成および初期化するために使用されます。この関数は、レジストリキーに格納された値を使用して呼び出しを実行するための情報を取得します。これらのCLSID値は、レジストリのHKEY_CLASSES_ROOT\CLSID\パスにあります。ただし、プロセスがCLSIDを呼び出す前に、そのCLSIDの値を認識している必要があります。これは、まずHKEY_CLASSES_ROOT\<COMオブジェクト名>でCOMオブジェクトを検索するレジストリクエリを実行し、存在する場合は、サブフォルダに格納されているCLSID値を取得するために2回目のレジストリクエリが行われます。
レジストリのサブフォルダをさらに調査すると、CLSID値の権限が一貫していないことがわかります。ここに格納されているCOMオブジェクトの大部分は、「完全制御」権限をTrusted Installerにのみ許可しています。Trusted Installerは、管理者からもリソースを保護するためにリソースを所有するサービスアカウントです。これは、攻撃者が管理者権限を取得した場合でも、リソースが悪意を持って操作されないようにするためのものです。残念ながら、多くのCOMオブジェクトはAdministratorsグループの誰にでも「完全制御」権限を許可しています。さらに、ルートキーCLSIDは、NT AUTHORITY\SystemやTrusted Installerではなく、Administratorsグループに「完全制御」権限を許可しています。このため、昇格されたコンテキストでは、特定のCOMオブジェクトの値を作成したり、変更したりすることができます。
重要
これらのレジストリキーの作成は、昇格されたコンテキストで実行した場合にのみ機能します。GUIからダブルクリックしても、管理者であっても、.VBSファイルは昇格されたコンテキストで実行されません。管理シェルまたはコマンドプロンプトから実行することをお勧めします。ただし、キーが作成されると、任意のアプリケーションが任意のコンテキストでこのCOMオブジェクトを呼び出すことができます。
このタイプのバイパスでScareCrowペイロードを利用するには、次のコマンドを実行できます：
./ScareCrow -I <rawのステージレスシェルコードへのパス> -domain <ドメイン名> -Loader dll
ペイロードを入手したら、-Nフラグでディスクに書き込まれるペイロードの名前、-CフラグでCOMオブジェクトの名前、-Iフラグで書き込み先の場所、最後に-Oフラグでコンテンツを保存する出力ファイルを指定します。
このオプションは、いくつかのASRルールをバイパスして、シェルコードをダウンロード、ディスクに書き込み、ロードおよび実行するコードブロックを生成し、ASRの予防的制御を回避します。これは、Excel.Application COMオブジェクトを使用して行われます。このオブジェクトはExcelアプリケーション全体を表しますが、自動化された形式であり、プログラムによる操作を可能にします。これが依然としてExcelであるため、ASRルールはトリガーされません。これは、Excel.Applicationを呼び出すと、Service Hostプロセス（Svchost.exe）の下で生成され、WinWord.exeプロセスではないためです。Svchost.exeは複数のWindowsベースのサービスをホストするために使用されるシステムレベルのプロセスですが、作成された子プロセス（Excel.exe）はシステムレベルの特権を取得しませんでした。
アプリケーション全体であるCOMオブジェクトを作成したため、ExcelプロセスはSvchost.exeの下で作成され、WinWord.exeプロセスへの不安定性を防ぐために適切に処理されました。このプロセスはSvchost.exeの下にありますが、対処すべき別の課題があります：シェルコードの実行です。マクロ内でのバイナリ実行やWinAPIの使用は他のASRルールをトリガーするため、ASRルールをトリガーしたりWDAPTのEDRコンポーネントに捕捉されたりせずに実行できることは限られています。ここでDLLが威力を発揮します。適切なエクスポート関数でコンパイルされたDLLベースのペイロードは、Officeプラグインとして使用でき、ロードされると自動的にシェルコードを実行します。これを行うには、ExcelのRegisterXLL関数を利用できます。RegisterXLL関数はXLLプラグインをメモリにロードし、自動的に登録および実行します。XLLファイルは基本的にExcelベースのDLLです。
システムにコンテンツを取得するために、別のCOMオブジェクト（Microsoft.XMLHTTP）を使用してHTTPリクエスト（この場合はURLへのHTTP GETリクエスト）を実行できます。2番目のCOMオブジェクト（ADODB.stream）は、データストリームのバイトの読み取り/書き込み機能を提供します。これら2つのCOMオブジェクトを組み合わせることで、攻撃者はHTTP GETリクエストを介してリモートリソースを要求し、応答（この場合はファイル自体）をディスクに書き込むことができます。これは、ADODB.stream COMオブジェクトを再度使用してデータストリームのバイトの読み取り/書き込みを処理することで行われます。2番目のCOMオブジェクト（Microsoft.XMLDOM）は、ファイルに保存されたデータの読み取りを可能にします。XMLDOMオブジェクトはデータ型の設定（この場合はbase64）を可能にし、適切なデータ型でファイルを開いて文字列に保存すると、ADODB.streamオブジェクトは異なるデータ型（この場合はBinaryStreamType）を使用してコードの文字列をディスクに書き込み、base64文字列をバイナリ形式に変換します。
このタイプのバイパスでScareCrowペイロードを利用するには、次のコマンドを実行できます：
./ScareCrow -I <rawのステージレスシェルコードへのパス> -domain <ドメイン名> -Loader excel -O <出力ファイル名>
生成されたら、出力ファイルの13行目と14行目をコピーしてマージし、以下のものを削除します：
var <変数名>;
エンコードされたペイロードを入手したら、-Nフラグでディスクに書き込まれるペイロードの名前、-UフラグでエンコードされたペイロードがホストされるURL（例：https:///）、-Fフラグでサイトでホストされるファイルの名前を指定します。出力されたコードはマクロドキュメントで動作するように設計されています。
さらなる調査を通じて、これはWDATPのセンサーのギャップではなく、WDATPがこのアクティビティを可視化しているものの、無視されていることが観察されました。WDATPエンドポイントのイベントタイムラインでAppwiz.xllへの参照を検索したところ、WordがファイルAppWiz.xllを作成したときにWDATPが「ファイル作成」イベントを記録したことが観察されました。重要なのは、.XLLファイルが実行可能であることです。
2020年11月20日 - 研究開発と記事の執筆。
2021年3月14日 - 特定された問題を概説した予備的な開示文書をMicrosoftに提出。
2021年3月31日 - Microsoftは、Officeの子プロセスの生成とファイルのディスクへの書き込みに関連する脆弱性が実際の脆弱性であることを認識し、是正措置の作業を開始しました。ただし、レジストリの権限の不整合は、昇格された特権が必要であるため、脆弱性ではないと判断されました。
2021年4月21日 - Microsoftは、2021年3月22日にリリースされたシグネチャビルド1.333.1055.0と2021年4月21日にリリースされた1.335.1321.0にOfficeアプリケーションベースの脆弱性の検出が含まれていることを著者に通知し、ケースをクローズしました。
2021年4月22日 - 著者は同じ技術を再テストし、脆弱性が依然として存在することを確認しました。