IcedIDのWordマクロを解読してみる 後編

前回はDOCファイルのマクロを解読しました。今回はマクロによって生成されるHTMLファイル「in.html」を解読してみます。検体は引き続きこちら

先週から複数のなりすましメール送信の被害報告を受けています。メールの特徴は #emotet と似ていますが、別のマルウェア(#IcedID)へ感染させるメールです。
なりすましメールの送信元はマルウェア起因でなくメールアカウントへの不正ログインが疑われますので、パスワードを再設定ください。 ^KS pic.twitter.com/Fob1PCbut1

— Analysis Center (@jpcert_ac) November 6, 2020

「in.html」は86行で構成されています。その一部はこのような感じです。

インデントが一切なく読みづらいので、VSCodeの自動整形機能を使って可読性を上げてみます。難読化が施されていないので内容自体は非常にわかりやすいのですが、不要なコードが至るところに紛れています。下の画像でブレークポイントで印を付けた行は不要なコードです。

「in.html」には3つのscriptタグで構成されています。上から順番に読んでいきます。まず1つ目のscriptタグの始めに「decode」という関数が定義されていますが、こちらは後ほど。

30行目：謎のレジストリキーを変数「aWa3z」に。
31・32行目：mshtaのウィンドウを最小化して、見えない場所に移動させています。気づかれないための小細工でしょうか。
33行目：WshShellオブジェクト「a3BzD」を作成。
34行目：謎の長い文字列を変数「aqNdX」に格納。
この後、生成したWshShellオブジェクトを使用して、レジストリの書き込みが行われます。レジストリキー「HKEY_CURRENT_USER\\Software\\mysoftware1\\key1」に34行目の長い文字列を書き込みます。

続いて、2つ目のscriptタグです、

先程書き込みを行ったレジストリを読み出し、「afeN9」に格納された後、すぐに削除されます。なお、ここでは「key1」のエントリが削除されるため、「HKEY_CURRENT_USER\\Software\\mysoftware1」のレジストリキーは残ったままとなります。レジストリエディターで確認すると、レジストリキーだけ残っていることが確認できます。

最後となる、3つ目のscriptタグです。

こちらではまずレジストリから読みだした文字列「afeN9」を、最初に登場した「decode」関数に通します。ここまでの処理を見ると、わざわざレジストリを経由させていますが、レジストリに痕跡を残すことになるうえ、レジストリ操作が振る舞い検査で検出されるリスクとなるため、そのようにするメリットがあるのかは疑問です。

「decode」関数は、BASE64というエンコード方式のデコードを行う関数です。文字列の最後が「=」になっていたので、BASE64というのが推測しやすいかと思います。

「aqNdX」をBASE64でデコードした結果の一部がこちらです。

不要な単語が混ざっていているようです。というわけで43行目のとおり、「ntsa」を置換して削除してみます。

すると、新たにJavaScriptのコードが出てきました。44行目ではこのコードを使用して、関数「aVaEb」を宣言しています。関数「aVaEb」は、第一引数を「u」として、第二引数を「c」として受け取り、「afeN9」のJavascriptコードが関数内で実行されます。45行目では関数が実行され、46行目でmshtaのウィンドウがクローズされます。

それでは、ここからどのような処理が行われるのか、「afeN9」のJavaScriptのコードを見てみましょう。

本来は1行ですが、セミコロンで改行し、自動整形するとこのような感じに。96行あるのですが、「in.html」と同様に不要なコードが多数挿入されています。不要なコードをすべて削除すると、元の半分以下の42行になりました。

こちらも流れを追っていきます。

Web通信に使用されるXMLHTTPオブジェクト、テキストの読み書きに使用されるストリームオブジェクト、WshShellオブジェクトが作成され、TEMPフォルダに「temp.tmp」が結合されたファイルパスが登場しました。

ここでは、第一引数で受けた文字列に対して処理が行われます。関数「aZtEN」では分割→反転→結合という順番でメソッドが噛まされていますが、分割と結合は意味が無いため、実質文字を反転させる関数になります。関数「decode」については、先程と同様にBASE64をデコードするだけです。

というわけで、同様の処理を引数の文字列「u」に施してみると…

通信先URLが出てきました！！！

あとはその通信先URLに対してGETリクエストが送信され、レスポンスが正常に返ってきたら、「temp.tmp」として保存され、Regsvr32で実行されるという流れになります。

Wordマクロに含まれている部分の解読は以上になります。

Twitter上で既出ではありますが、インデントレスポンスの際には、
・TEMPフォルダの「in.com」の有無
　(C:\Users\User\AppData\Local\Temp\in.com)
・TEMPフォルダの「in.html」の有無
　(C:\Users\User\AppData\Local\Temp\in.html)
・レジストリキー「HKEY_CURRENT_USER\\Software\\mysoftware1」の有無
・検体に含まれる通信先URLへの通信有無
・TEMPフォルダの「temp.tmp」の有無
　(C:\Users\User\AppData\Local\Temp\temp.tmp)
を確認するのが良さそうです。

また、検体から通信先URLを抽出する手順としては、
　①ネットワークを切断した仮想環境上でWordマクロを実行
　②「in.html」に含まれる反転したBASE64文字列を抽出
　③反転→BASE64デコード
　④仮想環境切り戻し
という方法がスムーズかと思います。