パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知
宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「パッチを当てた。再起動もした。これで終わり」

そう思っていたのが、ここ数日で揺らいでいます。

2026年4月24日、CISA（米国サイバーセキュリティ・社会基盤安全保障庁）が勧告 AR26-113A を出しました。Ciscoのファイアウォール製品（ASA/Firepower）に、Linuxの実行ファイル形式（ELF）で書かれた永続化バックドア「FIRESTARTER」が仕込まれていた、という内容です。攻撃者はUAT-4356。2024年に騒がれた ArcaneDoor と同じグループだそうです。

正直、最初に読んだとき「これはきつい」と声に出ました。

何がきついかというと、パッチを当てても消えないからです。ファームウェアを更新しても消えない。普通に再起動しても消えない。

この記事では、20年以上Linuxサーバーの運用に関わってきた立場から、FIRESTARTERのインシデントを「Cisco機器の話」で終わらせず、汎用Linuxサーバーの永続化バックドア検知という実務にどう落とすかを書きます。
auditd、AIDE、systemd、ss、lsof、/proc、rkhunter、YARA。記事を読み終わるころには、自分のサーバーで何を見るべきかが具体的に分かる構成にしました。
パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

FIRESTARTERで何が起きたか

3行でまとめると、こうなります。

・攻撃者は2025年9月、米連邦民間機関のCisco ASAに侵入し、ELF型の永続化バックドアを設置した
・初期侵入はCVE-2025-20333（バッファオーバーフロー／CWE-120／CVSS 9.9のRCE）とCVE-2025-20362（認可不備／Missing Authorization／CWE-862／CVSS 6.5）の組み合わせ。両方とも2025年9月にはCisco修正版が出ていた n-day（既知だがまだ叩かれる脆弱性）です
・侵入後はLINA（ASAのコアエンジン）プロセスのメモリを書き換え、WebVPNハンドラを乗っ取る。外向きの通信は一切しない

最後のところがいやらしくて、攻撃者の側からビーコンを打たないんです。被害側のサーバーが「なんか変だな」と気づくきっかけを意図的に消している。

同じグループは LINE VIPER という別のマルウェアも併用しています。こちらはユーザーモードのシェルコードローダーで、CLI実行・パケットキャプチャ・AAAバイパス・syslog抑止までやる。要するに、入ったあとで「証拠を残さず・気付かれず・好きに動く」ための一式を持ち込んでくる相手です。

Cisco/CISA/NCSCの三者が連名で勧告を出すレベルのインシデントは、年に何回もありません。

パッチを当てても残る ── n-day侵入の本当の怖さ

CVE-2025-20333と20362は、2025年9月にパッチがリリースされています。

ここで一度、自分の運用を思い出してみてほしいです。

たとえばサーバー管理を任されている境界機器（ファイアウォール、VPN、ロードバランサ）に、9月リリースのパッチを「その月のうちに」当て切れていますか。私はSE時代、業務影響の調整で「翌月の定期メンテで」と先送りにしたことが何度もあります。なんなら四半期メンテに丸めたことすらある。

攻撃者はそこを見ています。

n-day脆弱性とは「公開されてはいるが、まだあちこちに残っている脆弱性」のことです。0-dayより手間が掛からず、パッチが行き渡るまでの数週間〜数ヶ月で大量のターゲットを刈り取れる。今回のFIRESTARTERは、まさにこの隙間で動いた事例です。

もうひとつ、本気で怖いのはここからです。

仮に9月の修正版を当てたとしても、それより前にすでに侵入されていた場合、パッチ適用は何の意味もありません。

バックドアは脆弱性経由で入った後、別の場所に居座ります。脆弱性を塞いでも、居座った先までは塞げない。「パッチを当てた＝完了」という思考停止こそが、現代の永続化マルウェアにとって一番ありがたい思考停止です。

これはCisco固有の話ではありません。Linuxでもまったく同じ話があります。SSHの脆弱性で入られたあと、パッチを当ててssh周りをきれいにしても、/usr/local/binに置かれた偽バイナリが残っていればそこから何度でも復活されます。
パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知 - 解説1

永続化の手口を読み解く ── lina_cs / CSP_MOUNT_LIST / svc_samcore.log

ここがFIRESTARTERの「最大の見せ場」です。

普通、Linuxの永続化と聞いて思い浮かべるのは以下あたりではないでしょうか。

・systemdのservice unitとして登録される
・cronに行を足される
・/etc/rc.localや/etc/profile.dに仕込まれる
・SSHのauthorized_keysに鍵を足される

FIRESTARTERは、このどれも使いません。

代わりに3つのパーツを使います。

・/usr/bin/lina_cs ── これが本体。正規プロセスの「LINA」に「_cs」を付けただけのファイル名。psで眺めて見落とさせる擬態です
・/opt/cisco/platform/logs/var/log/svc_samcore.log ── 中身は実行ファイル。拡張子がlogで、ログディレクトリにあるため、運用者の目をすり抜けます
・/opt/cisco/config/platform/rmdb/CSP_MOUNT_LIST ── 起動時に何をマウント・実行するかの設定ファイル。ここを書き換えることで、systemdにもcronにも痕跡を残さずに「ブート時に自分を起動する」を実現しています

極めつけはshutdownの挙動です。

このマルウェアはSIGTERMを傍受して、自分自身を svc_samcore.log にコピーしてから死にます。次のブートで CSP_MOUNT_LIST が svc_samcore.log を読み込んで lina_cs として復活させ、その復活処理の中で CSP_MOUNT_LIST を元の状態に書き戻す。つまり、稼働中のシステムを静かに調べただけでは、書き換えの痕跡が見当たらないんです。

graceful shutdown（正規の手順での再起動）も、ファームウェア更新も、セキュリティパッチも、全部生き延びる。

唯一消えるのは、最低1分以上の完全な電源遮断（コールドリスタート）でメモリ常駐部分が落ちたときだけ。Cisco／CISA側は「単なる電源OFFや再起動では除去できず、最低1分の完全電源遮断が必要」と明記しています。一方で電源遮断はメモリ常駐の証拠を消し、ディスクやDB破損のリスクもあるため、本番機は事前のフォレンジック手順整備が前提になります。

ここまで読んで、自分の運用しているLinuxサーバーで「systemctlとcrontabしか見ていない」と気づいた方、私は同じです。これは反省点として正直に書いておきます。

C2が「自分から喋らない」設計

普通のマルウェアは、定期的にC2サーバー（指令サーバー）にビーコンを打ちます。生存報告と指令受信のためです。

ここをトラッキングするのが、IDS/SIEM/EDRの主戦場でした。「外向きの不審な通信」を見つける、という。

FIRESTARTERは、外向き通信を一切出しません。

何をやっているかというと、LINAプロセス（WebVPNを処理する正規プロセス）のメモリ上で、XMLハンドラ関数のオフセットを自分の不正ハンドラに置き換えます。受信したXMLにあらかじめ決めたマジックバイトが入っていれば、続くデータをシェルコードとしてメモリ上で実行する。マジックバイトがなければ、そのまま正規のWebVPN処理に流す。

つまり、攻撃者は「新しい接続を開く」のではなく、「既に開いている正規のWebVPNセッション」に便乗する。完全なパッシブ寄生です。

何が問題かというと、出口の監視（プロキシログ、ファイアウォールの外向きルール、DNSログ）では絶対に見つからない。常に内向き通信に紛れているからです。

これはLinuxサーバーの運用にもそのまま跳ね返ってきます。よくある対策で「不審な外向き通信を切る」というのがありますが、相手がパッシブ寄生型ならその対策は素通りされます。攻撃者にとって都合のいい姿勢でしか動かないので、外向き監視に対するすり抜けはむしろ設計上の前提です。

私はかつて、proxyのアクセスログだけを見て「外向きは綺麗ですね」と報告したことがあります。あの報告は、いま振り返ると不十分でした。
パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知 - 解説2

これは他人事か？ ── 汎用Linuxサーバーへの教訓

「うちはCiscoのASAなんて使っていない」と思った方、私もそう思いました。

でも、ASAの中身はLinuxです。FIRESTARTERはELF（Linuxの実行ファイル形式）です。乗っ取られているのは、Linuxプロセスのメモリです。

今回の事例から汎用Linuxサーバーに転用される可能性のある手口を抜き出すと、こうなります。

・正規プロセス名 + 1〜2文字の擬態（sshd → sshdd、nginx → nginxs みたいなやつ）
・logディレクトリに実行ファイルを置く（/var/log配下を意外と運用者は見ていない）
・マウント・初期化系の設定ファイル書き換えでブート時実行を仕込む（/etc/fstab、/etc/initramfs-tools/scripts/、Dracut系のフック）
・正規プロセスのメモリ上で関数フックする（LD_PRELOADや、procfs経由の/proc/PID/mem書き換え）
・外向き通信ゼロのパッシブ寄生（Apache/Nginxのリクエスト処理関数を乗っ取り、特定のヘッダーが来たときだけ反応する）

このうちのどれかでも自分のサーバーで動かれていたら、systemctl status と crontab -l しか見ていない運用ではほぼ確実に見落とします。

正直に書きますが、私自身、若い頃に踏み台にされた事故があります。/usr/sbin/initd という実在しないファイル名（initに似せた偽物）でプロセスが上がっていて、psで見ても流してしまっていました。気づいたきっかけは外部からの帯域使用量の通報。半月、放置していたことになります。

永続化バックドアの検知実務

ここからは、私が今のサーバーで実際に使っているチェックを並べます。Cisco機器の話ではなく、汎用Linuxサーバーの話です。

全部やる必要はありません。最初の3つだけでも入れておけば、見える範囲がだいぶ広がります。

1. auditdで設定ファイル・実行ファイルの書き換えを記録する

systemd・cron・初期化系の設定ファイルが書き換わったら、auditdで記録を残します。

/etc/audit/rules.d/persistence.rules に以下のような行を入れて、auditctl -R で読み込ませます。

# 永続化に使われやすいパスを監視する例
-w /etc/systemd/system/ -p wa -k persistence_systemd
-w /lib/systemd/system/ -p wa -k persistence_systemd
-w /etc/cron.d/ -p wa -k persistence_cron
-w /etc/cron.daily/ -p wa -k persistence_cron
-w /etc/rc.local -p wa -k persistence_rc
-w /etc/init.d/ -p wa -k persistence_init
-w /etc/profile.d/ -p wa -k persistence_profile
-w /root/.ssh/authorized_keys -p wa -k persistence_ssh
-w /home -p wa -k persistence_home_ssh
ポイントは「-p wa」（書き込みと属性変更を見る）と「-k」でキーを付けておくことです。あとからausearch -k persistence_systemd でその種類だけ抽出できます。

2. AIDEで「ファイルが書き変わった」事実を毎晩比較する

AIDEはファイルのハッシュ値データベースを取って、差分を毎日メールするための仕組みです。

インストール後、aide --init で初期DBを作り、/etc/aide.confで監視対象を絞ります。重要なのは「初期DBを作る瞬間が、そのサーバーがクリーンであるという前提」です。すでに侵入されているサーバーで--initすると、悪性ファイルがクリーン扱いされます。

# 初期化（クリーンな状態でのみ実行）
sudo aide --init
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# 毎晩cronで差分比較
sudo aide --check
差分が出たメールを「いつものパッケージ更新だろう」と読み流さないこと。これはSE時代の自分への一番の戒めです。

3. systemdの異常ユニットをワンライナーで洗う

新規追加・編集されたservice unitに不審なExecStartが無いかを、寝る前に1回叩くだけでも違います。

# 過去24時間で更新された.serviceファイルの一覧
sudo find /etc/systemd /usr/lib/systemd -name "*.service" -mtime -1 -ls

# enabledなunitのExecStartを一気に出す
systemctl list-unit-files --state=enabled --type=service | awk 'NR>1 {print $1}' | \
  xargs -I{} systemctl cat {} 2>/dev/null | grep -E "^ExecStart="
特に怪しいのは、/tmp、/var/tmp、/dev/shm、/home配下を実行する ExecStart です。普通のサーバー運用でこれらのパスを実行するunitはほぼありません。

4. ss / lsof で「謎のリッスン」を確認する

ss -tlnp と lsof -i -P -n を定期的に走らせて、見覚えのないリッスンポートとプロセスを洗います。

# 全TCPリッスンとプロセスを確認
sudo ss -tlnp

# 開いているファイル・ソケットの全体像
sudo lsof -i -P -n | head -50
FIRESTARTERのようなパッシブ寄生型は新しいポートを開かないので、ss/lsofだけでは見つからない場合もあります。それでも「正規プロセスが想定外のポートを掴んでいる」ことはあるので、最低限のベースラインとして毎日確認する価値はあると思います。

5. /proc 経由で「実行ファイルが消えているのに動いているプロセス」を炙る

これは個人的に好きなチェックです。攻撃者が侵入後、自分のバイナリをディスクから削除してプロセスだけ生かす（メモリ上で稼働を続ける）パターンを見つけられます。

# /proc/PID/exe が削除済み（deleted）になっているプロセスを抽出
sudo ls -la /proc/*/exe 2>/dev/null | grep -i deleted
正規のアップデート直後（パッケージ更新でバイナリが置換されたが古いプロセスが動いている状態）でも引っかかるので、systemctl restartで現行バイナリに揃えてから再確認するのが正解です。それでも残るプロセスは、本気で疑ったほうがいい。

私が踏み台にされた時に最終的に犯人を特定したのが、このチェックでした。

6. rkhunter / chkrootkit / Lynis で外部ツールにも目を借りる

自分の目と手元のツールだけだと、知らない手口を見落とします。

・rkhunter ── 既知のルートキット署名と、SUIDバイナリ/隠しファイルの異常検知
・chkrootkit ── psやlsがトロイ化されているかの確認
・Lynis ── システム全体のセキュリティ姿勢監査（auditd未設定、AIDE未導入なども指摘してくれる）

3つとも誤検知はあります。でも、誤検知を1つずつ潰していく作業の中で、自分のサーバーの「正常状態」が見えてきます。それが何より重要なんだと思います。

7. YARAでバイナリ・メモリの既知パターンマッチ

YARAは、マルウェアの特徴的なバイト列をルールにしておいて、ファイルやプロセスメモリをスキャンするツールです。

今回のFIRESTARTERのようなインシデントでは、Talosが公開するYARAルールをそのまま流用できる場合があります。

# /usr/binと/optを既知ルールでスキャンする例
yara -r /path/to/firestarter.yar /usr/bin /opt
実運用で大事なのは「公開されたYARAルールを定期的に取り込む仕組み」を持っておくこと。インシデント発生のたびに自分でルールを書くより、信頼できる出元のルールを取り込み続ける方が、コストも品質も合います。
パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知 - 解説3

運用と捜査の衝突 ── 「電源を抜く」が正解とは限らない

ここはCISAの勧告で一番考えさせられた部分です。

FIRESTARTERは、最低1分の完全電源遮断でメモリ常駐部分が消えます。「じゃあ怪しかったら電源抜けばいいのか」と思いますが、ここで一拍置きたい。電源遮断はメモリ常駐の証拠（コード・キー・直前のシェルコード・通信履歴）を一気に消し、さらにディスクやDB破損のリスクもあります。本番機での緊急対応は、事前のフォレンジック手順整備が前提になります。

理由は、消えるのが攻撃者にとって都合のいい証拠だからです。

パッシブ寄生型のマルウェアはメモリ上にしか存在しない部分があります。電源を切れば、そこにあったコード・キー・通信履歴・直前にやり取りしたシェルコード、全部消える。攻撃者がやってきたことの再現と、横展開先（同じ攻撃者に侵入された他のシステム）の特定が、いきなり困難になります。

つまり、運用としての「即復旧」と捜査としての「証拠保全」が、真っ向からぶつかる。

ここは事前にルールを決めておく以外に方法がないと思います。

・「侵入の疑い」が立った時に、誰が判断して、誰がメモリダンプを取り、誰が電源を落とすのか
・本番停止のSLAと、フォレンジック対応のSLAのどちらを優先するか
・外部のインシデントレスポンス会社に依頼する場合の連絡先と契約形態

これを「事故が起きた時に決めればいい」と先送りにすると、現場で判断が止まります。SE時代に一度やらかしたのですが、緊急時の判断をその場でやろうとすると、絶対に綺麗な手順にはなりません。

まとめ：パッチ＝完了の思考停止を捨てる

FIRESTARTERから持ち帰るべき教訓を、表で整理します。
論点 従来の常識 今後の前提
パッチ適用 当てたら終わり 適用前に侵入されていた可能性も常に検討する
永続化の場所 systemd / cron を見ておけばいい マウント設定・初期化フック・logディレクトリも見る
C2監視 外向き通信の異常検知が中心 パッシブ寄生型は内向きセッションへの便乗を疑う
緊急時対応 とにかく早く再起動・電源断 証拠保全とのバランスを事前に決めておく
検知の手数 ウイルス対策ソフト任せ auditd/AIDE/proc監査/YARAを多層で組む
「パッチを当てた、再起動した、終わり」ではなく、「侵入されていた前提で、何を見ればいいか」を平時から仕込んでおく。

これは20年以上Linuxの運用に関わってきて、自分にも何度も言い聞かせてきた話です。私自身、踏み台にされて半月気づかなかった経験があります。あのときの「気づくのが遅れた」という感覚は、今でも残っています。

今回のFIRESTARTERは「パッチ＝完了」という思考停止を、これ以上ない形で揺さぶってきました。Cisco機器を持っていない方も、汎用Linuxサーバーを運用している以上、明日の自分の話だと思って読み直すだけの価値はあると思います。
パッチを当てても消えないバックドア｜FIRESTARTERから学ぶLinuxサーバの永続化検知 - まとめ

参考

・Cisco Talos「UAT-4356 / FIRESTARTER」分析: https://blog.talosintelligence.com/uat-4356-firestarter/
・CISA Analysis Report AR26-113A: https://www.cisa.gov/news-events/analysis-reports/ar26-113a
・CISA MAR（Malware Analysis Report）PDF: https://www.cisa.gov/sites/default/files/2026-04/AR26-113A_MAR_FIRESTARTER_backdoor.pdf

「パッチを当てて終わり」から一歩抜け出す運用の型を身につけませんか？

auditd、AIDE、systemd監査、proc整合性チェック。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

Linux無料マニュアル（図解60P） 名前とメールで30秒登録