Recovering Cleared Browser History - Chrome Forensics

 


Hello naughty sysadmin... I've been watching your search history this Summer O_o

How do you detect when a user deletes their chrome history and is there a way to forensically recover it? The answer is… it depends. ðŸ˜ˆ

A good indicator for recovering what a user was doing when they deleted their chrome browser history is by checking inside the C:\Users\<name>\AppData\Local\Google\Chrome\User Data\Default\Sessions folder. The two files you need to look at are named:

  • Session_<Webkit/Chrome date>
  • Tabs_<Webkit/Chrome date>

The session file stores session information and the tabs file stores what tabs they had opened. In a certain situation when a user CLEARS their Chrome history, what they were browsing can persist within these files. 

There are a few potential cases that could have occurred, and we will go through all of them:

  • A user cleared their history and did not use Chrome since
  • A user clears their history and re-opened ONE new session
  • A user clears their history and re-opened several sessions since

Scenario 1: User cleared their history and did not use Chrome since
When a user clears their Chrome history (by all time or even by the last hour) and has not opened Chrome since, everything they were looking at during the session is STILL STORED inside the session files. This is great news because the session file is dated with the exact Webkit/Chrome timestamp in the name of the file. Why is this the case? I don't work for Google so I have nfi. 

In this instance the files I’m looking at were named:

  • Session_13311227045752079
  • Tabs_13311227047407569

Using this time converter (https://www.epochconverter.com/webkit), you can see the time when the user “exited” the session was at 2022-10-26T03:04:05Z. You can see a full timeline of what the user did by viewing the contents of the file. Please note there are no corresponding “timestamps” captured within this file unfortunately. This is what the file looks like:



Does this look like a flipping mess? Yes. I know, but it's actually well structured and I'll show you what it looks like in a timeline output. This is a full timeline of what our strange sysadmin was looking at:


In the case of this user, they were searching “Naruto Feet Pics” UwU and this is what they were looking at. They opened a Google search for “Naruto feet pics” and then this image is what they proceeded to “click”. The image source is https://www.deviantart.com/tag/temaritoes. 



Scenario 2: A user clears their history and re-opened ONE new session
Firstly, how do you even know they did this? Let your girl help you out. In this instance two session files and tab files will exist in the directory!


Now one of these sessions will correspond to the previously “deleted” files 
This is sadge days T_T, because the actual content of the “cleared” session will be deleted other than evidence that the history was cleared. The only data you can go off from this is:
  • Session cleared date you pull from the session Webkit/Chrome epoch name 

You have some other options like considering pulling from Volume Shadow Copies or looking at Chrome crash dumps (if any). But the data itself appears to be nulled in these files. 


Scenario 3: A user clears their history and re-opened several sessions since
This is GG for us forensically. Previously, the Favicons file would store potentially “cleared” websites a user visited. But I found this to be very inconsistent and not in line with the results I got during my testing:
  • C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Favicons
The only location I found consistently referencing “deleted” search terms was inside this file:
  • C:\Users\<name>\AppData\Local\Google\Chrome\User Data\Default optimization_guide_prediction_model_downloads/b0b608bd-983f-4cf9-aee4-99fc96c39371/global-entities_metadata
It appears that when you “search” certain terms, Google tries to optimise your searches and stores some of this data inside here. Unfortunately, it also stores a whole lot of other nonsensical uninteresting things, so I’m not sure this is a good forensic artefact.

goodbye & thank u for your time! <3

Comments

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988  
Read more

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more