はじめに はじめにNTT西日本の長谷川です。 本記事では、セキュリティ業界の有志で運営している「MINI Hardening」というコミュニティのメンバーにより開発された、サイバー攻撃を想定したインシデント・レスポンスを体験するためのトレーニングツール「ZANSIN」の体験談と自身で環境を構築する際の手順と注意点をまとめています。 ※Hardening とは情報セキュリティ分野においてセキュリティ強化演習を指す用語です。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN セキュリティの勉強をすすめていると、よく攻撃手法やその脅威をテキストとして見ることはありますが、座学だけではその動きや脅威はあまり実感できません。 このZANSINはそれを体験できるツールですので、セキュリティのスキル強化やセキュリティ対策の重要性を理解し、スキルアップに役立てるべく紹介していきます。 トレーニング環境はローカル環境やプライベートゾーンなど外部から悪用されない安全な環境で構築してください。 許可なくインターネットサイトを攻撃することは法律（不正アクセス禁止法等）に抵触する行為となるため、絶対に行わないでください。 この「ZANSIN」を用いて以下の習得が期待できます。 実践的なセキュリティ強化スキル 脆弱性をついた攻撃とその対策方法 セキュリティ対策の重要性 本ツールは体験・トレーニングツールとして公開されているため、初級～中級を主なターゲットにしています。 対象読者 本記事が想定する対象読者は以下の通りです。 サーバーのセキュリティ対策に興味があり、そのスキルを伸ばしたい方 サイバーセキュリティ対策の腕試しをしたい方 サイバーセキュリティ対策の実践力を鍛えたい方 目次 はじめに 対象読者 目次 1.背景 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 2-2. 脅威モデリングと対策検討 2-3.ZANSINのトレーニングシナリオ 2-4.ゲームサーバー（Trainingサーバー）の構成 2-5.トレーニング例 3.ZANSINを使ったトレーニングイベントに参加してみて 3-1.チームでのトレーニング 3-2.実際のトレーニング結果 3-3.トレーニングを受けて感じたこと 4.ZANSINの構築方法 4-1.要求スペック 4-2.構築場所 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） 4-4.クラウド環境におけるZANSIN事前設定（AWS＆Azureのみ実施) 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） 4-6.ZANSINトレーニング開始 5.最後に 執筆者　 参考資料・出典 商標　 免責事項 1.背景 セキュリティの勉強を進めていくと、さまざまな攻撃や脆弱性について語られることがありますが机上では学べないものが多く、以下のように悩むことがあります。 実際に脆弱性をついた攻撃などを体験する機会がない。 脆弱性を確認するにも環境構築からが大変。 実践的なスキルを身につける環境が欲しい。 私自身も、頭では理解しているつもりでも「実際に何が起きるのか」が結び付かず、もどかしさを感じていました。 このような悩みを持つ方も多いのではないでしょうか？ こういった机上では学べないことを実際に体験してみましょう。 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 ZANSIN は Ubuntu®で構築されたControlサーバーとTrainingサーバーの2台で構成され、Trainingサーバーには「MINI QUEST」というWeb ゲームが稼働しています。 ControlサーバーはTrainingサーバーに対してサイバー攻撃を行います。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN 利用者はTrainingサーバーに潜む脆弱性を特定し、対策を施していくことでサイバー攻撃や不正行為に対して迅速かつ効果的な対応スキルを体験的に学ぶことができます。 実行される攻撃例 不正ログイン バックドア設置 ゲームサービス妨害 ゲームのチート行為 これらの攻撃に対する対策を通してセキュリティ対策スキルを養っていきます。 トレーニングの性質上どういった攻撃が実行されるかは明示しませんが、よく耳にする攻撃からの対策方法を学ぶことができます。 （あくまで防御について学ぶトレーニングツールであり、攻撃手法が学べるものではありません） ZANSINはあえて複数の脆弱性を含んだシステムを用意し、攻撃を受けながら守り方を学ぶという設計思想となっています。 実運用では本来避けるべき構成や設定も含まれていますが、それらを「なぜ危険か」「どう検知し、どう是正するか」を体験的に理解することを目的としています。 ※ZANSINは教育目的専用のツールです。実際の本番システムへの攻撃に応用することは法律で禁止されています（不正アクセス禁止法等） 2-2. 脅威モデリングと対策検討 事前資料から潜在的な脆弱性の洗い出し、攻撃シナリオの想定を行うことでセキュリティ設計の基本も体験できます。 ぶっつけ本番でおこなって体験するのもいいですが、効果的なトレーニングにするためにはしっかり事前準備するとより効果が得られます。 2-3.ZANSINのトレーニングシナリオ ZANSINは以下の指示に従ったトレーニングを行います。 Ubuntuで構築されたゲームサーバー（Trainingサーバー）が公開されましたが、脆弱性を含んでいるようです。 ゲームサーバー（Trainingサーバー）にはMINI QUESTと呼ばれるブラウザゲームが稼働しています。 ゲームサーバー（Trainingサーバー）がサイバー攻撃にさらされています。サイバー攻撃に対応しシステムを保護してください。 稼働しているMINI QUESTをチート行為から守ってください。 トレーニング時間（240min）の間に多様な攻撃が行われます。どの程度脆弱性が修正されたかで評価します。 2-4.ゲームサーバー（Trainingサーバー）の構成 ゲームサーバーにはUbuntu上に構築されたNGINX®、MySQL®、Redis®、Docker®で動作しており、構成は概略として以下となっています。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN このゲームサーバには多くの脆弱性が潜んでいます。 トレーニングを受けるユーザーはこの構成図と配布されるGAME API設計書から脆弱性の予測と洗い出しを行い、トレーニングに挑みます。 2-5.トレーニング例 トレーニングに影響が出るといけないので、多くは書けませんが、 実際にどのような攻撃が行われるか一つの例をあげてみます。 Trainingサーバーにはいくつかの脆弱性があります。 その中の一つに脆弱なパスワードを使っているユーザーがいます。 それを放置しているとパスワードを推測されて不正ログインされた結果、管理者権限を奪われ、バックドアとなる不正ユーザーが作成されます。（不正ユーザーが作成される経路は複数用意されています） ログなどから不審なユーザーが登録されていることを見つけることができれば、その後バックドア経由での攻撃を防げるかもしれません。 他にもセキュリティを勉強しているとよく目にするいろいろな攻撃が仕掛けられます。 ログや配布資料をもとに攻撃を特定し対策をしていきます。 3.ZANSINを使ったトレーニングイベントに参加してみて 実際に私もZANSINを使ったトレーニングイベントに参加してみました。 3-1.チームでのトレーニング トレーニングイベントでは参加者は4～5人のチームに割り振られました。 チームごとに提供された事前情報をもとにサーバーを防御するというものでした。 このときはZANSINというものは知っていたので、実際に体験するいい機会でした。 イベントでは初対面同士でチームが構成されてトレーニングに臨みました。 写真：社内で実施したトレーニングイベントの様子 トレーニング実施前の準備時間に、与えられた情報から簡単に以下の役割を決めました。 全体管理 ログ等からの分析 実際の改修、修復 3-2.実際のトレーニング結果 実際にトレーニングを行った結果はボロボロでした。 （普段から専門的にセキュリティ対策に携わっていないと初見ではかなりやられると思います） ですが、今まで机上でしか知ることがなかった攻撃が目の前で実行されます。 それをログなどから追いかけ対策を講じていくというのは非常に多くの学びがありました。 紹介していたようにWeb ゲームが動いていますが、どうしようもなく破壊されたときには頭を抱えるほどでした。 3-3.トレーニングを受けて感じたこと 実践的な経験を通じたトレーニングの有効性を改めて実感しました。 私は即席のチームでイベントに臨みましたが、いろいろな対応が必要になるためチームビルディングの重要性を感じました。 トレーニングに挑む際には以下にあげたような役割を決めて挑むほうが、慌てず対処できると思います。 全体管理 ログ分析（攻撃監視） 対策（スクリプト・設定修正） ZANSINは公開されているので、自身で環境構築をすればこのトレーニングを通してスキルの向上に役立てられそうです。 実際、1回ですべて対策できるとはとても思えないくらい多様な攻撃が行われます。 繰り返しトレーニングしてスキルを高めていきたいと思わせるツールです。 4.ZANSINの構築方法 自身でトレーニングをするためのZANSINを構築していきます。 ZANSINはUbuntu Serverで動作しますが、ControlサーバーとTrainingサーバーの2台が必要になります。 ZANSINの要求スペックは低いのでローカル環境でも十分構築できると思います。 Ubuntu Serverは20.04以上が必要とされており、22.04までは正常にインストールできることが確認されています。 24.xではインストールスクリプトを修正すればインストールが可能とコミュニティへの報告もありますが、22.04で構築することをお勧めします。 4-1.要求スペック それぞれのサーバーに必要とされる最低スペックは以下のとおりとなっています。 コア数 メモリ 記憶域 Controlサーバー 1 2GB 30GB Trainingサーバー 1 2GB 30GB 記憶域は30GBとなっていますが、実際は10GB程度しか使っていないことを私の環境（Ubuntu 22.04, 2026年3月時点）で確認しているため、節約したい場合は20GB程度でも動作します。 メモリは2GBとなっていますが、1GB以上のSWAPがあればメモリは1GBでも動作します。 4-2.構築場所 ZANSINが要求するスペックは高くありません。 古いPCを2台用意する方法もありますが、仮想環境を用意して構築するほうが現実的かもしれません。 AWS®やAzure®といったクラウド環境であれば手軽に構築を始められるかわりにローカル環境の構築より手順が多くなっています。 クラウド環境構築に必要な追加手順や外部から悪用されないセキュリティ設定などに不安があるのであれば、ローカル環境でHyper-V®やVirtualBox®などを用いるほうが手軽に構築できます。 （ローカル環境構築の場合も外部ネットワークに公開しないなどのセキュリティを考慮した設定は行ってください。） ※クラウド環境の場合いくつかの追加モジュールが初期インストールされていないため、手動追加する必要があります。 （”4-4.クラウド環境（AWSやAzure）におけるZANSIN事前設定”や”4-5.ZANSIN構築手順”の手順5～6が必要） 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） ※クラウド環境は、Ubuntuの22.x系を選択し、4-4項を実施。 以下にインストール時のパラメータを示す。 Controlサーバー、Trainingサーバー用に2台用意し、同じ設定で構築する。 インストール手順については公式ドキュメント等を参照してください。 項目 値 備考 OS Ubuntu Server 22.x インストールメディア・iso等 インストールタイプ Ubuntu Server（minimized） 両サーバー共通 Profile:Your name zansin 両サーバー共通 Profile:Your servers name 例：ControlServer、TrainingServer 運用上わかりやすい名前を任意で設定 Profile:Pick username zansin 両サーバー共通 Profile:Choose a password 任意のパスワード 両サーバー共通 SSH設定 チェック 利用できるようチェックする ローカル環境で構築する場合、トレーニング受講者のみがアクセスできる安全なプライベートネットワークにControlサーバー、Trainingサーバーを構築してください。 4-4.クラウド環境におけるZANSIN事前設定（ AWS＆Azureのみ実施 ) AWSやAzureを利用した場合の追加となる事前設定。 （Hyper-VやVirtualBox等ローカル環境で構築の場合は不要） この設定を行わないとAWSやAzureではインストールスクリプトが正常に終了しなかったり、トレーニングが正常に行えないため、必ず実施する。 自分でOSからインストールする場合は不要。 1.ネットワークセキュリティ設定（ トレーニング用途限定 ） トレーニングに必要な以下のネットワーク通信を許可する。 プロトコル ポート TCP 5555 TCP 3000 TCP 22 TCP 6379 TCP 80 TCP 3306 TCP 443 TCP 2375 ICMP (推奨) これらのポートへの接続ができなければ、正常なトレーニングが行えないため、トレーニング環境に限定して通信を許可すること。 ※これらのポートはトレーニング用途で解放するもので、そのままでは脆弱性につながるものがあります。 ※本番環境では解放するポートについては用途を確認し十分注意して解放すること。 ※特にTCP:2375の解放は本番環境では注意すること。 勘の鋭い人はここからどんな攻撃が行われるか予測できるかもしれませんね。 クラウド環境の場合、外部からの不正アクセスに対する設定を行ってください。 以下が一例ですが、このような設定を推奨します。 ・ トレーニング受講者のみがアクセスできるようなIPによるアクセス制限の追加。 ・ 以下のようなSSHのみ許可した踏み台サーバを用意し、踏み台サーバからポートフォワード機能を利用してトレーニング環境へアクセスする。 （踏み台サーバの構築、ポートフォワード機能については本記事では取り上げておりません） 2.zansinユーザーの作成 アカウント：zansinを作成する。 コマンド例 $ sudo useradd zansin $ sudo passwd zansin パスワードは任意で登録。 ただしControlサーバーとTrainingサーバーでパスワードは共通にしておくこと 3.ZANSIN展開用ホームフォルダの作成 以下の例を参考にホームフォルダを作成する コマンド例 $ sudo mkdir /home/zansin $ sudo chown zansin:zansin /home/zansin 4.sudoersの追加 以下コマンド例を参考にアカウント:zansinでsudoが使えるようにする。 コマンド例 $ sudo usermod -aG sudo zansin 5.apache2の停止 クラウド環境ではapahe2がインストール済みで自動起動している場合がある。（AWSでは確認済み） ZANSINの構築時には競合するため、停止させておく。 コマンド例 $ sudo systemctl stop apache2 $ sudo systemctl disable apache2 6.SWAP作成（推奨） ※必須ではないものの、やっておいた方が安定性とレスポンスが向上する コマンド例 $ sudo mkdir /swap $ sudo dd if=/dev/zero of=/swap/swapfile bs=1M count=2048 $ sudo chmod 600 /swap/swapfile $ sudo mkswap /swap/swapfile $ sudo swapon /swap/swapfile $ sudo echo ‘/swap/swapfile none swap sw 0 0 ‘ | sudo tee -a /etc/fstab 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） ZANSINをインストールして環境を構築します。 一番の山場で時間がかかります。 ここは手順通りに進めていても不安になりやすい箇所なので、焦らず進めることが大切です。 ※AWS、Azureで構築した場合はインストーラがモジュール不足でエラーを出し、正常にインストールできません。5及び6の修正作業が必要 1.sshdの設定変更（Controlサーバー、Trainingサーバー両方で実施）　 ※本番環境では非推奨 ControlサーバーはパスワードログインのSSHを通してTrainingサーバーを制御しています。 そのため両サーバーでSSHのパスワードログインを有効にします。 パスワードログインの有効化 /etc/ssh/sshd.confの修正 以下コメントアウト　もしくは追記 PasswordAuthentication yes ※SSHのパスワードログインはセキュリティリスクにつながる可能性があります。 本番環境では特別な理由がない限りは推奨されません。 2.ZANSINセットアッスクリプトのダウンロード（Controlサーバーで実施） ZANSINをインストールするためのスクリプトを入手します。 以下は ZANSIN のインストールスクリプトを取得するコマンドです。 このスクリプトは GitHubで公開されています。 https://github.com/ZANSIN-sec/ZANSIN コマンド例 $ cd /home/zansin $ wget https://raw.githubusercontent.com/ZANSIN-sec/ZANSIN/main/zansin.sh ※このコマンドで指定しているのはGitHubの公開リポジトリへの直接リンクである。そのため将来リポジトリ構成が変更された場合にリンク切れとなる可能性がある。その場合はGitHubから変更されたリンクを確認すること。 3.インストールスクリプト実行（Controlサーバーで実施） インストール作業はカレントディレクトリを/home/zansinに変更して実施。 コマンド例 $ cd /home/zansin $ chmod +x zansin.sh $ ./zansin.sh 4.インストールスクリプト（Controlサーバーで実施） スクリプトを実行するとインストーラが走ります。 インストールに必要な情報として以下を入力するよう求められます。 sudoパスワード（設定したzansinパスワード） ControlサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） TrainingサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） zansinパスワード：zansinのパスワード（設定したパスワード） 必要な情報を入力してインストールが開始されます。 マシンスペックにもよりますが、データ転送に時間がかかります。 要求最低減のスペックの場合、30分以上かかる場合もあります。 特にコンテンツデータの転送は時間がかかり止まってるように見えますが、気長に待ちましょう。 ※クラウド環境で実行した場合モジュール不足でエラーが表示されます。（インストールは最後まで走る） ※クラウド環境で構築する場合、以下を追加で実行する必要があります。（AWS、Azure以外では不要） 5.Controlサーバーでのモジュール追加（ AWS、Azure環境のみ実行 ） ※AWS、Azureで構築した場合はインストーラがPython®のモジュール不足でエラーを出し、正常にインストールできないためこの作業でモジュールを手動追加します。 エラーが出る不足モジュールを追加します。 $ source /home/zansin/red-controller/red_controller_venv/bin/activate $ pip3 install python-nmap $ pip3 install bs4 $ pip3 install paramiko $ pip3 install requests $ pip3 install docopt $ pip3 install aiohttp 6.インストールスクリプト再実行（ AWS、Azure環境のみ実行 　Controlサーバーで実施） 以下コマンドでインストールを再実行します。 $ ./zansin.sh 4-6.ZANSINトレーニング開始 構築作業お疲れさまでした。 以上でZANSINの構築は完了しました。 ここからは、ZANSINを実際に動かしてみましょう。 最初はすべての攻撃に対応できなくても問題ありません。 私も初回は思うように対処できず、かなり戸惑いました。 特にこういったインシデントに初めて触れる人は以下を目標とするくらい気楽にやる方がいいかもしれません。 ログやWeb画面で攻撃を目の当たりにする （何が起きているかを追えるようになるとさらにGood） なにか一つ対処できた （こうすれば対処できたといった振り返りができただけでも十分） ZANSINでトレーニングを開始する場合は以下を参考にコマンドを実行します。 SSHでControlサーバーに接続しトレーニング実行のコマンド以下を実行します。 通常モードでトレーニング開始 ~$ source /home/zansin/red-controller/red_controller_venv/bin/activate ~$ cd /home/zansin/ red-controller/ ~$ python3 red_controller.py -n ***** -t ***.***.***.*** -c ***.***.***.*** -a 1 python3 red_controller.py　オプションパラメータ補足 -n　Trainingユーザー名指定（自由に指定可能） -t　TrainingマシンのIP指定（AWSではプライベートIPV4アドレス） -c　ControlマシンのIP指定（AWSではプライベートIPV4アドレス） -a　攻撃シナリオ（上記例は1） 標準で登録されている攻撃シナリオは以下のとおり　0：デバッグシナリオ、1：標準シナリオ、2：簡易シナリオ（動作チェック等でなければ1を選択すること） コマンド例： Trainingユーザー名：test01 TrainingマシンのIP：10.10.10.1 ControlマシンのIP：10.10.10.2 攻撃シナリオ：１ $ python3 red_controller.py -n test01 -t 10.10.10.1 -c 10.10.10.2 -a 1 5.最後に 環境を用意する手間はありますが、仮想化技術を活用することで、トレーニング環境は容易に構築できます。 こういったトレーニング環境を活用することで、セキュリティインシデントを他者に影響与えることなく体験することができます。 セキュリティに興味のある方は、力試しやスキルアップの機会として活用を検討してみてください。 きっとセキュリティ設計やトラブルシュートに役立つ学びがあると思います。 執筆者　 長谷川 喬一（NTTビジネスソリューションズ（株） エンタープライズビジネス営業部 ネットワーク＆ソリューション推進担当） サーバーやクラウド、セキュリティの案件支援及びエリアのPMOに携わっています。 参考資料・出典 GitHub - ZANSIN-sec/ZANSIN · GitHub 商標　 「Ubuntu®」は、Canonical Ltd. の登録商標です。 「Hyper‑V®」および「Azure®」は、Microsoft Corporation の登録商標です。 「VirtualBox®」および「MySQL®」は、Oracle America, Inc. またはその関連会社の登録商標です。 「AWS®」は、Amazon Technologies, Inc. またはその関連会社の登録商標です。 「NGINX®」は、F5 Networks, Inc. の登録商標です。 「Redis®」は、Redis Ltd. の登録商標です。 「Docker®」は、Docker, Inc. の登録商標です。 「Python®」は、Python Software Foundation の登録商標です。 免責事項 本記事の情報を利用した結果として生じた損害・トラブルについて、当社および執筆者は一切の責任を負いかねます。

本ブログは 2026 年 3 月 18 日に公開された AWS Blog “ Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls ” を翻訳したものです。 Amazon Threat Intelligence は、Cisco Secure Firewall Management Center (FMC) Software の重大な脆弱性 CVE-2026-20131 を悪用する Interlock ランサムウェアのアクティブなキャンペーンを確認しました。この脆弱性は、認証を必要とせずにリモートの攻撃者が対象デバイス上で root 権限により任意の Java コードを実行できるというもので、2026 年 3 月 4 日に Cisco が公開しました。 Cisco による 脆弱性の公開 を受け、Amazon Threat Intelligence は Amazon MadPot のグローバルセンサーネットワークを使用して、この脆弱性の調査を開始しました。Amazon MadPot は、サイバー犯罪者のアクティビティをおびき寄せて監視するハニーポットサーバーのシステムです。過去から現在にかけてのエクスプロイトを調査した結果、Interlock が脆弱性公開の 36 日前にあたる 2026 年 1 月 26 日から悪用を開始していたことが判明しました。これは単なる脆弱性の悪用ではありませんでした。Interlock はゼロデイを手にしており、防御側がこの脆弱性の存在を認識するよりも前に、組織を侵害するための数週間の猶予を得ていたのです。この発見を受けて、AWS は Cisco の調査を支援するとともにお客様を保護するため、調査結果を Cisco と共有しました。 設定に誤りのあったインフラストラクチャサーバー、つまり攻撃者が使用していたセキュリティが不十分なステージング領域から、Interlock の攻撃ツールキットの全容が明らかになりました。このまれな設定ミスにより、Amazon のセキュリティチームは、ランサムウェアグループの多段階攻撃チェーン、カスタムのリモートアクセス型トロイの木馬 (RAT、攻撃者が侵害したシステムをリモート制御するためのバックドアプログラム)、偵察スクリプト (被害者のネットワークをマッピングする自動化ツール)、および回避テクニックの全容を把握することができました。 今回のキャンペーンにおいて、AWS インフラストラクチャや AWS 上のお客様のワークロードが影響を受けた事実は確認されていません。本アドバイザリでは、潜在的な侵害の特定と Interlock の活動からの防御に役立てていただけるよう、包括的な技術分析と侵害インジケータ (IoC) を共有します。Cisco Secure Firewall Management Center を使用している組織は、Cisco のセキュリティパッチを直ちに適用し、以下に示す IoC を確認してください。 発見と調査のタイムライン Amazon Threat Intelligence は、CVE-2026-20131 に関連する可能性のある脅威アクティビティが、脆弱性の公開に先立つ 2026 年 1 月 26 日から発生していたことを特定しました。確認されたアクティビティには、影響を受けるソフトウェアの特定のパスに対する HTTP リクエストが含まれていました。リクエスト本文には、Java コードの実行を試みるコードと 2 つの埋め込み URL が含まれていました。1 つはエクスプロイトに必要な設定データの配信用で、もう 1 つは脆弱なターゲットから HTTP PUT リクエストで生成ファイルをアップロードさせ、悪用の成功を確認するためのものでした。複数のエクスプロイト試行を通じて、これらの URL にさまざまなバリエーションが確認されました。 調査をさらに進め、脅威インテリジェンスを得るため、AWS は想定されるファイル内容を含む HTTP PUT リクエストを送信し、侵害に成功したシステムを装いました。これにより Interlock は攻撃の次のステージに進み、リモートサーバーから悪意のある ELF バイナリ (Linux 実行ファイル) をダウンロードして実行するコマンドを送信してきました。 アナリストがこのバイナリを取得したところ、同一のホスト (攻撃者が制御するサーバー) が Interlock の攻撃ツールキット全体の配布にも使用されていることが判明しました。この外部に露出していたインフラストラクチャでは、アーティファクトが標的ごとに個別のパスで整理されており、侵害したホストへのツールのダウンロードとステージングサーバーへのアーティファクトのアップロードの両方に同じパスが使用されていました。 Interlock ランサムウェアへのアトリビューション ELF バイナリと関連アーティファクトは、技術的および運用面の指標の一致から、Interlock ランサムウェアファミリーによるものと判断されます。埋め込まれたランサムノートと TOR 上の身代金交渉ポータルは、Interlock が従来使用してきた特徴的な手口やインフラストラクチャと合致しています。ランサムノートで複数のデータ保護規制に言及していることは、規制上のリスクを指摘して被害者に圧力をかけるという Interlock の既知の手法を反映しています。データの暗号化だけでなく、規制上の罰金やコンプライアンス違反をも利用して組織を脅迫する手口です。ランサムノートに埋め込まれたキャンペーン固有の組織識別子も、Interlock が被害者ごとに追跡を行うモデルと一致しています。 Interlock はこれまで、業務の中断が身代金支払いへの大きな圧力となる特定のセクターを標的としてきました。標的として最も多いのは教育セクターで、次いでエンジニアリング・建築・建設企業、製造・産業組織、医療機関、政府・公共セクターの順となっています。 観測された脅威アクティビティのタイムスタンプ、設定に誤りのあったインフラストラクチャサーバー上のアーティファクト、および取得した脅威アーティファクトに埋め込まれたメタデータの時間分析から、この脅威アクターは 75～80% の確度で UTC+3 タイムゾーンにおいて活動していると推定されます。すべての UTC オフセットを対象とした体系的な分析の結果、UTC+3 が最も一致しました。アクティビティの開始は 08:30 頃、ピークは 12:00～18:00、推定される非活動時間帯は 00:30～08:30 でした。 図 1: Interlock ランサムウェアの身代金交渉ポータル。被害者が組織 ID とメールアドレスを入力し、認証トークンを受け取って交渉チャットセッションを開始する 技術分析: Interlock の攻撃ツールキット 侵害後の偵察スクリプト Interlock は初期アクセスを獲得した後、さまざまなツールを使用して攻撃を展開します。Amazon Threat Intelligence チームは、Windows 環境を体系的に列挙する (被害者のネットワーク情報を自動収集する) PowerShell スクリプトを取得しました。このスクリプトは、オペレーティングシステムとハードウェアの詳細、実行中のサービス、インストール済みソフトウェア、ストレージ構成、Hyper-V 仮想マシンインベントリ、デスクトップ・ドキュメント・ダウンロードの各ディレクトリにわたるユーザーファイル一覧、Chrome、Edge、Firefox、Internet Explorer、360 ブラウザからのブラウザアーティファクト (履歴、ブックマーク、保存された認証情報、拡張機能を含む)、プロセスに関連付けられたアクティブなネットワーク接続、ARP テーブル、iSCSI セッションデータ、および Windows イベントログからの RDP 認証イベントを収集します。 このスクリプトは、各システムの完全修飾ホスト名に基づいて専用ディレクトリを作成し、結果を集約用ネットワーク共有 (\JK-DC2\Temp) にステージングします。つまり、侵害した各コンピュータにフォルダが作成されます。収集が完了すると、データはホスト名に基づく名前の ZIP アーカイブに圧縮され、元の生データは削除されます。このようなホスト単位の構造化された出力形式は、スクリプトがネットワーク内の複数マシンにまたがって実行されていることを示しており、組織全体の暗号化に向けた準備を行うランサムウェア侵入チェーンの典型的な特徴です。 カスタムリモートアクセス型トロイの木馬 リモートアクセス型トロイの木馬 (RAT) とは、攻撃者が侵害したシステムへの持続的な制御を可能にする悪意のあるプログラムであり、不正なリモートデスクトップソフトウェアのように機能します。 JavaScript インプラント: Amazon Threat Intelligence は、難読化された JavaScript ベースの RAT を取得しました。この RAT はブラウザコンソールのメソッドをオーバーライドしてデバッグ出力を抑制し、基本的な検出ツールからアクティビティを隠蔽します。実行時には、PowerShell と Windows Management Instrumentation (WMI) を使用して感染ホストのプロファイリングを行い、システム ID、ドメインメンバーシップ、ユーザー名、OS バージョン、権限コンテキストを収集した上で、暗号化された初期化ハンドシェイクでこれらのデータを送信します。 コマンドアンドコントロール (C2) 通信には永続的な WebSocket 接続が使用され、メッセージごとにパケットヘッダーに埋め込まれた 16 バイトのランダムキーによる RC4 暗号化が適用されます。各メッセージが異なる暗号化キーを使用するため、傍受がより困難になる仕組みです。インプラントは、オペレーターが制御する複数のホスト名と IP アドレスをランダムな順序で巡回し、再接続試行間にはエクスポネンシャルバックオフを適用します。 このインプラントは、インタラクティブなシェルアクセス、任意のコマンド実行、双方向ファイル転送、TCP トラフィックのトンネリングに対応する SOCKS5 プロキシ機能 (悪意のあるトラフィックを他のシステム経由でルーティングして発信元を隠蔽) といった機能を備えています。また、自己更新および自己削除の機能もあり、オペレーターは再感染を伴わずにインプラントを置換または削除でき、フォレンジック調査を妨害する痕跡消去にも対応します。 Java インプラント: Java で実装された機能的に同等のクライアントも存在し、同一の C2 機能を提供します。GlassFish エコシステムライブラリ上に構築されており、ノンブロッキング I/O トランスポートには Grizzly を、WebSocket プロトコル通信には Tyrus を使用しています。つまり Interlock は、同じバックドアを 2 つの異なるプログラミング言語で構築することで、防御側が一方のバージョンを検出した場合でもアクセスを確実に維持できるようにしているのです。 インフラストラクチャロンダリングスクリプト 高度な脅威アクターは自身のインフラストラクチャから直接攻撃を仕掛けるのではなく、使い捨ての中継ネットワークを構築して痕跡を隠蔽します。Amazon Threat Intelligence チームは、Linux サーバーを HTTP リバースプロキシ (攻撃者の実際の所在地を隠すためにトラフィックを転送する中間サーバー) として構成する Bash スクリプトを特定しました。このスクリプトは、システムアップデートの実行、SSH ブルートフォース保護機能を持つ fail2ban のインストール、HAProxy 3.1.2 のソースからのコンパイルを行います。構成された HAProxy インスタンスはポート 80 でリッスンし、すべてのインバウンド HTTP トラフィックをハードコードされたターゲット IP に転送します。また、systemd によりシステム再起動後も持続性が確保されます。 特に注目すべきコンポーネントが、5 分ごとに cron ジョブとして実行されるログ消去ルーチンです。このルーチンは /var/log 配下のすべての *.log ファイルを切り詰め、HISTFILE 変数をアンセットしてシェル履歴を抑制します。5 分間隔でログを消去するこの積極的な証拠破壊は、専用に構築された HTTP 転送プロキシと組み合わせて考えると、このスクリプトが使い捨てのトラフィックロンダリング用中継ノードの構築を目的としていることを示しています。これらのノードは、エクスプロイトトラフィックの発信元隠蔽、C2 通信の中継、データ窃取のプロキシとして機能し、攻撃の発信源への追跡をほぼ不可能にします。 メモリ常駐型 Web シェル Amazon Threat Intelligence チームは、ELF バイナリの投下に代わる手段として配信される Java クラスファイルを確認しました。Java Virtual Machine (JVM) によってロードされると、静的イニシャライザが、サーバーの StandardContext に ServletRequestListener を登録し、ディスクへのファイル書き込みを一切行わずに HTTP リクエストを傍受する永続的なメモリ常駐型バックドアをインストールします。この「ファイルレス」アプローチにより、悪意のあるファイルを探索する従来のウイルス対策スキャンを回避することが可能になります。 リスナーは受信リクエストを検査し、暗号化されたコマンドペイロードを含む特殊なパラメータの有無を確認します。ペイロードは、ハードコードされたシード値 “geckoformboundary99fec155ea301140cbe26faf55ed2f40” の MD5 ハッシュから導出されたキー (先頭 16 文字の 09b1a8422e8faed0 を使用) による AES-128 で復号されます。復号されたペイロードはコンパイル済みの Java バイトコードとして扱われ、JVM に動的にロードされて実行されます。これは、悪意のあるコードを完全にメモリ内で実行することで、ファイルベースの検出を回避するために設計されたテクニックです。 接続確認ツール Amazon Threat Intelligence チームは、ポート 45588 でリッスンする基本的な TCP サーバーを実装した Java クラスファイルを取得しました (ポート番号は静的分析による特定を困難にするため、Unicode 文字 넔 としてエンコードされていました)。サーバーは接続を受け入れると、接続元の IP アドレスをログに記録し、挨拶メッセージを送信した後、即座に接続を切断します。この動作パターンは、初期エクスプロイト実行後のコード実行成功確認やネットワークポートへの到達性確認に使用される軽量なネットワークビーコン (いわゆる「フォンホーム」ツール) の特徴と一致しています。 正規ツールの悪用 Interlock はカスタムインプラントと並行して、正規の商用リモートデスクトップツールである ConnectWise ScreenConnect もデプロイしていました。ランサムウェアオペレーターが正規のリモートアクセスツールをカスタムマルウェアと併用するのは、いわば保険をかけているようなものです。防御側が 1 つのバックドアを発見して除去しても、別の侵入経路が残ります。これは冗長なリモートアクセス手段を複数確保するパターンであり、個々の足場が除去されてもアクセスを維持しようとするランサムウェアオペレーターの典型的な手法と一致しています。正規ツールならではのネットワークフットプリントにより、許可されたリモート管理トラフィックに紛れ込むことができ、検出がさらに困難になります。 Amazon Threat Intelligence チームは、インシデントレスポンダーが広く使用するオープンソースのメモリフォレンジックフレームワークである Volatility も取得しました (防御側が攻撃調査に使用するのと同じツールです)。自動化された使用を示すアーティファクトは確認されなかったものの、カスタムインプラントや偵察スクリプトとともに配置されていたことは、高度な脅威オペレーションの特徴と合致しています。ランサムウェアグループと国家支援型アクターの双方が、侵入時に Volatility をデプロイしていることが確認されています。メモリダンプの解析に特化したこのツールは、RAM に保存された認証情報などの機密データへのアクセスを可能にし、ラテラルムーブメント (ネットワーク内の横展開) やより深い環境侵害を通じてランサムウェアオペレーションやスパイ活動を支援します。 さらに Interlock は、Active Directory Certificate Services (AD CS) の設定ミスを悪用するためのオープンソースの攻撃的セキュリティツールである Certify も使用していました。ランサムウェアオペレーターにとって、Certify は脆弱な証明書テンプレートや、認証用証明書の要求を許可する登録権限を特定する手段となります。取得した証明書は、ユーザーのなりすまし、権限の昇格、永続的なアクセスの維持に悪用できます。これらの機能は、ランサムウェアオペレーションにおける初期侵害と長期的な永続化の双方を直接支援するものです。 侵害インジケータ (IoC) 以下のインジケータは、影響を受けた可能性のある組織での防御に役立てることができます。Interlock はコンテンツバリエーション技法を使用しているため、ほとんどのファイルハッシュは信頼性の高いインジケータとしては掲載していません。脅威アクターは、異なるターゲットに配信するスクリプトやバイナリなどのアーティファクトに逐次変更を加えており、機能的には同一のツールであってもファイルハッシュが異なるものとなっていました。このカスタマイズにより、ファイルの完全一致に依存するシグネチャベースの検出が回避されていました。 206.251.239[.]164 エクスプロイトソース IP 2026 年 1 月に活動確認 199.217.98[.]153 エクスプロイトソース IP 2026 年 3 月に活動確認 89.46.237[.]33 エクスプロイトソース IP 2026 年 3 月に活動確認 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0 エクスプロイト HTTP User-Agent 2026 年 1 月および 3 月に観測 b885946e72ad51dca6c70abc2f773506 エクスプロイト TLS JA3 2026 年 1 月および 3 月に観測 f80d3d09f61892c5846c854dd84ac403 エクスプロイト TLS JA3 2026 年 3 月に観測 t13i1811h1_85036bcba153_b26ce05bbdd6 エクスプロイト TLS JA4 2026 年 1 月および 3 月に観測 t13i4311h1_c7886603b240_b26ce05bbdd6 エクスプロイト TLS JA4 2026 年 3 月に観測 144.172.94[.]59 C2 フォールバック IP 2026 年 3 月に活動確認 199.217.99[.]121 C2 フォールバック IP 2026 年 3 月に活動確認 188.245.41[.]78 C2 フォールバック IP 2026 年 3 月に活動確認 144.172.110[.]106 バックエンド C2 IP 2026 年 3 月に活動確認 95.217.22[.]175 バックエンド C2 IP 2026 年 3 月に活動確認 37.27.244[.]222 ステージングホスト IP 2026 年 3 月に活動確認 hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php 身代金交渉ポータル 2026 年 3 月に活動確認 cherryberry[.]click エクスプロイトサポートドメイン 2026 年 1 月に活動確認 ms-server-default[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 initialize-configs[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 ms-global.first-update-server[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 ms-sql-auth[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 kolonialeru[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 sclair.it[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 browser-updater[.]com C2 ドメイン 2026 年 3 月に活動確認 browser-updater[.]live C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]com C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]org C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]live C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]top C2 ドメイン 2026 年 3 月に活動確認 d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be 攻撃的セキュリティツール (Certify) 2026 年 3 月に観測 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f スクリーンロッカー 2026 年 3 月に観測 防御に関する推奨事項 Interlock ランサムウェアの脅威から組織を守るために、以下の対策を実施してください。 直ちに実施すべきアクション: Cisco Secure Firewall Management Center に対する Cisco のセキュリティパッチを適用する 上記の IoC についてログを確認する 侵害の兆候がないかセキュリティ評価を実施する ScreenConnect の不正なインストールがないか確認する 検出のポイント: ネットワーク共有にホスト名ベースのディレクトリ構造でデータをステージングする PowerShell スクリプトを監視する Web アプリケーションコンテキストでの Java ServletRequestListener の登録 (Java Web アプリケーションへの通常とは異なる変更) を検出する 積極的なログ消去用 cron ジョブを伴う HAProxy のインストール (5 分間隔で自身のログを消去するプロキシサーバー) を特定する 通常とは異なる高番号ポート (例: 45588) への TCP 接続を監視する 長期的な対策: 複数のセキュリティ制御レイヤーによる多層防御戦略を実装する 継続的な脅威監視とスレットハンティングの能力を維持する 侵害を受ける可能性のあるシステムとは分離した、安全で一元化されたログストレージによる包括的なログ収集を確保する ランサムウェアシナリオに対するインシデントレスポンス手順を定期的にテストする Interlock の戦術、テクニック、手順についてセキュリティチームを教育する ここで本当に重要なのは、これが特定の脆弱性や特定のランサムウェアグループだけの問題ではないということです。ゼロデイエクスプロイトがあらゆるセキュリティモデルに突きつける根本的な課題なのです。パッチが存在しない段階で攻撃者に脆弱性を悪用されてしまえば、どれほど徹底したパッチ管理を行っていても、その重要な期間中は防御できません。だからこそ多層防御が不可欠なのです。複数のセキュリティ制御を重ねることで、いずれかの対策が機能しない場合や、まだ導入されていない場合でも保護を維持できます。迅速なパッチ適用は脆弱性管理の基盤であり続けますが、多層防御は、エクスプロイトが確認されてからパッチが提供されるまでの空白期間に、組織が無防備にならないための重要な手段です。 Amazon Threat Intelligence チームは Interlock ランサムウェアの活動を引き続き監視しており、新たな情報が判明し次第アップデートを提供します。今回のキャンペーンから収集したインテリジェンスは、お客様をプロアクティブに保護するため、AWS のセキュリティサービスに統合されています。 この記事に関するご質問は、 AWS サポート までお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しており、セキュリティの実践が最も自然で簡単な選択肢となるようにすることで Amazon のビジネスを支えることを使命としています。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO を含むさまざまな役職を歴任した後、2023 年 9 月に現職に就任しました。 Amazon 入社以前は、連邦捜査局 (FBI) サイバー部門でコンピュータおよびネットワーク侵入に関する技術分析を率いていました。また、空軍特別捜査局 (AFOSI) の特別捜査官も務めました。現在のセキュリティ業界の基盤を築いたとされる、複数のコンピュータ侵入捜査を指揮しました。 CJ はコンピュータサイエンスと刑事司法の学位を取得しており、SRO GT America GT2 のレースカードライバーとしても活躍しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Hyper-VのNAT機能で仮想マシンを外部ネットワークへ接続する手順を解説。仮想スイッチ作成、IP設定、PowerShellでのNAT設定、ゲストOS設定までを網羅。