.png&w=3840&q=75)
「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
こんにちは。東内（@yousukezan）です。
相変わらず引きこもってAIとセキュリティの記事を中心に読んでいます。セキュリティの世界では、10月にランサムウェア攻撃を受けたアサヒグループホールディングスやアスクルが復旧できておらず、ダメージの大きさに戦々恐々としています。
それでは、最近読んで良かったコンテンツの一部を紹介します。
【図解】Torネットワークによる匿名化と、.onionドメインにアクセスする仕組みについて
インターネットには、通常のブラウザやDNS経由では到達できない「ダークウェブ」と呼ばれる領域が存在します。その中核技術の一つが、匿名通信を実現するためのネットワーク「Tor」です。この記事では、実際のコマンド例やTorの内部構造を追いながら、「なぜIPアドレスが隠れるのか」「なぜ.onionドメインはTorでしか見られないのか」を丁寧に解きほぐしています。
前半では、curlとipinfo.ioを用いたデモを通じて、通常アクセスとTor経由アクセスで見えるIPアドレスがどう変化するのかを確認しつつ、Guard/Middle/Exit Relayから構成されるTorネットワークの基本的な仕組みを説明しています。また、Directory AuthorityやDirectory Cacheによるコンセンサス配布、Torクライアントがどのようにリレー情報を取得して多段の暗号化経路（オニオンルーティング）を構築するかといった、内部メタデータの具体例にも踏み込んでいます。
後半では、Torのもう一つの重要な側面である「Onion Service（.onionドメイン）」に焦点を当て、Hidden Service Directory、Rendezvous Point、Introduction Pointといった構成要素がどのように連携して「利用者も提供者も互いのIPを知らない通信」を実現しているかを解説します。
特に、.onionドメインがDNSでは名前解決できない理由、HSDirからの記述子取得を起点とした接続確立の流れ、Onion Serviceがリバースプロキシのように動作し、Tor経由の通信だけを受け付ける設計など、「Torを経由しないと本当にアクセスできない」技術的背景が分かりやすく整理されています。
最後に、Torを利用していてもSNSのハンドルネーム使い回しやアクセスログから身元が特定された実例に触れ、「技術的な匿名化があっても最後の穴は人間である」という重要な示唆も示されています。Torやダークウェブに興味があるエンジニアだけでなく、「.onion ドメインって結局どう動いているの？」という疑問を持った読者にとっても、基礎から実践的な観点まで一気に理解を深められる詳細な解説記事となっています。
NIST SP 800-63B-4：パスワードセキュリティの新基準を読み解く
この夏公開された「NIST SP 800-63B-4」は、いまだに広く使われている「パスワード認証」を、今の時代にふさわしい形にアップデートするための新基準です。本記事では、この文書のポイントを、企業内の認証システムを設計・運用するエンジニアや、パスワードポリシーを決める立場の人向けに、背景と狙いを含めて分かりやすく解説しています。
まず特徴的なのは、パスワードを「サーバー側で検証される秘密」と「デバイス内で検証されるアクティベーション秘密（PINなど）」に分けて整理したうえで、従来の「常識」を次々と否定している点です。代表例として、定期的なパスワード変更の強制や「大文字・小文字・数字・記号を必須にする」といった複雑性要件、パスワードヒントや秘密の質問の利用などが「むしろ有害」とされています。その理由が、実際の攻撃手法やユーザー行動の研究結果と合わせて丁寧に説明されています。
一方で新たに推奨されるのは、「複雑さ」よりも「長さ」を重視したパスワード、あらゆる印字可能文字やUnicodeを許容する柔軟な入力仕様、漏えいパスワードやありがちな候補を弾くブロックリストの導入、そしてパスワードマネージャーの積極的なサポートです。
サーバー側の安全なハッシュ保管要件や、PINの試行回数制限、ブロックリスト、ハードウェア保護といったアクティベーション秘密向けの要件も整理されており、「どう実装すべきか」まで具体的にイメージできる構成になっています。記事後半の附属書Aでは、パスワードの強度を、エントロピー計算や攻撃モデルを用いて比較し、なぜパスフレーズ方式が本質的に強いのかを数式レベルで解説します。
全体として「NIST SP 800-63B-4」の要点を押さえつつ、ISO/IEC 27002との関係や現場でありがちな誤解にも触れた実務的なガイドとなっています。
誰もがフィッシングサイトを作れる時代に？フィッシングツールキットで作られたファイルやサイトを解析
今でも証券口座やオンラインサービスへの不正アクセスが止まっていませんが、本記事では、CSIRTメンバーである筆者が、実際に「フィッシングツールキット」で生成されたファイルやサイトを解析し、攻撃の起点から認証突破までの流れを丁寧に追跡しています。
記事の前半では、二要素認証をすり抜けるAiTM（Adversary-in-the-Middle）攻撃の仕組みと、それを誰でも使える形にしたPhaaS（Phishing as a Service）について解説。攻撃者は、専用ツールを使って本物そっくりのログイン画面を簡単に生成し、利用者が正規サイトと信じて入力したID・パスワード・ワンタイムパスコードをそのまま中継して盗み取ります。こうした量産型フィッシングが、二要素認証前提の現代でも十分な脅威となり得ることが示されています。
解析パートでは、フィッシングメールに添付されたSVGファイルから調査を開始し、暗号化されたJavaScriptの復号や、攻撃者サイトへの自動遷移、CAPTCHAによる解析妨害、Microsoftログイン画面の巧妙な模倣といった挙動を具体的に追いかけています。さらに、難読化されたコードの中から、Microsoft Authenticator由来とみられるセキュリティコードを読み取り、sendAndReceive関数で外部送信していると思われる処理も特定。ツールキット側に、アンチデバッグ機能やコード流出防止の工夫まで組み込まれている点も印象的です。
終盤では、「ではどう守るのか」という観点から、防御策が整理されています。FIDO2や証明書ベース認証といったAiTM耐性の高い認証方式の採用、条件付きアクセスポリシーによるアクセス元IPアドレス制限、そして運用レベルの対策まで具体的に言及されています。「攻撃者側の視点」と「防御側の視点」の両方を学べるバランスのよい内容で、セキュリティ担当者から一般利用者まで、幅広い層にとって読んでおきたい解説記事といえるでしょう。
My AWS Account Got Hacked - Here is What Happened
かつては脆弱性をハントしていた筆者が、自身の個人AWSアカウントを実際に侵害された体験を詳細に綴ったインシデントレポートです。「自分は狙われない」「個人アカウントなんて価値がない」といったよくある思い込みを、現実の攻撃シナリオを通して容赦なく打ち砕いていきます。
攻撃の始まりは、一見ただの「スパム洪水」でした。大量のメールに埋もれる中に、AWS OrganizationやSESの設定に関する重要な通知が紛れ込みます。筆者自身も最初は違和感を覚えつつ見逃しかけ、さらには、ChatGPTに「問題なさそう」と誤誘導されてリンクをクリックしてしまうなど、人間らしい判断ミスの流れがリアルに描かれています。
その後、CloudTrailの確認によって、自分の作っていないIAMユーザーによるSES DKIM設定変更や、大規模なEC2インスタンスの起動、Organizationの作成とダミーアカウントの追加・即削除といった不審なアクションが次々と判明します。原因は、Next.jsによるSSR実装の中でアクセスキーをコードに埋め込んだまま公開してしまい、クローラにより秘密情報を抜かれたことでした。
記事では、検知から初動対応、AWSサポートとのやりとり、全リージョンのCloudTrailログをCSVに落としてタイムライン化する過程まで、インシデントレスポンスの一連の流れが具体的に解説されています。また、攻撃者がEC2での暗号資産マイニングや、SES＋DKIMを悪用したフィッシングメール送信を狙っていたと推測される点など、クラウドリソースがどのように「お金を生むインフラ」として悪用されるのかもよく分かる構成です。
最後に、秘密情報管理をSecrets Managerなどに任せること、ルートユーザーを日常運用に使わないこと、GuardDutyなどの検知サービスの有効化、権限やキーの分割と定期ローテーション、「違和感を覚えたらまず封じ込めを優先すること」など、具体的な教訓が整理されています。クラウドに少しでもリソースを置いているエンジニアにとって、現実の失敗から多くを学べる必読の記事といえるでしょう。