▌ TRANSMISSION · [CONCEPT]

Kerberos

2026-05-23 · principal · realm · key distribution center · authentication service · ticket granting service · ticket granting ticket · service ticket · long-term key · session key · service principal name

Kerberos V5

0. Kerberos는 왜 존재하는가?

회사 내부에 여러 서비스가 있다고 해보자.

파일 서버
메일 서버
웹 서버
DB 서버
WinRM 서버

사용자가 매번 서비스에 접속할 때마다 비밀번호를 직접 보내면, 서비스 서버마다 사용자의 비밀번호가 노출될 수 있다. 이 문제를 해결하기 위한 Kerberos의 핵심 아이디어는 다음과 같다.

비밀번호를 서비스마다 직접 보내지 말고, 도메인 컨트롤러에게 티켓을 받아서 서비스에 보여주자!

AD에서 DC는 Kerberos의 KDC(Key Distribution Center) 역할을 한다.

KDC : 도메인 안에서 티켓을 발급해주는 기관
Kerberos(프로토콜) 서비스 포트는 TCP/UDP 88

KDC (Key Distribution Center)

KDC라는 서버는 2개의 서비스로 나누어져있다.

AS (Authentication Service)
- 초기 인증을 처리하며, TGT 발급을 담당한다.
TGS (Ticket Granting Service)
- TGT 검증 및 ST(Service Ticket) 발급을 담당한다.

`krbtgt` 계정

KDC는 자신이 발급한 TGT를 나중에 검증할 수 있어야 한다.

그래서 TGT를 “KDC만 아는 키”로 암호화해서 발급한다.

사용자가 나중에 들고 오면 그 키로 복호화를 시도하여 성공/실패로 정상/비정상을 결정한다.

TGT 안에는 비밀번호가 들어가 있는 것이 아니라, KDC만 알고 있는 키가 들어가 있는 것이다.

문제는 그 “KDC만 아는 키”를 어디에 저장하느냐다.

Microsoft는 이걸 위해 별도 저장소를 만드는 대신, 가짜 계정 하나를 만들고 그 계정의 비밀번호에서 파생된 키를 사용하기로 했다.

(AD가 이미 계정 비밀번호 저장·복제 시스템을 잘 갖춰놨으니 그걸 재활용한 셈이다.)

그 가짜 계정이 바로 krbtgt다.

즉, krbtgt는 사람이 쓰는 계정이 아니라 KDC의 마스터 키를 담아두기 위한 보관함일 뿐이다.

만약 이 계정의 키가 유출되면, 공격자가 직접 TGT를 만들어 “나는 Domain Admin이다”라고 적어넣은 뒤 krbtgt 키로 암호화해서 KDC에 들고 갈 수 있다.
KDC는 자기 키로 복호화가 되니 정상 티켓으로 받아들이게 될 것이다.
이것을 Golden Ticket 공격이라고 하고, 도메인 점령으로 이어진다.

정리

항목	내용
계정 이름	`krbtgt`
생성 시점	도메인 만들 때 자동 생성
로그인 가능 여부	불가능 (Disabled)
비밀번호	랜덤 (사람이 쓸 일 없음)
실제 용도	비밀번호에서 파생된 키를 KDC가 TGT 암호화에 사용

TGT (Ticket Granting Ticket)

도메인에 로그인한 정상 사용자임을 증명하는 티켓
KDC가 자신의 krbtgt 키로 암호화해서 발급
따라서 클라이언트는 TGT 내부를 못 보고, KDC만 검증 가능

사용자 → KDC: 나 m0nk3ygod.king 인데 비밀번호 맞지?
KDC → 사용자: 맞네. 여기 TGT 줄게!

TGS와 Service Ticket (ST)

이 부분에서 용어가 조금 헷갈릴 수 있는데 정리하면,

TGS (Ticket Granting Service) : KDC 안에서 서비스 티켓을 발급해주는 서비스
Service Ticket (ST) : TGS가 발급한 티켓 자체

흔히 “TGS”라는 단어 하나로 둘 다 부르긴 하지만, 엄밀히는 TGS는 발급해주는 쪽이고 결과물은 Service Ticket이다.

(이 글에서도 편의상 “TGS 티켓”이라고 쓰는 부분이 나오는데, 정확히는 “Service Ticket”으로 이해하면 된다.)

1. 사용자 → KDC: 파일 서버에 접근할 티켓 주세요.
2. KDC → 사용자: 여기 파일 서버용 티켓(ST) 줄게.
3. 사용자 → 파일 서버: 이 티켓으로 들어갈게요.

그러면 KDC는 “어떤 서비스”인지 어떻게 구분할까? (SPN)

그건 바로 SPN(Service Principal Name) !!

KDC에게 이렇게 말한다고 해보자.

웹 서버 티켓 주세요.

KDC 입장에서는 헷갈린다.

어떤 웹 서버?
어떤 호스트?
그 서비스는 어떤 계정으로 실행 중이지?

그래서 Kerberos에서는 서비스를 식별하는 이름이 필요하다.

SPN (Service Principal Name)

형태는 보통 다음과 같이 생겼다.

서비스종류/서버이름

또는

서비스클래스/호스트:포트/서비스이름

예)

HTTP/web01.voleur.htb            (웹)
MSSQLSvc/sql01.voleur.htb:1433   (MSSQL)
CIFS/dc.voleur.htb               (SMB 파일 공유)
WSMAN/server01.voleur.htb        (WinRM)
LDAP/dc.voleur.htb               (LDAP)

SPN은 AD 객체의 속성으로 저장된다.

특히 서비스 계정에 저장되는 경우가 많다.

서비스 계정이란?
- 사람이 로그인하려고 만든 계정이라기보다, 서비스가 실행될 때 사용하는 계정이다.

IIS 웹 서비스 → svc_iis 계정으로 실행
LDAP 관련 서비스 → svc_ldap 계정으로 실행
WinRM 관련 서비스 → svc_winrm 계정으로 실행
SQL 서버 → svc_sql 계정으로 실행

(이렇게 하는 이유는 서비스마다 필요한 권한을 따로 줄 수 있기 때문이다.)

예를 들어 svc_iis라는 계정이 웹 서비스를 실행한다고 해보자. AD에는 다음과 같이 들어갈 수 있다.

계정: svc_iis
SPN: HTTP/web01.voleur.htb

1. Kerberoasting

Kerberoasting : 서비스 계정의 TGS를 받아내서, 그 안에 들어있는 서비스 계정 키 암호화 부분을 오프라인으로 크랙하여 비밀번호를 알아내는 공격

Service Ticket이 크랙 대상이 되는 이유

KDC가 어떤 서비스용 티켓, 즉 Service Ticket(ST)을 만들 때, 그 티켓의 일부는 서비스 계정의 비밀번호에서 나온 키로 암호화된다.

예를 들자면,

svc_iis 계정 비밀번호 → 암호화 키 생성
KDC가 HTTP/web01.voleur.htb용 ST 생성
ST 일부를 svc_iis 키로 암호화

이렇게 하는 이유는, 실제 서비스가 이 티켓을 검증해야 하기 때문이다. (kbrtgt 같은 느낌)

서비스는 자신의 계정 비밀번호에서 파생된 키를 알고 있다. 그래서 사용자가 티켓을 가져오면,

웹 서비스: 이 티켓이 내 계정 키로 복호화되나?
복호화 됨 → 정상 티켓
복호화 안 됨 → 가짜 티켓

이런 식으로 확인이 가능하다.

여기서 중요한 점이 나오는데,

티켓 안에 비밀번호가 그대로 들어가있는 것은 아니다.
하지만, 티켓 일부가 서비스 계정 비밀번호 기반 키로 암호화가 되어있다는 점이다.

그래서 공격자는 이 암호화된 티켓을 가져와서 오프라인 크랙을 시도하게 된다.

왜 아무 도메인 사용자(TGT가 있는)가 Kerberoasting이 가능한가?

AD에서는 정상 도메인 사용자가 서비스에 접근하기 위해 ST를 요청하는 것이 정상 행위이다.

즉, KDC 입장에서는 “ST 달라”는 요청 자체를 의심할 이유가 없다.

사용자가 실제로 그 서비스에 접속할지 안 할지는 KDC가 알 바가 아니다.

→ 결과적으로 유효한 도메인 자격증명만 있으면, 도메인 내의 SPN이 걸린 모든 계정에 대해 ST를 받을 수 있고, 그걸 오프라인에서 크랙할 수 있다.

Kerberoasting 조건

SPN이 등록된 계정만 Kerberoasting 대상이 된다.

(SPN이 없으면 KDC가 그 계정에 대한 ST를 만들 수가 없으니 당연한 이야기이다.)

WriteSPN

대상 계정 SPN 속성의 값을 쓸 수 있는 권한

WriteSPN 권한이 있다는 것은 대상 계정의 Service Principal Name 속성을 수정할 수 있다는 이야기이다.

예를 들어 다음과 같은 관계가 나왔다고 하자.

SVC_LDAP --WriteSPN--> SVC_WINRM

그러면 svc_ldap 권한으로 svc_winrm에 이런 SPN을 추가해볼 수 있다.

fake/svcwinrm

이러면 svc_winrm은 SPN이 등록된 계정이 된다.

Targeted Kerberoasting

WriteSPN이 위험한 이유

원래 svc_winrm에 SPN이 없었다고 해보자.

svc_winrm
SPN 없음
→ Kerberoasting 대상 아님

그런데 svc_winrm에 대해 WriteSPN 권한으로 임의 SPN을 추가하면,

svc_winrm
SPN 있음
→ Kerberoasting 대상이 됨

그러면 KDC한테 다음과 같이 요청이 가능해진다.

fake/svcwinrm 서비스 티켓 주세요.

그러면 내부적으로는 다음과 같이 처리된다.

fake/svcwinrm SPN은 svc_winrm 계정에 등록되어 있네.
그럼 svc_winrm 계정 키(패스워드에서 파생된 키)로 암호화된 ST를 발급해야겠다.

공격자는 그 티켓을 받아서 크랙하게 된다.

일반 Kerberoasting vs Targeted Kerberoasting

일반

이미 SPN이 있는 계정을 찾음
→ 그 계정에 대한 ST 요청
→ 크랙

ex)
svc_iis 계정에 HTTP/web01 SPN이 이미 있음
→ svc_iis ST 요청
→ svc_iis 비밀번호 크랙 시도

Targeted

원래 SPN이 없던 계정에 SPN을 추가함
→ 그 계정에 대한 ST 요청
→ 크랙
→ SPN 제거 (흔적 지우기)

ex)
SVC_LDAP --WriteSPN--> SVC_WINRM

svc_ldap 권한으로 svc_winrm에 SPN 추가
→ svc_winrm ST 요청
→ svc_winrm 비밀번호 크랙 시도

2. AS-REP Roasting

Kerberoasting의 형제 격인 공격이다. 잠깐 짚고 가자.

AS-REP (AS Exchange의 응답 메시지)
Roasting (오프라인 크래킹. Kerberoasting에서 유래한 표현)
- 사전인증이 비활성화된 계정의 AS-REP을 받아내서, 그 안의 사용자 키 암호화 부분을 오프라인으로 크랙해 비밀번호를 알아내는 공격

원래 정상적인 AD 환경에서는 AS-REQ(=TGT 요청)를 보낼 때 사전인증(pre-authentication) 데이터를 같이 보내야 한다.

사용자 → KDC: TGT 줘. (PA-ENC-TIMESTAMP = 현재시간을 내 비밀번호 키로 암호화)

KDC: 어디 보자... 그 키로 복호화되네. 비밀번호 알고 있구나. 통과.

KDC → 사용자: TGT 줄게.

잠깐 ‘내 비밀번호 키’에 대해 이야기하자면,,,

Long-term Key : 사용자의 비밀번호나 서비스 계정 비밀값에서 파생되어, kerberos에서 티켓을 암호화, 복호화하거나 신원을 증명할 때 장기간 사용되는 암호키 이다.

이건 어떻게 만들어지냐…

현재 윈도우 클라이언트는 기본적으로 AES256을 선호하기에, 일단 AES256 + 표준 솔트로 PA-ENC-TIMESTAMP를 만들어 보낸다.
KDC가 알려주는 경로 (PA-ETYPE-INFO2)를 이용한다. (KDC가 어떤걸 사용해서 키를 만들어야하는지 알려줌)
etype 목록을 알려준다.
etype의 키를 미리 다 만들어둔다.

KDC가 사용하는 방식과 동일해야, KDC가 사용자 키를 받았을 떄 복호화를 진행할 수 있고, 인증이 가능해진다.

(다시 AS-REP Roasting으로 돌아와서…)

이 사전인증이 있어야 KDC는 “비밀번호 안다는 증거를 제출했네”를 확인할 수 있다.

그런데 AD의 사용자 옵션 중 “Do not require Kerberos preauthentication” (플래그: UF_DONT_REQ_PREAUTH)이 체크된 계정있을 수 있다.

이 계정에 대해서는,

공격자 → KDC: 그 사용자 TGT 줘. (사전인증 안 보냄)

KDC → 공격자: 어, 너 사전인증 패스 가능한 계정이네. 자, TGT.

로 처리한다.

하지만, KDC가 응답으로 보내는 AS-REP의 일부는 그 사용자의 비밀번호 키로 암호화되어 있다.

즉, Kerberoasting과 똑같은 방식으로 오프라인 크랙이 가능해진다.

요약하자면,

Kerberoasting은 “서비스 계정 비밀번호” 크랙 — 입장권은 도메인 사용자 필요
AS-REP Roasting은 “일반 사용자 비밀번호” 크랙 — 티켓 없이도 가능 (사용자 이름만 알면 됨)

조건은 단순하다.

DONT_REQ_PREAUTH 플래그가 켜진 계정이 존재하기만 하면 된다.

3. Kerberos에서 쓰는 암호화 타입(etype)

etype	알고리즘	hashcat 모드 (TGS-REP)	크래킹 속도 (RTX 4090 기준 대략)
23 (0x17)	RC4-HMAC (NTLM)	13100	~수십억 h/s
17	AES128-CTS-HMAC-SHA1-96	19600	~수십만 h/s
18	AES256-CTS-HMAC-SHA1-96	19700	~수십만 h/s

AS-REP Roasting은 hashcat 모드가 다르다. (etype 23 → 18200)

이 표를 알아두면 좋은 점은, 크랙 가능성 및 가치를 판단할 수 있다는 점이다.

hashcat 사용 예시

# Kerberoasting RC4 해시
hashcat -m 13100 hashes.txt wordlist.txt

# Kerberoasting AES256 해시
hashcat -m 19700 hashes.txt wordlist.txt

# AS-REP Roasting RC4 해시
hashcat -m 18200 hashes.txt wordlist.txt

etype은 누가 결정하는가?

TGS 발급 시 KDC는 다음 우선순위로 결정한다.

서비스 계정의 msDS-SupportedEncryptionTypes 속성 (해당 계정이 어떤 etype을 지원하는지)
클라이언트가 TGS-REQ에 명시한 지원 etype 목록
두 집합의 교집합 중 가장 강한 것

기본값으로 많은 서비스 계정이 RC4를 “지원”하도록 설정돼 있다.
그래서 공격자가 TGS-REQ에서 “나는 RC4만 지원해”라고 거짓 선언하면, KDC는 친절하게 RC4 티켓을 발급해준다.
이것을 etype downgrade라고 하며, 사실상 모든 Kerberoasting 도구가 기본 동작으로 RC4를 요청한다.

이걸 막는 방법은 msDS-SupportedEncryptionTypes 속성에서 RC4를 제거하면 된다.

그러면 클라이언트가 RC4를 요청해도 KDC가 “그 계정은 RC4 지원 안 함” 하고 AES로만 발급하거나, 또는 거부하게 된다.

4. Kerberos V5 프로토콜 정리 (공식자료)

Kerberos는 IETF RFC 4120(2005) 에 정의된 네트워크 인증 프로토콜이다.

개방된(unprotected) 네트워크에서 principal(워크스테이션 사용자나 네트워크 서버 등)의 신원을 검증하는 수단을 제공하며, 호스트 OS의 단언이나 호스트 주소에 대한 신뢰, 모든 호스트의 물리적 보안을 요구하지 않는다.

또한 네트워크 패킷이 임의로 읽히거나 변조·삽입될 수 있다는 가정 하에서도 동작한다.

이는 대칭키 암호(shared secret key cryptography)에 기반한 신뢰된 제3자(trusted third-party) 인증 서비스 로 구현된다.

Active Directory 환경에서 사용되는 Kerberos는 Microsoft가 [MS-KILE] 로 확장한 변형이며, 동일한 RFC 4120 메시지 흐름을 따르되 PAC(Privilege Attribute Certificate) 등 권한 정보가 추가된다.

PAC: 사용자가 어떤 SID를 가지는지, 어떤 그룹에 속하는지 등 인가(authorization) 정보를 담은 구조체이다. AD에서는 TGT/Service Ticket 안에 PAC가 포함되어, 서비스가 별도로 LDAP 조회를 안 해도 “이 사용자가 Domain Admins구나”를 알 수 있다.

4.1 핵심 용어

용어	정의
Principal	인증 주체. 표기 형식 `primary[/instance]@REALM` (예: `ryan.naylor@VOLEUR.HTB`, `cifs/DC.voleur.htb@VOLEUR.HTB`)
Realm	Kerberos 인증 도메인. 관례상 대문자 표기
KDC (Key Distribution Center)	AS와 TGS를 함께 구현한 서버. RFC 4120은 두 서버를 별개로 기술하지만 실제 구현은 단일 Kerberos 서버 안의 두 진입점(entry point)으로 통합되어 있음. AD에서는 도메인 컨트롤러가 KDC 역할을 함 (TCP/UDP 88)
AS (Authentication Service)	초기 인증 처리, TGT 발급
TGS (Ticket Granting Service)	TGT를 검증하고 Service Ticket 발급
TGT (Ticket-Granting Ticket)	AS가 발급. `krbtgt` 계정의 long-term key로 암호화되어 KDC만 복호화 가능
Service Ticket (ST)	TGS가 발급. 대상 서비스 계정의 long-term key로 암호화됨
Long-term key	사용자/서비스 비밀번호로부터 string-to-key 함수로 파생되는 대칭키. AD 기본값은 `AES256-CTS-HMAC-SHA1-96`, 호환을 위해 `RC4-HMAC`도 존재
Session key	KDC가 매 교환마다 새로 생성하는 대칭키. 클라이언트와 상대(TGS 또는 서비스)가 공유
Authenticator	클라이언트가 매번 새로 생성하는 구조체. 시스템 시각, 클라이언트 이름 등으로 구성. 티켓의 session key를 클라이언트가 알고 있다는 사실을 서버에 증명하여 티켓 재전송(replay)을 방지
SPN (Service Principal Name)	서비스 식별자. 예: `cifs/DC.voleur.htb@VOLEUR.HTB`

4.2 비밀번호 인증 시 클라이언트가 가지고 있어야 할 것

Client principal name (cname) — 사용자 이름
Realm 이름
사용자 long-term key — 비밀번호 또는 미리 파생된 NT hash / AES key
KDC의 호스트 주소 — krb5.conf의 [realms] 섹션에서 매핑
정확한 시각 — 사전인증(PA-ENC-TIMESTAMP)과 Authenticator timestamp에 사용

이 중 5번은 의외로 자주 사람을 괴롭히는데, 뒤의 KRB_AP_ERR_SKEW 절에서 자세히 본다.

4.3 전체 흐름: 3개의 메시지 교환

alt text

AS Exchange (`KRB_AS_REQ` / `KRB_AS_REP`)

목적: 사용자의 long-term key 보유를 증명하고 TGT를 획득.

AS-REQ: 클라이언트가 KDC의 AS에게 krbtgt/REALM@REALM에 대한 티켓을 요청한다. AD에서는 사전인증(pre-authentication)이 강제되므로 PA-DATA 필드에 PA-ENC-TIMESTAMP(현재 timestamp를 사용자 long-term key로 암호화한 값)가 포함된다. 사전인증이 없는 계정은 UF_DONT_REQ_PREAUTH 플래그가 설정된 경우이며, 이는 앞서 본 AS-REP Roasting 공격 대상이 된다.
AS-REP: AS가 두 부분으로 응답한다.
- TGT — krbtgt 계정의 long-term key로 암호화 (클라이언트는 복호화 불가, KDC가 나중에 검증)
  - 복호화가 불가능한 이유는, krbtgt가 랜덤 문자열을 쓰기 때문에 해시 크랙이 불가능하다.
- 사용자의 long-term key로 암호화된 부분 — TGS와 공유할 session key, 만료시간 등 포함

클라이언트는 자신의 long-term key로 두 번째 부분을 복호화하여 session key를 얻는다. 이 부분이 password-based 인증의 본질이며, 비밀번호를 모르면 session key를 얻지 못한다.

TGS Exchange (`KRB_TGS_REQ` / `KRB_TGS_REP`)

목적: TGT를 사용해 특정 SPN의 Service Ticket을 획득.

TGS-REQ: 클라이언트가 KDC에 server용 티켓을 요청한다. TGT, Kerberos authenticator, 그리고 SPN을 함께 제출한다. 정확히는 PA-DATA 필드 안에 PA-TGS-REQ 형태의 AP-REQ(=TGT + Authenticator)가 포함되는 구조다.
TGS-REP: KDC가 TGT와 authenticator를 검증한다. 유효하면 Service Ticket과 클라이언트가 server와의 통신 암호화에 사용할 session key를 반환한다. Service Ticket은 대상 서비스 계정의 long-term key로 암호화된다 — 이 점이 Kerberoasting 공격의 기반이다 (서비스 계정 비밀번호가 약하면 ST를 오프라인 크래킹 가능).

AP Exchange / CS Exchange (`KRB_AP_REQ` / `KRB_AP_REP`)

목적: 클라이언트가 서비스에 직접 인증.

AP-REQ: 티켓, authenticator, 그리고 부가 정보로 구성된 인증 정보를 인증 트랜잭션의 첫 메시지로 전달한다. 티켓은 cleartext로 네트워크에 전달되므로(티켓 자체는 암호화·비암호화 부분을 모두 포함하지만 단위 전체는 복사 가능) 티켓만으로는 클라이언트 인증이 불충분하며 authenticator로 보완한다.
AP-REP: 상호인증이 요청된 경우(MUTUAL-REQUIRED 플래그)에만 응답이 온다. 서비스가 authenticator의 timestamp를 session key로 암호화해 반환함으로써 자신이 정당한 서비스(=대응되는 long-term key 보유자)임을 증명한다.

4.4 정리

세 단계와 각 단계에서 쓰이는 암호화 키를 정리하면 다음과 같다.

AS  Exchange:  비밀번호 → TGT
TGS Exchange:  TGT → Service Ticket
AP  Exchange:  Service Ticket → 서비스 접근

단계	결과물	암호화 키	노리는 공격
AS-REP	TGT + 사용자용 부분	TGT는 `krbtgt` 키, 사용자용 부분은 사용자 계정 키	AS-REP Roasting
TGS-REP	Service Ticket	서비스 계정 키	Kerberoasting
AP-REQ	서비스 접근	session key	(Pass-the-Ticket 등 또 다른 얘기)

5. `KRB_AP_ERR_SKEW` — 시간 오차 에러

Kerberos를 만지다 보면 거의 한 번씩은 만나는 에러이다.

KRB_AP_ERR_SKEW는 RFC 4120에 정의된 Kerberos error code이다.

현재 시각과 가까워야 하는 timestamp가 5분 이상 차이날 때 생성되는 코드로, AP-REQ나 TGS-REQ 안의 authenticator timestamp, encrypted timestamp 사전인증 등에서 발생한다.

즉, 클라이언트 시계가 KDC 기준 5분 이상 어긋난 경우 다.

5.1 원인

Kerberos는 재전송 공격(replay attack) 방지를 위해 시간에 매우 엄격한 프로토콜이다. Windows 환경에서는 기본적으로 클라이언트와 도메인 컨트롤러 간 시계 차이가 5분을 초과하면 KDC가 인증 요청을 거부한다. 이 5분이라는 값은 RFC 4120이 권장한 기본 허용치(clockskew)이며, AD에서는 GPO Maximum tolerance for computer clock synchronization로 조정된다.

5.2 검증되는 시각 필드

PA-ENC-TIMESTAMP (AS-REQ 사전인증)
AP-REQ 안의 Authenticator의 ctime 필드
TGS-REQ 안의 padata로 들어가는 AP-REQ의 Authenticator

5.3 해결: DC 시각으로 동기화

HTB 같은 환경에서는 NTP가 외부 인터넷으로 가버리면 DC와 어긋나므로, DC를 시간 소스로 강제 동기화한다.

# 1. 리눅스 자체의 네트워크 시간 자동 동기화 기능(NTP) 비활성화
sudo timedatectl set-ntp off

# 2. 타겟 DC와 다시 시간 동기화
sudo rdate -n DC.voleur.htb
# 또는
sudo ntpdate DC.voleur.htb

# 3. 시간 동기화가 풀리지 않고 유지되는지 확인
date

VMware/VirtualBox 같은 가상 머신 툴에서는 호스트-게스트 시간 동기화가 백그라운드에서 시간을 다시 되돌려놓는 경우가 있다. 그럴 때는 게스트 추가기능의 time sync가 켜져있지는 않은지 확인해보자!

6. 참고 자료

← ALL POSTS