CVE-2026-90817 REDCap 侵害スキャナー

redcap_cve_2026_90817_scan.py は、REDCap ホストが CVE-2026-90817 に 晒されているか、また侵害されているかをチェックする読み取り専用のパッシブスキャナーです。 これは、Palo Alto Unit 42 が文書化した XMRig クリプトマイニングキャンペーン (2026-10-07-XMRig-campaign-through-CVE-2026-90817) で悪用された、 認証不要の survey エンドポイントにおけるリモートコード実行の脆弱性です。

このツールは、実行対象のホストについて次の 2 つの問いに答えます。

1. 脆弱か? インストールされている REDCap のバージョンが修正済みリリースより古いか?
2. 侵害されているか? 文書化された侵害指標 (IOC) のいずれかが存在するか? また、ホストが攻撃を受けた場合、その攻撃は修正の前に成立したのか、それとも後か?

安全性 / スコープ

このツールは検出専用です。次のことは行いません。

• HTTP リクエストを送信せず、エクスプロイトやペイロードを再現することもありません。
• 何かを変更、隔離、削除、または「クリーンアップ」することはありません。
• ホスト上のファイル、プロセスメタデータ、ソケット、ログを読み取るだけです。

自身が管理する REDCap サーバーに対して管理者が実行することを想定しています。

要件

• Python 3.7 以上。標準ライブラリのみ — pip インストールは不要です。単一ファイルなので、 ホストにコピーして実行するだけです。
• Linux (Debian 系および RHEL 系): 完全にサポートされています。Apache ログは /var/log/apache2 (Debian) または /var/log/httpd (RHEL/CentOS/Rocky/Alma)、nginx は /var/log/nginx で自動スキャンされます。RHEL 8 では システムの python3 が 3.6 なので、python3.9 (またはそれ以降) を呼び出してください。 RHEL/Rocky/Alma 9 には 3.9 以上が同梱されています。完全なスキャンには root として 実行してください (ユーザーごとの crontab、他ユーザーの authorized_keys や /proc/<pid>/exe、一部のログは root でないと読めません)。root でなくても実行は可能で、 結果は部分スキャンであることが明確に示されます。
• Windows (IIS または Apache/XAMPP 上の REDCap): 未テスト — Windows ホストでは 一度も実行されたことがありません。 プラットフォームと Windows サポート を参照してください。 完全なスキャンには管理者権限で昇格した PowerShell/cmd から実行してください。

使用方法

# Simplest: defaults to /var/www/html/redcap, auto-detects the mitigation date
sudo python3 -I redcap_cve_2026_90817_scan.py

# Point at a non-default install, pin the mitigation date, list every attack entry
sudo python3 -I redcap_cve_2026_90817_scan.py \
    --redcap-root /var/https/redcap \
    --mitigation-date 2026-09-21 \
    --max-log-matches all

# Machine-readable output for monitoring / ticketing
sudo python3 -I redcap_cve_2026_90817_scan.py --json

Windows では、管理者権限のプロンプトから実行し、--redcap-root をインストール先に指定します（プラットフォームとデフォルトのログディレクトリは自動検出されます）:

# IIS or Apache/XAMPP; logs under C:\inetpub\logs\LogFiles or the Apache logs dir
python -I redcap_cve_2026_90817_scan.py --redcap-root C:\redcap --json

-I は Python を分離モードで実行します（$PYTHONPATH と CWD を無視）— 改ざんされた可能性のあるホストをスキャンする際の適切な衛生管理です。

オプション

フラグ	デフォルト	目的
--redcap-root PATH	/var/www/html/redcap	REDCap のインストールルート。
--log-dir DIR（繰り返し指定可能）	プラットフォーム固有（Linux では Apache/nginx、Windows では IIS LogFiles + Apache）	スキャンする Web サーバーログディレクトリ（ローテーションされた .gz および IIS W3C ログを処理）。
--home-dir DIR（繰り返し指定可能）	/root + 各 /home/*（Linux）、各 C:\Users\*（Windows）	SSH キー / シェル/プロファイルファイルをスキャンする追加のホームディレクトリ。
--platform auto|linux|windows	auto	想定するホストプラットフォーム。OS から自動検出されます。プロバイダーを選択するために強制指定できます（OS 固有のホストプローブは、一致する実際の OS 上でのみ実行されます）。
--mitigation-date YYYY-MM-DD	自動検出	アップグレードによって脆弱性が修正された日付。攻撃タイミングを参照。
--since YYYY-MM-DD	—	この日付以降（含む）の Web ログエントリのみを検査します。これより前に最終更新されたログファイルは開かれません。両方のログパスに適用されます。ホスト状態のチェックには影響しません。攻撃タイミングを参照。
--until YYYY-MM-DD	—	この日付以前（含む）の Web ログエントリのみを検査します。
--full-hash-scan	オフ	temp/cache およびステージングディレクトリ配下のファイルを再帰的にハッシュ化します（低速）。
--max-log-matches N | all	100	カテゴリごとに一覧表示する攻撃ログエントリの数。そのまま保持されます。
--attacker-ip IP（繰り返し指定可能）	—	追加の既知の攻撃者 IP（例: 別ホストのスキャンから）。文書化された IOC IP と同様に扱われます。第2パスを参照。
--json	オフ	テキストレポートの代わりに JSON を出力します。
--quiet	オフ	テキスト出力の OK/INFO 行を抑制します。

終了コード

コード	意味
0	クリーンかつパッチ適用済みで、スキャンが完全に完了しました。
1	1 つ以上の検出結果（脆弱なバージョンおよび/または IOC/攻撃）— 調査が必要です。
2	スキャンを完全に完了できませんでした（エラー、または非特権かつそれ以外はクリーン — クリーンな結果を完全には断言できませんでした）。

チェック内容

文書化された各 IOC は、受動的なローカルチェックに対応します:

• バージョン / パッチ状態 — redcap_vX.Y.Z ディレクトリ名からインストール済みバージョンを読み取り、パッチ適用済みリリース（16.0.49 LTS / 17.3.10 LTS / 17.4.4 Standard、影響下限 13.3.0）と比較します。
• temp/cache 内の既知の悪性ファイル — そこにあるすべてのファイル（およびステージングディレクトリ内）は、Unit 42 のドロッパー SHA-256 に対してハッシュ化されます。注: このツールは .bladec 拡張子によってファイルをフラグしません。REDCap コアは BladeOne テンプレートエンジンを使用しており、ハッシュ名の .bladec コンパイル済みテンプレートを通常の出力として temp/cache に書き出すため、この拡張子は侵害の指標ではありません。真に悪意のあるドロップされたファイルは、拡張子に関係なくその内容ハッシュによって検出されます。
• マイナーのステージング — .syslog-* ディレクトリ、xmrig* アーカイブ、およびキャンペーンがパーミッション 000 にロックする競合ディレクトリ（/dev/shm/duet、/var/tmp/.bin）。
• プロセス — マイナー（XMRig / プール / ウォレット参照）、/var/tmp、/dev/shm、/tmp から実行されている実行ファイル、および syslog-ng-* に偽装したプロセス。
• ソケット — 127.0.0.1:50001 上のローカル XMRig JSON-RPC API、および攻撃者の送信元 IP へのライブ接続 — 文書化されたもの、観測されたもの、任意の --attacker-ip、および Web ログチェックが発見したすべての IP。
• Cron 永続化 — システムおよびユーザーごとの crontab 内の fetch-to-shell クレードルおよび IOC 参照。
• SSH authorized_keys — 攻撃者のバックドアフィンガープリントに一致するキー。（「レビュー」のために無関係なキーを意図的に一覧表示しません — 通常のホストではそれらは実在のアカウントに属し、独立して検証できないためです。）
• シェル rc / ~/.profile — 注入された起動コードおよび HISTFILE アンチフォレンジック。
• Web サーバーアクセスログ — エクスプロイト試行のシグネチャ（下記参照）。

Web ログ検出（誤検知を回避する方法）

__passthru と route= はそれ自体が正当な REDCap パラメータです — External Modules は __passthru を経由してルーティングされ、通常の survey トラフィックは PdfController や SendItController のような無害なコントローラに到達するために 平文の __passthru=index.php を使用します。したがって、スキャナがそれらだけにマッチすることは 決してありません。ログ行がエクスプロイト形状と見なされるのは、次のいずれかを示す場合のみです:

• RCE シンク — __passthru が（レポートに記載されたシンクである）DataImportController に 到達している場合（エンコーディングを問わず）; または
• 二重エンコードされた __passthru が任意の内部 …Controller に到達している場合 — 例: __passthru=%2569ndex.php&route=ParcelController:show。これはこのキャンペーンの 一般化可能なシグネチャです: 正当なクライアントは平文のリテラル index.php を送信し、 二重エンコードされたものを送信することは決してないため、攻撃を区別するのは （コントローラ名でも HTTP ステータスでもなく）難読化です。これにより、文書化された IOC IP 以外の攻撃者ホストも捕捉されます; または
• レポートに記載された特定の攻撃者 survey ハッシュ。

一部のリクエストは、エクスプロイト形状のリクエストではなく、偵察（MEDIUM）として 別途分類されます:

• 既知の攻撃者 IP からのあらゆるリクエスト: 文書化された IOC IP、任意の --attacker-ip、または以下に示す観測された IP。
• 任意の IP からの、404 を返す二重化された survey パス。例: /redcap/surveys/surveys?s=…、/redcap/surveys/redcap/surveys/、 /redcap/redcap/surveys/。これは攻撃ツールにおけるパス結合のバグです。
• 任意の IP からの、/surveys リクエストにおけるツール生成のユーザーエージェント。これは Gecko トークン内に日時が含まれることを意味します。例えば Gecko/8618-10-13 16:07:47.714447 Firefox/3.8 のような、Python の Faker が生成する種類の文字列です。実際のブラウザは例えば Gecko/20100101 を送信します。

これらの 2 つのプローブパターンのうちいずれか一方のみにマッチする行は、偵察として リストされますが、攻撃の合計や attack-timing の判定にはカウントされません。 どちらのパターンも、壊れたリンクや風変わりなクライアントなど、無害なソースから生じる可能性があります。 同じ行が既知の攻撃者 IP から来ている場合は、通常どおりカウントされます。

観測された攻撃者 IP（Unit 42 レポートには未記載）

これらの IP は、2026 年 10 月に UF の REDCap ホストへエクスプロイト形状のリクエストを送信しました。 これらは文書化された IP とまったく同じように扱われます:

• それらのログトラフィックは偵察（MEDIUM）です;
• それらのいずれかへのライブソケット、cron、またはプロファイルの参照は HIGH です。

IP	初回観測	挙動
72.167.149.182	2026-10-14	python-requests; ベースパスプローブ、続いて ParcelController
18.163.208.19	2026-10-15	python-requests; ベースパスプローブ、続いて ParcelController
159.65.159.30, 45.225.183.6, 159.89.115.81, 165.22.168.95	2026-10-19	でっち上げのユーザーエージェント、ペアになった IP; ParcelController
5.180.77.102	2026-10-19	DataImportController; 202.61.130.221 と同じ survey ターゲットと二重化パスのバグ

ほとんどは再割り当て可能なクラウドホストであるため、各証拠行には IP の出所が 示されます。古くなったエントリは IOC_OBSERVED_IPS から削除してください。

以下は同じトラフィック内で見られましたが、IOC ではありません:

• 攻撃者が標的とした survey ハッシュ: これらはサイトの実際の survey であるため、マッチさせると正規の回答者を誤検知してしまいます。
• python-requests: 汎用的すぎます。
• 5 バイトの 2xx レスポンス: これはリクエストがコントローラに到達したことを示しますが、 それはすでに HTTP ステータスによってランク付けされています。

検出は IP ではなくリクエストのパターンに基づくため、スキャナはエクスプロイト形状の リクエストを発行したすべての異なる送信元 IP を集約し、文書化された IOC IP 以外のものを 指摘します。各エクスプロイトヒットはHTTP ステータスによってランク付けもされます: 2xx は __passthru が認証なしでコントローラに到達したことを意味し、非 2xx は 到達しなかった試行です。コントローラへの到達は到達可能性であり、コードが実行されたことや ホストが侵害されたことの証明ではありません — 実際の侵害を確認するのはホスト状態のチェックです。