「知らないうちにサーバーが乗っ取られていないか」と不安なら、まず/etc/ld.so.preloadを見てください。2025年2月にPalo Alto Networks傘下の脅威分析チームUnit 42が報告したLinux向けバックドア「Auto-Color」は、このファイルを悪用して自分の存在を隠す手口を使っていました。この記事では、ld.so.preloadの中身の確認、lsof +L1による不審な共有ライブラリ（.soファイル）の点検を、実際に打てるコマンドと出力例つきで解説します。
Auto-Colorとは何か——/etc/ld.so.preloadを悪用するバックドアの手口
/etc/ld.so.preloadは、Linuxのプログラムがライブラリを読み込む仕組み（動的リンカ）に対して「このファイルに書かれた共有ライブラリを、他のどのライブラリより先に、すべてのプログラムに強制的に読み込ませる」という指示を出すための設定ファイルです。デバッグ用途などで使われることもある正規の仕組みですが、これはつまり「ここに悪意あるライブラリのパスを書き込めば、サーバー上で動くほぼ全てのプログラムに勝手にコードを注入できる」ということでもあります。
Unit 42が2025年2月に報告したAuto-Colorは、北米・アジアの大学や政府機関を狙ったLinux向けバックドアで、感染すると自分自身を/etc/ld.so.preloadに登録し、悪意ある共有ライブラリを常時読み込ませる形で居座りました。このライブラリはファイル一覧やプロセス一覧を返す標準的な関数の動きを横から書き換え、自分に関連するファイルやプロセス、通信を通常のコマンド結果から見えなくする（＝隠蔽する）よう作られていたと報告されています。
なぜps・lsコマンドだけでは気づけないのか
攻撃手法そのものの再現はここでは扱いませんが、防御側として押さえておくべきポイントは1つです。ld.so.preloadに悪意あるライブラリが登録されていると、そのライブラリ自体が「調べるためのコマンド」の内部動作に介入してくる可能性があるため、通常のps・ls・netstatの目視確認をすり抜けることがあるという点です。だからこそ、ld.so.preloadというファイル自体を直接見に行く点検が重要になります。
まず/etc/ld.so.preloadの中身をcatで確認する
sudoは不要です（このファイルは通常誰でも読み取れる権限で置かれています）。まずは中身をそのまま見るところから始めます。
cat /etc/ld.so.preload何を見ているか：このファイルに強制読み込みされる共有ライブラリのパスが1行ずつ書かれているかどうかです。
状態 | 出力例 | 判断 |
|---|---|---|
正常（多くのUbuntu/Debian環境） |
| ファイル自体が存在しない。これが最も一般的な状態 |
正常（何も登録されていない） | （何も表示されず、次のプロンプトに戻る） | ファイルはあるが中身が空。問題なし |
要確認 |
| 聞き覚えのないパス・ファイル名。次の章の手順で出どころを確認する |
あわせてファイルの所有者・権限も見ておきます。
ls -l /etc/ld.so.preload正常な出力例（ファイルが存在する場合）：
-rw-r--r-- 1 root root 42 Sep 1 09:00 /etc/ld.so.preload所有者がroot root以外になっていたり、直近であなたが変更した覚えのない日時に更新されていたりする場合は要注意です。なお、環境によっては/etc/ld.so.preload.d/のような分割ディレクトリを使う場合もあるため、同じディレクトリ内に似た名前のファイルが無いかもls -la /etc/ | grep preloadで軽く確認しておくと安心です。
見つかったパスの出どころをdpkg -Sとfileで鑑定する
ld.so.preloadに何か書かれていた場合、そのパスが正規のパッケージ由来のファイルかどうかを確認します。Ubuntu/Debianでは、インストール済みのファイルがどのパッケージに属するかをdpkg -Sで逆引きできます。
dpkg -S /usr/lib/x86_64-linux-gnu/libcap-helper.so何を見ているか：そのファイルパスを「自分がインストールしたはずのソフトウェア」がパッケージ管理システム経由で持っているかどうかです。
- 正常：
libcap2:amd64: /usr/lib/x86_64-linux-gnu/libcap-helper.soのように、見覚えのあるパッケージ名が返ってくる。 - 異常：
dpkg-query: no path found matching pattern ...と返ってくる。パッケージ管理を通さずに後から置かれたファイルである可能性が高く、要注意です。
あわせてファイルの種類とサイズ・更新日時も見ておきます。
file /usr/lib/x86_64-linux-gnu/libcap-helper.so
ls -la /usr/lib/x86_64-linux-gnu/libcap-helper.sofileコマンドは「ELF 64-bit LSB shared object」のようにファイルの実体の種類を表示します。拡張子は.soなのに中身がテキストファイルやスクリプトだったり、システム構築時期よりずっと後の日付で作成されていたりする場合は、正規のライブラリを装った別物である可能性があります。XZ Utils教訓｜debsumsで改ざん点検2026年9月で紹介したdebsumsを使えば、パッケージ由来のファイル全体がインストール時から改ざんされていないかを一括でチェックできるので、あわせて実行しておくとより確実です。
lsof +L1で「消えたのに動いているファイル」を探す
もう一つ、rootkit系のマルウェアがよく使う隠蔽テクニックが「ファイルをディスク上からは削除しておきながら、プロセスにはそのファイルを開いたままにしておく」というものです。これを見つけるのがlsof +L1です。
sudo lsof +L1何を見ているか：リンク数（そのファイルにディレクトリからアクセスできる経路の数）が1未満、つまり0になっている＝ディレクトリ上からは既に削除済みなのに、どこかのプロセスがまだ掴んで動かし続けているファイルです。
出力例（列はCOMMAND・PID・USER・FD・TYPE・DEVICE・SIZE/OFF・NLINK・NODE・NAMEの順）：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
rsyslogd 612 syslog mem REG 259,3 38208 0 131074 /var/log/journal/xxxx.journal (deleted)
suspiciou 4821 username mem REG 259,3 91200 0 131980 /usr/lib/x86_64-linux-gnu/libcap-helper.so (deleted)1行目のようにrsyslogdやログローテーションに絡む一時的な削除済みログファイルは日常的によく出るので、それ自体は異常ではありません。判断のポイントはファイル名の末尾に(deleted)がついた.soファイルを、見覚えのないプロセスが掴んでいるかどうかです。2行目のように、聞いたことのないコマンド名やuser欄がroot以外なのにroot権限で動いていそうなプロセスが、削除済みの共有ライブラリを開きっぱなしにしていたら要確認です。ps -p 4821 -fでそのPIDが何のプロセスか、いつ起動したかを確認します。
怪しいエントリが見つかったときの対処
ここから先はファイルの変更を伴います。設定変更・sudoが必要な作業なので、必ず手順通りバックアップを取ってから進めてください。
- バックアップを取る：
sudo cp /etc/ld.so.preload /etc/ld.so.preload.bak_20260919元に戻す必要が出たら
sudo cp /etc/ld.so.preload.bak_20260919 /etc/ld.so.preloadで復元できます。 - 不審な行を削除する：
sudo nano /etc/ld.so.preload該当行を消して保存します（
Ctrl+O→Enter→Ctrl+X）。登録内容が全て不審なものだけだった場合は、ファイルごと空にするかsudo rm /etc/ld.so.preloadで削除して構いません（多くのUbuntu/Debian環境では、このファイルが存在しないのが標準状態です）。 - 第三者の目でも確認する：自分の判断だけに頼らず、rootkit検出ツールでも裏取りします。
sudo apt install rkhunter -y sudo rkhunter --check導入だけで動作が変わることはなく、チェックが走るだけです。不要になれば
sudo apt remove rkhunterで削除できます。 - 判断に迷う場合は先に切り離す：どのファイルが原因か特定できない、または本番で動かし続けるのが不安な場合は、無理に自己判断で削除を進めず、いったんネットワークから切り離す（LANケーブルを抜く、ファイアウォールで外向き通信を止める）などして被害の広がりを止めてから、落ち着いて調査してください。
日常的にできる予防点検
ld.so.preloadの点検は一度きりで終わらせず、他の点検と組み合わせて定期的に行うのが効果的です。
- パッケージ由来のファイルが改ざんされていないかはXZ Utils教訓｜debsumsで改ざん点検2026年9月のdebsumsで一括確認できます。
- Auto-Colorのようなバックドアは、居座った後に権限昇格の脆弱性と組み合わせて悪用されるケースがあるため、CVE-2026-31431点検|userns制限2026年9月もあわせて確認しておくと安心です。
- OS本体を最新の状態に保つのも基本の予防策です。Debianは2026年9月12日に安定版のポイントリリース13.7を、Ubuntuは2026年9月11日に24.04.5 LTSを公開しており、いずれもセキュリティ修正が中心の更新です。
sudo apt update && sudo apt upgradeを定期的に実行しておくことで、既知の脆弱性を突く形の侵入経路をふさげます。
なお、CentOSやRHEL系ではライブラリの標準パスが/lib64/や/usr/lib64/になるなど本文中の例とは異なりますが、/etc/ld.so.preload自体の位置や役割、lsof +L1の使い方は共通です。
まとめ
Auto-Colorの教訓は、「侵入されたかどうかは、通常のコマンドの見た目だけでは判断できないことがある」という点です。cat /etc/ld.so.preloadで強制読み込み設定の有無を確認し、見つかったパスはdpkg -Sで出どころを、sudo lsof +L1で削除済みなのに動き続けているファイルがないかを点検すれば、この手口による隠蔽をすり抜けにくくなります。いずれも読み取りだけなら環境を壊す心配はありません。月に一度でよいので、他の点検とあわせてルーティンに組み込んでおくことをおすすめします。