2026.10.13 セキュリティ

Webシェルとは？Tomcatへの設置手口と検知・除去の手順をコマンド例で解説

Webシェルは、公開Webサーバーに置かれ、ブラウザやHTTPクライアントからOSコマンドを実行させる不正なスクリプトです。JPCERT/CCは2026年10月9日、国内組織への不正アクセスの注意喚起に、WARファイルでJSPのWebシェルを設置する手口を追記しました。本記事では、Webシェルの定義と設置の流れを押さえたうえで、Tomcatを例に、ファイル監視・プロセス監視・アクセスログ集計で見つける手順、証拠を残して除去する順序、設置経路を塞ぐ設定までをコマンド例つきで扱います。不正アクセスの痕跡調査全体の進め方はセキュリティログ分析の手法｜不正アクセスの痕跡を見つける手順とコマンド例を前提にしています。

まとめ：Webシェルの正体とTomcat公開サーバーで今日始める検知と除去

Webシェルは侵入の入口ではなく、侵入した攻撃者が居座るための足場です。脆弱性や管理画面の不備で一度入られると、Webサーバーの実行ユーザーの権限でコマンドを何度でも打てる状態が残ります。

検知で先に入れるべきは2つです。デプロイ済みファイルのハッシュ基準線を取り、webapps配下に増えたファイルと変わったファイルを毎日比べること。そして、Tomcatの実行ユーザーがシェルやcurlを起動した記録をauditdで残すことです。ウイルス対策ソフトの署名照合は補助と考えてください。

見つけたら、すぐに消さずに証拠を複製してから止めます。シェルの起動記録が1件でも残っていれば、ファイル削除で済ませずサーバーを作り直す判断が妥当です。

Webシェルの定義とJPCERTが2026年10月に報告したWAR経由の設置手口

最初に、Webシェルが何を指すのかと、今回報告された手口の具体を確認します。

MITRE ATT&CK T1505.003の定義とバックドアとの違い

攻撃手法の分類として広く参照されるMITRE ATT&CKのT1505.003（Web Shell）は、Webシェルを「公開されたWebサーバーに置かれるWebスクリプト」と定義し、目的を永続的なアクセスの確保（Persistence）に分類しています。2026年5月更新のv1.5時点で、対象はLinux・Windows・macOS・ネットワーク機器です。

一般的なバックドア型マルウェアとの違いは、通信の形にあります。専用の通信ポートを開く代わりに、Webサーバーが元から受け付けている80番や443番のHTTPリクエストに命令を載せるため、ファイアウォールの通過許可をそのまま使えます。中身はPHP・JSP・ASP.NETなど、サーバーが実行できる言語の数行で足りる。

JPCERT注意喚起ケースDにみるWARファイルとJSPによる設置の流れ

JPCERT/CCの注意喚起（JPCERT-AT-2026-0030）は2026年10月8日に公開され、翌9日の更新でケースDが加わりました。公開Webサーバーからアクセスできるアプリケーションサーバー上にWARファイルが設置され、中のJSPファイルが簡易的なWebシェルとして動いた事案です。このJSPは、特定のクエリパラメーターの値を取り出してシェルコマンドとして実行します。

WARはJavaのWebアプリケーションをまとめたアーカイブで、Tomcatはこれをwebapps配下に置くだけで展開して公開します。つまり攻撃者は、WARを1つ送り込めれば、そのJSPのURLを叩くだけでコマンドを実行できる。同じ注意喚起には、9月ごろにGETとPOSTを繰り返した送信元として124.133.237.18が載っています。正規の利用元である可能性も注記されているため、単独で遮断の根拠にせず、手元のログとの照合に使ってください。

Manager公開・自動デプロイ・アップロード機能という3つの侵入口

Tomcatの環境でWebシェルが置かれる経路は、実務上は次の3つにほぼ収まります。

Managerアプリが外部に公開され、弱いパスワードで管理者ログインされる
Tomcatやアプリの既知の脆弱性を突かれ、webapps配下へファイルを書き込まれる
アプリのファイルアップロード機能が拡張子と保存先を検査せず、JSPを公開ディレクトリに受け入れる

1つ目は、Tomcat公式のSecurity Considerationsも、弱いパスワードと公開されたManagerの組み合わせで頻繁に狙われると明記しています。2つ目はApache Tomcatの脆弱性一覧【2026年9月】で自社の版が対象か確かめてください。3つ目の事例として、PhotoGoodsの不正アクセスとアップロード機能の締め方とスカラコミュニケーションズの不正アクセスと最大71万件も参考になります。

Tomcat公開サーバーでWebシェルを見つけるファイル監視とプロセス監視の手順

検知の考え方は、NSAとオーストラリア信号局が公開したMitigating-Web-Shellsの整理に沿うと抜けが減ります。正しい状態との差分、Webサーバーが起こしたプロセス、アクセスログの偏りの3方向から見ます。

webapps配下の新規・更新ファイルをfindとハッシュ基準線で洗い出す

まず、直近に作られたり変わったりしたJSPとWARを一覧にします。$CATALINA_BASEはTomcatの設置先に読み替えてください。

find "$CATALINA_BASE/webapps" -type f \( -name '*.jsp' -o -name '*.jspx' -o -name '*.war' \) \
  -newermt '2026-09-01' -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort

更新日時は攻撃者が書き換えられるので、本命はハッシュの基準線です。正規のデプロイ直後に全ファイルのSHA-256を記録し、以後は定期的に照合します。

# デプロイ直後に基準線を作る（書き込み不可の場所に保管する）
find "$CATALINA_BASE/webapps" -type f -print0 | xargs -0 sha256sum > /root/baseline.sha256

# 照合：変更・削除されたファイルだけを表示する
sha256sum -c --quiet /root/baseline.sha256

# 新しく増えたファイルを表示する
comm -13 <(awk '{print $2}' /root/baseline.sha256 | sort) \
  <(find "$CATALINA_BASE/webapps" -type f | sort)

sha256sum -cは基準線にあるファイルの変更しか見ないため、増えたファイルはcommで別に拾います。MITREの検知例AN1108も、Webディレクトリへの想定外のファイル作成を起点に置いています。ハッシュで改ざんを見分ける原理はハッシュ化とは？暗号化との違いと改ざん検知の仕組みで解説しました。

auditdでtomcatユーザーのexecveを記録しシェル起動を捉える設定

ファイル監視は「置かれた」ことを捉え、プロセス監視は「使われた」ことを捉えます。Tomcatの実行ユーザーがsh・bash・curl・whoamiを起動することは、通常の業務ではほぼ起きません。Mitigating-Web-ShellsのREADMEがApache向けに示すauditdの規則を、Tomcatの実行ユーザーに置き換えた例です。

# /etc/audit/rules.d/webshell.rules
# 1001 は id -u tomcat で確認した実行ユーザーのUIDに置き換える
-a always,exit -F arch=b64 -F uid=1001 -S execve -k tomcat_exec
-a always,exit -F arch=b32 -F uid=1001 -S execve -k tomcat_exec

# 反映と確認
augenrules --load
ausearch -k tomcat_exec -i | grep -oE 'exe=[^ ]+' | sort | uniq -c | sort -rn

Javaアプリが正規に外部コマンドを呼ぶ設計なら、その実行ファイルを除外してから通知につなぎます。複数台を横断して親子プロセスを追うなら、EDRとは？EPP・XDRとの違いと検知の仕組みで扱った製品の守備範囲になります。

アクセスログから少数の送信元しか叩かないJSPを抽出する集計

Webシェルへのアクセスは、ごく少数の送信元からクエリ付きで繰り返されるという偏りを持ちます。TomcatのAccessLogValveが出力する既定の形式なら、次の集計でJSPごとの送信元の数を並べられます。

cd "$CATALINA_BASE/logs"
awk '$7 ~ /\.jspx?(\?|$)/ {split($7,a,"?"); print a[1], $1}' localhost_access_log.*.txt \
  | sort -u | awk '{n[$1]++} END {for (u in n) print n[u], u}' | sort -n | head -20

# 注意喚起に載った送信元との照合
grep -h '124\.133\.237\.18' localhost_access_log.*.txt

送信元が1〜2件しかないJSPは、正規の画面かどうかをソース管理と突き合わせます。誤検知は多めに出るので、ファイル監視とプロセス監視で絞った後の裏付けに使うのが向いている。ログの保存期間や他のログとの突き合わせ方はセキュリティログ分析の手法で手順化しています。

Webシェル発見後に証拠を残して除去し再発を防ぐまでの作業順

見つけた後の数時間で、調査できる範囲が決まります。焦って消すと、何をされたかを後から確かめられなくなります。

undeployの前に証拠を保全するstop・複製・ハッシュ記録の順序

Tomcat公式のManager App How-Toは、undeployがappBase内のWARと展開済みディレクトリを削除すると警告し、止めるだけなら/stopを使うよう案内しています。除去は次の順で進めます。

該当サーバーを外部から切り離すか、ロードバランサーから外す
WAR・展開ディレクトリ・ログ一式を別の媒体へ複製し、SHA-256を記録する
Managerの/stopか、Tomcatの停止で該当アプリを止める
Managerのアクセスログとauditdの記録から、設置日時と実行されたコマンドを確定する
侵入口を塞いでから、正規の成果物で再デプロイする

2の複製では、メモリ上の状態も失われる点に注意してください。調査会社に渡す可能性があるなら、電源を落とす前に相談するほうが残せる情報は多くなります。

ファイル削除で済ませずOSからサーバーを再構築すべき実行痕跡の判定条件

判断を言い切ります。auditdやEDRに、Tomcatの実行ユーザーによるシェルやダウンロードコマンドの起動が1件でもあれば、ファイルを消して運用を続けることはしません。攻撃者が別のバックドアや認証情報を置いている前提で、OSから作り直します。

あわせて、tomcat-users.xmlのパスワード、アプリが持つDBの接続情報、APIキー、サーバー上のSSH鍵をすべて入れ替えてください。JPCERTの注意喚起も、Webサーバー侵害後の横展開対策の見直しを挙げています。個人情報が漏れた可能性があるときの調査範囲と報告期限はフォレンジック調査とは？流れ・費用・調査項目と依頼先の選び方にまとめました。

逆に、ファイルは置かれたがアクセスログにもプロセスの記録にも実行の跡が無い場合は、除去と経路の封鎖で収めてよい範囲です。

autoDeploy無効化とRemoteCIDRValveで設置経路を塞ぐ設定

TomcatのHost設定リファレンスでは、autoDeploy・deployOnStartup・unpackWARsの既定値はいずれもtrueです。webappsにWARが置かれた時点で、再起動なしに公開されます。本番では次のように締めます。

<!-- conf/server.xml -->
<Host name="localhost" appBase="webapps"
      autoDeploy="false" deployXML="false" unpackWARs="true">

<!-- webapps/manager/META-INF/context.xml（Managerを残す場合のみ） -->
<Valve className="org.apache.catalina.valves.RemoteCIDRValve"
       allow="127.0.0.0/8, ::1/128, 10.0.0.5/32" />

autoDeployを切っても、deployOnStartupがtrueなら次の再起動で配置されます。Security Considerationsが示すとおり、Tomcatのファイルをroot所有にしてTomcatユーザーには読み取りだけを許せば、プロセスを奪われても新しいアプリを配置できません。使わないManagerとexamplesは削除してください。

Webシェル対策の投資判断：自社で回せる範囲と外部に任せる境界

最後に、どこまで自社で持つかを条件で分けます。

単一のTomcatならハッシュ基準線とauditdで足りる構成条件

公開しているTomcatが数台で、デプロイがCIなど決まった経路に限られるなら、専用の改ざん検知製品を買う前に、本記事の基準線照合とauditdをcronと通知に組めば足ります。デプロイのたびに基準線を作り直す手順を、リリース手順書に1行足すだけです。

この構成が回らないのは、運用者が手でファイルを置き換える文化が残っている場合です。正規の変更と攻撃の区別がつかず、通知が鳴りっぱなしになります。先にデプロイ経路を一本化してください。

署名型のウイルス対策やWAFだけに頼る運用を採らない2つの理由と重ね方

Mitigating-Web-Shellsは、YARAの基本規則について、誤検知は少ないが亜種は検出しにくいと説明しています。数行のJSPは変数名を変えるだけで別物になるため、署名照合だけでは抜けが残ります。

WAFも、既知の攻撃パターンでの書き込みは止められても、正規の管理画面から正しい認証情報でWARを上げられた場合は通します。アプリの内側で危険な呼び出しを止めるRASPは有力な追加策ですが、まずは差分とプロセスの監視を土台に置き、署名型とWAFはその上に重ねる順序が妥当です。

侵害が確定したときにフォレンジックと脆弱性診断を外部へ出す範囲

自社で進めやすいのは、検知の仕組みづくりと、実行の跡が無い場合の除去までです。どちらも本記事のコマンドと設定ファイルで対象を特定できます。

外部に任せたほうがよいのは、コマンドの実行が確認され、何のデータに触れられたかを確定させる調査と、再構築後のシステムに同じ穴が残っていないかの検証です。侵入口がアプリのアップロード機能や管理画面にあった場合は、Tomcatの設定だけでは再発を防げません。脆弱性診断・セキュリティ診断のように、公開範囲のアプリとサーバーをまとめて点検する形で、対象のURLと管理画面の一覧を渡して依頼すると手戻りが少なくなります。

よくある質問

Webシェルの検知と対応で、検討の段階で出やすい質問に答えます。

Webシェルとバックドアは同じものですか？

Webシェルはバックドアの一種です。違いは通信の経路で、Webシェルは専用のポートを開かず、Webサーバーが受け付けているHTTPやHTTPSのリクエストに命令を載せます。そのため、ファイアウォールで通信を許可しているWebサーバーであれば、追加の設定なしに外部から操作できてしまうわけです。MITRE ATT&CKでは、サーバーのソフトウェア部品を悪用した永続化の手法（T1505.003）として分類されています。

ウイルス対策ソフトでWebシェルは検出できますか？

よく知られたWebシェルなら検出されることが多いものの、それだけでは不十分です。JSPやPHPのWebシェルは数行で書けるため、変数名や書き方を変えた亜種は署名に当たりません。NSAの公開資料も、YARAの基本規則は亜種を検出しにくいと説明しています。デプロイ済みファイルとの差分監視と、Webサーバーの実行ユーザーによるコマンド起動の監視を組み合わせてください。

Tomcat以外のWebサーバーでも同じ手順で検知できますか？

考え方は共通です。PHPを動かすApacheやNginxなら公開ディレクトリ（/var/www/html等）、IISならw3wp.exeの子プロセスが監視の対象です。MITRE ATT&CKの検知例も、Webディレクトリへの想定外のファイル作成の後にWebサーバーのプロセスが別のプロセスを起動する流れを、サーバーの種類を問わない共通の兆候としています。対象のディレクトリと実行ユーザーを読み替えれば、本記事のコマンドはそのまま使えます。

Webシェルを見つけたらすぐに削除してよいですか？

すぐには削除せず、先に複製してハッシュを記録します。削除すると、設置日時や実行内容を後から確かめる手がかりが失われます。TomcatのManagerでundeployを実行すると、WARと展開済みディレクトリがまとめて消える点にも注意してください。サーバーを外部から切り離し、証拠を残してから止め、実行の跡があればサーバーを作り直す、という順で進めます。

JPCERTの注意喚起に載ったIPアドレスを遮断すれば十分ですか？

十分ではありません。注意喚起自体が、掲載したIPアドレスは正規に使われている可能性もあると注記しています。攻撃者は送信元を簡単に変えられるため、遮断は一時的な効果にとどまります。掲載されたアドレスは、自社のアクセスログを過去にさかのぼって照合し、すでに接触されていないかを確かめる用途に使ってください。