Weaponized ScreenConnect App Spreads AsyncRAT and PowerShell RAT
2025/09/19 gbhackers — ConnectWise ScreenConnect などのリモート監視/管理のためのツールは、IT 管理を簡素化することで評価を確立している一方で、高度な攻撃者の注目を集めている。攻撃者たちは、ScreenConnect の信頼できるインストール環境と高いシステム権限を悪用することで、そのインストーラーをトロイの木馬化している。具体的に言うと、AsyncRAT とカスタムされた PowerShell RAT という、2種類の Remote Access Trojans (RAT) を、米国の組織を標的として展開している。

この新たな脅威で確認された手法は、汎用的な RAT を正規のソフトウェア・チャネル内に隠蔽し、ステルス性の高い長期的なアクセスを実現するものだ。
最近の Hunt.io の調査では、トロイの木馬化された ScreenConnect インストーラーが、オープン・ディレクトリ上にホストされ、動的な “/Bin/” パスを介してペイロードを取得するという、再利用が可能な悪意のインフラのパターンが確認されている。
少なくとも8台のインフラ・ホスト (例: 176.65.139[.]119/45.74.16[.]71/164.68.120[.]30) が、”logs.ldk” や “logs.idr” の亜種も含めたインストーラを公開しており、それらのサイズは 60KB〜3MB の範囲だとされる。
それらのインストーラーが実行されると、多段階のシーケンスが起動される。VBScript/JavaScript ドロッパーがショートカットを呼び出し、PowerShell ローダー (Skype.ps1) を実行する。このローダーは、ペイロード BLOB を再構築/デコードしてメモリにロードする場合もあれば、”libPK.dll” を利用してネイティブ・インジェクションでロードする場合もある。
多くのケースにおいて、最初の段階では /Bin/ ディレクトリから取得された ClickOnce 形式のインストーラーが利用され、偽の IRS や Zoom の更新ページなどのソーシャル・エンジニアリングと、信頼できる ScreenConnect ブランドが組み合わされている。
これらの事例が示すのは、ScreenConnect がマルウェア配信ベクターであるだけではなく、サプライチェーン攻撃における高価値の標的になっていることだ。
この二重の RAT 配信戦略により、たとえ1つのペイロードが無効化されても、攻撃の基盤は維持される。
巧妙な攻撃手法
複数のホストで確認された、この二重 RAT のアプローチは、防御側の対策に適応しながら、複数の実行経路を活用していく。
スクリプト・ベースのスキャン機能を備えた環境では、”Skype.ps1″ が .NET の “Assembly.Load” を介して下流モジュールをメモリに直接ロードし、ディスク上には痕跡を残さない。
保護されていない、あるいは AV が導入されていないエンドポイントでは、ローダーが “libPK.dll” の “Execute” エクスポートを呼び出し、”AppLaunch.exe” などのネイティブ Windows バイナリを読み込み、信頼されているプロセス内に RAT を埋め込む。
永続性の維持は、”SystemInstallTask” または “3losh” という、2分間隔で実行されるスケジュール・タスクにより実現される。

AsyncRAT の通信は、標準ポート (21/80/443) と高ポート (30,000~60,000) を利用し、多くのケースにおいて TLS による検査の回避を可能にしている。
ScreenConnect クライアントの頻繁な再パックと動的なドメイン・ローテーションにより、静的な検出は困難になっている。なお、2024年以降において、”/Bin/” URL パターンは、少なくとも8件のフィッシング・キャンペーンで確認されている。
緩和策
防御側にとって必要なことは、ハッシュ依存の検出から、動作/手法に基づく制御へと移行することである。
RMM (Remote Monitoring and Management) インストーラーに対して、署名者メタデータの検証と不定期ベンダーチェックによる厳格なホワイトリスト登録を適用することで、トロイの木馬化バイナリの実行を防げるようになる。
また、プロキシや IDS は、”/Bin/” のダウンロードおよび ClickOnce URL に対して、異常を示す Content-Type レスポンス・フラグを付ける必要がある。さらに、エンドポイント・セキュリティで求められるのは、Add-Type ランタイム・コンパイル/メモリ内 Assembly.Load/DLL エクスポートによる、ネイティブ・インジェクションに関するルールである。
“C:\Users\Public” などの、書込が可能な場所からの実行に対しては、ブロックまたは厳重に監視で臨み、AppLocker や Device Guard ポリシーでレガシー・スクリプト・ホストを制限すべきである。
プロアクティブなハンティングでは、”Ab.vbs/Ab.js” ドロッパー、”Skype.ps1″ ローダー、”libPK.dll” エクスポート、”logs.*” ペイロード・コンテナといった指標に注目する。
さらに、ホスティング・プロバイダや CERT と連携し、オープン・ディレクトリやフィッシング・ドメインを削除することで、攻撃インフラに混乱を引き起こせる。
まとめると、武器化された ScreenConnect インストーラーは、信頼できる RMM ソフトの悪用/適応的なペイロード・ステージング/巧妙なネットワーク戦術を組み合わせた、デュアル RAT 配信メカニズムとして機能している。
ユーザー組織にとって必要なことは、行動ベースの EDR/TLS インスペクション/厳格な RMM インストーラー制御に加えて、積極的なハンティングを含む多層防御を導入することで、サプライチェーンのリスクを回避し、ステルス侵入を防止することである。進化する攻撃キャンペーンを検知/阻止するためには、”/Bin/” パターンとモジュール型ペイロード・コンテナの継続監視が不可欠である。
ScreenConnect など正規の RMM インストーラーを悪用する攻撃者たちは、信頼チェーンと配布経路の検証不足の隙を突いてきます。ClickOnce やオープン・ディレクトリ経由で、ScreenConnect の改変版や悪意のインストーラーが配布され、署名や配布元チェックが緩いと、メモリ内ロードやネイティブ注入で痕跡を残さず侵入を成功させるようです。それに加えて、動的ドメインや TLS 回避により検出が難しくなると、この記事は指摘しています。よろしければ、ScreenConnect で検索も、ご参照ください。



You must be logged in to post a comment.