cms-detection

CMS の特定

稼働中のすべてのホストについて、コンテンツ管理システム、ウェブフレームワーク、サーバーソフトウェア、技術スタックを特定します。攻撃を始める前に、どのスタックが使われているか把握しましょう。WordPress サイトには、Laravel API や Spring Boot マイクロサービスとは異なるテストが必要です。複数の CMS を対象にした検出では、WordPress、Drupal、Joomla、Magento、Shopify、Wix、Squarespace、Laravel、Django、Express、Spring Boot などをカバーします。

使用するタイミング

• 稼働中のホストのリストがあり、テクノロジー別に分類する必要がある場合。
• WordPress 固有のテストで誤検知が発生した場合（サイトが Drupal を使用している場合など）。
• 既知の CVE と照合するために、実行中の CMS のバージョンを特定する必要がある場合。
• ホストがすべてのパスで汎用的な 200 を返す場合。テクノロジーを検出すると、実際に何を実行しているかがわかります。
• 古いバージョンの一般的な CMS プラットフォームを実行しているサイトを見つけたい場合。

前提条件

• httpx、whatweb、wappalyzer、curl を備えた terminal。
• skill_view(name='visual-recon') または skill_view(name='subdomain-enumeration') で取得した、稼働中のサブドメインのリスト。

クイック検出

# Fastest: httpx with built-in tech detection
cat alive_subs.txt | httpx -silent -tech-detect -o tech_detect.txt

# Deep: whatweb with aggressive checks
whatweb -i alive_subs.txt -a 3 -t 50 --log-brief=cms_results.txt

手順

フェーズ 1 — テクノロジーの一括フィンガープリント

# httpx — fast tech detection using Wappalyzer signatures
cat alive_subs.txt | httpx -silent -tech-detect -o tech_httpx.txt

# Parse results: extract unique technologies with counts
cat tech_httpx.txt | awk -F' [' '{print $2}' | tr -d ']' | tr ',' '\n' \
  | sed 's/^ *//' | sort | uniq -c | sort -rn > tech_summary.txt

# whatweb — deeper, identifies specific CMS versions
whatweb -i alive_subs.txt -a 3 -t 50 \
  --log-brief=cms_results.txt \
  --log-json=cms_results.json

# Parse whatweb JSON for versioned findings
cat cms_results.json | jq -r '.[] | select(.version != null) | "\(.target): \(.plugin) \(.version)"' \
  | sort -u > versioned_cms.txt

フェーズ 2 — CMS 固有のバージョン検出

WordPress

# Generator meta tag
curl --max-time 30 --connect-timeout 10 -sk "https://target.com" | grep -Eo '<meta name="generator"[^>]*content="WordPress [^"]+' | head -1

# RSS feed
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/feed/" | grep -Eo '<generator>https://wordpress.org/\?v=[^<]+' | head -1

# readme.html (often left accessible)
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/readme.html" | grep -Eo "Version [0-9.]+" | head -1

# wp-json namespace
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/wp-json/" | jq -r '.namespaces[]' 2>/dev/null

Drupal

# CHANGELOG.txt (Drupal's canonical version leak)
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/CHANGELOG.txt" | head -5

# Drupal specific paths
curl --max-time 30 --connect-timeout 10 -skI "https://target.com/user/login" | grep -i "drupal\|x-generator"
curl --max-time 30 --connect-timeout 10 -skI "https://target.com/node/1"

Joomla

# Joomla version files
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/administrator/manifests/files/joomla.xml" | grep -Eo '<version>[^<]+' | head -1
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/language/en-GB/en-GB.xml" | grep -Eo '<version>[^<]+'

# Meta tag
curl --max-time 30 --connect-timeout 10 -sk "https://target.com" | grep -Eo '<meta name="generator"[^>]*content="Joomla[^"]+' | head -1

Magento

# Magento version file
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/magento_version" | head -1
# Composer lock
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/composer.lock" | jq -r '.packages[] | select(.name=="magento/magento2-base") | .version' 2>/dev/null

Laravel

# Laravel debug info
curl --max-time 30 --connect-timeout 10 -sk "https://target.com" | grep -Eo 'Laravel v[0-9.]+'
# Composer lock
curl --max-time 30 --connect-timeout 10 -sk "https://target.com/composer.lock" | jq -r '.packages[] | select(.name=="laravel/framework") | .version' 2>/dev/null

フェーズ 3 — サーバーとフレームワークの検出

# Server header — often removed but check anyway
for host in $(cat alive_subs.txt); do
  echo -n "$host: "
  curl --max-time 30 --connect-timeout 10 -skI "https://$host" | grep -i "server:\|x-powered-by:" | tr '\n' ' '
  echo
  sleep 0.3
done > server_headers.txt

# Common server signatures and what they mean
# nginx → likely PHP-FPM or Node.js proxy
# Apache → shared hosting, cPanel
# IIS → Windows, ASP.NET
# LiteSpeed → shared hosting, WordPress optimized
# cloudflare → CDN/WAF in front, need origin-ip-discovery
# Microsoft-IIS/10.0 → Windows Server 2016+

# Framework detection via specific paths
# Django admin: /admin/ → redirect to /admin/login/
# Rails: /assets/application-*.js pattern
# Express: X-Powered-By: Express
# Spring Boot: /actuator/health returns {"status":"UP"}
# Next.js: /_next/static/ chunks

フェーズ 4 — 技術スタックの分類

# Categorize hosts by CMS for targeted testing
echo "=== WORDPRESS ==="
grep -i "wordpress" tech_detect.txt

echo "=== DRUPAL ==="
grep -i "drupal" tech_detect.txt

echo "=== OTHER CMS ==="
grep -iE "joomla|magento|shopify|wix|squarespace|ghost" tech_detect.txt

echo "=== FRAMEWORKS ==="
grep -iE "laravel|django|rails|express|spring|next\.js|nuxt" tech_detect.txt

echo "=== E-COMMERCE ==="
grep -iE "woocommerce|magento|shopify|prestashop|opencart" tech_detect.txt

echo "=== NO CMS (Static/Custom) ==="
cat alive_subs.txt | httpx -silent -td \
  | grep -v -iE "wordpress|drupal|joomla|magento|laravel|django|rails"

フェーズ 5 — バージョンから CVE への対応付け

# Map detected versions to known CVEs
# WordPress: check https://wpscan.com/wordpress-security/vulnerability-database/
# Drupal: check https://www.drupal.org/security
# Magento: check https://magento.com/security/patches

# searchsploit — local ExploitDB search
searchsploit wordpress 6.5
searchsploit drupal 10.2
searchsploit joomla 5.1

# nuclei — automated CVE detection on detected CMS
nuclei -l wordpress_sites.txt -t nuclei-templates/http/cves/2024/

注意点

• Generator のメタタグは偽装できます。 「WordPress 7.0」と表示するサイトが、実際には 6.5 を実行している可能性があります。readme.html または RSS フィードで照合してください。
• テクノロジーの検出はシグネチャに基づいています。 カスタムテーマによって、シグネチャが削除または変更されている場合があります。
• CDN キャッシュによって古いバージョン情報が返されることがあります。 ランダムなクエリパラメーターを指定して、キャッシュを回避してください。
• 積極的なスキャンでは、whatweb が WAF によるブロックを引き起こすことがあります。 保護されたターゲットでは、より低侵襲な -a 2 を使用してください。
• ヘッドレス CMS（Strapi、Contentful）にはバージョンファイルがありません。 代わりに API エンドポイントを探してください。

検証

1. 少なくとも 2 つの独立した方法で、同じ CMS とバージョンを確認します（メタタグ、readme、wp-json など）。
2. バージョン固有のパスが存在します（例：WordPress の /wp-admin/、Drupal の /user/login）。
3. フレームワーク固有のエンドポイントが正しく応答します（例：Spring Boot の /actuator/health）。
4. ホスト名、CMS、バージョン、検出方法、既知の CVE がそのバージョンにあるかどうかを記録します。

関連スキル

• web-enumeration — CMS の特定後、その CMS 固有のパスとエンドポイントを列挙します。
• wordpress-plugin-hunt — WordPress ターゲットのプラグインバージョンを詳しく検出します。
• wp-mass-recon — WordPress の脆弱性を一括スキャンします。
• visual-recon — スクリーンショットを目視で確認し、CMS の検出結果を検証します。
• deep-invade — 検出したバージョンに対して nuclei の CVE スキャンを実行します。