Netwiz LLC

サーバーのログから侵入の兆候を見つける。自分でできる「少し上級」のセキュリティ点検

ネットウィズ合同会社 庄司育雄

ランサムウェアの記事で書いたとおり、 攻撃者は侵入した日にいきなり暴れたりしません。数日から数週間、社内に潜伏して 準備をします。逆に言えば、この期間に兆候へ気づければ、被害が出る前に断ち切れます。

そして侵入の兆候は、多くの場合サーバーのログに残っています。 大量のログイン失敗、深夜の見知らぬログイン、勝手に作られたアカウント、 そして「ログそのものが消されている」という痕跡。

この記事は、当ブログの中では少し上級編です。 社内にWindowsサーバーやLinuxサーバーがあり、 「業者に全部任せる前に、自分でも最低限の点検ができるようになりたい」という 経営者・兼任IT担当者に向けて、専門ツールなしで、OSに最初から入っている機能だけで できるチェック方法をまとめます。 まだ基本のセルフチェック7項目を終えていない場合は、 先にそちらからどうぞ。

先に、チェックの考え方

やみくもにログを眺めても、何も見つかりません。 攻撃者が潜伏中にやることは決まっているので、その行動が残す痕跡だけを狙って見ます。

攻撃者の行動残る痕跡
パスワードを総当たりで試す大量のログイン失敗
盗んだパスワードで入る見慣れない時間・場所からのログイン成功
自分用の入口を確保する新しいアカウント、新しいサービスや自動実行タスク
道具を持ち込む見慣れないファイル、見慣れない通信の待ち受け
指令サーバー（C2）と通信して指示を待つ業務で説明のつかない外向きの通信
検知されないよう守りを止めるウイルス対策の無効化・除外設定の追加
データを持ち出す準備をする見覚えのない巨大な圧縮ファイル
痕跡を消すログの消去・不自然な空白

もうひとつ大事なのが、平常時の姿を知っておくことです。 「このサーバーには普段、誰が・いつ・どこからログインするのか」を知らないと、 異常かどうか判断できません。最初の1〜2回は「異常を探す」のではなく 「普段の姿を覚える」つもりで見てください。

Windowsサーバー編

ログはイベントビューアーで見ます。スタートメニューで「イベントビューアー」 （eventvwr）を検索して起動し、左のツリーから 「Windowsログ」→「セキュリティ」を開いてください。 膨大な行が並びますが、見るのはイベントIDです。右上の「現在のログをフィルター」で ID番号を指定すると、目的の記録だけに絞れます。

1. ログイン失敗の嵐が来ていないか（イベントID 4625）

4625はログオン失敗の記録です。フィルターで4625を指定してみて、

  • 同じアカウント名に対して失敗が短時間に何十件・何百件も並んでいる
  • administrator、admin、testなど、実在しない・使っていない名前への失敗が続いている

これはパスワード総当たり攻撃を受けている状態です。特にリモートデスクトップを 外部公開しているサーバーでは頻発します。失敗が並ぶこと自体より、 その後に「成功」が続いていないかが重要です。

2. 不審なログイン成功がないか（イベントID 4624）

4624はログオン成功です。全部見る必要はありません。見るポイントは3つ。

  • 時間: 深夜・休日など、誰も仕事をしていないはずの時間帯の成功
  • アカウント: 退職者のアカウント、誰も使っていないはずのアカウントでの成功
  • ログオンタイプ: 詳細欄の「ログオンタイプ」が10ならリモートデスクトップ経由、 3ならネットワーク経由です。リモートデスクトップを使っていないはずの サーバーでタイプ10の成功があれば、明確な異常です

3. 勝手にアカウントが作られていないか（イベントID 4720・4732）

4720は新しいアカウントの作成、4732は管理者グループへの追加の記録です。 攻撃者は、盗んだアカウントをいつか無効化されても戻って来られるように、 自分専用のアカウントを作って管理者権限を付けておくことがよくあります。 自分たちが作った覚えのないアカウントの作成記録があれば、重大なサインです。

あわせて「コンピューターの管理」→「ローカルユーザーとグループ」で、 いま存在するアカウントの一覧も定期的に見てください。 見覚えのないアカウントがいないか、Administratorsグループに知らないメンバーが いないか。この確認はログを読むより簡単で、効果があります。

4. ログが消されていないか（イベントID 1102）

ここがこの記事で一番伝えたいポイントです。 1102は「監査ログが消去された」という記録です。

Windowsは、セキュリティログを誰かが消去すると、 消去したという事実そのものを新しいログとして残します。 攻撃者は痕跡を消すためにログを消しますが、消した痕跡は残るのです。

自分たちで意図的にログを整理した覚えがないのに1102が記録されていたら、 それは「何かを隠したい誰かがいた」ことの直接の証拠です。 他のどのIDより優先して、フィルターで1102を確認してください。 また、ログを開いたら空っぽだった・ある日から前の記録が不自然に消えている、 という場合も同じ疑いを持ってください。

5. 勝手に仕込まれたものがないか（イベントID 7045・4698）

攻撃者は、サーバーが再起動されても自分のプログラムが動き続けるように、 サービスや自動実行タスクとして仕込みます。

  • 7045（「Windowsログ」→「システム」側にあります）: 新しいサービスの登録
  • 4698: 新しいタスクスケジューラのタスク作成

心当たりのないサービス名・タスク名、特に意味のないランダムな英数字の名前や、 C:\Windows\Temp や C:\Users\Public といった一時フォルダーから実行される 設定のものは要注意です。タスクスケジューラの一覧を直接開いて、 見覚えのないタスクがないかを確認するのも有効です。

6. いま誰がつながり、どこへ通信しているか

ここまでは過去の記録の確認でしたが、いまの状態も見ておきます。 コマンドプロンプトを管理者として起動して、次の2つ。

query user
netstat -ano | findstr ESTABLISHED

query user は、いまログインしているユーザーの一覧です （リモートデスクトップのセッションを含む）。見知らぬセッションがあれば即異常です。

netstat のほうは通信の一覧で、ここがC2通信のチェックになります。 ランサムウェアの記事で書いたとおり、 潜伏中のマルウェアは外部のC2サーバー（指令サーバー）へ自分から接続して 指示を待ち続けます。つまり侵入されたサーバーには、 業務では説明のつかない外向きの接続が現れます。 ESTABLISHED（確立済み）の行を眺めて、宛先が社内でも、契約している クラウドサービスでもないIPアドレスへの接続がないか。 気になる行があれば、右端のPID（プロセス番号）を控えて、

tasklist /svc /fi "PID eq 1234"

で、どのプログラムの通信なのかを特定します（1234は実際のPIDに置き換え）。

ひとつ注意点があります。C2通信には常時つなぎっぱなしの型だけでなく、 数分〜数時間おきに一瞬だけ通信する間欠型もあります。 一度見て何もなくても白とは言い切れません。だからこそ、 毎回の点検項目として見続けることに意味があります。

7. ウイルス対策が骨抜きにされていないか

攻撃者が侵入後、真っ先にやるのが検知の無効化です。ただし、分かりやすく 停止させると気づかれるため、除外設定に自分の作業フォルダーを追加して 検知だけをすり抜けるという手口が定番になっています。PowerShellで確認できます。

Get-MpPreference | Select-Object Exclusion*

Microsoft Defender の除外設定（フォルダー・プロセス・拡張子）が表示されます。 自分たちで設定した覚えのない除外が追加されていないかを確認してください。 あわせて、Windowsセキュリティの画面でリアルタイム保護が有効になっているか、 「保護の履歴」に検知が残っていないかも見ます。リアルタイム保護が無効化されると、 イベントログ（「アプリケーションとサービス ログ」内の 「Windows Defender」→「Operational」）にイベントID 5001が記録されるので、 心当たりのない5001がないかも手がかりになります。

8. 勝手な共有・自動起動が増えていないか

net share

共有フォルダーの一覧です。C$・ADMIN$・IPC$ はOS標準の管理用共有なので 正常です。それ以外に見覚えのない共有名があれば、社内での横展開や データ持ち出しの足場にされている可能性があります。

自動起動の古典的な仕込み先であるレジストリのRunキーも見ておきます。

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

サービス（7045）やタスク（4698）より原始的ですが、今も現役の永続化の手口です。 見覚えのない項目、特に一時フォルダー配下のプログラムを起動する登録が ないかを確認してください。

Linuxサーバー編

Linuxの場合はコマンドで確認します。SSHでログインし、管理者権限（sudo）で 実行してください。ログの場所はUbuntu/Debian系なら /var/log/auth.log、 RHEL/AlmaLinux系なら /var/log/secure です。以下はUbuntu系の例で書きます。

1. ログイン失敗の嵐が来ていないか

sudo grep "Failed password" /var/log/auth.log | tail -50
sudo grep "Invalid user" /var/log/auth.log | tail -50

SSHを外部公開しているサーバーなら、世界中からの総当たりで この行が大量に出るのはある意味「日常」です。問題は次の確認です。

2. 不審なログイン成功がないか

sudo grep "Accepted" /var/log/auth.log | tail -50
last -20

Accepted の行がログイン成功です。last はログイン履歴の一覧を出します。 見るポイントはWindowsと同じで、時間・アカウント・接続元の3点です。 普段は社内や特定の拠点からしか入らないサーバーに、見知らぬIPアドレスからの 成功が記録されていないか。深夜の成功、使っていないアカウントの成功がないか。

3. 勝手にアカウントが作られていないか

sudo tail -20 /etc/passwd

ファイルの末尾に、新しく作られたアカウントが追記されていきます。 見覚えのない行が増えていないかを確認してください。 あわせて、管理者になれるアカウントの一覧も見ておきます。

sudo grep -E "sudo|wheel" /etc/group

さらに、次の1行も習慣にしてください。

awk -F: '$3==0 {print $1}' /etc/passwd

これは、rootと同じ最高権限（UID 0）を持つアカウントを列挙するコマンドです。 表示されるのが root だけなら正常。それ以外の名前が出てきたら、 攻撃者が作った裏口アカウントである可能性が極めて高い。 名前は一般ユーザー風でも中身はrootという偽装は、この方法で見抜けます。

4. 勝手に仕込まれたものがないか

自動実行の仕込み先はcronです。

sudo ls -la /etc/cron.d/ /etc/cron.daily/
sudo crontab -l

見覚えのない項目、特に /tmp や /var/tmp 配下のファイルを実行する設定や、 curl や wget で外部から何かを取ってきて実行する行は危険なサインです。

そして、cronと並ぶ——現在ではむしろ主流の——仕込み先がsystemdです。

systemctl list-timers
sudo find /etc/systemd/system -mtime -7 -ls

list-timers は定期実行の一覧（cronのsystemd版）、find のほうは 直近7日でサービス定義が追加・変更されていないかの確認です。 見覚えのないタイマーや、新しく増えた .service ファイルがないかを見てください。

あわせて、1秒で終わる確認をもうひとつ。

cat /etc/ld.so.preload

このファイルは、ほとんどのサーバーでは存在しない （「そのようなファイルやディレクトリはありません」と出る）のが正常です。 ここに登録されたプログラムは、サーバー上のすべてのコマンド実行に割り込めるため、 rootkitと呼ばれる隠蔽型の不正プログラムの定番の住処になっています。 中身が入っていて心当たりがなければ、重大なサインです。

もうひとつ、攻撃者の定番の仕込み先が SSHの公開鍵です。 .ssh/authorized_keys というファイルに公開鍵を1行追加するだけで、 攻撃者はパスワードを変えられても、そのサーバーに入り放題になります。 ログにはただの「鍵認証での正常なログイン」としか残らないため、気づきにくい裏口です。

sudo find /root /home -name authorized_keys -exec ls -la {} \; -exec cat {} \;

各ユーザーの authorized_keys の中身が表示されます。1行が1つの鍵です。 自分たちが登録した覚えのない行が増えていないかを確認してください。 行末のコメント欄（user@hostname のような表記）に見覚えがあるかがひとつの手がかりですが、 コメントは自由に書けるため、それらしく偽装されることもあります。 確実なのは、平常時に正規の鍵の一覧（行数と内容）を控えておき、差分で見ることです。

外部からの接続を待ち受けているプログラムの一覧も見ます。

sudo ss -tlnp

Webサーバーなら80/443、SSHの22など、そのサーバーの役割として説明のつくもの だけが並んでいるのが正常です。役割を説明できないポートで何かが待ち受けていたら、 そのプログラム名を確認してください。

5. いま誰がログインし、どこへ通信しているか

Windows編の6と同じ観点です。過去の記録だけでなく、いまの状態も見ます。

w
sudo ss -tnp state established

w は、いまログイン中のユーザーと接続元の一覧。見知らぬセッションがあれば即異常です。

ss のほうは、いま確立している通信の一覧です。先ほどの -tlnp（待ち受け）と違い、 こちらは外向きの接続、つまりC2通信のチェックになります。 潜伏中のマルウェアはC2サーバーへ自分から接続して指示を待つため、 業務で説明のつかない外向きの接続は強いサインです。 自分のSSH接続、OSの更新、契約しているクラウドサービスへの通信は正常なので、 宛先とプロセス名の両方に説明がつくかで判断してください。 Windows編で書いたとおりC2通信には間欠型もあるため、 一度何もなくても白と断定せず、毎回見続けることが大事です。

6. 不審なファイルがないか

攻撃者の道具は、書き込みやすい一時フォルダーに置かれがちです。

sudo find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls

直近7日間に作られた・変更されたファイルが出ます。心当たりのない実行ファイルや スクリプトがないか。Webサイトを動かしているサーバーなら、公開フォルダー内に 覚えのないファイル（不正な遠隔操作の入口として置かれる、いわゆるWebシェル）が 増えていないかも同様に確認してください。

sudo find /var/www -name "*.php" -mtime -7 -ls

もうひとつ見ておきたいのが、SUIDという特殊な権限（パーミッション4755など）が 付いた見慣れないファイルです。SUIDが付いた実行ファイルは、 誰が実行しても、ファイルの所有者（多くはroot＝管理者）の権限で動きます。 攻撃者は一度rootを取ると、シェル（コマンド実行プログラム）のコピーにSUIDを付けて 置いておき、いつでも一般ユーザーからrootに戻れる裏口にします。

sudo find / -perm -4000 -type f 2>/dev/null

passwd や sudo、su など、OS標準のSUIDファイルは正常でも一定数出てきます。 怪しいのは、/tmp・/var/tmp・/dev/shm・ホームディレクトリ配下にあるものや、 bash のコピーとしか思えないものです。これも平常時に一覧を控えておき、 増えたものがないか差分で見るのが確実です。

7. ログが消されていないか

Linuxではログの消去そのものの記録は標準では残りにくいため、不自然さで見ます。 基本の観点はこの3つです。

  • ログファイルが0バイト・ほぼ空になっている （ls -la /var/log/ でサイズを確認）
  • 時系列の途中に不自然な空白がある（毎分何かしら記録されるはずのログが、 特定の数時間だけ何もない）
  • last の履歴が不自然に短い、途切れている

稼働中のサーバーのログが「きれいさっぱり空」なのは、正常ではまず起きません。 消えていること自体が、最重要のサインです。 ただし誤解しやすい点をひとつ——ログは一定期間ごとに世代交代 （ローテーション）される設定が一般的で、切り替わり直後に現行ファイルが 小さい・ほぼ空なのは正常です。異常なのは、.1 や .gz といった 過去世代のファイルごと消えている、全世代が不自然に空、という状態のほうです。

さらに一歩踏み込むと、次のような消し方の癖まで見抜けます。

「ログアウトだけ」の記録は消された跡

auth.logには、ログインとログアウトが対で記録されます （session opened と session closed）。

sudo grep -E "session opened|session closed" /var/log/auth.log | tail -40

対応する session opened が見当たらないのに session closed だけがある—— これは、攻撃者が自分のログイン記録だけを狙って削除したものの、 ログアウト側の消し忘れや、別ファイルに散った記録までは消し切れなかった跡である 可能性が高い。ログは複数のファイルやサービスに分散して記録されるため、 完全に消すのは攻撃者にとっても難しく、こうした「つじつまの合わない残骸」が 手がかりになります。

ログインしたときの「Last login」表示を毎回見る

SSHでログインすると、最初に前回のログイン記録が表示されます。

Last login: Mon Jul 27 22:14:03 2026 from 203.0.113.45

この1行は、毎回目に入る場所にある無料の侵入検知です。

  • 見慣れないIPアドレスや時刻が表示されたら、自分以外の誰かが そのアカウントでログインした可能性
  • 普段は表示されるのに表示されなくなったら、前回ログインの記録元である lastlog や wtmp といった履歴ファイルが削除・改ざんされた可能性

「いつもの表示と違う」に気づくために、普段からこの行を流し読みせず 確認する習慣をつけてください。

「痕跡消しツール」の消し忘れを見つける

攻撃者の間には、ログイン履歴（wtmp など）から自分の記録だけを消す 専用ツール（zap系などと呼ばれます）が出回っています。ただし、この種のツールの 多くは記録を「削除」するのではなく、該当の行をゼロ（空データ）で上書きするだけです。 last コマンドの表示からは消えますが、ファイルの中には不自然な空レコードが残ります。

sudo utmpdump /var/log/wtmp | tail -50

utmpdump はログイン履歴ファイルの中身を1行ずつそのまま表示するコマンドです。 正常な行にはユーザー名・端末・接続元・日時が入りますが、 ユーザー名や接続元が空欄で、日時だけが 1970-01-01（コンピューターの 時刻の起点）になっている行が混ざっていたら、それはゼロ上書きされた跡—— つまり誰かが履歴を意図的に消した強いサインです。

コマンド履歴が「残らない設定」にされていないか

攻撃者は、自分が実行したコマンドの履歴（.bash_history）も隠します。 単純に削除するほか、履歴ファイルを /dev/null（書き込んだ端から消える 特殊な場所）へのリンクに置き換えるという定番の手口があります。

ls -la /root/.bash_history /home/*/.bash_history

表示の中に -> /dev/null とあれば、それは誰かが意図して 「履歴が残らないように細工した」証拠です。普段使っているサーバーなのに 0バイト、というのも同様に疑ってください。

8. su コマンドがすり替えられていないか

古典的ですが今も警戒すべき手口に、偽の su を仕掛けてrootのパスワードを 盗むというものがあります（いわゆるsuトロイ）。一般ユーザーの権限までしか 取れていない攻撃者が、管理者への昇格を狙って仕掛ける罠です。

仕組みはこうです。攻撃者は、本物そっくりの偽 su を、本物より先に 見つかる場所に置いておきます。管理者が su を実行すると、 偽物がパスワードの入力を受け取ってこっそり記録し、わざと「認証失敗」と 表示して本物に処理を渡します。管理者は「打ち間違えたか」と思って もう一度入力し、2回目は本物なので成功する。違和感はほぼ残りませんが、 rootのパスワードはすでに盗まれています。

チェックは3段階です。

type su
echo $PATH
ls -la /usr/bin/su
  • type su の結果が /usr/bin/su（環境によっては /bin/su）以外の場所—— ホームディレクトリや /tmp 配下——を指していたら、それが偽物です
  • echo $PATH の結果に .（今いるフォルダーの意味）や、誰でも書き込める場所が 含まれていないか。特にシステム標準の場所より前にあれば、偽物を 割り込ませる下地になります

さらに、本物の置き場所そのものが書き換えられていないかは、 パッケージ管理の照合機能で確認できます。

dpkg -V util-linux   # Ubuntu/Debian系
rpm -V util-linux    # RHEL/AlmaLinux系

su を含むパッケージのファイルを、インストール時の記録と照合するコマンドです。 何も表示されなければ改ざんなし。5 を含む行（内容の変更を意味します）が 表示されたら、ファイルが書き換えられています。同じ方法で sudo や openssh-server など、他の重要コマンドのパッケージも照合できます。

日常の症状としては、正しいパスワードを入れたはずなのに1回目だけ 「認証失敗」になり、2回目で通る——これが繰り返されるようなら、 思い込みで流さず、上のチェックを実行してください。

両OS共通——データ持ち出しの前兆を見つける

二重恐喝を仕掛ける攻撃者は、 暗号化の前にデータを外へ持ち出します。その直前の段階では、 盗むデータをまとめた巨大な圧縮ファイルが一時フォルダーなどに 作られることが多く、これは持ち出しの前に気づける数少ないチェックポイントです。

Linuxなら:

sudo find / -xdev -size +500M -mtime -3 -ls 2>/dev/null

WindowsならPowerShellで:

Get-ChildItem C:\Users, C:\ProgramData, C:\Windows\Temp -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $_.Length -gt 500MB -and $_.LastWriteTime -gt (Get-Date).AddDays(-3) }

どちらも、直近3日間に作られた・更新された500MB超のファイルを探します。 バックアップや業務データなど説明のつくものは正常です。 心当たりのない場所に、心当たりのない巨大なzip・rar・7z——これが要注意のサインです。

怪しいものを見つけたら——やってはいけないことが先

ここが本題です。チェックの結果、不審なログイン・見知らぬアカウント・ 消されたログ・不審なファイルを見つけたとき、善意でやりがちな行動が 被害を広げ、調査を不可能にします。

やってはいけないこと

  • 不審なファイルやアカウントを削除して「解決」にしない。 入口が生きていれば攻撃者は戻ってきますし、調査の証拠が消えます
  • サーバーを再起動・シャットダウンしない。メモリ上にしか残らない 手がかりが消えます
  • 「様子を見る」で放置しない。潜伏期間は攻撃者の準備期間です

やるべきこと

  1. ネットワークから切り離す（LANケーブルを抜く。電源は切らない）
  2. 見つけたものを記録する。画面のスクリーンショット、該当ログ行のコピー、 気づいた日時。この記録が、後の調査と保険・取引先への説明の材料になります
  3. 専門家に連絡する。契約しているIT業者やセキュリティベンダー、 公的窓口ならIPA（情報処理推進機構）の相談窓口、 都道府県警察のサイバー犯罪相談窓口があります。 被害の調査（フォレンジック）は専門領域で、自力での完全解明は困難です
  4. 社内の報告ルートに乗せ、 関係者で状況を共有する

「これは黒だ」と確信できるケースは実は少なく、大半は 「怪しい気がするが、正常な動作かもしれない」というグレーです。 グレーの段階で聞ける相手を持っておくことが、このチェックを 実践する上での一番の保険になります。

続けるためのコツ

  • 全部を毎日やる必要はありません。w や query user と外向き通信の確認だけなら 1分で終わるので毎日、ログを含むフルチェックは曜日を決めて週1回、 という組み合わせが現実的です。毎日やろうとして三日坊主になるより、続く方が価値があります
  • 最初の回は「平常時のメモ」を作る。普段ログインする人・時間・接続元、 動いているサービス、待ち受けポートの一覧を控えておく。 次回からは「メモとの差分」を見るだけになり、格段に楽になります
  • チェックした日付を記録する。万一のとき「いつまでは異常がなかったか」が 分かることは、それ自体が調査の重要な手がかりです

なお、この手のチェックを本格化するなら、ログを別サーバーに集約して 自動監視する仕組み（SIEMなど）が専門的な選択肢ですが、 小規模事業者がいきなり導入するものではありません。 まずは手動でも見る習慣があるだけで、まったく見ていない会社とは 発見の早さが段違いです。

まとめ

  • 攻撃には潜伏期間があり、その間の痕跡はログと「いまの状態」の両方に残る
  • Windowsはイベントビューアーの4625・4624・4720・1102・7045に加え、 query user・netstat・Defenderの除外設定・net share・Runキーを見る
  • Linuxはauth.logとlast・/etc/passwd・cron・systemd・authorized_keys・SUID、 w と ss でいまのログインと外向きの通信、 type su と dpkg -V / rpm -V でコマンドのすり替えを見る
  • 潜伏中のマルウェアは外のC2サーバーと通信し続ける。 業務で説明のつかない外向きの接続は、それだけで強いサイン
  • ログが消されていること自体が最重要のサイン
  • 見つけたら、削除も再起動もせず切り離して記録して専門家へ

サプライチェーン攻撃の文脈で、取引先から セキュリティチェックシートが届く時代です。 「何かあってからでは遅い」に対して、小規模事業者が自力でできる最低限の備えが、 この定期チェックとバックアップの分離です。

とはいえ、実際にログを見始めると「この記録は正常なのか異常なのか」という グレーな判断に必ずぶつかります。気になるログや見慣れないファイルを見つけて 判断に迷ったら、該当部分のスクリーンショットやログの抜粋を添えて 無料相談からどうぞ。メールのやり取りだけで「これは平常」「これは専門調査に 回すべき」の見立てをお返しします。