攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記）

はじめに

こんにちは、ドコモグループのサマーインターンシップ2023に参加した河井です。普段は大学院で暗号理論の研究をしています。

この記事では、私がこのインターンシップで取り組んだことについて紹介します。セキュリティ系インターンシップに興味のある人の参考になれば幸いです。

はじめに
NA4Sec PJの紹介
インターンシップ概要
脅威検証：攻撃インフラの秘匿
- セキュリティに関するクローキングとは
- サーバ側のクローキングの実装
  - IPアドレスによるクローキング
  - RefererとUser-Agentによるクローキング
脅威検証：攻撃インフラの構築
おわりに
参考文献

NA4Sec PJの紹介

まずは、私がお世話になったNA4Sec PJについて紹介します。正式にはNetwork Analytics for SecurityというNTTコミュニケーションズイノベーションセンターのプロジェクトチームであり、NA4Sec（なよせ）と呼ばれています。

NA4Sec PJは、インターネット上の攻撃インフラの解明・撲滅を目指して活動するプロジェクトです。具体的には、サイバーセキュリティに関する情報の収集と分析・技術開発・人材育成を行っています。

インターンシップ概要

8/28から9/8までの約2週間、プロジェクトチームの一員としてセキュリティアナリストの仕事を体験しました。

この期間で、私は以下の4点のことに取り組みました。

脅威調査

Cobalt Strikeが何なのか理解する。
脅威分析

Cobalt Strikeが使われた攻撃事例に関するインシデントレポートをダイヤモンドモデルに基づいて分析する。
脅威探索

インターネットスキャナ系検索ツールCensysを使ってインターネット上のC2サーバを見つける。
脅威検証

以下の攻撃インフラに関わる技術について理解する。
1. 攻撃インフラの秘匿に使われるクローキング技術
2. Dynamic Device Code Phishingと呼ばれるフィッシング攻撃手法

脅威調査・分析・探索については前回のインターンシップに参加された方が紹介されていますので¹、ここでは脅威検証について紹介しようと思います。

脅威検証：攻撃インフラの秘匿

私は脅威検証として今回、サーバ側のクローキング技術の検証に挑戦しました。

セキュリティに関するクローキングとは

クローキング(cloaking)は、もともとは「マントを着せる」「覆い隠す」といった意味の単語ですが、そこから転じて「攻撃インフラの秘匿のために使われる技術」を指す用語として使われるようになりました。フィッシングサイトやマルウェアダウンロードサイトにおいて使われることが多いです。

この記事におけるクローキングの定義は次の通りです。

攻撃対象者には悪性挙動を示し、それ以外には非悪性（良性）挙動を示すことで攻撃の発見を遅らせたり、回避したりする技術

図1 クローキングをする攻撃者

クローキング技術について、攻撃対象者とそれ以外を判別するために使われる情報の例を以下にまとめます。

クローキング技術の実装箇所	利用する情報	活用方法
攻撃者のサイトを閲覧したクライアント	OSやブラウザの情報	攻撃対象者かどうか知る
	マウスの動き	人が操作しているかどうか知る
	画面・ウィンドウのサイズ、CPUのコア数	仮想環境（検証環境）かどうか知る
攻撃者のサーバ	IPアドレス	特定のIPアドレスからのアクセスを遮断する
	User-Agent	攻撃対象者かどうか知る
	Referer	例えば、ブラウザの検索結果からアクセスしてきたユーザだけを狙う
	サイトにアクセスした回数	初回のアクセス時のみ悪い挙動を見せる（IPアドレスやCookieの情報を使う）

サーバ側のクローキングの実装

今回のインターンシップでは、攻撃者のサーバ側で動作するクローキング技術の実装に取り組みました。クローキングを実装するにあたっては、クラウドサービス上でフィッシングサイトを単純に模擬した実験環境が与えられました。

その環境におけるクローキングの挙動として設定されたゴールは以下の通りです。

攻撃対象者からのアクセス：特定のページを表示（悪性な挙動はなし）
それ以外のアクセス：アクセス拒否

課題として達成すべき目標だけが与えられ、その実現手段を自分なりに考えて実装する形式でした。

ここでは、その課題と実現手段について紹介したいと思います。

IPアドレスによるクローキング

Torからのアクセス拒否

1つめは、Torからのアクセス拒否です。インターネット上で稼働しているC2サーバの中にはリサーチャー等からアクセスを防ぐためにTor経由のアクセスを遮断していると考えられるサーバが観測されています。

そこで、それらと同様に「Tor経由で来たアクセスを拒否する」ことが課題として与えられました。

Torからのアクセス拒否を実現するために、今回はTorの出口ノードだと考えられるIPアドレスからのアクセスを拒否することにしました。探したところGitHub上でTorの出口ノードをまとめているリポジトリ（SecOps-Institute/Tor-IP-Addresses）を見つけたため、今回はここから出口ノードのIPアドレスリストを取得し使用しました。ただし、このリストは度々更新されていることに注意が必要です。

モバイルキャリアによるクローキング

2つめは、モバイル回線以外のアクセス拒否です。モバイルを狙ったフィッシングなどではモバイル回線からのアクセスに限定して攻撃を発現させたいケースが考えられます。

そこで「モバイル回線からアクセスが来た場合に限って攻撃が発現する」ことが課題として与えられました。

これを実現する1つの方法として、モバイル回線のIPアドレスからのアクセス以外を拒否することが考えられます。モバイルキャリアによっては、スマートフォン向けコンテンツ開発者のためにモバイル回線のIPアドレス情報を開示しているケースがあるため、今回はその公開情報を利用して実装しました。

RefererとUser-Agentによるクローキング

3つめは、HTTPリクエストヘッダによる攻撃対象の選別です。

フィッシングサイトには、参照元（Referer）やUser-Agentの情報を使ったクローキングを実装しているものも実在します。例えば、Refererの情報を利用することでメールセキュリティサービスからのアクセスを遮断していたケースが確認されています。また、Drive-by-Download攻撃で使われたサイトやフィッシングサイトの中にはUser-Agentの情報を利用することで特定の環境でのみ攻撃が発現するようにしたり、解析ツールやCLIツールからのアクセスを遮断しようとしているケースが確認されています。

そこで「example.jpを参照元とするアクセスの拒否」や「iPhone/Android以外からのアクセス拒否」といった課題が与えられました。

これは、HTTPリクエストヘッダ内のRefererとUser-Agentの値によって挙動の場合分けをすることによって実現できます。

ところで、HTTPリクエストヘッダの内容はクライアント側でコントロールすることができます。したがって、リサーチャーは以下のようにヘッダの情報を個別に指定することで、クローキングを回避し悪性挙動を示すコンテンツにたどり着ける可能性があります。ただし、確実にたどり着くためには、フィッシングサイトがサーバ側でどのようなクローキングを仕込んでいるのか事前に知っている必要があります。

  $ curl -H "User-Agent: Android" <URL>

脅威検証：攻撃インフラの構築

今回のインターンシップではNA4Sec PJの他に関連プロジェクトであるRedTeam PJでもお世話になりました。そこでは、Dynamic Device Code Phishingという攻撃手法の検証に挑戦しました。

OAuth 2.0のデバイス認可付与（RFC8628）とは

最初に攻撃手法の説明で必要になるOAuth 2.0のデバイス認可付与(RFC8628)について紹介します。

OAuth 2.0は認可のためのプロトコルであり、認可を外部に委託するための仕組みです。

デバイス認可付与（RFC8628）は、OAuth 2.0で定義されている認可フローの1つで通称デバイスフローと呼ばれています。テレビやプリンタなどの入力制限のあるデバイスがリソースへの制限付きアクセスを得る際に使われます。

デバイスフローについて簡単に説明します。例としてプリンタからオンラインストレージへのアクセスを許可するケースを考えます。簡単なデバイスフローの流れは以下のとおりです。

プリンタ上のアプリケーションと認可サーバが通信しユーザコードを生成する。プリンタはプリンタのディスプレイなどにユーザコードを表示して、ユーザにユーザコードを伝える。
ユーザはWebブラウザを用いて認可サーバ（https://example.com/device）にアクセスし、必要に応じてユーザ認証をしたあと、ユーザコードを入力する。
プリンタはオンラインストレージにアクセスできるようになる。

つまりプリンタのディスプレイに表示されるユーザコードを、Webブラウザを用いて認可サーバ（https://example.com/device）のフォームに入力することで、プリンタが特定のリソースにアクセスすることを許可できます。

またOAuth 2.0の認可基盤としては、Microsoft Entra ID（MEID。旧Azure AD）などが用いられます。

認可フローを悪用した攻撃

認可フローを悪用した攻撃としてDevice Code Phishingがあります。 Device Code Phishingは、攻撃者が自身で生成したユーザコードと検証用URI（https://example.com/device）をメールなどで被害者に送信したあと、被害者が騙されて攻撃者のユーザコードをそのリンク先で入力することで、攻撃者が被害者のリソースに不正アクセスできる攻撃です。

しかし、ユーザコードには有効期間が設定されているため、被害者がメールをすぐに読まない場合やリンク先にすぐにアクセスしない場合に、この攻撃は失敗してしまいます。

この弱点を克服した攻撃としてDynamic Device Code Phishingがあります。この攻撃名における"Dynamic"は、ユーザコードを動的に生成することを意味しています。メールを作成する際にユーザコードを生成するのではなく、被害者がフィッシングサイトにアクセスした後で動的にユーザコードを生成するため、上記の問題が解消され、攻撃に成功しやすくなります。