サイバーセキュリティ初心者が知っておきたいリコン技術の実態(副業目的の場合)

Published on: | Last updated:

你是不是也卡在那種很尷尬的狀態:想做漏洞賞金或滲透測試,手都放到鍵盤上了,腦子卻空的,因為你根本不知道「從哪裡下手」;然後看著別人貼一張終端機綠字截圖,就覺得自己像在演反派臨演。現實比較殘酷:真正值錢的時間,多半花在偵查與情報整理,不是爆破那一下。

別再迷信爆破了,Recon 才是拿錢的主戰場

Reconnaissance(偵查)在バグバウンティや攻撃面調査では、作業時間の大半を占める工程で、OSINT・サブドメイン列挙証明書透明性ログ・ディレクトリファジングを連結して攻撃経路を作る。

  • OSINT(公開情報収集)で「技術スタック」と「人」を先に掴む
  • サブドメイン列挙で攻撃面(Attack Surface)を広げる
  • Certificate Transparency Logs(証明書透明性ログ)で過去の痕跡を掘る
  • スクショで優先順位を付けて、ffuf で穴を探す
  • GitHub でキーや内部 URL を拾って、点を線にする
Type 1: Recon の流れを雑にでも固定する
Type 1: Recon の流れを雑にでも固定する

で、ここから先。ちょっと冷めた話をするけど、Reconって「道具の名前を覚えた人」が勝つんじゃなくて、記録が雑じゃない人が勝つ。結局、後から自分で自分のメモを疑う羽目になるから。

短いけど本当。眠いときにやると特に。

バグを探すんじゃない。バグに繋がる情報を探す。

OSINT の金脈は地味な場所にある

OSINT(Open-Source Intelligence、公開情報からの諜報)は、求人票・PDF・GitHub・SNS・放置サブドメインみたいな「誰も気にしない残骸」から、内部構成のヒントを抜く手法だ。

映画のハッカーみたいに「侵入」から始める人、いる。いるけど、だいたい燃える。静かに拾える情報って、静かに致命傷になる。

たとえば求人票。クラウド移行の文言とか、わりと無防備に書かれる。AWS Lambda から GCP Anthos に寄せてる、とか。そこに「今の構成」と「これから触る予定の部品」が混ざってる。ロードマップを自分で描かなくていい。向こうが描いてくれてる。

Google Dorking(検索演算子で特定の露出を炙り出す手口)も、派手じゃないけど効く。

site:example.com filetype:pdf intitle:internal -public

このへん、倫理とルールの話を避けるのは無理なので一応言う。対象の許可範囲とプログラム規約は先に読む。読まないと、技術が正しくても終わる。ほんと終わる。

Type 2: OSINT で拾うネタの分類
Type 2: OSINT で拾うネタの分類

サブドメインは忘れ物置き場で、だいたい危ない

サブドメイン列挙は、assetfinder などで組織のサブドメインを洗い出し、httprobe で生存確認して、ステージングやQA環境の露出を攻撃面として把握する手順だ。

assetfinder --subs-only example.com | tee subs.txt
cat subs.txt | httprobe > live.txt

この工程、単純作業に見えるのに、なぜか差が付く。理由は簡単で、見つかったドメインを「ただのリスト」にするか、「仮説のリスト」にするかで、その後の動きが変わる。

staging / dev / qa / old / backup。名前の付け方って、会社の癖が出る。癖は、繰り返される。繰り返されるものは、探しやすい。嫌な話だけど。

あと、古いエンドポイント。archive.org や waybackurls みたいな「過去の URL の痕跡」から拾えることがある。表側から消しても、記憶は残る。人間と同じだね。

消したつもりのものほど、外からは見つかる。

証明書透明性ログで過去の名前がバレる

Certificate Transparency Logs(TLS/SSL証明書の発行履歴が公開記録される仕組み)を使うと、crt.sh・Censys・Shodan などから過去に存在したサブドメイン名を追跡できる。

これ、最初に知ったときは「そんなの公開してていいの?」ってなるやつ。公開してる。現実はそういう設計。

  • 過去の命名規則(old-dev / backup-api みたいな匂い)
  • 開発系・CI/CD・内部ツールがどこに出やすいかの癖

DNS 履歴は SecurityTrails や DNSDB みたいなサービスと組み合わせると、いつ頃どの IP に向いてたか、という時間軸が出る。時間軸が出ると、移行の途中で置き去りになったものが見えたりする。

で、急に話が逸れるけど、日本だと四半期末とか年度末とか、移行が走りがちで、現場が荒れがち。荒れると設定が荒れる。そういう季節の癖、ある。梅雨の湿度みたいに。

Type 3: 同じ対象を三つの視点で見る
Type 3: 同じ対象を三つの視点で見る

スクショとファジングは宝探しじゃなくて仕分け作業

EyeWitnessやAquatoneのスクリーンショット収集と、ffufによるディレクトリファジングを組み合わせると、ログイン画面・Jenkins・初期設定ページ・放置WordPressなどの優先ターゲットを素早く仕分けできる。

スクショ撮って眺めるの、地味だけど効く。なぜなら人間の脳は、文字ログより「画」で異常を見つけるのが速いから。変な管理画面、古いブランドロゴ、謎のBasic認証。そういうのが一瞬で刺さる。

で、ffuf。

ffuf -w /usr/share/wordlists/dirb/common.txt -u http://staging.example.com/FUZZ

/admin /backup /uploads /test /config。ありがちな道。ありがちな事故。backup.zipが落ちてたら? まあ、胸がざわつくよね。資格情報、ソースコード、設定ファイル。入ってることがある。あるから困る。

ただし、ここでテンション上げるとミスる。記録。検証。範囲確認。眠い時ほど。

うん、また眠い話してる。

Type 4: 目に付く画面をどう扱うか
Type 4: 目に付く画面をどう扱うか

GitHub と人間関係は最後に効いてくる

GitHub上のコード検索やtruffleHog・GitHound・shhgitのような検出ツールは、APIキーやアクセストークン、内部URLの露出を見つけ、メール形式や所属情報と組み合わせて人物起点の手掛かりに繋げられる。

開発者は悪くない。納期が悪い。で、急いで push して、あとで消すつもりのものが残る。残るんだよね。現実。

# 例: ドメイン名や組織名を手掛かりにコード検索
"example.com" password
"example" AWS_SECRET_ACCESS_KEY

ここで「メール形式」も絡む。名.姓なのか、頭文字+姓なのか。2つ見つかるとパターンが見える。見えると、社内の別の痕跡にも繋がる。LinkedIn の職種や投稿内容も、普通にヒントになる。

ただ、社会工学っぽい話は扱いが難しい。倫理的ハッキングの範囲でやるなら、プログラムの規約や社内ルールに沿って「検証」になる形に寄せるしかない。ここは綺麗事じゃなくて、現場の生存戦略。

Feature 何が分かる よく使う道具や手掛かり ありがちな落とし穴
OSINT 技術スタック、移行計画、組織の癖 Google Dorking、求人票、公開PDF 情報を集めただけで満足して、仮説にしない
サブドメイン列挙 攻撃面の広さ、環境の種類 assetfinder、httprobe 生存確認を雑にして、死んでるホストに時間を溶かす
証明書透明性ログ 過去のサブドメイン、命名規則 crt.sh、Censys、Shodan 過去ログだけ見て「今もある」と決めつける
ビジュアル偵察 優先順位、露出の種類 EyeWitness、Aquatone スクショだけで判断して、裏側の挙動を見ない
ディレクトリファジング 隠しパス、バックアップ、設定漏れ ffuf、一般的なwordlist 規約外の負荷を掛けて検知・遮断される
コード偵察 キー、トークン、内部URL、開発の流れ GitHub検索、truffleHog、shhgit 見つけた断片を繋げず、単発で終える
インフラ把握 IP、ASN、ポート、サービス露出 Shodan、Wappalyzer、Nmap スキャンの範囲と許可を曖昧にして事故る

迷思というか、よくある勘違い。ここで一回だけ、早口で潰す。

ポイント: 迷思は3つだけ。短く直球で返す。

  • Q Recon はツールを回せば終わり?
    A Recon は「記録して仮説にする」までが仕事で、ツールはその手前の作業を速くするだけ。
  • Q すごいエクスプロイトが書けないと稼げない?
    A 高額に繋がるのは、弱点そのものより「弱点が置かれてる文脈」で、文脈は偵查で作れる。
  • Q サブドメインが少ない会社は安全?
    A 表に見える数と、過去の痕跡や外部サービス連携の数は一致しない。

速さは派手だけど、金になるのは遅さのほう。

ここまで読んで、「結局どれから触るのが正解なんだ」ってなるよね。正解はない。…って言うと腹立つか。じゃあ現実的な言い方をすると、自分の中で再現できる順番が正解になる。毎回同じ順で回せるやつ。

個人的に落ち着く順番は、OSINT → サブドメイン → 証明書ログ → スクショ → ffuf → GitHub → その後に Nmap。Nmap(ポートスキャンでサービス露出を確認する標準的手段)は最後でいい。最後でいい、というか最後のほうが無駄が減る。

あと日本の話をもう一個だけ。企業によっては、窓口がはっきりしてる。脆弱性報告ポリシーがあったり、CSIRT がいたり。IPA(情報処理推進機構)周りのガイドラインに寄せて運用してるところもある。そういう「入口」を無視して突っ込むと、技術の話じゃなくなる。面倒だけど、そういう国。

Type 5: よくある誤解と、現場での見え方
Type 5: よくある誤解と、現場での見え方

最後に、これだけは言い切れる。Recon はループだよ。人の名前→GitHub→露出IP→サービス→設定ミス、みたいに繋がっていく。繋がらない日は、ただの散歩。繋がる日は、急に世界が薄く見える。

真相はシンプルで残酷だ。 目立つ一撃じゃなく、地味な積み重ねが一番強い。

Related to this topic:

Comments