sgy: IP別未解決分析
主な根拠: in/sgy/exam1、in/sgy/exam2、in/sgy/exam3
exam1: 192.168.131.111
状況
SMB anonymous、AnneAuto 共有、emails.zip、Web 上の氏名情報を確認しています。ZIP のクラックやユーザー推測で詰まり、RDP / SMB の有効な認証まで届いていません。
解けた可能性
展開済みのメール、.msg、vCard、anne.txt、names.txt、users.txt、pass.txt などを材料に、ユーザー名生成とパスワード生成を広げるべきでした。名前、会社名、年、月、部署名、Voltaic1992 のような既知パターンをルール化して ZIP と SMB / RDP の両方に使います。
RDP が絡む場合は、ドメイン指定、ローカル認証、NLA、FQDN、時刻同期を切り分けます。メール本文から得た資格情報が対話ログオン不可でも、SMB / RPC / WinRM / LDAP で別の権限が出る可能性があります。
exam1: 192.168.131.112
状況
未認証 API から JWT やユーザー情報を取得し、jay / Beginnin24Of4End81 で WinRM、local flag まで進んでいます。whoami /priv では強い権限はなく、SeChangeNotifyPrivilege と SeIncreaseWorkingSetPrivilege のみ有効でした。
ログ上では C:\inetpub\wwwroot\backend\api\v1\test.txt への書き込み確認があり、Web ルートまたは API 配下への書き込み可能性が見えています。
解けた可能性
IIS 配下に書けるなら、単なるテキスト配置で止めず、ASPX、web.config handler、既存 API ルートの上書き、拡張子マッピング、アプリプール権限での実行可否を試すべきでした。Web 書き込みが成立すれば、jay の低権限をアプリプール ID や別ユーザーの実行権限に変換できた可能性があります。
また、Firefox / DPAPI / RoamingCredentialSettings / 設定ファイルなど、ログに残るユーザー領域の資格情報探索も続ける価値がありました。Potato 系は SeImpersonatePrivilege がないため優先度は低いです。
exam1 AD: 192.168.131.206 / 172.16.131.200 / 172.16.131.202
状況
WS26 のポート、SMB signing、RDP / WinRM の存在は確認していますが、有効な AD 足場を作れず、SMBGhost、Zerologon、ntlmrelay などの試行に寄っています。
解けた可能性
OSCP の AD セットでは、まず与えられた、または他ホストから得た認証情報を -d oscp.exam 付きで SMB、WinRM、RDP、LDAP に試し、認証成功、管理者権限、対話ログオン可否を分けるべきでした。古い CVE はバージョンが一致しない限り時間を使いすぎない方がよいです。
WS26 に入れたら、winPEAS、環境変数、LSASS / SAM / SYSTEM、BloodHound、共有、ブラウザ、設定ファイルから次の資格情報を探し、172 系に pivot して DC / SRV の列挙へ進みます。
exam2: 192.168.106.110
状況
.env から DB_USERNAME=root、DB_PASSWORD=Strong.DB?Password を得ていますが、SSH / FTP では使えず、Apache 2.4.50 向け exploit を Apache 2.4.52 に試して失敗しています。
解けた可能性
.env の認証情報は OS ログインではなく、Web アプリや DB の内部接続用と考えるべきでした。アプリのフレームワーク、ルート、.git、composer / npm ファイル、ログ、バックアップ、DB 管理画面、SSRF / LFI を確認し、DB へローカルから到達する経路を探します。
バージョン不一致の Apache exploit は優先度を下げ、.env からアプリの秘密鍵、セッション署名、DB 内ユーザー、管理画面の突破につなげるのが自然です。
exam2: 192.168.106.111
状況
BarracudaDrive 6.5、WebDAV 系メソッド、PostgreSQL 15.2 を確認。postgres / password で DB には入れていますが、CVE-2019-9193 系は刺さらず、関数も存在せずに詰まっています。
解けた可能性
DB ログイン後は、CVE だけでなく DB 内容、権限、拡張、ファイル読み書き、superuser 可否、COPY PROGRAM 可否を確認します。PostgreSQL 15.2 では古い exploit がそのまま使えないことが多いため、DB 内の Web 認証情報や BarracudaDrive の設定に接続する視点が必要でした。
WebDAV があるなら、PUT / MKCOL でアップロードできる場所と、実行可能な Web ルートが一致するかを確認します。BarracudaDrive は PG の Medjed と近いテーマなので、既知の操作感や設定ファイル探索を練習しておくとよさそうです。
exam2: 192.168.106.112
状況
FTP、MySQL、HTTPS、simulate.ps1、.env、messages-for-admin を確認しています。admin@oscp.exam / AdminIsCool234 で Web ログインできていますが、アップロードや MySQL 接続、PHP 8.2.12 / CVE-2024-4577 の試行は RCE に至っていません。
解けた可能性
HTTPS の証明書エラーを -k で統一し、Cookie やセッション、messages-for-admin の入力処理、管理画面の隠し機能を優先して見るべきでした。.env の MySQL は 127.0.0.1 指定のため、外部からではなく SSRF、LFI、RCE、ローカルポートフォワード後の利用が本命です。
CVE-2024-4577 は環境条件依存が強いため、CGI パス、ロケール、エンコード、php-cgi.exe の存在を確認し、刺さらなければアプリロジックへ戻る判断が必要でした。
exam2 AD: 192.168.106.206
状況
r.andrews / BusyOfficeWorker890 で WinRM、環境変数から administrator / WorkIsValuable444 を取得し、proof と mimikatz まで到達しています。v.perry / SurfaceConditionMove441 を得て Ligolo で 172 系へ pivot しています。
whoami /priv では SeImpersonatePrivilege はなく、Potato 系ではなく通常の資格情報再利用と AD 列挙が中心です。
解けた可能性
WS26 は十分な足場になっているため、ここからは v.perry と Administrator 権限の使い分けが重要です。BloodHound / SharpHound の実行ログはあるため、結果 ZIP を確実に回収し、v.perry の ACL、グループ、セッション、ローカル管理者権限を優先して追うべきでした。
exam2 AD: 172.16.106.202
状況
v.perry / SurfaceConditionMove441 で SMB / RDP の認証ヒットは出ていますが、RDP 実ログオン、psexec、WinRM で詰まっています。
解けた可能性
nxc rdp [+] は資格情報が有効という意味で扱い、RDP 権限不足、NLA、Kerberos、FQDN、時刻同期、ドメイン指定を分離します。SMB 共有列挙ができるなら、共有 ACL、SYSVOL、サービス設定、MSSQL、ローカルグループ、BloodHound パスを先に拾います。
xfreerdp は /d:oscp.exam、FQDN、/sec:nla、NTLM 強制、証明書無視を試し、並行して Kerberos チケットで smbclient -k や impacket を通すと原因を分けやすくなります。
exam2 AD: 172.16.106.200
状況
v.perry で SMB / LDAP の一部列挙ができ、LDAPDomainDump の結果が残っています。r.gallagher が Domain Admins かつ Human Resources、説明に Backup Administrator、c.dean に General Administrator のような情報が見えています。
解けた可能性
LDAP の説明欄、グループ、SPN、パスワードポリシーを起点に、AS-REP Roast、Kerberoast、パスワードスプレー、GPP / SYSVOL、ACL レビューを行うべきでした。r.gallagher、c.dean、svc 系の優先度を上げ、既知パスワードの派生を低回数で試します。
exam3: 192.168.142.110
状況
WHOIS から sysadmin@oscp.exam、POP3 から james / Welcome2026! を得て SSH、local まで進んでいます。localhost の 127.0.0.1:8005 に Nexus Platform API / Swagger / Werkzeug を見つけていますが、古い Werkzeug debug exploit に寄って proof には届いていません。
解けた可能性
この系統は、Werkzeug debugger ではなく Swagger / API の LFI が本命です。SSH ローカルポートフォワードで API を安定して叩き、/static/swagger.json、download / artifact / file 系エンドポイント、../../../../etc/passwd、/root/.ssh/id_rsa の読み取りを試すべきでした。
root SSH が有効なら、LFI で秘密鍵を得た後に root ログイン、または root の設定ファイルやトークンを読む経路が現実的です。
exam3: 192.168.142.111
状況
FTP anonymous は見えるがホームに入れず、Web にメールアドレス、Redis 5.0.14.1 on Windows が unauth で開いています。CONFIG SET dbfilename、SET、SAVE は ERR で止まり、SSH がないため Linux でよくある SSH key 投下も使えません。
解けた可能性
Windows Redis では、SSH key 投下ではなく Web ルートへの ASPX / web.config 書き込みを狙います。まず CONFIG GET dir、Redis の実行ユーザー、書き込み可能ディレクトリ、IIS ルート候補を確認し、SAVE の ERR が権限、パス、保護設定、ファイル名制限のどれかを切り分けます。
Redis module load や replica 系の手法は条件が厳しいため、WebDAV / FTP / IIS のドキュメントルート特定と組み合わせて、書ける場所と実行される場所を一致させるのが重要です。
exam3 AD: 192.168.142.206
状況
r.andrews / BusyOfficeWorker890 で WS26 に入り、Web / MariaDB / XAMPP / schema.sql / Kerberoast を調査しています。svc_mssql / qazwsx を得ていますが、WinRM は失敗し、RunasCs やサービスバイナリ差し替えも決定打になっていません。
BloodHound ZIP は残っており、SVC_MSSQL には SRV22 の MSSQL SPN が見えます。whoami /priv では SeBackupPrivilege は Disabled、SeChangeNotifyPrivilege は Enabled でした。
解けた可能性
svc_mssql は RDP / SMB の認証ヒットよりも、SPN 名どおり MSSQL への接続を優先して検証すべきでした。ドメイン認証、FQDN、Kerberos チケット、mssqlclient.py -windows-auth、ポート 1433、SQL 権限、xp_cmdshell 可否、リンクサーバ、資格情報を確認します。
RDP / SMB の [+] は管理者権限を意味しないため、psexec 失敗は自然です。BloodHound で SVC_MSSQL の権限、委任、セッション、グループ、MSSQL 経由のローカル権限を追う方が筋でした。
また、SeBackupPrivilege が Disabled と表示されていても、それは「権限が存在しない」ではなく「現在のトークンで未有効化」という意味です。有効化できれば reg save HKLM\SAM と reg save HKLM\SYSTEM、または backup semantics を使って SAM / SYSTEM を抽出し、ローカル Administrator の NTLM hash 取得から Pass-the-Hash でローカル admin へ進めた可能性があります。このため、WS26 では SeBackupPrivilege の有効化と SAM / SYSTEM 抽出を試す価値が高かったです。
exam3 AD: 172.16.142.202
状況
svc_mssql / qazwsx と r.andrews で SMB / RDP の認証ヒットは出ていますが、WinRM、psexec、wmiexec、smbexec は権限不足で失敗しています。krb5.conf に誤った YOUR_DOMAIN.COM が残るなど、Kerberos 設定の不整合もあります。
解けた可能性
Kerberos を使うなら、/etc/hosts、/etc/resolv.conf、krb5.conf、時刻同期、FQDN を最初に修正する必要がありました。その後、getTGT.py、KRB5CCNAME、klist、impacket-* -k -no-pass で MSSQL / SMB / LDAP を確認します。
RDP については /d:oscp.exam、FQDN、NTLM 強制、NLA 指定で再確認します。ただし、対話ログオン権限がない場合もあるため、MSSQL と BloodHound 上の権限経路を優先した方が到達可能性は高いです。
exam3 AD: 172.16.142.200
状況
DC20 はスキャン止まりで、実質的な列挙や権限取得には届いていません。
解けた可能性
DC へ直接攻撃するより、WS26 / SRV22 から得たチケット、MSSQL 権限、BloodHound の ACL / group path、SYSVOL / LDAP / Kerberoast を経由して段階的に進むべきでした。DC 側では SMB signing が有効で relay は難しいため、資格情報、ACL、Kerberos の正攻法が中心になります。