1. Analyzing Android Malware
静的解析から見る傾向と識別方法
Android Malware Research Project
Ayase(@data_head)

2. 自己紹介
Ayase
ソフトウェア開発・SIをメインとする企業に勤めています
主な業務
• インフラ設計・構築(PKI・認証システム)
• ISMS(当時はBS7799)コンサル
• 移動機系サービス(設計・技術検証)
• そのほかトラブルシュート要員(´д｀
Blog: とある技術屋の日記 (http://sememorandum.blog.fc2.com/)
Ayaseのセキュリティメモ (http://securememo.blogspot.com/)
Twitter: @data_head
Mail: datahead0@gmail.com
Malware解析の仕事は?
→業務経験ありません。素人です(Android Malware解析暦2年)
周りに有識者いたとか…
→いえ、金床さんのBlogとGoogleのDalvik関連資料が私の先生です
(ありがたいことに最近プロの方からご助言・ご協力頂いております)

3. なぜ素人がここに立って話しているのか？
趣味から講じた Android Malware 解析ですがBlogによる情報
公開に飽き足らず、昨年よりAndroid Malwareの情報を収
集・公開するためのサイトを運営し始めました。
Android Malware Research Project (AMR-Project)
https://sites.google.com/site/amrprjt/
このサイトでは収集した検体の解析結果を公開し一般向けの
注意喚起やセキュリティ関連組織への検体提供をしています。
今回、主催(中津留様)にこちらのサイトに興味を持って頂き、
発表の場を頂きました。

4. さて、今回のお話は…
今回 Android をターゲットとしたMalwareのお話を
させて頂きます。
AndroidMalwareの歴史と傾向
AndroidMalwareの識別方法

5. Android Malwareの歴史と傾向

6. Android Malwareの歴史
AndroidのMalware史上(個人的に)記憶に残っているイベン
トをピックアップしてみると…
8/10 3/2 1/11 2/28 2/4
Claco
FakePlayer Droid Dreams Oneclickfraud Loicdos
Windows端末で盗聴する
Android初のMalware Root権限を奪取 日本初ワンクリ詐 DoSTool
マルチプラットフォーム
(プレミアムSMS送信) するTrojanの出現 欺アプリの出現 の出現
スパイウェアの出現
2010 2011 2012 2013
1/1 7/7 1/27 4/4
CounterClank DougaLeak
Geinimi MobileSpy
過度な機能を持つ 日本をターゲット
多機能Trojan 商用スパイ
広告モジュールの にしたアドレス情
の出現 ウェアの出現
出現 報収集Trojanの出現
※上記日付は Symantec Security Response の情報に基づく
Point
 初期のMalwareから実用的な機能を持っている
 金銭・情報搾取目的が多くみられる
 2011年に出現したRootExploitを利用するMalwareは2012年以降下火。
代わりに人気アプリのRepackageや模倣で騙すケースが現在は主流

7. Android Malwareの機能
Android Malwareが持つメジャーな機能を
ピックアップしてみました。
 端末内情報搾取
 メッセージ(SMS/MMS)不正操作
 端末内設定改ざん
 Remote control
 攻撃Tool

8. 端末内情報搾取
 端末固有情報
 GPS
 アドレス(PIM)情報
 SDカード内ファイル
 アプリケーションInstall/Uninstall情報
 Log

9. メッセージ(SMS/MMS)不正操作
 プレミアムSMS送信
 端末内情報送信
 告発メッセージ送信
 リモートコマンド受信
 メッセージ受信拒否・削除

10. 端末内設定改ざん
 端末設定(ネットワーク設定、BookMark…)
 アプリケーションInstall(Dropper)
 SDカード内ファイル改ざん・削除
 ショートカットアイコン自動設定

11. Remote Control
前述の機能を以下のI/Fを介してリモートで
実行する
 Webサイト(専用のCGI, Blog)
 SMS, WAPPush

12. 攻撃Tool
 DoSTool
 Wi-Fiルータを介したノードへの攻撃ツール

13. 最近の傾向
 プレミアムSMS
 情報搾取(Banker, アドレス(PIM)情報搾取)
 BoT
 SpyWare
 Adware

14. 今後の予想
 アドレス情報やBank情報の搾取は継続増加
 BoT ネットは増加するならこれから
 海外の外部モジュールは今後も注意
 Malcodeの隠ぺいは今後も巧妙化する
 マルチプラットフォームへの展開(悪い意味で)

15. Android Malware の識別方法

16. さて本論に入りますが…
AndroidのMalwareを識別をするにあたり、
私はそのほとんどを静的解析で行っているわけです。
まぁ、静的解析自体は…
『割と簡単です』
ただ、Windowsの実行ファイルを解析する時同様、smaliからAPIを辿って
1つ1つ追いかけるのは 超めんどうくさい。
もう少し楽な方法はないものか…

17. 今回のアプローチ
アイデア
前回の#Malwatで @cci_forensics さんが発表していた
IOC(Indicator of Compromise)の概念を利用できないか
ということで
 Apk内の各ファイル毎にMalwareの特徴を見てみる
 超めんどうくさいclasses.dexの解析によるMalware
識別を「APIの利用頻度解析」と「ssdeepによる類
似性評価」の2つの方法から簡略化できるか試し
てみる

18. Android アプリケーションの構造
左記の構造からファイルを抽出し、 /application.apk
以下の順番で解析します。
<> AndroidManifest.xml
01 resources.arsc
1. AndroidManifest.xml 01 classes.dex
2. META-INF/CERT.RSA 初動解析 /META-INF
•メタ情報の取得
•既存検体との比較
3. resources.arsc 01 CERT.RSA
01 CERT.SF
4. classes.dex
MANIFEST.MF
res/ 配下のファイル
01
5. 詳細解析 /assets
6. asset/ 配下のファイル •ロジック解析
•ファミリ特定
(img.png)
/res
7. lib/libABI.so
/drawable
icon.png
今回は、実際に解析するこれらのファ /layout
イルを見てみようと思います。 <> main.xml
/lib
<> libABI.so

19. AndroidManifest.xml
(Tool) AXMLPrinter を使って可読化
 Permission (何ができる？)
→ READ_CONTACT, RECEIVE_SMS…
 Receiver (何をトリガに動く？)
→ ACTION_REBOOT, SMS_RECEIVED…
 Activity (外部モジュールに何がある？)
→ Apperhand, Airpush, Leadbolt…

20. AndroidManifest.xml - Permission
LifemonSpy
Malwareが持つ機能によって要求する
Permissionは様々
<uses-permission
android:name="android.permission.READ_SMS"
>
</uses-permission>
<uses-permission
android:name="android.permission.READ_CONTACTS"
>
</uses-permission>

21. AndroidManifest.xml - Receiver
指定されたイベントが発生するとアプリが
起動する。左記のようにあらゆるイベント
をキャッチする場合、プロセスを殺しても
すぐに上がってくる。
<action
android:name="android.intent.action.BOOT_COMPLETED“
>
</action>
<action
android:name="android.intent.action.CAMERA_BUTTON“
>
</action>
<action
android:name="android.intent.action.CONFIGURATION_CHAN
GED“
>
</action>
<action
android:name="android.intent.action.DATA_SMS_RECEIVED“
>
</action>
FakeLookout

22. AndroidManifest.xml - Activity
画面を持っていたり、サービスが
立ち上がる外部モジュールはAndroid
Manifestに設定が必要になる。
また、ここに設定されたパッケージ名
はProguardの対象外となるため、
smaliでも追跡しやすい。
<service
android:name="com.apperhand.device.android.A
ndroidSDKProvider“
android:enabled="true“
>
Counterclank </service>
<activity
android:theme="@android:0103000F“
android:name="com.apperhand.device.android.E
ULAActivity“
>
</activity>

23. META-INF/CERT.RSA
(Tool) Binary Editor or OpenSSL
 Signature
→過去のMalwareと比較して同じならバリアントか、
同一開発者による別のファミリである可能性が
高い
 DN(Issuer/Subject)
→野良アプリはDebug証明書を用いているケースが
多い。開発者の自己署名の場合も意味のない文
字列のケースが多いため特徴をつかむのは難し
い

24. resources.arsc
(Tool) Binary Editor
 アプリ名
→インストール時に端末で表示されるアプリケー
ション名を確認できる。
(Android Malware ではInstall時のアプリ名がWebサイト上
で表記されるアプリ名と異なるケースが多い)
 URL
→C&CサーバのURLが入っていることがある。
同一ファミリの場合同じC&Cサーバを用いてい
るケースが多いことからファミリの識別や
Malwareのシステム構成をつかむ証拠になる

25. resouces.arsc
Enesoluty
実際にアプリをインストールしなくてもresourcesファイルでインス
トール時のアプリ名を確認できる。
ただし、 resourcesファイル内のマルチバイトはUTF-8だったり、
Unicodeだったりアプリによって異なるので、普段Stirlingを使ってい
る私はUTF-8のためにBZも入れている(面倒)

26. classes.dex
(Tool) baksmali
 静的解析の大本命
 Smali を直接読む → 超めんどうくさい
なので…
1. SmaliからAPI(invoke-virtual) を抽出してAPI毎の
利用頻度を比較し類似性を評価する
2. Ssdeepでsmaliを比較し類似性を評価する
という2つの方法から既知のMalwareとの類似性を
評価して識別できるか試してみました。

27. classes.dex – APIの利用頻度解析
1. SmaliからAPI Call(invoke-virtual)の行のみ抽出
2. その中からGoogle 標準APIのみさらに抽出
3. API毎にカウントを取ってAPIの利用頻度を算出
4. 同様の方法で複数の検体からAPIの利用頻度を抽出
5. 検体同士APIの利用頻度からコサイン類似度を算出
6. 算出結果が0～1で1に近いほど類似している(はず…)

28. classes.dex – APIの利用頻度解析(結果)
A121212003 A121114001 A121212001 A120412001 A120708001 A121020001
A121212003
(Enesoluty.A(12/12)) 100.00% 40.96% 22.13% 22.31% 2.66%
A121114001
(Enesoluty.A(11/14)) 100.00% 40.96% 22.13% 22.31% 2.66%
A121212001
(Enesoluty.B(12/12)) 40.96% 40.96% 誤検知 74.22% 72.79% 6.60%
A120412001
(DougaLeak) 22.13% 22.13% 74.22% 66.66% 5.88%
A120708001
(CounterClank) 22.31% 22.31% 72.79% 66.66% 5.23%
A121020001
(FakeLookout) 2.66% 2.66% 6.60% 5.88% 5.23%
→ あまりいけてない…

29. classes.dex – ssdeep
classes.dex(バリアント)のままだとうまく
評価できないようなのでsmaliに対して
ハッシュ算出してみたのですが…
Ssdeepに至っては、C&CサーバのURLが違うだけのバリア
ントで64Point(完全一致で100)。
Stringの数が増減するだけでString_idsのIndex値がずれて
しまうために以降のデータが全部変わってしまってるのか
も…
このままではダメっぽい…
そうだ！西田さんに聞いてみよう！(ごめんなさい

30. res/・asset/
 画像ファイルやrawデータファイル等はバ
リアントで使いまわしてるケースもあるた
め、特徴情報として使えるケースもある。
 また、PNGファイル内に別のファイルを埋
め込んでるケースもあり、画像ファイルの
中をチェックすることも必要

31. PNGファイル内のdex埋め込み例
Android.GameXの例
asset/logo.pngをバイナリエディタで見てみると…
apkが埋め
込まれている

32. lib/libABI.so
偶然にも今までネイティブライブラリをcoreに
したMalwareが表に出てくることはなかったの
ですが、
このアプリのおかげでネイティブライブラリも
今後の解析対象に入ることとなりました。
冒頭に述べたとおり、私はネイティブコードの
解析についてはさっぱりなので、今後の課題に
なります。

33. まとめ
 Androidの歴史と傾向
 Android Malware の識別を効率化するための基
礎研究
 Apk内の各ファイル毎の識別ポイントまとめ
 Classes.dexの類似性評価の試み(そして失敗)
見解
今回挙げたMalwareの識別ポイントから複合的
に判断してMalwareの識別が可能。
類似性評価は方法を見直し、より多くのサンプ
ルで検証が必要。

34. 今後の展開と希望
 Malwareの特徴を抽出したメタ情報をDB化して比
較できるようにしたい
 類似性評価は今回全くいけてなかったので、より
多くのサンプルで検証しながら精度を上げていき
たい
 オープンな形で運営されたメタ情報DBが欲しい
 Android Malwareの分類統一を望みたい(これは難
しいかも…)
→一緒に考えて頂ける方いらっしゃいましたらお
声掛けて頂けると嬉しいです