侵害されたかどうかを確かめるための手がかりが、IOC（侵害指標）です。意味と種類、使い方、そして過信してはいけない理由までを、防御目線で解説します（攻撃手順は扱いません）。
IOCの主な種類
「どこに残る痕跡か」で大きく4つに分かれます。
| 種類 | 例 | どこで照合するか |
|---|---|---|
| ネットワーク系 | 攻撃者サーバのIP/ドメイン、C2のURL | ファイアウォール/プロキシ/DNSログ |
| ファイル系 | マルウェアのSHA-256ハッシュ、特徴的なファイル名 | EDR/ウイルス対策/ファイル一覧 |
| ホスト系 | 不審なレジストリキー、見慣れない常駐プロセス | OSのログ・プロセス一覧 |
| 挙動系 | 普段と違う時間/国からのログイン、急な大量通信 | 認証ログ・通信量の監視 |
IOC と IOA — 「痕跡」と「振る舞い」
よく対比されるのが IOA（Indicator of Attack＝攻撃指標） です。違いを押さえると、IOCの強みと弱みが見えます。
IOC（侵害指標）＝結果の痕跡
- すでに起きたことの証拠（ハッシュ・IP等）
- 既知の悪いものと機械的に照合できる＝速い
- だが攻撃者が簡単に変えられる（使い捨て）
- 本質的に後追い
IOA（攻撃指標）＝進行中の振る舞い
- 「権限昇格→横移動→外部送信」等の手口の流れ
- リアルタイムに近い段階で気づける
- 痕跡より変えにくい（攻撃の本質だから）
- 仕組みの理解が要るぶん導入の手間が大きい
攻撃者にとっての“変えやすさ”（痛みのピラミッド）
同じIOCでも、攻撃者がそれを変える手間（＝こちらが押さえたときの効き目）は段違いです。下ほど変えやすく、上ほど変えにくい。
つまり、ハッシュやIPの照合は手早く効く反面すぐ陳腐化します。手口（どう攻めてくるか）まで理解して備えるほど、防御は長持ちします。
小規模でもできるIOCの使い方
専用のEDRや脅威インテリジェンス契約が無くても、現実的にできることがあります。
信頼できる出典からIOCを得る
自分のログ・依存と照合する
ヒットしたら隔離して調査
自分の環境のIOCを記録し、他の端末も点検
具体例：公開された侵害で、何が照合の手がかりになったか
IOCはIPアドレスやハッシュだけではありません。当サイトで扱ったサプライチェーンの事例では、パッケージの「版」そのものが、最初に確かめるべき手がかりになりました。
| 事例 | 手がかり | 利用者が確かめたこと |
|---|---|---|
| XZ Utils（2024年） | 不正なコードを含む版（5.6.0・5.6.1） | 自分のOSやコンテナに該当の版が入っていないか。米CISAは 5.4.6 などの汚染されていない版に戻すよう勧めた |
| Codecov（2021年） | 配布スクリプトのハッシュ（SHA-256）が公式の値と食い違う | 改ざんに気づけたのは、1社がこの照合をしていたから。CIで実行していた期間と、その間に使えた秘密情報 |
| Trivy（2026年） | 不正に公開された版（v0.69.4 ほか）と、公表された確認項目 | CIでその版やタグを使った時間帯があるか。該当すれば認証情報をすべて入れ替える |
3つとも、手がかりを公表したのは侵害された側や当局で、照合するのは利用者自身でした。公式の発表が出たら、まず自分の環境に同じ版やハッシュがないかを確かめる。IOCの使い方の基本はこれです。
IOCには使用期限がある
IOCの扱い方をまとめた IETF の RFC 9424（2023年）は、IOCを発見・評価・共有・配備・検知・対応・廃棄という流れで管理するものとして整理しています。最後の「廃棄」があるのは、IOCが古くなるからです。
- 攻撃者が手放したIPアドレスやドメインは、後で正規のサービスに再利用されることがある。古い一覧で止め続けると、正規の通信を止めてしまう
- ハッシュは1バイト変えるだけで別の値になるので、同じ攻撃の新しい版には当たらない
- そのため、IOCには入手日と出典を記録し、一定期間で見直す
自分の環境で照合する方法
専用の製品がなくても、公表されたIOCのうち「版」「ハッシュ」「ドメイン」の3種類は自分で照合できます。
- 版：lockfile を依存パッケージ脆弱性スキャナに貼り、既知の悪性・脆弱な版が含まれていないかを見る。OSのパッケージは
xz --versionのように各コマンドで版を確かめる - ハッシュ：ダウンロードしたファイルの値を
sha256sum ファイル名（Windowsはcertutil -hashfile ファイル名 SHA256）で計算し、公式の値や公表されたIOCと比べる - ドメイン・IP：DNSのログやWebサーバーのアクセスログを、公表されたドメインやIPで検索する。ログが残っていない期間は確かめられないので、ログの保存期間も合わせて確認する
ヒットしたら、該当する端末・鍵・トークンを切り離し、上の手順3に進みます。
当サイトの視点：IOCは侵害後の確認手段。守りの中心は侵入させない設計
IOC照合は大事ですが、それは侵害が起きた後に痕跡を確認する作業です。痕跡が見つかる頃には、もう侵入されています。だから当サイトは、IOC照合を点検の道具として持ちつつ、力点はそもそも侵入されない設計に置きます。具体的には、最小権限・素早いパッチ適用（CVE監視）・フィッシング耐性MFA・秘密を平文で置かない、といった根本対策です。後追いの痕跡照合に依存した守りは、いつも一歩遅れます。痕跡で気づく力と、侵入を防ぐ力は、両方必要です。
出典（一次情報）
- IETF RFC 9424「Indicators of Compromise (IoCs) and Their Role in Attack Defence」（2023年8月） — rfc-editor.org（IOCの定義、痛みのピラミッド、IOCの管理の流れと廃棄）
- 米CISA「Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094」（2024年3月29日） — cisa.gov（対象の版と推奨対応）
- CodecovとTrivyの出典は、各事例の解説記事に掲載しています
次に読む
- 用語：IOA とは（攻撃指標） / C2 とは / EDR とは / CVE とは（脆弱性の識別子） / ランサムウェア とは / フィッシング とは
- 事例：XZ Utils バックドア / Trivy のサプライチェーン侵害
- 自分のサイトで確かめる：サイト・サーバーが不正アクセスされたか調べる方法
- 復旧：バックアップと復旧の基本