共用ホスティング環境における2026年7月上旬の運用記録

概要
サーバー別詳細
教訓
タイムライン

概要

7台のサーバーで構成される共用ホスティング環境において、定例のログ監視（logwatch）巡回と、複数のインシデント対応を実施した。本記事では、認証情報窃取によるメール不正送信、顧客側の設定ミスによる誤検知、そして「AIが生成した過去の調査結果を鵜呑みにしたことで生じた前提のズレ」という運用上の教訓について記録する。

対象	状態	主な事象
サーバーA（cPanel）	対応完了	メールアカウント侵害による不正送信、キュー滞留
サーバーB（DirectAdmin）	調査完了・対応不要	顧客側メールクライアントの設定ミス、Webサーバーへの探査アクセス（実害なし）
サーバーC（cPanel）	要確認1件	Webサーバーへの探査アクセス（対象・実害とも未確認）
サーバーD（cPanel）	異常なし	–
サーバーE（cPanel）	異常なし	–
サーバーF（cPanel）	異常なし	パスワード認証を意図的に許可した特殊構成、突破の形跡なし
サーバーG（Ubuntu/コンテナ基盤）	異常なし	–

サーバー別詳細

サーバーA：メールアカウント侵害と対応

あるメールアカウントの認証情報が外部から窃取され、SMTP認証を通じて短時間に3万通超のスパムメールが送信された。送信は特定の90分間に集中しており、宛先を詐称した金融詐欺（前払い詐欺）風のメールが大量に配信されている。

調査の結果、このアカウントは既に前日の時点で利用者本人によってパスワードがリセット済みであることが判明した。リセット後のログを確認したところ、新規の不正送信は確認されず、認証試行自体は継続しているものの全て失敗に終わっていた。これにより、パスワード変更という基本的な対処が有効に機能していることが確認できた。

不正送信の残骸（配信不能メールに対する自動遅延通知が、詐称された宛先へさらに配送失敗を繰り返す現象）によってメールキューが増加し続けていたため、該当バースト分のメッセージIDを特定し、他の正常な滞留メールを巻き込まない形でピンポイント削除を実施した。削除前後でキュー件数は約3割減少している。

さらに、辞書攻撃のログを分析する過程で、同一の送信元IPアドレスから、ある企業ドメイン配下の複数の異なるメールアカウント（5〜6件）へ、規則的な間隔で認証試行が行われているパターンを確認した。これは特定のアカウントへの総当たりというより、ドメイン内の複数アカウントを機械的にリスト化して試行する挙動に近く、攻撃の型として記録に値する。

サーバーB：顧客都合の設定ミスと、調査プロセスの見直し

ある顧客のメールソフトが、約1ヶ月にわたり毎時1回、誤った形式のユーザー名（本来「アカウント@ドメイン」であるべきところを「ドメイン/アカウント」という古い形式のまま）でサーバーに接続を試み続けていた。この形式はサーバー側の認証機構で機械的に拒否される仕様のため、パスワードの正誤に関わらず接続は必ず失敗する。

顧客への確認の結果、該当アカウント自体を「使用していない」という回答があり、当初の前提と食い違いが生じた。再調査により、同一の接続元IPアドレスから、その顧客が管理する別のドメインの正規アカウントへは正常にログインが成立していることが判明した。ここから、過去に別ドメイン用のメール設定を作成した際、サーバー名の入力を誤って古いドメイン名のまま保存してしまった設定が、メールソフト内に取り残されている可能性が高いと推測している。顧客には実際のログ行(日時・IPアドレス)を添えて再確認を依頼し、返信を待っている段階である。

この案件と並行して、Webサーバーのアクセスログに「成功した可能性のある探査」として、OSの設定ファイルを狙ったパストラバーサル攻撃の痕跡が記録されていた。詳細な再調査の結果、該当する形式のリクエスト自体がアクセスログのどこにも見当たらず、実際にファイル内容が漏洩した証拠は確認できなかった。判定ツールが検出条件に一致した文字列を機械的に拾っただけで、実害は伴っていなかったと判断している。

サーバーC：Webサーバーへの探査(未確定)

設定ファイル(環境変数ファイル)の内容を狙ったパストラバーサル形式のリクエストが1件検出された。ただし、今回入手したログ形式には対象ドメイン名の記載がなく、実害の有無を確認するには追加調査が必要な状態のまま保留している。

サーバーD・E・F・G：異常なし

定型的な辞書攻撃・ポートスキャンといった背景ノイズ以外に、対応を要する事象はなかった。サーバーFは特定の利用者向けにパスワード認証を意図的に有効化している特殊構成だが、認証試行は全て失敗に終わっており、突破の形跡はない。

教訓

過去の調査結果を鵜呑みにする危険性。 今回、サーバーAのメールキュー件数について「対応済み」という前回の記録を前提に指示を出したところ、実際には未対応のまま件数が増加していたことが後から判明した。原因を辿ると、過去の会話記録がAIによる要約であり、「提案した内容」と「実際に実行された内容」が明確に区別されないまま記録されていたことにあった。AIが生成した過去のやり取りの要約を次の作業の前提として使う際は、それが実行結果なのか、単なる提案・意図の記録なのかを都度切り分ける必要がある。この教訓は、AIを継続的な運用補助として使う場面全般に当てはまるだろう。

顧客の申告と技術的事実は、両方とも正しいことがある。 サーバーBの案件では、顧客が「該当アカウントを使っていない」と回答したことと、実際にそのIPアドレスから接続が続いていた事実は、一見矛盾するようで矛盾していなかった。同じ顧客が管理する別ドメインの設定作業時に生じた、単純な入力ミスの副産物だったという構図である。片方の情報だけで結論を急がず、両方の整合性が取れる説明を探す姿勢が有効だった。

「成功した可能性のある探査」という表現は、実害の証明ではない。 Webサーバーの監視ツールは、既知の攻撃パターンに一致する文字列を含むリクエストと、それに対するHTTPステータスコード200という組み合わせだけで「成功」と分類することがある。今回の2件はいずれも、実際のアクセスログを遡って確認した結果、該当するリクエスト自体が存在しない、あるいは対象となるスクリプトがサーバー上に実在しないことが判明した。アラートの文言だけで深刻度を判断せず、一次ログでの裏取りを徹底することの重要性を再確認した。