Go back

CTF writeup

Detecting Active Directory Attacks

Each challenge has its own expandable writeup. Open a challenge below to follow the investigation.

Campfire-1

On 21 May 2024, alonzo.spire used PowerView on FORELA-WKSTN001 (172.17.79.129) to find accounts with service principal names. Rubeus then requested an RC4 service ticket for MSSQLService. The DC logged the request at 03:18:09 UTC.

Evidence and tools

  • Domain Controller/SECURITY-DC.evtx — DC Security log
  • Workstation/Powershell-Operational.evtx — PowerShell log
  • Workstation/.../C/Windows/prefetch/ — workstation prefetch files

I used Chainsaw for the EVTX files and sccainfo from libscca for prefetch.

Tasks 1–3: Kerberoast evidence on the DC

Kerberoasting requests a service ticket (TGS) for an account with an SPN, then attempts to crack that ticket offline. The DC logs TGS requests as event 4769. Here, the useful filter is the RC4 ticket encryption type 0x17. 

./chainsaw search -t 'Event.System.EventID: =4769' \
  -t 'Event.EventData.TicketEncryptionType: 0x17' \
  "Domain Controller/SECURITY-DC.evtx"

The search returned one matching event:

EventID: 4769
SystemTime: 2024-05-21T03:18:09.459682Z
Computer: DC01.forela.local
TargetUserName: alonzo.spire@FORELA.LOCAL
ServiceName: MSSQLService
TicketEncryptionType: '0x17'
IpAddress: ::ffff:172.17.79.129
Status: '0x0'
  1. Kerberoast time: 2024-05-21 03:18:09 UTC, from SystemTime.
  2. Targeted service: MSSQLService, from ServiceName.
  3. Workstation IP: 172.17.79.129, from IpAddress. The ::ffff: prefix is the IPv4-mapped IPv6 form.

Chainsaw's leading = means a numeric comparison. The encryption type is stored as the string '0x17', so filter on 0x17 without =.

Tasks 4–5: PowerView on the workstation

With Script Block Logging enabled, PowerShell records script content and its file path in event 4104. A file-backed script has a populated Path field. 

./chainsaw search -t 'Event.System.EventID: =4104' \
  Workstation/Powershell-Operational.evtx \
  | grep -E "SystemTime|Path:" | paste - - | grep -v "Path: ''" | head

Twenty-nine events have a path, all for C:\Users\alonzo.spire\Downloads\powerview.ps1 and all within the same second. The first is timestamped 2024-05-21T03:16:32.588340Z. The script begins with the PowerSploit header, identifying it as PowerView.

  1. Enumeration script: powerview.ps1.
  2. Script run time: 2024-05-21 03:16:32 UTC, using the earliest 4104 event.

An earlier 4104 event at 03:16:29 records powershell -ep bypass, preceding the script load.

Tasks 6–7: Rubeus in prefetch

Rubeus is an executable, so the PowerShell log does not provide its run time. The workstation has RUBEUS.EXE-5873E24B.pf. Prefetch records the executable path, run count and recent run times. Windows 10 prefetch files are compressed; strings alone will not parse them. 

sudo apt install libscca-utils
cd Workstation/2024-05-21T033012_triage_asset/C/Windows/prefetch
sccainfo RUBEUS.EXE-5873E24B.pf

The relevant sccainfo output is:

Executable filename: RUBEUS.EXE
Run count: 1
Last run time: 1: May 21, 2024 03:18:08.972822200 UTC
Filename: \VOLUME{01d951602330db46-52233816}\USERS\ALONZO.SPIRE\DOWNLOADS\RUBEUS.EXE
Filename: \VOLUME{01d951602330db46-52233816}\USERS\ALONZO.SPIRE\DOWNLOADS\RUBEUS.EXE:ZONE.IDENTIFIER
  1. Kerberoast tool path: C:\Users\Alonzo.spire\Downloads\Rubeus.exe. Replace the volume device prefix with C:.
  2. Tool run time: 2024-05-21 03:18:08 UTC. The run count is one; the ticket request follows one second later.

The :ZONE.IDENTIFIER stream indicates a downloaded file. Other loaded files include KERBEROS.DLL, WLDAP32.DLL, SYSTEM.DIRECTORYSERVICES.DLL, NTDSAPI.DLL and the cached domain schema FORELA.LOCAL.SCH. If libscca-utils is unavailable, libscca-python provides pyscca; on Windows, PECmd.exe can parse the prefetch file.

Timeline

  • 03:16:29 UTC: PowerShell execution policy bypass.
  • 03:16:32 UTC: powerview.ps1 loads from Downloads.
  • 03:18:08 UTC: Rubeus.exe runs from Downloads.
  • 03:18:09 UTC: DC logs an RC4 TGS request for MSSQLService from 172.17.79.129.
Campfire-2

On 29 May 2024, a request from 172.17.79.129 targeted arthur.kyle with an AS-REP roast. Pre-authentication was disabled on that account, and the DC returned an RC4-encrypted reply that could be cracked offline. Subsequent activity from the same IP used happy.grunwald.

Evidence and tool

The archive contains Security.evtx, the domain controller's Security log. All five tasks can be answered with Chainsaw.

Tasks 1–3: the AS-REP roast

A normal TGT request is logged as event 4768 with pre-authentication type 2. When an account does not require Kerberos pre-authentication, a request can be made without its password. The resulting AS-REP contains material encrypted with that account's password hash. In this log, the roast is a 4768 event with PreAuthType 0 and RC4 encryption (0x17). 

./chainsaw search -t 'Event.System.EventID: =4768' \
  -t 'Event.EventData.PreAuthType: 0' \
  Security.evtx

The search returns one event:

EventID: 4768
SystemTime: 2024-05-29T06:36:40.246362Z
Computer: DC01.forela.local
TargetUserName: arthur.kyle
TargetSid: S-1-5-21-3239415629-1862073780-2394361899-1601
ServiceName: krbtgt
Status: '0x0'
TicketEncryptionType: '0x17'
PreAuthType: '0'
IpAddress: ::ffff:172.17.79.129
  1. AS-REP roast time: 2024-05-29 06:36:40 UTC, from SystemTime.
  2. Targeted account: arthur.kyle, from TargetUserName.
  3. Targeted account SID: S-1-5-21-3239415629-1862073780-2394361899-1601, from TargetSid.

Filtering event 4768 on TicketEncryptionType: 0x17 returns the same event. The other 4768 events are for DC01$ or Administrator from the DC itself, with pre-authentication type 2 and AES.

Tasks 4–5: workstation and account in use

  1. Workstation IP: 172.17.79.129, from the 4768 IpAddress. The ::ffff: prefix is IPv4-mapped IPv6 notation.

The AS-REP request needs no credentials, so its TargetUserName identifies the target, not the account in use on the workstation. Search for other DC events from the same IP: 

./chainsaw search 172.17.79.129 Security.evtx \
  | grep -E "EventID|SystemTime|TargetUserName|ServiceName"

This finds six events: the 4768 roast, a 4769 service-ticket request, and four 5140 network-share events. The 4769 event at 06:37:49 has TargetUserName: happy.grunwald@FORELA.LOCAL and ServiceName: DC01$. It uses AES (0x12).

  1. Compromised account used: happy.grunwald, identified by its ticket request from the same IP 69 seconds after the roast.

To see the share activity, include SubjectUserName and ShareName:

./chainsaw search 172.17.79.129 Security.evtx \
  | grep -E "EventID|SystemTime|SubjectUserName|ShareName"

The account opened IPC$ at 06:37:49, then DC-Confidential at 06:37:51, and IPC$ again at 06:38:44. An anonymous IPC$ access appears at 06:39:31.

Timeline

  • 06:36:40 UTC: event 4768 records an AS-REP roast of arthur.kyle from 172.17.79.129.
  • 06:37:49 UTC: happy.grunwald requests a ticket for DC01$ and opens IPC$.
  • 06:37:51 UTC: happy.grunwald opens DC-Confidential.
  • 06:38:44 UTC: happy.grunwald opens IPC$ again.
  • 06:39:31 UTC: anonymous access to IPC$ is logged.

For Chainsaw filters, leave = off string values such as '0' and '0x17'; use it for numeric fields such as EventID. A 4768 request with pre-authentication type 0 from a workstation is a useful detection lead. Accounts with DONT_REQ_PREAUTH should also be audited.

Noxious

John Deacon tried to reach \\DCC01 instead of \\DC01. When DNS could not resolve the typo, his workstation broadcast an LLMNR query. A rogue host answered and received a NetNTLMv2 authentication response. The packet capture shows the poisoning, the hash exchange and John's later connection to the intended share.

Evidence and tool

The archive contains capture.pcap. I used tshark for the packet analysis; the same filters can be used in Wireshark.

Questions 1–2: find the rogue host

LLMNR uses UDP 5355. The capture shows one host answering queries for multiple names it does not own, including the misspelled DCC01. 

tshark -r capture.pcap -Y "llmnr && dns.flags.response==1 && ip" \
  -T fields -e frame.time_utc -e ip.src -e ip.dst -e dns.qry.name

At 11:18:30.902 UTC, 172.17.79.135 answered a query for DCC01 from 172.17.79.136. It answered the same name again at 11:18:40, then answered for two other workstations. The real DC01 resolves to 172.17.79.4.

  1. Rogue machine IP: 172.17.79.135.

DHCP reveals the host name advertised by that IP:

tshark -r capture.pcap -Y "dhcp && ip.addr==172.17.79.135" \
  -T fields -e dhcp.option.hostname | sort -u

The output contains V17VT3M03 and kali. The earlier DHCP Discover uses V17VT3M03; the later lease request uses kali.

  1. Rogue machine hostname: kali.

Questions 3–5: identify the captured account

The poisoned reply directs the victim to the rogue host. The NTLM AUTHENTICATE message (type 3) carries the username and response. 

tshark -r capture.pcap -Y "ntlmssp.messagetype==0x00000003" \
  -T fields -e frame.number -e frame.time_utc \
  -e ntlmssp.auth.domain -e ntlmssp.auth.username \
  -e ntlmssp.auth.hostname | head -3

Frame 9292 records FORELA\john.deacon from FORELA-WKSTN002 at 11:18:30.922052 UTC, about 20 ms after the poisoned reply. The workstation then retries authentication.

  1. User whose hash was captured: john.deacon.
  2. First capture time: 2024-06-24 11:18:30 UTC.
  3. Misspelled host: DCC01. The NTLM target is cifs/DCC01.

Use frame.time_utc to avoid local-time confusion. This NTLM exchange uses link-local IPv6, so filtering it with ip.addr would miss the handshake.

Questions 6–8: reconstruct the NetNTLMv2 hash

Frame 9292 belongs to TCP stream 197. The type 2 message holds the server challenge; the type 3 message holds the proof. 

tshark -r capture.pcap -Y "frame.number==9292" -T fields -e tcp.stream
tshark -r capture.pcap -Y "tcp.stream==197 && ntlmssp" -T fields \
  -e frame.number -e ntlmssp.messagetype \
  -e ntlmssp.ntlmserverchallenge \
  -e ntlmssp.ntlmv2_response.ntproofstr
9290  0x00000001
9291  0x00000002  601019d191f054f1
9292  0x00000003                    c0cc803a6d9fb5a9082253a04dbd4cd4
  1. NTLM server challenge: 601019d191f054f1.
  2. NTProofStr: c0cc803a6d9fb5a9082253a04dbd4cd4.

Hashcat mode 5600 expects user::domain:challenge:NTProofStr:blob. The blob is the full NTLMv2 response after its first 32 hex characters, which are the proof already included separately. 

r=$(tshark -r capture.pcap -Y "frame.number==9292" \
  -T fields -e ntlmssp.ntlmv2_response)
echo "john.deacon::FORELA:601019d191f054f1:${r:0:32}:${r:32}" > hash.txt
hashcat -a 0 -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
  1. Cracked password: NotMyPassword0k?.

The PDF notes that an official writeup spells the final k with a capital K. Recomputing the captured response matches the lowercase version shown here. If the challenge rejects it, try the capitalized variant.

Question 9: the intended share

SMB2 Tree Connect requests (command 3) show the full share path. After the typo, John's workstation (172.17.79.136) connects to the real DC (172.17.79.4): 

tshark -r capture.pcap \
  -Y "smb2.cmd==3 && smb2.flags.response==0 && ip.src==172.17.79.136" \
  -T fields -e frame.time_utc -e ip.dst -e smb2.tree
11:19:17.927 UTC  172.17.79.4  \\DC01\IPC$
11:19:18.419 UTC  172.17.79.4  \\DC01\DC-Confidential
  1. Intended share: \\DC01\DC-Confidential. IPC$ is a default SMB share.

Timeline and detection

  • 11:18:30.902 UTC: 172.17.79.135 answers the LLMNR query for DCC01.
  • 11:18:30.922 UTC: John's workstation sends the NetNTLMv2 response.
  • 11:18:40 UTC: another query for dcc01 is poisoned.
  • 11:19:18 UTC: John reaches \\DC01\DC-Confidential.
  • 11:19:46–11:22:31 UTC: the rogue host also answers LLMNR queries for other workstations.

The detection pattern is one host answering LLMNR queries for names it does not own. Disabling LLMNR and NBT-NS prevents these fallback broadcasts. The cracked password also shows why complexity rules alone do not protect against a common wordlist guess.

Reaper

Reaper follows the same LLMNR poisoning pattern as Noxious, but the attacker relayed an NTLM authentication instead of cracking a captured response. Arthur Kyle on FORELA-WKSTN002 tried \\D instead of \\DC01. The rogue host at 172.17.79.135 answered, then forwarded Arthur's authentication to FORELA-WKSTN001. The target's Security log records a successful network logon whose workstation name and source IP do not match.

Evidence and tools

The archive contains ntlmrelay.pcapng and Security.evtx from FORELA-WKSTN001. The packet analysis uses tshark. The event values below were parsed from the log with python-evtx; the Chainsaw filters are provided as equivalent ways to locate them.

Map the hosts

NetBIOS name announcements identify the two workstations:

tshark -r ntlmrelay.pcapng -Y nbns -T fields \
  -e ip.src -e nbns.name | grep -i wkstn | cut -d, -f1 | sort -u
172.17.79.129  FORELA-WKSTN001
172.17.79.136  FORELA-WKSTN002

The DC is 172.17.79.4. A third host, 172.17.79.135, requested a DHCP lease as E9OGH1DCE and then answered LLMNR queries. This is the attacker IP, also seen in Noxious.

Follow the poisoning and relay

The victim queried the name D. The rogue host replied to its LLMNR requests at 04:55:12 and 04:55:13 UTC. 

tshark -r ntlmrelay.pcapng -T fields \
  -e frame.time_utc -e _ws.col.Protocol -e dns.qry.name \
  -Y "(llmnr || nbns) && ip.src==172.17.79.135 && ip.dst==172.17.79.136" \
  | head -4

Listing NTLM AUTHENTICATE messages reveals the handoff. Frame 1213 sends Arthur's authentication from the victim to the attacker; frame 1214 sends it from the attacker to WKSTN001 less than a millisecond later. 

tshark -r ntlmrelay.pcapng -Y "ntlmssp.messagetype==0x00000003" \
  -T fields -e frame.number -e frame.time_utc -e ip.src \
  -e tcp.srcport -e ip.dst -e ntlmssp.auth.username \
  -e ntlmssp.auth.hostname | head -4
Frame 1213  04:55:13.568900  172.17.79.136:50145  →  172.17.79.135
            arthur.kyle  FORELA-WKSTN002
Frame 1214  04:55:13.569818  172.17.79.135:40252  →  172.17.79.129
            arthur.kyle  FORELA-WKSTN002

The SMB session-setup response in frame 1229 is 0x00000000 (STATUS_SUCCESS), confirming that the relay succeeded. The attacker did not need Arthur's password.

  • Relayed account: arthur.kyle.
  • Attacker IP: 172.17.79.135.
  • Relayed source port: 40252.

Find Arthur's intended share

SMB2 Tree Connect requests show the share paths requested by WKSTN002. Arthur first tried the poisoned \\D\IPC$, then connected to the real DC about 15 seconds later. 

tshark -r ntlmrelay.pcapng -T fields \
  -e frame.time_utc -e ip.dst -e smb2.tree \
  -Y "smb2.cmd==3 && smb2.flags.response==0 && ip.src==172.17.79.136"
04:55:13.559 UTC  172.17.79.135  \\D\IPC$
04:55:28.138 UTC  172.17.79.4    \\DC01\IPC$
04:55:28.147 UTC  172.17.79.4    \\DC01\Trip

Share Arthur wanted: \\DC01\Trip.

Confirm the landing on WKSTN001

Event 4624 is a successful logon. Filtering the target's Security log by the relayed source port finds the session: 

./chainsaw search -t 'Event.System.EventID: =4624' \
  -t 'Event.EventData.IpPort: 40252' Security.evtx
SystemTime: 2024-07-31T04:55:16.240589Z
TargetUserName: arthur.kyle
TargetLogonId: 0x64a799
LogonType: 3
LogonProcessName: NtLmSsp
AuthenticationPackageName: NTLM
WorkstationName: FORELA-WKSTN002
IpAddress: 172.17.79.135
IpPort: 40252

FORELA-WKSTN002 belongs to 172.17.79.136, yet this logon came from 172.17.79.135. The relay preserved the original client's workstation name while connecting from the attacker's IP. The log clock is about three seconds ahead of the packet capture.

  • Logon ID: 0x64A799.
  • Workstation name and source IP: FORELA-WKSTN002, 172.17.79.135.
  • Malicious logon time: 2024-07-31 04:55:16 UTC, from the event log.

A 5140 share-access event with the same logon ID and port records ShareName: \\*\IPC$. The packet capture also shows a Tree Connect from the attacker to \\172.17.79.129\IPC$. 

./chainsaw search -t 'Event.System.EventID: =5140' \
  -t 'Event.EventData.IpAddress: 172.17.79.135' Security.evtx

Share accessed by the relay tool: \\*\IPC$.

Timeline and detection

  • 04:55:12 UTC: attacker answers WKSTN002's LLMNR query for D.
  • 04:55:13.559 UTC: WKSTN002 authenticates to the attacker as arthur.kyle.
  • 04:55:13.570 UTC: attacker relays the authentication to WKSTN001 from port 40252.
  • 04:55:16 UTC: WKSTN001 logs the network logon and IPC$ access.
  • 04:55:28 UTC: Arthur reaches \\DC01\Trip.

Require SMB signing on targets and disable LLMNR and NBT-NS to remove the relay and poisoning paths. For detection, compare event 4624's WorkstationName with the hostname assigned to its IpAddress; a mismatch is a useful relay signal.

CrownJewel-1

On 14 May 2024, a Volume Shadow Copy on DC01 gave access to ntds.dit and the SYSTEM hive while the live files were locked. Copies appeared in the Administrator's backup_sync_dc folder. Together, these files can expose the domain's password hashes offline.

Evidence and tools

The archive contains SYSTEM.evtx, SECURITY.evtx, Microsoft-Windows-NTFS.evtx and $MFT. The logs can be searched with Chainsaw, and the MFT can be parsed with MFTECmd or the Python mft package. The exact Chainsaw commands below were proposed in the source walkthrough; their field values were extracted separately. The MFT query was run against the challenge artefact.

Questions 1–3: the shadow copy service

Service Control Manager event 7036 records when Volume Shadow Copy entered the running state: 

./chainsaw search "Volume Shadow Copy" SYSTEM.evtx \
  | grep -E "SystemTime|param"
SystemTime: 2024-05-14T03:42:16.783106Z
param1: Volume Shadow Copy
param2: running
  1. VSS running time: 2024-05-14 03:42:16 UTC.

VSS checked membership of the groups allowed to perform backup operations. Security event 4799 records these lookups by VSSVC.exe: 

./chainsaw search -i vssvc SECURITY.evtx \
  | grep -E "SystemTime|TargetUserName|SubjectUserName|CallerProcess"
SystemTime: 2024-05-14T03:42:16.793461Z
TargetUserName: Administrators
SubjectUserName: DC01$
CallerProcessId: '0x1190'
CallerProcessName: C:\Windows\System32\VSSVC.exe

SystemTime: 2024-05-14T03:42:16.794485Z
TargetUserName: Backup Operators
SubjectUserName: DC01$
  1. Groups and account: Administrators, Backup Operators, DC01$. VSS runs as SYSTEM, so the DC machine account performs the lookups.
  2. VSS process ID: 4496 decimal, converted from 0x1190.

Question 4: the shadow copy mount

The NTFS operational log records mounts. The shadow copy appears as \Device\HarddiskVolumeShadowCopy1 rather than a regular volume: 

./chainsaw search ShadowCopy Microsoft-Windows-NTFS.evtx \
  | grep -E "EventID|SystemTime|DeviceName|VolumeCorrelationId"
EventID: 4
SystemTime: 2024-05-14T03:44:22.812931Z
VolumeCorrelationId: '{06c4a997-cca8-11ed-a90f-000c295644f9}'
DeviceName: \Device\HarddiskVolumeShadowCopy1
  1. Mounted shadow copy GUID: {06c4a997-cca8-11ed-a90f-000c295644f9}.

Questions 5–7: the copied files

The NTFS Master File Table records file paths, sizes and timestamps. Looking for ntds.dit and SYSTEM finds two new copies in the Administrator's Documents folder: 

2024-05-14 03:44:22.813756 UTC  16777216 bytes
  C:\Users\Administrator\Documents\backup_sync_dc\ntds.dit
2024-05-14 03:44:42.344933 UTC  17563648 bytes
  C:\Users\Administrator\Documents\backup_sync_dc\SYSTEM

The copied ntds.dit was created in the same second as the shadow copy mount and is the same size as the live database. The SYSTEM hive followed 20 seconds later.

  1. Dumped database path: C:\Users\Administrator\Documents\backup_sync_dc\ntds.dit.
  2. Dump creation time: 2024-05-14 03:44:22 UTC, from its MFT standard-information timestamp.
  3. Registry hive and size: SYSTEM, 17563648 bytes.

Timeline and detection

  • 03:42:16.783 UTC: System 7036 records Volume Shadow Copy starting.
  • 03:42:16.793 UTC: Security 4799 records VSS group lookups by PID 4496.
  • 03:44:22.813 UTC: NTFS records the shadow copy mount.
  • 03:44:22.814 UTC: MFT records the copied ntds.dit.
  • 03:44:42 UTC: MFT records the copied SYSTEM hive.

A VSS start outside the backup window, followed by a shadow copy mount on a DC, is worth investigating. Command-line logging could also reveal the snapshot command, though it was not present in these artefacts. If both ntds.dit and SYSTEM are taken, response must account for domain credential exposure, including privileged passwords and krbtgt.

CrownJewel-2

CrownJewel-2 reaches the same goal as CrownJewel-1 with ntdsutil.exe, Microsoft's Active Directory maintenance tool. Its Install From Media mode creates a shadow copy and exports ntds.dit to a chosen folder. The Application log's ESENT events show the database copy being created and detached.

Evidence and tools

The archive contains APPLICATION.evtx, SECURITY.evtx and SYSTEM.evtx. The event values were extracted with the Rust EVTX parser. The Chainsaw commands below are equivalent searches from the source walkthrough and were not run there.

Question 1: choose the relevant VSS start

System event 7036 records VSS entering the running state. There are two starts: 05:35:29, followed by a stop at 05:38:29, and a second start at 05:39:55. The second aligns with the database dump. 

./chainsaw search "Volume Shadow Copy" SYSTEM.evtx \
  | grep -E "SystemTime|param"
  1. Relevant VSS start: 2024-05-15 05:39:55 UTC.

Questions 2–5: ESENT records the database copy

The Extensible Storage Engine writes Application events for database creation (325), attachment (326) and detachment (327). Searching for ntds.dit separates this activity from other ESE users: 

./chainsaw search -i ntds.dit APPLICATION.evtx \
  | grep -E "EventID:|SystemTime|ntds.dit"
326  05:39:56.408  NTDS
  C:\$SNAP_202405151039_VOLUMEC$\Windows\NTDS\ntds.dit
325  05:39:56.502  NTDS
  C:\Windows\Temp\dump_tmp\Active Directory\ntds.dit
327  05:39:58.549  NTDS
  C:\Windows\Temp\dump_tmp\Active Directory\ntds.dit

Event 326 opens the database inside the shadow copy. Event 325 records the new copy in dump_tmp. Event 327 closes it two seconds later. dump_tmp was chosen by the operator; IFM creates the Active Directory subfolder.

  1. Dumped database path: C:\Windows\Temp\dump_tmp\Active Directory\ntds.dit.
  2. Database creation time: 2024-05-15 05:39:56 UTC, from ESENT 325.
  3. Database detach time: 2024-05-15 05:39:58 UTC, from ESENT 327.
  4. Event source: ESENT.

Questions 6–7: connect the dump to the session

Security event 4799 records group-membership checks by ntdsutil.exe. There are 118 lookups between 05:39:55.6 and 05:39:56.4: 59 for each group. They carry SubjectUserName: Administrator and logon ID 0x8de3d. 

./chainsaw search -i ntdsutil SECURITY.evtx \
  | grep -E "TargetUserName|SubjectUserName|SubjectLogonId" \
  | sort | uniq -c
118  SubjectLogonId: '0x8de3d'
118  SubjectUserName: Administrator
 59  TargetUserName: Administrators
 59  TargetUserName: Backup Operators
  1. Groups enumerated: Administrators and Backup Operators.

No 4624 for this logon ID appears in the supplied log. Kerberos event 4768 at 05:36:31.166 shows Administrator requesting a TGT from ::1 on the DC, followed by a 4769 ticket for DC01$ at 05:36:31.168. Activity under 0x8de3d begins about 200 ms later.

  1. Session start time: 2024-05-15 05:36:31 UTC, inferred from the Kerberos events and first session activity.

Timeline and detection

  • 05:36:31.166 UTC: Administrator requests a TGT on the DC.
  • 05:39:55.580 UTC: Volume Shadow Copy starts.
  • 05:39:55.636 UTC: ntdsutil.exe begins group lookups under 0x8de3d.
  • 05:39:56.408 UTC: ESENT 326 attaches to the snapshot database.
  • 05:39:56.502 UTC: ESENT 325 creates the exported database.
  • 05:39:58.549 UTC: ESENT 327 detaches the completed copy.

An ESENT 325 event on a DC that creates ntds.dit outside C:\Windows\NTDS is a strong lead, especially in Temp. The 4799 events identify the tool, groups and logon session. IFM also writes the registry hive into a sibling registry folder. A completed dump warrants investigating the Administrator session and treating domain credentials as exposed.