ブラックエナジーの解体、パート2 – “THE MARK”

BlackEnergyフレームワークについてのスピーチはしません。既に多くの情報が提供されており、私がいなくても理解できるはずですから。しかし、特定の情報源からの情報に言及したいと思います。 レビュー:

皆さん、Flashplayerをご覧ください！

我々のインフラへの攻撃を調査中に、さまざまなマルウェアサンプルを検出しました。その中にはFlashplayerapp.exe（https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)簡単に言えば、flashplayerappはmain_light.dllを自身のメモリスペースに抽出し、それに制御を移します。このライブラリはBlackEnergyの軽量版であり、C＆C通信に使用され、攻撃者が追求している目的に応じた主なペイロードをダウンロードします。次のファイルを作成します：C:UsersuserAppdataAdobecache.datこのファイルは暗号化されており、ビルドバージョン（2015lstbなど）、さまざまなペイロードを取得できるコマンド＆コントロールセンターのアドレス（hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.phpなど）などの情報を含んでいます。このサンプルを調べているうちに、C＆Cから焦点を切り替えました。ある特定のコード部分が私の注意を引きました。そこにはコード置換という技法を使用している明確なサインがありました。この情報源からの引用を翻訳します http://hacks.clan.su/publ/11-1-0-481：

エンジンによって残された痕跡

関数の名前ではなくハッシュ値に基づいて関数呼び出しを行うことで静的コード解析を困難にする手法は新しいものではありません。しかし、それは私に以下のような考えをもたらしました：悪意のあるコードがどのように処理されるかに関係なく、関数の名前のハッシュ化アルゴリズムを知っているので、コード内でこの二つの関数（LoadLibraryAとGetProcAdress）を自信を持って探すことができるということです。そこで、ネット上でこれらのハッシュ（0xC8AC8026）の言及を探し始め、この例で使用されたエンジンと同じものが過去に使用されたかを調べたところ、驚いたことに実際に何か見つけました：このハッシュは2006年に初めて言及されています（記事はarchive.orgでのみ見つけられます）： https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

その後、2008年にはこのアルゴリズムの潜在的な作者がフォーラムに姿を見せています：https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

その後、2009年にはshellcode MS08-067の分析記事がblogs.technet.comに掲載されています：http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

そして2013年には、「XAKEP」マガジン（ロシアのITおよび情報セキュリティに関する最大級のメディア）が https://xakep.ru/2011/06/23/55780/ という記事で同じハッシュを生成するこのアルゴリズムを言及しています：ちょっと待ってください、ここで我々が直面しているのは、同じハッシュ値を生成する同じアルゴリズムが10年以上も使用されているのに、誰もこれに気づかなかったということですか？そうでなければ、現在のように見えるflashplayerapp.exe（https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/）が2016年に入り、アンチウイルスソリューションによって未発見のままであることは不可能です。この分析されたサンプルで使用された具体的な置換エンジンによって残された明確な「マーク」があり、これは正当なシグネチャと感じます。さらに、それはクリアテキストで直接追跡するのがかなり簡単です：さて、我々は仮説と理論を確かなものにしましたので、実際に進んで結論をYaraシグネチャ/ルールに変換してみましょう：

rule API_Hash

{meta: description = “Hash of LoadLibrary that is {26 80 ac c8} and GetProcAddres {ee ea c0 1f}”

strings:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

condition: $a and $b

}

残ることは、複数のさまざまなサンプル（例えばアンチウイルスラボのもの）に対してテストを行い、本当にどれだけ多くの悪意のあるコードがこのエンジンでパックされたかを見極めることだけです。現時点では、私はアンチウイルス会社の少量のサンプルで実験を行うことができましたが、結果はそれだけの価値があります！捕らえられたサンプルの中には、以下のものがあります：Win32/Spy.Bebloh （バンキングトロイの木馬） — http://www.virusradar.com/en/Win32_Spy.Bebloh/detailWin32/PSW.Fareit （パスワードを盗むトロイ） — http://www.virusradar.com/en/Win32_PSW.Fareit/detailWin32/Rustock （バックドア） — http://www.virusradar.com/en/Win32_Rustock/detailWin32/TrojanDownloader.Carberp （バンキングトロイCarberpをインストールするドロッパー） — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detailWin32/Kelihos （スパム送信者） — http://www.virusradar.com/en/Win32_Kelihos/detailこのリストには、よく知られたファミリーのみが含まれています。これら二つのハッシュ値は、ランサムウェア/ファイル暗号化ソフト（Win32/Filecoder.HydraCrypt）、ビットコインマイナー（CoinMiner.LC）、WinLocker（LockScreen.AQT）など、他のマルウェアファミリーにも現れます。

今のところ、この比較的シンプルなYaraルールは、テストが数十台のコンピュータでのみ行われたため、唯一の誤検知を記録していません。しかし、この研究の公開後、 あなた（！） とここまで読んだ方々は、このルールの精度を立証または反証するのに十分なフィードバックを共有していただけることを切に願います。もちろん、たった8バイトのシグネチャを使用するのは非常に小さく、ルールはいくつかの「正当な」ファイルを偶然キャッチする可能性が高いですが、この軽量なYaraルールは、より複雑な分析ロジックの一部としてサンドボックスに存在することができます。

結論

この文章の目的は、BlackEnergyマルウェアのリバースエンジニアリングではなく、マルウェアコードのアセンブリ時に使用されるツールが痕跡を残し、それが防御に役立つ有用な指標の出現につながる可能性があることを強調することです。そして、これらの指標は長期間にわたって気付かれずに存在することができます…

Andrii Bezverkhyi CEO SOC Primeによって翻訳されました