2021年3月26日

NECサイバーセキュリティ戦略本部セキュリティ技術センターの岩田です。
今回のブログのテーマを考えていたところ、タイミング良く（？）会社スマートフォン宛に宅配便の不在通知を装う偽ショートメッセージが届きました。Blog記事にしてから約半年経過していますが未だに活動が止まっていないようです。せっかくなのでどのように変化しているか確認してみたいと思います。

Webサイト

SMSで通知されたURLへPCからアクセスしても応答がなく、ブラウザのUser AgentをAndroidに変更するとPOPUPが表示されました。OKボタンをクリックするとAPKファイルがダウンロードされました。

Webページのソースを確認すると、難読化されたコードを復号し実行していました。

難読化を解除すると先ほどPOPUPに表示されていた、Chromeのバージョンアップメッセージを表示しAPKファイルをダウンロードさせるコードがでてきました。

Webページをリロードしたところ、異なるファイルネームのAPKファイルがダウンロードされました。リロードを繰り返す毎に規則性の無い異なるファイルネームのAPKファイルがダウンロードされました。htmlコードおよびファイルネームをランダムにすることで検知を難しくしているのだと考えられます。

APKファイルの調査

Webページのリロードを繰り返しても同じファイルネームでダウンロードされることはありませんでした。無数のバリエーションがあるのでしょうか。確認するためダウンロードしたファイルのHASH値を確認したところ、HASH値が何種類かあることが分かりました。さらに時系列順でファイルを確認したところ約2分毎にHASH値が異なるAPKファイルがダウンロードされることがわかりました。

HASH値の異なるAPKファイルを時系列で３つ（yyninmiizz.apk、omipinkpti.apk、riwznqqdyp.apk）ピックアップし、APKファイルに含まれているファイルを確認したところ以下の差異がありました。

1、2、3よりプログラムの機能に差がある可能性があるため、この後確認してみたいと思います。4よりダウンロードされるAPKファイルは事前に準備されていたのではなく、リアルタイムに作成されていると考えられます。このことは各APKに含まれているファイルの更新日時が約2分毎と、ダウンロードしたAPKファイルのHASH値変化のタイミングと同じことからも確認ができます。

APKファイルの比較

HASH値が異なるAPKファイルにどのような機能差があるのか確認するため、先ほどと同じHASH値の異なるAPKファイルを時系列で3つ（yyninmiizz.apk、omipinkpti.apk、riwznqqdyp.apk）ピックアップし、jadx (https://github.com/skylot/jadx) でデコンパイルしました。デコンパイル結果を確認したところ、クラス名が異なっていました。プログラムをざっと見たところ3つのファイルでクラス名以外に大きな差異は確認できませんでした（復号するassetsのファイルパスは異なっていた）。

前回の記事で確認したAPKファイルと比較すると、Kotlin(https://developer.android.com/kotlin) が導入された点とネイティブコードが追加された点が大きく異なりました。

各APKファイルのネイティブコードを比較してみましたが同一のファイルでした。ネイティブコードのHASH値は変化しないようです。

ネイティブコードの機能を確認したところ複雑な処理は実装されておらず、一部Javaの関数呼び出しを置き換えているだけのようです。このため解析妨害の１つとして導入されたのだと考えられます。

ネイティブコードをデコンパイルした結果の一例

バイナリの復号

直接確認ができるコードはローダー部分で、メイン機能はassetsに暗号化されたバイナリファイルに実装されていることが分かっています。各APKファイルよりassetsに含まれているバイナリファイルを取り出し比較してみます。比較結果は、各バイナリファイルのサイズは同一ですがHASH値は異なりました。暗号化されたバイナリファイルの機能に差があるのかも知れません。

暗号化されたバイナリファイルを復号するため復号処理を確認します。復号処理はネイティブコードには含まれておらず従来通りJavaのコードで書かれていました。ただし、ファイルのフォーマットは以下のように変更されていました。

フォーマットが分かったので復号します。以下のコードはPythonで実装した復号処理例となります。

復号したバイナリは3ファイルとも同一でした。暗号化されたバイナリファイルを詳しく確認したところXOR Key、ファイルサイズ、暗号化データが同一でした。差があるのは暗号化されたバイナリデータの先頭4バイトだけでした。暗号化されたバイナリファイルのダミー領域にランダム値を書き込むことでHASH値を変化させ、検知されることを防いでいるのだと考えられます。

サイト調査

復号したバイナリ（メイン機能）は前回Blogで確認した機能と大きな差異が無さそうなため本記事では割愛し、今回はAPKファイルを配布していたサイトについて調べてみます。

HTTPS証明書

ブラウザからhttp (80/tcp) だけではなくhttps (443/tcp) でアクセスすることができました。https通信で利用されていたSSLサーバー証明書は自己署名証明書（通称オレオレ証明書）でした。SSLサーバー証明書に含まれているドメイン名を調査したところ、有名な既存ドメインを含む300以上のドメイン名が含まれていました。今回のAPKファイル配布と別目的で（ただし正当な理由では無い）使われていたと考えられます。また、SSLサーバー証明書に含まれていたドメイン90以上のTLDは.krのため、特定地域を狙う目的で作成されたと考えられます（なおJPドメインは0件でした）。

ポート8100

ブラウザからポート8100にアクセスすると以下のようなページが表示されました。

SHODAN等を利用しIPアドレスについて調査すると以下のことが分かりました。

悪意のある目的で利用しているためテイクダウンされる可能性があります。そのため、APKを配布するサイトが稼働しているか、APKを配布するサイトのドメイン名が有効であるかなどを確認していると思われます（韓国に強いこだわりがあるようです）。

その他

IPアドレスから今回のAPK配布サーバーの所在地は台湾のようです。日本と台湾の時差は1時間のためAPKファイル内のファイル更新日時とダウンロード日時との時間差と一致します。そのため、APKファイルを配布していたサイトでAPKのBuildを実施していた可能性がありそうです。また、APKを配布していたサーバーをSHODAN等で確認するとport 445/tcp(SMB)やport3389/tcp(RDP) がインターネットに公開状態でした。そのため、第三者に侵害され悪意のあるプログラムの配布に利用された可能性もありそうです。もしサーバーが侵害されたのだとしたら残留物を分析すると興味深い結果が得られそうです。

まとめ

不在通知SMSの活動が継続している原因を調査してみました。その結果、APKを配布するサイトの構造の変化や、ダウンロードされるAPKファイルの構造が変化していることを確認しました。また、HASH値による検知を逃れるためAPKファイルを約2分毎にBuildを繰り返していることが分かりました。悪意のあるプログラムを配布する側は解析妨害の追加実装やHASH値・ファイルネームを変化させるなど、注意喚起や検知難しくするための活動を継続していることが確認できました。

執筆者の他の記事を読む