Immediate Remediation for Kerberoasting Attack
A malicious user has acquired a Ticket Granting Service from the domain controller using a valid user's Ticket Granting Ticket in a Kerberoasting attack. He exhorted the TGS tickets from memory for offline cracking. But the attacker was stopped before he could complete his attack. The system administrator needs to investigate and remediate the potential breach. What should be the immediate step the system administrator takes?
Community Votes
57% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Tests the distinction between immediate containment and long-term remediation in Kerberos security, highlighting that invalidating active tickets is the first priority over changing passwords.
This question addresses the immediate remediation steps following a detected Kerberoasting attack where TGS tickets were extracted from memory. The correct action is to invalidate the compromised Ticket Granting Service (TGS) ticket to immediately prevent unauthorized access.
Many learners choose to change the service account password (Option C) because it prevents future offline cracking of the hash. However, this ignores the immediate threat: if the attacker already has a valid TGS ticket in memory or captured before the password change, they can still use it until it expires or is explicitly invalidated.
Community Discussion (14 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The correct answer is D: Invalidate the TGS the attacker acquired. In a Kerberoasting attack, the attacker extracts a TGS-REP message encrypted with the service account's NTLM hash. If the administrator changes the password (Option C), the hash changes, but any TGS tickets issued before the change remain cryptographically valid until their lifetime expires. To stop an active attack or prevent the use of a captured ticket, the administrator must revoke or invalidate that specific ticket immediately using tools likeklist or Active Directory management consoles.Why the Other Options Are Wrong
Option A (Reboot) is impractical for a domain controller and does not address the network-level validity of the ticket. Option B (Delete account) is too drastic and causes service disruption; it also doesn't invalidate existing tickets issued prior to deletion. Option C (Change password) is a critical subsequent step to ensure the cracked hash becomes useless for future authentication or replay, but it is not the immediate step to stop the currently acquired ticket from being used.Community Comment Notes
The community was split, with many arguing for Option C based on the logic that 'changing the password stops the attack.' However, users like 'insaniunt' correctly noted that invalidating the ticket prevents usage regardless of whether the password is cracked. User '49f4430' emphasized that the question asks for the 'immediate step,' making ticket invalidation the primary action before password rotation.Exam Strategy
Always look for keywords like 'immediate step' or 'first action.' In incident response scenarios involving active exploitation, containment (stopping the current breach) often precedes eradication (removing the cause). For Kerberos attacks, remember that tickets have lifetimes; changing a password does not instantly kill existing tickets.
Frequently Asked Questions
Why isn't changing the password the immediate step?
Changing the password updates the hash but does not invalidate TGS tickets already issued. Those tickets remain valid until expiration unless explicitly revoked.
How do you invalidate a TGS ticket in Windows?
Administrators can use the klist purge command or manage Active Directory accounts to reset the password, which effectively invalidates future tickets but requires explicit revocation for existing ones.