はじめに

7月、Googleは、Windows上のChrome内に保存されたCookieに対する新しい保護メカニズム、Application-Bound Encryptionを発表しました。このセキュリティ実装がハードルを上げ、マルウェアのエコシステムに直接影響を与えたことは間違いありません。この新機能を数か月使用した後、多くのインフォスティーラーは、市場での競争力を維持し、ChromeブラウザからCookieデータを確実に取得する機能を提供するために、この保護を回避する新しいコードを作成しました(Chromeセキュリティチームが予測したように)。

Elasticセキュリティラボは、この活動の一部を追跡し、さまざまなマルウェアファミリーがApp-Bound Encryptionを回避するために使用する複数の手法を特定しています。この圧力に照らしてエコシステムはまだ進化していますが、私たちの目標は、組織がこれらの手法を理解し、防御するのに役立つ技術的な詳細を共有することです。この記事では、次のインフォスティーラーファミリーで使用されるさまざまな方法について説明します。

• STEALC/VIDARの
• METASTEALER
• フェメドロン
• ゼノスティーラー
• LUMMA

重要なポイント

• 最新バージョンのインフォスティーラーは、アプリケーションバウンド暗号化を使用して、Googleの最近のCookie保護機能を回避するバイパスを実装しています
• 手法には、攻撃的なセキュリティツールChromeKatzの統合、COMを活用したChromeサービスとの対話とアプリにバインドされた暗号化キーの復号化、Chrome内のリモートデバッグ機能の使用などがあります
• 防御側は、Windows 上の Chrome に対するさまざまな Cookie バイパス手法を積極的に監視し、近い中期的に発生する可能性のある将来の緩和策とバイパスを予測する必要があります
• Elasticセキュリティは、メモリシグネチャ、動作ルール、ハンティングの機会を通じて緩和策を提供し、インフォスティーラーのアクティビティをより迅速に特定して対応できるようにします

背景

一般的に言えば、Cookieは、訪問者がそのWebアプリにアクセスするために使用するブラウザに訪問者情報を保存するためにWebアプリケーションによって使用されます。この情報は、Web アプリがそのユーザー、ユーザーの好み、およびその他の情報を場所ごとに、さらにはデバイス間で追跡するのに役立ちます。

認証トークンは、クライアント側のデータストレージ構造の1つの用途であり、最新のWebインタラクティビティの多くの機能を可能にします。これらのトークンは、ユーザーが Web アプリケーションで正常に認証された後に、ブラウザーによって保存されます。ユーザー名とパスワードの後、ワンタイムパスコードまたは生体認証による多要素認証(MFA)の後、Webアプリケーションは、このトークンを後続のWebリクエストと交換することで、ブラウザがあなたであることを「記憶」します。

有効な認証トークンにアクセスした悪意のあるアクターは、それを再利用して、アカウントを乗っ取ったり、個人情報や財務情報を盗んだり、そのユーザーとして金融資産の転送などの他のアクションを実行したりして、そのWebサービスにユーザーになりすますことができます。

サイバー犯罪者は、インフォスティーラーを使用して、金銭的利益のためにこの種の情報を盗み、商品化します。

Google Chrome の Cookie のセキュリティ

Windows 上の従来のバージョンの Google Chrome では、Windows ネイティブの データ保護 API (DPAPI)を使用して Cookie を暗号化し、他のユーザー コンテキストから Cookie を保護していました。これにより、いくつかの攻撃シナリオに対して適切な保護が提供されましたが、標的となるユーザーのコンテキストで実行されている悪意のあるソフトウェアは、DPAPIメソッドを直接使用してこれらのCookieを復号化する可能性があります。残念ながら、このコンテキストは、インフォスティーラーが初期アクセスのためにソーシャルエンジニアリングの後によく見つけるニッチです。DPAPIスキームは、現在、いくつかの攻撃ベクトルを持つ 攻撃者によく知られています 。APIを使用したローカル復号化から、マスターキーの盗難とリモートでの復号化、エンタープライズ環境でのドメイン全体のバックアップDPAPIキーの悪用まで。

2024年7月のChrome 127 のリリースに伴い、Googleはブラウザデータのアプリケーションバウンド暗号化 を実装しました 。このメカニズムは、Cookie を含む Windows Chrome ブラウザのデータに対する多くの一般的な DPAPI 攻撃に直接対処しました。これは、暗号化されたデータファイルにデータを保存し、SYSTEMとして実行されているサービスを使用して、保存されたデータの復号化のためにそのプロセスにキーを返す前に、Chromeプロセスからの復号化の試みを確認することによって行われます。

この暗号化方式は、すべてのブラウザデータを保護するための万能薬ではないと考えていますが(Chromeセキュリティチームがリリースで認めているように)、マルウェア作成者をより明白に悪意のあるTTPに誘導し、防御者が特定して対応することが容易になったと感じています。

スティーラーバイパス技術、まとめ

次のセクションでは、Elasticが観察したGoogleのApp-Bound Encryption機能を回避するために使用される特定のインフォスティーラー手法について説明します。これはバイパスの網羅的な編集ではなく、これらのファミリの開発は進行中ですが、マルウェア開発者が最近更新されたGoogleのセキュリティ制御にどのように対応したかを示す、インフォスティーラースペース内の興味深いダイナミクスを表しています。私たちのチームが観察した手法は次のとおりです。

• Chrome の DevTools プロトコルによるリモート デバッグ
• Chromeネットワークサービスプロセス(ChromeKatzおよび ReadProcessMemory （RPM）)のプロセスメモリの読み込み
• SYSTEMに昇格し、COMを介してGoogleChromeElevationServiceするDecryptData方法でapp_bound_encryption_keyを復号化します

STEALC/VIDARの

私たちのチームは、9月20日頃にSTEALC / VIDARに導入されたCookieバイパス技術に関連する新しいコードを観察しました。これらは、以前のバージョンとは一線を画す非定型的なサンプルであり、条件付きチェックとともに埋め込み 64 ビット PE ファイルとして実装されました。Chrome がデータを保存する SQLite データベース内の暗号化された値には、アプリケーションバウンド暗号化を使用して値が暗号化されるようになったことを示す v20 のプレフィックスが付けられるようになりました。

STEALC は 2023 年に導入され、 RACOON や VIDARなどの他のより確立されたスティーラーからの「重いインスピレーション」で開発されました。STEALCとVIDARは並行して開発を続けており、App-Bound Encryptionの場合、バイパスは同じ実装に落ち着いています。

データベースから暗号化されたデータを抽出する際に、マルウェアはこのプレフィックスをチェックします。で始まる場合 v20、バイナリの .data セクションに埋め込まれた PE ファイルを使用して子プロセスが生成されます。このプログラムは、Chromeの子プロセスの1つに存在する暗号化されていないCookie値を抽出する役割を果たします。

この埋め込みバイナリは、 OpenDesktopA / CreateDesktopA を介して非表示のデスクトップを作成し、 CreateToolhelp32Snapshot を使用してすべての chrome.exe プロセスをスキャンおよび終了します。その後、新しいデスクトップ オブジェクトを使用して新しい chrome.exe プロセスが開始されます。マルウェアは、インストールされているChromeのバージョンに基づいて、Cookieの管理に使用される内部コンポーネントである Chromium機能CookieMonsterの署名パターンを選択します。

シグネチャパターンを使用して、ChromeKatzと呼ばれる攻撃的なセキュリティツール用に開発された既存のコードにピボットしました。この時点で、パターンはChromeKatzリポジトリから削除され、新しい手法に置き換えられました。私たちの分析に基づくと、マルウェアの作成者は、アプリにバインドされた暗号化保護機能を回避するために、STEALC内にChromeKatzを再実装したようです。

マルウェアは、一致する署名を特定すると、Chromeの子プロセスを列挙して、 --utility-sub-type=network.mojom.NetworkService コマンドラインフラグの存在を確認します。このフラグは、プロセスがすべてのインターネット通信の処理を担当するネットワーク サービスであることを示します。MDSecの 投稿で説明されているように、攻撃者が探している機密データを保持しているため、主要なターゲットになります。その後、その特定の子プロセスのハンドルを返します。

次に、ネットワーク サービスの子プロセス内の各モジュールを列挙して、メモリにロードされた chrome.dll のベース アドレスとサイズを見つけて取得します。STEALC は、CredentialKatz::FindDllPattern と CookieKatz::FindPattern を使用して CookieMonster インスタンスを見つけます。CredentialKatz::FindDllPatternへの 2 呼び出しがあります。

CredentialKatz::FindDllPatternへの最初の呼び出しでは、chrome.dllの署名パターンの 1 つ(被害者の Chrome バージョンによって異なります)を見つけようとします。見つかると、STEALC は、バイト シーケンスが始まるメモリ位置への参照ポインターを持ち、これが CookieMonster クラスの関数 net::CookieMonster::~CookieMonsterデストラクタです。

CredentialKatz::FindDllPattern の 2 回目の呼び出しでは、バイト シーケンス検索の引数として net::CookieMonster::~CookieMonster(void) の関数アドレスが渡されるため、STEALC は CookieMonsterの仮想関数ポインタ構造体へのポインタを持つことになります。

STEALC で使用される次の方法は、ChromeKatz と同じで、chrome.dll モジュール内のメモリ チャンクをスキャンして CookieMonster vtable を参照するポインタを探すことで、CookieMonsterインスタンスを特定します。vtable は特定のクラスのすべてのオブジェクトで定数であるため、どの CookieMonster オブジェクトも同じ vtable ポインターを持ちます。一致が識別されると、STEALC はメモリ位置を CookieMonster インスタンスとして扱い、そのアドレスを配列に格納します。

識別されたCookieMonsterインスタンスごとに、STEALC は +0x30のオフセットにある 2 分木の内部CookieMap構造体にアクセスします。このツリー内の各ノードには、 CanonicalCookieChrome 構造体へのポインターが含まれています。CanonicalCookieChrome 構造体は暗号化されていないCookieデータを保持しているため、抽出のためにアクセスできます。次に、STEALC は、最初のノードを専用のトラバーサル関数に渡すことにより、ツリートラバーサルを開始します。

ノードごとに、 ReadProcessMemory を呼び出してターゲット プロセスのメモリから CanonicalCookieChrome 構造体にアクセスし、さらに jy::GenerateExfilStringで処理します。

STEALC は、有効期限を UNIX 形式に変換し、 HttpOnly フラグと Secure フラグの存在を確認することで、抽出された Cookie データをフォーマットします。次に、Cookieの名前、値、ドメイン、パス、 HttpOnly と Secure などの詳細を最終的な文字列に追加して抽出します。OptimizedString構造体は文字列の代わりに使用されるため、文字列値は文字列自体にすることも、文字列の長さが 23 を超える場合は、文字列を格納するアドレスを指すこともできます。

METASTEALER

2022年に初めて観測されたMETASTEALERは、Googleの最新の緩和策を回避して、最近Chromeデータを盗む機能をアップグレードしました。9月30日、マルウェアの作成者は、Telegramチャネルを通じてこのアップデートを発表し、Chromeのバージョン 129+のセキュリティ変更にもかかわらず、Cookieを含む機密情報を抽出する機能が強化されていることを強調しました。

私たちのチームが野生で観察した 最初のサンプル は、著者がアップデートを推進したのと同じ9月30日に発見されました。このマルウェアは Administrator 権限を必要とせずに動作すると主張していますが、私たちのテストでは、実行中に SYSTEM トークンを偽装しようとするため、昇格されたアクセスが必要であることが明らかになりました。

上のスクリーンショットで示されているように、 get_decryption メソッドには新しいブールパラメーターが含まれています。暗号化されたデータ(Cookie)がv20プレフィックスで始まる場合、この値はTRUEに設定され、CookieがChromeの最新の暗号化方法を使用して暗号化されていることを示します。更新された機能は下位互換性を保持し、感染したマシンに古いChromeバージョンからのCookieが存在する場合は、引き続きCookieの復号化をサポートします。

その後、マルウェアはChromeプロファイルディレクトリにある Local State ファイルまたは LocalPrefs.json ファイルにアクセスしようとします。どちらのファイルもJSON形式で、古いChromeバージョンの場合は暗号化キー(encrypted_key)を、新しいChromeバージョンの場合は app_bound_encrypted_key キーを保存します。フラグが TRUEに設定されている場合、マルウェアは特に app_bound_encrypted_key を使用して、更新されたChrome暗号化方法に沿ってCookieを復号化します。

この場合、マルウェアは最初に、新しく導入された ContextSwitcherというクラスを使用して SYSTEM トークンを偽装します。

次に、CLSID 708860E0-F641-4611-8895-7D867DD3675Bを使用して、復号化を担当する Chrome サービス (GoogleChromeElevationServiceという名前の) の COM を介してインスタンスを作成することで、キーを復号化します。初期化されると、 DecryptData メソッドを呼び出して、暗号化されたCookieの復号化に使用される app_bound_encrypted_key キーを復号化します。

METASTEALERは、9月27日に Xで 共有された 要点 で示されたものと同様の手法を採用しており、マルウェアの作成者にインスピレーションを与えた可能性があります。どちらのアプローチも、同様の方法を利用して Chrome の暗号化メカニズムを回避し、機密データを抽出します。

フェメドロン

この オープンソースのスティーラー は、Windows SmartScreen の脆弱性 (CVE-2023-36025) を使用して、今年の初めに世界の注目を集めました。その開発はまだTelegramで行われていますが、私たちのチームは9月末に提出された最近の リリース (2.3.2)にChrome用の新しいCookieグラバー機能が含まれていることを発見しました。

マルウェアは、最初にChrome内のさまざまなプロファイルを列挙し、次に関数(BrowserHelpers.NewEncryption)を使用してブラウザチェックを実行します。次に、バージョンが 127以上のChromeブラウザをチェックします。

条件が一致する場合、PHEMEDRONEはヘルパー関数の組み合わせを使用してCookieを抽出します。

ChromeDevToolsWrapperクラスとそのさまざまな関数を見ると、PHEMEDRONEがChrome内でリモートデバッグセッションを設定してCookieにアクセスしていることがわかります。デフォルトのポート(9222)は、window-positionを -2400に設定し、画面外に設定するとともに使用され-2400 表示されているウィンドウが被害者に警告しないようにします。

次に、マルウェアはChromeのデバッグインターフェイスへのWebSocket接続を確立し、非推奨のChrome DevTools Protocolメソッド(Network.getAllCookies)を使用してリクエストを行います。

その後、Cookieは前のリクエストからプレーンテキストで返されますが、以下はこの動作を示すネットワークキャプチャです。

ゼノスティーラー

XENOSTEALER は、GitHub でホストされているオープンソースのインフォスティーラーです。 2024 年7月に登場し、この公開時点では活発に開発されています。特に、Chromeバイパス機能は2024年9月26日にコミットされました。

XENOSTEALERが採用するアプローチは、METASTEALERのアプローチと似ています。まず、特定のChromeプロファイルの下のJSONファイルを解析して、 app_bound_encrypted_keyを抽出します。ただし、復号化プロセスはChromeプロセス内で行われます。これを実現するために、XENOSTEALER は Chrome.exeのインスタンスを起動し、 SharpInjectorというヘルパークラスを使用してコードを挿入し、暗号化されたキーをパラメータとして渡します。

その後、挿入されたコードは、GoogleChromeElevationServiceから DecryptData メソッドを呼び出して、復号化されたキーを取得します。

LUMMA

10 月中旬、 LUMMA の最新バージョンは、@g0njxaが報告したように、ChromeのCookie保護を回避する新しい方法を実装しました。

最新バージョンのLUMMAを分析したところ、最新バージョンのGoogle Chrome(130.0.6723.70)からCookieデータを正常に回復できたことを確認しました。LUMMAはまず、 Kernel32!CreateProcessWを介して目に見えるChromeプロセスを作成します。

このアクティビティは、デバッガーで NtReadVirtualMemory への複数回の呼び出しでフォローアップされ、Chrome プロセス内で chrome.dllの LUMMA 検索が特定されました。

マルウェアが見つかると、マルウェアはNtReadVirtualMemoryを使用してchrome.dllイメージを自身のプロセスメモリにコピーします。ChromeKatzの手法と同様に、Lummaはパターンスキャンを活用してChromeの CookieMonster コンポーネントをターゲットにします。

Lummaは、難読化された署名パターンを使用して、 CookieMonster 機能を特定します。

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

以下は、難読化解除後のYARAルールです。

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

chrome.dllでパターンをデコードして検索した後、これはCookieMonsterデストラクタ(net::CookieMonster::~CookieMonster)につながります。

その後、Cookieはメモリ内で識別され、Chromeプロセスからクリアテキストでダンプされます。

完了すると、LUMMA は Cookie を他の要求されたデータと共に複数の zip ファイル (xor 暗号化および base64 エンコード) として C2 サーバーに送信します。

検知

以下は、情報窃取者が使用する手法を特定するために使用できる次の動作検出です。

• 通常とは異なるプロセスによるWebブラウザの資格情報アクセス
• 署名されていないプロセスによるWebブラウザーの資格情報アクセス
• 不審なメモリーからのブラウザー認証情報へのアクセス
• Webブラウザーファイルへのアクセス試行の失敗
• 通常とは異なる親からのブラウザーのデバッグ
• 潜在的なブラウザ情報の検出

さらに、次のクエリを使用して、関連するさまざまな異常な動作をハンティングできます。

通常とは異なるプロセスによるCookieアクセス

このクエリは、ファイルオープンイベントを使用し、プロセスごとにアクセスを集約し、一意のホストで観察され、合計アクセス数が少ないものを探します。

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

以下は、新しいChromeのCookie窃取機能を備えた更新されたものを含む、さまざまな情報窃取者からの一致の例です。

METASTEALERの動作は、最初に実行中のすべてのChromeインスタンスを終了し、次にCoCreateInstanceを呼び出してGoogle Chrome昇格サービスをインスタンス化する傾向があります。この一連のイベントは、次のEQLクエリで表すことができます。

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

前のハントでは、疑わしいエージェントが示されていますが、ソース プロセスは特定されていません。Chrome Elevation サービス CLSID レジストリ キー {708860E0-F641-4611-8895-7D867DD3675B}でイベント 4663 を使用してレジストリ オブジェクト アクセス監査を有効にすることで、そのキーにアクセスしようとする異常なプロセスを検出できます。

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

以下は、 CoCreateInstance (CLSID_Elevator)を呼び出しているときにMETASTEALERマルウェアに一致する例です。

PHEMEDRONEスティーラーは、既知のブラウザのデバッグ方法を使用してChromium APIを介してCookieを収集しますが、これは次のスクリーンショットで観察でき、NodeJsのインスタンスがポート9222を介してデバッグが有効になっているブラウザインスタンスと通信していることがわかります。

次のEQL問合せを使用して、同様の動作を実行する異常なプロセスを探すことができます。

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

Chromeブラウザは、異常な親から生成されます

ChromeKatzの実装を使用するSTEALCサンプルは、Google Chromeのインスタンスを生成してユーザーのデフォルトプロファイルを読み込み、通常の親実行可能ファイルを探している間、それはChromeの署名された親とExplorer.exeに限定されていることが判明しました。次のES|QL クエリを使用して、通常とは異なる親を見つけることができます。

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Chrome アプリケーション フォルダの信頼できないバイナリ

Chrome 昇格サービスは Chrome program files フォルダから実行されるバイナリを信頼するため、次のクエリを使用して、そこから実行または読み込まれた署名されていないバイナリまたは信頼できないバイナリをハンティングできます。

Google Chromeアプリケーションフォルダから読み込まれた署名されていないDLL

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

Google Chromeアプリケーションフォルダから起動された署名されていない実行可能ファイル

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

まとめ

Googleは、Chrome内のCookieデータを保護するための新しいセキュリティ制御を実装するための水準を引き上げました。予想通り、これによりマルウェア開発者は独自のバイパスを開発または統合するようになりました。Google がユーザーデータの保護を強化するために、今後も革新を続けていくことを願っています。

組織と防御側は、異常なエンドポイントのアクティビティを常に監視する必要があります。これらの新しい手法は成功するかもしれませんが、ノイズが多く、適切なセキュリティ機器、プロセス、および人員で検出可能でもあります。

スティーラーバイパスと MITRE ATT&CK

Elasticは、 MITRE ATT&CK フレームワークを使用して、脅威がエンタープライズネットワークに対して使用する一般的な戦術、手法、手順を文書化します。

戦術（Tactics）

戦術は、テクニックまたはサブテクニックの理由を表します。 それは敵の戦術的な目標であり、行動を実行する理由です。

• 認証情報アクセス
• 防御回避
• ディスカバリ
• 実行

手法

手法は、敵対者がアクションを実行することによって戦術的な目標を達成する方法を表します。

• WebセッションCookieの窃取
• プロセスインジェクション
• パスワードストアからの認証情報
• システム情報の検出
• プロセスディスカバリー
• プロセス間通信: コンポーネント オブジェクト モデル

ヤラ

Elasticセキュリティは、このアクティビティを識別するためのYARAルールを作成しました。

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

観測

すべてのオブザーバブルは、ECS形式とSTIX形式の両方で ダウンロード することもできます。

この研究では、次の観測量について議論しました。

参照資料

上記の研究を通じて、以下のことが参照されました。

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html