AS Requested Service Tickets
도메인 서비스 티켓을 요청하기 위해서는 SPN을 통해 TGS-REQ를 한다고 알려져 있지만 이는 사실이 아닙니다. 실제 TGS-REQ에서 sname 필드는 티켓을 요청하는 주체를 나타내는 cname 필드와 동일한 구조체를 가지고 있으며, 값의 유형을 나타내는 name-type의 경우 상당히 융통성 있기 때문입니다.
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
realm [2] Realm
sname [3] PrincipalName OPTIONAL,
...
}
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
cname / sname 필드에 국한하는 것을 넘어서 AS-REQ와 TGS-REQ는 근본적으로 유사한 구조체를 가집니다. 다음 사진은 impacket 프로젝트의 getTGT와 getST를 정상적으로 요청했을 때 요청하는 패킷입니다.


우리가 흔히 아는 커버로스 1-2 단계에서 발급되는 TGT는 3-4 단계에서 발급되는 서비스 티켓과 근본적으로 다른 특수한 티켓이 아닌, krbtgt의 티켓일 뿐입니다. 이러한 이유로 AS-REQ와 TGS-REQ는 유사하며, KDC에서 어떤 단계냐에 따라 검증하는 로직이 다른 것을 제외하면 대부분 동일하다고 볼 수 있습니다.

AS-REQ에서 정상적인 모든 요청은 sname 필드가 krbtgt/domain으로 고정되어 있는데, 언급했듯이 TGT 역시 서비스 티켓이기 때문에, 이 필드를 다른 서비스 티켓으로 변경 시 KDC는 정상적으로 서비스 티켓을 발행합니다.
AS-REQ에서도 타임스탬프를 cname 주체의 해시 패스워드로 암호화하여 요청이 인가자로부터 전송된 것인지 판단하는데, Do not require Kerberos pre-authentication 속성이 설정된 계정은 타임스탬프를 인증하는 과정을 생략하게 됩니다. SPN 목록을 모르더라도 SPN을 가진 객체 이름만 아는 상태에서 AS-REP Roasting 공격에 취약한 계정이 도메인 내에 존재한다면, 공격자는 이 계정을 이용하여 AS-REQ 과정의 인증을 건너뛰고 서비스 티켓을 발급받을 수 있습니다.
Abuse
# Do not require Kerberos preauthentication 설정 객체 열거
ldapsearch -x -H ldap://<dc-ip> -D <user@domain> -w <pass> -b "dc=,dc=" "(&(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" cn,distinguishedname,samaccountname
# AS-REP Roasting에 취약한 객체를 이용하여 사용자 SPN 요청
impacket-GetUserSPNs -no-preauth <target> -usersfile <user-file> -dc-host <dc-ip> <domain>/
Practice
원활한 실습을 위해서 공격자는 이미 RID Cycling과 같은 방법을 통해서 도메인 내의 유효한 사용자 목록을 획득했다고 가정하고, users.txt 파일에 실제 도메인에 존재하는 계정들을 저장해두고 사용하겠습니다.
ldapsearch를 사용하여 도메인에 AS-REP Roasting에 취약한 객체가 있는지 열거합니다.


References
Last updated
Was this helpful?