# 【検証】IcedIDとは？検知傾向と感染に至るプロセスを徹底 解説 **[nri-secure.co.jp/blog/explaining-the-tendency-of-malware-icedid](https://www.nri-secure.co.jp/blog/explaining-the-tendency-of-malware-icedid)** ----- NRIセキュアのセキュリティ・オペレーション・センター(以下、当社SOC)では、10月下 旬より「IcedID」と呼ばれるマルウェアの感染被害を検知しております。 本記事では、この「IcedID」の傾向と感染に至るまでのプロセスを解説します。 ## IcedIDとは？キャンペーン検知傾向について IcedIDはユーザの金融情報やホスト情報などを窃取したり、他のマルウェアをダウンロー ドする特徴があり、過去にやり取りのあったメール件名を引用し返信を装い、パスワード付 きzipしたdocファイルを添付したメールを通じて感染します(図1、図2)。 ----- 図1 確認した不審メールの例 図2 添付されたパスワード付きzipファイルに含まれるdocファイルを開いた例 ----- 弊社SOCで観測するIcedIDへの感染を誘導する不審メール数は日によって変化があり(図 3)、その変化にあわせて不審メールを実行した例やマルウェア感染に至った例を確認してお ります(図4)。 IcedIDの不審メール実行や感染通信の検知は、他の検体に比べ比較的多い傾向にありま す。これは、IcedIDが多くの日本企業の運用で採用されているパスワード付きzipで拡散する ため、アンチウイルス製品による対策やメールフィルタリングによる拡張子規制がしづら く、またユーザにとってもなじみのあるオペレーションでファイル実行に至ること、実在の メールを使って不審メールが送信されること、docファイルを開くと日本語の案内文が出現 するなどが理由として推測されます。 図3 IcedIDの不審メール検知件数推移 図4 IcedIDの不審メール実行、感染検知件数推移 ----- このような傾向は日本国内全般で確認できる状況であり、JPCERT/CCのTwitterアカウン トから注意が呼びかけられております。 本稿では弊社SOCのIcedID検知状況を踏まえ、不審なdocファイルを開封後からマルウェ ア感染に至るまでのプロセスに注目し検証を行いました。 なお、IcedIDの挙動が時期によって差異があることを確認しているため、IcedIDは複数の バージョンが存在する可能性があります。本検証は、以下の検体を確認したものであり、今 後の動向によっては同種の検体でも挙動が異なる可能性があります。 今回分析したdocファイルのハッシュ値 cd43b5b630c1a81cd463dbf83c4a82f604d971144ca4a118892dcf836c1ccaf7 ## 不審な添付ファイルを実行からマルウェア感染までの概要 図5に、不審メールに添付されたdocファイルを解析して得られたファイル実行からマルウ ェア感染までの概要を示します。 図5 docファイルの実行からマルウェア感染までの挙動 ①パスワード付きzipファイルが添付された不審メールを受信する ②パスワード付きzipファイルを展開しdocファイルを開いた後、wordのコンテンツ有 効化を許可しマクロを実行する。マクロは mshta.exe を in.com としてリネームコピ ーして保存する ③マクロがin.html を生成する ④②で生成したファイルで in.html を実行する ⑤in.html は スクリプトをレジストリに書き出す ⑥in.html は ⑤で生成したレジストリを読み込み、内部関数を使ってスクリプトを実行 する。ホストは外部からHTTP通信で実行ファイルを取得する。取得したファイルは temp.tmp として保存される ⑦in.html は temp.tmp を実行し、IcedIDに感染する ----- ## 不審なdocファイルに含まれるマクロの解析 不審なdocファイルに含まれるマクロ(図5②～④)を解析します。マクロは複数のマクロフ ァイルから構成されており(図6)、ユーザによって一度マクロが有効化されたdocファイル は、AutoOpenマクロにより当該ファイルを開くたびにマクロが実行されるよう工夫されて います。 図6 不審メールに添付されたdocファイルに含まれるマクロ それぞれのマクロファイルは特有の処理を行うといった意味のある構成になっておらず、 複数のマクロファイルの関数を相互に呼び出すことで攻撃者の意図した挙動を取ります。ま た、それぞれのマクロファイルは不要な処理やコメントアウトを多く含み、冗長な作りにす ることで解読を困難にする工夫がされています。 AutoOpenマクロで呼び出される関数は大きく3つの処理から成り立っています(図7)。 図7 AutoOpenマクロにより呼び出される関数 ### docファイルのマクロ 1つ目の処理 ----- AutoOpenマクロで呼び出される 1つ目の関数(図7中関数① 「aN5MS8」) に含まれる機能 を解説します。この関数では、後続の処理でスクリプトを実行させるために、Windows標準 ファイルの mshta.exe を別名でコピーする処理を行います。 まず、図8に示すブロックでは "lmth.ni|moc.ni|exe.athsm" の文字列(赤枠)を反転し分割す ることで、ファイル名として使用するmshta.exe, in.com, in.html の文字をそれぞれを配列に 格納します。 図8 ファイル名生成処理 図9 に示すブロックでは、図9(a)のブロックで定義した値を図9(b)で反転・置換処理の 後、図8のファイル名生成処理で得られた値と結合しファイルパスを生成します。反転、置 換処理の例を以下に示し、図9の当該部分を赤枠で示します。 （例）231met1sys1 →(反転)→ 1sys1tem132 →(置換)→ system32 図9 (a) ファイルパス生成処理(変数定義) ----- 図9 (b) ファイルフルパス生成処理(文字列処理) 図9の処理の結果、以下のファイルパスが生成されます。 1. C:\WINDOWS\system32\mshta.exe 2. C:\Users\【ユーザ名】\AppData\Local\Temp\in.com 3. C:\Users\【ユーザ名】\AppData\Local\Temp\in.html そして、得られたパスである「C:\WINDOWS\system32\mshta.exe」は、図10に示すブロ ックの処理で「C:\Users\【ユーザ名】\AppData\Local\Temp\in.com」としてファイルコピー されます。 実行される処理) FileCopy C:\WINDOWS\system32\mshta.exe C:\Users\【ユーザ名】 \AppData\Local\Temp\in.com ----- 図10 ファイルコピー処理 以上より、AutoOpenマクロで呼び出される 1つ目の関数ではWindows既存のプログラム である mshta.exe を in.com という名前でコピーします。また、C:\Users\【ユーザ名】 \AppData\Local\Temp\in.html のファイルパスは次の関数の処理に利用されます。 ### docファイルのマクロ 2つ目の処理 AutoOpenマクロで呼び出される 2つ目の関数(図8中関数② 「ayG652」) に含まれる機能 を解説します。この関数では、不審なスクリプトを書き出す処理を行います。 2つ目の関数には、ActiveDocument.BuiltInDocumentProperties という処理を含むブロッ クが見られ、ここではActiveDocument.BuiltInDocumentProperties(category) を取得してい ます(図11)。 図11 ActiveDocument.BuiltInDocumentProperties(category) を取得 ActiveDocument.BuiltInDocumentProperties はdocファイルのプロパティを取得する組み 込み関数であり、category を指定することで、「分類」の項目に含まれる値を取得します。 検証した不審なdocファイルのプロパティを確認すると、「分類」の項目には不審なタグの ようなものが設定されていました。(図12 赤枠) ----- 図12 docファイルのプロパティ画面から見える「分類」の値 この「分類」に含まれていた文字列を詳細に確認したところ、docファイルのプロパティ 画面では1行目だけが見えていましたが、実際には難読化された複数行のコードが格納され ていました(図13)。 ----- 図13 docファイルの「分類」の値 この難読化されたコードは一見可読性がないように見えますが、docファイルのプロパテ ィ画面で確認できたはアルファベットを13文字戻して表記しなおすと となる ことから、このコードがROT13(アルファベットを13文字戻す暗号化)で書かれていることが わかります。実際にホスト上では、この難読化されたコードはROT13で復号されたのち、 先ほどの1つ目の関数で得られた「C:\Users\【ユーザ名】\AppData\Local\Temp\in.html」と いう名前で保存されていました(図14) 。 図14 ROT13で復号した docファイルの「分類」の値 つまり、AutoOpenマクロで呼び出される 2つ目の関数ではdocファイルの「分類」に隠れ ている暗号化 されたスクリプトを、ROT13で復号し「C:\Users\【ユーザ名】 \AppData\Local\Temp\in.html」という名前で保存します。 ### docファイルのマクロ 3つ目の処理 AutoOpenマクロで呼び出される 3つ目の関数(図8中関数③) に含まれる機能を解説しま す。この関数の構成はシンプルで、AutoOpenマクロ1つ目の処理で in.com の名前にリネー ムした mstha.exe を in.html を引数に指定して実行します(図15)。この結果、2つ目の処理で 書き出した不審なスクリプトが実行されます。 ----- 実行される処理) CreateObject("wscript.shell").run(C:\Users\【ユーザ名】 \AppData\Local\Temp\in.com C:\Users\【ユーザ名】\AppData\Local\Temp\in.html) 図15 in.html として書き出した不審なスクリプト実行 ## 不審なdocファイル実行により生成されるスクリプトファイル in.htmlの 解析 in.html は、外部のホストからHTTP通信で実行ファイルをダウンロードし実行すること で、ホストをIcedIDに感染させる機能を持ちます。 in.html は、まず一時的にレジストリ (HKEY_CURRENT_USER\\Software\\mysoftware1\\key1)に難読化された文字列を値として 登録し、その値を読み込んだ後、登録したレジストリキーを削除します(図16)。 図16 レジストリの登録、読み込み、削除処理 key1に登録される難読化された値はbase64など複数の処理を施したコードであり、図17 の後続の処理で復号し実行されます。このコードを復号すると外部へのHTTPの通信 （GET）を行う処理が確認できます。ここでも接続先となるURLは難読化されており、この 文字列を反転し、base64デコードをすると平文として取得が可能です。 ----- 図17 レジストリ登録した値を復号(HTTP通信部分) 今回復号して得られる通信先は以下であり、マクロを実行した際に発生するこのホストへ のHTTP通信を図18に示します。このHTTP通信の通信先には表1の特徴があり、観測する時 期によって特徴が変化することを確認しています。 hxxp://fg-clip8673[.]com/share/cgHW3FKPXMSQzsZ（省略）/ahtap15 ※httpをhxxp, .を[.], 部分的に（省略）とすることで無害化しています。 図18 マクロ実行時に発生するHTTP通信 表1 マクロ実行時のHTTP通信の特徴 観測時期 **HTTP** メソッド 特徴 2020/11/20以前 GET URLに、「4桁数字.com/update/」を含む 2020/11/20以降 GET URLに、「4桁数字.com/share/」を含む 図18 で発生したHTTP通信のレスポンスは %temp%temp.tmp として保存され、後続の処 理でrundll32.dll の引数として実行されます(図19)。 ----- 図19 HTTPレスポンスを保存し実行するコード 以上の処理でdocファイルのマクロが実行する in.html は、外部から不審なファイルをダウ ンロードし、レスポンスを %temp%temp.tmp として保存し実行します。 このとき、ダウンロードを試行したホストに不審なファイルが配置されていればホストは IcedIDに感染し、ファイルが存在しない場合はHTTPレスポンス内容がホスト上に保存され ます。今回確認した検体は、本稿執筆時点では接続先から不審なファイルを取得できません でした。 図20 検証したホストに保存されたtemp.tmpの内容(IcedID取得失敗) ## 監視視点のアドバイス 弊社SOC監視環境ではIcedIDの不審メール拡散活動直後に検知があったため、情報収集し ても不審情報が集まらない事例がありました。このような状況の場合、アンチウイルスベン ダの対応も間に合わず、IcedID感染が組織内で発生する可能性があります。 監視環境下において IcedID感染有無を確認できるポイントは以下の通りです。ただしこの チェックポイントで想定する感染有無はホスト上でアンチウイルスやエンドポイント監視な どがなく、特定の挙動を遮断できない場合としています。 ----- チェックポイント **Yes** **No** 1 表1 マクロ実行時のHTTP通信の特徴 をもつログがProxy ログにあり、200レスポンスを応答している 2 ホスト上で、%temp%temp.tmp が存在し、ファイルは 実行形式である 3 レジストリ HKEY_CURRENT_USER\\Software\\mysoftware1 が存 在する 4 Proxyログに .club や .cyou などのホストへ定常的な通信 ログがある 感染の可能性あり 感 染 無 感染 感 染 無 感染 感 染 無 No1 No2の結果次第 で感染の可能性あり 感 染 無 ### ☑ マクロ実行時のHTTP通信の特徴をもつログがProxyログにあり、200レスポン スを応答している 表1 マクロ実行時のHTTP通信の特徴 に記載した通り、マクロ実行時に発生するHTTP通 信には特徴があります。この通信はホストに設定されたProxyを通って発生するため、組織 内のProxyログでこのような特徴を持つ通信の有無とレスポンスコードを確認します。 当該通信が発生し、レスポンスコードが200であった場合、実行ファイルのダウンロード が完了している可能性があります。今回検証したファイルでは、実行ファイルのダウンロー ドが成功した場合、自動的にこの実行ファイルは実行されたため、送信元のホストはIcedID に感染している可能性が高いと言えます。以下は、Proxyログで実行ファイルを取得する通 信を確認した例です。 表2 マクロ実行時に発生した通信が確認できるProxyログの例 ### ☑ ホスト上で、%temp%temp.tmp が存在し、ファイルは実行形式である ----- チェックポイント1 で実行ファイルのダウンロードがあったホストでは、不審なdocファ イルを実行した痕跡の有無を確認します。これまでの解説の通り、不審なdocファイルを実 行したホストでは以下のファイルが生成されます(図21)。これらのファイルがホスト上に存 在する場合、当該ホストでは不審なdocファイルを実行したと言えます。 また、「C:\Users\【ユーザ名】\AppData\Local\Temp\temp.tmp」の実体が実行ファイルで ある場合、チェックポイント1と同様、本ファイルは自動的に実行されるため、送信元のホ ストはIcedIDに感染している可能性が高いと言えます。なお、C:\Users\【ユーザ名】 \AppData\Local\Temp\in.com のタイムスタンプは、コピー元の mshta.exe の時間となるた め、docファイルを実行した付近の時間より古い時間が表示される場合があります。 ・ C:\Users\【ユーザ名】\AppData\Local\Temp\in.com ・ C:\Users\【ユーザ名】\AppData\Local\Temp\in.html ・ C:\Users\【ユーザ名】\AppData\Local\Temp\temp.tmp 図21 不審なdocファイル実行時に作成されるファイル ### ☑ レジストリ HKEY_CURRENT_USER\\Software\\mysoftware1 が存在する ----- 不審なdocファイルを実行した際に生成されるスクリプトである C:\Users\【ユーザ名】 \AppData\Local\Temp\in.html ファイルでは、不審なコードを書き出すレジストリ登録、およ び削除を一連の処理として行います。 そのため、in.html ファイルが実行されたホスト上では登録されたレジストリ値をあとか ら確認することはできません。しかし、一連の処理で削除されるのは レジストリキーと値 であるため、パスである「HKEY_CURRENT_USER\\Software\\mysoftware1」 はホスト上 で確認できる可能性があります(図22)。このようなレジストリパスが存在する場合、このホ ストでは不審なdocファイルを実行した可能性があるため、チェックポイント1、2の状況を 加味してホストの感染状況を判断します。 図22 不審なレジストリパスが存在する事例(レジストリキーは削除されている) ### ☑ Proxyログに .club や .cyou などのホストへ定常的な通信ログがある 本記事では詳細な解析を掲載しておりませんが、IcedIDに感染したホストは、 revopilte3[.]club、aweragiprooslk[.]cyou などのホストに約5分に1回のビーコン通信を発生す る事例を確認しております。送信先のドメインは変化する可能性があるため、「.club」、 「.cyou」のTLDに対して定常的に通信を行っているホストを確認します。当てはまる挙動 ----- を持つホストがあった場合、接続しているドメインはIcedIDに関連する情報が公開されてい ないか、またはホストではチェックポイント1~3に当てはまる特徴があるかの検証内容を加 味してホストの感染状況を判断します。 なお、確認の結果、この通信が不審なdocファイルを実行したことによると結論付けられ る場合、ホストはマルウェアに感染している可能性が高いため、ビーコン通信の遮断有無に かかわらず対策が必要です。 ### セキュリティデバイスでの検知 最後に、不審なdocファイルを実行しIcedID に感染するまでの挙動のいくつかは一般的な セキュリティデバイスで検知可能です。 表3 IcedID に感染するまでの挙動と検知可能なデバイス 挙動 検知デバイス例 ① パスワード付きzipファイルが添付された不審メールを受信する パスワード付き zipファイルを解 析可能なサンドボ ックス ② パスワード付きzipファイルを展開しdocファイルを開いた後、 wordのコンテンツ有効化を許可しマクロを実行する。マクロは mshta.exe を in.com としてリネームコピーして保存する ③ マクロがin.html を生成する ④ ②で生成したファイルで in.html を実行する ⑤ in.html は スクリプトをレジストリに書き出す ⑥ in.html は ⑤で生成したレジストリを読み込み、内部関数を使っ てスクリプトを実行する。ホストは外部からHTTP通信で実行フ ァイルを取得する。取得したファイルはtemp.tmp として保存さ れる ⑦ in.html は temp.tmp を実行し、IcedIDに感染する ※Endpoint Detection and Response EDR（※） 図23 IDS、Proxy ----- 図23 エンドポイントで不審なファイル作成を検知した例(CrowdStrike) ## まとめ 本稿では、弊社SOCで確認したIcedIDの傾向と感染に至るまでのプロセスを解説しまし た。IcedIDは、弊社SOC監視環境下でも感染の被害を確認している検体です。 現在確認しているIcedIDのキャンペーンは、日本で利用されやすいパスワード付きzipを使 って拡散します。そのため、メールゲートウェイによる拡張子規制による対策が難しく、メ ール受信者においては身に覚えのない添付ファイルを実行しないことが改めて重要になりま す。万が一docファイルを開いてしまっても、警告に出てくる「コンテンツ有効化」をしな いことが重要です。 弊社SOCではこれらの特徴をSIEM(Security Information and Event Management)の相関監 視ルールとして実装することでFirewallログやProxyログから実行ファイル取得通信や、感染 [通信を検知することが可能です。また、弊社が提供しているマネージドEDRサービスでは、](https://www.nri-secure.co.jp/service/mss/edr) エンドポイントでの不正なファイル作成の実行を検知・遮断可能です。これまでのネットワ ーク監視の視点に加え、エンドポイントでの対策を実施することでより効果的なマルウェア [対策が実現できます。セキュリティログ監視サービスやマネージドEDRサービスにご興味が](https://www.nri-secure.co.jp/service/mss/log_monitoring) ありましたら、お気軽にお問い合わせいただければ幸いです。 - 連サービス [セキュリティログ監視サービス（NeoSOC）](https://www.nri-secure.co.jp/service/mss/log_monitoring) [マネージドEDRサービス](https://www.nri-secure.co.jp/service/mss/edr) ----- NeoSOC NeoSOC（セキュリティオペレーションセンター）は、NRIセキュアが提供するセキュリテ ィ監視サービスのブランド名称であり、日米にある監視センターを中心に24時間体制でセキ ュリティインシデントの分析を行っています。ここではNeoSOCを運営するセキュリティア ナリストが、最新の脅威動向や実際に分析したセキュリティインシデントについて定期的に 情報発信いたします。 -----