또 AD문제인 것 같다,,
정보를 정리해보자.
- 도메인: logging.htB
- DC 호스트명: DC01.logging.htb
- 웹: IIS 10.0
- 원격 접속 후보: WinRM 5985
- SMB, LDAP, Kerberos가 모두 열려 있음 -> AD문제라 판단!
추가로 머신 info를 보니 계정 정보가 하나 제공된다.
smb에 활용해봤다.
성공! 이제 이 계정으로 공유폴더를 확인해보자.
참고로 익명 계정으로 시도하면 이렇게 실패한다.
확인 ㄱㄱ
이 중에서 admin, c는 읽기 권한 x
logs파일은 기본으로 있는 애가 아니다. 얘를 확인해보자.
추가로 맨 아래 파일에 대한 설명은 다음과 같다.
일단 당장에 활용가능한 건 logs이니 얠 중심으로 탐색하자.
4개의 파일이 보임.
다 다운받아보자.
다 열어보기 ㄱㄱ
중간에 계정 정보가 보인다.
ldap는 안 된다,, kerberos를 활용해보자.
추가로 smb랑 winRm역시 안 됐다,,
그리고 켈베로스로 다시 해보는데, 역시나 안 된다,,,
그래서 뭔가 했는데,,,,
비번을 무작위로 여태 나온 걸 섞어야 하나,, 싶었다.
근데 웃기게도 2025 ->2026으로 바꾸니까 된다....ㅋㅋㅋㅋ
그런데 여전히 활용이 안 된다..
여러차례 다양한 방식으로 해봤는데 안 된다..
여기서 어떻게 할까 지피티한테 물어보니, 그냥 여기서 블러드하운드를 써보라고 나온다.
아무래도 비번이 바뀐것 같다.
블러드 하운드에 접속해서 계정을 찾아주자.
그리고 목표 계정을 설정해봤는데, 안 뜬다,,,,흠,,,
그러다가 지피티에서 나온 의견이, 현재 계정 자체에서 수정가능한 걸 찾아보자라는 의견이었다.
그래서 결과를 출력해 알려주니, 라는 계정이 의심스럽다 한다.
추가로 권한정보까지 확인해봤다.
-> 즉, 해당 계정은 msDS-GroupManagedServiceAccount으로, 일반 사용자 계정이 아니라 AD에서 비밀번호를 관리하는 gMSA 계정이라고 한다.
그래서 설명에 나온대로 shadow 크리덴셜이라는 방식을 사용해 봄. 이는 해시로 로그인이 가능하도록 돕는 방식이라고 한다!
핵트릭스에도 섀도우 핵트릭스가 정리되어 있긴하다,,
Shadow Credentials - HackTricks
Check the original post for all the information about this technique .
hacktricks.wiki
svc_recovery는 msa_health$의 msDS-KeyCredentialLink를 수정할 수 있다.
: gMSA의 관리형 비밀번호를 강제로 바꾸지 않고 별도의 인증 키를 추가하는 방식이라, 기존 계정 동작을 유지하면서 인증수단을 얻을 수 있다..!고 한다.
-> 저 권환 활용해 내가 직접 생성한 공개키 정보를 해당 계정에 등록
-> 이후 등록한 개인키로 인증을 수행
-> msa_health$의 TGT와 NT 해시를 획득
이제 플래그를 읽어야 하는데,,,또 권한이 없단다.
WinPEAS를 업로드해서, 어떻게 권한 상승이 가능할지를 탐색해봤다.
결과 모두 복붙해서 gpt에게 질문,,
-> 분석결과는 다음과 같다.
- UpdateChecker Agent라는 이름이 이전 TaskMonitor.log의 단서와 일치한다.
- 3분마다 자동 실행된다.
- WinPEAS 출력에는 logging\Administrator와 연결된 것으로 표시되어 잠재적 영향이 매우 크다.
- 실행 파일, DLL, 설정 또는 입력 파일 중 하나라도 현재 사용자가 수정할 수 있다면 자동 코드 실행이 가능하다.
즉, 저 updatemonitor라는 걸 활용해서 악성 zip을 업로드하는 방식을 사용할 수 있다고 한다.
악성 zip은 따로 업로드해주고
Meterpreter에서 콜백을 기다리면 된다,,
접속 성공!
일단 유저 플래그는 끝!
이제 루트 플래그를 따자.
일단 앞선 계정처럼, jaylee또한 TGT가 존재할 거라 생각했다.
얘를 추출해보자,,
tgt추출 후, 그대로 캐시로 변환해준다.
(Rubeus 업로드 먼저하고 함)
이제 캐시형태로 변환해줌
이제 새로운 계정 권한을 확보했으니, 먼저 Jaylee가 수정할 수 있는 AD 객체를 열거해보자.
CREATE_CHILD라는 키워드가 많이 보인다,,,
해당 권한은, 해당 AD 통합 DNS 영역에 새로운 DNS 객체를 만들 수 있다는 의미라 한다.
> 즉, logging.htb 아래에 임의의 A 레코드를 생성할 수 있다는 의미가 됨!
이제 좀 더 Jaylee계정에 대한 권한 정보를 찾아보자..
솔직히 이 부분은 이해가 잘 안 갔는데,,, 일단 시간이 부족해서 gpt가 해보라는대로 했다.
-> 즉, 1. 대상이 내부 WSUS를 사용하고 있었다.
2. wsus.logging.htb DNS 레코드가 원래 없었다. -> 즉, 우리가 선점해서 활용 가능하다
3. Jaylee가 DNS 레코드를 만들 수 있었다. -> create child권한 앞에서 확인한 거..
4. Jaylee가 HTTPS 서버 인증서를 발급받을 수 있었다. - IT그룹에 있던 거..
즉, 우리는 WSUS라는 도구를 활용해보려 한다.
wsuks 도구 정리)
가짜 WSUS 서버를 만들어주는 도구.
현재 타겟의 레지스트리에는 이렇게 저장되어 있음
-> 저 말을 해석하자면, 즉 DC01은 주기적으로 wsus.logging.htb:8531에 접속해서 업데이트를 받는 것이라 한다..
https의 dns 과정은 다음과 같다)
1. 도착할 서버의 ip확인
2. 서버의 인증서를 통해, 그 인증서가 진짜인지 확인
그럼 위 방식을 활용해, 뒤에 있을 공격 과정을 정리해보자면 이렇다.
1. https가 갈 ip를 내 머신의 ip로 바꾸기 (원래가 내부 wsus에 접속하는 것이었다면)
2. 내 머신은 미리 도메인이 인정하는 wsus.logging.htb 인증서를 받아두기
-> UpdateSrv라는 템플릿을 통해 받을 수 있다고 함
: wsus.pem
그럼 이제 위 결과로 나온 서버 인증서를 발급받아보자.
인증서와 개인키를 분리해주고
두 파일을 하나의 PEM으로 합쳤다.
이제 다음은, ADIDNS 레코드 생성해야한다고 한다....
: 도메인 DNS 주소록에 wsus.logging.htb의 IP를 새로 등록하는 것
이 부분도 gpt에서 나온대로 따라한거라, 추후에 다시 공부해봐야 할 것 같다,,
처음 dig에서 아무 결과도 반환되지 않음
-> Jaylee의 CREATE_CHILD 권한으로 wsus.logging.htb가 공격자 IP를 가리키도록 만들었다.
타겟 측 dns도 확인 ㄱㄱ
참고로 내가 노린 건 이렇다.
가짜 WSUS 서버 준비)
Pwnbox에 wsuks와 필요한 nftables Python 바인딩을 설치,
내 측에서도 wsus.logging.htb가 Pwnbox 주소를 가리키도록 등록.
새로운 Domain Admin 토큰 발급 -> 새로 winRM접속 시도!
끝......!!
