AI＋オフライン環境＋Kali Linuxでセキュリティ診断を自動化！ハッキング入門！

はじめに

このコンテンツは、
「社内で許可を取りつつ、仮想マシン上でオフライン環境でKali Linux環境を構築し、安全に“防御観点のセキュリティ診断”を自動化するためのワークフロー」
をまとめた手順ノウハウです。
note,Google,X,Instagram,Youtube,ココナラ,Udemy検索しても、
ある程度プログラミングができることや、
機械言語がわかる前提の情報ばかりでPC初心者やPC自体は仕事や学校で使うし、ある程度は使えるけど、

• プログラミング（Python,C言語,コマンドプロンプト等のコーディング）

• デプロイ（アプリ作成的な認識でOK）

• 仮想マシン導入

• インターネットにつながないオフライン環境でのテスト

• セキュリティ診断

• ChatGPT,gemini,ClaudeなどのAI

• API

このあたりが全くといってもいいほど分からないレベルでも、
企業での運用までできるようになります。

PC初心者でもわかりやすく、とても丁寧に細かくインストールから使い方説明までカバーできるようにしています。

※Kali Linuxはハッカー御用達のハッキングツールがたくさんビルドされているUbuntuベースのLinuxOSです。日本語化も可能です。MacやWindowsPCにも導入できるように説明しています。

対象読者は下記のいずれかに該当する方です：

• 外部委託なし低予算で最低限の診断を回したい（基本無料が前提です）

• 既存のセキュリティ診断が工数的に回らない。

• やることが多すぎてデバックチームがパンクしてる。

• 規模が小さくても “外部に出ると困る” 情報資産がある

• 開発者として社内完結で診断スキルを持ちたい

• AIを使って再現性あるオペレーションへ寄せたい

• よくわからんけど、ハッキングって響きカッコいいし試してみたい

• AIって今すごいんでしょ？使いたいけどお金かかるのはちょっと一歩出ないよねぇ。経費下りないかもだし…

• ホワイトハッカー雇うと人件費が…（セキュリティ関係は相場が高い）

• etc.

結論から言うと、
セキュリティ診断の 80% は「同じ穴」を潰す作業です。

• SSH鍵

• SUID/SGID

• world-writable

• cron/systemd

• DB が外へ開いている

• Webroot に秘密情報

• ライブラリが古い

• 不審バイナリ

どの案件でも、必ずここで何かが見つかります。
裏を返すと、この“よくある穴”さえ網羅的に洗えれば、

「最低ラインの防御品質」を担保できます。

今回のワークフローは、
そこに限定して徹底的に効率化した仕組みです。

なぜこのワークフローを作ったのか

結論は単純です。

セキュリティ診断は“人力で全部やる”と破綻する

手動でやると

• 見逃す

• 面倒

• 工数が読めない

• 毎回やり方が違う

• そもそも続かない

現実はこうなります。
僕も最初、自分ひとりで案件を回した時に体力的に潰れかけました。

そして強く感じたのが、
同じ作業を毎回ゼロからやっている無駄です。

なので僕は
「人間は“構築と許可”だけすればよい」
という前提で仕組み化しました。

このワークフローが解決すること

人手の削減

• AI が triage（分類・優先度）

• Ansible 雛形を自動生成

再現性の担保

• 同じ detection.sh を流せば

• 同じ質の出力が得られる

判断ミスの防止

• AI が JSON 単位で evidence をまとめる

• 「どこに何が書いてあったか」を明確化

チケット化が速い

• CSV で出るので

• JIRA/Notion/Trello に流し込める

オフラインで完結

• ネットに出さない

• 依頼された資産が外に漏れない

攻撃を自動化するものではありません。
“防御側がやるべき洗い出しと整理” を支援する仕組みです。

「攻撃前提」ではなく「防御前提」の設計

ここは特に強調します。

このワークフローは、
“攻撃者を再現する”ことではありません。
“攻撃者が入りそうな場所を機械的に洗い出す”ための手法です。

AIがやっていい領域

• ログの整理

• 不審箇所の指摘

• 優先度の分類

• 修復案（防御）

• チケット形式への整形

AIにやらせない領域

• 攻撃手順

• エクスプロイト生成

• 観測系以外のスキャン

• 未許可対象へのアクセス

守備範囲を分けることで安全が担保されます。
（そもそも 完全オフライン です）

全体像：8フェーズ

1) 依頼定義
2) testbed構築（オフライン）
3) detection.sh 実行
4) findings.json 生成
5) AI triage（分類）
6) 修復案（Ansible雛形）
7) チケット化
8) 再スキャン & 承認

人間が本当にやるのは
①②（構築と許可）だけ。

③以降は
機械 → AI → 結果
の流れで回ります。

依頼を仮想化し、オフライン testbed に落とし込む

実案件でも、
まずはローカルに“閉じた箱”を作る
ことが最重要です。

testbed に入れるもの

• Webアプリ

• API

• DB

• nginx/apache

• 環境変数ファイル（env）

• Git依存物

「製品化前のサービスを再構成できる」
という前提があれば、
この testbed にすべて放り込めます。

※ネット接続は不要
（むしろ繋がないほうが安全）

detection.sh が取得するもの

• 全ユーザーの authorized_keys

• SUID/SGID

• world-writable

• cron/systemd timers

• パッケージリスト

• listenポート

• 最近の変更

• Webroot内の秘密情報

いわゆる
バックドアの入口候補
がすべて取れます。

鍵が転がっていないか
権限が緩い箇所がないか
DBが外部から触れそうか
env に認証情報が残ってないか

このフェーズだけで
かなりの “事前防御” が成立します。

※scan は非侵襲（安全）

findings.json に統一する理由

ログはツールごとに形式が違います。

• 文字列

• 改行混じり

• XML

• CSV

そのまま AI に渡すと混乱します。
（人間でもつらい）

なので
03_parse.py
で一本化。

[
  {
    "type": "port",
    "host": "10.0.0.5",
    "port": "5432",
    "service": "postgres",
    "evidence": "/out/xxx/nmap.xml"
  },
  ...
]

こうしておくことで

• AIが扱いやすい

• 再現しやすい

• チケット化しやすい

という利点があります。

AI triage の精度を上げるための設計

AIは万能ではありません。
しかし
扱いやすい JSON を与えれば、誤差は大きく減ります。

triage の観点

• 優先度

• 理由

• 推奨作業

• evidence（根拠）

• 注意点

特に「理由」と「evidence」を一緒に返すことで
再度調査するときに迷いません。

AIを「まとめ係」に徹底させるのがポイントです。

人間の失敗（事例）

このワークフローを作る過程で
僕が痛感したことを共有します。

1) 「人間の思い込みが一番危ない」

• “この鍵は大丈夫でしょ”

• “このcronはたぶん大丈夫”

→ 調べると普通に危ない

2) ログを読む時間がとにかく無駄

• 量が多い

• 見落とす

→ AI に整理させると3分

3) 毎回ゼロからやる → 再現性なし

→ detection.sh で固定化

修復案が Ansible 雛形で出ることの意味

人間が
「どう直そうか」
と考える時間が大幅に削れます。

たとえば

world-writable
→ 0755 で閉じる
→ 所有者は www-data

など
“最低限の線” が引けていれば
担当に渡すときも迷わない。

「できる人の脳内をコピーする」
という意味で
AIの使い方として最も価値が高い部分です。

チケット化まで自動

CSV で出せば
JIRA
Notion
Redmine
など
どこでも流せます。

ID,タイトル,説明,優先度,修復案,エビデンス

運用へ受け渡すまでがセット
という思想です。

個人的には
診断→報告書
より
診断→チケット
のほうが現場が動きます。

この仕組みを動かすために必要な要素

• VirtualBox or VMware

• Kali（OVA）

• Python3

• bash

• Ansible

クラウドは不要。
インターネットも不要。
必要なのは
構築と許可
だけです。

注意点：万能ではない

誤解してほしくないのですが
この仕組みは万能ではありません。

• 攻撃の再現

• 難易度の高いゼロデイ調査

• Webアプリ特有の動的欠陥（論理抜けなど）

こういった領域は
人間の専門的調査
が必要です。

ただし
「まず抑えるべき下地」
としては十分です。

僕の肌感では
最初の 8割 は
この仕組みで潰せます。

ここで一度、問いかけです。

もし、
あなたの組織が
「最低限のセキュリティチェックを全プロジェクトで回す」
必要があるとしたら、
この仕組みは使えるでしょうか？

目を閉じて、
1年後の運用を想像してみてください。

• 人手で頑張る

• 毎回ログを読む

• 人に依存

これを続けられますか？

無料パート まとめ

ここまでで触れた内容：

• 役割は「構築と許可」だけ

• 80%の穴はパターンで潰せる

• detection.sh が情報を回収

• findings.json で統一

• AI が triage

• 修復案が Ansible 雛形

• チケット化で運用まで繋がる

• オフライン完結

ここからの有料パートでは
手順レベルで細かく解説します。

ここから先は有料パートです。

• testbed の具体構築

• detection.sh 全文

• parse & triage サンプル

• AI プロンプト例

• Ansible 雛形

• チケットテンプレ

• 運用例

• 再スキャン自動化

• 実践 Tips

続きを読みたい方はこの下からどうぞ。