--- title: "不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例" url: "https://www.issoh.co.jp/tech/details/2788/" published: 2024-06-26 updated: 2026-10-18 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例 不正アクセスを受けたかどうかは、ログを先頭から眺めても分かりません。調べる対象（サーバーか、PCか、クラウドのアカウントか）ごとに見るログが決まっていて、そのログから「同じ送信元の失敗の連続」「失敗のあとの成功」「攻撃文字列への200応答」を機械的に抜き出せば、痕跡はかなり絞り込めます。この記事では、ログの保存場所と確認手順、grep・awk・Python・PowerShellのコマンド例、検証用ログで確かめたgrepの見落とし、PC・スマホ・Googleアカウントでのログイン履歴の確認、証拠保全と初動までを順に説明します。 ## まとめ：不正アクセス調査のログ確認・抽出・照合 - **見るログは対象で決まる**：Webサーバーはアクセスログ（Apache／Nginx）、OSは認証ログ（Linuxのauth.log／secure／journal、Windowsのセキュリティログ）、境界はWAF・ファイアウォールのログ。個人のPCやスマホは、OSのイベントログより先にGoogle・Microsoft・Appleのアカウント側の履歴を見ます。 - **手がかりは4つ**：同じ送信元からの認証失敗の連続、404の連発（探索）、URLに紛れた攻撃文字列への200応答、アップロード先のファイルへのPOST（Webシェル）。 - **最優先は「失敗のあとの成功」**：総当たりをしていたIPからのログイン成功は、侵入が成立した可能性を示します。失敗の件数より先に、認証方式・時刻・ユーザー名を確認します。 - **grepだけでは漏れる**：検証用ログでは、二重にURLエンコードされたトラバーサルと、Webシェルへのアクセスを攻撃文字列のgrepが拾えませんでした。デコードしてから照合する処理を足します。 - **ログは消される前提で守る**：別ホストへの集約、時刻同期、ハッシュによる証拠保全を先に済ませます。痕跡が無いことは安全の証明になりません。 この記事のコマンドと無償ツールは初期調査の入口になりますが、調査範囲や必要な専門性は、被害の疑いと利用できるログによって変わります。手順の詳細は次の章から、対象ごとに説明します。 ## 不正アクセスされたかを調べる対象とログの対応 「不正アクセスされたか」を調べるとき、最初に決めるのは対象です。運営しているWebサイトやサーバーなのか、自分のPCやスマホなのか、GoogleやMicrosoftのアカウントなのかで、見るログも、見られる人も変わります。 | 調べる対象 | 見るログ | 主な手がかり | | ---------------------- | ----------------------- | --------------------- | | Webサイト・Webサーバー | アクセスログ・エラーログ | 404の連発・攻撃文字列への200 | | Linuxサーバー | auth.log／secure／journal | SSHの失敗の連続と成功 | | Windowsサーバー・PC | セキュリティログ | 4625の連続・時間外の4624・1102 | | 社内ネットワークの境界 | WAF・ファイアウォール・IDS | ポートスキャン・遮断の記録 | | Google・Microsoft・Apple | アカウントのログイン履歴 | 見覚えのない端末・場所 | サーバーのログは管理者しか見られません。レンタルサーバーやSaaSでは、管理画面からダウンロードできるアクセスログが調査の起点です。一方、個人のスマホにはサーバーのような「侵入履歴」のログはなく、アカウント側のログイン端末の一覧を確認するのが現実的な調べ方です。この違いを先に押さえると、見当違いの場所を探さずに済みます。 ## サーバーのログの保存場所と確認手順 攻撃者はWeb経由で侵入し、OSにログインし、外部へ通信します。それぞれの段階が別のログに残るため、サーバーの調査は「Web→OS→境界」の順に押さえます。 ### Webサーバーのアクセスログ（Apache／Nginx）の保存場所 WebサーバーへのHTTPリクエストを調べる起点はアクセスログです。保存場所は導入方法や設定で異なるため、以下のパスは配置例として確認してください。Debian・Ubuntu系のApacheでは一般に`/var/log/apache2/access.log`（RHEL系は`/var/log/httpd/access_log`）、Nginxは`/var/log/nginx/access.log`に、どのIPがどのURLへどのメソッドでアクセスし、サーバーが何を返したかを1行ずつ記録します。書式はApacheの[mod\_log\_configのLogFormat指定](https://httpd.apache.org/docs/2.4/mod/mod%5Flog%5Fconfig.html)と、nginxの[ngx\_http\_log\_moduleのlog\_format指定](https://nginx.org/en/docs/http/ngx%5Fhttp%5Flog%5Fmodule.html)で決まります。設定を変えている環境では、解析の前に実際の書式を確認してください。 エラーログ（error.log）も併読します。PHPの実行エラーや拒否された処理から、アクセスログだけでは成否が分からない侵入試行を裏取りできます。 ### Linux認証ログ（auth.log／secure／journal）でSSHを確認する手順 SSHやsudoへの攻撃はOSの認証ログに残ります。Ubuntu系は`/var/log/auth.log`、RHEL系は`/var/log/secure`に、SSHログインの成否・sudoの実行・アカウント操作が記録されます。 注意したいのはDebian 12以降です。[Debian 12（bookworm）のリリースノート](https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html)で、rsyslogが既定でインストールされなくなったと明記されています。この場合`auth.log`は存在せず、systemdのjournalから読み出します。 ``` # journalからSSHの認証失敗を直近24時間ぶん抽出（RHEL系はユニット名がsshd） journalctl -u ssh --since "24 hours ago" | grep "Failed password" # 認証失敗の送信元IPを回数順に集計（auth.logがある環境） grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20 # 認証に失敗したIPから、ログインに成功した記録を探す grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort -u > failed_ips.txt grep "Accepted" /var/log/auth.log | grep -F -w -f failed_ips.txt ``` `$(NF-3)`は「from 203.0.113.45 port 22 ssh2」の末尾から数えて4番目、つまり送信元IPを指します。「invalid user admin」のように存在しないユーザー名で失敗した行でも、この掲載例と同じ末尾形式なら同じ式で取れます。ただし、末尾に\[preauth\]などが付く形式では位置がずれるため、実際のログに合わせてfromとportの間のIPを抽出してください。同一IPが数百回失敗していれば総当たり、多数のIPが少しずつ失敗していれば分散型の試行です。 3つ目のコマンドは、認証に失敗したIPの文字列を含む成功行を候補として抜き出します。失敗と成功の前後関係や送信元フィールドの完全一致までは確かめないため、出力された行の日時・送信元IP・ユーザー名・認証方式を照合してください。`Accepted`には公開鍵認証の成功も含まれるので、この行だけでパスワードが破られたとは判断できません。総当たりのあとに見覚えのない時刻・ユーザー名での成功が続いていれば、失敗が何千件あるかより優先して対応します。 ### Windowsイベントログ4625・4624・1102で侵入の兆候を読む手順 Windowsではイベントビューアーの「Windowsログ」→「セキュリティ」を見ます。[イベントID 4625（ログオン失敗）](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625)の多発はブルートフォース、4624（ログオン成功）が業務時間外や見慣れないアカウントで出ていれば侵入の兆候です。アカウント作成の4720も同じログで追えます。 見落とされがちなのが[イベントID 1102（監査ログの消去）](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-1102)です。正規の運用で消すことはまれなので、1102が出ていたら痕跡隠しを疑います。PowerShellなら、4625の送信元IPを次のように集計できます。 ``` # 直近24時間のログオン失敗(4625)を送信元IPごとに集計（管理者権限で実行） Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } | Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name ``` コマンドプロンプトなら`wevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:text`でもログオン失敗だけを抽出できます。 ### WAF・ファイアウォール・IDSのログとポートスキャンの確認 境界のログは「そもそも到達したか、防がれたか」を示します。WAFのログには遮断した攻撃のシグネチャ名が残り、ファイアウォールやIDSのログにはポートスキャンや許可外ポートへの接続試行が並びます。ポートスキャンはWebのアクセスログには現れないので、単一の送信元IPが短時間に多数のポートへ接続を試みていないかを、ファイアウォールかIDSのログで確かめます。WAFで遮断済みのはずの攻撃がアクセスログに200で残っていたら、WAFを迂回する経路がある疑いです。WAFの役割は[WAFの仕組みとIPS・IDSとの違いを解説した記事](/tech/details/13275/)に、侵入検知の方式は[IDS・IPSの違いと仕組みの解説](/column/details/13258/)にまとめています。 ## アクセスログのフォーマットとステータス別の不審な兆候 Apache／Nginxで広く使われる記録形式は「Combined Log Format」で、以下のフィールドが空白区切りで並びます。各フィールドの意味は[Apache公式のLog Files解説](https://httpd.apache.org/docs/2.4/logs.html)に定義があります。 ``` 203.0.113.45 - - [18/Oct/2026:03:12:44 +0900] "GET /admin/login.php HTTP/1.1" 401 512 "-" "sqlmap/1.8" ``` | フィールド | 例 | 着目点 | | ---------- | -------------------- | ----------------- | | 送信元IP | 203.0.113.45 | 同一IPの大量アクセス | | 日時 | 18/Oct/2026:03:12:44 | 深夜・業務時間外の集中 | | メソッドとパス | GET /admin/login.php | 管理画面・存在しないパス | | ステータス | 401 | 401/403連発・想定外の200 | | User-Agent | sqlmap/1.8 | 攻撃ツール名・空欄 | 判断の軸はステータスコードです。401・403の連続は認証突破の試行、404の連発は管理画面や脆弱なファイルを探す探索、攻撃文字列を含むURLへの200は攻撃が成立した疑いを示します。User-Agentがsqlmap・nikto・masscanのような診断ツール名、あるいは空欄のリクエストも警戒対象です。ただしUser-Agentは簡単に詐称できるため、単独の証拠にはせず、送信元IPと挙動で裏付けます。 ## grep・awkでアクセスログから不正アクセスの痕跡を抽出する手順 数万行のログを目視で追うと見落としが出ます。grepとawkで機械的に絞り込み、頻度と時系列で異常を浮かび上がらせます。grepのオプションと正規表現の基本は[grepコマンドの基本構文とログ検索の解説](/tech/details/15274/)にまとめています。 ### awkによる送信元IP・ステータスの集計と調査候補の抽出 ``` # 送信元IPをアクセス回数の多い順に集計 awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20 # 認証失敗(401/403)だけを抽出して攻撃元を特定 awk '$9==401 || $9==403 {print $1}' access.log | sort | uniq -c | sort -rn # 404を返したパスの種類数をIPごとに数える（探索の検出） awk '$9==404 {print $1, $7}' access.log | sort -u | awk '{print $1}' | uniq -c | sort -rn | head # 第1フィールドの送信元IPが完全一致する行をログの記録順に確認 awk '$1=="203.0.113.45"' access.log ``` 同一IPから数百〜数千のリクエストが集中していれば調査の候補ですが、正規のクローラーや共有回線からの利用もあり得るので、次の章の方法で送信元を確かめます。1つのIPが数百種類のパスに404を出していれば、管理画面や脆弱なファイルを探す探索の可能性が高いと読めます。`$9`はCombined Log Formatでステータスが入る9番目のフィールド、`$7`はパスです。書式を変えている環境では番号がずれます。これらの集計は入力ファイル全体が対象なので、短時間の集中を調べる場合は、先に対象期間のログを切り出してください。 ### 攻撃パターン別の痕跡（SQLインジェクション・トラバーサル・Webシェル） 攻撃の種類ごとに、ログに残る文字列はおおむね決まっています。 | 攻撃 | ログに残る典型 | 検索の手がかり | | ------------ | ------------------------ | --------------- | | SQLインジェクション | ‘ OR ‘1’=’1、UNION SELECT | パラメータにSQL断片 | | ディレクトリトラバーサル | ../ や %2e%2e/ | URLに etc/passwd | | XSS |