改ざん検知の警報17,097件を全件分類したら、マルウェアは0件だった
この記事は、CloudHonu が実際に運用している監視の記録をそのまま公開するものです。集計値のみを扱い、個別のお客様が特定される情報は含みません。
結論：17,097 件鳴って、マルウェアは 0 件だった
改ざん検知（ファイル整合性監視）を入れると、まず驚くのは鳴る量です。
CloudHonu で保守管理しているサーバー群に対して毎日回している改ざん検知の記録を、2026 年 8 月 11 日から 9 月 2 日までの 23 日間ぶん、全件分類しました。結果は次のとおりです。
| 種別 | 件数 | 実体 |
|---|---|---|
| 監視ファイルの消失 | 14,103 | ほぼ全て、計画された撤去作業 |
| 既存ファイルの変化（改ざん疑い） | 2,881 | 更新とデプロイ |
| コアにあるはずのないファイル | 113 | ここだけが人の判断を要した |
| 合計 | 17,097 | |
| うちマルウェア検出 | 0 |
23 日のうち21 日で何かが鳴っています。ほぼ毎日です。そして悪性なものは 1 件もありませんでした。
「では、この監視は無駄だったのか」というのが、この記事の主題です。
何を監視しているか
先に前提を書きます。サイトの全ファイルを監視対象にすると、画像のアップロードやキャッシュの生成で毎日数万件が動き、実質的に何も見ていないのと同じになります。かといって数点に絞れば、絞った外側がまるごと盲点になります。
私たちが置いている基準は「コードが実行されうる場所を、正常な変化が少ない範囲で最大限とる」です。サイトの入口、WordPress が無条件に読み込む領域、テーマの処理、そして本体の外側に置かれた PHP。いずれも「そこに置けば実行される」場所で、バックドアを仕込むなら、まず候補になります。
そして、この範囲は固定ではありません。設計した時点で完全な監視範囲というものは無く、監視対象は見逃した経験のぶんだけ広がっていきます。「何を見ているか」を決めて終わりにせず、「今の範囲では何が見えないか」を定期的に問い直すほうが実際的です。
17,097 件の内訳
監視ファイルの消失 — 14,103 件（82%）
最大の種別は「あったはずのファイルが無くなった」でした。全体の 8 割強を占めます。
ただしこの期間、私たちは不要になった WordPress の撤去作業を集中的に行っていました。閉鎖したサイトの残骸、サーバー構築時の雛形、旧サーバーから引き継いだまま使われていないインストール。撤去すれば当然、監視対象だったファイルは消えます。
つまりこの 14,103 件は、自分たちの作業が鳴らした音です。攻撃で消えたものは含まれていません。
ここに設計上の判断が 1 つあります。ファイルの消失も警報にするかどうかです。消失を無視する設計にすれば、この 14,103 件は鳴りません。しかし改ざんの手口には「痕跡を消す」ものがあり、消失を見ないことはその手口に目を閉じることを意味します。自分たちの作業でうるさくなることを受け入れて、消失も鳴らすほうを選んでいます。
既存ファイルの変化 — 2,881 件（17%）
「改ざん疑い」として最も緊張する種別です。中身を分類すると、こうなりました。
| 何が変わったか | 件数 | 理由 |
|---|---|---|
| WordPress 本体のローダー類 | 1,034 | コアの更新（この期間に新しいメジャー版が出た） |
| 常時読み込まれる領域のファイル | 653 | 管理ツール自身の自動更新 |
| 自社の管理システム | 624 | 私たち自身のデプロイ |
テーマの functions.php | 458 | サイト側の更新・改修 |
.htaccess | 63 | 設定変更 |
wp-config.php | 34 | 設定変更 |
入口の index.php | 14 | コア更新に伴うもの |
| その他 | 1 | |
| 合計 | 2,881 |
分類の合計は 2,881 件で、警報が申告した総数と一致します。「大半は」ではなく、全件です。そのうえで、すべてに説明がつきました。
しかし重要なのは、説明がついたのは分類したからであって、鳴った時点では分からなかったという点です。
653 件を占めるのは、サーバーの管理ツールが配置しているファイルです。ツールが自分で自動更新するたびに、そのツールが入っている全サイトぶんが一斉に鳴ります。1 回の自動更新が、そのまま件数になります。これを「よくある奴だ」と流す習慣がつくと、その中に紛れた 1 件を必ず見逃します。だから毎回、変化した全パスを突き合わせています。
コアにあるはずのないファイル — 113 件（0.7%）
件数は最小ですが、実務上いちばん重要なのはこの種別でした。
WordPress は本体ファイルの一覧と、その内容のハッシュを公式に配布しています。これと実物を突き合わせると、「公式には存在しないのに、本体のフォルダに置かれているファイル」が分かります。
期間内に出てきたものは、大きく 2 種類でした。
- 本体のファイルを直接書き換えたときの退避ファイル（書き換える前の内容を別名で残したもの）
- 制作当時に置かれた、独自のアップロード用の仕組み（テーマやプラグインをブラウザから設置するためのもの）
具体的なファイル名は伏せます。現に存在しているものの置き場所を公開すると、それを探す手がかりを配ることになるためです。
いずれもマルウェアではありません。2014 年前後に制作されたサイトに共通して見られる、当時の制作会社の作業用ファイルです。
ただし、放置してよいという意味ではありません。
- 退避ファイルは本体が直接改造されている痕跡で、コアを更新すると改造が消える（あるいは更新に失敗する）
- アップロード用の仕組みはファイルを設置できる経路そのもので、認証の実装が当時の水準のまま止まっている
- いずれも現在は誰も使っておらず、更新もされない
マルウェアを 0 件しか見つけなかったこの監視が、実際に見つけたのは「10 年前に置かれ、以後誰も触っていない、ファイルを設置できる仕組み」でした。悪用された形跡はありませんが、悪用されるとすれば真っ先に候補になる種類のものです。
「悪性 0 件」は、監視が無駄という意味ではない
17,097 件鳴って 0 件。数字だけ見れば、費用対効果の悪い仕組みに見えます。実際そう判断して、改ざん検知を止めてしまう現場もあります。
ただ、この結論には順序の間違いがあります。
0 件だと分かったのは、17,097 件を分類したからです。 分類しなければ「0 件かもしれないし、そうでないかもしれない」という状態が続くだけで、それは監視していないのとほとんど変わりません。
火災報知器が 1 年間鳴らなかったことを「無駄だった」とは言いません。改ざん検知も同じで、成果は「何も見つからなかったことを証明できる状態」そのものです。
誤検知を減らすより、説明できる状態を作る
毎日鳴る監視に対する自然な反応は、「誤検知を減らしたい」です。しかしこの方向には落とし穴があります。
誤検知を減らす作業は、たいてい「よく鳴るものを除外リストに入れる」形になります。そして攻撃者が狙うのは、まさに「よく変わる場所」です。除外するほど、監視は静かになり、同時に見えなくなります。
私たちが選んでいるのは、鳴る量は受け入れて、鳴ったものを全部説明できる状態を保つほうです。そのために、いくつか運用上の仕掛けを入れています。
変化を自動で「正しい」としない
多くの改ざん検知は、変化を検出したあと現状を新しい基準として自動で取り込みます。これをやると、改ざんされた状態が翌日には「正常」になります。1 日でも見逃せば、以後永久に鳴りません。
基準の更新は、人が確認するまで行わない設計にしています。
新しく現れたファイルは、検査を通すまで取り込まない
新規ファイルは、バックドアが設置される経路そのものです。ウイルス検査を通し、明確に問題なしと出たものだけを基準に取り込みます。検査が終わらない、結果が読めない、という場合は取り込まない側に倒します。
取り込みは、宣言と一致しないと実行できない
これは私たちが自分の運用の弱点をふさぐために足したものです。
人が一覧を眺めて「これは既知の変化だ」と判断して基準を更新する運用は、実質的に追認になります。疲れている日に紛れ込んだ 1 件を、そのまま通します。
そこで、基準を更新するときは「今回取り込む変化はこれだ」と先に宣言することを必須にしました。宣言と実際の差分が一致しなければ、更新は実行されずに中止されます。件数が急に減った場合（収集そのものが失敗している可能性）も止まります。
実際、この記事を書いている最中にも、宣言していない変化を 1 件検出して更新が拒否されました。調べたところ、前日に自分たちが行ったデプロイの取り込み漏れでした。害はありませんでしたが、止まるべきときに止まることを確認できました。
まとめ
23 日間で 17,097 件。マルウェアは 0 件。内訳は、8 割が自分たちの撤去作業、17% が更新とデプロイ、残る 0.7% が人の判断を要したものでした。
この記録から言えることは 3 つです。
- 改ざん検知は毎日鳴る。鳴らない設定になっているなら、それは監視できていない可能性のほうが高い
- 価値があるのは検出ではなく分類。「0 件だった」は、全部見た後にしか言えない
- 見つかるのはマルウェアとは限らない。実際に出てきたのは、10 年前に置かれて誰も触っていない仕組みだった
改ざん検知を導入するかどうかを検討しているなら、判断の基準は「何件検出できるか」ではなく、鳴ったときに全部説明する体制を作れるかです。作れないなら、入れても静かに切られるだけで終わります。
