GSocketのリレーとの通信を探す：Google Threat Intelligence で接続先のIPアドレスを洗い出す

この記事の要点

GSocketの通信で、ログに残るもの

GSocketは、オープンソースの遠隔操作の道具です。Microsoft社は2026年11月に、攻撃者がWebアプリケーションの脆弱性から侵入したLinuxサーバーにGSocketを置き、脆弱性を直したあとも接続を保っていた事案を公開しました（Microsoft社の記事）。

GSocketでは、侵害されたサーバーと操作する側の両方が、GSocketのリレー（Global Socket Relay Network）に外向きにつなぎ、リレーが2つの接続を結びます。攻撃者は自前のサーバーを用意しないので、自組織のログに攻撃者のIPアドレスは残りません。

攻撃の指令を中継するサーバーはC2と呼ばれ、ふつうは攻撃者が自分で用意します。GSocketでは、このC2サーバーの役目を、リレーが果たします。違いは、リレーが攻撃者のものではないことです。GSocketの開発元が公開している共有のサービスで、誰でも無料で使えます。そのため、ログに残るリレーのIPアドレスは、どの攻撃者かの手がかりにはなりません。

一方で、侵害されたサーバーからリレーへの通信は残ります。GSocketの公式のソースコードでは、既定の接続先はa〜z.gs.thc[.]orgの26の名前のどれかで、ポートは443番です。どの名前につなぐかは、接続に使う秘密の値から決まります。

Microsoft社の記事も、対策として、リレーへの通信を監視することと、駆除したあとにリレーへの通信が止まったことを確かめることを挙げています。リレーとの通信の中身は端から端まで暗号化されているので、ログで分かるのは、どのサーバーがリレーにつないだかです。

Google Threat Intelligence で、GSocketの使われ方を調べる

Microsoft社の記事は、複数の無関係な攻撃者がGSocketを使っていると書いています。誰が、どの業種で使ったかは、Google Threat Intelligence（以下GTI）でたどれます。

GSocketのページから、攻撃者とキャンペーンをたどる

GTIには、Google社の分析チームがまとめたGSOCKETのページ（種類は Software Toolkit）があります。このページは、2つの攻撃者（Associated Actors）と、6つのキャンペーンに結び付いています（2026年11月13日、弊社のEnterpriseの契約で確認）。

2つの攻撃者は、動機が違います。1つは諜報と破壊、もう1つは金銭です。動機の違う攻撃者が、同じ道具を使っています。

6つのキャンペーンは、2024年12月から2026年9月にかけてのものです。狙われた業種は、教育が3つで、ほかは金融、エネルギー・公益、政府でした。Microsoft社の記事も、影響を受けた組織は教育・研究がいちばん多いと書いています。キャンペーンごとの期間、地域、結び付いた攻撃者は、GTIの画面で確かめられます。

Microsoft社の記事のファイルを引く

Microsoft社の記事に載っている4つのファイル（SHA-256）をGTIで引くと、4つともGTIの判定はMaliciousで、GTIスコアは70〜95でした（2026年11月13日）。

1つ目のファイルは、GSOCKETのページのキャンペーンのうち2つと、2つの攻撃者に結び付いています。公開された記事の指標から、GTIのキャンペーンと攻撃者のページへたどれます。

Google Threat Intelligence でリレーのIPアドレスを洗い出す

リレーの名前は決まっていますが、名前の解決先のIPアドレスは入れ替わります。GTIのパッシブDNS（名前とIPアドレスの対応を観測した記録）で、今と過去のIPアドレスを洗い出します。

GTIは、リレーの26の名前のうち24を、MaliciousかSuspiciousと判定しています。Maliciousが11、Suspiciousが13です（2026年11月13日）。

名前ごとの解決先の履歴を見る

GTIの検索欄にリレーの名前を入れ、ドメインの画面のRELATIONSタブを開きます。Passive DNS Replication の欄に、この名前の解決先のIPアドレスと、観測した日が並びます。次の画面は、t.gs.thc[.]org（GTIの判定はMalicious、GTIスコア60）の例です。

t.gs.thc[.]orgには、2022年3月2日から2026年7月16日までに観測した8つのIPアドレスがありました。同じように26の名前を引くと、2020年12月2日から2026年7月21日までに観測した27個のIPアドレスが出ました（2026年11月13日に照会）。解決先は1日単位で変わることがあるので、照らし合わせるたびに引き直します。

DomainToolsで、リレーだった期間を確かめる

洗い出したIPアドレスをログと照らすときに、もう1つ必要なのが期間です。リレーのIPアドレスは入れ替わるので、同じIPアドレスへの通信でも、リレーだった期間の中か外かで意味が変わります。

GTIのパッシブDNSに出る日付は、名前とIPアドレスの組ごとに、観測した日が1つです。期間は、DomainToolsの Iris Investigate で分かります。DomainToolsは、ドメインとDNSの記録を調べる製品です。パッシブDNSでは、IPアドレスごとに、最初に観測した日時（First Seen）、最後に観測した日時（Last Seen）、観測の回数が出ます。

図は、t.gs.thc[.]orgの8つの解決先を、同じ時間軸に並べたものです。出てくるIPアドレスは、GTIもDomainToolsも同じ8つでした。GTIの観測日（点）は、8つともDomainToolsの期間（帯）の中に入っています（2026年11月13日）。

リレーのIPアドレスは、複数の名前で使い回されています。GTIでも、26の名前の観測日をIPアドレスごとに集めると、点が増えて、おおよその時期が分かります。ただ、始まりと終わりの日は分かりません。たとえば91.188.254[.]187は、GTIの観測日をつなぐと2024年8月28日から2025年2月27日までですが、DomainToolsでは2025年11月28日まで観測されていました。

期間が分かると、ログの通信がリレーへの通信だったかを、日付で確かめられます。たとえば、次のようになります。

GTIでは、名前の判定、通信したファイル、使っている攻撃者が分かります。DomainToolsでは、そのIPアドレスがいつからいつまでリレーだったかが分かります。2つを合わせて、照らし合わせに使う一覧を「IPアドレスと期間」の組にします。

同じIPアドレスが、別の名前のリレーになっていた期間もあるので、26の名前の期間を合わせて見ます。pDNSのパネルは、複数の提供元の記録を並べます。0.0.0.0のような、リレーではない応答が1つの提供元だけに出ることがあるので、複数の提供元に出ているIPアドレスを採ります。

その日の名前解決と組み合わせる

パッシブDNSは観測の記録です。照らし合わせに使う一覧は、パッシブDNSの履歴に、その日に名前解決した結果を足して作ると確実です。2026年11月13日に26の名前を名前解決すると、解決先は10個のIPアドレスで、10個ともGTIの27個に含まれていました。

APIでまとめて引く

26の名前を画面で1つずつ引く代わりに、GTIのAPIでまとめて引けます。次の例は、26の名前の解決先の履歴をCSVのファイルに書き出します。APIキーを環境変数GTI_API_KEYに入れて実行します。Python 3 の標準ライブラリだけで動きます。

import csv
import json
import os
import string
import urllib.request
from datetime import datetime, timezone
API_KEY = os.environ["GTI_API_KEY"]
rows = []
for c in string.ascii_lowercase:
    name = f"{c}.gs.thc.org"
    url = f"https://www.virustotal.com/api/v3/domains/{name}/resolutions?limit=40"
    req = urllib.request.Request(url, headers={"x-apikey": API_KEY})
    with urllib.request.urlopen(req, timeout=30) as res:
        data = json.load(res)["data"]
    for item in data:
        a = item["attributes"]
        day = datetime.fromtimestamp(a["date"], timezone.utc).date()
        rows.append([name, a["ip_address"], day])
with open("gsrn_relay_ips.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["name", "ip", "date_resolved"])
    w.writerows(rows)
print(len(rows), "rows,", len({r[1] for r in rows}), "unique IPs")

1つの名前につき40件まで取ります（多い名前でも8件でした）。2026年11月13日にこの例を実行すると、116行、27個のIPアドレスが出ました。StandardとEnterpriseのどちらのプランのAPIキーでも、同じ結果でした。

自組織のログと照らし合わせる

洗い出したIPアドレスと名前を、自組織のログと照らし合わせます。

ログを保存している期間の分だけ、過去の侵入にも気づけます。当たったサーバーは、GSocketが置かれていないかを、次の章の手がかりで確かめます。駆除したあとは、同じ一覧で、リレーへの通信が止まったかを確かめます。

リレーと通信したファイルから、サーバーで探す手がかりを得る

GTIのドメインの画面のRELATIONSタブでは、Communicating Files の欄で、その名前と通信したファイルを見られます。

リレーの26の名前と通信したファイルを集めると、241件ありました（2026年11月13日）。シェルスクリプトが149件、Linuxの実行ファイル（ELF）が79件です。148件はGTIの判定がMaliciousで、GTIスコアの中央値は70でした。

ファイルの名前には、Microsoft社の記事が挙げた隠し方が、そのまま出ています。カーネルのスレッドに似せた名前の多くは、GSocketの公式の導入スクリプトに、プロセス名の候補として書かれている12個の名前でした。攻撃者はファイルを作り直せるので、ファイルごとの値ではなく、隠し方の傾向をサーバーで確かめます。

241件を、GTIに初めて提出された年で分けると、2024年が22件、2025年が54件、2026年が147件（11月13日まで）でした。提出されたファイルの数なので、被害の件数ではありませんが、Microsoft社の記事が示した検知の増加と同じ向きです。

YARAルールで、作り直されたファイルも探す

ファイルの名前は簡単に変えられ、作り直せば別のファイルになります。一方、ファイルの中身に残る文字列は変えにくく、YARAルール（ファイルの中身のパターンを書いたルール）で探せます。

GSocketの公式のソースコードから文字列を取り、ルールを2つ書きました。1つは実行ファイル用で、既定のリレーの名前と、接続先を変える環境変数の名前を見ます。もう1つは導入スクリプト用で、カーネルのスレッドに似せた名前の候補を見ます。

rule GSocket_Client_Binary
{
    meta:
        description = "GSocket (gs-netcat) client: default relay domain and environment variable names"
    strings:
        $relay = "gs.thc.org" ascii
        $e1 = "GSOCKET_HOST" ascii
        $e2 = "GSOCKET_IP" ascii
        $e3 = "GSOCKET_DOMAIN" ascii
        $e4 = "GSOCKET_SOCKS_IP" ascii
    condition:
        (uint32(0) == 0x464c457f or uint32(0) == 0xfeedfacf or uint32(0) == 0xfeedface)
        and $relay and 2 of ($e*)
}
rule GSocket_Deploy_Script
{
    meta:
        description = "GSocket deploy script - kernel-thread-like process names used to hide gs-netcat"
    strings:
        $s1 = "GS_SECRET" ascii
        $s2 = "gs-netcat" ascii
        $p1 = "[kstrp]" ascii
        $p2 = "[watchdogd]" ascii
        $p3 = "[ksmd]" ascii
        $p4 = "[kswapd0]" ascii
        $p5 = "[rcu_preempt]" ascii
        $p6 = "[raid5wq]" ascii
        $p7 = "[slub_flushwq]" ascii
    condition:
        filesize < 300KB and 1 of ($s*) and 3 of ($p*)
}

このルールを、GTIのRetrohunt（過去に届いたファイルを、YARAルールでさかのぼって探す機能）にかけました。対象は過去12か月です（2026年11月13日）。

一致した144件のうち112件は、リレーの名前と通信した241件に入っていません。通信の記録がないファイルも、中身で見つかります。システムの部品に似せた名前のファイルもありました（/root/.systemd-udevd、/tmp/.systemd-eHIHoB、openssh-9.9p2-hotpatch2）。macOSの実行ファイルも20件ありました。

このルールに一致するのは、GSocketそのものです。正当な遠隔管理に使われているものも含まれるので、一致したファイルは、どこで見つかったかとあわせて判断します。

同じルールをLivehunt（これから届くファイルを、YARAルールで見張る機能）に登録しておくと、新しいファイルが一致したときに通知が届きます。Livehuntでは、ファイルの中身だけでなく、解析環境での動きも条件にできます。弊社では、解析環境でリレーの名前を名前解決したファイルに一致するルールも足しました。文字列が見えないように包まれたファイルを、動きで見つけるためです。

RetrohuntとLivehuntは、GTIのどのプランでも使えます。Retrohuntでさかのぼれる期間は、プランによって過去3か月か過去12か月です。

照らし合わせるときの注意

リレーへの通信だけでは、侵害とは決められない
リレーは誰でも使える共有の基盤で、正当な遠隔管理にも使われます。当たったら、そのサーバーで何が動いているかを確かめます。

一覧だけでは、すべては拾えない
GSocketは、接続先のリレーを環境変数で変えられ、Tor経由でもつなげます。一覧との照らし合わせは、サーバーの上での検知と組み合わせます。

判定は、名前の画面で見る
リレーのIPアドレスは入れ替わる共有の基盤なので、GTIの判定は名前のほうに付いています。IPアドレスからではなく、名前から調べます。

IPアドレスは入れ替わる
解決先は1日単位で変わることがあります。一覧は、照らし合わせるたびに作り直します。

遮断する前に、業務への影響を確かめる
リレーのIPアドレスには、別のドメインが乗っていることがあります。遮断する前に、業務の通信が含まれていないかを確かめます。

補足：Censysで、同じ運営者のサーバーをたどる

最後に、ログとの照らし合わせからは少し外れますが、調べる中で分かったことを1つ紹介します。

Censysで今のリレーのIPアドレスを引くと、7台が見つかりました。どれも、高い番号のポート（64222か54222）でSSHを開けています。そして、複数のリレーが、同じSSHのホスト鍵を使っていました。同じホスト鍵は、同じ運営者が用意したサーバーの手がかりです。

リレーの5つのホスト鍵でCensysを検索すると、9台が見つかりました（2026年11月13日）。7台は今のリレーです。残りの2台は、リレーの名前の解決先にも、GTIのパッシブDNSの履歴にも出ていません。

この2台がリレーとして使われた記録はありません。分かるのは、今のリレーと同じホスト鍵を使っている、ということだけです。それでも、リレーのIPアドレスが入れ替わるときの候補として、先に見張りに足しておけます。

Google Threat Intelligence やDomainToolsの使い方、調査への組み込み方のご相談は、お気軽にお問合せください。

お問合せはこちら

関連製品Google Threat IntelligenceGoogleの観測データ、VirusTotalに集まる検体、Mandiantが現場で得た知見を1つに束ねた脅威インテリジェンスです。Standard・Enterprise・Enterprise+の3つのプランで使える機能と上限を一覧にしています。関連製品DomainToolsIris Investigate、Iris Detect、Iris Enrich、Farsight DNSDB などの製品ごとの機能と、プラン、SIEM・SOARとの連携をまとめています。関連製品Censys Platformインターネット全体を走査したデータから、ホスト、Webサイト、証明書を検索・調査できます。製品ページでは、主な機能と、プランごとに使える機能の違い、追加オプションを紹介しています。