2026.10.08 セキュリティ

ジャパンタイムズのランサムウェア被害とグループ会社サーバー：Eclipseの犯行声明と被害を分けたインフラ設計

英字日刊紙「The Japan Times」を発行する株式会社ジャパンタイムズは2026年10月2日、グループ会社が管理するサーバーの一部が不正アクセスを受けたと公表しました。これに先立つ9月30日には、ランサムウェアグループ「Eclipse」のリークサイトに同紙の名前が載っていたと報じられています。本記事で整理するのは、会社の公式発表と攻撃者側の主張の違いです。そのうえで、電子版や決済を別のインフラで動かしていたという公表内容を手がかりに、グループ会社を含む環境で被害の範囲を分ける設計と、持ち出しの有無を確かめる手順をコマンド付きで示します。

まとめ：ジャパンタイムズの不正アクセスで公表された事実と攻撃者側の主張の区別

公式発表で確定しているのは、グループ会社が管理するサーバーの一部に不正アクセスがあったこと、情報漏えいの有無・影響範囲・原因を外部の専門業者と調べていること、電子版サービスと購読者データベースと決済システムには影響が確認されていないことの3点です。新聞の発行とWebサイトは通常どおり続いています。

Eclipseのリークサイトへの掲載は、あくまで攻撃者側の主張です。公式発表はEclipseの名前にも、データの暗号化や持ち出しにも触れていません。同じ構成を持つ組織が読み取るべき点は、グループ会社の環境と中核のシステムを分けておく設計が、被害の届く範囲を左右するということです。

項目	内容	根拠
公表日	2026年10月2日	公式
対象	グループ会社管理サーバーの一部	公式
電子版・購読者DB・決済	別インフラで影響なし	公式
新聞発行・Webサイト	通常どおり継続	公式
漏えいの有無	調査中	公式
リークサイト掲載	9月30日付でEclipseが掲載	報道
データの公開	10月4日時点で未確認	報道

公式発表で確認できる事実｜10月2日の公表文に書かれたことと書かれていないこと

グループ会社管理サーバーの不正アクセスと調査中とされた3項目

ジャパンタイムズの公表文は、不正アクセスを受けたのが「グループ会社が管理するサーバーの一部」だと記しています。情報漏えいの有無、影響範囲、原因の3項目は外部専門業者と連携して調べている段階で、調査の完了には一定の期間がかかる見込みとしました。関係機関とも連携し、セキュリティ対策の強化を進めると述べています。

公表文の本文は「不正アクセス」という語を使っており、ランサムウェアとは書いていません。ページのURLには ransomware の語が含まれていますが、暗号化の被害があったかどうかを本文から読み取ることはできません。本記事では、公式の表現を「不正アクセス」として扱います。

電子版・購読者データベース・決済システムに影響がないとされた理由

公表文は、電子版サービス「The Japan Times Online」をはじめ、各種の購読者データベースと決済システムが、対象のサーバーとは異なる独立したインフラで動いていると説明しました。そのため今回の事象による影響と安全上の問題は確認されていない、という整理です。

この一文は、購読者の情報とカード決済という、漏えいすれば影響の大きいデータを、グループ会社のサーバーとは別の環境に置いていたことを示しています。どの程度の分け方だったのか（ネットワークだけか、管理者アカウントまで別か）は公表されていません。分ける設計の点検方法は、後半の章で扱います。

グループ会社名・侵入経路・身代金要求が未公表の段階で書けないこと

グループ会社の名前、サーバーの用途、侵入経路、暗号化の有無、身代金の要求、持ち出されたデータの中身は公表されていません。ITmedia NEWSの報道も公表文の範囲にとどまっています。本記事は特定の手口に結び付けた推測をせず、グループ会社を持つ組織の点検の観点として以降を書きます。

Eclipseのリークサイト掲載と二重恐喝｜攻撃者の主張を事実と扱わない読み方

9月30日付のリークサイト掲載と10月4日時点のカウントダウン表示

セキュリティ対策Labの記事によると、Eclipseのリークサイトには9月30日付で「The Japan Times」が載り、社名、ドメイン、英文の説明、データ公開までとみられるカウントダウンが表示されていました。10月4日に確認した時点では公開済みの表示はなく、データのダウンロードもできなかったとしています。同記事は、Eclipseのリークサイト活動が2026年8月ごろから見られる新しいグループで、使うランサムウェアや侵入の手口は確定的な情報が少ないと伝えています。

リークサイトの掲載が被害の証明にならない理由と組織側の確かめ方

暗号化に加えて、盗んだデータを公開すると脅して支払いを迫る手口を二重恐喝と呼びます。リークサイトへの掲載は交渉を有利にするための宣伝でもあり、主張するデータ量や中身が誇張されている場合も、別の被害者のデータを使い回している場合もあります。掲載された組織は、主張を否定も肯定もせず、自社のログで「何が、いつ、どこへ出ていったか」を確かめることが最初の作業です。確かめ方は後半のフローログの章で示します。

警察庁の令和8年上半期の集計では、ランサムウェアの被害報告は123件でした。侵入経路の有効回答36件のうち、VPN機器が18件、リモートデスクトップが9件を占めています。被害に遭ったときの相談先はIPAのランサムウェア対策特設ページにまとまっています。

被害を電子版と決済から切り離した設計｜グループ会社の環境を分ける境界の点検

グループ会社のサーバーが侵入されても中核のシステムに届かないためには、ネットワークの経路と管理者の権限の両方が分かれていることが必要です。経路だけを分けても、同じ管理者アカウントで両方に入れるなら、攻撃者は権限を伝って移れます。経済産業省のサイバーセキュリティ経営ガイドライン Ver3.0も、サプライチェーン全体を通じた対策を経営者が指示すべき事項に挙げています。以下はAWSで両社の環境を持つ場合の点検例です。

VPCピアリングとTransit Gatewayの接続を一覧にするAWS CLI

中核システムのAWSアカウントで、他のアカウントのVPCとつながっている経路を一覧にします。VPCピアリングは別アカウントのVPCとも直接つなげるため、グループ会社の環境とつながったまま残っていないかを確かめます。どちらも読み取りだけの操作です。

# 有効なVPCピアリングを、要求側と承諾側の所有アカウントつきで一覧にする
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=active \
  --query 'VpcPeeringConnections[].[VpcPeeringConnectionId,RequesterVpcInfo.OwnerId,RequesterVpcInfo.VpcId,AccepterVpcInfo.OwnerId,AccepterVpcInfo.VpcId]' \
  --output table \
  --region ap-northeast-1

# Transit Gatewayにつながっている接続を、接続先の所有アカウントつきで一覧にする
aws ec2 describe-transit-gateway-attachments \
  --query 'TransitGatewayAttachments[].[TransitGatewayId,ResourceOwnerId,ResourceType,ResourceId,State]' \
  --output table \
  --region ap-northeast-1

出力に自社以外のアカウントIDが出たら、その経路で何の通信が必要なのかを担当者に確かめます。必要がない経路は切り、必要な経路はセキュリティグループで宛先のポートを絞ります。

IAM Access Analyzerで他アカウントから使える権限を洗い出す手順

権限の境界はIAM Access Analyzerで確かめます。分析の範囲（信頼ゾーン）をアカウントにすると、同じ組織に属するグループ会社のアカウントからのアクセスも外部として検出されます。組織単位で作ると、グループ会社からのアクセスは信頼ゾーンの内側になって見えなくなる点に注意してください。

# 中核システムのアカウントで、アカウント単位のアナライザーを作る
aws accessanalyzer create-analyzer \
  --analyzer-name core-external-access \
  --type ACCOUNT \
  --region ap-northeast-1

# 有効な検出結果（他アカウントから使えるロール・バケット・鍵など）を一覧にする
aws accessanalyzer list-findings-v2 \
  --analyzer-arn arn:aws:access-analyzer:ap-northeast-1:111122223333:analyzer/core-external-access \
  --filter '{"status":{"eq":["ACTIVE"]}}' \
  --query 'findings[].[resourceType,resource,findingType]' \
  --output table \
  --region ap-northeast-1

グループ会社のアカウントが引き受けられるIAMロールや、読み書きできるS3バケットが出てきたら、それぞれ用途と期限を確かめます。管理者のログインには多要素認証を必ず掛け、グループ会社と中核で同じ認証基盤の管理者を共用しない形にしてください。方式の選び方は多要素認証（MFA）とはで比べています。

分離を徹底すべき組織とグループ共通基盤で足りる場面の判断基準

購読者や会員の個人情報、決済、取材や顧客との取引の記録を持つ組織は、グループ会社の環境と経路も管理者も分けるべきです。ジャパンタイムズの公表文が影響なしと言い切れたのは、この分け方が前提にあったからだと読めます。

逆に、グループ会社のサーバーが社内の掲示や検証の環境だけで、中核のデータに触れないなら、共通基盤のまま運用してもかまいません。その場合も管理者アカウントの共用は避け、ログを一か所に集めて見られる状態にしておきます。判断の分かれ目は、グループ会社のサーバーから中核のデータに一つの権限で届くかどうかです。

持ち出しの有無を確かめる｜VPCフローログで外向き通信の量を集計する手順

CloudWatch Logs Insightsで送信量の多い宛先を上位20件出すクエリ

リークサイトに名前が載ったとき、最初に確かめるのは大量の外向き通信があったかどうかです。VPCフローログをCloudWatch Logsに送っていれば、Logs Insightsのクエリで送信元と宛先ごとのバイト数を集計できます。

# 直近14日間で、社内の範囲（ここでは10.0.0.0/8）以外へ送ったバイト数の多い組み合わせを出す
QID=$(aws logs start-query \
  --log-group-name /vpc/core-flow-logs \
  --start-time $(date -d '14 days ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'filter action = "ACCEPT" and not isIpv4InSubnet(dstAddr, "10.0.0.0/8")
| stats sum(bytes) as sentBytes by srcAddr, dstAddr
| sort sentBytes desc
| limit 20' \
  --query queryId --output text \
  --region ap-northeast-1)

# 数秒待ってから結果を取り出す
aws logs get-query-results --query-id "$QID" --region ap-northeast-1

社内の範囲は自社のVPCのアドレス帯に合わせて書き換えてください。上位に出た宛先のうち、バックアップ先やCDNなど用途が分かるものを外し、残った宛先の通信が始まった時刻をサーバーのログと突き合わせます。ログの読み方は不正アクセスのログ確認・解析方法にまとめています。

フローログを取っていない環境が侵入後に後から調べられない事柄

フローログは有効にした時点からしか記録されず、さかのぼって取ることはできません。取っていなかった環境では、何がどこへ出ていったかを示す材料がサーバー側のログだけになり、それも攻撃者に消されていれば確かめようがありません。漏えいの有無が「調査中」のまま長引く事案が多いのは、この材料の不足が一因です。中核とグループ会社の両方で、フローログの保存期間を最低90日にしておくことを勧めます。

なりすましメールへの備え｜グループ各社のドメインをDMARCで揃える手順

公表文は、同社やグループを装った不審なメールや電話への注意を呼びかけています。受け取る側の注意に頼るだけでなく、送る側のドメインでなりすましを拒否させる設定がDMARCです。本体のドメインだけ設定し、グループ会社のドメインが未設定のまま残っている例は少なくありません。

# 現在のDMARCレコードを確かめる（Linux・macOS）
dig +short TXT _dmarc.example.co.jp

# Windows PowerShellの場合
Resolve-DnsName -Type TXT -Name _dmarc.example.co.jp

# 公開するレコードの例（グループ各社のドメインでも同じ方針で揃える）
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject"

2026年5月に公開されたRFC 9989は、存在しないサブドメインに対する方針を示す np タグを正式に取り込みました。攻撃者は実在しないサブドメインを名乗ることがあるため、np=reject まで書いておきます。集計レポートの送付先（rua）も足し、正規の送信元がすべて認証を通っているのを確かめてから p=reject に上げてください。段階的な移行は pct タグが廃止されたため t=y（試験中の表示）で行います。仕組みの全体を解説した記事はDMARCの仕組みです。正規のアカウントが乗っ取られて送られるメールはDMARCを通ってしまうため、その場合の調査は兄弟記事の日経の不正アクセスとなりすましメール約9,000件で扱っています。

報道機関・出版社が点検する順番｜取材情報の置き場所と報告・第三者の診断

グループ会社を含めた4項目の点検で今月中に済ませられる確認作業

報道機関や出版社は、購読者の情報に加えて、取材先の連絡先や未公開の原稿のように外に出れば取り返しのつかない情報を持っています。点検は次の4項目から始めます。

取材先の連絡先・原稿・契約書がどのグループ会社のどのサーバーに置かれているかを一覧にする
前章のCLIで、中核のアカウントと他のアカウントを結ぶ経路と権限を洗い出し、用途の分からないものを止める
中核とグループ会社の両方でフローログを有効にし、保存期間を90日以上にする
グループ各社のドメインのDMARCレコードを確かめ、未設定のドメインを残さない

1と4は設定の確認だけなので、予算をかけずに今月中に済ませられる作業です。出版社が被害に遭った事例として、データセンターのサーバー群が止まり復旧に2か月を要したニコニコ動画（KADOKAWA）へのサイバー攻撃や、アカウントの侵害から流出した講談社の個人情報流出3,812件があります。初動を担う体制の作り方はCSIRT（シーサート）とはで、戻す手段の方式はシステムバックアップとはで整理しています。

個人情報の漏えいのおそれがあるときの報告と第三者の診断を入れる時期

不正の目的をもった行為による個人データの漏えいのおそれがあれば、件数に関係なく個人情報保護委員会への報告の対象になり、速報は発覚から3〜5日以内に出します。類型と期限は個人情報保護委員会への報告義務で解説しています。

4項目を見直しても、グループ会社を含めた外からの入口の全体と、侵入されたときに中核のデータまで届く経路を自社で説明できない場合は、第三者の目を入れる時期です。脆弱性診断・セキュリティ診断では、公開しているVPN機器やWebシステムから中核のサーバーに至る経路を含めて点検できます。

よくある質問

ジャパンタイムズの不正アクセスについて、読者と情報システムの担当者から出やすい質問をまとめました。

ジャパンタイムズの不正アクセスでは何が起きたのですか？

2026年10月2日の公表によると、グループ会社が管理するサーバーの一部が不正アクセスを受けました。情報漏えいの有無、影響範囲、原因は外部の専門業者と調査中です。新聞の発行とWebサイトは通常どおり続いています。

Eclipseとはどのようなランサムウェアグループですか？

報道によると、2026年8月ごろからリークサイトの活動が見られる新しいグループです。9月30日付でThe Japan Timesを掲載し、データ公開までとみられるカウントダウンを表示していました。使うランサムウェアや侵入の手口は確定的な情報が少なく、ジャパンタイムズの公式発表もEclipseには触れていません。

電子版の購読者の情報やカード情報は漏えいしたのですか？

公式発表では、電子版サービス、各種の購読者データベース、決済システムは対象サーバーとは別のインフラで動いており、影響は確認されていないとしています。2026年10月8日時点で続報は確認できていません。

ジャパンタイムズを名乗るメールが届いた場合はどうすればよいですか？

同社は、同社やグループを装った不審なメールや電話が届くおそれがあるとして、心当たりのない送信元のメールや不審な添付ファイル・URLは開かずに削除するよう呼びかけています。気になる連絡は、メールのリンクではなく公式サイトを自分で開いて確かめてください。

グループ会社のサーバーから本体に被害が広がるのを防ぐには何をすればよいですか？

ネットワークの経路と管理者の権限の両方を分けることです。AWSであれば、VPCピアリングとTransit Gatewayの接続を一覧にし、IAM Access Analyzerをアカウント単位で作って他アカウントから使える権限を洗い出します。あわせて、持ち出しを後から確かめられるようにフローログを残しておきます。