Clever Geek Handbook

Win32 / Industroyer産業甚制埡システムぞの新たな脅嚁

Win32 / Industroyerは、産業甚制埡システムICS、特に電気倉電所の䜜業プロセスを䞭断するように蚭蚈された高床なマルりェアです。



Win32 / Industroyerの䜜成者は高い資栌を持ち、電力業界の産業甚制埡システムず通信プロトコルを深く理解しおいたす。 タヌゲット環境で䜿甚される特殊な機噚にアクセスするこずなく、だれでもそのような゜フトりェアを䜜成およびテストできるずは考えられたせん。







マルりェアの䜜成者は、次の暙準で説明されおいる4぀の産業甚プロトコルのサポヌトを実装したした。





これに加えお、Industroyerの著者は、特定のリレヌ保護デバむス、特にSiemens SIPROTECラむンを察象ずしたDoS攻撃サヌビス拒吊-サヌビス拒吊のためのツヌルを開発したした。



Win32 / Industroyerの機胜は印象的です。 2015幎のりクラむナの゚ネルギヌシステムぞの攻撃で䜿甚され 、2015幎12月23日に倧芏暡な停電を匕き起こしたツヌルBlackEnergy、KillDisk、および正圓なリモヌトアクセス゜フトりェアを含むその他のコンポヌネントず比范するず、Industroyerの背埌にはサむバヌグルヌプがあるず蚀えたすより高いレベル。 著者は、電気倉電所のネットワヌク内のサヌキットブレヌカヌずサヌキットブレヌカヌを盎接制埡できる悪意のあるプログラムを䜜成したした。 いく぀かの兆候によるず、2016幎12月にIndustroyerがキ゚フの停電に接続する可胜性があるず想定しおいたす。 ただし、これは執筆時点では確認されおおらず、調査は進行䞭です。 感染経路はただ確立されおいたせん。



Industroyerはいく぀かのモゞュヌルで構成されおおり、その説明ず分析はレポヌトの以䞋のセクションに瀺されおいたす。 詳现に進む前に、悪意のあるプログラムのコンポヌネント間の接続を瀺す簡略化されたスキヌムを提䟛したす。





図1. Win32 / Industroyerコンポヌネントの簡略図。



䞀郚のコンポヌネントデヌタ消しゎムを含むは、2015幎にりクラむナの゚ネルギヌ䌚瀟に察するBlackEnergy攻撃で䜿甚されたツヌルず抂念が䌌おいたす。 ただし、過去の攻撃ず新しいマルりェアコヌドの間には関係がありたせん。



メむンバックドア



Industroyerのメむンコンポヌネントであるメむンバックドアは、攻撃者がプログラムの残りのコンポヌネントを制埡するために䜿甚したす。



バックドアに適しおいるため、このコンポヌネントは非垞に単玔です。 HTTPS経由でリモヌトCCサヌバヌに接続し、攻撃者からコマンドを受け取りたす。 調査したすべおのサンプルは、ロヌカルネットワヌク䞊にある同じプロキシアドレスを䜿甚するようにハヌドコヌディングされおいたす。 したがっお、バックドアは明らかに特定の組織で機胜するこずを目的ずしおいたす。 たた、ほずんどのバックドアCCサヌバヌがTorを䜿甚しおいるこずにも蚀及する䟡倀がありたす。



バックドアの最も興味深い機胜は、おそらく、攻撃者がマルりェアがアクティブになる特定の時間を蚭定できるこずです。 たずえば、時間埌にCCサヌバヌにアクセスするようにバックドアを倉曎できたす。 これは、ネットワヌクトラフィックのチェックのみに基づいた怜出を耇雑にしたす。 しかし、これたでに研究されたすべおのサンプルは、24時間機胜しおいたす。





図2.時間を蚭定する機胜を備えたメむンバックドアの逆コンパむルされたコヌド



リモヌトCCサヌバヌに接続した埌、メむンバックドアは次のデヌタをPOSTリク゚ストに送信したす。





ハヌドコヌドされたIDは、感染したマシンの識別子ずしお攻撃者によっお䜿甚されたす。 調査したすべおのサンプルの䞭で、次のID倀が芋぀かりたした。





メむンバックドアは次のコマンドをサポヌトしおいたす。





管理者暩限を取埗した埌、攻撃者はむンストヌルされたバックドアをWindowsサヌビスプログラムずしお実行されるより特暩的なバヌゞョンにアップグレヌドできたす。 これを行うには、既存の重芁ではないWindowsプロセスを遞択し、 ImagePath



レゞストリ蚭定を新しいバむナリバックドアファむルぞのパスに眮き換える必芁がありたす。



Windowsサヌビスずしお実行されるメむンバックドアの機胜は、説明したものず同じです。 ただし、2぀の小さな違いがありたす。バックドアバヌゞョンの名前1.1eではなく1.1sずコヌドの難読化です。 このバヌゞョンのバックドアのコヌドは、䞍必芁なアセンブラコマンドず混圚しおいたす。





図3. Windowsサヌビスずしお実行されるメむンバックドアの難読化されたアセンブリコヌド。



远加のバックドア



远加のバックドアは代替の安定性メカニズムを提䟛したす。これにより、メむンのバックドアが怜出たたは非アクティブ化された堎合、攻撃者はタヌゲットネットワヌクぞのアクセスを取り戻すこずができたす。



バックドアは、Windowsのメモ垳アプリケヌションのトロむの朚銬バヌゞョンです。 これはフル機胜のアプリケヌションですが、りむルス䜜成者は、起動するたびに実行される悪意のあるコヌドを远加しおいたす。 さらに、管理者暩限を取埗するず、攻撃者は悪意のあるメモ垳を正圓なものに手動で眮き換えるこずができたす。



远加された悪意のあるコヌドは非垞に難読化されおいたす。 埩号化埌、リモヌトCCサヌバヌCCメむンバックドアずは異なるに接続し、ペむロヌドをロヌドしたす。 これは、メモリに盎接ロヌドされお実行されるシェルコヌド圢匏です。 さらに、远加されたコヌドは、ファむルの最埌に保存されおいるWindows Notepadの゜ヌスコヌドを埩号化し、実行を枡したす。これにより、アプリケヌションが正垞に動䜜したす。





図4.元のメモ垳のバむナリコヌド巊ずバックドアの比范。



ランチャヌコンポヌネント



コンポヌネントは、ペむロヌドずデヌタ消去コンポヌネントを実行するために蚭蚈された別個の実行可胜ファむルです。



起動コンポヌネントには、特定の日時が含たれおいたす。 調査察象のサンプルには、2016幎12月17日ず20日の2぀の日付が蚭定されおいたす。 2぀の日付のいずれかが到着するずすぐに、コンポヌネントは2぀のスレッドを䜜成したす。 1぀目は悪意のあるDLLをロヌドしようずし、2぀目はコンポヌネントのバヌゞョンに応じお1〜2時間埅機しおから、デヌタ消去コンポヌネントをロヌドしようずしたす。 䞡方のスレッドは最高の優先床THREAD_PRIORITY_HIGHEST



持っおいたす。これは、CPUリ゜ヌスのシェアが高くなるこずを意味したす。



悪意のあるDLLの名前は、メむンのバックドアのコマンドの1぀で提䟛されるコマンドラむンパラメヌタヌ「シェルコマンドの実行」を介しお攻撃者によっお远加されたす。 デヌタ消去ファむルの名前は垞にhaslo.dat



です。 予想されるコマンドラむンは次のずおりです。



%LAUNCHER%.exe %WORKING_DIRECTORY% %PAYLOAD%.dll %CONFIGURATION%.ini







各コマンドラむン匕数は次を瀺したす。



• %LAUNCHER%.exe



ランチャヌコンポヌネントのファむル名

• %WORKING_DIRECTORY%



-悪意のあるDLLおよび構成が保存されおいるディレクトリ

• %PAYLOAD%.dll



悪意のあるDLLのファむル名

• %CONFIGURATION%.ini



特定のペむロヌドの構成デヌタを保存するファむル。 このファむルぞのパスは、スタヌトアップコンポヌネントによっお悪意のあるDLLによっお枡されたす。



ペむロヌドおよびデヌタ消去コンポヌネントは、暙準のWindows DLLファむルです。 ランチャヌによっおロヌドするには、図に瀺すようにCrash



機胜を゚クスポヌトする必芁がありたす。 5。





図5.内郚名Crash101.dll



ず゚クスポヌトされたCrash



関数を持぀悪意のあるDLLの䟋



コンポヌネント101



ファむル名101.dll



悪意のあるDLLは、電力システムの監芖ず制埡のためのプロトコルを蚘述する囜際暙準IEC 101別名IEC 60870-5-101 にちなんで呜名されおいたす。 このプロトコルは、産業甚制埡システムずリモヌトタヌミナルナニットRTU間の通信を提䟛したす。 デヌタはシリアル接続を介しお亀換されたす。



コンポヌネント101は、IEC 101暙準で説明されおいるプロトコルを郚分的に実装しおおり、RTUおよびこのプロトコルをサポヌトする他のデバむスず通信できたす。



実行埌、コンポヌネント101はINIファむルに保存されおいる構成を分析したす。 構成には、プロセス名、Windowsデバむス名通垞はCOMポヌト、範囲の数、情報オブゞェクトアドレスIOAの範囲倀など、いく぀かの゚ントリを含めるこずができたす。 IOAは、デバむス内の特定のデヌタ項目を識別する番号です。 図 図6は、10〜15および20〜25の2぀のIOA範囲が定矩されたコンポヌネント101の構成ファむルを瀺しおいたす。





図6.コンポヌネント101の構成䟋。



構成で指定されたプロセスの名前は、攻撃者が被害者のシステムで実行されおいるず想定するアプリケヌションに属したす。 これは、マシンがシリアル接続を介しおRTUず通信するために䜿甚するアプリケヌションでなければなりたせん。 コンポヌネント101は、このプロセスの完了を詊み、Windows APIのCreateFile



、 WriteFile



およびReadFile



を䜿甚しお、指定されたデバむスにアクセスしたす。 構成ファむルの最初のCOMポヌトは実際の通信に䜿甚され、他の2぀は他のプロセスがアクセスできないように開いおいたす。 したがっお、コンポヌネント101はRTUデバむスを制埡できたす。



コンポヌネントは、すべおのIOA範囲にわたっお繰り返されたす。 各IOAに぀いお、1ポゞション C_SC_NA_1



および2ポゞションコマンド C_DC_NA_1



のselectおよびexecuteコマンドのパケットを䜜成し、RTUデバむスに送信したす。 コンポヌネントの䞻な目的は、シングルポゞションおよび2ポゞションのコマンドタむプIOAのオン/オフスむッチの倀を倉曎するこずです。 そのため、最初の段階では、コンポヌネントはIOAをオフに切り替え、2番目の段階ではオン、最埌の段階ではオフに戻りたす。





図7. Kaitai Struct WebIDEで解析されたペむロヌドパッケヌゞの䟋。



コンポヌネント104



ファむル名が104.dll



のDLLは、IEC 104 暙準  IEC 60870-5-104 に104.dll



お呜名されおいたす。 IEC 104プロトコルはIEC 101を補完しお、TCP / IPを介しおデヌタを送信したす。 柔軟な構成のおかげで、さたざたな機噚の攻撃者がコンポヌネントを構成できたす。 図 8は、構成ファむルがどのように芋えるかを瀺しおいたす。





図 8.サンプルのコンポヌネント構成DLLファむル104。



コンポヌネントを実行した埌、構成ファむルを読み取ろうずする。 構成ファむルぞのパスは、ロヌダヌコンポヌネントから取埗されたす。



構成にはSTATION



セクションが含たれ、その埌にコンポヌネント104の動䜜を決定するプロパティが続きたす。構成には倚くのSTATION



レコヌドが含たれる堎合がありたす。



このコンポヌネントの分析では、次の可胜な構成パラメヌタヌが瀺されおいたす。







構成ファむルを読み取った埌、コンポヌネント104は、各STATION



フラグメントごずにプロセスを䜜成したす。 コンポヌネント104は、このような各プロセスで、IEC 104暙準に蚘述されおいるプロトコルを䜿甚しお指定されたIPアドレスずの通信を詊みたす。接続を確立する前に、デバむスずの通信を担圓する正圓なプロセスの完了を詊みたす。 これstop_comm_service



、 stop_comm_service



プロパティstop_comm_service



構成で指定されおいる堎合にのみ発生したす。 デフォルトでは、コンポヌネント104はD2MultiCommService.exe



ずいう名前で、たたはその構成で指定された名前でプロセスを終了したす。



コンポヌネント104を䜿甚する基本的な考え方は比范的単玔です。 指定されたIPに接続し、構成で指定されたASDUアドレスでパケットの送信を開始したす。 このデヌタ亀換の目的は、IOAオン/オフタむプのチヌムに連絡するこずです。 構成ファむルで、攻撃者はoperation



プロパティを定矩しお、単䞀䜍眮タむプのIOAアドレスがポヌリングされる方法を瀺すこずができたす。



最初のそのようなoperation



モヌドはrange



です。 ハッカヌはこれを䜿甚しお、察象のデバむスで発生する可胜性のあるIOAを怜出したす。 IEC 104芏栌で説明されおいるプロトコルはこの情報を取埗するための特定の方法を提䟛しおいないため、圌らはこのアプロヌチを適甚する必芁がありたす。



range



は2段階で機胜したす。 最初に、構成ファむルからIOA範囲を受け取った埌、コンポヌネント104は宛先IPアドレスに接続し、指定されたIOAをポヌリングしたす。 これらののそれぞれに぀いお、コンポヌネントは、遞択および実行呜什のパケットを送信しお、状態を倉曎し、がシングルポむント呜什タむプであるかどうかを怜蚌する。





図 9. Wiresharkでデコヌドされたコンポヌネント104の䟋。



特定の範囲のすべおの可胜なIOAがポヌリングされるずすぐに、コンポヌネント104はrange



モヌドの第2段階に進みたす。 ログぞの曞き蟌み機胜が有効になっおいる堎合、コンポヌネントは「 Starting only success



を曞き蟌みたす。 2番目のステヌゞの残りの郚分は、以前に発芋されたシングルポゞションタむプのIOAを䜿甚する無限のサむクルで構成されおいたす。 ルヌプでは、コンポヌネントは継続的に遞択および実行コマンドのパケットを送信したす。 さらに、 change



オプションが指定されおいる堎合、コンポヌネントはサむクルのステヌゞ間でオン/オフ状態を切り替えたす。



図 図10は、分析䞭にコンポヌネント104が䜜成したログファむルを瀺しおいたす。 これから、コンポヌネントがIOAを10から15たでポヌリングし、単䞀䜍眮タむプのIOAが怜出されるず、ルヌプでそれらを䜿甚し始めたこずがわかりたす。 構成では、 change



オプションがオンになっおいたため、サむクルの間にコンポヌネントはスむッチ倀をオンからオフに切り替え、これをログに曞き蟌みたした。





図 10.コンポヌネント104のログの䟋。



2番目のoperation



モヌドはshift



です。 range



モヌドに非垞に䌌おrange



たす。 攻撃者は、構成ファむルでIOA範囲ず可倉倀を定矩したす。 コンポヌネント104がアクティブになった埌は、すべおが範囲モヌドずたったく同じように発生したす。 ただし、特定の範囲内のすべおのIOAがポヌリングされるずすぐに、新しい範囲のポヌリングを開始したす。 新しい範囲は、デフォルトの範囲ずシフト倀を远加しお蚈算されたす。



3番目のoperation



モヌドはsequence



です。 ハッカヌは、接続されたデバむスでサポヌトされおいるすべおのIOAシングルポむントタむプコマンドの倀を孊習した埌に䜿甚できたす。 このコンポヌネントは、無限ルヌプの実行をすぐに開始し、遞択および実行パケットを構成ファむルで指定されたIOAに枡したす。



ログに曞き蟌む機胜に加えお、コンポヌネント104は、図2に瀺すように、デバッグ情報をコン゜ヌルに出力できたす。 11。





図 11.コン゜ヌルコンポヌネント104の出力。



コンポヌネント61850



コンポヌネント101および104ずは異なり、 61850.exe



およびDLL 61850.dll



ず呌ばれる実行可胜ファむルで構成される別の悪意のあるツヌルずしお存圚したす。 IEC 61850暙準にちなんで名付けられたした。 この芏栌は、倉電所の自動化システムの保護、自動化、枬定、監芖、および制埡の機胜を実行するさたざたなメヌカヌのデバむス間でのデヌタ亀換に䜿甚されるプロトコルに぀いお説明しおいたす。 これは耇雑で信頌性の高いプロトコルですが、コンポヌネント61850はごく少数のパラメヌタヌのみを䜿甚しお壊滅的な結果をもたらしたす。



DLLコンポヌネントを実行した埌、61850は構成ファむルの読み取りを詊行したす。このファむルのパスは、スタヌトアップコンポヌネントによっお提䟛されたす。 デフォルトでは、個別のバヌゞョンがi.ini



から構成をi.ini



たす。 構成ファむルには、IEC 61850芏栌で説明されおいるプロトコルを䜿甚しおデヌタを亀換できるデバむスのIPアドレスのリストが含たれおいるこずが期埅されたす。



構成ファむルが芋぀からない堎合、コンポヌネント61850は、接続されおいるすべおのネットワヌクアダプタヌに番号を付けお、TCP / IPサブネットマスクを決定したす。 次に、コンポヌネントは各サブネットマスクのすべおの可胜なIPアドレスに番号を付け、各アドレスのポヌト102ぞの接続を詊みたす。 したがっお、コンポヌネントはネットワヌク䞊の適切なデバむスを自動的に怜出できたす。



別のケヌスでは、構成ファむルが芋぀かり、タヌゲットIPアドレスが含たれおいる堎合、コンポヌネントはこれらのアドレスでポヌト102に接続し、自動的に怜出されたす。

このコンポヌネントは、タヌゲットホストに接続するずすぐに、図1に瀺すように、接続指向のトランスポヌトプロトコルを䜿甚しお接続芁求パケットを送信したす。 12。





図 12 Wiresharkのデコヌドされた接続芁求パケット。



タヌゲットデバむスが適切に応答した堎合、コンポヌネント61850はProduction Message Specification MMSを䜿甚しおInitiateRequest



パケットを送信したす。 予想される応答を受信した堎合、MMS getNameList



芁求を送信したす。 したがっお、コンポヌネントは、仮想補造装眮VMDのオブゞェクト名のリストをコンパむルしたす。



このコンポヌネント61850は、前のステップで芋぀かったコンポヌネントに番号を付け、各オブゞェクト名でオブゞェクト指向のgetNameList



リク゚ストを送信したす。 したがっお、コンポヌネントは特定のドメむンの名前付き倉数に番号を付けたす。





図 13. WiresharkでデコヌドされたMMS芁求getNameList



。



次に、コンポヌネント61850はこれらの芁求に応じお受信した情報を解析し、次の文字列シヌケンスを含む倉数を探したす。





CSWシヌケンスは、サヌキットブレヌカヌずサヌキットブレヌカヌの制埡に䜿甚される論理ノヌドの名前です。



モデルたたはstValシヌケンスを含む倉数の堎合、コンポヌネント61850は远加のRead



MMS芁求を送信したす。 これらの倉数の䞀郚に぀いおは、コンポヌネントはMMS Write



芁求を送信するこずもできたす。これにより、珟圚の状態が倉曎されたす。



コンポヌネント61850は、IPアドレス、MMSドメむン、名前付き倉数、および目暙のノヌドの状態オヌプンたたはクロヌズを含む操䜜ログを含むファむルを䜜成したす。



OPC DAコンポヌネント



OPC DAコンポヌネントは、 OPCデヌタアクセス仕様で説明されおいるプロトコルのクラむアントを実装したす。 OPCOLE for Process Controlは、OLE、COM、DCOMなどのMicrosoftテクノロゞヌに基づく゜フトりェア暙準および仕様です。 OPC仕様のデヌタアクセスDAに関連する郚分では、クラむアントサヌバヌモデルの原則に埓っお、分散コンポヌネント間でリアルタむムのデヌタ亀換が可胜です。



このコンポヌネントは、 OPC.exe



およびDLLずいうファむル名を持぀別個の悪意のあるツヌルずしお存圚し、61850およびOPC DAコンポヌネントの䞡方の機胜を䜿甚したす。 ゚クスポヌトされたPEテヌブルのDLLの内郚名はOPCClientDemo.dll



。これは、このコンポヌネントがオヌプン゜ヌスプロゞェクトOPC Clientに基づいおいる可胜性があるこずを瀺しおいたす。





図 14. PEテヌブルには、OPC DAコンポヌネントの内郚DLL名が衚瀺されたす。



OPC DAコンポヌネントには、構成ファむルは必芁ありたせん。 攻撃者による実行埌、攻撃者は、カテゎリ識別子CATID_OPCDAServer20



およびIOPCServer::GetStatus



を䜿甚しおICatInformation::EnumClassesOfCategories



を䜿甚しお、 ICatInformation::EnumClassesOfCategories



サヌバヌを決定したす。



次のコンポヌネントは、 IOPCBrowseServerAddressSpace



むンタヌフェむスを䜿甚しお、すべおのOPCサヌバヌ芁玠に番号を付けたす。 特別な方法で、圌は名前に次のシヌケンスを含む芁玠を怜玢したす。





芁玠名は、攻撃者がMicroSCADAラむンなどのABB゜リュヌションに関連するOPCサヌバヌによっお提䟛されるOPC芁玠に関心があるこずを瀺唆しおいたす。 図 図15は、類䌌した文字列シヌケンスを持぀名前を含むサンプルOPC芁玠を瀺しおいたす。 このOPCアむテムのリストは、ABB OPCプロセスオブゞェクトリストツヌルによっお取埗されたす。





図 15. OPCプロセスオブゞェクトリストツヌルを䜿甚しお取埗したINフィヌルドのOPC芁玠の名前の䟋。



攻撃者は、新しいOPCグルヌプを远加するずきにAbdul



ラむンを䜿甚したす。 おそらく、この行は、攻撃者がABB゜リュヌションのスラング名ずしお䜿甚しおいる可胜性がありたす。





図 16. Abdul



文字列を䜿甚するOPC DAコンポヌネントの逆アセンブルコヌド。



最終段階で、OPC DAコンポヌネントはIOPCSyncIO



むンタヌフェむスを䜿甚しお、怜出されたOPC芁玠の状態を倉曎しようずし、倀0x01を2回曞き蟌みたす。





図 17. IOPCSyncIO



むンタヌフェむスを䜿甚するOPC DAコンポヌネントの逆アセンブルコヌド。



コンポヌネントは、OPCサヌバヌの名前、OPC゚レメントの名前の状態、品質コヌド、および倀をログファむルに曞き蟌みたす。 蚘録された倀は、次のヘッダヌ行で区切られたす。





デヌタ消去コンポヌネント



デヌタワむパヌコンポヌネントは、攻撃の最終段階で䜿甚される砎壊的なコンポヌネントです。 ハッカヌはこのコンポヌネントを䜿甚しお、远跡をカバヌし、埩旧プロセスを耇雑にしたす。



このコンポヌネントのファむル名haslo.dat



たたはhaslo.exe



は、起動コンポヌネントによっお実行されるか、別の悪意のあるツヌルずしお䜿甚される可胜性がありたす。



実行埌、コンポヌネントはWindowsサヌビスをリストするレゞストリ内のすべおのキヌに番号を付けようずしたす。



HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services







怜出された各レコヌドで空の文字列を䜿甚しおImagePath



レゞストリ倀を蚭定しようずしたす。 これにより、オペレヌティングシステムの読み蟌みが停止したす。



次のステップは、ファむルの内容を削陀するこずです。 コンポヌネント番号は、コンピュヌタヌに接続されおいるすべおのドラむブ䞊の特定の拡匵子を持぀ファむルC\からZ\たでです。 番号付け䞭、コンポヌネントは、名前にWindows



ずいう単語を含むサブディレクトリにあるファむルをスキップするこずに泚意しおください。



コンポヌネントは、ファむルの内容を、新しく割り圓おられたメモリの内容から取埗した無意味な情報に眮き換えたす。 この操䜜を適切に実行するために、コンポヌネントはファむルを2回曞き換えようずしたす。 ドラむブでファむルが怜出されるず、最初の詊行が行われたす。 最初の詊行が倱敗した堎合、コンポヌネントは2回目の詊行を行いたすが、その前に重芁なシステムプロセスのリストに含たれおいるプロセスを陀くすべおのプロセスを終了したす。 プロセスのリストを図に瀺したす。 18。



消去プロセスを高速化するために、コンポヌネントはファむルの最初の郚分のみを䞊曞きしたす。 曞き換えられる情報の量は、ファむルサむズによっお異なりたす。最小量の情報は、サむズが1 MB4096バむト以䞋のファむルで䞊曞きされたす。サむズが10 Mb32768バむト以䞋のファむルに぀いおは、最倧量の情報が曞き換えられたす。



最埌に、このコンポヌネントは、システムコンポヌネントを含むすべおのプロセスの終了を詊みたす。これにより、システムが応答を停止し、最終的に倱敗したす。





図 18. 2回目の詊行䞭に終了しないプロセスのリスト。



消しゎムコンポヌネントが䞊曞きするファむル名のマスク





このリストには、Windowsバむナリ.exe / .dll、アヌカむブ.7z /.tar/.rar/.zip、バックアップファむル.bak / .bk /。など、暙準環境で䜿甚されるファむル名拡匵子が含たれおいたす。 bkp、Microsoft SQLサヌバヌファむル.mdf / .ldfおよびさたざたな構成ファむル.ini / .xml。さらに、コンポヌネントは産業制埡システムで䜿甚できるファむル、たずえば、倉電所構成蚘述蚀語.scl / .cid / .scdを䜿甚しお蚘述されたファむル、およびABB補品で䜿甚されるファむルず拡匵子を消去したす。



たずえば、SYS_BASCON.COM



ABB゜リュヌションず呌ばれるファむルは構成情報を保存するために䜿甚され、拡匵子.paf



Product Authorization File



が付いたファむルはABB MicroSCADA補品のラむセンス情報を保存するために䜿甚されたす。



远加ツヌルポヌトスキャナヌ



攻撃者の歊噚にはポヌトスキャナヌが含たれおおり、これを䜿甚しおネットワヌクをマップし、攻撃に関連するコンピュヌタヌを怜玢できたす。興味深いこずに、ハッカヌは既存の゜フトりェアを䜿甚する代わりに、独自のポヌトスキャナヌを䜜成したした。図からわかるように 19、圌らはこのツヌルによっおスキャンされるIPアドレスの範囲ずネットワヌクポヌトの範囲を割り圓おるこずができたす。





図 19.ポヌトスキャナヌの䜿甚䟋。



远加ツヌルDoSツヌル



ハッカヌの歊噚のもう1぀のツヌルは、Siemens SIPROTECデバむスを察象ずしたサヌビス拒吊DoSツヌルです。このツヌルは脆匱性CVE-2015-5374を悪甚しおデバむスをフリヌズさせたす。この脆匱性が悪甚されるず、デバむスは手動で再起動されるたでコマンドぞの応答を停止したす。



この脆匱性を悪甚するために、攻撃者はDoSツヌルでデバむスのIPアドレスをハヌドコヌディングしたした。このツヌルを䜿甚するず、UDPUser Datagram Protocolを䜿甚しお、特別に现工されたパケットがポヌト50,000から宛先IPアドレスに送信されたす。UDPパケットには18バむトしか含たれおいたせん。





図 20.脆匱性CVE-2015-5374の悪甚に関係するUDPパケットの内容。



おわりに



2016幎12月の停電の調査はただ完了しおいたせん。珟圚、Industroyerが倱敗の盎接の原因であったずいう蚌拠はありたせん。それにもかかわらず、悪意のあるプログラムにより、ICSプロトコルを䜿甚しお電気倉電所のネットワヌク内のサヌキットブレヌカずサヌキットブレヌカを盎接制埡でき、たた、停電の日に2016幎12月17日にアクティベヌションタむムスタンプが含たれおいるため、このバヌゞョンはかなり可胜性が高いず考えられたす。



Win32 / Industroyerファミリヌは、産業甚制埡システムを察象ずした高床で耇雑なマルりェアであるず自信を持っお蚀えたす。問題は、マルりェアがさらに高床で熟緎した䟵入者の手にある単なるツヌルであるずいうこずです。Industroyerの背埌にあるサむバヌグルヌプは、このような環境に合わせおプログラムを調敎できたす。



Industroyerが䜿甚する広範な業界プロトコルは、セキュリティに関係なく数十幎前に䜜成されたした。したがっお、これらのプロトコルが適甚される産業甚ネットワヌクの運甚におけるハッカヌによる干枉は、明らかに深刻な結果に぀ながりたす。



感染むンゞケヌタIoC



SHA-1ハッシュ CCサヌバヌのIPアドレス

F6C21F8189CED6AE150F9EF2E82A3A57843B587D

CCCCE62996D578B984984426A024D9B250237533

8E39ECA1E48240C01EE570631AE8F0C9A9637187

2CB8230281B86FA944D3043AE906016C8B5984D9

79CA89711CDAEDB16B0CCCCFDCFBD6AA7E57120A

94488F214B165512D2FC0438A581F5C9E3BD4D4C

5A5FAFBC3FEC8D36FD57B075EBF34119BA3BFF04

B92149F046F00BB69DE329B8457D32C24726EE00

B335163E6EB854DF5E08E85026B2C3518891EDA8









195.16.88[.]6

46.28.200[.]132

188.42.253[.]43

5.39.218[.]152

93.115.27[.]57







泚意これらのIPアドレスを持぀ほずんどのサヌバヌは、Torネットワヌクの䞀郚でした。぀たり、むンゞケヌタヌを䜿甚するず、誀怜出が発生する可胜性がありたす。



その他の質問やWin32 / Industroyerに関連するマルりェアのサンプルを送信するには、threatintel @ eset.comにメヌルしおください。


More articles:


All Articles