Hacker Directory — Understand what you hack.Hacker Directory — Understand what you hack.
Continue learning
TR

Learn to understand a record.

Explore the important fields in event, permission and message examples, and what those fields mean.

Ready examples

READ THE EXAMPLE TOGETHER

SYNTHETIC TEACHING EXAMPLE

What happened to this TGT request?

4771 · Pre-authentication / full XML

01
Preauthentication error0x18

0x18 = KDC_ERR_PREAUTH_FAILED: invalid preauthentication information. An incorrect password is possible; one record proves neither attack nor intent.

02
Target account SIDS-1-5-21-111111111-222222222-333333333-1104

The SID recorded for the target account. Read it together with the displayed account name.

03
Account nametunahan

The account name recorded here. A name alone does not establish that accounts from different authorities are identical.

04
TGT request targetkrbtgt/IYELABS.EXAMPLE

In 4771 this names the service in the realm receiving the TGT request. The krbtgt/REALM form identifies a TGT service, not file access.

What to take away

Preauthentication was invalid for the TGT request made for the recorded account. This establishes neither a successful logon, file access nor attack intent. Read the account name with its SID.

We are reading a sample record. This does not connect to Windows or verify that an event or an attack occurred.

06.04 · Kerberos pre-authentication →

Scope of this example

Synthetic teaching record in full Event XML form, not collected from a real DC. Requires Audit Kerberos Authentication Service / Failure. No object SACL is required for this event. A single 0x18 record is not evidence of an attack by itself.

Open the raw record · EVENT-XML
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing"
      Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4771</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14339</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-28T09:14:22.0000000Z" />
    <EventRecordID>10482</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="1048" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan</Data>
    <Data Name="TargetSid">S-1-5-21-111111111-222222222-333333333-1104</Data>
    <Data Name="ServiceName">krbtgt/IYELABS.EXAMPLE</Data>
    <Data Name="TicketOptions">0x40810010</Data>
    <Data Name="Status">0x18</Data>
    <Data Name="PreAuthType">2</Data>
    <Data Name="IpAddress">::ffff:192.0.2.21</Data>
    <Data Name="IpPort">51462</Data>
    <Data Name="CertIssuerName"></Data>
    <Data Name="CertSerialNumber"></Data>
    <Data Name="CertThumbprint"></Data>
  </EventData>
</Event>

READ THE EXAMPLE TOGETHER

SYNTHETIC TEACHING EXAMPLE

Which entries describe access, audit or integrity rules?

SDDL · Security descriptor

01
Local SystemA · File All

Allow entry. The mask scopes the allow/deny entry for its trustee. Effective access cannot be concluded without the request, token, order and object type.

02
Built-in UsersA · File Read

Allow entry. The mask scopes the allow/deny entry for its trustee. Effective access cannot be concluded without the request, token, order and object type.

03
EveryoneAU · File Read

Audit entry. The mask identifies access types to audit, not granted access. SA selects success auditing and FA failure auditing. This ACE alone does not prove an event was logged.

04
Object ownerLocal System

This section is part of the security descriptor. Owner, primary group, DACL and SACL carry different information.

What to take away

Reading an entry is different from concluding that someone can access the object. The request, token, ACE order and object type also matter.

This view explains SDDL entries; it does not run the Windows access decision. SACL audit and mandatory-label entries do not replace DACL permissions.

Scope of this example

Synthetic file-object descriptor. A/D/OA/OD/AU/OU/ML types are read; callback/conditional ACEs are flagged without interpretation. Generic-right mapping and effective access are not computed.

Open the raw record · SDDL
O:SYG:BAD:PAI(A;;FA;;;SY)(A;;FR;;;BU)S:(AU;SAFA;FR;;;WD)

READ THE EXAMPLE TOGETHER

SYNTHETIC TEACHING EXAMPLE

Which parts are inside this byte sequence?

AS-REP · ASN.1 / TLV

01
INTEGER5

This part is 1 bytes long. Type and length identify its boundary within the message; they do not establish its protocol meaning on their own.

02
INTEGER11

This part is 1 bytes long. Type and length identify its boundary within the message; they do not establish its protocol meaning on their own.

03
GeneralStringIYELABS.EXAMPLE

This part is 15 bytes long. Type and length identify its boundary within the message; they do not establish its protocol meaning on their own.

04
INTEGER1

This part is 1 bytes long. Type and length identify its boundary within the message; they do not establish its protocol meaning on their own.

What to take away

A byte sequence contains parts with a type, length and value. Seeing a part’s boundary does not decrypt its content.

This reads structure only. It does not validate an ASN.1 schema or cryptography, or decrypt content.

Scope of this example

Synthetic ASN.1 structure illustrating the RFC format. Cipher fields deliberately contain eight dummy bytes; these are not real tickets or verifiable ciphertext. The reader decodes TLV offsets, not Kerberos schema or cryptography.

Open the raw record · ASN1-HEX
6b 81 ae 30 81 ab a0 03 02 01 05 a1 03 02 01 0b
a3 11 1b 0f 49 59 45 4c 41 42 53 2e 45 58 41 4d
50 4c 45 a4 14 30 12 a0 03 02 01 01 a1 0b 30 09
1b 07 74 75 6e 61 68 61 6e a5 5c 61 5a 30 58 a0
03 02 01 05 a1 11 1b 0f 49 59 45 4c 41 42 53 2e
45 58 41 4d 50 4c 45 a2 24 30 22 a0 03 02 01 02
a1 1b 30 19 1b 06 6b 72 62 74 67 74 1b 0f 49 59
45 4c 41 42 53 2e 45 58 41 4d 50 4c 45 a3 18 30
16 a0 03 02 01 12 a1 03 02 01 01 a2 0a 04 08 a1
a2 a3 a4 b1 b2 b3 b4 a6 18 30 16 a0 03 02 01 12
a1 03 02 01 01 a2 0a 04 08 c1 c2 c3 c4 d1 d2 d3
d4

Read a record and reach a supported conclusion.

  1. Choose the prepared “4771 · Pre-authentication / full XML” record.
  2. Select Status, TargetSid, TargetUserName and ServiceName; read what each field says.
  3. Evaluate the four fields together and compare your interpretation with the explanation. You can also open the raw XML and read Computer to identify the producer.

Distinguish the operation recorded from the limits of your interpretation. An error record alone does not establish account compromise.