インシデント対応事例から学ぶ教訓 case4 「便利なクラウドだからこそ生まれる弱点 素早いランサムウェア攻撃の被害を抑える方法とは」
クラウド環境を起点したランサムウェア感染の実際の事例を、当社のインシデント対応サービスの過去事例を元に紹介します。具体的な攻撃シナリオとそれにむけた対策、インシデント全体から得た教訓をご紹介します。
今回の事例の経緯（実話をもとにしたフィクションとなります。）
とある企業に勤めるSさんは、IT部門に所属していました。
Sさんの会社では、DX化推進の取り組みが盛んであり、その一環として3年前より名刺情報管理クラウドを運用していました。
そうした中ある日、営業部の社員からチャットで連絡がありました。
「先ほど営業先で受け取った名刺情報をクラウドの方に登録しようとしたのですが、アクセスできない状況でした。ほかの社員の端末からもアクセスできないようですのでシステムの稼働状況を確認願います。」
Sさんとしては、システムアップデートは連絡を受けた次の週を予定しており、そうした都合以外でサービスが停止したことがないため、いまいち原因に心当たりのないまま、クラウド上のサーバー状況を確認することにしました。
確認したところ、クラウドに構築しているサーバー上のファイルやフォルダのほとんどが見慣れない拡張子のファイルに変換されており、開くことができない状態になっていました。
ただ、サーバー上には.txtの通常の拡張子のファイルも残されていたことから、そちらのファイルを実行したところ、「encrypted」や「Tor」などの見慣れない単語が並んでおり、この時点でSさんはこれがランサムウェア攻撃であることに気づきました。
名刺情報は個人情報にあたる顧客データである為、情報漏えいがあった際には重大なインシデントになりかねないと判断したSさんは、すぐに該当のサーバーと接続できうる端末の通信を全て遮断するとともに、社内への利用停止アナウンスやアクセス禁止の案内を告知しました。
その後、影響範囲を特定するため、暗号化されているファイルの洗い出しや、社員に対するシステム利用可否状況のヒアリングなどを始めました。
一週間ほど経過し、どうやら暗号化されたのはあくまでクラウド上のサーバーとそこへの中継サーバーのみであることが確認されました。
元々社内端末間でのアクセス制御も実施していたことに加えて、この一週間に追加で別端末が暗号化される被害もなかったことから、被害範囲自体は特定できたと考えていました。
しかし、どうやって侵入してきたかに関して明確な特定ができなかったことから、情報漏えいがあったかどうかの判断ができていないままでした。
このまま社内で調査を続けても限界があると感じたSさんは、導入していたセキュリティ製品のベンダーであるトレンドマイクロに連絡して調査に協力してもらうよう依頼しました。
協力して調査を行う中で、クラウド上のサーバーにおけるリモートデスクトップ（RDP）のポートが、意図せず外部から接続可能な状態になっていたことがわかりました。
Sさんは念のため運用で使用するポート番号をデフォルトポート番号から変更するなどの対策も実施していたのですが、攻撃者により見破られ悪用された可能性が高いと判断されました。
こうして侵入の明確な履歴を発見することまではできなかったものの、可能性の高い侵入経路の特定ができたことで、対策として何が必要かということも把握でき、事態は一旦収束することとなりました。
なお情報漏えいに関しては、残念ながら漏えいが起きた可能性を完全には否定することができないという結論となりました。
以上が今回の事の顛末となります。
本記事では、この一連のインシデントの中でどういった攻撃が行われていたのか、またどのような対策を実施するべきだったかに関して具体的に紹介し、ここから学び取れる教訓をご紹介したいと思います。
なお、本事案において注目すべきことの1つは、内部情報を扱うクラウド環境がインターネット環境上に露出する設定になっていたことが根本的な原因となった可能性が挙げられます。
調査の中で判明した事ですが、ＳさんはそうしたIT資産が露出するリスクに関して認識しており、普段からそのような危険な設定を回避するよう心がけていたのですが、過去に社員からの要望でインターネット環境からの接続を許可する設定を施した後、設定をそのままにしてしまった経緯がありました。
そうしたリスクのあるクラウド設定の放置を防ぐためにも、定期的に設定状況を確認する運用が今後は求められます。
今回主に侵害が確認されたデジタル資産は上記赤枠に含まれる2つのサーバーです。
赤枠で示す範囲が、今回の被害組織がクラウドサービスとして利用しているIaaS環境であり、ここにサーバーを構築して、名刺情報の管理や情報照会などに利用していました。
システム構成として、外部からのアクセスの際は必ず一度中継サーバーを経由してサーバーAに接続するように設計されていました。
後述しますが、今回このように中継サーバーを経由するように設計されていたことが被害を抑える要因の1つとなりました。
なお、今回被害の対象となったサーバーAにも中継サーバーにもセキュリティ製品が導入されていました。
攻撃者はまず公開設定となっていた中継サーバーにRDPで侵入したことが予想されます。
経緯のところでも記載した通り、被害企業においてはRDP用のポート番号(3389/tcp)をデフォルトから変更して別の番号に設定しておく、という対策を行っていました。
そのため、攻撃者にとってはポートの用途の特定に一定のハードルはあった可能性が予想されますが、RDP用のポートであることが見破られた可能性が高いと考えられます。
ただし、こちらはログ等から明確な痕跡が特定できなかったため、点線で表示しています。
ポート自体に侵入した際の認証回避については、明確な痕跡が確認できているわけではありませんが、公開された状態になっていることから総当たり攻撃や辞書攻撃を用いて認証を突破してきた可能性があります。
中継サーバーにRDPでアクセスできた攻撃者は、次にサーバーAに対しても同様にRDP接続で横展開を行ったことが確認されています。
こちらはログ上でも確認された動きとなりますので実線で記載しています。
次に攻撃者はサーバーA上にハッキングツールをインストールし、セキュリティ製品を停止させました。
ここで使用されたハッキングツール自体は正規のツールであり、スパイウェア対策の機能が有効化されていなかったために、その実行を防げなかったと考えられます。
こうした正規ツールを利用して、セキュリティ製品の動作を止める挙動はランサムウェア攻撃の中で度々みられる手法です。
セキュリティ製品を停止させ、自身の活動の自由度や秘匿性を高めた攻撃者は、横展開先をさらに広げる為、ネットワークスキャンを行ったことが確認されています。
しかし、今回の被害組織では内部でのRDP接続等の制限を適切に実施していたので、接続元となった中継サーバー以外にアクセスできる端末はありませんでした。
そのため、今回サーバーA以外の端末への接続が成功した痕跡は確認されていません。
その後、攻撃者はMimikatzやLazagneといったツールを使用して、認証情報や権限昇格を試みたことも確認されています。
より組織内での活動の自由度を高めて、侵害範囲を広げる方法を模索していたと考えられます。
MimikatzもLazagneも、当社が過去に対応したIR事例において認証窃取を行うツールとして度々悪用が確認されています。
最後に攻撃者は、サーバーAと中継サーバー上でランサムウェアを実行して、それぞれのファイルを暗号化し、脅迫文のファイルを設置して攻撃を終了したことが確認されています。
ランサムウェアとしては、CRYSISが利用されていました。
CRYSIS自体は情報流出型のランサムウェア攻撃ではない(専用の情報暴露サイトなどを持たない)ことや、情報送出の際によく使用されるデータ圧縮の挙動が今回確認されなかったことから、情報が漏えいした可能性は低いと考えられます。
一方で、クリップボードを利用するなどログ上に痕跡が残らない情報窃取の方法も存在するため、情報漏えいの可能性を完全に否定することはできないという判断となりました。
今回の攻撃において特筆すべき点として、侵入～ランサムウェア実行までの時間が、深夜12:00～早朝5:00までのわずか5時間に過ぎなかったことが挙げられます。
トレンドマイクロのIR支援を行ったランサムウェア事例における平均期間が侵入～実行まで5.82日間(本稿執筆時点)であることを鑑みるとかなり素早い攻撃であったことがわかります。
あくまで推測ですが、当該組織において社内での接続制限が実施されていたことにより、侵害可能範囲が限定されていたことが功を奏して、攻撃者にこれ以上工数をかけても侵害拡大が望めない環境であると判断され、早々に侵害を切り上げたのではないかと予想されます。
今回の侵害につながった防御体制上の脆弱性として、上記6つの点が挙げられます。
それぞれについて事前に対策することでリスクを低減できた点を表で記載します。
| 防げた可能性のある攻撃 | 防御体制上の脆弱性 | 事前に行うべき対策 | |
|---|---|---|---|
| ① | 公開設定となっているRDPポートを悪用され社内に侵入された | 通常の運用では使用しないポートの制御が不足していた | ・最小権限の原則に基づき、運用に必要な通信のみ許可するアクセス制御を行う |
| ② | 公開設定の確認や見直しが十分でなかった | ・運用に必要のないポートが公開されていないかなど、ネットワーク設定を定期的に監査する | |
| ③ | RDPを利用する際の認証制限が十分でなかった | ・パスワードの複雑性を向上するなどアカウントの堅牢性を高める ・アカウント情報だけでは利用できないよう多要素認証方式を採用する |
|
| ④ | RDPを用いて別端末に横展開された | 内部通信の制限が十分でなかった | ・内部での通信に関してもIPアドレスによる制限を実施する、接続可能時間帯を制限するなどのアクセス制御を行う |
| ⑤ | セキュリティ製品が停止させられた | ハッキングツール対策が十分でなかった | ・セキュリティ製品のスパイウェア対策機能を有効化し、ツールの実行をブロックする |
| ⑥ | ・セキュリティ製品の挙動監視機能を有効化し、ツールのインストールをブロックする |
表1：改善可能な防御体制上の脆弱性とその対策
これまでにも記載していた通り、今回の被害組織においては、外部、内部通信ともに通信制限自体は実施されており、機密情報を扱う上でのリスクに関して認識し対策を講じていたことが伺えます。
インシデント発生の根本的な原因は、運用上やむを得ず公開したRDPの設定値に関して変更管理が適切に実施されず、解放ポートが放置されてしまったことであることから、定期的な監査体制の下、設定状況の確認を行っていれば被害を防ぐことができたと考えられます。
また社内の通信に関しても、通信の制御としてIPアドレスを指定したり、接続時間帯を固定化したりすることにより通信制限をより強固なものにしていれば横展開を防げた可能性があります。
さらに今回ハッキングツールによってセキュリティ製品が停止させられましたが、セキュリティ製品においてスパイウェア対策機能や挙動監視機能を有効化していればツールのインストールまたは実行を食い止めることができたと考えられます。
一方今回、組織の多数のファイルが暗号化されてしまった事例と比べれば、被害が少なかったことも注目すべき点と言えます。
被害企業では完全な防御はできなかったものの、機密情報を取り扱うリスクを認識し、対策も施していました。
具体的には、外部からのアクセスの際は必ず中継サーバーを経由せねば社内サーバーにアクセスできないように制限すること、また特定のサーバーからアクセスできる端末を制限することなど、組織内外の通信制御を実施していたことが挙げられ、結果的に他事例に比較し被害を抑えることができました。
このことからゼロデイ脆弱性を使った攻撃やサプライチェーンを経由した攻撃など、ますますサイバー攻撃が高度化する中で、侵入を前提とした対策がリスクの低減に重要であることが伺えます。
さらにリスクを低減するためには、XDRの技術を採用することも有効な手立ての1つです。
今回の事例についていえば、XDRを用いることでRDPでの侵入やセキュリティ製品の停止といった事象を検知することが可能です。
また異なるレイヤーのテレメトリを収集することにより、攻撃の全体像を把握して被害範囲を素早く特定することができるので、侵入原因の予測や対策の意思決定までの時間を短縮化することができます。
また、クラウド環境の設定不備が原因となったことから、CSPM（Cloud Security Posture Management）などの技術を用いて、クラウド環境の設定状況を可視化し、管理体制をより充実させることも有効な対策と言えるでしょう。
今回はクラウドを経由してランサムウェアが実行される事例を紹介しました。
本事例から学び取れる教訓は、以下3点と考えられます。
●クラウド環境であっても必要な受信ポートを定義し、不要なポートを制限しておくこと
ポートを適切に制限していれば、外部からの侵入リスクを低減することができる。
●外部に露出する可能性のあるIT領域の設定状況を定期的に確認すること
特に機密情報を扱う場合、外部に露出している可能性を入念に確認する、また可能なかぎり可視化する。
●侵入された場合に備えて、クラウド環境においても社内とのアクセス制限を実施しておくこと
社内環境においても必要な通信のみを許可することで、侵入後の被害を低減できる。
今回の事例に限らず、リモートワークやDX化など組織業態の変化に伴って様々なIT資産や情報資産が増える中では、組織の機密情報を取り扱うリスクや攻撃の対象となりうる領域の危険性を正しく認識し、運用面と技術面の双方からそのリスクを低減していくことが重要です。
また侵入を前提とした対策といった観点では、リスク自体の低減に加えて、インシデントが発生した際の対応手順を整理し、かつ定期的に見直すこと、また対応訓練を行うことも重要と言えます。
今回のように攻撃シナリオを具体的に把握することで、致命的な被害につながり得る脆弱性を事前に把握し対処を施すことが可能になります。
他社のインシデント事例を参考に、自社にとって優先するべきリスク対応を決定することは有効な戦略の1つと言えるでしょう。
インシデント対応事例から学ぶ教訓 シリーズ
セキュリティインシデント事例集（セキュリティ対策状況チェックリスト付属）
Security GO新着記事
国内でも活発化するDDoS攻撃の事例を解説～攻撃者の目的や対策は？～
（2024年12月20日）
AIガバナンスの動向は？各国のAI法規制を概観
（2024年12月20日）
サイバー攻撃でよく悪用される正規ツールとは？
（2024年12月19日）
