user.txt
- nmap 구동
- 호스트 파일 매핑
DNS 서버에 certified.htb와 같은 주소가 등록되어있지 않기 때문에,
브라우저나 도구들이 해당 도메인이 어떤 IP를 가리키는지 알 수 없다
따라서, 외부 DNS 참조 전 확인하는 내부
/etc/hosts 파일에 IP-Domain 간 설정을 지정하기 위함이다- id/pw 획득
- SMB(445) 포트가 열려 있어 확인 하였으나, 특별한 정보는 획득하지 못했다
- 5985(winRM) 포트가 열려 있어 로그인 시도 하였으나, 로그인 불가능하였다
- enum4linux-ng -A 10.129.231.186 ; 별 다른 정보는 획득하지 못했다
- nmap 구동 시, ldap이 보였고, AD 문제라고 생각이 되어 AD CS 취약점을 확인하기 위해 certipy-ad 시도하였다
- vulnerable template은 없는 것 같다
- 블러드하운드는 직접 접속해서 하는 방법도 있지만, 현재 상황처럼 계정이 있는 경우에는 외부에서도 구동이 가능한 것을 확인하였다
winRM의 경우 remote 접속 권한까지 필요하지만, bloodhound의 ldap query는 단순 조회 정도
- neo4j와 bloodhound를 실행하여 zip 파일을 분석해본다
- 참고 https://bloodhound.specterops.io/resources/edges/write-owner https://www.hackingarticles.in/abusing-ad-dacl-writeowner/
- owneredit.py를 검색하니, impacket git이 최상단에 떠있었고, kali wiki에서도 찾아보니, owneredit은 impacket의 스크립트로 제공되고 있었다
- dacledit 또한, impacket에서 제공하고 있다
- 소유주와 쓰기권한을 judith에 부여하였고, 실제 인증서 템플릿에 judith를 추가하여야 하는데, 아쉽게도 impacket에서는 해당 스크립트를 제공하지 않았다
- certipy-ad, pywhisker, bloodyAD가 멤버를 추가할 수 있는 스크립트를 제공하는데, 앞선 두개는 virtual env를 따로 구축해줘야 하는 것 같고, 현재 내 kali 버전과 호환성도 안맞는 듯 하여, bloodyAD를 사용하였다 ; 명령어 순서 중요!
- SVC 그룹에 judith가 정상적으로 추가되었음을 확인하였다
-
GenericWrite : 대상의 거의 모든 AD 특성을 Wrtie 할 수 있는 권한, GenericAll과 비슷한 공격을 진행할 수 있다
-
GenericWrtie User / bloodyAD를 활용하여 shadowCredentials 공격을 수행하였다
Shadow Credentials 공격은 Microsoft의
Windows Hello for Business(WHfB) 기능을 악용하여
AD 내의 특정 계정(사용자 또는 컴퓨터)을 장악하는 공격 기법이다
1. 공격 원리
이 공격의 핵심은 AD 객체의 msDS-KeyCredentialLink라는 속성(Attribute)에 있다
신뢰 관계 구축: WHfB는 비밀번호 대신 인증서 기반의 키 쌍을 사용하는데,
사용자가 로그인할 때 자신의 공개키를 AD 객체의 msDS-KeyCredentialLink 속성에 등록한다
공격자의 개입: 만약 공격자가 타겟 계정에 대해 GenericWrite 또는,
WriteProperty 권한을 가지고 있다면,
공격자 자신의 공개키를 해당 계정의 msDS-KeyCredentialLink 속성에 강제로 써넣을 수 있다
인증서 요청: 이제 AD는 공격자가 등록한 키를 정당한 것으로 간주하게 되고,
공격자는 대응하는 개인키를 이용해 PKINIT 인증을 시도하고,
도메인 컨트롤러(DC)로부터 해당 계정의 **TGT(Ticket Granting Ticket)**를 발급받는다
*PKINIT 인증이란 : Public Key Cryptography for Initial Authentication in Keberos
커버로스 인증과 다른점은 PKINIT은 비대칭키 암호화 방식을 도이하여 보안성을 증가시켰다
한마디로, Public Key, PW 없이 제 3자(DC)의 CA(인증서) 발급 여부만으로 인증을 진행
- Shadow Credential 공격을 통해 인증서 기반 키 쌍을 획득하였다
- PKINITtools를 활용하여 인증 시도하여 TGT를 발급 받았다
ccache : 인증서들의 지갑
Windows Ticket in memory
Linux Ticket in file(ccache)
- 발급받은 TGT를 사용하여 NTLM 해시를 추출하고자 하였으나 실패하였다
PKINIT은 비밀번호 없이 로그인을 가능하게 하지만,
AD 환경의 많은 서비스(SMB WMI 등)는 여전히 NTLM 인증을 요구하는 경우가 많다
또한 TGT는 유효기간이 짧지만,
NTLM 해시를 추출하는 경우 비밀번호를 바꾼것과 다름없는 효과를 가진다
이를 활용하여 eveil-winrm, impacket-pasexec 같은 도구를 통해 -hashes 옵션을 사용하여 RCE를 수행한다
- export KRB5CCNAME= 설정을 통해, kali에서 커버로스 도구가 어떤 티켓을 사용하여야 하는지, 설정해준다
- TGT는 파일 형태로 저장되는데(mgmt_svc.ccache), getnthash.py는 해당 파일이 어디 위치하는지 모르기때문에, 해당 명령을 통해 “지금부터 실행되는 모든 커버로스 관련 명령은 이 파일을 티켓 저장소로 참조하라” 라고 선언하는 것(현재 터미널에서만 유효함)
- NT 해시를 획득하였고, NTLM → PTH 가능하다
- user.txt 획득
root.txt
- _svc 계정으로 로그인 후, bloodhound로 다시 한번 확인 하였다
- outbound로 CA_OPERATOR 계정에 접근이 가능했다 ; CA 계정이므로 인증서.. 결국 관리자 권한으로 이어지지 않을까 생각했었다
- GenericWrite를 공부하며, GenericAll은 이보다 더 좋은 권한임을 알고 있었다
- 다시 한번 Shadow Credential 공격을 시도하였다
- 티켓을 발급받고, 이를 활용하여 NTLM 해시 획득하였다
- evil-winrm에 실패하였다
- winRM 서비스를 사용하지 못하는 사용자인 것 같다
- outbound도 없고, CA 계정이므로 인증서 템플릿 관련 취약점을 분석해 본다
certipy-ad 인증서 체크 ; 해시는 -hashes 옵션
참고 https://www.hackingarticles.in/adcs-esc9-no-security-extension/
- ESC 9 취약점이 존재합을 확인하였다
ESC9(Extended Security Check 9)
ADCS 에서 인증서 템플릿의 msPKI-Enrollment-Flag 설정과 관련된 보안 결함
Enrollment-Flag 내 NoSecurityExtention 값이 포함되어 있어야 함
UPN을 조작하여 ADCS가 잘못된 인증서를 발급받게 하고,
해당 인증서를 사용하여 로그인 하고자 함- CA_OPERATOR의 권한으로 Admin의 upn을 CA로 바꾸고자 했지만, 실패하였다
- 왜냐하면, AD ROLE 중 하위에서 상위의 변경은 허용되지 않음
- 따라서, 현재 횡적이동은 _mvc → CA → ADM 이지만, 실제로는 _mvc의 쓰기 권한을 활용하여 CA의 UPN을 변경(ADM으로) ADCS 발급 시, ESC9 취약점에 의해 UPN만 보고 신원 확인 후 인증서를 발급하게 된다
- 따라서 위 내용이 아닌 아래 명령어를 통해 CA의 UPN을 변경한다
- 인증서를 요청한다
- 인증서를 받았고, 해당 인증서를 사용하여 로그인을 시도하였다
- 계속 해당 에러가 발생하였다
현재 AD DB에는 아래와 같이 admin@certified.htb UPN이 중복 존재할 것이다
adadministratorm - administrator@certified.htb
CA_OPERATOR -administrator@certified.htb
이런 경우, UPN 혼동으로 인한 에러가 발생한다
따라서, 인증서를 이미 받았기 때문에 CA 계정의 UPN을 다시 원상복구 하였다- UPN 오류를 해결하니, Clock skew 에러 발생하였고, 아래와 같이 시간 동기화를 진행하였다
- NTLM 해시를 획득하였고, 이를 통해 ADM 쉘을 획득하였다
- root flag를 획득하였다
