【セキュリティ事件簿#2025-376】オークマ株式会社 連結子会社におけるランサムウェア被害の発生および情報漏えいの可能性に関するお知らせ 2025/9/25

 

このたび、当社の連結子会社であるドイツの Okuma Europe GmbH(以下、「OEG 社」)のサーバーが第三者よる不正アクセスを受け、ランサムウェア感染被害が発生し、OEG 社が管理している従業員等の個人情報および機密情報が一部外部へ漏えいした可能性があることが判明いたしました。

本件につきましては、外部専門家の支援を受け、感染被害の範囲等の調査と早期復旧への対応を進めるとともに、現地の警察等関係機関への相談も実施しております。

被害の全容、原因の把握には、今暫く時間を要する見込みです。

このたびは、お客様および関係者の皆様には多大なるご心配とご迷惑をお掛けしますことを深くお詫び申し上げます。

1.不正アクセス発覚の経緯

2025 年9月 20 日(土)、OEG 社のサーバーに対する不正アクセスが発生し、サーバーに保存している各種ファイルが暗号化されていることを確認いたしました。

2.現在の状況と今後の対応

現在、外部専門家の協力のもと、原因究明と再発防止策の検討を進めており、情報漏えいにつきましても調査を継続しております。当社は、お客様および関係者の皆様へのご迷惑を最小限に抑えるべく取り組んでまいります。

なお、OEG 社およびその子会社を除き、当社および当社グループ会社には本件による影響は確認されておりません。

3.業績への影響

本件が当社グループの業績に及ぼす影響については精査中です。今後、業績に重大な影響があると判断した場合は速やかに公表いたします。

リリース文アーカイブ

【セキュリティ事件簿#2025-374】中央大学 不正アクセスによる個人情報流出に関するお詫びとお知らせ 2025/9/19

 このたび、本学の教員が利用するメールサーバの一つで、2名の教員のIDが不正に利用され、その結果、該当の教員にメールを送信された方のメールアドレスや氏名が、第三者に不正に取得された可能性があることがわかりました。

関係者の皆様には、多大なるご迷惑とご心配をおかけしますことを深くお詫び申し上げます。

この件は、限られた2名の教員に影響があったもので、本学のすべての教員とメールのやりとりをされた方に影響が及ぶものではありません。影響を受ける可能性のある方には、中央大学情報管理部・情報環境整備センターから個別にメールでご連絡をしますので、ご確認ください。

本学では、このような事態が再発しないよう、セキュリティ対策を一層強化してまいります。

流出した可能性のある個人情報 / Potentially leaked personal information

過去に tamacc.chuo-u.ac.jpドメイン上にアカウントを有する、ある特定の教員にメールを送信された方の下記の情報 (最大流出件数 教員A: 692名、教員B: 390名)

・差出人のmail address 

・氏名または表示名(差出人として記載がある場合)

メールのインデックス情報が第三者に不正に取得された可能性がある期間は次の通りとなります。

教員A 2025年7月19日 23:09pm (JST)までに送信されたメール

教員B 2025年7月23日 04:58am (JST)までに送信されたメール

原因

本学の教員用メールサーバ(ドメイン tamacc.chuo-u.ac.jp)において、ある専任教員のアカウントが不正に使用され、その時点でメールサーバに保存されたメールのインデックスが取得された可能性が発生いたしました。

二次被害の可能性

メールの差出人情報を使い、標的型攻撃メールに利用される恐れがあります。そのため、不審なメールには十分ご注意ください。

リリース文アーカイブ

【TryHackMeウォークスルー】Networking Essentials

 

Introduction

パソコンを起動したり新しいネットワークに接続したとき、どのようにしてネットワーク設定が自動的に構成されるのか、不思議に思ったことはありませんか?

自分の送ったパケットが目的地に届くまでに、いくつの機器や国を経由しているのか知りたいと思ったことはありませんか?
インターネット回線業者(ISP)から割り当てられるIPアドレスは1つなのに、なぜ自宅のすべての機器がインターネットに接続できるのか気になりませんか?

こうした疑問に答えるのが、このルームです。

このルームは、コンピュータネットワーキングに関する4部構成のシリーズのうち、2番目にあたります。


学習前提知識

このルームを有効に活用するためには、以下の知識を持っていることを推奨します。

  • ISO OSIモデルと各レイヤー

  • TCP/IPモデルと各レイヤー

  • Ethernet、IP、TCPといったプロトコル

言い換えれば、「Networking Concepts」を終えてから取り組むのが理想的です。


学習目標

このルームの目的は、ネットワークをつなぎ合わせる標準的なプロトコルや技術を学ぶことです。

  • DHCP(Dynamic Host Configuration Protocol)

  • ARP(Address Resolution Protocol)

  • NAT(Network Address Translation)

  • ICMP(Internet Control Message Protocol)

  • Ping

  • Traceroute


DHCP: Give Me My Network Settings

お気に入りのカフェに行き、ホットドリンクを手に取り、ノートPCを開いたとしましょう。
するとノートPCはカフェのWiFiに接続し、自動的にネットワーク設定が行われ、そのままTryHackMeの新しいルームに取り組めるようになります。
IPアドレスを手入力したわけでもないのに、デバイスはすでに準備完了。さて、どうしてこんなことが可能なのでしょうか?


ネットワーク接続に必要な基本情報

どんなネットワークにアクセスする場合でも、最低限以下の設定が必要です。

  • IPアドレスとサブネットマスク

  • ルーター(ゲートウェイ)

  • DNSサーバ

新しいネットワークに接続するたびに、これらの設定を環境に合わせて変更しなければなりません。
サーバのように固定的に動く機器では手動設定が好ましい場合もあります。例えば、ドメインコントローラをカフェのWiFiに持ち込んで接続するようなことは普通しませんし、サーバは他の機器から固定のIPで参照される必要があるからです。


自動設定のメリット

接続された機器を自動的に設定できる仕組みには大きな利点があります。

  1. 手動設定の手間を省ける(特にモバイル端末にとって重要)

  2. IPアドレスの重複(コンフリクト)を避けられる

もし同じIPアドレスが複数の機器に割り当てられると、通信ができなくなってしまいます。これを防ぐ仕組みこそが DHCP(Dynamic Host Configuration Protocol) です。

DHCPはアプリケーション層のプロトコルで、UDPを利用します。

  • サーバは UDP 67番ポート で待機

  • クライアントは UDP 68番ポート から送信

スマートフォンやノートPCは、デフォルトでDHCPを使うよう設定されています。


DHCPの基本手順「DORA」

DHCPは4つのステップから成り立ちます。

  1. Discover: クライアントがDHCPDISCOVERメッセージをブロードキャストし、利用可能なDHCPサーバを探す

  2. Offer: サーバがDHCPOFFERメッセージを送り、クライアントに利用可能なIPを提示する

  3. Request: クライアントがDHCPREQUESTメッセージを返し、提示されたIPを受け入れる意思を示す

  4. Acknowledge: サーバがDHCPACKメッセージを送り、クライアントへの割り当てを確定する

例:
ノートPC → DHCP Discover
サーバ → DHCP Offer
ノートPC → DHCP Request
サーバ → DHCP Acknowledge


パケットキャプチャ例

次のキャプチャでは、クライアントが 192.168.66.133 を割り当てられる様子が確認できます。

Terminal
user@TryHackMe$ tshark -r DHCP-G5000.pcap -n
    1   0.000000      0.0.0.0 → 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xfb92d53f
    2   0.013904 192.168.66.1 → 192.168.66.133 DHCP 376 DHCP Offer    - Transaction ID 0xfb92d53f
    3   4.115318      0.0.0.0 → 255.255.255.255 DHCP 342 DHCP Request  - Transaction ID 0xfb92d53f
    4   4.228117 192.168.66.1 → 192.168.66.133 DHCP 376 DHCP ACK      - Transaction ID 0xfb92d53f

ここで重要なのは:

  • DiscoverRequest の段階では、クライアントはまだIPを持っていないため、0.0.0.0 から 255.255.255.255 へ送信している。

  • リンク層ではブロードキャストMACアドレス ff:ff:ff:ff:ff:ff が使われる。

  • サーバはDHCPOFFERで利用可能なIPアドレスとネットワーク設定を提示し、クライアントのMACアドレス宛に送信する。


DHCPで得られる情報

DHCPによって最終的にデバイスは、ネットワークやインターネットにアクセスするための必要な設定をすべて取得します。

  • 割り当てられたIPアドレス

  • ネットワーク外へのルーティングに使うゲートウェイ

  • ドメイン名解決のためのDNSサーバ(後で詳述)

Answer the questions below

How many steps does DHCP use to provide network configuration?

4

What is the destination IP address that a client uses when it sends a DHCP Discover packet?

255.255.255.255

What is the source IP address a client uses when trying to get IP network configuration over DHCP?

0.0.0.0


ARP: Bridging Layer 3 Addressing to Layer 2 Addressing

Networking Concepts のルームで学んだ通り、2台のホストがネットワーク上で通信する際、IPパケットはデータリンク層のフレームにカプセル化されてレイヤー2を通過します。
私たちがよく使うデータリンク層の技術は Ethernet (IEEE 802.3)WiFi (IEEE 802.11) です。

同じEthernetやWiFi上でホスト同士が通信する際には、IPパケットをデータリンク層のフレームに載せて送る必要があります。ターゲットのIPアドレスは分かっていても、正しいデータリンク層ヘッダーを作成するには 相手のMACアドレス を調べる必要があります。

MACアドレスのおさらい

MACアドレスは48ビットの番号で、通常は16進数で表されます。
例:7C:DF:A1:D3:8C:5C44:DF:65:D8:FE:6C

ただし、同じEthernet上の機器が常にお互いのMACアドレスを知っている必要はありません。実際に通信を行うときに初めてMACアドレスを解決すれば十分です。

MACアドレスが必要になるシナリオ

デバイスをネットワークに接続すると、DHCPサーバがあれば自動的にゲートウェイやDNSサーバが設定されます。
この時点で、デバイスはDNSサーバやルーターの IPアドレス は知っていますが、MACアドレス は分かっていません。
しかし、同じLAN(EthernetやWiFi)上で実際に通信するには、MACアドレスの解決が必要です。

Ethernetフレームの構造

IPパケットはEthernetフレームにカプセル化されます。Ethernetヘッダーには次が含まれます。

  • 宛先MACアドレス

  • 送信元MACアドレス

  • タイプ(ここではIPv4)


ARPの仕組み

Address Resolution Protocol (ARP) は、Ethernet上で他の機器のMACアドレスを見つける仕組みです。

例:192.168.66.89192.168.66.1 と通信したい場合

  1. 192.168.66.89ff:ff:ff:ff:ff:ffARP Request を送信(「192.168.66.1 は誰?」)

  2. 192.168.66.1192.168.66.89ARP Reply を送信(自分のMACアドレスを通知)

これで双方が相手のMACアドレスを把握し、データリンク層フレームを交換できます。

パケットキャプチャ例(tshark)

Terminal
user@TryHackMe$ tshark -r arp.pcapng -Nn
    1 0.000000000 cc:5e:f8:02:21:a7 → ff:ff:ff:ff:ff:ff ARP 42 Who has 192.168.66.1? Tell 192.168.66.89
    2 0.003566632 44:df:65:d8:fe:6c → cc:5e:f8:02:21:a7 ARP 42 192.168.66.1 is at 44:df:65:d8:fe:6c

パケットキャプチャ例(tcpdump)

Terminal
user@TryHackMe$ tcpdump -r arp.pcapng -n -v
17:23:44.506615 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.66.1 tell 192.168.66.89, length 28
17:23:44.510182 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.66.1 is-at 44:df:65:d8:fe:6c, length 28

ARPのレイヤー位置

ARPメッセージはUDPやIP内ではなく、直接Ethernetフレーム に格納されます。
MACを扱うので「レイヤー2」とみなされますが、IP通信を支援する観点から「レイヤー3の一部」と捉える見解もあります。
重要なのは、ARPが レイヤー3のアドレス(IP)をレイヤー2のアドレス(MAC)へ対応付ける 役割を果たす点です。


Answer the questions below

What is the destination MAC address used in an ARP Request?

ff:ff:ff:ff:ff:ff 

In the example above, what is the MAC address of 192.168.66.1?

44:df:65:d8:fe:6c


ICMP: Troubleshooting Networks

Internet Control Message Protocol(ICMP) は主にネットワーク診断とエラー報告に使われます。ネットワークのトラブルシューティングやセキュリティでよく使われる代表的なコマンドが2つあり、どちらもICMPに依存しています。

  • ping:ターゲットへの接続確認と往復遅延(RTT)計測に使う。ターゲットが生きているか、返答が自分の端末まで届くかを確認できる。

  • traceroute / tracert:Linux/UNIX系では traceroute、Windowsでは tracert。ホストからターゲットまでの経路(経由するルーター群)を発見するのに使う。


Ping

ping は ICMP Echo Request(ICMP Type 8)を送信し、

相手は ICMP Echo Reply(ICMP Type 0)で応答します。これにより到達可否と往復遅延を測れます。WiresharkではICMPエコー要求/応答が IP パケット内に表示されます。

しかし、応答が得られない理由は複数あります:ターゲットがシャットダウンしている、あるいは経路上のファイアウォールがICMPをブロックしている、などです。下例では -c 4 で4回送信して停止しています。

Terminal
user@TryHackMe$ ping 192.168.11.1 -c 4
PING 192.168.11.1 (192.168.11.1) 56(84) bytes of data.
64 bytes from 192.168.11.1: icmp_seq=1 ttl=63 time=11.2 ms
64 bytes from 192.168.11.1: icmp_seq=2 ttl=63 time=3.81 ms
64 bytes from 192.168.11.1: icmp_seq=3 ttl=63 time=3.99 ms
64 bytes from 192.168.11.1: icmp_seq=4 ttl=63 time=23.4 ms

--- 192.168.11.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 3.805/10.596/23.366/7.956 ms

出力からはパケット損失の有無や RTT の最小/平均/最大/標準偏差が分かります。


Traceroute

ルータ群を一つずつあぶり出すには、IPヘッダの TTL(Time-to-Live) フィールドを利用します。TTL は「経由できるルータの最大数(ホップ数)」を示し、ルータはパケットを転送する前に TTL を1減らします。TTL が 0 になったパケットはそのルータで破棄され、ルータは ICMP Time Exceeded(ICMP Type 11) を送ってくれます。これを利用して、各ホップのルータから応答を引き出していくのが traceroute の仕組みです。(ここでの “time” は秒ではなくホップ数を意味します。)

ただし、すべてのルータが応答するわけではありません。応答を返さない(ICMP をブロックしている)ルータも存在します。また、ISP 内部のプライベートIPを返すルータや、応答として公開IPを表示するルータがあり、その場合はドメイン名の逆引きや地理的な手がかりを得られることがあります。もちろん、ICMP 自体がブロックされると Time Exceeded が届かないため経路が分からない場合もあります。

下は traceroute example.com の実行例です。* * * はそのホップで応答が得られなかったことを示します。経路はコマンドを再実行するたびに変わる可能性があります。

Terminal
user@TryHackMe$ traceroute example.com
traceroute to example.com (93.184.215.14), 30 hops max, 60 byte packets
 1  _gateway (192.168.66.1)  4.414 ms  4.342 ms  4.320 ms
 2  192.168.11.1 (192.168.11.1)  5.849 ms  5.830 ms  5.811 ms
 3  100.104.0.1 (100.104.0.1)  11.130 ms  11.111 ms  11.093 ms
 4  10.149.1.45 (10.149.1.45)  6.156 ms  6.138 ms  6.120 ms
 5  * * *
 6  * * *
 7  * * *
 8  172.16.48.1 (172.16.48.1)  5.667 ms  8.165 ms  6.861 ms
 9  ae81.edge4.Marseille1.Level3.net (212.73.201.45)  50.811 ms  52.857 ms 213.242.116.233 (213.242.116.233)  52.798 ms
10  NTT-level3-Marseille1.Level3.net (4.68.68.150)  93.351 ms  79.897 ms  79.804 ms
11  ae-9.r20.parsfr04.fr.bb.gin.ntt.net (129.250.3.38)  62.935 ms  62.908 ms  64.313 ms
12  ae-14.r21.nwrknj03.us.bb.gin.ntt.net (129.250.4.194)  141.816 ms  141.782 ms  141.757 ms
13  ae-1.a02.nycmny17.us.bb.gin.ntt.net (129.250.3.17)  145.786 ms ae-1.a03.nycmny17.us.bb.gin.ntt.net (129.250.3.128)  141.701 ms  147.586 ms
14  ce-0-3-0.a02.nycmny17.us.ce.gin.ntt.net (128.241.1.14)  148.692 ms ce-3-3-0.a03.nycmny17.us.ce.gin.ntt.net (128.241.1.90)  141.615 ms ce-0-3-0.a02.nycmny17.us.ce.gin.ntt.net (128.241.1.14)  148.168 ms
15  ae-66.core1.nyd.edgecastcdn.net (152.195.69.133)  141.100 ms ae-65.core1.nyd.edgecastcdn.net (152.195.68.133)  140.360 ms ae-66.core1.nyd.edgecastcdn.net (152.195.69.133)  140.638 ms
16  93.184.215.14 (93.184.215.14)  140.574 ms  140.543 ms  140.514 ms
17  93.184.215.14 (93.184.215.14)  140.488 ms  139.397 ms  141.854 ms

補足メモ

  • セキュリティ面:ICMPは診断に有用ですが、攻撃者による情報収集(ネットワーク探索やDoSの補助)にも使われるため、ファイアウォールで制御することが多いです。

  • オプションtraceroute はプロトコル(ICMP / UDP / TCP)、パケットサイズ、最大ホップ数など多くのオプションを持ち、状況に応じて使い分けられます(例:ファイアウォールでICMPがブロックされている場合はTCPトレーサートを試す等)。

Answer the questions below

Using the example images above, how many bytes were sent in the echo (ping) request?

40

Which IP header field does the traceroute command require to become zero?

TTL


Routing

下記のネットワーク図を考えてみましょう。わずか3つのネットワークしかありませんが、インターネットはどのようにして Network 1 から Network 2 や Network 3 にパケットを届けるのでしょうか? これは単純化した図ですが、Network 1 と Network 2・3 を相互に接続するにはアルゴリズムが必要になります。



複雑なネットワークにおける経路選択

実際のインターネットは何百万ものルーターと何十億ものデバイスから成り立っています。下記の例はインターネットのごく一部を示したものです。
モバイルユーザーがWebサーバに到達できるのは、経路上の各ルーターが適切なリンクを選んでパケットを転送するからです。

もちろん、モバイルユーザーからWebサーバに至る経路は複数存在します。そのため、ルーターには「どのリンクを使うか」を判断するための ルーティングアルゴリズム が必要です。




代表的なルーティングプロトコル

このルームの範囲外なのでアルゴリズムの詳細は扱いませんが、代表的なルーティングプロトコルを紹介しておきます。

  • OSPF(Open Shortest Path First)
    ネットワークトポロジーの情報をルーター同士で共有し、最も効率的な経路を計算するプロトコル。ルーターはリンクやネットワークの状態を更新し合うことで全体の地図を持ち、最適な経路を判断できます。

  • EIGRP(Enhanced Interior Gateway Routing Protocol)
    Cisco独自のプロトコルで、複数のルーティング手法を組み合わせたもの。ルーターは到達可能なネットワークとそのコスト(帯域幅や遅延など)を共有し、最も効率的な経路を選択します。

  • BGP(Border Gateway Protocol)
    インターネットの基幹的なルーティングプロトコル。ISPなど異なるネットワーク間で経路情報を交換し、データを複数ネットワークにまたがって効率的に転送できるようにします。インターネット全体の疎通を担う極めて重要な役割を持ちます。

  • RIP(Routing Information Protocol)
    シンプルなプロトコルで、小規模ネットワークで利用されます。ルーター同士が「到達可能なネットワーク」と「そこに至るまでのホップ数」を共有し、最もホップ数の少ない経路を選択します。

Answer the questions below

Which routing protocol discussed in this task is a Cisco proprietary protocol?

EIGRP


NAT

Networking Concepts のルームで説明した通り、IPv4 で扱えるアドレス数は最大約40億個です。しかし、インターネットに接続する機器(パソコンやスマートフォンから、防犯カメラ、洗濯機まで)が爆発的に増加した結果、IPv4 アドレス枯渇は避けられないものでした。その解決策のひとつが NAT(Network Address Translation) です。


NATの基本的な考え方

NAT の発想は「1つのパブリックIPアドレスを使って、多数のプライベートIPアドレスにインターネット接続を提供する」というものです。

例えば、20台のコンピュータがある会社を考えてみましょう。NATを使えば、20個のパブリックIPを契約する代わりに、1つのパブリックIPだけで全台をインターネットに接続できます。
(厳密には技術的制約から2つのパブリックIPを確保する必要がありますが、それでも32台分をカバーできるので、30個分のパブリックIPを節約できます。)


NATとルーティングの違い

通常のルーティングは、宛先ホストまでパケットを自然に届ける仕組みです。
一方、NAT対応ルーターは「どの内部ホストがどの外部接続を使っているか」を追跡する必要があります。そのため、内部アドレスと外部アドレスの対応関係を記録した 変換テーブル(Translation Table) を保持します。

  • 内部ネットワーク:プライベートIPアドレス帯を使用

  • 外部ネットワーク:パブリックIPアドレスを使用


NATの仕組み(例)

次の例では、複数のデバイスが NAT 対応ルーター経由でインターネットにアクセスしています。

  • ノートPCが Web サーバと接続を確立する

  • ノートPC視点では 192.168.0.129:15401 から接続開始

  • Web サーバ視点では 212.3.4.5:19273 から接続されたように見える

このときルーターは、内部IPとポート番号を外部IPとポート番号に対応付け、変換テーブルに保存します。外部のサーバには変換後のアドレスしか見えません。

NAT ルーターがこのアドレス変換をシームレスに行うことで、限られたパブリックIPを効率的に使い、IPv4アドレス枯渇を回避できるのです。



Answer the questions below

In the network diagram above, what is the public IP that the phone will appear to use when accessing the Internet?
212.3.4.5

Assuming that the router has infinite processing power, approximately speaking, how many thousand simultaneous TCP connections can it maintain?
65

Closing Notes

このルームでは、日常的に直接あるいは間接的に利用しているさまざまなプロトコルを紹介しました。扱った内容は以下の通りです。

  • ICMP

  • DHCP

  • ARP

  • NAT

  • Routing

普段インターネットを利用していると、これらの略語に出会うことはほとんどありません。
しかし、これらのプロトコルこそが、ネットワークを正しく機能させるための基盤となっています。

Answer the questions below

Click on the View Site button to access the related site. Please follow the instructions on the site to obtain the flag.
THM{computer_is_happy}

無料からプロ仕様まで!?OSINTツールまとめ【情報収集・セキュリティ研究】


サイバーセキュリティの調査やリサーチの第一歩は、対象に関する正確な情報を集めることから始まります。

OSINT(オープンソース・インテリジェンス)は、そのために欠かせない武器です。公開されている情報を正しく収集・分析することで、組織防御の強化やリスク発見、調査の効率化につながります。

本記事では、無料で気軽に使えるツールから、プロ向けの有料サービスまで幅広く紹介し、用途ごとの活用イメージも整理しました。

1) OSINTの立ち位置と注意点(超要約)

  • OSINT(Open Source Intelligence) は公開情報からの収集・分析。ブルー/レッド/パープルいずれの現場でも重要な“偵察・インテリジェンス基盤”、すなわち外部からの見え方を整理するための土台。

  • 合法性:規約違反・過度な負荷・未許可スキャンはNG。企業の許可範囲法令(不正アクセス/個人情報/名誉毀損等)を厳守。

  • 再現性:調査過程をあとから追跡できるよう、検索クエリや実行日時を含むログを残す。利用したサービスのAPIキーやクォータを適切に管理し、制限超過や不整合を防ぐ。得られた生データはCSV/JSONなどに整形して保存し、さらに可視化や差分比較まで行うことで、同じ手順を繰り返しても同等の結果が得られるようにする。

  • M&A/サプライチェーン外部SaaSにもリスクは広がる。外縁まで視野を。


2) 用途別マップ(課題:推奨ツール)


3) ツール一覧

表示順:フレームワーク/可視化 → 資産探索 → ドメイン/人/メタデータ → 監査/スキャン

3.1 フレームワーク/可視化・自動化

  • OSINT Framework(無料・カタログ)
    目的別に関連ツールへ導線を引く“索引”。まずここから俯瞰。

  • Maltego(無料/有料)
    エンティティ間の関係をグラフで可視化。トランスフォームで外部データ連携。

  • Recon-ng(無料)
    MetasploitライクなUXでWebリコン自動化。モジュール豊富、API鍵管理も容易。

  • SpiderFoot(無料/有料)
    100+ソースへ自動クエリ、資産・人・漏えい痕跡をまとめて収集/可視化。

  • IVRE(無料)
    Nmap/Masscan/ZDNSなどの出力をMongoDBで統合・Webで分析できる“OSINT SIEM”的基盤。

3.2 露出資産・IoT・サービス探索(攻守で必須)

  • Shodan(無料/有料)
    露出デバイス/サービス検索の定番。バナーやオープンポートから攻撃面把握

  • Censys(無料/有料)
    証明書・ホスト・HTTP/TLS詳細が強み。証明書ピボットで関連資産を深掘り。

  • ZoomEye(無料/有料)
    中国発のIoT/サービス検索。Shodan/Censysに並ぶサードオピニオン

  • BuiltWith(無料/有料)
    対象サイトの技術スタック(CMS/JS/CSS/サーバー/ホスティング等)特定。

3.3 ドメイン・メール・サブドメ・アカウント

  • theHarvester(無料)
    メール・サブドメ・VHost・ポート・社員名などを公開ソース横断で収集

  • Fierce(無料)
    DNSまわりのゾーン/誤設定探索。古典だが今も現役。

  • Unicornscan(無料)
    高速・柔軟なスキャン/バナー取得。研究用途向き。

  • CheckUserNames(無料)
    同一ユーザー名の多SNS横断チェック。アカウント名特定の起点に。

  • GHunt(無料)
    Googleアカウントの公開痕跡調査(レビュー/写真/サービス有効化状況など)。

  • Telegago(無料)
    Telegram公開チャンネル/グループをGoogleベースで横断検索。内部検索より見つかること多し。

3.4 メタデータ抽出/文書・画像・メディア

  • FOCA(無料)
    公開文書(PDF/Office等)からメタデータ抽出、隠れた情報の把握に有効。

  • Metagoofil(無料)
    検索エンジン経由で対象ドメインの文書を収集→メタデータ解析

  • ExifTool(無料)
    画像/動画/音声のEXIF/IPTC/XMPなどを読み書き。位置情報・撮影機材など痕跡確認。

3.5 監査・脆弱性・ポートスキャン

  • Nmap(無料)
    ホスト/ポート/OS/サービス検出の標準。スクリプト(NSE)で拡張。

  • WebShag(無料)
    HTTP/HTTPS監査(URLスキャン/ファジング/クローリング/プロキシ経由など)。

  • OpenVAS(無料)
    オープンソースの脆弱性スキャナ。マネージャで結果を蓄積・絞り込み。


4) クイックレシピ:最短で成果を出す手順例

レシピA:自社/対象ドメインの外縁資産を30分で把握

  1. Censys/Shodan/ZoomEyeで対象ドメイン/ASN/証明書からピボット → 露出サービス一覧。

  2. BuiltWithでWeb技術・CDN・WAF・アナリティクスIDを取得。

  3. theHarvesterでメール/サブドメ/社員名候補を収集。

  4. IVREにNmap結果を取り込み、ホスト/ポート/サービスを可視化&差分管理

レシピB:社外に散ったファイルとメタ情報の痕跡発見

  1. Metagoofil/FOCAでPDF/Officeを検索→DL→ユーザー名/ホスト名/ソフトを抽出。

  2. ExifToolで画像群を一括解析→位置情報/撮影機種/編集履歴を確認。

  3. 収集したID・ホスト名でRecon-ngのモジュールを再実行→関連を芋づる式に。


5) 導入・運用のコツ(実務で効くポイント)

  • API鍵の分離:個人検証用/案件用/CI用でキーを分離し、失効手順を整備。

  • 結果の正規化:CSV/JSON/SQLiteに統一。タイムスタンプ/ソース/クエリを必ず記録。

  • 差分志向:IVREやノートブックで前回との差分を見る運用に。変化点=リスクの種。

  • 負荷・礼節:並列度/レート制限は相手に優しく。robotsやToS順守。

  • レポートの“行動可能性”:発見→担当/期限/是正案まで落とし込む(例:古いDNSレコード削除期限、担当者割当)。


6) 用語ミニガイド

  • Passive/Active Recon:受動(公開情報照会)/能動(スキャン送信)。許可範囲を厳守。

  • Pivot(ピボット):証明書・アナリティクスID・NSなど共通点から関連資産へ“横展開”。

  • Banner:サービスが返す識別情報。バージョン露出はリスク。

  • Metadata:文書/画像に埋まる付帯情報。作成者/機材/座標/ソフト名など。


まとめ

OSINTを効果的に活用するためには、まず全体像を俯瞰し、次に重要な部分を深掘りし、その結果を可視化して関係性を明らかにし、最後に具体的な是正アクションへつなげるというサイクルを回すことが重要です。

本記事で紹介したツール群は、無料と有料を横断しながら、技術資産の把握から人物調査、公開文書や画像のメタデータ解析までを一気通貫でカバーできる構成になっています。現場での実務では、Shodan/Censys/ZoomEyeによる外部露出資産の確認、BuiltWithによる技術スタック把握、theHarvester/Recon-ngによるドメインやメールの収集、さらにFOCA/Metagoofil/ExifToolによる文書・画像解析、そしてNmap/IVREによるネットワーク可視化を基盤とするのが効果的です。

加えて、案件ごとの要件に応じてGHuntやTelegagoといったアカウント・SNS検索ツールを補完的に利用すれば、より再現性の高い調査が可能になります。国内では活用が限られる公開記録系や車両履歴系のサービスもありますが、適法性と実用性を確認しつつ組み合わせることで、より広範で実践的なOSINT環境を構築できるでしょう。

出典①:Top 25 OSINT Tools for Penetration Testingアーカイブ

出典②:Best Paid and Free OSINT Tools for 2024アーカイブ

【セキュリティ事件簿#2025-373】東京外国語大学 アジア・アフリカ言語文化研究所 本学ウェブサイトの改ざんに関するお詫び 2025/9/19

 

2025年8月3日(日)、本学アジア・アフリカ言語文化研究所が運営するWebサイトが改ざんされ、不適切なWebページが表示されていたことが判明いたしました。深くお詫びいたしますとともに、以下のとおり、本件の概要についてご報告いたします。

確認日時:

2025年8月3日(日)午後5時30分頃

確認された事象:

本学アジア・アフリカ言語文化研究所が研究業績の公開用に管理しているウェブサーバ(ドメインaa-ken.jp)内の一部のサイトにアクセスすると、オンラインカジノサイトに誘導される状態が作られておりました。

影響範囲:

aa-ken.jp (アジア・アフリカ言語文化研究所が独自管理しているウェブサーバ)

aa-ken.jp上でコンテンツ管理をしているウェブサイト

(irc.aa.tufs.ac.jpおよびcoe.aa.tufs.ac.jp)

今回改ざん被害を受けた範囲について、本学公式Webサイト(ドメイン tufs.ac.jp)および本学アジア・アフリカ言語文化研究所公式Webサイト(ドメイン aa.tufs.ac.jp)など、他のシステムへの影響はありません。

対応状況:

該当するウェブサーバを停止済みです。

原因等:

調査の結果、ウェブサイトを更新するシステムであるCMS (Contents Management System) の脆弱性を利用した不正アクセスと判明しました。

攻撃を受けたサーバ内の情報について:

公開可能な情報のみで、学生、教職員等に関する個人情報は含まれておりません。また、当該サーバに対してウイルススキャンを実施し、サーバのOSやミドルウェアおよび公開コンテンツについてウイルスは検知されませんでした。また、現在のところ不適切なウェブサイトが表示されたことによる被害等の報告はございません。

今後の対応及び再発防止について:

当該サーバについては、コンテンツ全体の脆弱性対応および、改ざんされたファイルを全て削除して安全が確認された後、公開を再開します。

再開に先だって、攻撃対策・サーバの構成管理や監視の強化を実施する予定です。

改ざんの影響が考えられる期間:

2025年6月5日(木) 16時12分 ~ 2025年8月8日(金) 15時50分

ご利用の皆さまへのお願い:

現在、脆弱性への対応と改ざんされたコンテンツの復元を進めており、安全性・正確性が確認でき次第、公開を再開いたします。ご利用の皆様にはしばらくご不便をおかけいたしますが、安心してご利用いただくための対応ですので、ご理解賜りますようお願い申し上げます。また、上記期間中に、当該Webサイトにアクセスされた可能性がある皆さまにおかれましては、誠にお手数ですが、お手持ちのセキュリティソフトを最新の状態にし、ウイルスチェック・駆除の実施をお願いいたします。

本件につきましては、ご迷惑及びご心配をお掛けいたしましたことを重ねて深くお詫び申し上げますと共に、今後はさらに対策・監視を強化し万全を期して運営して参ります。

リリース文アーカイブ

旅行予約サイト詐欺まとめ|kiwi.com・Expedia・vakatripの危険性と被害事例

詐欺サイト

kiwi.com

kiwi.comは表向きは旅行予約サイトですが、実態は詐欺的な運営を行っており、多くの利用者が被害に遭っています。航空会社の地上係員として実際に対応した事例では、既に欠航が決まっていた便の旅程を販売していたり、予約番号が存在しない状態で顧客に「購入済み」と誤認させたりするケースがありました。

結果として利用者は当日運賃の高額チケットを再度購入せざるを得ず、何倍もの費用を失うことになります。また、キャンセル済みと表示される予約が複数重複して存在するなど、システム上も極めて不自然な挙動が確認されています。

さらに深刻なのは、第三者のクレジットカードを不正利用して航空券を購入し、顧客にはその不正に取得したチケットを渡すという手口です。このため予約が途中で取り消され、顧客は空港で「決済が無効」と告げられる事態が頻発しています。航空会社側では不正利用を事前に防ぐことが難しく、結果として現場で被害を受けた利用者に説明し、新たな航空券を自費で買い直してもらうしかありません。

既に一社だけで100件を超える不正予約が確認されており、他社を含めれば被害規模はさらに拡大していると見られます。加えて不明瞭な手数料の徴収なども行われているとの報告があります。

こうした状況を踏まえると、kiwi.comは利用者から金銭をだまし取り、航空会社やカード会社を巻き込んで不正を繰り返す極めて悪質な詐欺サイトであり、絶対に利用すべきではありません。


Expedia

Expediaは世界的に有名な大手オンライン旅行予約サイトですが、その実態は利用者に深刻な不利益を与える“詐欺的な運営”が疑われています。最近注目を集めたのは、予約画面で「ビジネスクラス」と表記されていたにもかかわらず、実際にはエコノミークラスの座席が発券されたという事例です。投稿者は「ビジネスクラス」と信じて予約を確定し、往復9万円というお得な航空券を手にしたはずでしたが、いざ搭乗時にはエコノミー券しか発券されず、問い合わせてもチャットサポートは解決にならず、結局8時間以上のフライトをエコノミーで過ごす羽目になったのです。

こうしたトラブルの背景には、航空業界特有の「座席クラス(キャビンクラス)」と「予約クラス(ブッキングクラス)」の混同があります。座席クラスは実際に座る客室を指し、エコノミーやビジネスといった利用者のイメージ通りの区分です。一方で予約クラスはアルファベットで管理される運賃体系で、同じキャビンでも料金や条件が違います。OTAの画面表示ではこの二つが曖昧になり、利用者に「ビジネス」と誤認させるケースが少なくありません。しかし今回のケースは画面にも「Business」と明記されており、根本的な原因はさらに不透明です。

同様の事件は過去にも発生しており、格闘家・平本蓮氏が約70万円で予約したビジネスクラスが当日になって勝手にエコノミーに変更されていたこともありました。その際のエクスペディアの対応は、電話が繋がらない、チャットが一方的に終了するといった不誠実なもので、補償もわずか3万6,000円相当のポイント付与というお粗末な内容。世間の批判が高まった末にようやく100万円の返金が行われましたが、利用者保護の観点からは到底十分とは言えません。

さらに問題なのは、エクスペディアが日本の旅行業法の規制対象外である点です。公式サイトには「米国ワシントン州で登録されている旅行販売業者であり、日本の旅行業法の規制は受けない」と明記されています。つまり、万一トラブルが起きても日本の法制度に基づいた明確な救済を受けにくく、一般利用者は泣き寝入りを強いられる可能性が高いのです。

「安いから」「大手だから」と安心して予約した結果、現実には大幅なクラスダウンやサポート放棄に直面する。エクスペディアは一見便利なサービスに見えますが、繰り返されるトラブルや責任回避の姿勢を踏まえると、安心して利用できるサイトとは到底言えません。旅行という貴重な体験を守るためにも、こうしたサイトには決して依存すべきではないのです。

出典:エクスペディア「ビジネスクラス予約がエコノミー」炎上再び?過去には平本蓮氏も被害アーカイブ

ちなみにExpediaついては、筆者自身も嵌められた経験があり、イスラエルで宿なし体験をさせていただきました。貴重な体験記は下記を参照ください。


vakatrip.com

ベトナム・ホーチミン発→成田行きを「vakatrip」で手配した体験談では、表示と実態の乖離がはっきり見えました。サイト上ではJALコードシェア便として案内され、実質ベトジェットの最上位「skyBOSS」相当(優先チェックイン・手荷物・座席指定・機内食・アメニティ等)が適用される体で、片道2万2,000円という“お得”な価格が提示されていました。購入後に届いたEチケットも「JAL便名」表記。しかし、ベトジェット公式の予約確認に入れると、実際に発券されていたのはベトジェット最安の「エコ」運賃(オプション一切なし)。JALマイル付与もskyBOSS特典も当然つかない条件でした。

さらに、ベトジェット側の決済記録は約1万6,000円で、ユーザーの支払額2万2,000円との差額約6,000円の内訳説明はなし。サポートは日本語実務対応なし・英語テンプレ回答が中心で、表示と発券内容の不一致(JAL表記なのにVJ最安発券)という核心には向き合わない姿勢でした。空港の現場でも「予約は最安エコ運賃扱い」とされ、ラウンジや優先レーン等のskyBOSS権利は使えず、JAL側のカウンターでも介入余地はありません。

要は、「JAL名義で買えばskyBOSS相当」という期待を抱かせる表示で集客し、裏では最安のVJ運賃で発券する“実質的なおとり表示・ダウングレード”。安すぎる“エラー運賃風”の価格で釣り、差額や条件の違いは不透明、サポートは事実上の責任回避――という流れです。今回は運良くそのまま搭乗できたものの、期待していた特典もマイルもゼロ。価格差・体験差・説明責任のいずれも納得しがたい結果でした。


まとめ

旅行予約サイトは一見便利で安く見えますが、実態は利用者を食い物にする「詐欺的サービス」であることが少なくありません。kiwi.comのように存在しない便を販売したり、不正利用で取得したチケットを渡すケース、Expediaのように表示と実際の座席クラスが異なり、サポートも責任を回避するケースなど、被害の事例は後を絶ちません。

旅行は時間もお金もかかる大切な体験です。その入り口である航空券予約が不透明で詐欺的なサイトに奪われてしまえば、旅そのものが台無しになります。利用者としてできる最善の自衛策は「疑わしきは使わない」こと。航空券は必ず航空会社公式サイト、もしくは信頼できる販売窓口から購入しましょう。

安さや利便性に惑わされず、自分の旅を守る選択をすることが何より重要です。

【セキュリティ事件簿#2025-372】スターバックス コーヒー ジャパン 株式会社 Blue Yonder社の提供サービスへの不正アクセスによる弊社従業員の個人情報漏洩について 2025/9/19

 平素よりスターバックス コーヒーをご利用いただき、厚く御礼申し上げます。

この度、弊社が利用しているシステムサービスを提供するBlue Yonder社(以降「BY社」)に対し、外部からの不正アクセスによるサイバー攻撃が発生し、BY社が使用しているデータ転送システムから弊社の個人情報の一部が漏洩したことが判明いたしました。

今回漏洩した情報には、弊社及び弊社とライセンス契約を締結している取引先(以降「ライセンシー様」)の従業員(直営店舗とライセンス店舗の正社員、アルバイト)の個人情報が含まれております。なお、漏洩した情報に一般のお客様の情報は含まれておりません。また、住所、連絡先、金融情報、マイナンバー等の情報も含まれておりません。

対象となる皆様には、個別にご報告とお詫びを進めておりますが、退職などにより連絡先が確認できない方々もいらっしゃるため、この場を借りて公表させていただきます。あわせて、お問い合わせ窓口を設置し、誠意をもって対応いたします。

対象となる皆様に多大なご不安とご迷惑をおかけしておりますことを、心より深くお詫び申し上げます。今後BY社と緊密に連携し、全容の究明と再発防止に全力で取り組んでまいります。

1.概要

BY社が提供する以下のSaaSサービスにおいて漏洩が発生いたしました。

・Work Force Management(WFM):シフト作成ツール

このシステムには、弊社及びライセンシー様の全店舗従業員の氏名、従業員ID、生年月日、勤怠情報などが保管されておりましたが、今回漏洩したのはその一部となります。

2.漏洩した個人情報

対象者

・従業員および退職者:約31,500名(2025年9月16日時点:暫定)

 ※BY社がサイバー攻撃を受けた際に、データ転送システム上にデータが保存されていた従業員

 ※退職者、ライセンシー様の従業員も含みます

 ※一般のお客様の情報は漏洩しておりません

漏洩した情報(2025年9月16日時点:暫定)

・従業員ID(約31,500名)

・漢字氏名(約31,500名)

 ※フリガナ等の読み仮名情報は含まれておりません

・生年月日(約50名)

・契約開始日(約50名)

・職位(約50名)

・店舗番号

漏洩していない情報

・住所、電話番号、メールアドレス

・所属店舗名、部署情報

・給与、賞与等の処遇情報

・銀行口座情報

・マイナンバー

3.漏洩による影響について

漏洩した情報は従業員IDと漢字氏名、一部の生年月日に限定されておりますが、企業と紐づけられる可能性があるため、以下の点にご注意ください。

・スターバックスを装った不審な電話やメールにご注意ください

・身に覚えのない請求や勧誘があった場合は、下記窓口までご連絡ください

・個人情報の確認を求める連絡には慎重に対応してください

4.今後の対応

被害防止策

・対象者向け専用相談窓口の設置

・不審な連絡等に関する注意喚起の実施

再発防止策

・BY社に対し、セキュリティ体制の抜本的強化を要請

・委託先管理基準の見直しと監査体制の強化

・個人情報を扱うシステムの総点検実施

現在も調査を継続しております。今後新たな情報が確認されましたら改めてご報告いたします。

5.経緯:時系列

日付BY社の動き弊社の動き
2025/5/29BY社からスターバックスに「2024年12月ハッカー集団からのサイバー攻撃があり、スターバックスの従業員の個人情報が漏洩した可能性がある。現在調査中」との第一報
(人数、規模は不明と連絡あり)
-
2025/6/17-個人情報保護委員会に報告
(弊社従業員の個人情報漏洩の可能性あり)
2025/6/20BY社からスターバックスに「データ①」を提供
(BY社でデータ内の人数確認などの精査は実施しないと連絡あり)
-
--BY社より受領した「データ①」の精査し「弊社の従業員約110名の個人情報」であることを確認。
社内データと照合して、全員と直接連絡が取れることを確認
2025/7/28-個人情報保護委員会に報告
(「データ①」の内容を確報)
2025/7/29BY社からスターバックスに「6/20提供の「データ①」は、サンプルデータであり、全量データではないことが判明」と報告。再調査の開始-
2025/8/6-個人情報保護委員会に報告
(BY社の7/29の内容を報告)
2025/9/9BY社からスターバックスに「データ②」を提供-
--「データ②」を精査し「弊社及びライセンシーの従業員約31,500名の個人情報」であることを確認。
社内データと照合し、退職者データ等も含まれるため、全員と直接連絡を取ることが困難と判断
2025/9/12-個人情報保護委員会に報告
(「データ②」の内容)
2025/9/18-社内通知開始
(メールと社内コミュニケーションツール)
2025/9/19-対外告知開始

改めまして、この度は皆様に多大なるご心配をおかけしておりますことを深くお詫び申し上げます。この度の事案を厳粛に受け止め、信頼回復に努めてまいります。

リリース文アーカイブ