Hack The Box「Sizzle」から見える、Active Directory環境に潜む“静かな落とし穴”

日々の診断業務をしていると、「設定は昔からこうだから」「これまで特に問題は起きていない」
そんな理由で、長い間そのまま使われ続けている Active Directory 環境に出会うことが少なくありません。

個々の設定を一つひとつ見れば、致命的におかしいわけではない。
当時の判断としては、むしろ妥当だったのだろうと思えるものも多くあります。
ただ、それらが年月を重ね、少しずつ積み重なった結果、今の環境がどう見えるのか──そこまで意識される機会は、意外と多くありません。

Hack The Box の「Sizzle」は、そうした“よくある設定の積み重ね”が、どのように連なり、どこから崩れていくのかを、かなり素直な形で見せてくれる演習環境です。

派手なゼロデイや、見ただけで身構えてしまうような難解なエクスプロイトは登場しません。
出てくるのは、現場で何度も目にしてきた共有フォルダの権限や、証明書サービスの使われ方、運用上のちょっとした判断ばかりです。

だからこそ、このシナリオは現実味があります。
「この設定、うちにもありそうだな」そう感じる瞬間が、何度も出てきます。

攻撃は一気に広がるわけではありません。
静かに、段階を踏みながら、気づかれにくいところから足場を作っていきます。
Sizzle は、その過程を追いながら、今の Active Directory 環境を一度立ち止まって見直すきっかけを与えてくれる題材だと感じています。

ドメインコントローラらしさは、ポートが教えてくれる

まずは nmap を使用し、全ポートのサービス詳細とスクリプトスキャンを実行しました。

nmap -p- -sC -sV 10.10.10.103

最初に見えてくるのは、53、389、636 といったポートの並びです。
DNS と LDAP が同時に開いているのを見た時点で、多くの人は自然と「これはドメインコントローラだろうな」と頭の中で当たりをつけるはずです。

特別なスキャンを仕掛けたわけでも、深く踏み込んだわけでもありません。
それでも、公開されている情報だけで、システムの役割や立ち位置がある程度見えてしまいます。

ここで意識しておきたいのは、推測が成立してしまうこと自体です。
攻撃者にとっては、最初の一歩として十分な手がかりになります。

現実の環境でも状況はよく似ています。
ネットワークの外側では見えなかったものが、境界の内側に入った瞬間、一気に輪郭を持ちはじめる。
「中に入られたら、役割は隠しきれない」という前提で設計されていない環境ほど、この段階で情報が揃ってしまいます。

ポートの情報から役割の輪郭が見えてきたあと、80 番と 443 番の Web サービスも確認します。

ただ、この環境ではトップページに表示されるのは、いわゆる「bacon sizzling」の GIF だけでした。
見た目は印象的ですが、ここから直接広がる要素はなく、視点は自然と別の入口に向かいます。

次に目に入ってくるのが、SMB の共有です。

smbclient を使い、パスワードなし（Null Session）で共有ディレクトリの一覧を確認します。

smbclient -L //10.10.10.103/ -N

CertEnroll、Operations、Department Shares といった名前を見ると、どれも業務上必要だからこそ作られた共有だろう、という印象を受けます。

派手な挙動はありませんが、静かに状況を把握するには十分すぎる材料です。
Sizzle では、この“最初の見え方”が、その後の展開を自然につなげていきます。

SMB共有と「読めるだけ」の安心感

次に目に入ってくるのが、SMB の共有です。

CertEnroll、Operations、Department Shares といった名前を見ると、どれも業務上必要だからこそ作られた共有だろう、という印象を受けます。実際、こうした名前の共有は、現実の環境でも珍しくありません。

多くの現場でよく耳にするのが、
「書き込みはできないから問題ない」
「参照権限だけなら、そこまで神経質になる必要はない」
といった判断です。

一見すると、確かに大きなリスクはなさそうに見えます。
Sizzle でも、共有全体を眺めた段階では、ほとんどが読み取り専用で、目立った違和感はありませんでした。

ただ、ディレクトリ単位で権限を追っていくと、少し様子が変わります。
Users/Public 配下だけが、例外的に Everyone フルアクセス になっていました。

設定としては、よくあるものです。
「一時的な共有のつもりだった」
「誰でも使える場所が必要だった」
そうした理由で残り続けているケースを、診断の現場でも何度も見てきました。

しかし、この一点があるだけで、環境の見え方は大きく変わります。
Sizzle では、この“ごく小さな例外”が、その後の展開を静かに、しかし確実に押し進める起点になっていきます。

SCF ファイルと NTLM 認証という、古くて今も効く手口

ntlm_theft を用いて、フォルダ閲覧時に認証を強制する .scf ファイルを生成し、書き込み可能な Users/Public へアップロードします。

Everyone が書き込める共有が存在する場合、SCF ファイルを使った NTLM 認証の誘発は、今でも十分に成立します。

特別な操作をする必要はありません。ユーザーが「いつも通り」ファイルを開いただけで、認証情報が外部に送られてしまいます。

Sizzle では、この仕組みを利用して一般ユーザーの NTLM ハッシュが取得され、その結果としてパスワードまで辿られています。
使われているのは、昔から知られている手法です。それでも、条件がそろえば今も変わらず機能します。

この流れで気づきにくいのは、挙動があまりにも静かなことです。
マルウェアが展開されるわけでも、目立った不審通信が発生するわけでもありません。

やっていることは、

• ファイルを置く。
• 誰かが開く。

それだけです。

ログを後から確認しても、「共有フォルダへのアクセスがあった」程度の記録しか残らないことも珍しくありません。
日常的な操作に紛れてしまうからこそ、こうした入口は長く見過ごされがちだと感じます。

CertEnroll と証明書サービスの“盲点”

取得したユーザー権限で改めて環境を見直していくと、CertEnroll の共有にアクセスできることが分かります。
Active Directory 証明書サービス（AD CS）を有効にしている環境では、比較的よく目にする構成です。

発行された証明書（.crt）と秘密鍵（.key）を使い、evil-winrm でパスワードレスのシェルアクセスを確立します。

evil-winrm -i 10.10.10.103 -c amanda.crt -k amanda.key -S

証明書の発行自体は、もちろん正規の機能です。
業務上必要なケースも多く、決して危険なものではありません。
ただし、運用の整理が十分でないまま使われていると、思わぬ形で影響が広がります。

たとえば、

• 誰が証明書を申請できるのか
• どのテンプレートが割り当てられているのか
• 認証手段として、どこまで利用できる設計になっているのか

こうした点が曖昧なままだと、証明書が本来想定していなかったログイン手段として使われてしまうことがあります。

Sizzle では、その結果として、証明書を用いた WinRM アクセスが成立しました。
パスワードを知らなくても、正規に発行された証明書さえあればログインできる状態です。

機能としては間違っていません。
ただ、「そこまで使われるとは思っていなかった」という場所に、足場が生まれてしまう。
AD CS には、そうした側面があると感じます。

AppLocker があっても、実行できる場所は残る

侵入後は、環境全体を把握するためのドメイン情報の収集に進みます。
この段階で、AppLocker による実行制御が効いてくる場面も出てきます。

AppLocker 自体は、有効な対策です。
少なくとも、「どこでも実行できる」状態に比べれば、環境の自由度は大きく下がります。
ただ、Windows には既定で書き込みと実行の両方が可能なディレクトリがいくつか存在します。

代表的なのが、

C:\Windows\System32\spool\drivers\color

のようなパスです。

普段の運用では、意識されることはほとんどありません。
そのため、「AppLocker を入れているから大丈夫」という感覚だけが先に立ってしまうことがあります。

実際には、例外として残っているパスを把握し、定期的に棚卸しをしていないと、制御はどうしても形骸化します。
Sizzle でも、この“隙間”を使ってツールの実行が可能になっていました。

対策が無意味になるわけではありません。
ただ、どこまで防げていて、どこが残っているのかを把握していないと、抑止力は思っているほど強くならない。
AppLocker を見ていると、そう感じる場面は少なくありません。

Kerberoasting と DCSync──よく知られたが、今も強力な連鎖

収集したドメイン情報を整理し、全体像を可視化していくと、Kerberoasting が可能なサービスアカウントが浮かび上がってきます。
サービスアカウントのパスワード管理が甘い環境では、この時点でもう一段、侵入が進む余地が残っています。

Kerberoasting 自体は、特別な手法ではありません。
それでも今なお有効なのは、サービスアカウントが「人の目から外れやすい存在」だからだと感じます。
定期的な変更がされていなかったり、強度が十分でなかったりするケースは、診断の現場でも珍しくありません。

さらに、そのアカウントが DCSync 権限を持っている場合、状況は一気に変わります。
ドメインコントローラと同じ立場で認証情報を複製できるようになり、結果としてドメイン全体の資格情報が手に入ります。
ここまで来ると、管理者権限への到達は時間の問題です。

最後に、mrlky が持つ DCSync 権限を利用して、ドメインコントローラから Administrator のハッシュを直接抽出します。

python3 secretsdump.py sizzle.local/mrlky:'Football#7'@10.10.10.103

Sizzle の流れは、決して特別なものではありません。
一つひとつはよくある設定で、単体では大きな問題に見えない。
ただ、それらが少しずつ重なった結果、最終的にドメイン全体が見えてしまう。

最終的に、DCSync を通じてドメイン管理者の認証情報が取得されます。

この演習は、その過程を非常に分かりやすく示している、典型的な例だと感じます。

この演習が現実に教えてくれること

Sizzle を通して強く感じるのは、「危険な設定」というものは、一つひとつを切り取ると案外些細に見える、という点です。

たとえば、

• 共有フォルダの権限設定
• 証明書サービスの公開範囲
• サービスアカウントのパスワード管理
• 制御ポリシーに残された例外

どれも単体で見れば、「すぐに事故につながる」と言い切れるものではありません。
実際、多くの環境で長い間問題なく使われ続けている設定でもあります。

ただ、攻撃者はそれらを一つずつ評価し、順番につなげていきます。
最初から大きな穴を探しているわけではなく、使えるものを静かに積み重ねていく。
Sizzle が示しているのは、その現実的な進み方です。

設定そのものよりも、「どう組み合わさって見えるか」。
そこに目を向けない限り、環境の本当の姿は見えてこないのだと感じます。

まとめ──“よくある設定”が連なった先に見えるもの

この手の侵入は、「侵入された後」に振り返ってみると、ほぼ必ず説明がつきます。
「あの権限、確かに少し広かった」
「証明書サービスは入れたまま、細かくは見ていなかった」
そんな言葉を、診断やインシデント対応の現場で何度も耳にしてきました。

当時の判断が間違っていたとは限りません。
ただ、時間が経ち、環境や使われ方が変わる中で、設定だけが取り残されてしまうことはあります。

だからこそ、何も起きていない今の段階で、

• 共有フォルダの実効権限がどうなっているのか
• AD CS の設定が、いまの運用に合っているのか
• サービスアカウントが、どのように扱われているのか

こうした点を、一度だけ整理してみる価値があります。

予防や診断の立場にいると、「何も出なかった」環境ほど気になることがあります。
目立った問題がない状態の中にこそ、後から効いてくる差が静かに潜んでいる。
Sizzle を通して見えてくるのは、そんな現実だと感じています。

自社のセキュリティに不安を感じたら