不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例

不正アクセスを受けたかどうかは、ログを先頭から眺めても分かりません。調べる対象（サーバーか、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のアカウントなのかで、見るログも、見られる人も変わります。

サーバーのログは管理者しか見られません。レンタルサーバーや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指定と、nginxのngx_http_log_moduleのlog_format指定で決まります。設定を変えている環境では、解析の前に実際の書式を確認してください。

エラーログ（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）のリリースノートで、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（ログオン失敗）の多発はブルートフォース、4624（ログオン成功）が業務時間外や見慣れないアカウントで出ていれば侵入の兆候です。アカウント作成の4720も同じログで追えます。

見落とされがちなのがイベントID 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との違いを解説した記事に、侵入検知の方式はIDS・IPSの違いと仕組みの解説にまとめています。

アクセスログのフォーマットとステータス別の不審な兆候

Apache／Nginxで広く使われる記録形式は「Combined Log Format」で、以下のフィールドが空白区切りで並びます。各フィールドの意味はApache公式のLog Files解説に定義があります。

203.0.113.45 - - [18/Oct/2026:03:12:44 +0900] "GET /admin/login.php HTTP/1.1" 401 512 "-" "sqlmap/1.8"

判断の軸はステータスコードです。401・403の連続は認証突破の試行、404の連発は管理画面や脆弱なファイルを探す探索、攻撃文字列を含むURLへの200は攻撃が成立した疑いを示します。User-Agentがsqlmap・nikto・masscanのような診断ツール名、あるいは空欄のリクエストも警戒対象です。ただしUser-Agentは簡単に詐称できるため、単独の証拠にはせず、送信元IPと挙動で裏付けます。

grep・awkでアクセスログから不正アクセスの痕跡を抽出する手順

数万行のログを目視で追うと見落としが出ます。grepとawkで機械的に絞り込み、頻度と時系列で異常を浮かび上がらせます。grepのオプションと正規表現の基本はgrepコマンドの基本構文とログ検索の解説にまとめています。

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インジェクション・トラバーサル・XSSの試行痕跡を横断検索
grep -Ei "union(%20|\+| )+select|%27|' or |\.\./|%2e%2e|etc/passwd|<script|%3cscript" access.log

# アップロード先のPHPファイルへのPOSTで200を返した行（Webシェルの疑い）
awk '$6=="\"POST" && $7 ~ /uploads.*\.php/ && $9==200 {print $1, $7}' access.log | sort | uniq -c

攻撃リクエストは多くがURLエンコードされた形で記録されるため、生の記号と%27・%2e%2eのような符号化形の両方で探します。Apacheの既知の脆弱性を狙ったパスの実例はCVE-2021-41773・CVE-2021-42013とログに来る攻撃文字列の読み方に、トラバーサルの仕組みと防ぎ方はディレクトリトラバーサルの仕組みと実装対策にあります。Webシェルの疑いが出たときのファイル監視・除去の順序はWebシェルの設置手口と検知・除去の手順を参照してください。

grepが見落とす痕跡を検証用ログで確かめた結果

上の攻撃文字列のgrepで、どこまで拾えるのかを確かめました。2026年10月18日、攻撃の内訳を把握している検証用のアクセスログ（640行）と認証ログ（46行）を作り、この記事のコマンドをmacOSのBSD grep 2.6.0・awk・Python 3.9.6で実行しています。実際の攻撃を受けたサーバーのログではなく、検出の可否を比べるために作ったログです。

見落としは2種類でした。1つは%252e%252e%252fのような二重エンコードです。%25は%そのものを表すので、grepの%2e%2eには一致しません。サーバー側のアプリケーションが2回デコードする作りだと、この形でも攻撃は通ります。もう1つはWebシェルです。/wp-content/uploads/…/x.php?cmd=idへのPOSTは、上で使ったSQLインジェクション・トラバーサル・XSS用のgrep式には一致しません。アップロード先のパスやメソッドを条件に加えれば、grepでも候補を抽出できます。しかも送信元IPのアクセス数は15件で、10件ずつアクセスしていた通常の利用者とほぼ並び、頻度の集計でも目立ちませんでした。実際のサイトは通常の利用者がはるかに多いので、Webシェルは件数では埋もれると考えるべきです。

認証ログでは、総当たりの送信元と同じIPが、40回の失敗のあとにdeployユーザーでパスワード認証に成功している行を、前章の3つ目のコマンドが1行だけ返しました。件数の集計では40回の失敗が目立ちますが、対応の優先度が高いのはこの1行です。

見落としを減らすには、元のURLを保存したうえで、デコード後の文字列も照合し、アップロード先へのPOSTを別の規則で拾います。次のPythonは標準ライブラリだけで動き、デコードを最大3回に制限して候補を抜き出します。アプリケーションが実際に何回デコードするかは別に確かめる必要がありますが、検証用ログでは上の表のとおり全件を検出しました。

# 使い方: python3 scan_access.py access.log
import re
import sys
from collections import Counter, defaultdict
from urllib.parse import unquote_plus

LINE = re.compile(r'^(\S+) \S+ \S+ \[([^\]]+)\] "(\S+) (\S+) [^"]*" (\d{3}) ')
PATTERNS = {
    "sqli": re.compile(r"union\s+select|'\s*or\s*'", re.I),
    "traversal": re.compile(r"\.\./|etc/passwd", re.I),
    "xss": re.compile(r"<script", re.I),
    "webshell": re.compile(r"/uploads/.*\.php", re.I),
}

def decode(path):
    # 二重・三重のURLエンコードも剥がす（最大3回）
    for _ in range(3):
        new = unquote_plus(path)
        if new == path:
            break
        path = new
    return path

total, errors = Counter(), Counter()
hits = defaultdict(Counter)
with open(sys.argv[1], encoding="utf-8", errors="replace") as f:
    for line in f:
        m = LINE.match(line)
        if not m:
            continue
        ip, _, method, path, status = m.groups()
        total[ip] += 1
        if status.startswith("4"):
            errors[ip] += 1
        plain = decode(path)
        for name, pat in PATTERNS.items():
            if pat.search(plain) and (name != "webshell" or method == "POST"):
                hits[ip][name] += 1

for ip in sorted(total, key=lambda i: (-sum(hits[i].values()), -total[i])):
    n = total[ip]
    print(f"{ip:15} {n:5}件 4xx率={errors[ip] / n:4.0%} {dict(hits[ip])}")

# 出力（先頭5行）
192.0.2.99         15件 4xx率=  0% {'webshell': 15}
192.0.2.20          3件 4xx率= 33% {'traversal': 3}
192.0.2.10          2件 4xx率=  0% {'sqli': 2}
203.0.113.45      300件 4xx率=100% {}
203.0.113.77      120件 4xx率=100% {}

並び順は攻撃文字列の検出数が先、アクセス数が後です。4xx率が0%で検出のあるIP（ここでは192.0.2.99と192.0.2.10）は、攻撃が通っている疑いがあるため最初に時系列を確認します。4xx率100%でも、探索や総当たりと断定したり、侵害がないと判断したりはできません。検証用ログの203.0.113.77も、Webでは4xx率100%でしたが、SSHではログインに成功していました。必要に応じて遮断し、認証ログ・アプリケーションログ・ファイル変更も照合します。

PC・スマホ・アカウントで不正ログインの履歴を確認する手順

個人のPCやスマホで「不正アクセスされたか」を調べるなら、OSのログより先にアカウントの側を見ます。Google・Microsoft・Appleのアカウントへの不審なアクセスは、各サービスが提供するログイン履歴や端末一覧から確認できるためです。

Windows PCのログオン履歴とイベントビューアーでの確認手順

イベントビューアーの「Windowsログ」→「セキュリティ」を開き、「現在のログをフィルター」でイベントID 4624（ログオン成功）に絞ります。読むのは各イベントの「ログオンの種類」です。Microsoft Learnの4624の説明では、2が画面の前での対話型ログオン、3がネットワーク経由（共有フォルダ等）、10がリモートデスクトップによるログオンと定義されています。自分が使っていない時間帯に種類10が出ていれば、リモートデスクトップで外から入られた疑いがあります。4624・4625の「ネットワーク アドレス」に見覚えのないIPがある場合も同様です。

Google・Microsoftアカウントのログイン履歴の確認手順

Googleアカウントは、「セキュリティとログイン」の「最近のセキュリティ イベント」で「セキュリティ イベントを確認」を選ぶと、パスワードの変更や新しい端末からのログインなどの操作が並びます（Googleアカウント ヘルプ）。同じ画面の「お使いのデバイス」→「すべてのデバイスを管理」では、ログイン中の端末とセッションを一覧でき（デバイスの確認手順）、見覚えのない端末はそこからログアウトさせられます。

個人用のMicrosoftアカウントは、「最近のアクティビティ」ページに過去30日以内にアカウントを使った日時と場所が表示されます。30日より前の履歴はここでは追えないので、異変に気づいたらすぐ確認します。業務用のMicrosoft 365やGoogle Workspaceは管理者側の監査ログで調べます。手順はM365・Google Workspace乗っ取りの調査手順にまとめています。

iPhoneで確認できるApple Accountの端末一覧と調査の限界

iPhoneには、サーバーのアクセスログのように「誰がいつ侵入したか」を利用者が読めるログは用意されていません。確かめられるのは、自分のApple Accountにどの端末がサインインしているかです。「設定」で自分の名前をタップして下へスクロールするとデバイスの一覧が出て、端末名をタップすると詳細を確認できます（Apple サポート）。見覚えのない端末があれば一覧から外し、Apple Accountのパスワードを変更します。

iOS 16以降なら、「設定」→「プライバシーとセキュリティ」→「個人情報安全性チェック」で、自分の情報にアクセスできる人、Apple Accountに紐づくデバイス、アプリのプライバシー許可をまとめて確認・変更できます（Apple 個人の安全ユーザガイド）。二段階認証は、漏れたパスワードだけによる不正ログインのリスクを下げます。ただし、フィッシングやセッション窃取などには別の対策も必要で、対応サービスではフィッシング耐性のある認証方式を選びます。方式の違いは二段階認証と二要素認証・多要素認証の違いで整理しています。

送信元IPの信頼性を評価する方法とGooglebot偽装の見分け方

集計で浮かんだIPが正当なクローラーか攻撃元かは、外部の情報と突き合わせて判断します。IPアドレスだけで善悪は決まらないため、複数の情報源を使います。

• WHOIS：IPの割り当て組織・国を確認します。自社と無関係な海外のホスティング事業者から管理画面へのアクセスがあれば警戒対象です。
• AbuseIPDB：そのIPが過去に攻撃・スパムで報告されているかを、信頼度スコアで確認できます。
• Shodan：IPが公開しているサービス・ポートを調べ、攻撃用ホストか踏み台かを推定します。
• VirusTotal：IP・ドメイン・URLの評価を、複数のセキュリティベンダー横断で確認します。

検索エンジンを名乗るアクセスは、Googleが公開しているクローラーからのリクエストを確認する手順で真偽を判定できます。IPを逆引きしてgooglebot.com等のドメインになるか、さらにそのホスト名を正引きして元のIPに戻るかを確かめます。一致しないのにGooglebotを名乗るUser-Agentは偽装で、遮断してかまいません。

セキュリティログ分析の4手法と使い分け

ここまでのコマンドは、何を基準に「異常」と判定するかで4つの手法に分けられます。

シグネチャ分析は攻撃に特有の文字列を探す手法で、前章の検証のとおり難読化と文字列の無い攻撃（Webシェル）には弱い。統計分析は平常時の量を基準に外れ値を探す手法で、「普段は1日200件の401が、今日は1時間で5,000件」のような異常を文字列なしで拾えます。相関分析は、Webのアクセスログと認証ログを同じ送信元IPや時刻で突き合わせる手法で、検証用ログの「Webで401を120回出したIPがSSHにログインしていた」はこれで見つかります。タイムライン分析は、侵入の疑いが出たあとに各ログの出来事を1本の時系列へ並べ直し、影響範囲と封じ込めの対象を決める手法です。

実務の順序ははっきりしています。まずシグネチャと統計で疑わしいIPと時間帯を絞り、その範囲だけを相関・タイムラインで深掘りします。JPCERT/CCの高度サイバー攻撃への対処におけるログの活用と分析方法は、どの機器にどのログを残せば攻撃の痕跡を追えるかを整理した資料で、タイムラインを組む前提づくりに使えます。会員アプリの情報漏えいを例に、不正アクセスの期間をログから割り出すSQLはバーガーキング不正アクセスの対象確認と運営側のログ点検で扱っています。

不正アクセスのログ解析に使えるツール：iLogScanner・CyberChef・fail2ban

手作業のgrepで当たりを付けたら、専用ツールで網羅性と継続性を補います。

IPA iLogScannerの対応ログ形式とJava環境の条件

IPAが無償で公開しているiLogScannerは、アクセスログを読み込み、SQLインジェクションやディレクトリトラバーサル等の攻撃兆候を自動で検出するツールです。IPAの解析可能なログファイルの説明によると、対象はApache HTTP Server 1.3系〜2.4系のCommon Log Format（先頭がCommonと同じCombined Log Formatも可）、IIS 6.0〜8.5のW3C拡張形式とIIS形式、ModSecurity 2.5系〜2.8系のエラーログ、sshdとvsftpdの認証ログです。Nginxは対象一覧に名前がありません。

動作にはJava実行環境が必要で、IPAの概要ページは2026年6月19日の更新で「JAVA SE 26およびJDK 26 以降(Open JDK含む)は動作しません」と注記しています。OpenJDK 25までの環境で動かしてください。オンライン版は2019年1月16日に公開を終了しており、現在はダウンロードして使うオフライン版のみです。導入と結果の読み方はiLogScannerで攻撃兆候を検出する使い方にまとめています。

CyberChefで難読化された攻撃リクエストを復元する手順

英国GCHQが公開しているCyberChefはブラウザで動く変換ツールで、ログから抜き出した文字列の難読化を戻せます。「URL Decode」のレシピを入力欄の文字列にかけ、結果にまだ%2eが残っていればもう一度「URL Decode」を重ねます。検証用ログの%252e%252e%252fは2回で../に戻りました。パラメータがBase64らしい英数字の塊なら「From Base64」を足します。何回デコードして文字列が現れたかは、エンコードの重なりを調べる手がかりです。ただし、その回数だけでは攻撃者の意図やWAFの回避に成功したかどうかまでは分かりません。

fail2banによる自動遮断とSIEMによる継続監視

1回の調査で終わらせないなら、fail2banで認証失敗が閾値を超えたIPを自動遮断し、SIEMで複数サーバーのログを集約して相関分析します。設定例はFail2banでSSH総当たりを自動遮断する設定の解説に、SIEMの仕組みはSOCとSIEM・SOARの違いと監視運用の解説にまとめています。

ログ改ざんへの備えと証拠保全：集約・時刻同期・保存期間

攻撃者は侵入後に自分の痕跡を消します。MITRE ATT&CKでもT1070 Indicator Removal（痕跡の除去）として、Windowsイベントログの消去やLinuxのログ削除が攻撃手法に分類されています。サーバー上のログを消せる状態のまま解析すると、「痕跡が無い＝安全」という誤った結論に至ります。

• 別ホストへ集約する：syslog転送やログ収集基盤で、侵入されたサーバーの外にリアルタイムで複製を持ちます。転送の設定はrsyslogによるログ収集・転送の設定解説を参照してください。
• 改ざんを検知する：AIDE等で重要ファイルの整合性を監視し、ログは別ホストへ転送して保護します。書き込み中のログは正常な追記でもハッシュが変わるため、保存済みログのハッシュ照合と区別して設計します。ログの日時が不連続に飛んでいたら消去・改ざんのサインです。
• 時刻をそろえる：全サーバーをNTPで同期し、ログのタイムゾーン（+0900かUTCか）を把握しておきます。時刻が数分ずれると、ログ間の前後関係を誤認するおそれがあります。ずれが分かった場合は、元の時刻を残したうえで補正量を記録して照合します。
• 保存期間を決める：NIST SP 800-92（ログ管理のガイド、2006年9月）は、保存期間を組織の方針として定めることを求めています。改訂版のRev.1は2023年10月11日に初期公開ドラフトが出たまま、2026年10月18日時点で確定していません。侵入の発覚は数か月後になることも多いため、保存設計の一例は、3か月分をすぐ検索でき、1年程度を遡れる構成です。これはNISTの一律要件ではなく、法令・契約・想定する調査期間・費用に応じて保存期間を決めます。

解析は取得した保全用コピーからさらに作業用コピーを作って行います。下の例で記録するSHA-256は取得コピーの値であり、取得前の改ざんがないことを証明するものではありません。取得日時と取得者も記録してください。後回しにすると、解析中に自分でタイムスタンプを上書きし、証拠能力を損なうことがあります。

# 原本を書き換えずにコピーし、ハッシュ値を記録する（Linux）
mkdir -p ./evidence &&
cp -p /var/log/nginx/access.log ./evidence/ &&
sha256sum ./evidence/access.log | tee ./evidence/access.log.sha256

外部の専門家に調査を依頼する流れはデジタルフォレンジックの種類と調査の流れに、費用と依頼先の選び方はフォレンジック調査の流れと依頼先の選び方にまとめています。

不正アクセスを確認した後の初動対応：隔離から報告までの優先順位

ログから侵入が確認できたら、解析と並行して被害の拡大を止めます。優先順位は「隔離→範囲特定→認証情報の無効化→報告」です。

1. 隔離：侵害されたサーバーや端末をネットワークから切り離し、攻撃元IPを遮断します。電源を落とすとメモリ上の揮発性の証拠が消えるため、ネットワークの遮断を優先します。
2. 範囲特定：タイムライン分析で、いつ・どこから侵入され、どのアカウント・データに触れたかを追います。認証ログとアクセスログを突き合わせ、横展開の有無も確認します。
3. 認証情報の無効化：侵害された可能性のあるアカウントのパスワード・APIキー・SSH鍵をすべて再発行します。パスワードの変更は、侵害が疑われない別の端末から行います。
4. 報告：個人情報の漏えいが疑われる場合は、個人情報保護委員会への報告と本人への通知が必要かを判断します。報告の対象と期限は個人情報保護委員会への報告義務（速報は概ね3〜5日以内・確報は原則30日以内、不正目的のおそれがある場合は60日以内）で確認できます。

実際の企業インシデントで原因公表と報告がどの順で進んだかは村田製作所の不正アクセス事例（原因と時系列）が、企業として平時に点検する順番は不正アクセス対策の点検手順が参考になります。

規模別に選ぶログ調査の体制：内製で足りる条件と外部に任せる条件

この記事のコマンドとiLogScanner、fail2ban、rsyslogによる集約は、内製調査の構成例です。十分かどうかは台数や週1回の確認だけで決めず、扱う情報・許容する検知遅延・対応担当者を基準に判断します。SIEMを入れても、アラートを見る人がいなければ検知は誰にも届かないため、担当者を置けない段階での導入は見送ってください。サーバーが数十台を超える、クラウドとオンプレミスが混在する、夜間・休日の検知を取引先から求められる、のいずれかに当てはまれば、ログの相関分析や監視体制の強化を検討します。SIEMの要否と監視時間は、検知・対応の要求水準に合わせて決めます。

ログ調査は「起きたこと」を見つける手段で、侵入口そのものは閉じません。SQLインジェクションや認証の不備が残ったままなら、同じ攻撃は繰り返されます。一創の脆弱性診断・セキュリティ診断では、ログで見つかった攻撃パターンを手がかりに、Webアプリケーションとサーバーの弱点を特定し、修正まで支援しています。

よくある質問：不正アクセスのログ確認と調べ方

不正アクセスされたか調べる方法はありますか？

サーバーならアクセスログと認証ログで「同じ送信元の失敗の連続」「失敗したIPからのログイン成功」「攻撃文字列への200応答」を探します。個人のPCやスマホなら、Google・Microsoft・Appleのアカウントにログインしている端末と最近のアクティビティを確認し、見覚えのない端末や場所が無いかを見ます。

不正アクセスのログはどこを見ればいいですか？

Webサーバーのアクセスログ（Apacheは/var/log/apache2/access.log、Nginxは/var/log/nginx/access.log）を起点に、OSの認証ログ（Linuxはauth.log／secure、Debian 12以降はjournalctl、Windowsはイベントビューアーのセキュリティログ）、WAF・ファイアウォールのログを突き合わせます。

iPhoneに侵入された履歴は確認できますか？

iPhoneには利用者が読める侵入履歴のログはありません。「設定」で自分の名前をタップした先のデバイス一覧で、Apple Accountにサインインしている端末を確認し、見覚えのない端末を外してパスワードを変更します。iOS 16以降なら「個人情報安全性チェック」で、アクセスできる人と端末をまとめて見直せます。

ポートスキャンのログはどう確認しますか？

ポートスキャンはWebのアクセスログではなく、ファイアウォールやIDSのログに現れます。単一の送信元IPが短時間に多数のポート宛てへ接続を試みていればスキャンです。侵入前の探索段階なので、この時点で送信元IPを遮断しておくと、その後の攻撃の入口を減らせます。

アクセスログが改ざんされていないか確認するには？

保存済みログは、信頼できる場所に保管した取得時のハッシュ値と照合します。書き込み中のログは正常な追記でもハッシュが変わるため、単純なハッシュ不一致だけでは改ざんと判断できません。ログの日時が不連続に飛んでいる、特定期間だけ記録が欠けている場合は消去・改ざんの疑いがあります。WindowsではイベントID 1102（監査ログの消去）も確認してください。改ざんに備え、ログは別ホストへリアルタイムに集約しておくのが確実です。

関連記事

• iLogScannerとは？IPA無料ツールで攻撃兆候を検出する使い方
• SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説【2026年時点】
• Fail2banとは？SSH総当たり攻撃を自動遮断する仕組みと設定・導入判断を実装目線で解説
• rsyslogとは？Linuxのログ収集・転送の仕組みとrsyslog.conf設定・導入判断を実装目線で解説
• デジタルフォレンジックとは？種類・調査の流れと企業が平時に備えること｜株式会社一創