mi: IP別未解決分析
主な根拠: in/mi/メモ用.pdf、in/mi/20260321_試験2回目.pdf、in/mi/oscp三回目メモ.pdf
1回目: 192.168.100.112
状況
oscp.exam を hosts に追加し、WBCE を発見。reset_admin_pass.php から admin / reset123 を仮定してログインし、WBCE 1.6.1 の exploit でリバースシェル、local.txt 取得まで進んでいます。
管理者権限や proof までの記録は不十分です。
解けた可能性
WBCE の管理者 RCE でシェルを得た後は、config.php の DB 認証情報、Web ユーザーの sudo / SUID / cron、バックアップ、ローカルサービス、パスワード再利用を優先して確認します。wbce や verycomplicatedpassword123! のような設定値が出ているため、DB 内のユーザー情報や他サービスへの横展開が有力でした。
1回目: 192.168.100.110
状況
hosts 設定、WebThemez / LFI らしきリンク、Web 側の調査痕跡がありますが、具体的な突破手順は残っていません。
解けた可能性
WebThemez や Nexus 風のアプリであれば、既知 exploit だけでなく、ファイル読み取り API、テンプレートパス、Swagger / static JSON、ローカル管理 API の有無を確認します。後の 3 回目で同系統の WHOIS / POP3 / localhost API / LFI が成立しているため、この 1 回目でもメールサービス、WHOIS、POP3、ローカル API を組み合わせる視点が必要でした。
1回目 AD: 192.168.100.206
状況
r.andrews / BusyOfficeWorker890 で WinRM に入り、whoami /priv から Potato 系が使えそうだと判断しています。GodPotato で権限昇格し、proof.txt、SAM / SYSTEM、Administrator ハッシュ、BloodHound、backup.zip、b.martin / MartiniAllNight222 まで進んでいます。
このホスト自体は大きく進められていますが、後続の AD 横展開を安定させる観点では改善余地があります。
解けた可能性
得たローカル管理者権限、BloodHound、b.martin 認証情報をつなげて、SRV / DC への SMB、LDAP、RPC、Kerberos の経路を整理するべきでした。proof 取得後も、backup.zip 由来の資格情報がどのホストで何に使えるかを表にして、認証成功、管理者権限、RDP 可否、WinRM 可否を分けると迷いにくくなります。
2回目: 192.168.136.112
状況
FTP anonymous、WordPress、PDF 由来の piccaso らしきキーワード、WordPress API を確認しています。API は認証が必要で、XML-RPC / WordPress へのブルートフォースも決定打になっていません。
解けた可能性
piccaso を単一パスワードとして試すだけでなく、ユーザー名、作者名、PDF メタデータ、画像名、日付、ドメイン名を材料にして、WordPress ユーザー列挙と組み合わせるべきでした。REST API、author archive、XML-RPC、wp-json、テーマ / プラグイン / バックアップファイルの列挙を先に固めます。
WordPress exploit が刺さらない場合は、認証前 API、アップロード権限、メディア処理、テーマ編集権限、パスワードリセット導線を確認します。
2回目: 192.168.136.111
状況
emails.zip から sasha / Voltaic1992 を得て、nxc では一部ヒットしています。しかし、RDP 実接続に失敗し、Nicepage CMS、RPC、443 周りでも突破できずに詰まっています。
解けた可能性
nxc rdp [+] を RDP 対話ログオン成功と扱わず、資格情報の有効性、ドメイン指定、ローカル認証、NLA、時刻同期を切り分けるべきでした。SMB と RPC で所属グループ、パスワード期限、共有 ACL、ログオン権限を確認し、WinRM、WMI、リモートレジストリ、LDAP も試します。
Nicepage 側は、静的サイト生成物だけか CMS 管理画面があるかを分け、アップロード、バックアップ、設定ファイル、フォーム処理を調べると別経路が見つかった可能性があります。
2回目 AD: 192.168.136.206
状況
r.andrews / BusyOfficeWorker890 で WinRM、SeImpersonatePrivilege から GodPotato、Administrator 権限、BloodHound、backup.zip、b.martin / MartiniAllNight222、チケット import まで進んでいます。
一方で、チケットや pivot を十分使い切れず、後続ホストで詰まりが残っています。
解けた可能性
Kerberos を使う場合は、/etc/hosts、DNS、FQDN、時刻同期、krb5.conf、KRB5CCNAME、klist を最初に固定します。その上で getTGT.py、impacket-* -k -no-pass、GetUserSPNs、bloodhound-python を FQDN ベースで通すと、チケットの成否を追いやすくなります。
ntds.dit だけが取れても SYSTEM hive がないと復号できないため、VSS、バックアップ権限、ローカル管理者権限、DC 上の共有、レジストリ hive 取得経路を同時に確認する必要がありました。
2回目: 192.168.136.110
状況
FTP anonymous は空、PostgreSQL / MariaDB は認証情報なし、WebThemez CMS らしきものや Perl の違和感を見ていますが、入口に至っていません。
解けた可能性
TCP 全ポート、UDP、vhost、Web パラメータ、バックアップ、.git、設定ファイル、LFI を再探索すべきでした。後続の 3 回目と同系統なら、WHOIS / POP3 / メール本文 / localhost API / Swagger / LFI の線が強いです。
DB は外から直接入れない可能性が高いため、Web 側の設定ファイルや SSRF / LFI / RCE でローカル到達後に使う前提で扱うのがよさそうです。
2回目 AD: 172.16.136.202
状況
b.martin / MartiniAllNight222 で WinRM できていますが、権限不足、listener/pivot の不調、ntds.dit はあるが SYSTEM がない、PowerUp に望みがありそう、という状態で詰まっています。
解けた可能性
まず、b.martin のローカル権限、グループ、サービス操作権限、書き込み可能パス、スケジュールタスク、AlwaysInstallElevated、SeBackupPrivilege の有無を確認します。ntds.dit を見つけた場合は、同じバックアップ元から SYSTEM hive を得る筋を最優先にします。
SRV 側で権限が低いなら、BloodHound で b.martin から SRV / DC への ACL、ローカル管理者、セッション、グループ経路を見直し、WinRM で入れたこと自体を pivot の足場として使うべきでした。
3回目 AD: 192.168.144.206 / 172.16.144.202 / 172.16.144.200
状況
r.andrews / BusyOfficeWorker890 から WS26 に入り、環境変数から administrator / WorkIsValuable444 を得て proof 取得。mimikatz から v.perry / SurfaceConditionMove441、BloodHound / BloodyAD による HelpDesk Users への権限操作、IP3 の local 取得まで進んでいます。
ただし DC20 までは到達できていません。
解けた可能性
HelpDesk Users への追加や IP3 local 取得後に、IP3 上での資格情報探索を継続する必要がありました。KeePass、ブラウザ資格情報、DPAPI、サービス設定、共有、ローカルグループ、SAM / SYSTEM、LSASS、スケジュールタスク、アプリ設定を確認し、DC へつながる次の資格情報を狙います。
BloodHound では、v.perry から HelpDesk Users までの達成で止めず、そのグループがどのコンピュータ、ローカル管理者、ACL、セッションに接続しているかを追い切るべきでした。Kerberos 操作は、FQDN と時刻同期を固定してから行うと失敗の原因を切り分けやすくなります。