SC-200 Respond to security incidents Practice Question
A security administrator receives an alert from Microsoft Defender for Identity about a suspicious Kerberos ticket request from a domain controller. The alert suggests a possible Golden Ticket attack. Which action should the administrator take to validate the alert?
⚠ Common exam trap
Many exam-takers confuse validation steps with remediation actions, specifically choosing to reset the krbtgt password (Option C) before confirming the attack through log analysis, which would destroy forensic evidence and fail to validate the alert.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Check the domain controller's Security event log for Event ID 4769 with suspicious attributes.
Event ID 4769 (Kerberos Service Ticket Request) on a domain controller is the authoritative source for validating suspicious ticket requests. In a Golden Ticket attack, the forged ticket often exhibits anomalous attributes such as an unusually long lifetime, a non-existent or disabled user account, or encryption type mismatches (e.g., RC4 when AES is expected). Reviewing this log directly confirms whether the ticket characteristics deviate from normal Kerberos behavior, providing definitive evidence for the alert.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Review Microsoft Defender for Identity alerts for brute force attempts.
Why it's wrong here
Reviewing Microsoft Defender for Identity alerts for brute force attempts is not the correct validation step because brute force detection focuses on repeated password guessing against accounts, not on the cryptographic forgery of Kerberos tickets. A Golden Ticket attack involves using the compromised krbtgt account's hash to forge a TGT, which would not generate brute force-style alerts. While MDI might surface related suspicious activity, it does not directly validate the presence of a forged ticket.
- ✓
Check the domain controller's Security event log for Event ID 4769 with suspicious attributes.
Why this is correct
Checking the domain controller's Security event log for Event ID 4769 is the correct validation step because this event records every Kerberos service ticket request. In a Golden Ticket attack, the attacker uses a forged TGT to request service tickets, so Event ID 4769 entries will show anomalies such as unusual encryption types (e.g., RC4 when AES is expected), unexpected service names, or client IP addresses that don't align with normal behavior. These anomalies confirm that a forged ticket is being presented.
- ✗
Reset the krbtgt account password twice.
Why it's wrong here
Resetting the krbtgt account password twice is a remediation step, not a validation step. It is only performed after a Golden Ticket attack has been confirmed to invalidate all existing Kerberos tickets, including forged ones. If you reset the password before validating the attack, you risk disrupting authentication across the entire domain and may still fail to identify the actual compromise vector.
- ✗
Verify if the user account associated with the ticket is disabled.
Why it's wrong here
Verifying whether the user account associated with the ticket is disabled is not a reliable validation method because Kerberos ticket validation relies on the cryptographic trust of the TGT, not on the current state of the user account. Attackers can forge tickets for disabled, non-existent, or highly privileged accounts (such as enterprise admins) that do not require the account to be active or enabled. Therefore, a disabled account is neither necessary nor sufficient to confirm a Golden Ticket attack.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
About these practice questions
One of 1,303 original SC-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-200 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-200 exam.