Sunday, August 11, 2019

CyLR — Live Response Collection tool

CyLR — Live Response Collection tool by Alan Orlikoski and Jason Yegge
Windows exe found at:


CyLR was first brought to my attention from the SANS "FOR500: Windows Forensic Analysis"
Used for collection and artifact processing.

This tool looks in:

Windows Default
  • System Level Artifacts
    • %SYSTEMROOT%\SchedLgU.Txt
    • %SYSTEMROOT%\Tasks
    • %SYSTEMROOT%\Prefetch
    • %SYSTEMROOT%\Appcompat\Programs
    • %SYSTEMROOT%\System32\drivers\etc\hosts
    • %SYSTEMROOT%\System32\winevt\logs
    • %SYSTEMROOT%\System32\Tasks
    • %SYSTEMROOT%\System32\LogFiles\W3SVC1
    • %SYSTEMROOT%\System32\config\"REGISTRY HIVES"
    • %SystemDrive%$Recycle.Bin
    • %SystemDrive%$LogFile
    • %SystemDrive%$MFT
  • Artifacts For All Users
    • {user.ProfilePath}\NTUSER.DAT and \AppData

*Among other places and other locations for linux and macOS shown on the github page

Simulating Collecting on Remote System

The above diagram simulates as an admin remoting into a Desktop, running CyLR and sending the results to a SFTP server for retrieval


Open Start menu.
Type Apps.
Click on Apps & features.
Under “Apps & features,” click the Manage optional features link. 
Apps & features settings.
Click the Add a feature button. Manage optional features on Windows 10.
Select the OpenSSH Server option.
Select Install

May need to start service 

 Control Panel > System and Security > Administrative Tools and open Services.
Start OpenSSH SSH Server service

May need to Set up Firewall exceptions
Allow incoming connections to SSH server in Windows Firewall:
  • Either run the following PowerShell command (Windows 8 and 2012 or newer only), as the Administrator: 
    New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH SSH Server' -Enabled True -DirectionInbound -Protocol TCP -Action Allow -LocalPort 22
  • or go to Control Panel > System and Security > Windows Firewall1 > Advanced Settings > Inbound Rules and add a new rule for port 22.

May need to generate a keypair
 In WinSCP can select advanced settings > Authenitcation > Tools Generate New Key Pair with PuTTYgen
Or can use OpenSSH-Win64 "ssh-keygen.exe"


$s = New-PSSession -Computername DESKTOP-REMOTE -Credential Win10
s$ is the variable.  For the creation of a powershell session to the remote host.  Ideally using admin credentials

Prompt for credentials

3. COPYING CyLR to remote host in session with powershell:

Copy-Item –Path C:\USERS\Win10\Desktop\CyLR_win-x64\CyLR.exe –Destination 'C:\' ToSession $s

Using the previously created "$s" session to copy to the C: drive of the target

4. Enter session with powershell:
Enter-PSSession -Session $s
5. Run CyLR and point to SFTP server's IP address:
C:\CyLR.exe -u SFTP_Server -p password -s
Using the parameter to point to the SFTP server.  *Not recommended to use "password" as password



5. Verifying results on the SFTP server

RESULTS include:


Contains "NTUSER.dat registry hive for each user

In conclusion:
I think CyLR is a neat tool and can potentially be used by a IR shop to collect relative artifacts.  May try it on a Mac and/or Linux host and see what it retrieves.

Also looking to try out Eric Zimmerman's KAPE(Kroll Artifact Parser and Extractor) tool to simulate a remote collection.



Sectechno. (2018, October 10). CyLR - Live Response Collection Tool. Retrieved from

Orlikoski. (2019, March 18). Orlikoski/CyLR. Retrieved from

Thursday, July 11, 2019

Extracting Pcap from a Memory Image

Continuing from ""
where memory was captured remotely with the Windows Sysinternal's tool, psexec.exe, and memory capture tool, dumpit.exe.

This post will test the net capture extractor feature of the bulk extractor tool against the previously created memory image "memdump.mem".

From bulk extractor found here:

The command that will be used is:

bulk_extractor64.exe -x all -e net -o test/ memdump.mem
This command uses the "-x all" to disable all scanners.  And the "-e net" for the net scanner option of the tool.

The "-o test/" signifies the directory to which to output the extracted net objects.

*As a note network connections related to a memory image are a great way to try and see what the machine was connected to at the time of the memory capture.
Using, the memory forensics tool, Volatility's netscan module, will provide insightful data regarding network connections at the time of the capture.  Including source and destination IP addresses, ports, protocols, and process ids (PIDs).

After running the above command the output of the bulk_extractor64.exe tool is located in the "test/" directory is as follows:
There now contains text files detailing network artifacts from the image

This being a memory capture from a Windows 10 machine, and with the bulk extractor open source from a few years back.  I tend to wonder if offsets and structure locations in memory have changed to where certain outputs may be effected by the net scanner.

However we do get a pcap, and can view in wireshark.
It is not a complete packet capture that one may get from a network sensor.  And timestamps are off.

Can select from the wireshark menu
Statistics --> Conversations

This will show IP address talking to each other, ports, and packet/byte numbers

We see a potential IP of interest:

Checking the reputation of the IP address on virus total we see a communicating file reported:

With a pretty high red reported malicious reputation:

And a description of Emotet Trojan

This is just a brief over view of a method to extract pcap from a memory image with the bulk extractor tool.  The goal would be to extract possible network indications from an image.  As previously noted the volatility suite is a great option for memory analysis.  But this may serve as a potential secondary method.


SANS Internet Storm Center. (2016). SANS ISC: Extracting pcap from memory - SANS Internet Storm Center
Retrieved from pcap from memory/20639/

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