FalconEye: Evidence-Driven Cyber Kill Chain Investigation

I approached FalconEye as an incident investigation rather than a list of questions to answer. Every branch begins with an observed artifact, explains why that artifact mattered, and uses one of its fields as the next pivot: time, user, host, process, logon ID, hash, IP address, or service name. Where the logs support only an attempt or a strong inference, I say so explicitly.

Investigation map

• Telemetry baseline
• Reconnaissance and BloodHound discovery
• Unquoted service-path privilege escalation
• Persistence impact
• Mimikatz download and credential access
• Kerberos credential abuse
• Lateral movement
• Defense evasion and masquerading
• Staging infrastructure and possible C2
• DCSync attempt
• Investigation course corrections
• Final incident timeline
• Lab answers and supporting evidence

Phase 0: Telemetry Baseline and Investigation Scope

Observation: Identify available hosts, sources, sourcetypes, and visibility

1. The host panel confirmed five hosts and showed the volume disparity between them.

1. The source panel confirmed five Windows event channels and their relative volume.

1. The sourcetype panel confirmed that the dataset used XmlWinEventLog.

Data Pivot: Quantify channel coverage and event-code diversity

index=folks
| stats count, dc(EventCode) as distinct_event_codes, values(EventCode) as event_codes by Channel
| eval event_codes=mvjoin(event_codes, ", ")
| eventstats sum(count) as total
| eval pct=round((count/total)*100,1)
| sort - count

Closure: Dataset and telemetry baseline established

The baseline established:

• 5 hosts (ABDULLAH, ALI, CLIENT01-03), XmlWinEventLog sourcetype, 5 channels
• Security (53.5%) and Sysmon (29.0%) dominate the available telemetry.
• PowerShell/Operational was low volume at 0.7%, but it included useful 4103 and 4104 visibility.
• System and Application had high event-code diversity. I treated them as lower-priority sources, not as channels to suppress.

Client01 appeared in the baseline but did not enter any evidence-backed attack chain developed below. I do not label it clean because this investigation did not include a complete exclusion hunt for that host.

Investigation Brief: Scenario Context, Not Evidence

The scenario brief arrived partway through the hunt. It redirected several checks, especially the search for an unquoted service path, but I still required the event data to establish every conclusion. The brief influenced where I looked. It was not treated as proof of what occurred.

Kill Chain Stage: Reconnaissance and Discovery

Observation 1: Hunt for Native Windows Discovery Commands

I started from the attacker-behavior perspective: if someone had just gained access, they would want to learn the current user, host, network, sessions, processes, and domain environment. Instead of searching for one known tool, I grouped common Windows discovery utilities into five-minute windows so a burst would stand out.

index=folks Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\net.exe" OR Image="*\\net1.exe" OR Image="*\\whoami.exe" OR Image="*\\ipconfig.exe" OR Image="*\\NETSTAT.EXE" OR Image="*\\systeminfo.exe" OR Image="*\\nltest.exe" OR Image="*\\tasklist.exe" OR Image="*\\quser.exe" OR Image="*\\arp.exe" OR Image="*\\route.exe")
| bin _time span=5m
| stats count, values(CommandLine) as commands by _time Computer
| eval commands=mvjoin(commands, " | ")
| sort 0 - count

Native-command Pivot: Scope the Activity and Follow Its Lineage

The command burst gave me a host and process context to investigate. I scoped it to Client02 and kept the process GUIDs so I could follow parent processes without depending on reusable PIDs.

index=folks Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1 Computer="Client02.Abdullah.Ali.Alhakami" Image="*\\net.exe" User="NT AUTHORITY\\SYSTEM" CommandLine="*HelpDesk*"
| table _time, ProcessGuid, ParentProcessGuid, ParentImage, CommandLine

index=folks Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
(ProcessGuid="{e7c1085c-2435-645b-5100-000000000c00}" OR ProcessGuid="{e7c1085c-2435-645b-5000-000000000c00}" OR ProcessGuid="{e7c1085c-3bc9-645a-bf0a-000000000a00}" OR ProcessGuid="{e7c1085c-3bc0-645a-ba0a-000000000a00}")
| table _time, User, ParentImage, ParentProcessGuid, CommandLine

Observation 2: Use PowerShell 4104 to Find a Second Discovery Path

While reviewing the available event IDs, I also noticed PowerShell Event 4104. I did not want to jump straight to a tool name, so I first compared PowerShell activity by host and hour. events counts 4104 records, while unique_scripts counts distinct ScriptBlockId values. This prevents one heavily fragmented script from looking like hundreds of separate executions.

index=folks earliest=0
Channel="Microsoft-Windows-PowerShell/Operational"
EventCode=4104
| bin _time span=1h
| stats count as events
        dc(ScriptBlockId) as unique_scripts
  by _time Computer
| sort 0 - events

The results gave me three observations:

• Client03 had extreme volume from only three large scripts.
• ABDULLAH had extreme volume from six large scripts.
• Client02 had more distinct scripts spread across several hours.

I did not treat the highest count as automatically malicious, and I did not discard Client03 or ABDULLAH. I started with Client02 because its activity appeared earlier and showed more script diversity. In an enterprise I would compare this with a longer host baseline, but for this lab the frequency analysis was only a pivot into content.

Content Pivot: BloodHound Appears

When I inspected Client02’s script content, I found Invoke-BloodHound. This was the first fragment of a large PowerShell script block:

• ScriptBlockId: 0834fc26-...
• MessageTotal: 98
• Therefore, the script was divided across 98 Event 4104 records. This does not mean it executed 98 times.

I then used that 4104 event to recover the PowerShell PID and the user SID. This was the first reliable pivot from script content into process telemetry.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-PowerShell/Operational"
EventCode=4104 "Invoke-BloodHound"
earliest="05/10/2023:00:00:00" latest="05/11/2023:00:00:00"
| rex field=_raw "Execution ProcessID='(?<PS_PID>\d+)'"
| rex field=_raw "Security UserID='(?<UserSID>[^']+)'"
| table _time PS_PID UserSID ScriptBlockId MessageTotal

The result tied the script block to PID 5228 and SID S-1-5-21-1316629931-576095952-2750207263-1114.

Content Validation: Inspect the Final Fragment

I checked fragment 98 to understand what the function would do instead of assuming from its name.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
EventCode=4104
ScriptBlockId="0834fc26-7f16-4536-ba88-e464ce3b59b1"
MessageNumber=98
| table _time MessageNumber MessageTotal ScriptBlockText

The final fragment decompresses an embedded assembly, loads it through reflection, and contains Sharphound.Program.InvokeSharpHound. This proves SharpHound code was processed inside PowerShell. However, because the call sits inside the Invoke-BloodHound function body, the definition by itself does not prove the function was invoked.

Process Pivot: Map PID 5228 to the User and Permanent ProcessGuid

At this point I knew which PowerShell PID processed the script, but a PID can be reused. I correlated PID 5228 with Sysmon Event 1 to identify the account, executable, parent process, integrity level, and stable ProcessGuid.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
EventCode=1 ProcessId=5228
earliest="05/10/2023:00:00:00" latest="05/11/2023:00:00:00"
Image!="C:\\Program Files\\SplunkUniversalForwarder\\*"
| table _time User Image ParentImage CommandLine ProcessId ProcessGuid IntegrityLevel
| sort 0 _time

This mapped PID 5228 to an interactive, medium-integrity PowerShell session launched by explorer.exe as Abdullah-work\HelpDesk. The process’s stable identifier was {e7c1085c-fcda-645a-1015-000000000b00}.

Behavioral Pivot: Follow the ProcessGuid into DNS and Network Activity

I could not find a direct invocation in the other available PowerShell event IDs, so I did not stop at the function definition. Instead, I followed the exact ProcessGuid into Sysmon network, DNS, file-creation, and termination telemetry to see what the process actually did.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
ProcessGuid="{e7c1085c-fcda-645a-1015-000000000b00}"
(EventCode=3 OR EventCode=11 OR EventCode=22 OR EventCode=5)
earliest="05/10/2023:00:00:00" latest="05/11/2023:00:00:00"
| table _time EventCode Image DestinationIp DestinationHostname DestinationPort QueryName TargetFilename
| sort 0 _time

The timing gave the behavior meaning. After the SharpHound code was loaded at 03:28:41, the same PowerShell process queried the domain and _ldap._tcp SRV records, connected to LDAP on port 389, reached the Global Catalog on port 3268, and used SMB on port 445 across systems in both the Abdullah and Ali domains. Event 3 alone only proves network connections. The shared ProcessGuid and timeline place those connections in an Active Directory enumeration context.

Timeline Synthesis: Native Discovery Before and After SharpHound

index=folks Computer="Client02.Abdullah.Ali.Alhakami"
earliest="05/10/2023:00:00:00" latest="05/11/2023:00:00:00"
(
  (Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
   (Image="*\\net.exe" OR Image="*\\net1.exe" OR Image="*\\whoami.exe"
    OR Image="*\\ipconfig.exe" OR Image="*\\systeminfo.exe"
    OR Image="*\\nltest.exe" OR Image="*\\tasklist.exe"))
  OR
  (Channel="Microsoft-Windows-PowerShell/Operational"
   EventCode=4104 "Invoke-BloodHound" MessageNumber=1)
)
| eval activity=case(
    EventCode=4104, "SharpHound code loaded",
    EventCode=1, "Native discovery"
  )
| table _time Computer activity User Image ParentImage CommandLine ProcessId ScriptBlockId
| sort 0 _time

I combined the native-process and PowerShell results to determine their actual order. This also showed why image-name matches must be interpreted through their command lines:

• At 02:09:57, whoami.exe /all performed the first observed local identity and privilege discovery.
• At 03:28:41, the in-memory BloodHound/SharpHound script was loaded.
• From 03:35:25 to 03:38:19, the same PowerShell process performed automated AD-oriented DNS, LDAP, Global Catalog, and SMB discovery.
• From 04:53:10 to 04:54:45, net localgroup Administrators performed additional local-group enumeration.
• At 04:57:36, net localgroup administrators Abdullah-work\HelpDesk /add was not reconnaissance. It modified local Administrators membership and belongs with privilege or account manipulation.
• At 04:59:47, whoami.exe /groups checked the resulting group context.
• The later ipconfig /release and /renew events were network-configuration actions, not discovery.

The sequence was therefore not simply “native tools or SharpHound.” The attacker began with a quick native check, moved to automated domain-wide collection through the SharpHound-associated PowerShell process, and later returned to native commands for local-group discovery and privilege validation.

Reconnaissance Closure: What I Can Prove

I checked for stronger direct evidence as well: a 4103 command invocation, another 4104 script block calling Invoke-BloodHound, and a Sysmon Event 11 ZIP or JSON output artifact. None were present, and PowerShell invocation-start/stop Events 4105 and 4106 were not available in this dataset.

That leaves a clear evidence boundary:

Abdullah-work\HelpDesk used PowerShell PID 5228 on Client02 to perform Active Directory enumeration. The process loaded the in-memory BloodHound/SharpHound ingestor and then produced LDAP, Global Catalog, SMB, and domain-discovery traffic. This strongly attributes the enumeration to BloodHound/SharpHound, although the dataset does not contain the direct function-call record or output archive.

Kill Chain Stage: Exploitation and Privilege Escalation

Observation: Follow the Privilege-Changing Command Back to Its Parent

The discovery hunt had also surfaced:

net localgroup administrators Abdullah-work\HelpDesk /add

That command changes local group membership, so it belongs to privilege escalation rather than reconnaissance. Following its process ancestry led back to the unusual executable C:\program.exe.

index=folks Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="C:\\program.exe"
| table _time, User, ParentImage, ParentProcessGuid, CommandLine, Hashes
| sort _time

The suspicious executions ran as NT AUTHORITY\SYSTEM, were launched by services.exe, and carried the intended command line:

C:\Program Files\Basic Monitoring\Automate-Basic-Monitoring.exe

Because the actual image was C:\program.exe, the parent was services.exe, and the intended path contained spaces, I suspected an unquoted service-path hijack. I used the observed Basic Monitoring path to find the supporting event sources instead of assuming an event code.

Service Pivot: Find Where the Basic Monitoring Path Was Recorded

index=folks Computer="Client02.Abdullah.Ali.Alhakami"
("Basic Monitoring" OR "Automate-Basic-Monitoring.exe")
| stats count
        min(_time) as first_seen
        max(_time) as last_seen
        values(Image) as Image
        values(CommandLine) as CommandLine
  by Channel EventCode
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen

This returned System Event 7045, so I inspected those service-installation records directly.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="System" EventCode=7045
("Basic Monitoring" OR "Automate-Basic-Monitoring.exe")
| rex field=EventData_Xml "<Data Name='ServiceName'>(?<ServiceName>[^<]+)</Data>"
| rex field=EventData_Xml "<Data Name='ImagePath'>(?<ImagePath>[^<]+)</Data>"
| rex field=EventData_Xml "<Data Name='AccountName'>(?<ServiceAccount>[^<]+)</Data>"
| table _time Computer ServiceName ImagePath ServiceAccount
| sort 0 _time

Two services used the same unquoted executable path and ran as LocalSystem:

• Auto monitoring
• Monitor service
• Image path: C:\Program Files\Basic Monitoring\Automate-Basic-Monitoring.exe

Windows could therefore resolve C:\program.exe before reaching the intended executable.

The Windows service names were Auto monitoring and Monitor service. The lab answer mask expected the vulnerable service binary, so the answer is Automate-Basic-Monitoring.exe, not either display name.

Process Pivot: Reconstruct the SYSTEM Process Lineage

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
EventCode=1 Image="C:\\program.exe"
earliest="05/10/2023:04:57:30" latest="05/10/2023:04:57:45"
| table _time User ProcessId ProcessGuid ParentImage ParentProcessGuid CommandLine Hashes
| sort 0 _time ProcessId

Two program.exe instances ran at 04:57:36 as SYSTEM:

• PID 2360 → ProcessGuid ending 3000
• PID 2416 → ProcessGuid ending 3600
• Both were launched by services.exe.
• Both had SHA256 8ACC5D98CFFE8FE7D85DE218971B18D49166922D079676729055939463555BD2.

The hash belongs to C:\program.exe in the Sysmon Image field, not the intended path shown in CommandLine.

I followed both program.exe ProcessGuids to their direct children:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
EventCode=1
(
  ParentProcessGuid="{e7c1085c-2424-645b-3000-000000000c00}"
  OR ParentProcessGuid="{e7c1085c-2424-645b-3600-000000000c00}"
)
| table _time User Image ProcessId ProcessGuid ParentImage ParentProcessGuid CommandLine
| sort 0 _time ProcessId

Each instance spawned rundll32.exe. I then followed the two resulting rundll32.exe ProcessGuids:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
EventCode=1
(
  ParentProcessGuid="{e7c1085c-2435-645b-5000-000000000c00}"
  OR ParentProcessGuid="{e7c1085c-2435-645b-5100-000000000c00}"
)
| table _time User Image ProcessId ProcessGuid ParentImage ParentProcessGuid CommandLine
| sort 0 _time ProcessId

Both branches produced the same SYSTEM-level command:

services.exe
  → C:\program.exe
    → rundll32.exe
      → net.exe localgroup administrators Abdullah-work\HelpDesk /add

Confirmation Pivot: Verify That the Group Membership Changed

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4732
earliest="05/10/2023:04:57:20" latest="05/10/2023:04:58:00"
| table _time EventCode SubjectUserName SubjectUserSid SubjectLogonId
        MemberName MemberSid TargetUserName TargetDomainName TargetSid
| sort 0 _time

Event 4732 provides the independent Windows confirmation:

• Added member: Abdullah-work\HelpDesk
• Target group: BUILTIN\Administrators
• Security context: NT AUTHORITY\SYSTEM
• SYSTEM logon session: 0x3e7

Privilege-escalation closure

The evidence supports an unquoted service-path attack on the two LocalSystem Basic Monitoring services. Windows executed the attacker’s C:\program.exe as SYSTEM, and the resulting lineage attempted to add the compromised HelpDesk account to the local Administrators group. Event 4732 confirms that the membership change succeeded.

The Security event is timestamped six seconds before the recorded Sysmon process chain. I therefore treat them as strongly correlated activity in the same escalation window, rather than claiming that the displayed net.exe event definitively generated that exact Security record.

Persistence Impact: Durable Local Administrator Membership

Adding HelpDesk to BUILTIN\Administrators achieved immediate privilege escalation and also created a durable access condition that could survive the original process ending. I therefore map the successful group modification to both privilege escalation and persistence impact.

The two Basic Monitoring services are not counted as attacker-created persistence. Event 7045 established their configuration and exposed the vulnerable unquoted path, but the available sequence does not prove the attacker installed those services during this intrusion.

Kill Chain Stage: Credential Access

Post-Escalation Observation: What Did HelpDesk Do Next?

After Event 4732 confirmed that HelpDesk had been added to the local Administrators group, I returned to the same account and inspected the processes it launched during the next few minutes.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
User="Abdullah-work\\HelpDesk"
earliest="05/10/2023:04:57:30" latest="05/10/2023:05:10:00"
| stats count min(_time) as first_seen max(_time) as last_seen by Image
| convert ctime(first_seen) ctime(last_seen)
| sort 0 - count

Most results were normal desktop and interactive-logon processes. I narrowed the timeline to PowerShell, rundll32.exe, and whoami.exe, which were the only images that could explain what HelpDesk did immediately after the privilege change.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
User="Abdullah-work\\HelpDesk"
earliest="05/10/2023:04:57:30" latest="05/10/2023:05:10:00"
(
  Image="*\\powershell.exe"
  OR Image="*\\rundll32.exe"
  OR Image="*\\whoami.exe"
)
| table _time Image ParentImage CommandLine ProcessId ProcessGuid
        ParentProcessId ParentProcessGuid IntegrityLevel LogonId
| sort 0 _time

This produced three useful observations:

• At 04:59:47, whoami /groups confirms the attacker checked the new group membership.
• At 05:05:11, a new powershell.exe ran at High integrity as HelpDesk.
• The rundll32.exe ... SHCreateLocalServerRunDll entries are routine shell activity and can be dropped.

Process Pivot: Follow the Elevated PowerShell Instance

The elevated PowerShell process had ProcessGuid {e7c1085c-2607-645b-5a01-000000000c00}. Rather than guessing what happened inside it, I first checked which Sysmon event types were tied to that process.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
earliest="05/10/2023:05:05:00" latest="05/10/2023:06:30:00"
(
  ProcessGuid="{e7c1085c-2607-645b-5a01-000000000c00}"
  OR ParentProcessGuid="{e7c1085c-2607-645b-5a01-000000000c00}"
)
| stats count by EventCode
| sort 0 EventCode

I then expanded those events into a single process timeline:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational"
earliest="05/10/2023:05:05:00" latest="05/10/2023:06:30:00"
(
  ProcessGuid="{e7c1085c-2607-645b-5a01-000000000c00}"
  OR ParentProcessGuid="{e7c1085c-2607-645b-5a01-000000000c00}"
)
| table _time EventCode Image ParentImage CommandLine
        DestinationIp DestinationPort DestinationHostname
        TargetFilename ProcessId ProcessGuid ParentProcessGuid
| sort 0 _time EventCode

This gave me the next evidence-backed chain:

Elevated PowerShell starts at 05:05:11
  → connects to 192.168.159.1:80 at 05:07:32
  → creates C:\Users\HelpDesk\fun.exe at 05:08:57
  → executes fun.exe at 05:10:30

Payload-Identification Pivot: Determine What fun.exe Really Is

The filename alone did not identify the payload, so I inspected the process metadata recorded by Sysmon:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
ProcessGuid="{e7c1085c-2746-645b-8501-000000000c00}"
| table _time User Image OriginalFileName Description Product Company
        ParentImage CommandLine IntegrityLevel Hashes ProcessId ProcessGuid

The file executed from disk as fun.exe, while its embedded OriginalFileName, description, and product fields identified it as mimikatz.exe. This mismatch proves that the executable had been renamed.

• fun.exe is Mimikatz.
• It executed with High integrity.
• SHA256: CFD90BF9CB627FB3574096B9D1C33522A46DB7412CD0FF42226474BF6A74CD77

Hash Pivot: Find Every Execution of the Same Mimikatz Sample

The filename could change again, so I used the sample’s exact SHA256 to find its other executions:

index=folks
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
Hashes="*CFD90BF9CB627FB3574096B9D1C33522A46DB7412CD0FF42226474BF6A74CD77*"
| table _time Computer User Image OriginalFileName ParentImage
        CommandLine IntegrityLevel ProcessId ProcessGuid
| sort 0 _time

This result showed repeated high-integrity Mimikatz executions by HelpDesk. Most launches were interactive, so Sysmon recorded the process start but not the commands typed into the console. One later launch at 08:09:36 exposed a complete DCSync command line. I bookmarked that result for the final DCSync branch and continued chronologically from the first Mimikatz execution at 05:10:30.

Timeline Continuation: Follow HelpDesk After the First Mimikatz Execution

From the first Mimikatz execution, I summarized the later Sysmon and Security event types associated with HelpDesk. This kept the next pivot tied to the known actor without assuming which account or technique would appear next.

Known compromised actor → same host → later activity → available EventCodes → meaningful event

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
earliest="05/10/2023:05:10:30" latest="05/10/2023:08:09:36"
(
  (Channel="Microsoft-Windows-Sysmon/Operational"
   User="Abdullah-work\\HelpDesk")
  OR
  (Channel="Security"
   SubjectUserName="HelpDesk")
)
| stats count min(_time) as first_seen max(_time) as last_seen
  by Channel EventCode
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen Channel EventCode

Event 4648 stood out because it records an attempt to use explicit credentials. I inspected those events without assuming which secondary account mattered:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4648
SubjectUserName="HelpDesk"
earliest="05/10/2023:05:10:30" latest="05/10/2023:08:09:36"
| table _time SubjectUserName SubjectLogonId
        TargetUserName TargetDomainName
        TargetServerName TargetInfo
        ProcessName ProcessId IpAddress IpPort
| sort 0 _time

The result contained four distinct credential-use branches: Mohammed, it-support through PowerShell, it-support through Mimikatz, and Administrator. During the investigation I initially followed it-support because it led directly to Client03. That was useful, but it skipped the earlier Mohammed branch. Returning to the events in timestamp order exposed the lab’s first clear Overpass-the-Hash sequence.

Missed Branch Recovered: Trace the Earlier Mohammed Session

At 06:08:14 and 06:08:38, Event 4648 showed HelpDesk’s PowerShell using Mohammed against LDAP. The source LUID was 0x321bad, so I followed that session backward rather than searching globally for Rubeus:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security"
(EventCode=4624 OR EventCode=4648)
earliest="05/10/2023:05:45:00" latest="05/10/2023:06:09:00"
| search TargetLogonId="0x321bad" OR SubjectLogonId="0x321bad"
| table _time EventCode SubjectUserName SubjectLogonId
        TargetUserName TargetDomainName TargetLogonId
        LogonType LogonProcessName AuthenticationPackageName
        ProcessName ProcessId TargetInfo
| sort 0 _time

The LUID led back to a type-9 NewCredentials session created at 05:49:11:

I then searched Sysmon for the process created in that session:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
earliest="05/10/2023:05:49:00" latest="05/10/2023:05:50:00"
| search LogonId="0x321bad"
| table _time User Image ParentImage CommandLine ParentCommandLine
        ProcessId ProcessGuid ParentProcessGuid LogonId IntegrityLevel
| sort 0 _time

The child cmd.exe pointed to its parent, Microsoft-Update.exe. Sysmon identified that parent as Rubeus.exe and preserved the decisive command line:

"C:\Users\HelpDesk\Microsoft-Update.exe" asktgt
/user:Mohammed
/aes256:facca59ab6497980cbb1f8e61c446bdbd8645166edd83dac0da2037ce954d379
/opsec /createnetonly:C:\Windows\System32\cmd.exe /show /ptt

This is the clean Overpass-the-Hash, more precisely Pass-the-Key, chain:

Rubeus uses Mohammed's AES256 key
  → requests a Kerberos TGT
  → creates a type-9 net-only session
  → injects the ticket with /ptt
  → PowerShell in that session authenticates to LDAP as Mohammed

The account asked for in the Overpass-the-Hash question was therefore Mohammed, and its AES256 key was facca59ab6497980cbb1f8e61c446bdbd8645166edd83dac0da2037ce954d379. A later, separate Rubeus command used an Administrator key. Treating that later key as the answer was one of the false turns in the original investigation.

Backward Account Pivot: How Was it-support Compromised?

I then returned to the same Event 4648 inventory. The first explicit use of it-support was at 06:59:41, but Event 4648 only proves use. It does not explain acquisition. I searched backward from that timestamp for earlier Security events containing the account:

index=folks
Channel="Security"
"it-support"
earliest=0 latest="05/10/2023:06:59:40"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(Computer) as Computers by EventCode
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen

Event 4769 was the useful branch because it records Kerberos service-ticket requests:

index=folks
Computer="Abdullah.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4769
"it-support"
latest="05/10/2023:06:59:40"
| stats count min(_time) as first_seen max(_time) as last_seen
  by TargetUserName IpAddress ServiceName TicketEncryptionType Status
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen

The meaningful pattern was not simply “RC4 equals malicious.” It was the combination:

Mohammed → it-support → RC4 (0x17) → 16 successful requests in three seconds

• 0x17 is RC4-HMAC, so the returned service tickets were suitable for offline cracking.
• Status=0x0 means the requests succeeded.
• Sixteen requests between 12:30:32 and 12:30:35 on May 8 form a rapid burst against one service account.

That strongly supports Kerberoasting against it-support.

Source Pivot: Map the Requester to Client02

The service-ticket requests originated from 192.168.1.102. I mapped the address through a successful DC logon rather than assuming the last octet matched a hostname:

index=folks
Computer="Abdullah.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4624
(IpAddress="192.168.1.102" OR IpAddress="::ffff:192.168.1.102")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(TargetUserName) as Users by IpAddress WorkstationName
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen

The row containing WorkstationName=CLIENT02 and TargetUserName=CLIENT02$ supports 192.168.1.102 → Client02.

Client02 later appeared as 192.168.2.101 on May 10. That does not invalidate the May 8 mapping because each address was independently tied to Client02 in its own timestamped event. The later ipconfig /release and /renew activity shows that network reconfiguration occurred, but its timing does not prove that DHCP caused this particular subnet change.

I also checked the available telemetry on Client02 during the May 8 burst. Only Security and System events were present. No Sysmon or PowerShell events covered that window. The source process and the offline cracking step are therefore unobserved. What the logs support is the ticket-request burst and the account’s later use, not a recorded cracking command.

Whether the recovered key actually worked is tested in the later Client03 branch.

Credential-access assessment

The credential-access evidence now has two different confidence levels:

• Observed directly: renamed Rubeus used Mohammed’s AES256 key for Overpass-the-Hash and injected a TGT.
• Strongly inferred: the May 8 RC4 burst Kerberoasted it-support. Its later successful use is consistent with an offline crack, but the cracking process is absent from the dataset.

Kill Chain Stage: Lateral Movement

The broad Event 4648 result gave several possible paths. I followed them in time order and required three layers before calling any movement successful: source-side intent, a network connection, and target-side evidence. Authentication alone was not treated as remote execution.

Administrator on Client03: S4U to the WinRM Service

Once Microsoft-Update.exe had been identified as Rubeus in the Mohammed branch, the natural next pivot was to inventory later executions of the same tool:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
OriginalFileName="Rubeus.exe"
earliest="05/10/2023:06:00:00" latest="05/10/2023:06:30:00"
| table _time User Image OriginalFileName ParentImage CommandLine
        ProcessId ProcessGuid IntegrityLevel
| sort 0 _time

At 06:18:19, Rubeus used the Client02 machine-account key for S4U delegation and impersonated Administrator to the SPN http/Client03:

"C:\Users\HelpDesk\Microsoft-Update.exe" s4u
/user:Client02$
/aes256:0a87dfe150dc1da194b965a620e2acd94aea917185c7bb6731aa323470f357d9
/msdsspn:http/Client03 /impersonateuser:Administrator /ptt

HTTP/Client03 is a Kerberos service principal name, not a web page. Windows Remote Management over HTTP uses that service class, so the command gave me a precise destination and protocol to validate.

index=folks
Computer="Client03.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4624
TargetUserName="Administrator"
earliest="05/10/2023:06:18:00" latest="05/10/2023:06:32:10"
| table _time TargetUserName TargetDomainName LogonType
        AuthenticationPackageName IpAddress WorkstationName TargetLogonId
| sort 0 _time

The first corresponding Administrator logon on Client03 occurred at 06:21:44 with LUID 0x23f77d3. Following that LUID into Sysmon showed what the network logon created:

index=folks
Computer="Client03.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
LogonId="0x23f77d3"
earliest="05/10/2023:06:21:30" latest="05/10/2023:06:24:00"
| table _time User Image ParentImage CommandLine
        ProcessId ProcessGuid ParentProcessGuid LogonId IntegrityLevel
| sort 0 _time

The sequence was conclusive:

• At 06:21:44, high-integrity wsmprovhost.exe -Embedding started as Abdullah-work\Administrator.
• At 06:23:37, that WinRM host launched HOSTNAME.EXE and whoami.exe.

This branch proves both the abused service, http/Client03, and the target-side process, wsmprovhost.exe. It also proves remote command execution, not merely authentication.

it-support on Client03: Follow the Type-9 Source Session

The next branch began with HelpDesk’s Event 4648 at 06:59:41:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4648
SubjectUserName="HelpDesk" TargetUserName="it-support"
earliest="05/10/2023:06:59:35" latest="05/10/2023:07:00:15"
| table _time SubjectUserName SubjectLogonId
        TargetUserName TargetDomainName TargetServerName TargetInfo
        ProcessName ProcessId
| sort 0 _time

The event supplied two useful correlation values: SubjectLogonId=0x504b8b and PowerShell PID 0x1c0c (decimal 7180). The LUID was the stronger pivot because it described the entire local logon session, not only one process.

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security"
(EventCode=4624 OR EventCode=4648)
earliest="05/10/2023:06:40:00" latest="05/10/2023:07:01:00"
| search TargetLogonId="0x504b8b" OR SubjectLogonId="0x504b8b"
| table _time EventCode SubjectUserName SubjectLogonId
        TargetUserName TargetDomainName TargetLogonId
        LogonType LogonProcessName AuthenticationPackageName
        ProcessName ProcessId TargetServerName TargetInfo
| sort 0 _time

This is the important Windows logon-session relationship:

06:49:48 Event 4624 creates session 0x504b8b
         and records it as TargetLogonId
                         ↓
06:59:41 Event 4648 is performed by session 0x504b8b
         and records it as SubjectLogonId

The Target and Subject labels describe the session’s role in each event. They are not different IDs. Event 4624 also identified the source-side session as Logon Type 9 (NewCredentials).

I then used that same LUID in Sysmon Event 1 to find the process created inside the session:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
earliest="05/10/2023:06:49:40" latest="05/10/2023:06:50:10"
| search LogonId="0x504b8b"
| table _time Image CommandLine ParentImage ParentCommandLine
        ParentProcessGuid LogonId

The child cmd.exe did not contain the key in its own command line, but its ParentCommandLine already exposed the full Rubeus invocation. I still followed ParentProcessGuid to verify the parent’s embedded identity:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
ProcessGuid="{e7c1085c-3e8c-645b-8f04-000000000c00}"
| table _time Image OriginalFileName CommandLine Hashes ProcessGuid

The parent was again renamed Rubeus:

asktgt /user:it-support
/aes256:e1545adafb17d4e61b66a6ecc189718aed4ad3e5c3382ea08575a499ed231428
/opsec /createnetonly:C:\Windows\System32\cmd.exe /show /ptt

This establishes how the source session was prepared. I next followed PowerShell PID 7180 to the network:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
earliest="05/10/2023:06:59:30" latest="05/10/2023:07:01:00"
(
  (Channel="Security" EventCode=4648
   ProcessId="0x1c0c" TargetUserName="it-support")
  OR
  (Channel="Microsoft-Windows-Sysmon/Operational" EventCode=3
   ProcessId=7180)
)
| stats min(_time) as first_seen max(_time) as last_seen
        values(User) as User values(Image) as Image
        values(TargetServerName) as DestinationHost
        values(TargetInfo) as TargetInfo
        values(DestinationIp) as DestinationIp
        values(DestinationPort) as DestinationPort
        values(Protocol) as Protocol
| convert ctime(first_seen) ctime(last_seen)

The process connected from Client02 (192.168.2.101) to 192.168.2.106:5985. The Event 4648 fields map that endpoint to Client03 and HTTP/Client03. Sysmon’s blank DestinationHostname does not weaken the mapping because the hostname came from the correlated Security event.

On Client03, two Event 4624 records confirmed successful Kerberos network logons:

index=folks
Computer="Client03.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4624
TargetUserName="it-support"
earliest="05/10/2023:06:59:35" latest="05/10/2023:07:00:15"
| table _time TargetUserName TargetDomainName LogonType
        AuthenticationPackageName IpAddress WorkstationName TargetLogonId
| sort 0 _time

The target logons were Type 3, which is distinct from the Type 9 source session on Client02. Searching the target LUIDs produced only Events 4624 and 4634:

index=folks
Computer="Client03.Abdullah.Ali.Alhakami"
("0x252a424" OR "0x252a408")
earliest="05/10/2023:06:59:35" latest="05/10/2023:07:10:00"
| stats count min(_time) as first_seen max(_time) as last_seen
  by Channel EventCode
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen Channel EventCode

This branch proves the injected it-support identity authenticated to Client03 and that the source PowerShell reached WinRM. Unlike the earlier Administrator branch, it does not contain a target-side wsmprovhost.exe or child command, so I stop at successful authentication and connection.

Later Administrator Use: Recover the Session Before Following the Targets

After closing the it-support branch, I returned to the original Event 4648 inventory. The later rows showed PowerShell using Administrator from SubjectLogonId=0x5c344e:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4648
SubjectUserName="HelpDesk"
earliest="05/10/2023:06:00:00" latest="05/10/2023:08:00:00"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(TargetServerName) as TargetServers
        values(TargetInfo) as TargetServices
  by SubjectUserName SubjectLogonId TargetUserName TargetDomainName
     ProcessName ProcessId
| convert ctime(first_seen) ctime(last_seen)
| sort 0 first_seen

I followed 0x5c344e backward through Security events:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security"
(EventCode=4624 OR EventCode=4648)
earliest="05/10/2023:07:10:00" latest="05/10/2023:07:35:00"
| search TargetLogonId="0x5c344e" OR SubjectLogonId="0x5c344e"
| table _time EventCode SubjectUserName SubjectLogonId
        TargetUserName TargetDomainName TargetLogonId
        LogonType LogonProcessName AuthenticationPackageName
        ProcessName ProcessId TargetInfo
| sort 0 _time

At 07:19:23, Event 4624 created another Type-9 NewCredentials session. Sysmon linked the session’s cmd.exe to its parent:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
earliest="05/10/2023:07:19:00" latest="05/10/2023:07:20:00"
| search LogonId="0x5c344e"
| table _time User Image ParentImage CommandLine
        ProcessId ProcessGuid ParentProcessId ParentProcessGuid
        LogonId IntegrityLevel
| sort 0 _time

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
ProcessGuid="{e7c1085c-457a-645b-6e05-000000000c00}"
| table _time User Image OriginalFileName ParentImage CommandLine
        IntegrityLevel Hashes ProcessId ProcessGuid ParentProcessGuid

The parent was Rubeus, this time using the Administrator AES256 key:

asktgt /user:Administrator
/aes256:730f8f17b250ced37d8f9bd548043cc31b4fd5da101e2429febfd4dc0b237ce8
/opsec /createnetonly:C:\Windows\System32\cmd.exe /show /ptt

This is another Pass-the-Key operation, but it occurred later than the Mohammed event and is not the AES key requested by the lab’s Overpass-the-Hash question.

The same LUID later appeared in Administrator Event 4648 records from PowerShell PID 0x1170 (decimal 4464):

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Security" EventCode=4648
SubjectUserName="HelpDesk" TargetUserName="Administrator"
earliest="05/10/2023:07:30:00" latest="05/10/2023:08:00:00"
| table _time SubjectUserName SubjectLogonId TargetUserName
        TargetDomainName TargetServerName TargetInfo ProcessName ProcessId
| sort 0 _time

Following PID 4464 in Sysmon network events revealed LDAP traffic to both domains and WinRM traffic to Abdullah:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=3
ProcessId=4464
earliest="05/10/2023:07:32:00" latest="05/10/2023:07:58:00"
| table _time User Image ProcessId ProcessGuid SourceIp SourcePort
        DestinationIp DestinationPort DestinationHostname Protocol
| sort 0 _time

• Abdullah over LDAP port 389.
• Ali over LDAP port 389.
• Abdullah repeatedly over WinRM port 5985.

I validated those source-side connections against Event 4624 on the destinations:

index=folks
Channel="Security" EventCode=4624
TargetUserName="Administrator"
(Computer="Abdullah.Abdullah.Ali.Alhakami" OR Computer="Ali.Ali.Alhakami")
earliest="05/10/2023:07:32:00" latest="05/10/2023:07:58:00"
| table _time Computer TargetUserName TargetDomainName LogonType
        AuthenticationPackageName IpAddress WorkstationName TargetLogonId
| sort 0 _time Computer

Abdullah received Administrator authentication from 192.168.2.101, while Ali received Administrator authentication from 192.168.159.133. Both were successful Kerberos network logons. At this point that proved authentication, but not execution on either host.

Parent-Domain Pivot: Find the Forged Trust Ticket

The Ali LDAP connection introduced a new domain into the active timeline. My first pass stopped after validating the logon. That missed the more useful source-side question: what was HelpDesk doing on Client02 immediately after reaching Ali?

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
User="Abdullah-work\\HelpDesk"
earliest="05/10/2023:07:34:00" latest="05/10/2023:07:58:00"
| table _time Image ParentImage CommandLine ProcessId ProcessGuid
| sort 0 _time

The wider timeline mattered. A narrow search for Rubeus.exe would have missed Better-to-trust.exe, whose embedded behavior and command syntax were Mimikatz-style kerberos::golden. Three executions forged Administrator tickets for the parent domain Ali.Alhakami:

• At 07:36:07, the AES256 command wrote trust_tgt.kirbi.
• At 07:44:42, the RC4 command also wrote trust_tgt.kirbi.
• At 07:51:24, the RC4 command wrote trust-test2.kirbi.

The commands used /user:Administrator, /service:krbtgt, /target:Ali.Alhakami, and a SIDHistory value ending in -519 (Enterprise Admins). The final generated ticket name was trust-test2.kirbi.

That filename is copied exactly from the final /ticket:trust-test2.kirbi command-line argument. I retained the five-character .kirbi extension because the event value is stronger evidence than a visually estimated answer mask.

The order prevents overclaiming: the first Ali authentication at 07:34:26 occurred before these ticket-generation commands, so the later files cannot explain that earlier logon. Nearby klist.exe and fun.exe executions support ticket inspection and follow-on Mimikatz activity, but they do not by themselves prove that Ali accepted any forged ticket.

Target-Process Pivot: Prove Administrator Execution on Abdullah

The network results gave a rational way to choose among the many Administrator logons: Abdullah was the only target that received WinRM traffic on port 5985. I searched it for Administrator processes in that interval:

index=folks
Computer="Abdullah.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
User="Abdullah-work\\Administrator"
earliest="05/10/2023:07:32:00" latest="05/10/2023:07:58:00"
| table _time User Image ParentImage CommandLine
        ProcessId ProcessGuid ParentProcessGuid LogonId IntegrityLevel
| sort 0 _time

The result tied LUID 0x257a387 to a high-integrity wsmprovhost.exe at 07:37:48:

index=folks
Computer="Abdullah.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
LogonId="0x257a387"
earliest="05/10/2023:07:37:40" latest="05/10/2023:07:40:00"
| table _time User Image ParentImage CommandLine
        ProcessId ProcessGuid ParentProcessGuid LogonId IntegrityLevel
| sort 0 _time

I then followed the WinRM host’s ProcessGuid, not its reusable PID:

index=folks
Computer="Abdullah.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
ParentProcessGuid="{fd11aacb-49cc-645b-da20-000000000a00}"
| table _time User Image ParentImage CommandLine
        ProcessId ProcessGuid ParentProcessGuid LogonId IntegrityLevel
| sort 0 _time

At 07:39:07, wsmprovhost.exe launched PING.EXE 192.168.159.1. This completed the proof chain for Abdullah:

Rubeus-created Administrator session on Client02
  → PowerShell connects to Abdullah:5985
  → Abdullah records a successful Administrator network logon
  → high-integrity wsmprovhost.exe starts in the matching LUID
  → wsmprovhost.exe launches PING.EXE

Ali had successful LDAP authentication but no comparable target-side execution evidence.

Continue Forward: Separate the Diamond Ticket Activity

After closing the Abdullah WinRM branch, I returned to the already identified Rubeus sample and continued forward from 07:57:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
earliest="05/10/2023:07:57:00" latest="05/10/2023:08:10:00"
(
  OriginalFileName="Rubeus.exe"
  OR Image="*\\Microsoft-Update.exe"
  OR Hashes="*471A515A58F5BF831D0AE9922BE70BFF69A026B27785E459D7B163FA1865B585*"
)
| table _time User Image OriginalFileName CommandLine ProcessId ProcessGuid
| sort 0 _time

At 08:03:18 and 08:03:43, Rubeus explicitly used its diamond action with /ticketuser:Administrator and /ptt. These commands targeted the child domain Abdullah.Ali.Alhakami and its DC Abdullah. They did not generate the parent-domain ticket asked for in the lab. They also used no /outfile option, so a .kirbi filename should not be expected from this branch.

The logs prove that the Diamond Ticket commands ran and requested ticket injection. They do not independently prove that a forged ticket was accepted. The named parent-domain ticket remains the separate trust-test2.kirbi artifact.

Lateral-movement assessment

• Client03 as Administrator: S4U produced HTTP/Client03. Client03 created high-integrity wsmprovhost.exe, which launched hostname.exe and whoami.exe. Remote execution is proven.
• Client03 as it-support: a Type-9 source session on Client02 led to Type-3 Kerberos logons and a WinRM connection. Target-side execution was not observed.
• Ali as Administrator: LDAP authentication succeeded. Forged parent-domain ticket files were later created on Client02, but acceptance and remote execution were not proven.
• Abdullah as Administrator: WinRM authentication and the wsmprovhost.exe → PING.EXE process tree prove remote execution.

Cross-Phase Finding: Defense Evasion Through Masquerading

The same naming pattern appeared across multiple stages:

• fun.exe had the embedded OriginalFileName=mimikatz.exe.
• Microsoft-Update.exe had the embedded OriginalFileName=Rubeus.exe.
• Better-to-trust.exe used Mimikatz-compatible kerberos::golden syntax under another benign-looking name.

The first two are direct filename-to-metadata mismatches and support Masquerading (T1036). The third is consistent with the same operator habit, but the displayed evidence does not include its embedded original filename. I therefore describe it as suspicious naming around Mimikatz-style behavior, not as a third confirmed metadata mismatch.

Cross-Phase Finding: Staging Infrastructure and Possible C2

The address 192.168.159.1 appeared at two meaningful points in the attack:

• At 05:07:32, elevated PowerShell on Client02 connected to 192.168.159.1:80. It created fun.exe shortly afterward, supporting the role of an HTTP payload server.
• At 07:39:07, the new Administrator WinRM session on Abdullah launched PING.EXE 192.168.159.1, proving a reachability check back to the same server after the DC was accessed.

This supports attacker-controlled staging infrastructure and a post-compromise connectivity check. It is compatible with Command and Control activity, but it does not prove a persistent C2 channel because the dataset does not show beaconing, command exchange, or application-layer response content.

The nearby 192.168.159.133 address has a different meaning. Sysmon recorded it as the source address of Client02’s PowerShell connection to Ali, not as another external controller. It shows that Client02 could communicate through the 192.168.159.0/24 segment. The shared subnet alone is not enough to classify the entire range as attacker infrastructure.

Domain Compromise: DCSync Attempt

The earlier Mimikatz hash pivot had exposed one launch with a full command line at 08:09:36. Returning to that bookmarked event produced the final branch:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=1
Image="C:\\Users\\HelpDesk\\fun.exe"
earliest="05/10/2023:08:09:30" latest="05/10/2023:08:09:45"
| table _time User Image OriginalFileName ParentImage CommandLine
        IntegrityLevel ProcessId ProcessGuid Hashes
| sort 0 _time

The matching event and full command line are visible in the earlier Mimikatz hash-pivot result. I link to that existing screenshot instead of duplicating it here.

Sysmon recorded the exact command:

"C:\Users\HelpDesk\fun.exe" "lsadump::dcsync /user:Abdullah-work\Administrator"

That command proves the attacker launched a DCSync request for the domain Administrator account. I followed the same ProcessGuid into Sysmon network events to confirm the request reached the domain controller:

index=folks
Computer="Client02.Abdullah.Ali.Alhakami"
Channel="Microsoft-Windows-Sysmon/Operational" EventCode=3
ProcessGuid="{e7c1085c-5140-645b-d906-000000000c00}"
| table _time User Image SourceIp SourcePort DestinationIp
        DestinationPort DestinationHostname Protocol ProcessGuid
| sort 0 _time

fun.exe connected from Client02 to Abdullah using RPC endpoint mapper port 135 and dynamic RPC port 49667, which is consistent with DRS replication traffic. The target then recorded successful HelpDesk authentication:

index=folks
Computer="Abdullah.Abdullah.Ali.Alhakami"
Channel="Security"
(EventCode=4624 OR EventCode=4776)
earliest="05/10/2023:08:09:30" latest="05/10/2023:08:10:00"
| table _time EventCode TargetUserName TargetDomainName LogonType
        AuthenticationPackageName IpAddress WorkstationName TargetLogonId
| sort 0 _time EventCode

At 08:09:36, Abdullah recorded a successful NTLM Type-3 logon for HelpDesk from 192.168.2.101 (CLIENT02). This correlates the Mimikatz command, network path, and target authentication.

I also searched for Event 4662 with the directory-replication GUIDs. No result was present, and the dataset contains no Mimikatz console output. My conclusion is deliberately bounded:

HelpDesk launched DCSync against Abdullah-work\Administrator, reached the DC over RPC, and authenticated successfully. The logs do not prove that the DC authorized the replication operation or returned the Administrator credential material.

Investigation Course Corrections

The final chain looks orderly because the pivots have now been reconstructed, but the hunt was not linear. These were the important corrections:

• The scenario brief arrived partway through the hunt. I started blind and scenario helped later, It redirected the investigation toward the unquoted service path and other named behaviors. I used those hints to choose searches, then required the returned events to prove or limit each claim.
• I followed the most obvious row before the earliest row. The first Event 4648 review pulled me toward it-support and Client03. Sorting the same results chronologically later recovered the earlier Mohammed branch and the correct Overpass-the-Hash key.
• A logon ID is local to the host that created it. Searching a Client02 LUID directly on a destination returned no results. The correct bridge was source account, target service, timestamp, and network endpoint. The destination then assigned its own LUID.
• A ProcessGuid is a process-tree key, not a cross-host session key. It was reliable for parent/child and network correlation on one host, but could not be carried from Client02 to Client03 or Abdullah.
• Successful authentication was not automatically remote execution. Client03’s it-support and Ali’s Administrator branches stopped at authentication because neither produced a target-side remote-process chain. Administrator on Client03 and Abdullah did produce wsmprovhost.exe children, so those branches reached execution.
• The known Rubeus filename was too narrow for the parent-domain ticket. The decisive program was Better-to-trust.exe. Expanding to all HelpDesk process creation after the Ali pivot exposed the kerberos::golden commands and trust-test2.kirbi.
• Missing Event 4662 limited the DCSync conclusion. The command, RPC connection, and successful DC authentication prove an attempt reached the target. They do not prove replication data was returned.

These were useful misses: each one clarified which identifiers can be joined safely and where the available telemetry stops supporting the story.

Final Incident Timeline

This is the attack sequence rather than a list of isolated hits. The connection column explains how each event advances the chain or opens a separate branch. Where the telemetry does not establish a causal handoff, I state that boundary instead of filling the gap with an assumption.

Lab Answers and Supporting Evidence

The answer table is intentionally an index, not a substitute for the investigation. Each link returns to the query and reasoning that established the answer, including the limits of what the telemetry could prove.