This post is also available in: English (英語)
要約
2014年、Turlaグループと呼ばれる高度な技術を持つ新たな攻撃グループについてのニュースが報道されました。エストニア対外情報庁によれば彼らは「ロシアを拠点としロシア連邦保安庁のために活動しているグループ」とされており、同グループの使うカーネルモードで動作するマルウェアはサードパーティ製デバイスドライバを悪用しドライバ署名の強制(Driver Signature Enforcement 以降「DSE」)を無効化したことが報じられた初の事例となりました。
DSEはWindows Vistaから導入されたセキュリティメカニズムで、未署名のドライバがカーネル空間にロードされないようにするものです。Turlaは署名されたVirtualBoxドライバVBoxDrv.sys v1.6.2を使用してDSEを非アクティブ化した後、自身の未署名のペイロードドライバをロードします。
なお一般にCVE-2008-3431と呼ばれている本エクスプロイトについては一部で認識に混乱が見られます。Turlaが使用するエクスプロイトには、実際には2つの脆弱性が悪用されているのですが、CVE-2008-3431で修正されたのはこのうちの1つのみなのです。Turlaが発見したもう1つの脆弱性は、CVE-2008-3431とともに、彼らのエクスプロイトの最初のバージョンで使用されています。おそらく2014年に投入されたTurlaのカーネルモードマルウェアの2つ目のバージョンでは、パッチが適用されていない脆弱性のみが悪用されます。この脆弱性については、後で詳しく解説します。
さて2019年2月、Unit 42は、情報セキュリティコミュニティにはまだ知られていない攻撃者が、パッチ未適用の2つ目の脆弱性により、VirtualBoxのVBoxDrv.sysドライバv1.6.2だけでなく、v3.0.0までのその他すべてのバージョンも悪用できることを発見したことに気付きました。さらに私たちの調査では、この未知の攻撃者がVirtualBoxドライババージョン2.2.0を悪用して2017年に2つ以上のロシアの組織を攻撃したことがわかっており、この件についてはここで初めて発表します。私たちは、これはドライババージョン2.2.0が脆弱だとは知られておらず、したがって攻撃されたセキュリティ企業が警戒していなかったために発生したと考えています。その他の被害は見つかっていないため、これは標的型攻撃でのみ使用される非常にまれなマルウェアであると考えられます。
攻撃者は、AcidBoxと私たちが呼んでいる(マルウェアのドライバデバイス名のアナグラムとVirtualBoxの組み合わせから)、それまでは知られていなかったマルウェアファミリを悪用しています。このマルウェアは複雑かつまれであり、より大きなツールセットの一部であるため、標的型攻撃用に高度な攻撃者により使用されたものであり、攻撃者がまだ活動していればこのマルウェアは現在もまだ使用されている可能性が高いと考えられます。ただし、ある程度書き換えられていることが予想されます。私たちが保持している情報から、使用されたエクスプロイト以外は、この未知の攻撃者はTurlaとはつながっていないと考えています。
パロアルトネットワークスのお客様は、この脅威から保護されています。WildFireの脅威防御プラットフォームは、このマルウェアを悪意のあるものとして識別します。AutoFocusのお客様は、AcidBoxタグを使用してマルウェア活動を追跡できます。この攻撃に対する攻撃者プレイブックも作成し、こちらで公開しています。
未知の攻撃者
2019年2月、私たちはTurlaのVirtualBoxエクスプロイトで使用されていることがわかっている文字列を含む、AcidBoxのサンプル(SHA256: eb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5)がVirusTotalにアップロードされていることを発見しました。サンプルのより深い分析の結果、これはいずれの既知の攻撃者にも結び付けることができなかった高度なマルウェアの一部であるメイン ワーカー モジュールであることがわかりました。
私たちはDr.Web社のリサーチャーと共同調査を行い、このサンプルが2017年にロシアで不特定のエンティティに対する標的型攻撃で使用されたものであることを突き止めました。同社のリサーチャーたちは同じマルウェアファミリの追加のサンプルを3つ提供してくれました。これらのユーザーモードサンプルのうちの2つは、Windowsレジストリからメインワーカーをロードするモジュールで、残り1つはメインワーカーのサンプルに埋め込まれているカーネルモード ペイロード ドライバでした。私たちはさらにロシアに本社を置くKaspersky社にも連絡しました。Kaspersky社のデータベースに含まれていた唯一の追加のサンプルは、同じくユーザーモード ローダー バージョンでした。このほか、ESET社にも連絡しましたが、私たち同様、ESET社も同マルウェアによる感染被害者を発見していませんでした。このことから、これは標的型攻撃でのみ使用されている非常にまれなマルウェアであると考えられます。
すべてのサンプルに共通しているのが、2017年5月9日というコンパイルタイムスタンプです。Kaspersky社が発見したサンプルは2017年6月にデータベースに登録されているため、この日付は正当なようです。したがって、このマルウェアを使用したキャンペーンは2017年に発生したと結論付けられます。より新しいサンプルは発見できていないため、AcidBoxが今も使用されているのか、またさらに発展しているのかは不明です。
サンプルの特定の特性をすべての既知のマルウェアと比較しましたが、明確な一致は見つかりませんでした。ProjectSauronによるマルウェアであるRemsecとは、以下に示すような若干の類似性があります。
-
- DWORDサイズ データ マーカー値
- 2/3ワードで構成されるエクスポート関数名
- 使用されているMS Visual C/C++コンパイラ
- 各種のインポートAPI関数の重複
- 自身の未署名ドライバをロードするための脆弱なサードパーティ製ドライバの悪用
- 使用されているzlib圧縮
- リソースセクションでの機密データの暗号化
ただしこれらの事実だけでは、サンプルが攻撃者ProjectSauronによるものであると判断することはできません。私たちは、未知の攻撃者によるものである可能性が高いと考えています。
VirtualBoxエクスプロイトとTurlaのバージョン
CVE-2008-3431に記述されている元の脆弱性はCore Security社が2008年に発見したもので、VBoxDrv.sysのバージョン1.6.2とそれ以下のバージョンに影響しました。バージョン1.6.4で修正されたため、それ以降悪用されることはなくなりました。
![](https://unit42.paloaltonetworks.jp/wp-content/uploads//2020/06/Figure-1.-Vulnerable-and-patched-VirtualBox-device-dispatch-handler-routines-on-the-left-and-right-respectively.png)
当該の脆弱性はVBoxDrvNtDeviceControlと呼ばれるディスパッチデバイス制御ルーチンに存在します。1.6.4より前のバージョンでは、ユーザーモードDeviceIoControl API関数を呼び出し、入出力バッファとして上書きしたいカーネルアドレスとともに以下のいずれかの制御コードを送信することができます。
-
- SUP_IOCTL_FAST_DO_RAW_RUN
- SUP_IOCTL_FAST_DO_HM_RUN
- SUP_IOCTL_FAST_DO_NOP
カーネルアドレスはチェックも検証もなく制御ハンドラに渡され(図1左の28行目を参照)、supdrvIOCtlFastの戻り値が挿入されます(図1左の24行目を参照)。Core Security社の脆弱性調査はここまでだったのですが、Turlaはその後も調査を続けました。元のエクスプロイトでは、supdrvIOCtlFastからの戻り値は制御されていないため、カーネルアドレスに書き込まれるランダムな値となります。Turlaのエクスプロイトでは、必要な値を返す簡単なシェルコードに実行をリダイレクトするようにsupdrvIOCtlFastの関数ポインタを上書きすることで戻り値を制御しています。これについては、複数の記事で詳細に解説されており、リバースエンジニアリングされた完全なエクスプロイトコードも提供されています。
パッチが適用されたバージョン1.6.4(図1右を参照)では、カーネルアドレスを渡すことにより悪用される可能性があるUserBufferポインタは使用されなくなっています。また、rc変数が0以上であるかがチェックされます。これはパッチには必要ありませんが、サニティチェックのようなものです。
このパッチでカーネルアドレスを上書きする元の脆弱性については修正されましたが、supdrvIOCtlFastの関数ポインタの制御を可能にするもう一方の脆弱性は修正されないままになりました。これは当時Core Security社はまだこの脆弱性を発見しておらず、それを数年後にTurlaの攻撃者が発見したためです。
Turlaは現在も脆弱なVirtualBoxドライバv.1.6.2を使用していますが、悪用されているのはパッチ未適用の脆弱性のみです。Lastline社が、Turlaがこの脆弱性を悪用する理由および方法について解説しています。またリバースエンジニアリングされたエクスプロイトコードが、Turla Driver Loaderというプロジェクトで提供されています。
問題は、この同じエクスプロイトを、わずかな修正を加えるだけで(どのような修正かはここでは公開しませんが)、3.0.0までのすべてのVBoxDrv.sysのバージョンで悪用できるという点です。未知の攻撃者もこのことに気付きました。4.0未満のVirtualBoxバージョンは公式Webサイトでは提供されなくなっていますが、一部のソフトウェア ダウンロード サイトではまだ入手可能です。
バージョン3.0.0以降、一部の構造やルーチンが変更されているため、このエクスプロイトは悪用できなくなっています。ただしそれ以降のバージョンでも、何らかの調整を加えることにより、同じ脆弱性が悪用される可能性がないとは言い切れません。
さらに興味深いのは、Turlaの作成者達もそのことに気付いていないようであるということです。その他の点では気付かれにくいエクスプロイトで、未だにVBoxDrv.sys v.1.6.2を使用しているのです。このドライバは、ゲーム内でのチートなど、悪意があるかその他のいかがわしい目的で使用されることがよく知られています。
AcidBoxの技術分析
このマルウェアは複雑なモジュール型のツールキットであり、私たちはその一部しか入手していません。合計で4つの64ビットユーザーモードDLLと、未署名のカーネルモードドライバを発見しています(SHA256: 3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d)。4つのユーザーモードサンプルのうちの3つは同一の機能を持ち、メイン ワーカー モジュールに対するローダーです。異なるのは、ファイルの説明と、埋め込まれ、暗号化されたレジストリパスのみです。これらのローダーはセキュリティ サポート プロバイダ(SSP)として作成されています。SSPは、少なくともSpLsaModeInitialize関数をエクスポートし、通常はクライアント/サーバーアプリケーション間の認証などのセキュリティメカニズムを提供するDLLです。Kerberos (kerberos.dll)やNTLM (msv1_0.dll)など、Windowsではいくつかの標準SSPが提供されています。SSPインターフェイスは、マルウェアの永続化および注入を目的として悪用される可能性があります。永続性を維持するためには、SSP DLLをWindowsのシステムディレクトリに挿入し、DLLの名前を特定のレジストリ値に追加する必要があります。これにより、システムの再起動時にDLLがWindowsのlsass.exeプロセスにロードされ、実行されます。SSP DLLをlsass.exeに注入するだけであれば、即時ロードをトリガーするAPI関数AddSecurityPackageを呼び出します。もちろんどちらの方法でも、最低でも管理者権限が必要です。SSPインターフェイスを悪用したマルウェアの最初の事例は、2014年にMatt Graeber氏により報告されました。それ以来、この永続化と注入のトリックは広く知られるようになりましたが、今もマルウェアではほとんど使用されていません。
3つのAcidBox SSP DLLでは、いずれのセキュリティ関連の操作も利用せず、このインターフェイスを純粋に注入目的で、またおそらくは永続化目的でも悪用しています。3つのSSPはそれぞれ、Windowsで提供されている標準パッケージ(msv1_0.dll、pku2u.dll、wdigest.dll)に似た、以下のファイル名を持ちます。
-
- msv1_1.dll (SHA256: b3166c417d49e94f3d9eab9b1e8ab853b58ba59f734f774b5de75ee631a9b66d)
- pku.dll (SHA256: 3ad20ca49a979e5ea4a5e154962e7caff17e4ca4f00bec7f3ab89275fcc8f58c)
- windigest.dll (SHA256: 003669761229d3e1db0f5a5b333ef62b3dffcc8e27c821ce9018362e0a2df7e9)
![](https://unit42.paloaltonetworks.jp/wp-content/uploads//2020/06/Figure-2.-Standard-SSP-DLLs-provided-in-Windows-7-present-in-the-“Security-Packages”-value.png)
このため、AcidBox SSPは永続化目的でもインターフェイスを悪用していると考えています。ただし、SSP DLLをインストールするコンポーネントを入手していないため、これは確実ではありません。わかっているのは、SSPはロードされるプロセスパスがリソースセクションですべてのサンプルに埋め込まれているパスと一致しているかどうかを最初にチェックするため、SSPインターフェイスはlsass.exeへの注入に使用されているということです(C:\WINDOWS\SYSTEM32\lsass.exe)。このプロセスパスはリソース4097に含まれており、ステガノグラフィによりどのように隠されているかについては後で解説します。
AcidBox SSP DLLの目的は、各サンプルのリソース256に含まれているレジストリ値からメイン ワーカー モジュールをロードすることです。メインワーカーDLLがレジストリにどのように格納されたのかはわかりませんが、SSP DLLをインストールしたのと同じ、私たちが入手していないコンポーネントにより実行されたと考えられます。また、これらのサンプルの1つには異なるレジストリキーが埋め込まれていたため、3つのSSP DLLは別々のシステムからのものであると想定されます。さらに、これらのモジュールはシステムで唯一目に見える部分であり、ロードされるメイン ワーカー モジュールはレジストリで暗号化されたままであるため、選択されているファイル名と同様に、それぞれ何らかの違いがある可能性があります。メインワーカーは、データBLOBのCRC32ハッシュなどの各種のメタデータや、含まれているデータのタイプを示すマジック バイト シーケンスを含むデータBLOB内で暗号化されてレジストリに格納されています。
データをキー0xCAと単にXORすることによって、SSP DLLによりレジストリから復号化されると、メインワーカーDLLはメモリからロードされるように準備されます。これは、モジュールに対するスレッドを作成し、メインワーカーのエクスポート関数UpdateContextを開始アドレスとして使用することにより行われます。メイン ワーカー モジュールはVirtualBoxエクスプロイトを使用して未署名のマルウェアドライバをロードし、私たちが入手していない1つまたは複数のコンポーネントからのコマンドを待機します。これらのコマンドには、ドライバによるカーネル空間のレジストリからの追加のペイロードのロードや、新たなSSP DLLのインストールを行うものなどがあります。
メインワーカーには、InitMainStartupとUpdateContextという2つのエクスポート関数があります。以下の文字列が平文で含まれます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
%s\%s %s\%s{%s} %s\[[%s]] %s.dll %s%s%s.dll \\.\PCIXA_CFGDEV InitEntry InitExit The Magic Word! ntoskrnl.exe ntkrn ntkrp hal.dll ntoskrnl ntkrnlpa.exe %s%s%s Group Count NextInstance Root\LEGACY_NULL\0000 |
以下の追加の文字列がスタック難読化されています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
SeLoadDriverPrivilege %s\%c*.dll System\CurrentControlSet\Control\ NtQueryInformationThread BFE_Notify_Event_ Microsoft\Cryptography ntdll.dll \Registry\Machine\ SOFTWARE Global %s\%s Security Packages kernel32.dll SOFTWARE \Registry\Machine\ MachineGuid ntdll.dll |
後で動的に解決されて使用される、XORエンコードされたDLLおよび関数名も含まれます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
ntdll.RtlGetVersion ntdll.ZwLoadDriver ntdll.ZwUnloadDriver ntdll.ZwQuerySystemInformation kernel32.DeviceIoControl kernel32.GetSystemDirectoryA ntdll.RtlAnsiStringToUnicodeString ntdll.ZwClose ntdll.ZwCreateFile ntdll.ZwQueryInformationFile ntdll.ZwReadFile ntdll.ZwWriteFile kernel32.GetSystemDirectoryA kernel32.GetSystemDirectoryW kernel32.BaseThreadInitThunk kernel32.LZDone advapi32.CryptAcquireContextA advapi32.CryptGenRandom advapi32.CryptReleaseContext ntdll.RtlRbInsertNodeEx ntdll.RtlRbRemoveNode ntdll.RtlAcquireSRWLockExclusive ntdll.RtlReleaseSRWLockExclusive ntdll.RtlEnterCriticalSection ntdll.RtlPcToFileHeader ntdll.RtlGetVersion ntdll.RtlUpcaseUnicodeChar ntdll.RtlAnsiStringToUnicodeString ntdll.LdrLockLoaderLock ntdll.LdrUnlockLoaderLock ntdll.ZwClose ntdll.ZwCreateSection ntdll.ZwMapViewOfSection ntdll.ZwUnmapViewOfSection |
すべての機能は2つのエクスポート関数に含まれており、DllMainには関連するコードは含まれていません。目に付くのが、コード全体でカスタムDWORDサイズのステータスコードが多用されている点です。result変数にステータスコードが指定されている、逆コンパイルされたコードの例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
… if ( !a1 || !a2 || !(_DWORD)v3 ) { result = 0xA0032B02; goto LABEL_45; } if ( strlen(a1) <= 1 ) goto LABEL_65; result = get_kernel32_path(a1, &v43, &v37, &v41); if ( result ) goto LABEL_45; if ( (unsigned int)v3 < 0x1C ) { LABEL_65: result = 0xA0032B02; goto LABEL_45; } pBuffer = allocate_buffer(v13, (unsigned int)v3, 0i64, v11, 0, 1); buffer = pBuffer; if ( !pBuffer ) { LABEL_9: result = 0xA0032B04; goto LABEL_45; } if ( memcpy_s(pBuffer, v3, a2, v3) ) { LABEL_11: result = 0xA0032B06; goto LABEL_45; } … |
メインワーカーのサンプルには、16、256、4097、8193、12289という有効なアイコンを持つ5つのアイコンリソースが含まれます。各名前は異なるアイコン解像度を表していますが、付加されている暗号化データが異なるだけで、これはステガノグラフィの一形態と見なすことができます。このデータはカスタムアルゴリズムで暗号化され、さらにzlib圧縮されています。同じ手法はSSP DLL内でも使用されています。復号化および解凍用のPythonスクリプトについては、付録を参照してください。復号化後、データBLOBの構造は以下のようになります。
1 2 3 4 5 6 7 8 9 |
struct data_blob { DWORD marker; // Marker bytes (0x9A65659A) DWORD crc32; // CRC32 value of decrypted or zlib uncompressed bytes DWORD size; // Size of decrypted or zlib uncompressed bytes DWORD option; // Information if data is encrypted or zlib compressed; 0x1 = encrypted, 0x2 = zlib compressed char data[]; // Encrypted or zlib compressed data }; |
復号化されたデータは以下のとおりです。
リソース16:
1 2 |
System\CurrentControlSet\Control\Class\{4D36E97D-E325-11CE-BFC1-08002B E10318}\0003\DriverData |
リソース256:
1 2 |
System\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002B E10318}\0000\DriverData |
リソース16と256は、リソース8193内に埋め込まれたドライバおよびAcidBoxドライバにより注入される可能性が高い追加のペイロードに対する復号化キーを含むWindowsレジストリキーです。
リソース4097:
1 |
C:\WINDOWS\SYSTEM32\lsass.exe |
このリソースには、自身が正しいプロセスにロードされていることを検証するために各サンプルが使用するプロセスのパスが含まれます。リソース8193には、RSAによって暗号化されている未署名のカーネルモード ペイロード ドライバが含まれます。ドライバは、2つのエクスポート関数InitEntryとInitExitを持つカーネルモードDLLとして実現されています。以下の平文文字列が含まれます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
ntoskrnl.exe ntkrn ntkrp hal.dll ntoskrnl ntkrnlpa.exe csrss.exe PsCreateSystemThread \Device\VBoxDrv \DosDevices\PCIXA_CFGDEV \Windows\ApiPort \Sessions\%u\Windows\ApiPort \Sessions\xxxxxxxx\Windows\ApiPort \Device\PCIXA_CFG \DosDevices\PCIXA_CFGDEV |
リソース12289には、同様に脆弱であると既述した、Sun Microsystems社により署名されたVirtualBox VBoxDrv.sysドライバv2.2.0.0が含まれます。
![AcidBoxの署名された脆弱なVBoxDrv.sysドライババージョン2.2.0.0](https://unit42.paloaltonetworks.jp/wp-content/uploads//2020/06/Figure-3.-Signed-vulnerable-VBoxDrv.sys-driver-version-2.2.0.0.png)
PEヘッダについての科学的なこぼれ話
私たちはサンプルの調査時に、科学的インジケータとして見逃されることの多いPEヘッダ特性に注目しました。このあまり知られていない事実はエクスポートディレクトリにあり、マルウェアサンプルの特定に役立ちます。すべてのAcidBoxサンプルでは、単一のエクスポート関数のエントリ間にギャップが含まれます。
![AcidBoxサンプルのディレクトリ](https://unit42.paloaltonetworks.jp/wp-content/uploads//2020/06/Figure-4.-Export-directories-of-AcidBox-samples-with-gaps-between-the-export-function-entries.png)
すべてのAcidBoxサンプルには、エクスポートディレクトリにNumberOfFunctions値があり、これはNumberOfNames値よりも大きくなります。すべてのエクスポート関数に名前が付いている必要はないため、これは珍しいことではありません。名前のない関数は序数値で呼び出すことができます。一般的でないのは、名前のない関数エントリが0に設定されているため、使用されていないという点です。
これは、DLLファイルの属性を記述するために、__declspec(dllexport)の代わりに独自のDEFファイルを使用した結果発生します。DEFファイルを使用する場合には、エクスポート関数に割り当てる序数を選択できます。Visual Studioコンパイラでは関数には必ず1から番号が割り当てられるため、__declspec(dllexport)ではこれは可能ではありません。
__declspec(dllexport)の代わりにDEFファイルを使用することにはいくつかのメリットがあります。序数を使用した関数のエクスポートや、関数のリダイレクトなどが可能です。デメリットは、プロジェクト内で追加のファイルを管理する必要があるという点です。
AcidBoxサンプルの場合は、次の点がわかりました。まず、作成者はDEFファイルを使用していますが、そのメリットは活用していません。これは、作成者にDEFファイルを使用する習慣があることを示している可能性があります。次に、関数の序数は1つ置きに選択されているようです。この説明としては、未使用の序数も以前は関数に使用されていたことが考えられます。最後に、作成者が実際に1つ置きを選択したと想定するのであれば、ユーザーモードDLLでは1つのエクスポート関数が削除されています。序数3が使用されていないため、ギャップが1つ置きより大きくなっています。この情報はすべて、マルウェアの特定に役立ちます。
結論
AcidBoxと呼ばれる新しい高度なマルウェアが2017年に未知の攻撃者により使用されましたが、現在まで検出されていませんでした。このマルウェアはWindowsのドライバ署名の強制を無効化する既知のVirtualBoxエクスプロイトを使用しますが、次のような新たなひねりが加えられています。VirtualBoxドライバVBoxDrv.sys v1.6.2には脆弱性があり、これがTurlaにより悪用されていることは広く知られていますが、この新しいマルウェアでは同じエクスプロイトをやや新しいVirtualBoxのバージョンで利用します。
時に、新たな手法を利用する技術的に興味深いWindowsマルウェアが見つかることもあります。しかし、何かのコピーのコピーのそのまたコピーであるか、技術的に面白味がないものばかりの今日の脅威状況では、これは非常にまれなことです。AcidBoxは基本的にはさほど目新しい手法は使用されていませんが、「TurlaのエクスプロイトにはVirtualBox VBoxDrv.sys 1.6.2しか悪用されない」という定説は覆りました。機密データをオーバーレイとしてアイコンリソースに付加し、永続化と注入およびWindowsレジストリへのペイロードの格納を目的としてSSPインターフェイスを悪用する点から、興味深いマルウェアとして分類することができます。
AcidBoxと私たちが呼んでいるサンプルはより大きなツールキットの一部でしかなく、残念ながらこのツールキット自体は特定できていません。ただし、私たちは脅威を検出して捕捉するため2つのYaraルールを提供しています。またお客様は、追加のサンプルを見つけた場合、または感染した場合でも、提供されているPythonスクリプトを使用して、アイコンリソースに付加された機密データを抽出することができます。これらはすべて、こちら(Unit 42のGitHubリポジトリ)から入手できます。
この脅威についてさらに情報をお持ちであれば、弊社にご連絡ください。
パロアルトネットワークスのお客様は、このマルウェアから保護されています。WildFireの脅威防御プラットフォームは、このマルウェアを悪意のあるものとして識別します。AutoFocusのお客様は、AcidBoxタグを使用してこの活動を調査できます。
Dr.Web社、Kaspersky社、ESET社、およびhFireF0Xのご協力に感謝いたします。
IOC
Windowsのsystem32ディレクトリのファイル
- msv1_1.dll
- pku.dll
- windigest.dll
ミューテックス
- Global\BFE_Event_{xxxxxxxxxxxx--xxxx-xxxxxxxx-xxxxxxxx}
- Global\{xxxxxxxxxxxx--xxxx-xxxxxxxx-xxxxxxxx}
このマルウェアは、レジストリに格納されているMachineGuidを取り出し、末尾から先頭、そして先頭から末尾と切り替えながら、個々の文字を1つ置きに並べ替えます。たとえば、MachineGuid文字列a9982d3e-c859-4702-c761-df7eea468adeはe9a86daeecf5--67c2-07419d87-e34289daに変更され、上記のテンプレートに付加されます。
Windowsレジストリ
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E97D-E325-11CE-BFC1-08002BE10318}\0003\DriverData (REG_BINARY type)
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0000\DriverData (REG_BINARY type)
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E969-E325-11CE-BFC1-08002BE10318}\0000\DriverData (REG_BINARY type)
サンプルのハッシュ
メインワーカーのDLL:
- eb30a1822bd6f503f8151cb04bfd315a62fa67dbfe1f573e6fcfd74636ecedd5
カーネルモードドライバ:
- 3ef071e0327e7014dd374d96bed023e6c434df6f98cce88a1e7335a667f6749d
SSP DLLモジュール:
- 003669761229d3e1db0f5a5b333ef62b3dffcc8e27c821ce9018362e0a2df7e9
- b3166c417d49e94f3d9eab9b1e8ab853b58ba59f734f774b5de75ee631a9b66d
- 3ad20ca49a979e5ea4a5e154962e7caff17e4ca4f00bec7f3ab89275fcc8f58c
- 無害なVirtualBox VBoxDrv.sysドライバv2.2.0 (「Sun Microsystems, Inc.」により署名):
- 78827fa00ea48d96ac9af8d1c1e317d02ce11793e7f7f6e4c7aac7b5d7dd490f