Slapdash Safeguards

にわか仕込みのセキュリティ

悪意のあるURLスキャンサービスを繋げてフィッシングページ検知回避

by skybreaker 脅威情報

メールセキュリティ製品やURLチェックサービスは、URLをチェックしてからユーザにアクセスさせるためにhttps://<チェックサービスURL>/?url=<対象のURL>というような形式のURLを作成する。

例えば、https://cloudstorage.exampleへのアクセスURLがメールで送信されてきた場合に、Ciscoのメールゲートウェイはメール内のURLをhttps://secure-web.cisco.com/...?url=https%3A%2F%2Fcloudstorage.exampleというURLに書き換えてユーザにアクセスさせる。

これにより、問題なければそのままリダイレクトとなる。

今回の話は、https://secure-web.cisco.com/...?url=https%3A%2F%2Fmalicious.phishingというような感じのURLをユーザに送り付ければ、ユーザは安全なURLだと思うし、URL/ドメインチェックをする製品はセキュリティベンダのURLと判断して検知されない可能性が高いという話。

www.levelblue.com

URLスキャンサービスを経由してフィッシングURLへ

今回の手法は、セキュリティ製品そのものを「リダイレクタ」として使用する。

「メールサービス使っているユーザしか被害を受けないのでは？」と思うかもしれないが、その生成されたURLをフィッシングキャンペーンで使い回している。

それって「オープンリダイレクト脆弱性の悪用になるのでは？」と思うかもしれないが、クリック時にリアルタイムでURLを検査するための正規のセキュリティ機能であってURL何でもリダイレクトできる訳ではない。

正直個人的には、少し違うというくらいの感覚なので何とも言えないところもあるが。

リダイレクトを行っているドメイン自体がセキュリティベンダーの正規ドメインであり、ブロックリストに入れるわけにいかないので、リダイレクタ悪用よりも厄介。

ユーザ側からすると、メールクライアント上でリンクにカーソルを合わせてもセキュリティベンダードメインが見える。

セキュリティ意識の高いユーザでも、「セキュリティベンダーのドメインを経由しているから安全だろう」と判断してしまうのでは？

URLスキャンサービスチェーン

攻撃者は、さらに検知回避能力を高めるために複数のリダイレクトするタイプのURLスキャンサービスを組み合わせた。

例えばLevelBlueの記事では、「cisco.com」 → 「trendmicro.com」 → 「cisco.com」 → 「trendmicro.com」 → 「cudasvc.com（Barracuda）」 → 「edgepilot.com」とリダイレクトチェーンを作成したことが報告されている。

こうすると、中間ドメインがすべて正規のセキュリティベンダードメインであるため、URLレピュテーションベースの検知がほぼ無効化される。

そして、各ベンダーのパラメータは単純なURL文字列だけではなく、Base64エンコードやURLエンコードが使用されるサービスもある。

たぶん以下の用な感じ。

Step 0：元の悪性URL（最終宛先）

攻撃者が最終的にユーザーを到達させたいURL

https://www.sdsg.moe/

Step 1：Barracudaがリライト

攻撃者が侵害したBarracudaユーザーのアカウントからhttps://www.sdsg.moe/を含むメールを送信し、Barracudaのゲートウェイが自動的にリライトしたものを生成させる。

https://linkprotect.cudasvc.com/url?a=https%3A%2F%2Fwww.sdsg.moe%2F&c=E,1,xR3kZ9...&typo=1

パラメータa=に元URLがURLエンコードされて格納され、c=にはBarracuda側のトラッキングトークン。

Step 2：Sophosがリライト

Step 1で生成されたURLを、今度はSophosが有効な別の侵害アカウントからメール送信し、SophosのゲートウェイがStep 1のURL全体をBase64エンコードしてラップ。

https://us-west-2.protection.sophos.com/?d=cudasvc.com&u=aHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw_YT1odHRwcyUzQSUyRiUyRnd3dy5zZHNnLm1vZSUyRiZjPUUsMSx4UjNrWjkuLi4mdHlwbz0x&p=m&r=abc123

d=cudasvc.comはSophosが記録する宛先ドメインのヒント、u=にStep 1のURL全体がBase64で格納される。この時点で元のsdsg.moeはBase64の中のURLエンコードの中に埋もれており、単純な文字列検索では見えない。

Step 3：Cisco がリライト

同様に、Cisco Secure Emailが有効な侵害アカウントからStep 2のURLを送信。

https://secure-web.cisco.com/1A2b3C4d5E6f.../https%3A%2F%2Fus-west-2.protection.sophos.com%2F%3Fd%3Dcudasvc.com%26u%3DaHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw_YT1odHRwcyUzQSUyRiUyRnd3dy5zZHNnLm1vZSUyRiZjPUUsMSx4UjNrWjkuLi4mdHlwbz0x%26p%3Dm%26r%3Dabc123

多重にエンコードがかかり、サービスをチェーンさせるほど最終的な宛先URLの静的解析が困難になっていく。

上記は想像ベースだが、大体こんな感じだと思う。

こうなると、シグネチャベースの検知だとエンコードされたものは当てはまらなかったり、エンコード順をちょっと変えただけで検知回避される。

セキュリティチェック用の自動クローラー/サンドボックスは、多層リダイレクトの途中にCAPTCHAやJavaScript実行やタイムアウトやリダイレクト上限に引っかかりスキャンできなくなったりする。

攻撃者が最初にスキャンさせる時点では、フィッシングページとなる最終宛先がまだ検知されていないのだろうし、もしくはまだフィッシングページとして稼働させていないから検知されないのかもしれない。

それか、フィッシングページ検知がガバガバなサービスなら長くフィッシングページを稼働させられるのかもしれない。

というように様々なベンダーのサービスが悪用されていたことが確認されている。

ベンダー ドメイン例
Avanan url.avanan.click
Barracuda linkprotect.cudasvc.com
Bitdefender linkscan.io/scan
Cisco secure-web.cisco.com
Cloud Security {securelinks|seclinks}.cloud-security.net
EdgePilot link.edgepilot.com
Egress *.defend.egress.com
Libraesva urlsand.esvalabs.com
Hornetsecurity atpscan.global.hornetsecurity.com
INKY shared.outlook.inky.com
Intermedia url.emailprotection.link
MailAnyone url..mailanyone.net
Mimecast *.mimecastprotect.com
Proofpoint urldefense.proofpoint.com
Sophos *.protection.sophos.com
Synaq linkshield.synaq.com
TitanHQ linklock.titanhq.com
Topsec scanner.nextgen.topsec.com
Trend Micro *ctp.trendmicro.com

PhaaS（Phishing as a Service）での活用事例

このURLスキャンサービスチェーンの悪用は、Tycoon2FAやSneaky2FAで確認されているとのこと。

Tycoon2FAは5ベンダーのネストチェーン、Sneaky2FAはHTML添付ファイル内にチェーンが埋め込まれているファイルをメールで送信していた。

しかし、Tycoon2FAは既に大規模テイクダウンがあったので、脅威は去ったか？それとも粛々と活動しているのだろうか。
www.trendmicro.com

今回の話と直接的な関係性は無いが、参考までにTycoon2FAやSneaky2FAの情報は以下に。

Tycoon2FA

  1. Sekoia — "Tycoon 2FA: an in-depth analysis of the latest version of the AiTM phishing kit"
    Tycoon2FAの最初の本格的な技術分析。Dadsec OTTとのコード類似性、管理パネル構造、AiTMフローの各ステージ、インフラ追跡。
    blog.sekoia.io

  2. Microsoft Security Blog — "Inside Tycoon2FA: How a leading AiTM phishing kit operated at scale" (2026年3月)
    Microsoft自身による分析。管理パネルのスクリーンショット、サブドメインローテーション戦略、Telegramでの販売形態（$120/10日、$350/月）、難読化手法、セッションCookie窃取の詳細フロー解説。
    www.microsoft.com

  3. CYFIRMA — "Tycoon 2FA: A Technical Analysis of its Adversary-in-the-Middle Phishing Operation"
    CAPTCHAゲーティング、バックエンドのメール検証、リアルタイムクレデンシャルリレー、エラーメッセージ解析による標的適応機能など、キットの内部動作を技術的に分解。YARAルール付き。
    www.cyfirma.com

  4. LevelBlue SpiderLabs — "Tycoon2FA New Evasion Technique for 2025"
    2025年の新しい回避技術に特化。カスタムCAPTCHA（HTML5 Canvas）、不可視Unicode文字によるJS難読化、Proxyオブジェクト併用、アンチデバッグなど。CyberChefでのデコード手順とYARAルール掲載。
    www.levelblue.com

  5. Barracuda — "Threat Spotlight: Tycoon 2FA phishing kit updated to evade inspection"
    2024年11月のバージョン変更点。侵害済みメールアカウントからの送信、外部JSリソース呼び出しの廃止、新たな難読化スクリプト関数の追加など。
    blog.barracuda.com

Sneaky2FA

  1. Sekoia — "Sneaky 2FA: exposing a new AiTM Phishing-as-a-Service"
    PHPソースコード分析、ライセンスAPI検証の仕組み、W3LL OV6との画像ハッシュ一致、Telegramボット（@SneakyLog_bot）の販売体系、約100ドメインのIOC公開。
    blog.sekoia.io

  2. Menlo Security — "Inside Attacker's Defensive Funnel: How Sneaky 2FA Cloaks Itself from Security Scanners"
    Cloudflare Turnstile、qualityScore変数によるクライアント側行動スコアリング、CSSのdisplay:noneを使ったHTML文字列分断（キーワード検索妨害）、DOMレベルの難読化コード。
    www.menlosecurity.com

  3. The Hacker News — "Sneaky 2FA Phishing Kit Adds BitB Pop-ups"
    Browser-in-the-Browser (BitB)機能解説。偽SSOポップアップの実装、OS/ブラウザ別の動的適応、トラフィック分割によるクローキングなど。
    pushsecurity.com

  4. Centripetal — "Tycoon 2FA versus Sneaky 2FA: Two PhaaS Campaigns Targeting MFA Bypass"
    両キットの比較分析。攻撃チェーンの差異、IOC（Sneaky: 170+、Tycoon: 306+）の分析、使用レジストラの傾向、ドメイン検知までのタイムフレームの比較。
    www.centripetal.ai

セキュリティベンダーのドメインだからって信じて良いわけではない。

高度なフィッシングって目につくので、よく解説しながら思うことがある。

フィッシングメール訓練って、このレベルまで対応しているものはあるんだろうか。

ここまで来るとペネトレーションテストかレッドチームオペレーションか？