私たちはフィッシング対策の「階層」を間違えている

攻撃者はフィッシング用ドメインをほぼ無料で入れ替えられます。セキュリティチームは、隠しにくいサーバーやインフラを追跡すべきです。

以前、攻撃者の作業時間を計測したことがあります。ドメインを登録してから、委任と証明書の取得を経て、認証情報を盗むページが稼働するまで、24分もかかりませんでした。しかもそのうち12分は、ネームサーバーの反映待ちでした。

この数字が頭から離れません。私たちのフィッシング対策の大半が、静かに問い直されるからです。私たちはドメインをブロックします。メールゲートウェイやDNSフィルター、脅威インテリジェンスプラットフォームにドメインを登録し、ブロック数を集計して、取締役会に報告します。取締役会はその数字に安心します。ところが、ブロックしている相手は、攻撃者にとっては1ドル程度、20分ほどで作り直せるものにすぎません。

ドメインは、攻撃者が持つ資産のなかで最も安価なものです。それなのに、多くのセキュリティプログラムが目にするのは、このドメインだけです。

攻撃者が実際にコストを負担しているのは、サーバーの層です。サーバーには費用も構築の手間もかかります。作り直すのが面倒なので、複数のキャンペーンにわたって使い回されます。そして何より、サーバーは共有されるため、攻撃活動の残りの部分も一緒に引き連れています。サーバーを見つければ、得られる指標は1つにとどまりません。攻撃基盤の全体が見えてきます。

だからこそ、最近のフィッシングキットは、サーバーを見つけられないように作られています。

壁と、そのひび割れ

現在、問題になっているキットは、中間者攻撃(AiTM)型のプロキシです。偽のログインページを表示するのではなく、被害者の通信を本物のMicrosoftサインインサービスへリアルタイムに中継します。本物の応答を被害者に返し、その途中で認証情報とセッショントークンを盗み取ります。被害者の目に映るのは本物のページで、多要素認証も本物のプロンプトで完了します。それでも攻撃者は、有効なセッションを手にします。Microsoftは、この手口による1つのキャンペーンが1万を超える組織に及んだと報告しています。以来、この手口の商品化はさらに進みました。

このプロキシをコンテンツ配信ネットワーク(CDN)の背後に置くと、サーバーは見えなくなります。先月、私が直面したのがまさにこの状況でした。証明書の透明性ログに出てきたのはCDN側の証明書で、オリジンの証明書ではありませんでした。パッシブDNSを見ても、そのドメインがほかのどこにも解決されたことはありませんでした。インターネット全体をスキャンするプラットフォームも、結果は空でした。当初は何も存在しないのだと解釈しましたが、後になって、これは拒否されていたのだと理解しました。オリジンは、想定どおりのホスト名を提示しない接続をすべて、1バイトも返さずに0.5秒足らずで切断していたのです。

この違いは、少し立ち止まって考える価値があります。腕のあるアナリストでも、この間違いをするのを私は見てきました。ホスト名で接続を制限しているサーバーに対してスキャンプラットフォームが空の結果を返しても、何もないという意味にはなりません。間違った言葉でドアをノックしただけです。この2つを同一視すると、全員が納得したまま、調査が早々に終わってしまいます。

メールも手がかりになりませんでした。誘い込みのメールは、実在する企業の、本当に乗っ取られたメールボックスから届いており、認証チェックはすべて通過していました。そのため、メッセージのどこにも攻撃者のアドレスはありませんでした。あるはずがなかったのです。

10通りの手法を試し、10回行き詰まりました。最後に突破口となったのは、攻撃者自身のサーバーが被害者に渡したCookieでした。

自分の名前を署名してしまうプロキシ

仕組みは単純です。だからこそ、私はこれまで確認しようと思いつかなかったのでしょう。

プロキシがログインを中継するとき、Microsoftから見えているのは、あるクライアントが接続してきたという事実です。そのクライアントは被害者ではなく、プロキシです。接続を行っているのはプロキシだからです。そしてMicrosoftは、多くのサービスと同様に、そのクライアントがどのアドレスから接続してきたかを記録したCookieを設定します。

プロキシは、誰かが止めない限り、透過型リバースプロキシとして動作します。応答をCookieごと被害者へ中継するのです。応答ヘッダーを書き換える設定は、誰もわざわざ行わないからです。

その結果、被害者のブラウザには、攻撃者自身の中継サーバーのIPアドレスが刻まれたCookieが届きます。プロキシは、封筒に自分の差出人住所を書いたうえで、それを盗みの相手に手渡しているのです。

私がこれを見つけたのは、復号したキャプチャデータから、フィッシングサイトが設定したCookieを絞り込んでいたときです。値はMicrosoftのアドレスでも、私のサンドボックスのアドレスでもありませんでした。暗号資産での支払いを受け付ける、小規模なホスティング再販業者のものでした。

ここで次に何をしたかは、発見そのものより重要です。どのチームに助言するときも、私が強く伝えたい点でもあります。私はこれを確定とは見なしませんでした。1つの痕跡は手がかりにすぎず、結論ではありません。前者から後者へ飛躍すれば、研究が撤回され、インテリジェンスプログラムは予算に値する信頼を失います。

その後の1時間は、自分の発見を覆すことに費やしました。まず考えられた別の説明は、Cookieが攻撃者のものではなく、私の検証環境の送信元を記録したというものでした。そこでアドレス自体を調べました。格安の仮想サーバー再販業者のもので、商用サンドボックスが使う経路ではありません。これで別の説明は弱まりましたが、完全には消えませんでした。決め手となったのは、最初の観察が影響を及ぼしえない方向からの裏付けです。それらは独立して得られ、結果が一致しました。そこで初めて、オリジンという言葉を書くことにしたのです。

もし結果が食い違っていれば、未検証のままメモに残し、そのとおりに公表していたでしょう。証明されていない結果も、結果であることに変わりはありません。次のアナリストにとっては、自信満々の推測よりも、不確かさを明記した情報のほうが役に立ちます。

1通のメールから、攻撃基盤の全体へ

サーバーの層で調査を進めると、何が得られるのか。これが、この層で調査すべき理由のすべてです。

サーバーのアドレスをたどると、2つ目のドメインが見つかりました。数か月前からそこを静かに指していながら、一度もコンテンツを配信していなかったドメインです。そこから、運営者がほかでは使っていないレジストラにも行き着きました。残りのドメインを名前解決すると、数台のマシンに集約されました。そのうち2台には、別々のクラウドIDテナントに属するドメインが載っていました。運営者が、手間をかけて分離していたテナントです。

これが事件の突破口でした。それらのテナントには、外から見える関係はありませんでした。どちらか一方を列挙しても、もう一方は決して見つからなかったでしょう。しかし運営者はホスティング費用を節約していました。共有されたインフラが、分離されたIDによって隠されていたものを明らかにしたのです。

報告された1通のフィッシングメールから、数十のよく似たドメインで構成される攻撃基盤の全体像が浮かび上がりました。それらのドメインは、実在のメーカーや人材派遣会社、廃棄物回収業者になりすましています。6か月にわたって辛抱強く構築され、取引先に対する請求書詐欺を支えていました。ドメインからは、どれも見えませんでした。サーバーからは、すべてが見えました。

1ドルで作り直せるものをブロックしているだけでは、何ひとつ見つけられなかったでしょう。

同じ事実を自社のテナントに向ける

セキュリティプログラムを運用する人にとって、最も重要なのは調査手法ではありません。発想の逆転です。しかもこれは、攻撃者が不注意であることを前提にしていません。

Microsoftから見えているのがプロキシなら、皆さんのログに映るのもプロキシです。従業員がこうしたキットでフィッシングの被害に遭うと、テナントに記録される成功したサインインには、従業員のアドレスではなく中継サーバーのアドレスが残ります。これは検知できるイベントです。ほかの統制がすべて正常を示したまま進む攻撃のなかで、数少ない信頼できるシグナルでもあります。この点が重要なのは、多くの組織が頼る予防的な統制では、この攻撃を止められていないからです。独立した分析では、こうしたキットで侵害されたアカウントの大多数が、すでに多要素認証を有効にしていたことがわかっています。

この検知が実際に機能するかどうかは、2つの点で決まります。1つ目は、ホスティング事業者や仮想サーバーのアドレス帯を調べることです。従業員がそうしたネットワークからサインインする正当な理由はなく、こうした中継サーバーが置かれているのもそこです。2つ目は、トークンが永続する点を忘れないことです。キットはセッションを維持するプロンプトをクリックするため、攻撃者のその後の活動は、新規サインインではなくリフレッシュのイベントとして現れます。対話型のログインだけを調べるハンティングでは、侵害の瞬間は見つかっても、その後の活動はすべて見逃します。実際にそうなった例を、私は見たことがあります。

そして実際に見つけたときは、対応の順序を変えてはいけません。攻撃者が握っているのはパスワードではなく、セッションです。先にセッションを失効させ、そのあとで認証情報をリセットします。順序が逆になると、何の効果もありません。全員がインシデントは終わったと信じているあいだも、侵入者は活動を続けます。

本件の技術的な詳細は、指標や検知ルールとともに公開リポジトリにまとめました。証拠を自分で確かめたい方は、ぜひご覧ください。私の言葉を信じるより、ほかの方に検証してもらいたいと考えています。

持ち帰っていただきたいのは、今回の手法そのものではありません。ドメインのブロックは、いつも進歩しているように感じられます。数字が増え、報告も簡単だからです。しかし私たちは、攻撃者が持つ最も安価なものに労力を費やしています。攻撃者のコストがかかっているのはサーバーです。私たちが力を注ぐべきなのも、そこです。

翻訳元: https://www.csoonline.com/article/4231923/we-are-fighting-phishing-at-the-wrong-layer.html

本記事は csoonline.com の記事を翻訳・要約したものです。