Zenn
🦔

フィッシングサイト自動テイクダウンの手法

2023/02/09に公開
AWS
GitHub
Security
#
DevOps
#
phishing
tech

はじめに

日常的なインシデント調査を効率化するために、自動化による分析は、フィッシング詐欺の分析者にとって重要な課題となっています。
クラウドベースの技術は、効率的にフィッシング詐欺の分析を自動化するための良い解決策です。
今回は、クラウドサービス上でのフィッシング詐欺分析とGoogle Safe Browsing(GSB)を活用した自動テイクダウンの方法について解説していきます。

フィッシングキットの解析結果についてこちらで更に詳しく解説しています。

対象読者

  • インフラ管理者
  • DevOpsエンジニア
  • 脅威ハンター

フィッシング攻撃の流れ

よくあるフィッシング詐欺の流れを以下に示します。

  1. 攻撃者はホスティングサーバーを購入する
  2. 購入したサーバにフィッシングキットをアップロードしセットアップする
  3. 動作確認を完了させた攻撃者は潜在的な被害者に大量のフィッシングメールを送信する
  4. 被害者はフィッング ページにアクセスして資格情報を入力する
  5. フィッシング キットは資格情報を処理し、外部の電子メール アカウントに送信する
  6. 最後に、攻撃者はこの電子メール アカウントにアクセスし、資格情報を収集する

アンチウイルスベンダをブロックする仕組み

フィッシングキットにはアンチウイルスベンダやリサーチャーのIPアドレスをブロックする仕組みを備えています。
IPアドレスのブロックはソースコードにハードコードしているものや、killbotやantibotのようなSaaSを利用して、常に最新のIPアドレスをフィッシングキット間で共有するような機能を備えていることがあります。
またipinfoのようなSaaSを利用してIPアドレスからISPの情報を取得し、特定のプロバイダのIPアドレスを全てブロックしているような場合もあります。

フィッシングサイトを構築段階で検出する方法

認証局が証明書のログを公開している場合、該当認証局がサインしたサーバ証明書が発行されるとCertificate Transparencyの仕組みによって証明書の情報がインターネット上に公開されます。
証明書にはドメイン名の情報が含まれているため、悪意のあるドメインの取得をサイトの構築段階で検出することが可能です。

攻撃者がフィッシングキットを展開している最中にGoogle Safebrowsingに報告することで被害者が出る前にブラウザの警告機能を使ってブロックすることができるようになります。
以下はセーフブラウジングの機能によって閲覧しようとしたサイトがブロックされた時の画面です。

構築したシステム

このシステムは、AWS上で動作しており、Certstreamから収集した証明書の更新履歴を収集しています。収集している履歴は定義されたルールに基づいてスコアリングされGoogleドライブへと保存して公開しています。

データのパイプライン処理はAWS EventBridige Pipesで実装していて、スコアが閾値を超えたドメインについてはurlscan.ioを使ってスキャンを行います。コンテンツが取得できる場合はYaraルールを使ってスキャンを実施し、結果をDiscordに通知しています。
フィッシングサイトと判定された場合にはGoogleセーフブラウジングとTwitterに詳細を投稿しています。

スコアリングルールやYaraルールについてもGithubに公開してるので、プルリクエスト経由で誰でも修正することが可能です。

ルールの検証について

過剰な検出を避けるためにGithub actionsを使ってスコアリングルールを最新の履歴を使って常に検証することができます。
Github actionsが失敗した場合はプルリクエストが行えないようになっています。

例えば以下のようにgithubにPushする前にスコアリングルールが問題ないかどうか検証することができます。スコアが150のドメインは1日500件までしか検出しないように調整しています。

git clone https://github.com/phishing-hunter/PHOps
cd PHOps
docker run --rm -it \
    -v $PWD:/work \
	-w /work \
	phishinghunter/cert-hunter:latest \
	/app/checker.py suspicious.yaml -f /csv/target.csv -m 500 -s 150

スコアリングアルゴリズムはこちらのリポジトリに公開しています。
phishing_catcherを参考に実装しており、ルールと同じように誰でも修正をリクエストすることができます。

Github公開するまでに注意した部分について

今回はルールの動作検証の目的でGithub actionsを活用しました。
検証用のGitリポジトリは以下を達成できるようにします

  • ルールの検証は20分ぐらいかかるのでpullリクエストする側のworkflowで実行してほしい
  • Googleドライブから最新のデータを参照してテストしたい
  • workflowを改ざんされても機密情報がダンプされないようにしたい

github actionsを使って処理の自動化を行う場合はsecrets等の機密情報がどのように処理されるかを理解しておく必要があります。

  • pull_request triggerはforkからのpull requestを受け取ったときにはfork 先のリポジトリの設定で github actions が動く
    • fork 元で設定している secrets にアクセスできない
    • テストに時間がかかる場合はfork先のアカウントでクレジットが消費される
name: Download File with Service Account
'on':
  pull_request:
jobs:
  build_and_preview:
    runs-on: ubuntu-latest
    # fork先で実行されるjob
  • trigger を pull_request の代わりに pull_request_target を使うようにすると、fork 先からのリポジトリからの pull request でも fork 元の設定で github actions が動くのでsecrets にアクセスできる
    • pull request のauthorにsecretsをダンプするようなコードを pull request で送りつけられてしまう
    • テストに時間がかかる場合はfork元のアカウントでクレジットが消費される
name: Download File with Service Account
'on':
  pull_request_target:
    types: [labeled]
jobs:
  build_and_preview:
    runs-on: ubuntu-latest
    if: contains(github.event.pull_request.labels.*.name, 'ok to test')
    # fork元で実行されるjob

このworkflow はok to testという名前のラベルが貼られた場合実行される、という意味になります。
この場合でもラベルを貼れる権限を持った人はsecretsを参照する権限を持つということになる。

今回のケースではルールの検証はfork先で行うためpull_requestトリガがユースケースに近いのですが、Googleドライブへの認証情報がfork先に存在しないとエラーになってしまいます。
これらの問題を解決するために検証データを含んだdockerイメージを毎日公開して、latestタグでdocker pullすることで最新のテストデータを認証情報無しで実行できるように作りました。
検証データを含んだdockerイメージはscheduleトリガーを使い、イメージのビルドとプッシュを行うワークフローを定期的に実行します。

最後に

今回はGithubを中心としたフィッシング詐欺検出の自動化方法について解説しました。
Githubに公開しているルールは通知するスコアの閾値やキーワードが固定されていますが、独自のキーワードや定期的なサイトの監視が必要な場合はフィッシングハンターに登録してみてください。通知はslackだけでなくwebhookでも通知することが可能です。

この記事を読んで、少しでもお役に立てたなら幸いです。何か質問やご意見がありましたら、お気軽にご連絡ください。

参考

GitHubで編集を提案

Discussion