Kerberoasting을 통한 서비스 계정 비밀번호 추출

우리의 LDAP 정찰 게시물에서 공격자가 Windows Active Directory (AD) 도메인에서 표적으로 삼을 서비스 계정을 찾아내기 위해 정찰을 수행하는 방법을 살펴보았습니다. 이제 공격자가 그러한 계정을 손상시키고 해당 계정의 권한을 악용하는 데 사용할 수 있는 한 가지 방법인 Kerberoasting을 알아보겠습니다. 이 기법은 도메인에서 관리자 권한이 필요 없고, 수행이 매우 쉽고, 사실상 탐지가 거의 불가능하다는 점에서 특히 무섭습니다.

Kerberoasting: 개요

Kerberoasting는 Kerberos 프로토콜의 기능을 악용해 Active Directory 사용자 계정의 비밀번호 해시를 수집하는 공격입니다. 인증된 도메인 사용자는 계정의 Service Principal Name(SPN)을 지정하여 해당 계정에 대한 서비스 티켓을 요청할 수 있으며, 도메인 컨트롤러의 티켓 부여 서비스(TGS)는 계정 비밀번호의 NTLM 해시를 사용해 암호화된 티켓을 반환합니다.

따라서 공격자가 LDAP reconnaissance 같은 전술로 서비스 계정의 SPN을 알아낸 다음에는, 해당 계정들에 대한 티켓을 모두 수집할 수 있습니다. 그 데이터를 오프라인으로 가져가면, 각 서비스 계정의 평문 비밀번호를 해독하기 위해 무차별 대입(브루트 포스) 공격을 수행할 수 있으며—탐지되거나 계정이 잠길 위험이 0입니다.

공격자가 도메인에 액세스하고 티켓을 수집한 뒤 비밀번호 해독(크래킹) 절차를 시작하는 데는 불과 몇 분이면 충분합니다. 그다음에는 한두 개 이상의 서비스 계정을 손상시키기까지 기다리기만 하면 됩니다. 손상된 서비스 계정을 이용해 민감한 데이터를 훔치거나 암호화하거나, 다른 형태의 피해를 가할 수 있습니다.

공격자는 여러 가지 이유로 서비스 계정을 집중적으로 노립니다. 먼저, 이러한 계정은 다른 AD 사용자 계정보다 훨씬 더 광범위한 권한을 갖는 경우가 많아서 이를 손상시키면 공격자가 더 많은 접근 권한을 얻게 됩니다. 또한 서비스 계정 비밀번호는 거의 변경되지 않으므로 공격자는 오랫동안 접근 권한을 유지할 가능성이 큽니다. Kerberoasting을 사용해 얻을 수 있는 접근 유형을 이해하려면 Sean Metcalf가 유지 관리하는 Active Directory SPNs 목록을 확인하세요.

Kerberoasting: 작동 방식

1단계. 서비스 계정의 SPN을 확보합니다.

. 이러한 SPN을 얻는 방법은 여러 가지가 있으며, 예를 들어:

• PowerShell 쿼리와 LDAP 정찰
• PowerShell용 Active Directory 모듈
• Kerberoast 도구 키트
• PowerSploit

2단계. 서비스 계정 SPN에 대해 서비스 티켓을 요청합니다.

PowerShell 몇 줄만 실행하면 서비스 티켓이 반환되어 시스템 메모리에 저장됩니다.

      Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘MSSQLSvc/jefflab-sql02.jefflab.local:1433’
      

3단계. Mimikatz를 사용해 서비스 티켓을 추출합니다.

Mimikatz는 로컬 티켓을 추출하고 오프라인 크래킹을 위해 디스크에 저장합니다. Mimikatz를 설치한 다음, 단 한 번의 명령을 실행하면 됩니다:

4단계. 티켓을 크랙합니다.

Kerberos 티켓은 티켓 요청에 지정된 SPN과 연결된 서비스 계정의 비밀번호로 암호화됩니다. Kerberoasting 도구는 티켓을 크랙하고 비밀번호 해시 사전(딕셔너리)을 대입해 해당 티켓의 평문 비밀번호를 제공하는 Python 스크립트를 제공합니다. 스크립트를 실행하는 데 필요한 환경이 갖춰져 있는지 확인하기 위해 약간의 설정이 필요할 수 있지만, 이 블로그에서 해당 세부 정보를 다룹니다.

또 다른 방법으로는 GetUserSPNs 스크립트를 사용해 Kerberos 티켓을 수집한 뒤, Hashcat 비밀번호 복구 도구로 크랙할 수도 있습니다.

Kerberoasting 공격으로부터 보호하기

Kerberoasting 공격에 대한 주요 대응책은 모든 서비스 계정이 크랙하기 어려운 길고 복잡한 비밀번호를 사용하도록 하고, 비밀번호를 크랙할 수 있게 된 공격자가 해당 계정을 사용할 수 있는 시간을 최소화하기 위해 이를 정기적으로 회전(교체)하는 것입니다. group managed service accounts 는 자동으로 회전할 수 있는 무작위의 복잡한 비밀번호를 할당하기 위한 모범 사례입니다.

공격자는 티켓을 오프라인에서 크랙하기 때문에, 해당 과정에서는 네트워크 트래픽이 발생하지 않아 그 부분의 공격은 탐지할 수 없습니다. 하지만 보안 솔루션을 통해 Active Directory를 모니터링하면 공격의 초기 단계는 포착할 수 있습니다. solid security solution 특히 서비스 계정은 일반적으로 동일한 방식으로 동일한 시스템에서 사용되므로, 비정상적인 인증 요청을 감지하는지 확인하세요. 또한 서비스 티켓 요청이 급증하는지 모니터링하십시오.

마지막으로 보안 전문가들은 RC4 기반 암호화를 비활성화할 것도 권장합니다. 그렇지 않으면 사용자의 계정이 AES 암호화를 지원하더라도 공격자가 RC4로 암호화된 티켓을 요청할 수 있으며, 이는 AES 암호화를 사용해 생성된 티켓보다 더 쉽게 크랙됩니다.

Kerberoasting은 표준 도메인 계정을 가진 공격자가 서비스 계정에 대한 암호화된 티켓을 요청한 후, 잠금 정책이 적용되지 않고 도메인 컨트롤러가 관여하지 않는 오프라인 상태에서 비밀번호를 크랙할 수 있게 합니다.

Kerberoasting이란 무엇인가요?

보호가 약한 계정을 대상으로 성공하며, 76%의 조직이 서비스 계정을 포함한 비인간 아이덴티티를 완전히 관리하거나 모니터링하지 않는다고 Netwrix 2026 Data and Identity Security Report에 따르면 밝혀졌습니다.

공격은 공격자가 LDAP reconnaissance를 통해 구축할 수 있는 해당 계정 목록으로 시작됩니다.

Kerberoasting는 일반적인 Kerberos 기능을 암호 해독 기회로 바꾸는 Active Directory(AD) 공격입니다. Kerberos는 인증된 사용자가 도메인 컨트롤러에 서비스 티켓을 요청할 수 있게 하며, 티켓은 서비스 계정 비밀번호에서 파생된 키로 암호화됩니다.

공격자가 Kerberoasting으로 서비스 계정 비밀번호를 추출하는 방법

추출은 네 단계로 진행되며, Rubeus와 Impacket의 GetUserSPNs.py가 처음 세 단계를 하나의 명령어로 결합하고 Hashcat이 네 번째 단계를 처리합니다.

1. SPN이 있는 계정을 찾으세요

2. SPN에 대한 서비스 티켓을 요청합니다

이 티켓을 수집한 공격자는 하나가 복호화될 때까지 오프라인에서 비밀번호를 추측할 수 있습니다. 대상은 service principal names (SPNs)가 포함된 사용자 계정이며 대부분의 service accounts입니다. 이 공격은 시작하는 데 권한 상승이 필요하지 않습니다.

도메인 계정이 있는 공격자는 LDAP 쿼리, PowerShell 쿼리 또는 Active Directory 모듈을 통해 SPN이 있는 계정을 나열할 수 있습니다. Rubeus와 GetUserSPNs.py는 자체적으로 kerberoastable 계정을 열거하며, Rubeus는 티켓 요청 없이도 해당 계정에 대한 통계를 보고할 수 있습니다.

SPN은 다음과 같이 세 부분으로 서비스 인스턴스의 이름을 지정합니다 MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand으로, 서비스 클래스, 호스트 및 포트를 나타냅니다. 서비스 클래스는 MSSQLSvc의 데이터베이스 액세스와 같이 탈취된 계정이 접근할 수 있는 범위를 암시합니다.

PowerShell 두 줄이 명명된 SPN에 대한 티켓을 요청하고 Windows가 메모리에 저장합니다.

Rubeus 모든 kerberoastable 계정에 대한 요청을 자동화하고 결과를 파일에 쓸 수 있습니다.

Kerberos는 신원을 증명하고 권한 부여는 서비스에 맡깁니다 (RFC 4120), 따라서 도메인 컨트롤러는 티켓을 발급하기 전에 요청자가 서비스를 사용할 수 있는지 확인하지 않습니다. 따라서 인증된 모든 사용자는 서비스 계정 비밀번호에서 파생된 키로 암호화된 티켓을 받습니다.

3. 서비스 티켓 추출

Impacket's GetUserSPNs.py는 -request 옵션으로 동일한 작업을 수행하며, 이 옵션은 John the Ripper와 Hashcat이 인식하는 형식으로 티켓을 출력합니다.

Kerberos 사전 인증이 비활성화된 계정이 존재할 때, Rubeus의 /nopreauth 옵션은 AS-REQ(인증 서비스 요청) 메시지를 해당 계정을 통해 전송하여 서비스 티켓을 요청합니다.

4. 티켓을 해독하세요

위 PowerShell 명령어로 요청된 티켓은 공격자가 내보낼 때까지 메모리에 남아 있습니다. Mimikatz는 현재 세션의 티켓을 나열하고 단일 명령으로 오프라인 크래킹을 위해 파일에 기록합니다.

Rubeus와 GetUserSPNs.py는 -request 옵션을 사용하면 이 단계를 건너뛰는데, 이는 직접 크랙 가능한 해시를 출력하기 때문입니다.

티켓 암호화 유형이 중요한 이유

크래킹은 공격자의 하드웨어에서 실행되므로 잠금 정책이 적용되지 않으며, 도메인 컨트롤러는 티켓 요청 후 아무 것도 보지 못합니다. Hashcat은 각 티켓에 대해 비밀번호 추측을 테스트하고 추측이 복호화되면 평문 비밀번호를 복구합니다. GetUserSPNs.py가 출력하는 형식을 지원하며, 각 암호화 유형마다 별도의 모드를 가지고 있습니다.

Netwrix Threat Prevention은 Active Directory에서 DCSync, Kerberoasting 및 Pass-the-Hash 공격을 실시간으로 차단합니다. 데모를 요청하세요.

RC4 티켓이 가장 빨리 해독됩니다

티켓의 암호화 유형인 RC4(Rivest Cipher 4) 또는 AES(Advanced Encryption Standard)는 공격자가 얼마나 빨리 추측할 수 있는지를 결정하며, Microsoft는 2026년에 기본 설정을 변경했습니다.

공격자는 AES를 지원하는 계정에 대해 RC4를 요청할 수 있습니다

AES 티켓은 추측을 늦추지만 여전히 약한 비밀번호에는 취약합니다

RC4 티켓의 키는 계정의 NT LAN Manager (NTLM) 해시로, 비솔트된 비밀번호 해시입니다 (RFC 4757). 솔트가 없으면 동일한 비밀번호가 모든 계정에 대해 동일한 키를 생성하며, 각 추측은 해시 계산 한 번의 비용이 듭니다.

Rubeus는 기본적으로 각 계정의 최고 지원 암호화 유형을 요청하지만, /usetgtdeleg 옵션은 AES를 지원하는 계정에 대해 RC4 티켓을 요청하며, /rc4opsec 옵션은 AES 활성화 계정을 건너뜁니다.

Impacket의 GetUserSPNs.py는 -no-rc4가 설정되지 않은 한 기본적으로 RC4를 요청합니다. 서비스 계정의 지원 암호화 유형에서 RC4를 제거하면 해당 다운그레이드 경로가 차단됩니다.

세 가지 유형 모두 해독 가능하므로 비밀번호 길이와 무작위성이 결과를 결정합니다.

2026년 4월 업데이트로 도메인 컨트롤러 기본값이 변경되었습니다

Kerberoasting으로부터 서비스 계정 보호

AES 키는 기본적으로 4,096회 반복되는 솔티드 키 파생에서 생성됩니다 (RFC 3962), 각 추측을 더 비용이 많이 들게 만듭니다. Rubeus의 /aes 옵션은 AES가 활성화된 계정을 대상으로 하며 해당 AES 티켓을 요청하고, Hashcat은 각 티켓 암호화 유형에 대해 별도의 모드를 제공합니다.

이 변경은 해당 속성을 통해 RC4를 명시적으로 허용하는 계정에는 영향을 미치지 않으며, 명시적으로 설정된 도메인 기본값은 작성된 대로 존중됩니다. 해당 계정들은 여전히 RC4 티켓을 받을 수 있으므로 먼저 찾아야 할 대상입니다.

Microsoft의 업데이트 KB5073381은 2026년 1월에 감사 이벤트로 시작되었습니다. 2026년 4월 14일, 도메인 컨트롤러 기본값이 변경되어 명시적인 msDS-SupportedEncryptionTypes 값이 없는 계정은 AES-SHA1만 지원하는 것으로 간주되며, 2026년 7월 이후에 출시된 업데이트는 관리자가 변경을 되돌릴 수 있었던 레지스트리 값을 더 이상 지원하지 않습니다.

각 제어는 공격의 다른 부분을 제한하며 모두 Active Directory 및 Windows의 기본 기능을 사용합니다.

서비스 계정을 관리 계정으로 이동

나머지에 긴 무작위 비밀번호를 설정하세요

비밀번호 재설정 및 AES 적용

Netwrix의 BadSuccessor 공격은 dMSA를 이용한 권한 상승 공격으로, 배포 전에 조직 단위에 대해 CreateChild, WriteProperty, WriteDACL, GenericAll, WriteOwner 권한을 가진 사용자를 감사할 것을 권장합니다.

그룹 관리 서비스 계정(gMSAs)는 Active Directory가 주기적으로 변경하는 120자 무작위 비밀번호를 사용하므로 공격자가 추측할 약한 점이 없습니다. 위임된 관리 서비스 계정(dMSAs)도 Active Directory가 자격 증명을 관리합니다.

이동할 수 없는 계정의 경우, MITRE ATT&CK는 이상적으로 25자 이상의 비밀번호를 권장합니다. 무작위 생성은 길이만큼 중요하며, 크래킹 워드리스트는 사람들이 선택한 비밀번호로 만들어집니다.

AES 키는 비밀번호가 설정되거나 변경될 때 생성되므로, AES 지원 이전에 설정된 비밀번호를 가진 계정은 재설정될 때까지 키가 없으며, AES 전용 계정은 키가 없으면 티켓을 받을 수 없습니다.

계정에 필요하지 않은 SPN 제거

제한하기 전에 각 서비스를 테스트하세요. AES를 지원하지 않는 서비스는 일부 비-Windows 장치를 포함해 RC4가 제거되면 인증이 중단됩니다.

먼저 비밀번호를 재설정한 후 계정의 msDS-SupportedEncryptionTypes 속성에서 명시적인 RC4 설정을 확인하고 AES128 및 AES256(값 24)으로 제한하세요.

사용자 계정의 모든 SPN은 해당 계정을 요청할 수 있게 하므로, 모두 나열하고 실행 중인 서비스와 각각 비교하세요.

SPN을 추가할 수 있는 사람을 제어하세요

서비스 계정 권한 제한

서비스 티켓 요청 기록

krbtgt 계정은 의도적으로 결과에 나타나며 변경해서는 안 됩니다. 폐기된 호스트나 사용 중단된 애플리케이션을 가리키는 다른 SPN의 경우, 다음으로 확인하십시오 setspn -L <account>Expand 그리고 다음으로 삭제하십시오 setspn -D <SPN> <account>Expand.

타겟형 Kerberoasting에서는 targeted Kerberoasting 권한(GenericAll, GenericWrite, WriteProperty 또는 Validated Write to Service Principal Name)을 가진 공격자가 계정에 SPN을 추가하여 해당 계정을 공격 가능하게 만듭니다. 서비스 계정의 접근 제어 목록을 검토하고 계정을 관리하지 않는 사용자로부터 해당 권한을 제거하세요. 일반적으로 내장된 Account Operators 그룹의 구성원이 이 권한을 보유합니다.

도메인 컨트롤러에서 Audit Kerberos Service Ticket Operations 하위 범주를 활성화하면 각 요청이 이벤트 ID 4769로 기록됩니다. MITRE는 Ticket Encryption Type 0x17로 표시되는 RC4를 사용하는 이상 요청을 주시할 것을 권고하며, AES 티켓은 0x11 또는 0x12로 표시됩니다.

사전 인증 없이 계정을 통해 로스팅하면 대신 AS-REQ 메시지가 전송되므로 해당 요청은 이벤트 ID 4768로 기록되며 동일한 RC4 검사가 적용됩니다.

해킹된 비밀번호는 공격자에게 계정이 할 수 있는 모든 권한을 부여합니다. Domain Admins와 같은 특권 그룹에서 서비스 계정을 제거하고, 최소 권한 원칙에 따라 서비스가 사용하는 권한만 부여하세요.최소 권한. 이 작업은 더 광범위한 Active Directory 보안 강화에 속합니다.

Microsoft의 Kerberos-Crypto 저장소에는 두 이벤트 유형을 모두 읽는 Get-KerbEncryptionUsage.ps1 스크립트가 포함되어 있으며, -Encryption RC4 및 -SearchScope AllKdcs 옵션으로 실행하면 모든 도메인 컨트롤러에서 RC4 요청을 나열합니다.

Netwrix가 Kerberoasting 방어에 어떻게 도움이 되는지

실시간으로 Kerberoasting 시도를 차단하세요

Netwrix 제품은 기본 Windows 설정을 넘어 세 가지 제어 기능을 추가합니다: 공격 차단, 후속 조치 탐지, 그리고 Active Directory가 악용하는 취약점 평가.

신원 기반 공격 탐지

Netwrix Threat Prevention는 Kerberoasting, DCSync 및 Pass-the-Hash 시도를 Active Directory에 대해 성공하기 전에 차단합니다. 이는 로그 검토로는 제공할 수 없는 공격 시점의 집행 지점을 팀에 제공합니다.

Active Directory 보안 상태 평가

여전히 RC4를 허용하는 계정부터 시작하세요

Netwrix Threat Manager는 자격 증명 도용, 측면 이동 및 권한 상승을 식별합니다. 이는 손상된 서비스 계정 암호 이후 발생할 수 있는 ID 기반 공격입니다. 또한 권한 있는 계정에 SPN이 추가될 때, 타깃 Kerberoasting 설정 단계를 감지합니다.

Kerberoasting은 약한 서비스 계정 암호 하나만 필요하므로 방어는 계정별로 순차적으로 적용하는 것이 가장 효과적입니다.

Netwrix PingCastle는 Active Directory 보안을 평가하고 잘못된 구성, 공격 경로 및 권한 노출을 식별합니다.

관리되는 계정으로 전환할 수 없는 계정은 오프라인 추측 공격을 견디기 위해 길고 무작위인 비밀번호가 필요합니다. 티켓 요청은 방어자가 여전히 관찰할 수 있는 유일한 단계이므로, 이를 기록하는 것은 비밀번호 위생으로는 커버할 수 없는 부분을 보완합니다.

2026년 4월 Microsoft 기본 설정 변경 이후, 계정 또는 명시적으로 설정된 도메인 기본값에서 RC4를 명시적으로 허용하는 계정은 여전히 RC4 티켓을 받을 수 있으므로 우선 처리됩니다. 이동할 수 있는 것은 관리되는 계정으로 옮기고, 나머지는 재설정한 후 AES로 제한하세요.

데모 요청하여 Netwrix Threat Prevention이 Active Directory 서비스 계정에 대한 Kerberoasting 시도를 성공하기 전에 차단하는 방법을 확인하세요.