Kerberos AS-REP Roasting

agnusdei·2025년 7월 9일
0

CTF

목록 보기
40/154

Kerberos AS-REP Roasting (MITRE ATT&CK: T1558.004)

문제

Kerberos AS-REP Roasting 공격 기법에 대해 상세히 설명하시오. MITRE ATT&CK 프레임워크의 T1558.004 기술 카테고리에 해당하는 이 공격의 과정을 매우 상세하게 설명하시오.

답변

1. 개념

Kerberos AS-REP(Authentication Service Reply) Roasting은 Kerberos 인증 프로토콜의 사전 인증(Pre-Authentication) 메커니즘이 비활성화된 계정을 대상으로 하는 공격 기법이다. 공격자는 이러한 계정에 대한 인증 서비스 응답(AS-REP, Authentication Service Reply)을 획득하고, 이를 오프라인에서 크래킹하여 계정 암호를 알아내는 방식이다. 여기서 AS는 Authentication Service(인증 서비스), REP는 Reply(응답)의 약자로, Kerberos 인증 체계에서 인증 서버가 클라이언트에게 보내는 응답 메시지를 의미한다. Kerberos 프로토콜 공식 문서 RFC 4120에서도 이 용어를 사용하고 있다.

2. 역할 & 목적

  • 공격 목적: 사용자 계정 비밀번호 획득
  • 타겟: 사전 인증이 비활성화된 Active Directory 사용자 계정
  • 활용: 권한 상승, 수평적 이동, 계정 탈취

3. 공격 원리 및 프로세스 (MITRE ATT&CK T1558.004)

3.1 MITRE ATT&CK 분류

  • 전술(Tactic): 자격 증명 접근(Credential Access)
  • 기법(Technique): T1558 - Steal or Forge Kerberos Tickets(Kerberos 티켓 탈취 또는 위조)
  • 하위 기법(Sub-technique): T1558.004 - AS-REP Roasting
  • 적용 단계: 권한 상승 전 정찰 및 자격 증명 획득 단계
  • 필요 권한 수준: 네트워크 접근 권한(도메인 내 일반 사용자 계정 수준)

3.2 Kerberos 사전 인증 메커니즘

  1. 정상적인 Kerberos 인증 흐름:

    • 클라이언트가 사용자 ID로 TGT(Ticket Granting Ticket) 요청 - AS-REQ(Authentication Service Request)
    • 클라이언트는 타임스탬프를 암호화하여 사전 인증 데이터 제공
    • KDC(Key Distribution Center)는 사용자 암호로 복호화 시도
    • 성공 시 TGT 발급 - AS-REP(Authentication Service Reply)
  2. 사전 인증 비활성화 시:

    • 클라이언트의 타임스탬프 암호화 검증 과정 생략
    • 요청 시 바로 AS-REP(Authentication Service Reply) 응답 발급

3.3 AS-REP Roasting 공격 과정 상세

  1. 정찰 단계:

    • 도메인 컨트롤러 식별 (nslookup, nmap 등 활용)
    • 도메인 정보 수집 (도메인 이름, 구조 등)
  2. 계정 식별 및 열거:

    • LDAP 쿼리를 통해 도메인 내 사용자 계정 목록 수집
    • 특히 'DONT_REQ_PREAUTH' 플래그(0x400000)가 설정된 계정 식별
    • PowerView, BloodHound 등 도구로 Active Directory 계정 정보 추출
    Get-DomainUser -PreauthNotRequired -Properties distinguishedname
  3. AS-REP 요청 수행:

    • 식별된 계정들에 대해 사전 인증 데이터 없이 AS-REQ 메시지 전송
    • 요청 메시지에는 사용자 이름, 도메인 이름, 서비스 이름(krbtgt) 포함
    • 타임스탬프 암호화 없이 요청을 전송하여 시스템 검증 우회
    KRB-AS-REQ ::= [APPLICATION 10] SEQUENCE {
        pvno[1]               INTEGER,           -- 프로토콜 버전 번호
        msg-type[2]           INTEGER,           -- 메시지 유형(AS-REQ는 10)
        padata[3]             SEQUENCE OF PA-DATA OPTIONAL, -- 사전 인증 데이터
        req-body[4]           KDC-REQ-BODY       -- 요청 본문(사용자명, 서비스명 등)
    }
  4. 암호화 데이터 획득:

    • 도메인 컨트롤러가 AS-REP 응답 메시지 반환
    • AS-REP 메시지에는 세션 키가 사용자 비밀번호 기반 키로 암호화되어 포함
    • 'enc-part' 필드에서 암호화된 데이터 추출
    KRB-AS-REP ::= [APPLICATION 11] SEQUENCE {
        pvno[0]               INTEGER,           -- 프로토콜 버전 번호
        msg-type[1]           INTEGER,           -- 메시지 유형(AS-REP는 11)
        padata[2]             SEQUENCE OF PA-DATA OPTIONAL, -- 추가 인증 데이터
        crealm[3]             Realm,             -- 클라이언트 렘(영역)
        cname[4]              PrincipalName,     -- 클라이언트 이름
        ticket[5]             Ticket,            -- 티켓(TGT) 정보
        enc-part[6]           EncryptedData      # 이 부분이 사용자 암호로 암호화됨
    }
  5. 암호화 데이터 변환:

    • 획득한 암호화 데이터를 Hashcat/John 호환 형식으로 변환
    • 포맷: $krb5asrep$23$사용자명@도메인:암호화된데이터
    • 이 형식은 Kerberos 5 AS-REP 해시 유형(모드 18200)으로 식별
  6. 오프라인 크래킹:

    • 해시 파일을 Hashcat이나 John the Ripper로 로드
    • 사전 공격, 규칙 기반 공격, 무차별 대입 공격 등 다양한 기법 적용
    • 성공 시 계정 암호 획득
    hashcat -m 18200 -a 0 hashes.txt wordlist.txt -r rules/best64.rule
  7. 권한 상승 및 횡적 이동:

    • 획득한 계정 정보로 도메인 내 추가 접근 권한 확보
    • 획득한 계정이 관리자 권한 계정이거나 다른 서버에 접근 가능한 경우 추가 공격 수행

4. 공격 도구 및 구현

4.1 Impacket의 GetNPUsers.py

# 도메인 내 모든 사전 인증 비활성화 계정 검색 및 해시 추출
GetNPUsers.py domain/ -usersfile users.txt -dc-ip 10.0.0.1

# 특정 계정에 대한 AS-REP 해시 요청 및 Hashcat 포맷으로 저장
GetNPUsers.py domain/user:password -request -format hashcat -outputfile hashes.txt

4.2 Rubeus 도구

# 도메인 내 사전 인증 비활성화 계정 검색 및 해시 추출
Rubeus.exe asreproast /format:hashcat /outfile:hashes.txt

4.3 해시 크래킹

# Hashcat을 이용한 크래킹
hashcat -m 18200 hashes.txt wordlist.txt -r rules/best64.rule

5. 특징 및 식별 방법

특징설명
공격 난이도낮음 (특별한 권한 불필요)
탐지 가능성중간 (이벤트 ID 4768 로그 분석 필요)
선행 조건사전 인증이 비활성화된 계정 존재
공격 범위도메인 내 모든 사전 인증 비활성화 계정

6. 방어 대책

6.1 기술적 대응

  • 사전 인증 활성화: 모든 계정에 Kerberos 사전 인증 강제 활성화

    # 단일 사용자에 대한 사전 인증 활성화
    Set-ADAccountControl -Identity user -DoesNotRequirePreAuth $false
    
    # 모든 사전 인증 비활성화된 계정에 대해 일괄 적용
    Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    ForEach-Object {
      Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
      Write-Host "사전 인증 활성화: $($_.Name)"
    }
  • 계정 감사: 사전 인증이 비활성화된 계정 정기적 검사

    # 전체 도메인에서 사전 인증이 비활성화된 계정 검색
    Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth |
    Select-Object SamAccountName, DoesNotRequirePreAuth
    
    # 상세 속성과 함께 출력
    Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties * |
    Select-Object SamAccountName, Enabled, LastLogonDate, whenCreated, DoesNotRequirePreAuth
  • 이벤트 모니터링: 이벤트 ID 4768(TGT 요청) 중 사전 인증 실패 없는 요청 모니터링

    # Windows 이벤트 로그 모니터링 예시
    Get-WinEvent -FilterHashtable @{
      LogName='Security';
      ID=4768;
      Data='0x0'   # 0x0: 사전 인증 옵션 없음
    } | Select-Object TimeCreated, Message
  • 고급 탐지 규칙 구현: SIEM 도구를 통한 AS-REP Roasting 패턴 탐지

    # Sigma 규칙 예시 (YAML)
    title: Potential AS-REP Roasting Attack
    description: Detects TGT requests without pre-authentication
    status: experimental
    author: Security Team
    logsource:
      product: windows
      service: security
    detection:
      selection:
        EventID: 4768
        Status: '0x0'
      condition: selection
    falsepositives:
      - Legitimate service accounts configured without pre-authentication
    level: medium

6.2 정책적 대응

  • 강력한 암호 정책 수립 및 시행

    • 최소 16자 이상의 복잡한 암호 적용
    • 다중 요소 인증(MFA) 구현
    • 서비스 계정용 관리형 서비스 계정(MSA) 사용
  • 계정 권한 최소화 원칙 적용

    • 필요한 최소 권한만 할당하는 최소 권한 원칙 준수
    • 서비스 계정과 일반 사용자 계정 분리
  • 정기적 보안 감사 및 취약점 점검

    • 분기별 Active Directory 구성 감사
    • 사전 인증 비활성화 설정에 대한 정기 점검
    • BloodHound 등 도구를 사용한 보안 평가
  • MITRE ATT&CK 기반 방어 체계 구축

    • T1558.004에 대응하는 특화된 보안 통제 구현
    • 위협 인텔리전스 기반의 선제적 모니터링

7. 실무 적용 시나리오

7.1 공격 시나리오

  1. 공격자가 도메인 내 사전 인증 비활성화 계정 검색
  2. GetNPUsers.py로 해당 계정들의 AS-REP 해시 획득
  3. 오프라인에서 해시 크래킹 수행
  4. 획득한 계정으로 네트워크 내 추가 침투

7.2 방어 시나리오

  1. 보안 감사로 사전 인증 비활성화 계정 식별
  2. 모든 계정에 사전 인증 활성화 적용
  3. SIEM을 통한 AS-REP 요청 패턴 모니터링
  4. 침해 대응 계획에 AS-REP Roasting 탐지 절차 포함

상세 내용: Kerberos 인증 프로토콜과 AS-REP Roasting의 관계

Kerberos 인증 체계와 약어 설명

Kerberos는 네트워크 인증 프로토콜로서 클라이언트와 서버 간 상호 인증을 제공한다. 기본 인증 흐름은 다음과 같다:

  1. AS(Authentication Service, 인증 서비스) 교환:

    • 클라이언트가 KDC에 AS-REQ(Authentication Service Request, 인증 서비스 요청) 메시지 전송
    • KDC는 AS-REP(Authentication Service Reply, 인증 서비스 응답)으로 TGT 제공
  2. TGS(Ticket Granting Service, 티켓 발급 서비스) 교환:

    • 클라이언트가 TGT를 사용하여 TGS-REQ(Ticket Granting Service Request, 티켓 발급 서비스 요청) 메시지 전송
    • KDC는 TGS-REP(Ticket Granting Service Reply, 티켓 발급 서비스 응답)으로 서비스 티켓 제공
  3. AP(Application Server, 응용 서버) 교환:

    • 클라이언트가 서비스 티켓을 사용하여 서버에 접근

AS-REP Roasting은 AS(Authentication Service) 교환 단계의 취약점을 악용하는 것으로, 사전 인증이 비활성화되면 AS-REQ(인증 서비스 요청)에 대한 응답으로 받는 AS-REP(인증 서비스 응답) 메시지 내 암호화된 부분을 공격 대상으로 삼는다.

암호화 측면의 취약점

AS-REP 메시지에는 사용자 비밀번호 기반 키로 암호화된 세션 키가 포함되어 있다. 따라서 이 암호화된 부분을 획득하면 사용자 비밀번호를 크래킹할 수 있는 기회를 얻게 된다. 세부 구조는 다음과 같다:

EncASRepPart ::= [APPLICATION 25] SEQUENCE {
    key [0] EncryptionKey,             # 세션 키
    last-req [1] LastReq,              # 마지막 요청 정보
    nonce [2] UInt32,                  # 요청의 nonce 값
    key-expiration [3] KerberosTime OPTIONAL, # 키 만료 시간
    flags [4] TicketFlags,             # 티켓 플래그
    authtime [5] KerberosTime,         # 인증 시간
    starttime [6] KerberosTime OPTIONAL, # 티켓 유효 시작 시간
    endtime [7] KerberosTime,          # 티켓 만료 시간
    renew-till [8] KerberosTime OPTIONAL, # 갱신 가능 시간
    srealm [9] Realm,                  # 서버 렘(realm)
    sname [10] PrincipalName,          # 서버 이름
    caddr [11] HostAddresses OPTIONAL  # 클라이언트 주소
}

이 구조체가 사용자의 장기 키(비밀번호에서 파생)로 암호화되어 AS-REP의 enc-part 필드에 포함된다. 공격자는 이 암호화된 데이터를 추출하여 오프라인 크래킹을 시도한다.

MITRE ATT&CK에서의 위치와 관련성

AS-REP Roasting(T1558.004)은 더 넓은 범주의 'Steal or Forge Kerberos Tickets'(T1558) 기법의 하위 기법으로, 자격 증명 접근(Credential Access) 전술에 속한다. 이 기법은 다음과 같은 다른 Kerberos 관련 공격 기법과 연관된다:

기법 ID이름연관성
T1558.001Golden Ticket도메인 컨트롤러 침해 후 KRBTGT 계정 해시로 위조된 TGT 생성
T1558.002Silver Ticket서비스 계정 해시로 위조된 서비스 티켓 생성
T1558.003Kerberoasting서비스 계정을 대상으로 한 유사한 공격 기법
T1550.003Pass the Ticket훔친 Kerberos 티켓을 이용한 인증

실제 환경에서의 취약점 발생 원인

  1. 레거시 시스템 호환성:

    • 일부 오래된 시스템이나 서비스는 사전 인증을 지원하지 않아 호환성을 위해 비활성화
    • 특히 서드파티 애플리케이션이 Kerberos와 통합될 때 발생
  2. 잘못된 구성:

    • 관리자의 실수로 사전 인증이 비활성화됨
    • 임시 테스트 계정을 생성할 때 기본 보안 설정 무시
  3. 서비스 계정 특성:

    • 일부 서비스 계정은 특수한 인증 요구사항으로 인해 사전 인증을 비활성화
    • Exchange 서버, SQL 서버 등의 특정 서비스 통합 과정에서 발생

어린이 버전 요약

Kerberos AS-REP Roasting은 컴퓨터에 들어갈 때 사용하는 특별한 열쇠(비밀번호)를 찾아내는 방법이에요. 보통은 컴퓨터가 누가 들어오려는지 확인하는 과정이 있는데, 이 확인 과정이 없는 특별한 계정들이 있어요. 그런 계정들은 컴퓨터에 들어갈 때 사용하는 암호화된 메시지를 받을 수 있고, 그 메시지를 가지고 비밀번호를 알아낼 수 있답니다. 이건 마치 문을 열기 전에 확인 없이 바로 열쇠를 주는 것과 같아서, 그 열쇠를 복사해서 나중에 문을 열 수 있게 되는 거예요!

약어 정리표

줄임말풀네임의미
AS-REQAuthentication Service Request인증 요청
AS-REPAuthentication Service Reply인증 요청에 대한 응답 (TGT 전달)
TGS-REQTicket Granting Service Request서비스 티켓 요청
TGS-REPTicket Granting Service Reply서비스 티켓 발급 응답
AP-REQApplication Request서비스 접근 요청
AP-REPApplication Reply서비스 접근 응답

참고: Kerberos 프로토콜 공식 문서 RFC 4120에 따르면, REP는 'Response'가 아닌 'Reply'의 약자로 사용됩니다.

profile
DevSecOps ⚙️ + CTF🚩

0개의 댓글