
Quantum Route Redirectと名付けられた新しいフィッシング自動化プラットフォームは、Microsoft 365ユーザーの認証情報を盗むために約1,000のドメインを使用している。
このキットは、スキルの低い脅威行為者が最小限の労力で最大の成果を達成できるよう、フィッシング・ドメインがあらかじめ設定されている。
8月以降、セキュリティ啓発企業KnowBe4のアナリストは、Quantum Route Redirect (QRR)攻撃が幅広い地域で発生していることに気づいているが、その4分の3近くは米国に集中している。
同社によると、このキットは「高度な自動化プラットフォーム」であり、悪意のあるドメインへのトラフィックの迂回から被害者の追跡まで、フィッシング攻撃の全段階をカバーすることができるという。
攻撃は、DocuSignリクエスト、支払い通知、不在ボイスメール、QRコードに見せかけた悪意のあるEメールから始まる。

KnowBe4
このメールは、特定のパターンに従ったURLでホストされているクレデンシャル・ハーベスティング・ページに標的を誘導します。
「当社の研究者は、ドメインURLが一貫して「/([˶wd-]+.){2}[˶w]{,3}/quantum.php/」というパターンに従っており、一般的にパークドメインまたは侵害ドメインでホストされていることも観察しました」とKnowBe4は説明しています。
「合法的なドメインでホストするという選択は、これらの攻撃のターゲットとなる人間をソーシャルエンジニアリングするのに役立ちます。
KnowBe4によると、QRRフィッシング・ページをホストしている約1,000のドメインを特定したという。
内蔵のフィルタリング・メカニズムにより、ボットと人間の訪問者を区別することができ、QRRは潜在的な被害者をフィッシング・ページにリダイレクトすることができる一方、電子メール・セキュリティ・ツールなどの自動化されたシステムは良性のサイトに送られる、と研究者は付け加えている。

ソースはこちら:KnowBe4
QRRの中央トラフィック・ルーティング・システムが自動的にリダイレクト・タスクを実行するため、オペレーターはダッシュボード上で関連統計を見ることができ、そこにはリアル対非ヒトのビジター数がリアルタイムで記録されています。

KnowBe4
KnowBe4は、90カ国のMicrosoft 365アカウントを標的としたQRRフィッシングキットを観測しているが、攻撃の76%は米国のユーザーに向けられている。

Source:KnowBe4
研究者は、URLスキャン技術を回避するために使用される手法により、Quantum Route Redirectの利用が増加すると予想している。
今年初めに注目を集めた同様のサービスには、VoidProxy、Darcula、Morphing Meerkat、Tycoon2FAなどがある。
しかし、この脅威から身を守る防御方法もあります。
KnowBe4 のアナリストは、フィッシングの試みを検出できる強固な URL フィルタリングの導入と、ユーザーの認証情報が盗まれた場合にアカウントに侵害の兆候がないか監視できるツールの導入を推奨しています。
11/12更新– Beazley Security LabsもQuantum Route Redirectインフラストラクチャを以前分析し、その結果をこちらで公開しています。
.ia_ad { background-color:#width: 95%; max-width: 800px; margin: 15px auto; border-radius: 8px; border:1px solid #d6ddee; display: flex; align-items: stretch; padding: 0; overflow: hidden; }:0; overflow: hidden; } .ia_lef { flex: 1; max-width: 200px; height: auto; display: flex; align-items: stretch; } .ia_lef a { display: flex; width: 100%; height: 100%; } .ia_lef a img { width: 100%; height: 100%; border-radius: 8px 0 0 8px; margin: 0; display: block; } .ia_rig { flex: 2; padding:display: flex; flex-direction: column; justify-content: center; } .ia_rig h2 { font-size: 17px !important; font-weight: 700; color:#line-height: 1.4; font-family:margin: 0 0 14px 0; } .ia_rig p { font-weight: bold; font-size: 14px; margin: 0 0 clamp(6px, 2vw, 14px) 0; } .ia_button { background-color:#border:1px solid #3b59aa; color: black; text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; cursor: pointer; padding:width: fit-content; } .ia_button a { text-decoration: none; color: inherit; display: block; } @media (max-width: 600px) { .ia_ad { flex-direction: column; align-items: center; } .ia_lef { max-width: 100%; } .ia_lef a img { border-radius: 8px 8px 0 0; } .ia_rig { padding:15px;
width: 100%;
}
.ia_button {
width: 100%;
margin: 0px auto;
}
}
MCPのための7つのセキュリティ・ベスト・プラクティス
MCP(モデル・コンテキスト・プロトコル)がLLMをツールやデータに接続するための標準になるにつれて、セキュリティ・チームはこれらの新しいサービスを安全に保つために迅速に動いています。
この無料のチート・シートには、今日から使える7つのベスト・プラクティスがまとめられています。





Comments