Windows Endpoint Forensics Investigation

Two workstation images and a wider incident

This was a collaborative Windows forensics investigation completed with Jordan Kimball for Champlain College coursework. We were given two E01 images from separate Windows 10 workstations in a fictional corporate domain and asked to determine what had happened, how the activity moved between systems, and what evidence should be acquired next.

The supplied scenario pointed towards a compromised privileged account and possible misuse by an internal user. The two images did not contain the whole incident. A domain controller and another workstation appeared repeatedly in the artefacts, but neither was available for examination. That made scope control part of the work: we could state what the two images supported, identify the systems that probably held further evidence, and avoid presenting unexamined hosts as confirmed facts.

Jordan and I divided the examination and combined our findings into one report. The investigation covered:

• basic evidence and system identification
• user profiles and installed applications
• executable and script activity
• persistence artefacts
• local and remote logons
• network shares and file access
• possible credential collection
• indications of data staging or exfiltration

Establishing the evidence baseline

I started with the supplied E01 metadata and NTFS information in FTK Imager. The report recorded the image hashes, acquisition dates, disk and volume sizes, and serial information before moving into interpretation. These details gave us a stable reference for each workstation and separated evidence facts from later conclusions.

Evidence	SHA-1	Disk / volume	Acquisition
prog-wks03.e01	ab646bc506457ba80fafd3c8fee7b7203492639a	26,843,545,600-byte disk; 26,197,622,784-byte basic-data volume; serial 8CB6-8B7D	30 March 2019, 22:58:21
it-wks01.E01	ae576547f34c9a80dbdca1345901ed9a2e2e5a53	26.83 GB disk; 24.3 GB volume; serial E2BE-578D	29 March 2019, 20:12:31

The metadata named ADI 4.2.0.13 as the acquisition program. One image named an examiner and the other did not. We recorded that difference rather than filling the missing field from assumption.

Time handling needed the same care. Registry data showed that both workstations were configured for Eastern Daylight Time, while the final timeline was normalised and labelled consistently. Without that step, activity from event logs, prefetch, shellbags, link files, and mounted shares could appear out of order.

The SOFTWARE and SYSTEM registry hives provided the basic host profiles. I used them to identify:

• Windows edition and build information
• registered user details
• installation or update timestamps
• configured time zone
• network interface history
• previous DHCP-assigned addresses
• DNS and domain configuration
• profile SIDs and local or domain account presence

Some values had to be treated cautiously. For example, the recorded DHCP lease date was implausible, so it was documented as an unreliable artefact rather than forced into the timeline.

The resulting system picture was:

Host	Operating system	Last recorded address	Domain and DNS
PROG-WKS03	Windows 10 Pro Education 1709	192.168.4.103 on 192.168.4.0/24	grru.local, DNS at 192.168.1.254
IT-WKS01	Windows 10 Pro Education 1709	192.168.1.101 on 192.168.1.0/24	grru.local, DNS at 192.168.1.254

Both addresses were DHCP-assigned. The registry presented a lease start in the year 19270 with an eight-day lease, which was plainly unusable as a real timestamp. The current IP and DNS values remained relevant, while the corrupt or misinterpreted date was excluded from temporal reasoning.

The profile list also established who had used each machine. PROG-WKS03 contained the local TestLocal account and domain profiles for roger.melton and james.middleton-adm. IT-WKS01 contained a local Admin account and domain profiles for james.middleton and james.middleton-adm. Profile creation times provided context, but a profile’s existence did not prove who was operating it at a later point.

One USB device had been assigned a drive letter before the incident period. We found no temporal or content relationship between it and the indicators of compromise, so it was recorded as examined and not carried into the incident theory.

Execution traces across the registry and file system

The next stage was to identify applications and scripts associated with the suspected activity. Magnet AXIOM, Registry Explorer, and Eric Zimmerman’s PECmd helped correlate several different Windows artefact types.

Prefetch showed execution of password-recovery utilities on one workstation and repeated use of cscript.exe on both systems. Prefetch supplied approximate first-run and last-run times, run counts, and executable paths. ShimCache entries independently showed that the credential-recovery tools had existed and been executed on the IT workstation.

On IT-WKS01, PasswordFox.exe and ChromePass.exe each appeared in execution-related artefacts. PasswordFox.exe was associated with 4 March 2019, while ChromePass.exe was associated with 28 March around 18:59. On PROG-WKS03, FTK Imager first ran on 29 March and last ran immediately before acquisition on 30 March; cscript.exe was associated with activity from 28 to 30 March.

The source times contain small inconsistencies, including first-run values that appear a few seconds after a stated last-run value. Rather than deriving a false second-by-second sequence, we used them to establish the broader execution window and relied on event, link, and shellbag timestamps for correlation.

Neither artefact was enough on its own. Prefetch is strong execution evidence, but it does not explain user intent. ShimCache records programme presence and execution-related state differently depending on the Windows version. I used the overlap between those artefacts, event logs, recent-item records, and network-share paths to build the account of activity.

The suspicious script was named UxTxlQwzP.vbs and launched through cscript.exe from a share hosted on the domain controller AD01. A Run value beneath Software\Microsoft\Windows\CurrentVersion\Run referenced the same script and interpreter combination, indicating that it had been configured to execute at logon for persistence. Sysmon process-creation records from Microsoft-Windows-Sysmon/Operational.evtx then linked:

• the user context active on the workstation
• the privileged domain account used to access the share
• the script interpreter
• the script path on the domain controller

That correlation was more useful than any single filename. It connected an account, a host, a network location, an execution method, and a persistence mechanism within the same period.

The key Sysmon event was recorded on PROG-WKS03 at 13:32:14 on 28 March 2019. It showed activity in the roger.melton user context, access involving the james.middleton-adm profile on AD01, and the same script-and-interpreter command found in the autorun entry. Within the supplied evidence, this was the strongest link between the ordinary workstation user, the compromised privileged account, and the persistent script.

Reconstructing share access

Windows keeps several traces of folders and files opened through Explorer. The investigation used shellbags, recent-document records, mapped-drive entries, and LNK files to reconstruct access to network resources.

On the IT workstation, a link file and shellbag entries referred to:

\\AD01\Users\james.middleton-adm\Desktop\machine_software

That directory contained the password-recovery utilities. machine_software.lnk was created at 18:56:30 on 28 March, and the relevant shellbag was added at 18:58:42. The path also appeared in RecentDocs and aligned with the ChromePass.exe prefetch period. The same directory was therefore represented as a recently opened item, an Explorer navigation artefact, and the execution source of a relevant program.

On the programming workstation, the affected privileged profile contained a mapped drive pointing to a separate lab host. Shellbags recorded access to a directory intended for memory dumps. AXIOM also exposed the mounted-share information from the user’s NTUSER.DAT hive.

The james.middleton-adm hive showed drive Z: mapped to TEST-MACHINE at 192.168.1.100. AXIOM recorded the share as accessed at 22:34:01 on 30 March. Shellbags in UsrClass.dat showed navigation to:

My Network Places:\TEST-MACHINE\Memdumps\prog-wks03\

at 22:25:58, shortly before the E01 acquisition. FTK Imager had also been used on PROG-WKS03 in the same period. Together those artefacts supported the interpretation that a memory image or related data was prepared for the remote share.

The available material also referred to an ad01.txt file containing NTLM-hash output, Firefox profile data, a Gmail password, and cookies on the share. Those observations came from the scenario evidence and share artefacts, not from an acquired TEST-MACHINE image.

The evidence indicated that workstation and credential data had been staged or copied through that share. It did not prove every transfer byte-for-byte because the destination image and network captures were not supplied. We therefore described this as an indication of exfiltration and recommended acquiring the destination host.

Building the logon timeline

I extracted Security.evtx from both images and parsed the records with WinLogOnView. The resulting tables made it easier to compare:

• account and domain
• logon and logoff time
• source address
• logon type
• session duration

I filtered the records to isolate remote sessions and then cross-checked the results against AXIOM. Earlier sessions from the domain controller were consistent with normal domain activity, while later privileged sessions occurred during the same period as the script execution, share access, and suspicious utilities.

The principal remote events were:

Host	Account	Time	Source	Type	Interpretation
PROG-WKS03	roger.melton	26 January, 23:55	192.168.1.254	Initial / service records	Before identified compromise activity
PROG-WKS03	james.middleton-adm	28 March, 18:35	192.168.1.254	Remote Interactive (10)	During the suspicious activity window
PROG-WKS03	james.middleton-adm	28 March, 21:35	192.168.1.254	Unlock (7)	During the suspicious activity window
IT-WKS01	james.middleton-adm	28 March, 18:55	192.168.1.254	Unlock (7)	Immediately before share and tool artefacts

IT-WKS01 also contained an unlock from 192.168.3.103 on 23 February. We found no associated malicious activity and did not group it with the 28 March sequence. This was another reminder that a non-local source address and a privileged account are not sufficient to label an event malicious.

This distinction prevented every remote logon from being labelled malicious. Domain controllers legitimately authenticate users and support administrative activity. The evidential value came from timing, account context, source host, associated process creation, and what happened immediately before and after the session.

The later sessions supported the working theory that the domain controller had already been compromised and was being used to move into the two supplied workstations. Because the domain-controller image was absent, this remained a scoped conclusion rather than a complete reconstruction of the initial compromise.

Credential access and persistence

The combined artefacts suggested that domain credentials had been collected and that a privileged account had then been used across the environment. The supplied scenario included traces consistent with an NTLM hash dump on the domain controller, while the workstation images contained:

• password-recovery utilities executed from a remote share
• privileged remote logons
• a script-based autorun entry
• the same script path in Sysmon process events
• access to directories containing credential and browser-profile material

Our working sequence was:

privileged account material obtained on AD01
  -> AD01 used as the source of later remote sessions
  -> VBS autorun placed or executed on both workstations
  -> password-recovery tools opened from the AD01 share
  -> FTK Imager used on PROG-WKS03
  -> TEST-MACHINE share accessed for memory-dump staging

The first step could not be independently reconstructed without AD01. The later workstation steps were supported by combinations of event logs, prefetch, registry values, link files, shellbags, and mapped-drive state. Keeping those levels of confidence separate prevented the scenario narrative from replacing the actual image evidence.

The evidence also showed why naming a single “malicious file” would have been incomplete. The activity depended on ordinary Windows components, domain authentication, file shares, registry autoruns, and administrative access. Those are legitimate mechanisms that become suspicious when their sequence and context do not match expected behaviour.

Findings and next investigative steps

Our report concluded that the two workstations were part of a wider domain incident. The strongest findings were the correlation between the compromised privileged account, remote sessions from the domain controller, script execution from a shared path, registry persistence, credential-recovery tools, and access to a separate host used for data staging.

We recommended extending the investigation to the domain controller and the destination workstation identified in the mounted-share artefacts. Those systems could answer questions the two supplied images could not:

• where the privileged credentials were first obtained
• whether other domain accounts or systems were affected
• what the remote script contained
• which files reached the staging host
• whether the activity continued elsewhere in the domain

For AD01, the priority evidence would include Security and Sysmon logs, PowerShell and script logging, the referenced share and VBS file, domain-controller authentication records, account-management events, remote-service artefacts, and any credential-dump output. For TEST-MACHINE, the priorities would be the Memdumps share, file-system metadata, share-access auditing, memory-image contents, browser-profile material, and evidence of further transfer.

The response recommendations included resetting all affected domain credentials because NTLM material was reportedly exposed, auditing james.middleton-adm activity after 27 March, reviewing remote-access logs across the domain, preserving both additional systems, and opening an insider-threat investigation around roger.melton within the fictional scenario.

What I developed through the investigation

This investigation moved beyond finding isolated artefacts. I had to combine registry state, executable traces, user activity, event logs, and network-share history into a timeline that could survive scrutiny.

It also reinforced several practical forensic habits:

• verify evidence and time context before interpreting activity
• use independent artefact families to support a conclusion
• distinguish execution evidence from intent
• separate confirmed findings from reasonable investigative leads
• document gaps created by missing systems
• turn technical findings into acquisition and response priorities

The work was completed against supplied university evidence from an older Windows environment. Tool behaviour, Windows artefacts, and enterprise logging have evolved, but the correlation method remains directly applicable to endpoint investigations.