攻城戦で城を守る方法🏰⚔️

By PLURA

昔、城壁🧱が高くて堀🌊が深い国がありました。

少ない城壁を越えられず、残りの道は城門だけでした。

今日の私たちのシステムも同じです。 ファイアウォールでアウトラインは閉じており、唯一の開いたドアはWebサービス（80/443）です。 だから攻撃者は声門を正面突破するより、城の中に「洗作(バックドア)」を入れる戦略にすべての創意と資源を注ぎます。

Protect the Castle

1)寓話で見る現在：城門・排水路・洗作

  • 城壁 = ネットワーク境界(ファイアウォール、分離ネットワーク)
  • 声門（正門） = Webサービス（HTTPS 443、リダイレクト80→443）
  • 排水路/隠蔽路 = 本文エンコード・バイパス技術、脆弱ライブラリ、管理コンソール
  • 洗作(バックドア、マルウェア) = ウェブシェル・マルウェアプラグイン・クレデンシャル脱臭後に設置された持続化ツール

すべての城壁が安全なとき、攻撃者は声門をだましたり、城内に洗作をすること以外には方法がありません。

2）なぜ「Web」がすべての攻撃の玄関口なのか？

  1. 唯一の開放ポート: 大国民・大客サービスは443が標準。最終的に、すべてのトラフィックがこのドアを通過します。
  2. 複雑性の罠: 数多くのフレームワーク・プラグイン・APIが絡み合い「機能＝攻撃面」。
  3. 運営常時変更: 配布・設定変更・緊急パッチが頻繁に、ルールが追いつく構造となる。
  4. TLS暗号化: 内容が見えない場合、WAF/セキュリティ装備が装飾になることがある(TLS終端位置・可視性問題)。

3）洗作（バックドア）製造の進化 - 「数百人→数億個」

かつては一日中人数十・数百人が一つの三作を作りました。 今は、AIが数億個の変種ペイロードを作成し、バイパス・難読化・ポリモルフィックを自動的に繰り返します。

  • トリックの質・量が幾何級数的増加: シグネチャー・静的ルールだけでは漏水発生。
  • 群衆の中の1、2人の三作を逃すと、すぐにトロイの木馬になり内部権限上昇・側面移動が始まります。

4) 「聞こえない耳」の危険 — 形式主義が作るモンスター政策

  • 旗の色を点検し、城門の装飾を点滅させる型式中心点検は排水路を見ません。
  • 現場の本文・監査ログが空であればどんな認証も実戦防御になりません。

AI防御は「データ」なしでは不可能です。 Web リクエスト/応答 本文、サーバー 監査ログがなければ、AIは見ることも、学ぶこともありません。

👉 私たちのハッキングは政府の認証制度によるものです

👉 ISMS認証制度、なぜ今はもはや有効ではないのですか？

5）本当の防衛原則 - 「声門の可視性+城内諜報+即応」

5.1 必須の可視性

  • Web層: リクエスト/レスポンス 本文ログ(POST/JSON/XML/ファイルアップロード)、ヘッダ・クッキー・ボディパラメータの正規化
  • ホスト層: 監査ポリシー(Windows Sysmon, Linux auditd)の有効化、プロセスツリー・コマンド行・ネットワーク接続
  • TLS 可視性: WAF/リバースプロキシ TLS 終端 で 本文検査 可能に設計

5.2 多層防御(Defense-in-Depth)

  • WAF: 本文・正規化・ファイル形式検証、可変ペイロード検出(行為/文脈)、脆弱なコンポーネント別専門文化ルールセット
  • EDR/XDR: ウェブシェル実行・権限上昇・クレデンシャルアクセス・圧縮/暗号化・C2接続の行為検出
  • SIEM/SOAR: ウェブ↔ホストイベント 相関分析, 自動プレイブックで 分離/アカウントロック/チケット発行

5.3 MITRE ATT&CKの視点

  • Initial Access: T1190(パブリックアプリケーションエクスプロイト)、T1133(外部リモートサービス)
  • Execution: T1059(コマンドインタプリタ)、Webシェルによるコマンド実行
  • Persistence: T1505.003(ウェブシェル)、T1053(スケジューラ)
  • Credential Access: T1003(LSA/LSASS ダンプ)
  • Exfiltration: T1041(ネットワークへの流出、分裂転送)
  • Command & Control: T1071（WebプロトコルC2）、ドメインフロント/ノーマルサービスの悪用

6) 検出・遮断プレイブック

  1. フロントライン(WAF)
  • TLS終端位置で本文チェックを有効にする
  • 正規化後の検出(デュアルエンコーディング/バイパス除去)
  • ファイルアップロード: 拡張子↔MIME↔マジックナンバー一致検証・隔離スキャン
  • 脆弱なコンポーネント専用のルールセット（例：フレームワーク/管理コンソール別）→
  1. ホスト(EDR/XDR)
  • Webプロセス（「w3wp」、「php-fpm」、「java」など）の子プロセスの実行モニタ
  • ウェブルート変更・新規スクリプト生成通知、権限上昇/パスワード収集遮断
  • アウトバウンドポリシー: サーバー→外部 直接通信最小化(プロキシ・許可リストベース)
  1. 相関・対応(SIEM/SOAR)
  • 「アップロード直後ウェブルートファイル生成+異常プロセスツリー+新規外部接続」=高リスクストーリーラインアラーム
  • オートメーション：セッションをブロック→ファイルを隔離→アカウントロック/秘密リセット→チケットを作成→証拠を保存

7) フィールドチェックリスト✅

  • リクエスト/応答本文ログが保存・照会・検索可能か？ （PIIマスキング・保存政策含む）
  • TLS可視性を確保しましたか？ （終端位置・再暗号化・性能テスト）
  • フレームワーク/プラグインインベントリが最新で、脆弱性マッピングルールが反映されるか。
  • ウェブルート変更検出とサーバーアウトバウンド制御が適用されているか？
  • MITRE ATT&CKベースの相関ルールが動作していますか？ (ウェブイベント↔ホストイベント)
  • リリース・パッチガバナンスがあり、 ロールバック・ブルー/グリーン配布市 セキュリティルール同期になるか？

8）よく間違っている方針🙅

  • 型式点検のみ強化し、本文・監査ログが空の状態にAI導入
  • 私たちのスタックにない脆弱性ルールまですべてオン→性能低下・誤検知増加
  • アウトバウンド無制限許可(サーバーがクライアントになる) — 流出・C2通路生成
  • TLSをバックエンドまで終端せず密閉 — 装備が内容を出さない

9) 結論 — 「声文を本文で見る」

AI時代の攻城戦で、攻撃の技術は洗作大量生産に進化しました。 私たちがしなければならないことは単純です。

🚪門を見るように、本文を見てください。

🗣️城内のささやき（監査ログ）を記録しなさい。

Web↔️ホストを1つのイベントとして理解し、自動的に対応します。

データが蓄積されると、AIは偽と本物を選別する訓練を開始でき、 その時初めて洗作は群衆の中で明らかになります。

📖 一緒に読む

PLURA-XDRはウェブ本文ログ+ホスト監査ログを収集・相関・自動対応(SOAR)まで接続して “見えなかった洗作“を可視化→分離→証拠化します。

Tags