GSocketバックドア: PHP、cPanel、Apacheのホストで侵害を確認

概要

2026年11月11日、Microsoftは、侵害されたLinuxサーバーにGSocketを導入している複数の別々の攻撃者グループに関する調査を公開しました。BleepingComputerは2026年11月12日にこれを報じています。GSocketは正規のオープンソースのリモートアクセスツールです。サーバー上で実行されると、サーバーと攻撃者の双方が公開の中継サービスであるGlobal Socket Relay Networkへ外向きの接続を行います。中継サービスは両者を結び、暗号化されたセッションを構成します。サーバーに公開ポートやグローバルIPアドレスは必要ありません。攻撃者は独自のインフラを運用していないため、ブロックすべき攻撃者のIPアドレスやドメインはありません。

これはGSocketの脆弱性ではありません。攻撃者はまずインターネット公開のWebアプリケーションに侵入し、その後アクセスを維持するためにGSocketを導入します。GSocketはアプリケーションとは別に動作するため、アプリケーションにパッチを適用しても削除されません。Microsoftによると、同社のテレメトリにおけるGSocket関連の検知件数は、2026年3月から8月の間に356.2%増加しました。

Microsoftは攻撃の流れを次のように説明しています。

• 攻撃者はWebアプリケーションを悪用し、curlを使ってインストールスクリプトをダウンロードして実行します。
• スクリプトは、/dev/shmなど書き込み可能またはメモリ上のパスにGSocketのクライアントを配置します。
• プロセスは、カーネルスレッドに見える名前（例: [kaluad]）や、systemd-remount-d、/usr/bin/defunctなどのシステムらしい名前で偽装されます。
• 永続化は、cronジョブ、systemdサービス、シェルの起動ファイル、ウォッチドッグ、追加のコピーによって設定されます。その後、ステージング用のファイルは削除され、ファイルのタイムスタンプは過去の日時に書き換えられます。
• 一部のケースでは、攻撃者はLinuxカーネルの脆弱性CVE-2026-43284（「Dirty Frag」として知られる）を通じてrootの権限を取得しようとしました。

影響を受ける対象

過去に侵害されたことがある、インターネット公開のWebアプリケーションを実行しているLinuxサーバーが対象です。Microsoftのデータでは、インシデントの87.1%がWebアプリケーションおよびホスティングに関係していました。そのうち、PHPのWebアプリケーションとcPanelホスティングが63.9%、Apacheが24.3%を占めています。Microsoftは、JavaおよびNode.jsのWebアプリケーションから起動されたシェルに関するアラートも挙げています。最近Webアプリケーションの欠陥が見つかり修正されたサーバーは、パッチ適用前に攻撃者が侵入していた可能性があるため、特に確認する価値があります。

Webアプリケーションが一度も侵害されていないサーバーは対象外です。自社のチームが意図的に導入したGSocketは、それ自体では侵害の兆候ではありません。

今すぐ行うこと

1. インターネット公開のすべてのLinuxのWebサーバーを確認してください。 次のセクションの手順を使用します。最近数か月の間に、Webアプリケーション、CMS、プラグイン、またはホスティングパネルの欠陥にパッチが適用されたサーバーから始めてください。
2. GSocketが見つかった場合は、そのサーバーを侵害されたものとして扱ってください。 プロセスを停止します。その後、バイナリ、すべてのコピー、およびすべての自動起動の設定（cron、systemdユニット、シェルの起動ファイル、ウォッチドッグスクリプト）を削除します。Microsoftは、永続化の仕組みが多層的であることが多いため、プロセスを停止するだけではアクセスは削除されないと指摘しています。攻撃者がCVE-2026-43284などを通じてrootの権限を取得した可能性がある場合は、クリーンなイメージまたは侵害前に取得したバックアップからサーバーを再構築することが最も安全です。
3. 影響を受けたサーバーの認証情報を変更してください。 データベースのパスワード、アプリケーションのシークレット、APIキー、SSHキーが対象です。また、authorized_keysに不明なエントリがないか確認してください。
4. 侵入経路を特定して塞いでください。 Webアプリケーション、CMSプラットフォーム、プラグイン、アプリケーションサーバーを更新してください。使用していないコンポーネントを削除し、ファイルアップロードと管理用パスを制限してください。
5. CVE-2026-43284（「Dirty Frag」）に対してカーネルにパッチを適用してください。 ディストリビューションのカーネル更新を適用し、新しいカーネルで再起動してください。
6. 外向きの通信を制限してください。 可能な場合は、外向きの接続をデフォルトで遮断し、サーバーに必要な宛先のみを許可してください。GSocketの通信は外向きのみのため、受信方向のファイアウォールルールでは検知できません。
7. 一時ディレクトリを強化してください。 実施が可能であれば、/tmpと/dev/shmをnoexecオプションでマウントしてください。
8. 事後に検証してください。 サーバーがGSocketの中継サービスや、下記のドメインにもはや接続していないことを確認してください。

影響を受けているかの確認方法

以下の確認はrootで実行してください。1件の一致だけでは侵害の証拠になりませんが、調査が必要です。

Microsoftが挙げているファイルとパス:

ls -la /dev/shm/.gs-* /tmp/.gsn_ora /tmp/systemd-remount-d /usr/bin/systemd-remount-d /usr/bin/defunct 2>/dev/null
find / -xdev \( -name 'gs-netcat*' -o -name 'defunct.service' -o -name 'defunct' -o -name 'systemd-remount-d' \) 2>/dev/null

実行中のプロセス:

ps -eo pid,ppid,user,args | grep -Ei 'gs-netcat|gsocket|defunct|remount-d' | grep -v grep

実際のカーネルスレッドには実行ファイルがありません。[kaluad]のように角括弧で囲まれた名前のプロセスがファイルを指している場合は、不審です。

for p in /proc/[0-9]*; do n=$(cat $p/cmdline 2>/dev/null | tr '\0' ' '); case "$n" in \[*) e=$(readlink $p/exe 2>/dev/null); [ -n "$e" ] && echo "${p#/proc/} $n -> $e";; esac; done

永続化:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
systemctl list-unit-files --type=service | grep -Ei 'defunct|remount'
grep -sEl 'gs-netcat|gsocket|defunct|GS_' /etc/profile /etc/profile.d/* /etc/bash.bashrc /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile

もっともらしい名前でも、ご自身で作成していないsystemdユニットがないか注意深く確認してください。www-data、apache、nobodyなどのWebサービス用アカウントのホームディレクトリと、cPanelのユーザーのホームディレクトリも確認してください。

Microsoftが挙げている既知のファイルハッシュ（SHA-256）:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

ネットワークとログ: DNS、プロキシ、ファイアウォールのログでgsocket.io、cdn.gsocket.io、gsgg.b-cdn.netを検索してください。これらのドメインはツールのダウンロードに使用されます。また、シェルの履歴とWebサーバーのログで、curlを使ってgsocket.io/yまたはgsocket.io/install.shを取得するコマンドを検索してください。Webサーバーまたは PHPプロセスから起動されたシェルを確認してください。ss -tnpを使って外向きの接続を保持しているプロセスを確認し、説明できないものは詳しく調べてください。攻撃者はステージング用ファイルやコマンド履歴を削除することがあるため、ある場所で痕跡が見つからなくても、サーバーが安全であるとは限らない点にご注意ください。

出典

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/