From Attack Names to Mechanisms: Understanding Kerberoasting, Relay, DCSync, and Related Terms.

1. Core mechanism

This lesson turns attack labels into mechanisms: Kerberoasting explains the relationship between service-ticket ciphertext and the service-account key; relay explains the conditions under which a challenge-response can be carried to a target; DCSync explains the DRS replication privilege and RPC surface.

Interfaces and specifications

• Kerberoasting: obtaining TGS ciphertext for a service account tied to an SPN and the risk of offline key guessing.
• Relay: forwarding an authentication exchange under the conditions required for the target service to accept it.
• DCSync: requesting replication-like directory data through the directory replication service protocol.
• DS-Replication-Get-Changes and DS-Replication-Get-Changes-All are separate control-access rights for directory replication; the latter covers replication of secret domain data. Verify the rights relevant to the claim's scope together with endpoint access.
• 4769: an observation of a KDC service-ticket operation.
• 4662: an observation of a directory-object operation when a SACL is present; the Properties GUID provides essential context.

Kerberoasting is not an SPN query

In the normal Kerberos flow, the KDC issues a ticket for a service principal; the service ticket is protected in relation to the relevant service-account key. Risk arises when an attacker can request a ticket in a valid domain context and the service key is susceptible to offline guessing.

Therefore, the presence of an SPN is not a finding by itself. Account-key hygiene, encryption types, the service-account usage model, and the context of the ticket request must be assessed separately.

Relay is an acceptance chain, not a protocol name

A relay assessment requires a client to produce a challenge-response, an intermediary to carry it to another target, and the target to accept it without controls such as signing, channel binding, or service binding.

Seeing NTLM in a logon does not prove relay. Without the source, target, negotiated protection, and authorization result at the target, the evidence is only candidate telemetry.

The DCSync label must not hide DRSR and right checks

What is called DCSync is associated with a client using the DRS Remote Protocol surface in a way that imitates normal DC replication architecture. DRSR/RPC endpoint access and directory-side replication authorization are separate gates; for a claim involving secret domain data, verify the scope of relevant rights such as Get-Changes and Get-Changes-All.

Seeing a replication control access-right GUID in 4662 can be a strong investigative signal for an operation involving that right under an appropriate SACL. The event alone, however, does not establish which client obtained all replica data or the full impact.

State and data flow

1. Translate the label back into the normal protocol or authorization flow.
2. State the principal, key/right, and network preconditions for each mechanism.
3. Separate the collected ciphertext, challenge-response, or directory-operation artifact.
4. State which step the detection signal observes and which result it does not prove.

2. Exploitation

Broken trust assumption

The attacker has a separate prerequisite, such as a domain principal, a network position, or an incorrectly delegated replication right; this lesson does not provide instructions for collecting credentials, setting up a relay, or operating a replication client.

Technical prerequisites

• For a Kerberoasting assessment, verify the target SPN and the domain context in which a ticket can be requested; also assess key strength.
• For a relay assessment, verify the target service, network path, and state of the negotiated protective mechanisms.
• For a DCSync assessment, verify endpoint access and the required replication control access rights separately.

Exploitation mechanism

Skipping different prerequisites under the same attack label produces false positives. DCSync is not a “hash dump button,” relay is not every NTLM record, and Kerberoasting is not every SPN; each claim must show the gates required by its mechanism.

Do not jump from a name directly to impact

The appearance of a Kerberos ticket does not prove that the service key is weak; NTLM in 4624 does not prove relay; and a replication GUID does not prove domain compromise. These are inputs to narrower hypotheses.

Opening up the mechanism also makes defense less disruptive: target only the correct SPN/key surface, protocol protection, or delegation right.

3. Defense & Detection

Telemetry scope

• In a Kerberos investigation, correlate the SPN owner, the service account’s purpose, encryption posture, and ticket telemetry.
• In a relay investigation, keep the client, candidate relay intermediary, target service, and negotiated protection on the same timeline.
• Examine replication rights at the object, trustee, inherited-scope, and control-access-GUID levels.
• For 4662, include SACL coverage, DC role, and ObjectType/Properties GUID resolution in the report.

Events and relevant fields

• 4769 is an observation of ticket request or issuance at the KDC; it is not evidence of access to the target service or of an offline-cracking result.
• Event 4662 records a directory-object operation selected by a SACL. ObjectType identifies the class of the accessed object; Properties carries class/property-set GUIDs associated with the operation. The event does not show replication traffic contents or the full impact.

Do not name an attack from a single telemetry signal

The artifact shows ObjectServer=DS, AccessMask=0x100, and a replication GUID context in a synthetic 4662 event. The parser reads the XML structure and fields; it does not calculate whether the GUID produced an effective authorization result.

This distinction ensures that a high-impact alert is first enriched with the right, trustee, source host, and SACL scope.

Detection logic · XPath

*[System[(EventID=4662)]]

Query assumptions

• This XPath example selects Event 4662 records; it does not filter by a replication GUID embedded in Properties.
• Review replication-right GUIDs by distinguishing ObjectType (the accessed object's class) from operation GUIDs in Properties; also consider AccessMask, Subject, ObjectName, and source-host context.
• Actual Event 4662 visibility depends on the SACL and relevant audit-policy settings; this query was not run against a live SIEM or Windows channel.

False positives

• An authorized DC or administrative operation may generate an event in the same right context.
• A GUID match is not evidence of data contents, client intent, or end-to-end compromise.

Hardening

• Manage service-account key hygiene together with an SPN inventory; remove unnecessary SPNs.
• Where NTLM is required, verify signing, sealing, and channel/service-binding controls according to the protocol and target.
• Grant replication control access rights only to the required DC or service principals, and review changes to them.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4662</EventID><Version>0</Version><Level>0</Level><TimeCreated SystemTime="2026-10-01T09:27:41.0000000Z"/><EventRecordID>1303001</EventRecordID><Channel>Security</Channel><Computer>dc01.outreason.example</Computer><Security/></System><EventData><Data Name="SubjectUserSid">S-1-5-21-1987654321-1234567890-2468013579-1504</Data><Data Name="SubjectUserName">sync-reader</Data><Data Name="ObjectServer">DS</Data><Data Name="ObjectType">{19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data><Data Name="ObjectName">DC=outreason,DC=example</Data><Data Name="OperationType">Object Access</Data><Data Name="AccessMask">0x100</Data><Data Name="Properties">{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}</Data></EventData></Event>

Two reality checks

Assumption: Seeing an SPN, NTLM, or replication GUID directly shows that Kerberoasting, relay, or DCSync occurred.

In fact: These are mechanism-specific candidate signals; separate evidence is required for the necessary right/key/network condition and the outcome.

Assumption: DCSync is a protocol completely separate from normal replication.

In fact: The claim is assessed through the DRS replication mechanism and authorization boundary; right scope and audit coverage are therefore critical context.

Sources

• Microsoft Open Specifications · MS-DRSR
  DRS Remote Protocol scope: AD replication and management RPC.
• Microsoft · DS-Replication-Get-Changes-All extended right
  Control access right identity and Rights-GUID.
• Microsoft Open Specifications · MS-NLMP
  NTLM negotiate flags, AV pairs, MIC and session-key protection context.
• Microsoft · 4662(S, F): An operation was performed on an object
  Appropriate SACL/audit settings govern event generation; ObjectType identifies the accessed object class; Properties carries class/property-set GUIDs associated with the operation; AccessMask gives operation context.
• Microsoft · 4769(S, F): A Kerberos service ticket was requested
  4769 is generated on DCs when a KDC gets a TGS request; request/issuance is not proof of target-service acceptance or offline guessing result.
• Microsoft · DS-Replication-Get-Changes extended right
  Extended right needed to replicate changes from a naming context; Rights-GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2.