勤め先がランサムウェア被害にあって、システム復旧に奔走した話

近年、ランサムウェア被害に遭った企業のニュースをよく目にするかと思います。

少し前に実は、私が所属する企業もランサムウェア攻撃に遭いました…

そこで今回は、ランサムウェア被害が発覚してから復旧までに対応したことや、当事者として得た教訓･所感などを備忘録として記載したいと思います。

ランサムウェア被害発覚から復旧までの対応

ランサムウェア攻撃と今回の原因について

ランサムウェア攻撃とは、攻撃者が社内ネットワークに侵入してサーバーやPCを暗号化し、｢データを復元したければ金銭を払ってね｣と要求するサイバー攻撃のことを指します。また、その際に社内データを窃取したうえで、｢公開されたくなければ金銭を払って｣と脅迫するケースもあるようです。このような特徴から、身代金ウィルスとも呼ばれています。

今回、私が所属する会社で受けた被害としては、Active Directoryサーバー(以降:AD)や顧客管理システムを始めとした基幹システム郡に加えて、一部の従業員用PCが暗号化されたうえで、身代金の要求がありました。なお、その支払い要求には応じておりません。

後の調査により、攻撃者はVPN機器の脆弱性を悪用し、社内ネットワークに侵入したと判明しています。

被害の発覚

とある日曜日の朝6時頃、部長からの電話連絡がありました。

部長からの連絡を受け、私はすぐに身支度を済ませてデータセンターに向かうことにしました。

その道すがら、VPN機能自体は生きていたようでしたので、社内ネットワークの中心にあるファイアウォール機器でALL Denyルール(すべての通信を遮断する設定)を有効にしつつ、AWSのSite-to-Site接続やOCI側のFastConnectをOFFにし、クラウドサービス⇔社内ネットワーク間の接続を遮断しました。

なお、ADサーバーなど一部の基幹システムは、クラウドサービス上ではなくデータセンター内にある物理的なオンプレミスサーバー(以降:オンプレサーバー)上で稼働させていました。

今思えば、｢次のサーバー保守切れタイミングで、クラウド移行しようかね～｣なんて話をしていたところでしたので、これが前もって実行できていれば、状況確認や復旧対応がもう少し楽だったかもしれません…

データセンターに到着し、いざ物理サーバー(ホスト機)に直接アクセスしてみると…その配下にある仮想マシン郡が軒並み意味不明な拡張子になっており、暗号化されていました。また、デスクトップ画像が英文で｢データを暗号化した。戻してほしければ以下の連絡先にコンタクトして、ビットコインを払え｣といったものに変更されていることも確認できました。

ひとまずオンプレサーバー郡が接続されているスイッチ(ネットワーク機器)のLANケーブルを抜線し、部長へ連絡を入れることに…

※この際、後の調査時に支障がでないよう、サーバーおよびネットワーク機器の電源はつけっぱなしにしています。

状況を部長に報告してから、指示通りデータセンターから本社へと向かいます。

本社に到着すると、部長とIT部門の役員が待っていました。

電話報告した内容と同じことを両名にも対面報告し、その後すぐに緊急の役員会議が(オンラインミーティングにて)実施されました。

余談ですが、従業員数が数千人程度の会社かつ、私はインフラ+サポートデスク兼務だった兼ね合いから、ほとんどの役員陣とは面識がある状態でしたので、そこまで彼らへの報告に抵抗感はありませんでした。それよりも、基幹システム郡が軒並みダウンしている状態を目の当たりにして、頭の中が｢ヤベー｣という感想で一杯だったことを鮮明に覚えています(^_^;)

気分はまさに、刑事ドラマでよく見る犯行現場の第一発見者的な感じでした。

ここから数カ月の間、帰宅が2日に一度&土日祝休みがなくなる日々の始まりです…

復旧に向けたアクション

3時間ほど続いた緊急の役員会議では、被害状況や営業活動への影響･復旧に向けてどうするかなど、様々な話題で紛糾しました。特に、個人情報流出の有無や個人情報保護委員会への報告等、早急に対応しなければならない事項についてヒートアップしたことが印象に残っています。

自社だけでは初動対応がどうにもならないとの判断に至り、会議終了後すぐに有名どころのセキュリティ会社に支援要請を入れました。この際、経営層の人脈ですぐに先方役員と連絡がつき、その日のうちにNDA&支援に関する契約が締結できたので、初動対応のスピード感は上々だったのではないかと思います。

セキュリティ会社によるフォレンジック調査

協力要請を行ったセキュリティ会社から、まずはサーバーやネットワーク機器など、取得できるSyslogを片っ端から連携するよう指示をいただきました。この対応のため、本社からデータセンターへ再び急行し、それが提出でき次第すぐにまた本社に戻っています。｢臨時の役員会議ミーティングはオンライン開催だったし、自分はデータセンター待機でよかったんじゃ…｣と思ったのは内緒です。当時は自分含め、関係者のみなさんパニック状態でしたので致し方なしですね(；´∀｀)

ちなみに、インシデント発生→社内ネットワークの全遮断→緊急の役員会議→セキュリティ会社への支援要請、Log収集などの初動対応に奔走していたため、この日は自宅に帰れずオフィスで一晩を過ごしました(;_;)

翌日を迎え、経営層から全従業員向けに、サイバー攻撃を受けた旨の通知が配信されました。

営業チームをはじめとした各部門の従業員も、被害当日より｢顧客管理システムや社内ポータルに接続できない｣などで異常は察知されていたようです。

通知が配信された後、基幹サーバー群だけではなく従業員用の社用PCも被害にあっていることが発覚しました。その旨をセキュリティ会社にエスカレーションしてからすぐに、サーバー･ネットワーク機器･社用PCを対象とした全ての社内デバイスでフォレンジック調査が開始されています。

なお、フォレンジック調査の結果が出るまでは、3週間ほど時間がかかりました。

膨大なログを全て、セキュリティ会社にて解析するため、相応の時間がかかるようです。

その解析結果では、VPN機器の脆弱性が悪用されて社内ネットワークに侵入されたこと、セキュリティ対策ソフトが有効になっていない端末でMimikatz(ミミカツ)が実行されて認証情報が窃取されたこと、その認証情報から派生してADの特権IDまで奪取されたこと、が発覚しました。

復旧方針の立案

フォレンジック調査と並行して、｢どのようにシステムを復旧させていくか｣の方針決めも進められていました。インシデント発生から営業活動が停止状態でしたので、対応が遅れれば遅れるほど、金銭的な経営ダメージが拡大していく状況です。ですので経営層からは、早急かつ確実にシステム復旧することが求められていました。正直、プレッシャーが半端なかったです…

もちろん、暗号化された基幹システム郡は廃棄せざるを得ませんし、ネットワークについても新規構築を進める必要があります。

ADサーバーについても、特権が奪取されている兼ね合いから、｢既存環境をバックアップから復元して再利用｣することはできませんし、ADを廃棄するということは、その配下にある社用PC数千台も再キッティングが必須、ということになります。※この時点では、フォレンジック調査の結果がいつ出るのか不明かつ、そもそも原因が特定できるかどうかも目処がたっていない状況でした。

そんな状況において、まず必要だと判断されたのが[安全なネットワーク&認証基盤(AD)の再構築]でした。

幸いなことに、侵害を受けていないネットワーク環境も一部存在していました。

また、AWSであればアカウントを新規発行することで、完全クリーンな環境を準備することができます。この新AWS環境に必要最低限の基幹システム郡を構築し、安全が確認できた社内ネットワークと再接続したうえで、再キッティング済みなクリーンPCを配置する方針に決まりました。

ただし弊社は、店舗型の営業拠点が全国に数百店舗あるため、上記の方法では時間が掛かりすぎて営業再開がいつまで経ってもできない、という問題にも直面しました。

そこで、元々契約のあったMicrosoftのEntra ID(旧称：Azure AD)+Intuneサービスを活用することで、社内ネットワークに依存しないデバイス管理手法も取り入れることにしました。

本社などの事務所型拠点においてはデバイスをADで管理し、営業拠点となる店舗においてはデバイスをEntra ID+Intuneで管理する、といった構成です。

※Entra ID+Intune管理のデバイス(以降:Entra仕様PC)であれば、PCがテザリング接続(社内ネットワーク外)でもメールやSharePoint/Teams等のサービスが利用できるため、不便ではあるものの営業再開できる水準になる、と判断されました。

取り急ぎの対応として、以下のような段取りで復旧を進めることに。

再構築の実行

店舗型営業拠点向けの対応

まず私は取り急ぎ、｢Entra ID+Intuneでデバイス管理するための環境整備｣に着手しました。

Microsoft環境へのアクセス制限(条件付きアクセス)が今までGIPベースだけだったものを、｢Entra ID Join｣等のデバイス管理状況も参照してアクセス可否が判定されるよう調整しました。

併せて、業務に必要なアプリ類が遠隔インストールできるよう、Win32アプリ配布機能から.intunewinファイルの作成&登録をしたり、USBなどの外部ストレージ利用禁止や無操作時の画面ロック強制など、必要最低限のIntune構成プロファイル(AD環境でいうGPO)を作成したり、といった調整も行っています。

Entra ID+Intuneでデバイス管理するための下地が整ったあとは、ユーザーから回収したPCを再キッティングしていくフェーズです。

ここではキッティング効率化のため、Sysprepを適用したPCクローニング用マスターデータを作成しました。以降のキッティング作業においては、マスターデータを回収PCに流し込んでいく単純作業となりますので、営業や総務など他部門の方々に協力いただきながら、人海戦術でゴリ押しています。余談ですが、この対応に必要な16GB以上のUSBやLANケーブル･ハブ等を、近隣の家電ショップから大量購入しました。家電屋で｢あるだけ全部ください｣なんて依頼したのは流石に初めてです(-_-;)

事務所型拠点向けの対応

店舗型営業拠点向けの対応が、後続のキッティング&配送チームにパスでき次第、次はAWS新規アカウントの開設に着手しました。

VPCまわりの設定を一通り整え、EC2でWindowsサーバーを起動し、AD DS/AD CS/Entra Connect（旧称：Azure AD Connect)/Radius等の基幹システム郡を再構築しています。

余談ですがAD DS再構築においては、数千人のユーザーアカウントを新規発行する必要がありました。こちらは人事情報をベースに、従来とは異なるアカウントID(sAMAccountName)のパターンでCSVを作成し、それをShellコマンドでインポートすることにより、一括作成しています。

ベースとなるサーバー郡が整ったあとは、AWS環境をSite to Site接続にて、侵害を受けていない社内ネットワークと接続していきました。また、社内ネットワークのDNS向き先を新ADに向ける等の必要な調整を行い、問題なく新AD配下の社用PCが利用できる環境を整えています。

この新AD配下の社用PCについてもキッティング作業を効率化するため、Sysprepを適用したPCクローニング用マスターデータを作成しました。あとのキッティング作業はEntra仕様PCと同様に、他部門も交えた人海戦術で、急ピッチに対応を進めていきました。

営業再開

従業員に再設定済みデバイスが概ね行き渡り、本格的な営業再開となるまでは2ヶ月半ほど掛かりました。※実際には、端末が届いたユーザーから順次再開しており、早いユーザーは3週間くらいで復帰されてました。

この短期間で基幹システム郡をほぼ全て再構築して、数千台のPCを再キッティングするというハードタスクを完遂できたのは、社員一丸となって事に当たれたことが大きかったと思います。

なお以上の内容は、営業再開できた段階までの話となります。

その後のセキュリティ強化施策や利便性をインシデント前の水準まで戻す調整、店舗型営業拠点のネットワーク機器総入替え等については、もう暫く走り続けることになりました。いずれにせよ、ランサムウェアによる影響は多大なものでした…

復旧対応で得た教訓･所感

バックアップは必須･されど過信はできない

今回のインシデントでは残念ながら、｢バックアップがあるからすぐに復旧できる｣とはなりませんでした。

そもそも｢いつの時点で、どこまで侵入が成功していたのか｣が確定できないと、｢いつ時点のバックアップデータなら利用OKなのだろうか｣と判断ができません。この部分の調査は自社解決できなかったため、セキュリティ会社にご支援いただくことになり、そこそこ時間を要しました。

また、バックアップデータを活かせたのは”データ基盤のみ”でした。

このデータ基盤についても、まずはクローズドな環境にリストアしてから、セキュリティ会社にフォレンジック調査をお願いしています。その結果が問題ないと確認できてから、中身のデータだけを再構築した顧客管理用システムにインポートする、といった手順になっていましたので、バックアップで復元したサーバーごとそのまま活用、とはなっていません。

ADなどの認証基盤については前述したとおり、｢再構築が必要だよね｣となりましたので、バックアップデータはあまり役に立ちませんでした。

ランサムウェアなどのサイバー攻撃においては、システム障害や災害対策用に用意していたバックアップ環境をそのまま利活用するのは難しいのかもしれません。ただ、データ基盤に関してはバックアップが存在していないと、そもそも復旧がお手上げ状態になってしまいます。ですので教訓として、｢バックアップは必須･されど過信はできない｣と掲題させていただきました。

このインシデント以降、｢システムのガワだけ再ビルドして、中身のデータはバックアップから引っ張ってきてマージさせる｣段取りについても、しっかり整備されることになりました。

クラウドサービスは救世主

ランサムウェアで暗号化されたサーバー群は、フォレンジック調査のため、ホスト機ごとセキュリティ会社に預けることになりました。そのため再構築にあたり、別のサーバー稼働環境をすぐに手配する必要がありました。

この課題について、AWSなどのクラウドサービスであれば、アカウント開設から環境構築開始まで、その日のうちにできてしまいます。

また、メール/クラウドストレージ(Microsoft 365)や人事情報管理などをSaaS系に依存していたのも、結果として功を奏しました。これらのクラウドサービスにおいては、不正ログインがなかったことを確認し、全アカウントの認証情報を強制リセットすることで、クリーンになった端末が手元に届いたユーザーからすぐに利用再開できています。

有名どころのクラウドサービスには大抵、ログイン時の多要素認証必須化オプションもありますし、社内ネットワーク外に情報を持たせることのメリットが活きていた認識です。

生成AIは有効な補助輪

ADサーバーを立ち上げるだけであれば、そんなに難易度は高くないかと思います。また、ADの堅牢化を実施するには、推奨されるパラメータが｢CIS Benchmarks｣から紹介されていますし、セキュリティ会社に支援を求める選択肢もある認識です。

問題は、ユーザーアカウント再作成などの自社内で完結せざるを得ない対応項目です。

数千人規模のユーザーアカウントを1つ1つ手作業で作成していくには、流石に時間がかかりすぎます。

そこで役に立ったのが、生成AI(ChatGPT)でした。

作りたいアカウント情報を一旦CSV上にまとめて、それをPowerShellコマンドで読み込むことにより、一気にアカウント作成が行えます。このShellコマンドの調整に、生成AIが大活躍でした。

また、新規作成したADアカウントを、これまた新規構築したEntra Connectサーバーを介して、既存のMicrosoft 365アカウントと同期させるためには、ユーザーアカウントごとにハードマッチングで紐づけを行う必要がありました。この処理においても、必要なPowerShellコマンドの調整で生成AIに助けられています。

脆弱性対策･資産管理の徹底は重要

前述したとおり、フォレンジック調査の結果では以下内容が発覚しました。

• VPN機器の脆弱性が悪用されて社内ネットワークに侵入されたこと
• セキュリティ対策ソフトが有効になっていない端末でMimikatz(ミミカツ)が実行されて認証情報が窃取されたこと
• その認証情報から派生してADの特権IDまで奪取されたこと

インシデントが発生する前のネットワーク環境においては、数百ある店舗型営業拠点も含めるとVPN機器が大量に存在していました。また、それらを一括管理する仕組み(例えばForticloudやMerakiなど)も導入されておりません。※予算申請が却下され、導入できなかった背景です。

そのため、ファームウェアアップデートを実施する際は、夜間に1台ずつ管理コンソールにアクセスして、地道に更新対応を行っていく必要があり、正直なところ対応が追いついていませんでした。

こんな状況でしたので、調査結果を聞いたときは｢やっぱそうですよね…｣と妙に納得したのを覚えています。

なお、復旧対応後はネットワーク構成を変更し、社内ネットワーク用VPN内に店舗型営業拠点を組み込まない方針にしました。社内ネットワークに属しているのは、主要な事務所型拠点･データセンター･AWS&OCIだけな構成です。

また、全てのVPN機器(UTMルーター)を交換し、それらをクラウドで一括管理できる環境も整えました。ファームウェア更新やファイアウォール設定の変更が効率的に実施できる環境です。

セキュリティ対策ソフトが有効になっていない端末が存在していた理由については、ライセンス管理の仕様および運用ミスが原因でした。

退職者の社用PCを回収し、次の貸与ユーザー向けに再キッティングを行うと、自動的にセキュリティ対策ソフトも導入されるようPCマスター側で調整していました。そのため、キッティング時点での導入忘れは生じにくい環境です。

しかしながら、PC再キッティング後にセキュリティ対策ソフトの管理画面を確認すると、同じシリアルの端末が重複して登録されている状況になっています。同じPCにおいて、初期化→再インストールを実施した際に、自動名寄せされない仕様だったことから、運用チーム側で定期的にセキュリティ対策ソフトの重複ライセンス解除を行っていたようです。その際、本来消すべきではない端末のセキュリティソフトライセンスを消してしまったことから、セキュリティ対策ソフトが有効になっていない端末が発生したとのことでした。

このような原因を踏まえて、インシデント発生後にキッティングしたPCには、名寄せが自動実行される別のセキュリティソフトを導入することにしました。また、元々がEPP機能だけのセキュリティソフトでしたので、EDR機能も含まれている製品を選定しています。

ランサムウェア被害に遭わないためには、脆弱性対策･資産管理の徹底が重要です。

とは言うものの、運用負荷の高い環境でこれらの対応を継続していくことは正直難しかったです。

ですので、クラウドで一括管理したり、処理を極力自動化させたりといった、人の手に依存しすぎない環境整備が重要なのかもしれません。

さいごに

今回は、ランサムウェア被害が発覚してから復旧までに対応したことや、当事者として得た教訓･所感などを備忘録として記事にしました。

このインシデントでは、｢業務停止による機会損失や多額な復旧コスト｣という経営的なインパクトだけでなく、一緒に働いていた情シスメンバーたちも疲弊して離職していくなど、様々な負の連鎖が発生しています。

正直、同じような経験は二度とごめんです…

ポジティブに考えると、インシデント発生時の初動対応からシステム復旧方針の策定･実行といった一連の対応に関わることができたのは、貴重な経験だったかもしれません。

それでは!