警戒被害が起きている。または、起きれば重く広い

GSocket を Linux サーバーに仕込む居座り、Microsoft が警告

正規の遠隔接続ツール GSocket(gs-netcat)が Linux の Web サーバーで悪用され、パッチ後も侵入が続く。Microsoft が確認した見つけ方と確認手順。

要点

  • 正規の遠隔操作ツール GSocket が、侵入された Linux サーバーに仕込まれ、攻撃者の裏口として使われている。
  • 入り口になった Web アプリの欠陥にパッチを当てても、仕込まれたツールが残れば、攻撃者はまた入ってこられる。
  • 通信は公開の中継網を経由するため、攻撃者専用の IP やドメインを塞ぐ従来のやり方では止めにくい。

何が起きたか

Microsoft は 2026年11月11日(米国時間)、GSocket の悪用についてブログで報告した。GSocket は公開されているオープンソースの遠隔接続ツールだ。ファイアウォールや NAT(社内ネットワークを外から隔てる仕組み)の内側にある機器にも、外へ向かう通信だけでつながれる。

Microsoft の観測では、GSocket に関する検知があった機器の数は、2026年3月から8月にかけて 356.2% 増えた。月ごとの増え方は一定ではなかった。

流れはこうだ。まず攻撃者がインターネットに公開された Web アプリの欠陥から入る。次に、外部から取ってきたスクリプトで GSocket を設置する。Microsoft によると、ごく一部の例では、Linux カーネルの欠陥 CVE-2026-43284(「Dirty Frag」とも呼ばれる)を使い、Web サービス用の権限から管理者権限(root)への格上げも試みられた。

設置後の GSocket は、カーネルの部品や systemd のサービス(Linux の常駐プログラム)に似た名前で動く。cron(決まった時刻に仕事を動かす仕組み)、systemd、シェルの起動ファイルなど、複数の場所に居座りの仕掛けを置くこともある。プロセスを止めるだけでは消えないことがある、と Microsoft は述べている。

Microsoft が属性を確かめられた事例のうち、87.1% は Web アプリとホスティングだった。内訳は PHP の Web アプリと cPanel(ホスティング管理画面)が 63.9%、Apache が 24.3% だ。組織の業種では、教育・研究が 30.7%、技術・通信が 22.9% だった。Microsoft は、これは狙い撃ちではなく、公開されている Web が多いためだと見ている。

日本の利用者への影響

日本の組織への被害の報告は、今回の Microsoft の発表では確認できなかった。ただ、自分たちのサーバーに当てはまるかは、確かめる価値がある。

今すぐやること

  1. 公開している Linux サーバーで、見覚えのない常駐プログラムや定期実行の設定がないか、管理者に点検してもらう。
  2. 過去に Web アプリの欠陥を突かれた疑いがあるサーバーは、パッチを当てたあとも「侵入されたままか」を調べる。GSocket の本体と居座りの仕掛けを消し、外部の中継網への通信が止まったことを確かめる。
  3. サーバーから外へ出る通信を、必要な宛先だけに絞る。Microsoft は、外向きを原則禁止にする設定を勧めている。
  4. カーネルの更新(CVE-2026-43284 への対応を含む)を、公開サーバーから優先して進める。
  5. 一時領域(/tmp など)からプログラムを動かせない設定にできるか、検討する。

背景

GSocket のように、正規の道具を悪用する手口は目新しくない。Microsoft は、この手口では塞ぐべき攻撃者の IP やドメインが無く、攻撃者が自前で道具を作る必要もない点を挙げている。GSocket 自体は欠陥ではなく、道具の使われ方の問題である。

GSocket の悪用は以前から報告されている。SANS ISC の Xavier Mertens は2026年3月、GSocket を仕込む Bash スクリプトを報告した。1時間ごとに復活させる cron の設定も見つかっている。Sansec は、EC サイトで GSocket の鍵ファイルを探す大量のスキャンを報告している。

技術者向けの詳細

Microsoft が挙げた痕跡(すべて Microsoft の報告より)。

  • プロセス名: systemd-remount-d、defunct、[kaluad](exec -a で偽装)。カーネルスレッド風の名前も使われた。
  • ファイル: /dev/shm/.gs-0/(隠し配置)、/tmp/.gsn_ora、/usr/bin/defunct、/usr/bin/systemd-remount-d。
  • 居座り: defunct.service(multi-user.target.wants にリンク)、cron、シェルの起動ファイル。タイムスタンプの改ざん、履歴の消去、配置ファイルの削除も確認された。
  • 配布元ドメイン(C2 ではなくツールの配布先): gsocket[.]io、cdn[.]gsocket[.]io、gsgg[.]b-cdn[.]net。
  • SHA-256 の例:
    • /dev/shm/.gs-0/gs-netcat_mini-linux-x86_64: d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
    • /dev/shm/.gs-0/gs-netcat_mini-linux-aarch64: f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
    • systemd-remount-d: 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
    • /tmp/.gsn_ora: 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c
  • Microsoft の検知名: HackTool:Linux/GsNetcat.A!MTB、HackTool:Linux/GsNetcat!rfn。
  • 初期侵入の特徴: Web サーバーや PHP・Java・Node などの子プロセスから、curl で取得したスクリプトを bash で実行する動き。
  • パッチ後の確認の例:
    • systemctl list-unit-files | grep -i defunct
    • ls -la /dev/shm /tmp
    • crontab -l、/etc/cron*、各ユーザーのシェル起動ファイルの確認
    • 配布元ドメインや、中継網への外向き通信のログ確認
  • ハッシュや名前は変えられる。一致しなくても無事とは言えない。詳しい検索クエリは Microsoft の記事を参照。

出典

一次情報

報道

参考

記事は、運営者が生成 AI を活用して作成し、内容を確かめたうえで公開しています。 誤りに気づいたら編集方針の連絡先へ。

次に読む

同じタグの記事