--- title: "ジャパンタイムズのランサムウェア被害とグループ会社サーバー：Eclipseの犯行声明と被害を分けたインフラ設計" url: "https://www.issoh.co.jp/tech/details/18191/" published: 2026-10-08 updated: 2026-10-09 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ジャパンタイムズのランサムウェア被害とグループ会社サーバー：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項目 ジャパンタイムズの[公表文](https://www.japantimes.co.jp/press/2026/10/02/noticeransomware-incident-jp/)は、不正アクセスを受けたのが「グループ会社が管理するサーバーの一部」だと記しています。情報漏えいの有無、影響範囲、原因の3項目は外部専門業者と連携して調べている段階で、調査の完了には一定の期間がかかる見込みとしました。関係機関とも連携し、セキュリティ対策の強化を進めると述べています。 公表文の本文は「不正アクセス」という語を使っており、ランサムウェアとは書いていません。ページのURLには ransomware の語が含まれていますが、暗号化の被害があったかどうかを本文から読み取ることはできません。本記事では、公式の表現を「不正アクセス」として扱います。 ### 電子版・購読者データベース・決済システムに影響がないとされた理由 公表文は、電子版サービス「The Japan Times Online」をはじめ、各種の購読者データベースと決済システムが、対象のサーバーとは異なる独立したインフラで動いていると説明しました。そのため今回の事象による影響と安全上の問題は確認されていない、という整理です。 この一文は、購読者の情報とカード決済という、漏えいすれば影響の大きいデータを、グループ会社のサーバーとは別の環境に置いていたことを示しています。どの程度の分け方だったのか（ネットワークだけか、管理者アカウントまで別か）は公表されていません。分ける設計の点検方法は、後半の章で扱います。 ### グループ会社名・侵入経路・身代金要求が未公表の段階で書けないこと グループ会社の名前、サーバーの用途、侵入経路、暗号化の有無、身代金の要求、持ち出されたデータの中身は公表されていません。[ITmedia NEWSの報道](https://www.itmedia.co.jp/news/article/2610/02/2000001975/)も公表文の範囲にとどまっています。本記事は特定の手口に結び付けた推測をせず、グループ会社を持つ組織の点検の観点として以降を書きます。 ## Eclipseのリークサイト掲載と二重恐喝｜攻撃者の主張を事実と扱わない読み方 ### 9月30日付のリークサイト掲載と10月4日時点のカウントダウン表示 [セキュリティ対策Labの記事](https://rocket-boys.co.jp/security-measures-lab/japan-times-eclipse-ransomware-claim-unauthorized-access/)によると、Eclipseのリークサイトには9月30日付で「The Japan Times」が載り、社名、ドメイン、英文の説明、データ公開までとみられるカウントダウンが表示されていました。10月4日に確認した時点では公開済みの表示はなく、データのダウンロードもできなかったとしています。同記事は、Eclipseのリークサイト活動が2026年8月ごろから見られる新しいグループで、使うランサムウェアや侵入の手口は確定的な情報が少ないと伝えています。 ### リークサイトの掲載が被害の証明にならない理由と組織側の確かめ方 暗号化に加えて、盗んだデータを公開すると脅して支払いを迫る手口を二重恐喝と呼びます。リークサイトへの掲載は交渉を有利にするための宣伝でもあり、主張するデータ量や中身が誇張されている場合も、別の被害者のデータを使い回している場合もあります。掲載された組織は、主張を否定も肯定もせず、自社のログで「何が、いつ、どこへ出ていったか」を確かめることが最初の作業です。確かめ方は後半のフローログの章で示します。 [警察庁の令和8年上半期の集計](https://www.npa.go.jp/news/release/2026/20260909001.html)では、ランサムウェアの被害報告は123件でした。侵入経路の有効回答36件のうち、VPN機器が18件、リモートデスクトップが9件を占めています。被害に遭ったときの相談先は[IPAのランサムウェア対策特設ページ](https://www.ipa.go.jp/security/anshin/measures/ransom%5Ftokusetsu.html)にまとまっています。 ## 被害を電子版と決済から切り離した設計｜グループ会社の環境を分ける境界の点検 グループ会社のサーバーが侵入されても中核のシステムに届かないためには、ネットワークの経路と管理者の権限の両方が分かれていることが必要です。経路だけを分けても、同じ管理者アカウントで両方に入れるなら、攻撃者は権限を伝って移れます。[経済産業省のサイバーセキュリティ経営ガイドライン Ver3.0](https://www.meti.go.jp/policy/netsecurity/mng%5Fguide.html)も、サプライチェーン全体を通じた対策を経営者が指示すべき事項に挙げています。以下はAWSで両社の環境を持つ場合の点検例です。 ### VPCピアリングとTransit Gatewayの接続を一覧にするAWS CLI 中核システムのAWSアカウントで、他のアカウントのVPCとつながっている経路を一覧にします。[VPCピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)は別アカウントの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](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)で確かめます。分析の範囲（信頼ゾーン）をアカウントにすると、同じ組織に属するグループ会社のアカウントからのアクセスも外部として検出されます。組織単位で作ると、グループ会社からのアクセスは信頼ゾーンの内側になって見えなくなる点に注意してください。 ``` # 中核システムのアカウントで、アカウント単位のアナライザーを作る 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）とは](https://www.issoh.co.jp/tech/details/13314/)で比べています。 ### 分離を徹底すべき組織とグループ共通基盤で足りる場面の判断基準 購読者や会員の個人情報、決済、取材や顧客との取引の記録を持つ組織は、グループ会社の環境と経路も管理者も分けるべきです。ジャパンタイムズの公表文が影響なしと言い切れたのは、この分け方が前提にあったからだと読めます。 逆に、グループ会社のサーバーが社内の掲示や検証の環境だけで、中核のデータに触れないなら、共通基盤のまま運用してもかまいません。その場合も管理者アカウントの共用は避け、ログを一か所に集めて見られる状態にしておきます。判断の分かれ目は、グループ会社のサーバーから中核のデータに一つの権限で届くかどうかです。同時期の京王グループの事案では、共通のポイント基盤などへの依存から複数社の決済と予約が止まりました。依存関係から止まる業務を数える手順は[京王電鉄のランサムウェア被害とグループ共通基盤](https://www.issoh.co.jp/tech/details/18201/)で扱っています。 ## 持ち出しの有無を確かめる｜VPCフローログで外向き通信の量を集計する手順 ### CloudWatch Logs Insightsで送信量の多い宛先を上位20件出すクエリ リークサイトに名前が載ったとき、最初に確かめるのは大量の外向き通信があったかどうかです。[VPCフローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)をCloudWatch Logsに送っていれば、[Logs Insightsのクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL%5FQuerySyntax.html)で送信元と宛先ごとのバイト数を集計できます。 ``` # 直近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など用途が分かるものを外し、残った宛先の通信が始まった時刻をサーバーのログと突き合わせます。ログの読み方は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)にまとめています。 ### フローログを取っていない環境が侵入後に後から調べられない事柄 フローログは有効にした時点からしか記録されず、さかのぼって取ることはできません。取っていなかった環境では、何がどこへ出ていったかを示す材料がサーバー側のログだけになり、それも攻撃者に消されていれば確かめようがありません。漏えいの有無が「調査中」のまま長引く事案が多いのは、この材料の不足が一因です。中核とグループ会社の両方で、フローログの保存期間を最低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](https://www.rfc-editor.org/rfc/rfc9989.html)は、存在しないサブドメインに対する方針を示す `np` タグを正式に取り込みました。攻撃者は実在しないサブドメインを名乗ることがあるため、`np=reject` まで書いておきます。集計レポートの送付先（`rua`）も足し、正規の送信元がすべて認証を通っているのを確かめてから `p=reject` に上げてください。段階的な移行は `pct` タグが廃止されたため `t=y`（試験中の表示）で行います。仕組みの全体を解説した記事は[DMARCの仕組み](https://www.issoh.co.jp/tech/details/12267/)です。正規のアカウントが乗っ取られて送られるメールはDMARCを通ってしまうため、その場合の調査は兄弟記事の[日経の不正アクセスとなりすましメール約9,000件](https://www.issoh.co.jp/tech/details/18189/)で扱っています。 ## 報道機関・出版社が点検する順番｜取材情報の置き場所と報告・第三者の診断 ### グループ会社を含めた4項目の点検で今月中に済ませられる確認作業 報道機関や出版社は、購読者の情報に加えて、取材先の連絡先や未公開の原稿のように外に出れば取り返しのつかない情報を持っています。点検は次の4項目から始めます。 1. 取材先の連絡先・原稿・契約書がどのグループ会社のどのサーバーに置かれているかを一覧にする 2. 前章のCLIで、中核のアカウントと他のアカウントを結ぶ経路と権限を洗い出し、用途の分からないものを止める 3. 中核とグループ会社の両方でフローログを有効にし、保存期間を90日以上にする 4. グループ各社のドメインのDMARCレコードを確かめ、未設定のドメインを残さない 1と4は設定の確認だけなので、予算をかけずに今月中に済ませられる作業です。出版社が被害に遭った事例として、データセンターのサーバー群が止まり復旧に2か月を要した[ニコニコ動画（KADOKAWA）へのサイバー攻撃](https://www.issoh.co.jp/column/details/2807/)や、アカウントの侵害から流出した[講談社の個人情報流出3,812件](https://www.issoh.co.jp/tech/details/16099/)があります。初動を担う体制の作り方は[CSIRT（シーサート）とは](https://www.issoh.co.jp/column/details/10174/)で、戻す手段の方式は[システムバックアップとは](https://www.issoh.co.jp/column/details/13448/)で整理しています。 ### 個人情報の漏えいのおそれがあるときの報告と第三者の診断を入れる時期 不正の目的をもった行為による個人データの漏えいのおそれがあれば、件数に関係なく個人情報保護委員会への報告の対象になり、速報は発覚から3〜5日以内に出します。類型と期限は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で解説しています。 4項目を見直しても、グループ会社を含めた外からの入口の全体と、侵入されたときに中核のデータまで届く経路を自社で説明できない場合は、第三者の目を入れる時期です。[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)では、公開している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をアカウント単位で作って他アカウントから使える権限を洗い出します。あわせて、持ち出しを後から確かめられるようにフローログを残しておきます。 ## 関連記事 - [日経の不正アクセスとなりすましメール約9,000件｜M365・Google Workspace乗っ取りの調査手順](https://www.issoh.co.jp/tech/details/18189/)：同時期の報道機関の事案（業務SaaSアカウント） - [大阪公立大学のランサムウェア被害と仮想化基盤の停止｜全授業休講に至った経緯とバックアップを守る設定](https://www.issoh.co.jp/tech/details/18178/)：消せないバックアップの設定 - [佐賀大学のランサムウェア被害と事務NASの暗号化｜4日で業務再開した初動と戻せるバックアップ](https://www.issoh.co.jp/tech/details/18097/)：初動と業務再開の事例 - [楽天ドライブの不正アクセスと保存データ1.5万件の流出｜管理用アカウントを守る認証と検知](https://www.issoh.co.jp/tech/details/18187/)：管理用アカウントを起点にした事案 - [アスクルのランサムウェア攻撃｜流出74万件と追加60万件・行政指導・全面復旧までの経緯](https://www.issoh.co.jp/tech/details/10261/)：調査中から流出件数が確定するまでの経過 --- 出典: [ジャパンタイムズのランサムウェア被害とグループ会社サーバー：Eclipseの犯行声明と被害を分けたインフラ設計]()（株式会社一創）