Sunday, June 30, 2019

Enable "Last Access" Time Updates

If you have been in the computer forensics field since the Windows XP days and before, then you probably already know that Windows had/has the ability to record a timestamp for all files and folders of when a user "last accessed" and opened for reading or writing.

For resource and performance improvements, in the NTFS filesystem, from Windows Vista to present the last access times for files and folders are not updated.

In one of his recent books, Investigating Windows Systems, Harlan Carvey mentions that:

"The version of Windows can impact our analysis...When files were accessed on Windows XP, the file system last accessed time was updated.  However, as of Windows Vista, this functionality was disabled by default, via a Registry value.
The value is named NtfsDisableLastAccessUpdate, and is found beneath the
HKLM\System\CurrentControlSet\Control\FileSystem key."

In his book, Mr. Carvey, goes into detailed reasons for the importance of timestamps and timelines in intrusion cases.  And following the above he mentions a real life story in his book how the last access time stamp was was helpful in leading him to find a malicious DLL that was loaded via search order hijacking based off last access times.

I just recently finished reading, Investigating Windows Systems, and do recommend it for those in the field of incident response.  Especially for sharpening the discipline that is walked through in the analysis process and in looking for key findings in the Windows environments.  It makes for a great read.


Link to Amazon

Carvey, H. (2018). Investigating Windows Systems. London: Academic Press, an imprint of Elsevier.


*Looking at some documentation, it was noted that the default key value for the NtfsDisableLastAccessUpdate key was updated in Windows 10 April 1803 edition to read
=dword:80000000 .  And in later versions can show as ending in 2 or 3, instead of just all zeros.

Taken from the Forensixchange blog:

"The NtfsDisableLastAccessUpdate registry key can be on the default value which is: dword:80000003. This value means: System Managed, the “Last Access” updates are disabled."

Below are 2 methods to change the value.
*NOTE enabling the registry key value may effect performance for read/writes on HD and SSD drives

1.  Using the Windows Registry Editor, Regedit, to change the below value.

This value is the default to disable the Last Access times.
Can end in "3" which is also default disabled.

Changing the value to read a "1" at the end will enable Last Access update times for NTFS.

Enabled by changing last digit to "1"


2.  Another method via an elevated admin command prompt

This disables the disable, then must reboot for changes to take place

Lastly, if the policy to update LastAccess times is in place:
A neat powershell command can be had to recursively list the file names and sort on last access times

gci -recurse . | select name,lastaccesstime,psparentpath |sort lastaccesstime
 *This can be ran from a target directory and outed to a text file to sort and see recently accessed items

These are sample malwares that I had on a test VM.  But this method can help to assist in getting sense of a timeline for last access.


Sunday, June 23, 2019

Capturing and Retrieving a Memory Image Remotely

In some instances, particularly intrusions cases or with enterprise security, it may be necessary to acquire memory from a remote system for DFIR analysis.

Many cases there are solutions for that purpose with forensics or endpoint security tools that have agents installed that allow for this.

However, came across an excellent Incident Response tricks and tools cheatsheet resource from:
"JPMinty" @

Specifically at ""

JPMinty mentions using psexec for a live ram capture on a remote windows pc.

The command is as follows:
psexec \\remotepcname -c RamCapture64.exe "output.mem"

So I set up two Windows 10 VMs with VMWare Workstation. And wanted to simulate a remote memory capture.  
* Note this is not necessarily a forensically sound method for imaging.  Because changes will be written to the remote machine.  However if a forensic/endpoint tool fail this may be a potential backup method.  

The machine on the left is the remote PC. And the right is the forensics host to launch psexec from.


Launching a cmd prompt with admin privileges.  
And run the following command : 

* PsExec64.exe <RemotePC> -u for username and -p for password -c <The Memory Capture tool> <output memory dump file>

Download of psexec can be found at: 

Running the PsExec with the RamCapture64.exe directly, returned an ERROR



The RamCapture64.exe download unzips with some dlls and a sys file in a folder called x64.

Will use the xcopy command.
To copy the x64 folder with the RamCapture64.exe in it to the target.

But FIRST...
With the following command had to mount a share to the target drive with the following command:
The net use command with mount a share and authenticating

SECOND is using the XCOPY command to copy the memory dump tool to the target's C$ drive.
The RamCapture tool has been copied to the target.  

NEXT to initiate a remote cmd session with PsExec on the target and run the tool
Now in a remote cmd prompt

*NOTE, can skip the remote command prompt method and use psexec to just run the ".\RamCapture64.exe"

READY to run RamCapture64.exe

Memory dump completed and is located on the C:\ root of the target

While we are here let's hash the memdump.mem file.  We can use the certutil command

MD5 for memory file = b8eafad7bf112f2d565093b611a8b52b

Can exit the remote cmd session

LASTLY we can use xcopy again to bring the memdump.mem back to the Forensic host
xcopy <DESTINATION\memdump.mem> <FORENSIC HOST>

The memdump.mem file copied

The Memory Capture "memdump.mem" is now on the Forensics Host with the same MD5 hash.

This method of using xcopy and psexec is kind of the long way around.  But is not too many steps to run.

----NEXT POST----

I will be attempting to extract a pcap from the same memory dump using the bulk extractor tool.

Happy forensicating


Friday, June 14, 2019

Windows PowerShell Transcription Logs

How to turn on PowerShell Transcription Logging:

From the Windows Local Group Policy Editor, details of policy:
At least Microsoft Windows 7 or Windows Server 2008 family.
"This policy setting lets you capture the input and output of Windows PowerShell commands into text-based transcripts.
If you enable this policy setting, Windows PowerShell will enable transcripting for Windows PowerShell, the Windows PowerShell ISE, and any other applications that leverage the Windows PowerShell engine. 

By default, Windows PowerShell will record transcript output to each users' My Documents directory, with a file name that includes 'PowerShell_transcript', along with the computer name and time started. 

Enabling this policy is equivalent to calling the Start-Transcript cmdlet on each Windows PowerShell session.

If you disable this policy setting, transcripting of PowerShell-based applications is disabled by default, although transcripting can still be enabled through the Start-Transcript cmdlet.
If you use the OutputDirectory setting to enable transcript logging to a shared location, be sure to limit access to that directory to prevent users  from viewing the transcripts of other users or computers.

Note: This policy setting exists under both Computer Configuration and User Configuration in the Group Policy Editor. The Computer Configuration policy setting takes precedence over the User Configuration policy setting."

1.  Windows key run --> gpedit.msc

2.   Navigate to: 
Computer Configuration – Administrative Templates – Windows Components –     Windows PowerShell and double-klick “Turn on PowerShell Transcription”.

Click on Enable and enter your preferred Output Directory. (include invocation headers will log the PS command start time)  

The transcript was manually picked to be at C:\PS_Transcripts.  Can output to anywhere, for instance a share server or log server.

3.  The transcript file will now be created in the selected output directory

Above is the PS transcript with the starttime, username, host, and scripts that was ran, with output


Saturday, June 8, 2019

DFIR GEAR: Forensicate in Style

Came across this cool site ( that has some neat shirts.
Shirts for Men, Women, and also sells posters.  That ship to the US.

My personal fav:
Kudos for the Wolverine reference
The site has written that "All proceeds go to Girls Who Code"  
"We’re building the largest pipeline of future
female engineers in the United States."

Which looks like a awesome cause.


Wednesday, June 5, 2019

Sticky Notes Location (part 2) - restoring from Volume Shadow Copies

Volume Shadow Copy (also known as Volume Snapshot Service or VSS ) is a technology included in Microsoft Windows. It allows the ability to take backup copies or snapshots of computer files or volumes whether in use or not. The process can be operated manually or automatically.

Can be used to view read only snapshot points in time.

How to turn on Volume Shadow Copies:

  1. Type restore in the windows search menu
  2. Select create restore point

     3.  Select Configure

4.  Turn on system protection

   5. Create is enabled as an option and name it





Opening a CMD prompt with admin privileges 

Typing "vssadmin list shadows"

Using the Shadow Copy Volume field for the make link command
Typing "mklink /d outputvolume \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\"  *including the trailing back slash at the end of the Shadow Copy Volume name

mklink command /d <source><destination>


Linked Volume is now there

PATHING TO THE "plum.sqlite" file related to Sticky Notes


Using DB Browser to view SQLITE file
dowload from site:

After copying the plite file to the another directory out of the mklinked directory, can open and view the deleted entry that was saved in the restored point shadow copy.

*Can also run strings on "plum.sqlite-wal" in the LocalState folder from the VS copy

strings .\plum.sqlite-wal