結果と考察

4. 結果と考察

4.1 概要

DARPA APAC プロジェクトのフェーズ I の終わりまでに、我々のチームは Red チームが開発した 77 の Android アプリケーションを監査し、そのうち 62 には新規のマルウェアが含まれていた。エンゲージメント 1C からはコントロールチームが置かれ、現在の最先端のツールを用いて Blue チームの参加者と並行してアプリを監査した。我々のプロセスは、悪意のあるアプリのうち 57（91.94%）で悪意を正しく特定し、66（85.71%）のアプリを悪意があるか無害かに正しく分類した。我々は意図されていない悪意のある振る舞いを 6 件発見し、マルウェアを見逃したのは 5（6.49%）のアプリだけであり、一貫してコントロールチームを上回った。我々は、最も成績のよい Blue チームとしてフェーズ I を終えた。

フェーズ I の終わり（エンゲージメント 2B 以降）に、チャレンジアプリケーションに含まれるマルウェアの性質が、フェーズ I で主に見られたものから変わり始めた。マルウェアははるかに難しくなり、コントロールチームを含むすべてのチームの成績が下がった。フェーズ II を通じて、我々のチームは Red チームが開発した 28 のチャレンジアプリケーションを監査し、そのうち 25 には新規のマルウェアが含まれていた。我々のプロセスは、悪意のあるアプリのうち 18（72%）で悪意を正しく特定し、25（89.29%）のアプリを悪意があるか無害かに正しく分類した。我々は意図されていない悪意のある振る舞いを 35 件発見し、7（25%）のアプリでマルウェアを見逃した。コントロールチームは上回ったが、その差はフェーズ I ほど大きくなかった。

PI ミーティングで提供されたメトリクスによれば、我々はフェーズ II でも上位 3 チームの位置を保ち、首位のチームに大きく遅れてはいなかったと判断した。

4.2 分析者の経歴

エンゲージメントを通じて参加した分析者には、大学院生、ISU 研究グループのスタッフ 1 名（このスタッフはコンピュータ工学の修士号を持つ）、学部生の研究助手、ENSOFT のソフトウェアエンジニアが含まれていた。エンゲージメント 1A では分析者は 6 名であったが、それ以降のすべてのエンゲージメントでは、エンゲージメントごとにチャレンジアプリケーションの監査に取り組んだ分析者は 2〜4 名だけであった。

4.3 分析のプロセス

実際の分析の前に、1 名が 1〜2 時間をかけてアプリケーションのサイズを調べ、すべてのアプリを監査できるように Eclipse プロジェクトとして準備した。アプリの前処理の後、各アプリに 2 名の分析者が割り当てられた。各分析者は独立して作業し、ほかの分析者の作業にはアクセスできなかった。プロセスを監督するがアプリの監査は行わないコーディネーターが、各分析者による分析の結果をレビューした。元の 2 名の分析者の結果が矛盾している、または結論が出ていないと判断された場合、コーディネーターは追加の分析者をそのアプリの監査に割り当てた。すべての分析者は、ほかの分析者による分析の結果にアクセスすることなく、独立して作業した。実験の最後に、アプリケーションごとに 1 つの報告書が選ばれ、最終報告書の集合として提出された。

分析者がマルウェアとトリガーを発見して報告した後、悪意のある振る舞いを検証するためにエミュレータを用いた。エミュレーションはマルウェアの検出には用いず、厳密に、我々の分析が予測した悪意のある振る舞いを観察するためだけに行った。悪意のある振る舞いを観察できなかった場合もあったが、我々の分析に基づいて悪意のあるペイロードの存在を確信していたため、それでもそのアプリケーションをマルウェアとして報告した。

4.4 エンゲージメントの結果

エンゲージメントの結果を解釈することは、多くの理由から難しい。各エンゲージメントの実験の設定は、エンゲージメントが進むにつれて変化した。コントロールチームはエンゲージメント 1C まで加わらず、マルウェアの難しさはエンゲージメント 2A から劇的に増した。フェーズ I の初期には、一部の悪意のあるアプリケーションに複数のマルウェアが含まれていたが、後のエンゲージメントでは、マルウェアを 1 つの悪意のある振る舞いに限定することで、悪意のある表面積を減らした。エンゲージメント 1B では、我々はすべてのマルウェアを見つけることを課された。エンゲージメント 2B からは、正しい証拠を示すと悪意を確認する人間のオラクルにアクセスできるようになった。オラクルの主な考え方はフェーズ II の終わりまで維持されたが、オラクルの公式な回答方針はエンゲージメントごとに変わった。オラクルは、チームが意図されていない悪意で「短絡」するのを防ぐことを目的としていた。エンゲージメント 1C、2B、3B はオンサイトで行われ、分析者の人数（それぞれ 4、3、3 名）と時間（それぞれ 8、4、5 時間）に制限があった。エンゲージメント 3B と 4A の一部のアプリケーションは、以前のエンゲージメントの既存のアプリケーションの「アップデート」であり、監査の際に以前の知識を活用できるようになっていた。エンゲージメント 1B からは、アプリケーションのサポートライブラリが、依存する JAR ライブラリとしてではなくソースに「同梱」されて提供され、監査の対象範囲とみなされた。エンゲージメント 4A では、アプリケーションの分類が不明であった以前のエンゲージメントとは異なり、すべてのアプリが悪意のあるものであるとわかっていた。

8 つのチャレンジアプリケーションを含む予行演習のエンゲージメントを除いて、我々のチームは 105 のアプリケーションの監査を完了した。105 のアプリケーションのうち 87 が公式にマルウェアと分類され、それらには公式に悪意があるとされた個々の振る舞いが 100 件含まれていた。

4.5 エンゲージメントに関する所見

エンゲージメント 1A では、Red チームは、コード行数（LOC）が 500 未満の新しい小さなアプリケーションを作成し、2K LOC から 60K LOC までの既存のオープンソースアプリケーションを利用した。悪意は、自動化の手法を破ることに焦点を当てていた。小さなアプリケーションは、手作業で読んでマルウェアを発見できるほど小さいというのが、大方の一致した見方であった。

エンゲージメント 1C 以降、すべてのアプリケーションは最低 1000 LOC であった。我々の予想どおり、分析時間と意図されたマルウェアの正しい検出に関する我々の成績は、アプリケーションのサイズと相関しなかった（図 5 と図 6 を参照）。これは、マルウェアを見つける難しさがコードのサイズとはあまり関係がなく、マルウェア自体の特性と大きく関係しているという我々の考えを裏付けている。たとえば、インターネットに接続し、アプリケーションの起動時にダウンロードしたコードをクラスローダーで実行するマルウェアは、主にオフラインで動作するアプリケーションの中では、アプリケーションのサイズにかかわらずひどく目立つ。マルウェアが正当な機能に溶け込み、既存の制御フローとデータフローを悪意のある目的に使う場合、数百行のコードのアプリケーションであっても、検出の作業ははるかに難しくなる。フェーズ II のエンゲージメントは、事前にモデル化できない、微妙なドメイン固有のマルウェアを作ることで難しさを増す傾向があり、そのため、よいマルウェアの仮説を立てることがボトルネックとなった。

1A から 1C のアプリケーションには、改変されたオープンソースアプリケーションがいくつか含まれていたが、エンゲージメント 2A からは、アプリケーションはゼロから開発された。これは、環境とソースコードを熟知した敵対者を模したものである。実験として、Red チームはインターンを雇い、人間の監査者を混乱させるために、大きく複雑だが書き方の拙いアプリケーションを作らせた。ほかのケースでは、悪意のある振る舞いの発見を難しくするために、デッドコード、壊れたコード、未完成のコードの大きな部分が意図的に追加された。そのようなケースでは、難しさが増したのは主にコードの品質の低さによるものであり、コードのサイズによるものではなかった。

ベースとなるアプリケーションの全般的な複雑さも、後のエンゲージメントで増した。初期のエンゲージメントのアプリケーションには、カウントダウンタイマー、聖書、スクリーンセーバー、バッテリーモニター、電卓、バックアップユーティリティなどのアプリが含まれていたが、後のエンゲージメントには、AI の Short Message Service（SMS）ボット、独自のプログラミング言語とインタプリタシェルを備えたネットワークスキャナー、デバイス管理ユーティリティ、悪用を防ぐシグネチャベースのファイアウォールを備えたデバイス追跡システムなどのアプリが含まれていた。これらのアプリケーションは、理解し、潜在的に悪意のある振る舞いの仮説を立てるのに、より多くの人間の労力を要した。

初期のエンゲージメントはほぼ完全に機密性に基づくものであり、マルウェアの仮説を立て、その存在についてコードを分析するのは容易であった。フェーズ I で我々が検出できなかった種類のマルウェアは、マルウェアの仮説を立てることが難しかったためのものであった。たとえば、非効率なアルゴリズムやバックグラウンドスレッドの無限ループを用いてバッテリーを浪費するマルウェアや、機能テストで検出できたはずの問題、たとえば正規表現を用いて中国の電話番号を誤ってバックアップする（5 と 6 の数字を入れ替える）バックアップアプリケーションなどである。

フェーズ I の終わり近くには、ほかのアプリケーションと悪意を持って連携するアプリケーションが見られた。また、動的解析の難しさが増していることも観察した。おそらく、動的解析の手法を用いるチームを阻むためであろう。この難しさの増加により、「トリガー解析」ははるかに難しくなった。マルウェアは、アプリケーションが 99 回目に起動されたときや、ある画面で 3 階層の深さのメニューを選択した後に別の画面で 3 階層の深さの別のメニューを選択したときなど、非常に厳密な条件の集合のもとで発生したからである。マルウェアの一部を発見しても、その部分がアプリケーションの別の部分の別の操作や状態によってどのように引き起こされうるかを突き止めるのは、依然として難しかった。後のチャレンジアプリケーションの多くでは、マルウェア自体はアプリケーションの外部にあり、アプリケーション内で発見すべき残りの部分は、アプリケーションとの悪意のある相互作用によって利用されうる脆弱性に近いものであった。さらに難しくするため、これらの相互作用は、我々がクライアントライブラリしか持たない独自のプロトコル上や、監査の際に提供されなかった Web サーバーとの間で起こる傾向があり、監査の際に追加の時間を投じなければ全体像を把握することがはるかに難しくなった。

我々の分析時間は、フェーズ I のアプリケーション 1 つあたり平均約 1 時間から、フェーズ II のアプリケーション 1 つあたり約 9 時間に増加した。これは、最大分析時間がそれぞれ 4 時間と 5 時間に制限されたオンサイトのエンゲージメント 2B と 3B で問題となり、成績の低下につながった。エンゲージメント 3B では、すべての Blue チームを合わせても 2 つのマルウェアしか発見できなかった。

特にエンゲージメント 4A では、公式のマルウェアの近くに「おとりのマルウェア」が置かれた。これらのおとりのマルウェアは、人間には悪意があるように見え、そう感じられたが、人間の分析者の疑いを誤った方向へそらすために、何らかの形で微妙に壊されているか無効化されていた（ただし常にではない）。これらのアプリケーションは、難しくはあったが、マルウェアの作成者は意図的に自分に疑いを向けさせない傾向があるため、我々の考えでは現実的ではなかった。