このブログでは、ウクライナのエネルギー企業に対するサイバー攻撃の分析結果について報告します。

重要なポイント：

• ESETの研究者は、CERT-UA（ウクライナのコンピューター緊急対応チーム）と共同でウクライナのエネルギー企業に対する攻撃を分析した。
• 破壊的な活動は2022年4月8日に予定されていたが、攻撃の痕跡（アーティファクト）から、少なくとも2週間前には攻撃が計画されていたことが判明。
• 攻撃には、産業用制御システム（ICS: Industrial Control System） を攻撃する能力を保有するマルウェアと、ディスクを完全に消去するワイパー型マルウェアが使用された。ワイパー型マルウェアは、Windows、Linux、Solarisオペレーティングシステムにそれぞれ対応している。
• この攻撃者は2016年にウクライナで大規模停電を引き起こしたマルウェアであるIndustroyerの新バージョンを使用したことを、ESETは確信している。
• 新しい攻撃を実行したのはAPTグループであるSandwormであることを、ESETは確信している。

ESETの研究者は、ウクライナのエネルギー企業を標的としたサイバーインシデントへの対応を行いました。ESETはCERT-UAと緊密に連携し、この最重要インフラのネットワークの修復と保護することができました。

CERT-UAとの協力により、Industroyerマルウェアの新しい亜種を発見しました。ESETとCERT-UAは共同でこのマルウェアをIndustroyer2と命名しました（CERT-UA の発表については、こちらを参照）。Industroyerは、APTグループのSandwormによって2016年にウクライナの電力網を停止するために使用された悪名高いマルウェアです。

Sandwormの攻撃者は、今回、ウクライナの高電圧変電所にIndustroyer2マルウェアを展開しようとしていました。

Sandwormは、Industroyer2の他に、CaddyWiper、ORCSHRED、SOLOSHRED、AWFULSHREDなどの破壊的なマルウェアファミリーも使用しました。ESETは、2022年3月14日にウクライナの銀行への攻撃でCaddyWiperが使用されたことを初めて検出しました（詳細は、CaddyWiperに関するESETのTwitterへの投稿を参照）。CaddyWiperの亜種が、2022年4月8日14:58に、このウクライナのエネルギー企業に対して再び使用されています。

現段階では、攻撃者がこのエネルギー企業に侵入した方法や、ITネットワークから産業用制御システム（ICS）のネットワークに移動した方法は明らかになっていません。図1に、今回の攻撃で使用された各マルウェアの概要を示します。

図2に、攻撃イベントの一連の流れを示します。

2017年にESETの研究者は、2016年12月にウクライナの首都キーウで発生した停電の原因が、Industroyerマルウェア（ESETが命名）であったことを明らかにしました。

当時の攻撃の詳細については、ESETが公開したホワイトペーパー「Win32/Industroyer：産業用制御システムを標的とする新たな脅威」（英語のみ）を参照してください。Industroyerは、電力システムで主に使用されている産業用制御システムを攻撃する能力を保有しています。このマルウェアが攻撃できるのは、IEC-101、IEC-104、IEC 61850、OPC DA規格に対応しているデバイスです。

当時、ESETは「標的となる特定の産業用システム環境で使用される特別な機器にアクセスすることなく、このようなマルウェアを作成およびテストできる攻撃者は極めて少なく、限定される」という見解を述べています。この見解は、2020年に米国政府によって確認され、ロシア軍参謀本部情報総局（GRU）74455部隊の6名の将校が、IndustroyerやNotPetyaなどの複数のサイバー攻撃に関与したとして起訴されています（justice.govの起訴状とSandwormのオペレーションに関するESETの過去のレポートを参照）。

今回発見されたマルウェアはIndustroyerの新しい亜種であり、ESETはこのマルウェアをIndustroyer2と命名しました。

Industroyer2は、108_100.exeという名前のWindowsの実行ファイルとして展開され、2022年4月8日16:10:00（UTC）に実行されるようにタスクがスケジュールされました。PE形式のこの実行ファイルのタイムスタンプによると、2022年3月23日に編集されており、攻撃者は2週間以上前から攻撃を計画していたことが分かります。

Industroyer2は、産業用機器と通信するために、IEC-104（別名IEC 60870-5-104）プロトコルのみを実装しています。また、変電所で使用される保護継電器とも通信します。Industroyer2には、複数のICSプロトコルに対応するペイロードを搭載した完全にモジュール型のプラットフォームであったIndustroyerの亜種（2016年に使用）から若干変更が加えられています。

Industroyer2は、Industroyerのペイロードである104.dllのコードと多くの類似性があります。今回の新しい亜種は、Industroyerと同じソースコードをベースに作成されたことを、ESETは確信しています。

Industroyer2の特徴は、極めて柔軟に構成できることです。マルウェア本体には詳細な設定がハードコードされており、これがマルウェアの動作を決定しています。この仕組みは、別の.INIファイルに構成を保存していたIndustroyerと異なっています。このため、攻撃者は新しい標的や環境に合わせてIndustroyer2を再コンパイルしなければならなくなっています。しかし、Industroyerマルウェアファミリーは過去に2回しか展開されておらず、前回展開されたバージョンから5年が経過しているため、Sandwormのオペレータにとって再コンパイルは特に難しいことはではなかったはずです。

新しい構成フォーマットは文字列として保存され、このマルウェアのIEC-104通信ルーチンに提供されます。Industroyer2は、複数のデバイスと同時に通信することが可能です。具体的な例を示すと、分析した検体には、8つの異なるIPアドレスのデバイスが含まれていました（図4参照）。

ASDU（アプリケーションサービスデータユニット）アドレス、IOA（情報オブジェクトアドレス）、タイムアウトなど、IEC-104プロトコルを介した通信で使用される値が設定されています。

Industroyer2は標的のデバイスに接続する前に、日常の標準的な操作で使用されている正規のプロセスを終了します。さらに、ファイル名に.MZを追加して、このアプリケーションの名前を変更します。これは、正規のプロセスが自動的に再起動しないための処置です。

各デバイスで実行された動作の詳細については現在も分析中です。このコンポーネントは、特定のICSシステムを制御して電力を遮断する能力があると考えられます。

Industroyer2は、ログファイルを生成したり、コンソールウィンドウに進捗を出力したりできます。しかし、前バージョンのように人間が理解できるテキストメッセージではなく、Industroyer2は各種のエラーコードを書き込みます（図5を参照）。これは、Sandwormの開発者が分析を妨害するための難読化の一種と考えられます。

この攻撃者は、Industroyer2をICSネットワークに展開しながら、破壊的なマルウェアであるCaddyWiperの新しいバージョンも展開しています。これは、復旧を遅らせ、エネルギー企業のオペレータがICSのコンソールを再び操作できなくするための妨害工作だと考えられます。また、Industroyer2が実行されたマシンにはCaddyWiperも展開されました。これは攻撃の痕跡を消し去るためだと考えられます。

CaddyWiperの最初のバージョンは、2022年3月14日にウクライナのESETの研究者によって検出されました。このバージョンは、ウクライナの銀行のネットワークに展開されていました。CaddyWiperは、グループポリシーオブジェクト（GPO）を介して展開されており、攻撃者が事前に標的のネットワークを制御していた可能性があります。このワイパー型マルウェアは、接続したドライブのユーザーデータやパーティション情報を消去し、システムの操作や回復を不能にします。

この攻撃者は、このエネルギー企業のネットワークに新しいローダーを使用するCaddyWiperの新しいバージョンを展開しています。CERT-UAは、この新しいバージョンをARGUEPATCHと命名しました。ARGUEPATCHは、リモートIDAデバッガーサーバー（win32_remote.exe）であるHex-Rays IDA Proソフトウェアの正規コンポーネントにパッチを適用したバージョンです。IDA Proは、マルウェア解析機能などソフトウェアのリバースエンジニアリングで主に利用されており、ICS環境での利用は想定されていません。この攻撃者がこのソフトウェアをトロイの木馬の一部として組み入れた理由は不明ですが、防御側の組織に対する嫌がらせである可能性もあります。

ARGUEPATCHはスケジュールタスクによって実行され、あるマシンでは2022年4月8日14:58（UTC）に、Industroyer2が展開されたマシンでは同日の16:20（UTC）に一度起動するように設定されていました。

パッチが適用されたこのバイナリは、暗号化されたシェルコードをファイルからロードし、鍵を使用して復号化します（これらの両方ともにコマンドラインから提供されています）。入力された鍵からシングルバイトのXOR鍵が取り出されて、シェルコードの復号化に使用されます。

復号化されたシェルコードは、CaddyWiperを少し変更したものです。新旧のCaddyWiperのメインルーチンの比較を図6と図7に示します。これらのCaddyWiperは、ドメインコントローラーは消去せず、C:\Users\のファイルとD:\から[:\のドライブを消去します。消去のルーチンはほぼ同じであり、すべてのファイルを0で埋めています。

最後に、CaddyWiperは、IOCTL_DISK_SET_DRIVE_LAYOUT_EXと一緒にDeviceIoControlを、そして、ゼロのInputBufferを\\PHYSICALDRIVE9から\\PHYSICALDRIVE0のすべてのディスクに対して実行します。これにより、ドライブのパーティションの拡張情報であるMBR（マスターブートレコード）またはGPT（GUIDパーティションテーブル）が消去され、マシンが起動できなくなります。

このエネルギー企業のネットワークと、先に攻撃を受けた銀行の両方で、CaddyWiperと一緒にPowerShellスクリプトが検出されています。

このスクリプトは、Active Directoryサービスインターフェイス（ADSI）を使用してグループポリシーオブジェクト（GPO）を列挙します。図8に示すスクリプトは、Mediumのブログで公開されたスニペットとほぼ同じです。

攻撃者は、GPOからCaddyWiperを展開しており、このGPOが存在することを確認するためにスクリプトを使用したと考えられます。

また、標的となったこのエネルギー企業のネットワークでは、LinuxやSolarisシステムを破壊する別のマルウェアも検出されました。この攻撃には、ワームとワイパーの2つのメインコンポーネントが使用されています。ワイパーには、攻撃対象のOS別に2種類の亜種が確認されました。すべてのマルウェアは、Bashで実装されていました。

攻撃者が最初に起動したコンポーネントはワームであり、このワームのファイル名はsc.shでした。このBashスクリプトは、owner引数を使用して起動していない限り、午後2時58分（UTC）にワイパーコンポーネントを起動するスケジュールタスク（cronジョブ）を追加して開始されます（このシステムは、UTCから3時間後のローカルタイムゾーンにあると仮定しています）。これは、ワームを起動するために使用された最初のシステムが自動的に破壊されるのを回避する方法と考えられます。

次に、このスクリプトは、ip routeまたはifconfig -aの結果を確認し、システムからアクセス可能なネットワークを繰り返し表示します。このスクリプトは、収集した各IPアドレスに対して、常にクラスCネットワーク（/24）がアクセス可能であると仮定しています。TCPポート22、2468、24687、522にSSHを使用して、これらのネットワークにあるすべてのホストへの接続を試みます。アクセス可能なSSHサーバーを見つけると、悪意のあるスクリプトから提供されるリストの認証情報を使用してアクセスを試行します。攻撃者は、ワイパーを拡散するために、攻撃前に認証情報を取得していたと考えられます。

システムのセキュリティが侵害されていない場合、マルウェアが新しい標的のマシンにコピーされ、ワームが起動されます。owner引数が指定されるとワームは起動せず、ワイパーが午後2:58（UTC）に起動し、すべてのデータを破壊するようスケジュールされます。これらのシステムにローカルタイムゾーンが設定されていた場合、CaddyWiperによって攻撃されたシステムと同じ時間に、この破壊活動も開始されていたはずです。

Linux向けのこのワイパーの亜種は、変数や関数名が意味のない8文字の単語に置換されて、若干難読化されています。また、ほとんどのリテラル値は、ファイルの冒頭で変数に置き換えられていました。

最終的にLinux向けのワイパーは、システムに接続されているディスク内のファイル、利用可能である場合にはshredを使用して、shredを利用できない場合には単にdd（if=/dev/random）を使用してすべて破壊します。複数のディスクが接続されている場合は、データ消去を並行処理して、処理の高速化を図ります。

ディスクのサイズによっては、ディスク全体を完全に消去するまでに数時間かかる場合もあります。システムを迅速に操作不能にするために、最初にHTTPとSSHのサービスを停止して無効化を試みます。systemctl disableを使用して、これらのサービスを無効化します。サービスが再び有効にならないように、サービスをロードするsystemdユニットファイルをディスクから削除します。

また、/boot、/home、/var/logのファイルは、ドライブを完全に破壊する前に削除されます。この処理により、システムをより早く操作不能にできます。また、ユーザーデータも削除され、攻撃の証拠となるログも削除されます。

悪意のあるスクリプトは最後に、SysRqを使用して強制的に再起動します。すべてのドライブが、無作為に作成されたファイルで埋め尽くされており、OSが起動することはありません。

Linux向けのワイパーとは異なり、Solarisの亜種は難読化されていません。

Linuxの亜種と同様に、この悪意のあるスクリプトは、キーワードssh、http、apache、さらにはora_またはoracleを含むサービスを停止して無効にする処理を繰り返し実行します。これらは、ICSシステムを制御するアプリケーションで使用されている可能性が非常に高いサービスです。これらのサービスを消去すれば、エネルギー企業のオペレータが変電所を再度制御したり、Industroyer2による攻撃の影響をロールバックしたりできなくなります。

systemctlまたはsvcadmのいずれか利用可能なコマンドを使用します。Solarisはsystemdを実行していないため、svcadmコマンドが使用される可能性が高いです。

データベースを削除することからファイルの破壊活動が開始されます。環境変数に含まれているORAで始まるすべてのファイルとディレクトリを、shred、rmコマンドを順に実行して削除します。Oracleのデータベースは、ORACLE_BASE、ORACLE_HOME、およびORACLE_PATHの変数を使用して、データベースファイルやソフトウェアの場所を定義しています。shredが実行されると、バックアップがなければ、データを復元することはできなくなります。

Linuxの亜種の場合と同じように、/boot、/home、/var/logのファイルが最初に削除されます。

スクリプトは、次に、/dev/dsk/にある、システムに接続されたディスクに対して繰り返し同じ処理を実行します。スライス（パーティション）は無視し、完全なディスクに対してのみ処理を実行します。悪意のあるこのスクリプトは、shredを使用して各ディスクのコンテンツ全体を上書きします。消去に要する時間を最小限にするため、すべてのディスクを並行して消去します。

最後に、スクリプトは自らを破壊します。

再び、ウクライナの重要インフラストラクチャを標的としたサイバー攻撃が活発になっています。この新しいIndustroyerを使用した攻撃は、ウクライナのさまざまな業界を標的とした複数のワイパー型マルウェアによる攻撃に続くものです。ESETの研究者は、このような破壊的な攻撃から組織を保護するために、これらの脅威について今後も監視していきます。

このインシデントの調査に協力いただき、検体を提供いただいたCERT_UAに謝意を表します。今回のキャンペーンに関するCERT_UAのアドバイザリは、こちらのリンクから参照できます。

WeLiveSecurityに掲載された調査に関するご質問は、threatintel@eset.comにお送りください。

ESET Researchは現在、独自のAPTインテリジェンスレポートとデータフィードも提供しています。このサービスに関するお問い合わせは、こちらからお問い合わせください。