Chapter 9: Internet Artifacts & Browser Forensics

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement, not replace, the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

The internet, it's so woven into everything we do now, isn't it?

Work, communication, learning,

everything.

It really is.

And all that activity, it leaves behind this massive trail.

Digital breadcrumbs, you could say.

Exactly.

And today, we're diving deep into those internet artifacts, the traces left behind by just using the web.

Our mission, really, is to get a handle on how digital forensic investigators uncover these artifacts.

We're talking browsers, social media, P2P sharing, even cloud stuff.

Yeah.

And it's not just about what gets left behind, right?

It's the why.

And crucially, how it can be used in an investigation.

That's key.

Totally.

And we're drawing this from a pretty comprehensive chapter that really maps out this whole digital terrain, covers everything from browser history, like you said, all the way to cloud storage evidence.

Yeah.

Lots to unpack.

Definitely.

Let's get started.

Where do we begin?

Browsers seem like the obvious gateway.

They are.

They're our main window to the internet.

And, you know, all the personalization, the security features, they're great for users, obviously.

But they make investigations trickier.

They certainly can add layers of complexity, yeah.

Different browsers store things differently, encrypt things differently.

So thinking about an investigator approaching a system,

what are they most likely running into, browser -wise?

Well, based on data from, let's see, around mid -2019,

Google Chrome was the big one.

About 55 % market share.

Wow, yeah, that's dominant.

Then you had Safari, maybe 12%, i .e.

and the early versions of Edge together around 8%.

And Firefox, about 6%.

So that gives you a pretty good idea where most investigations will start.

Chrome.

Feels like the default for so many people.

Let's dig into Chrome first, then.

What kind of breadcrumbs does it leave?

Oh, Chrome leaves a lot.

Bookmarks are a good starting point.

You know, the links people save.

Right.

They're saved places online.

Exactly.

They're stored in a file just called Bookmarks.

No extension.

It's buried deep in the user's app data folder under Google Chrome user data default.

And this file, what's special about it?

It's a JSON file.

JSON,

JavaScript Object Notation.

It's basically a text -based format, pretty readable, designed for data exchange.

And inside, you find details for each bookmark, like when it was added, its name, the actual URL, even if it was last visited on the desktop.

But reading raw JSON,

it can look a bit chaotic, right?

Just lots of brackets and quotes.

It absolutely can.

That's why investigators lean on tools.

Something like Notepad++ with the JSON Viewer plugin makes a huge difference.

How so?

It shows the structure visually.

You can see the folders, like the bookmark bar, that's the stuff you see at the top of the browser, then other, synced.

Ah, so you can see how they organize things.

Precisely.

You might see numbered folders that then contain named folders, like news or work.

It shows intent organization.

And the timestamps.

When was something bookmarked?

Also in there.

But Chrome uses its own format.

It's often called Google Chrome Value.

It's not immediately obvious what date it represents.

So you decode that.

Specialized tools again.

Yep.

There's a great open source one called Decode.

You feed it the Chrome timestamp value, and it spits out a standard human readable date and time, UTC, usually.

Got it.

So you can see, this new site was bookmarked April 16, 2016, at 3 .30 a .m.

UTC.

Exactly that level of detail.

But, okay, just bookmarking something doesn't mean you actually went there, right?

Yeah.

I bookmark stuff all the time.

I mean, to read later.

That's a really critical point.

A bookmark shows interest, maybe intent.

It doesn't prove a visit.

So where do you look for proof of actual visits?

For that, you need the history file.

Also in that Chrome user data area, also no extension.

But this one's a Squilite database.

Squilite.

That's a common database format, right?

Very common.

And most forensic tools handle Squilite really well.

This history database is packed with information.

Like what, specifically?

Downloads file path, where it came from, start and stop times, file size,

keyword searches typed into the address bar, specific URLs the user typed, and of course, the main browsing history URLs visited.

How many times?

Date, time.

Wow.

Okay.

So you can really build a timeline of what someone was doing online.

You often can, yeah.

For instance, you might see a record for a Thunderbird setup, 16 .0 .exe, being downloaded to the downloads folder between say 16 .14 .38 and 16 .14 UTC.

Then you might see searches like Gmail on one day and maybe Thunderbird the next.

Suggesting they were looking for email options.

Could be.

And if you look at the browsing history around that time, you might see visits to webmail login pages before the Thunderbird search, hinting they might have multiple email addresses they were managing or considering consolidating.

That detail really connects the dots.

What else is Chrome track that's useful?

Cookies.

Definitely cookies.

Little text files, websites drop on your machine.

To remember logins, shopping carts, that kind of thing.

Exactly.

Tracking your activity on their site.

Chrome stores these in another Squalite database, just called Cookies, in that same default folder.

And how do they help in investigation?

They show interaction with specific sites.

But like bookmarks, you need context.

A cookie's presence doesn't automatically mean the user deliberately visited the site it could from an ad or embedded content.

So you need supporting evidence.

Usually, yeah.

Corroborate it with history.

And again, reading raw Squalite isn't fun.

Tools like Niersoft's Chrome Cookies view are great for formatting it clearly and converting those timestamps to UTC.

Makes sense.

What about the cache that hidden stuff browsers keep to speed things up?

The cache, yeah.

It holds copies of website elements, images, code, etc.

In its raw state, it's pretty tough to make sense of.

But there are tools for that too.

Oh, yes.

Chrome Cache View, another Niersoft tool, is excellent.

It pulls out the file name, the original URL it came from, content type, size, last access time.

Anything else significant?

Server time, sometimes.

And crucially, the server's IP address.

Oh.

So if you find, say, illicit images in the cache.

That IP address could potentially lead you back to the original server hosting that content.

It's a potential lead.

You might see an entry for, like, gmail .html showing when it was cached and the Google server IP it came from.

Okay, that's powerful.

And lastly for Chrome, saved passwords.

Convenient, but maybe a bit risky.

Definitely convenient.

Chrome stores this info in the logon data file surprise.

It's another Squalite database in the default folder.

Are the passwords just sitting there in plain text?

Please say no.

No, they're encrypted.

But the logon data file holds the necessary information for decryption.

So investigators need another tool.

And legal authority, presumably.

Absolutely need the legal authority.

And yes, utilities like ChromePass can decrypt those credentials if you have the necessary access to the user system or profile.

Right.

Okay, that's a good look at Chrome.

Let's shift to Microsoft Internet Explorer and Edge.

Now the new Edge is Chromium based, like Chrome, right?

Exactly.

Modern Edge behaves very similarly to Chrome.

Same kinds of files, JSON bookmarks, Squalite history and cookies.

Just in slightly different locations under the Microsoft Edge user data path.

So we're mainly talking about the older legacy versions of IE and maybe the first version of Edge.

Yes, their approach was quite different.

How were their bookmarks handled?

Instead of one big JSON file, IE saved each bookmark as a separate file with a URL extension.

These were typically stored in the user's favorites folder.

Any advantage to that for forensics?

Well, they're simple text files, essentially.

So pretty much any forensic tool can read them easily.

And the file's own timestamps created, modified, can be significant evidence in themselves.

And inside the URL file?

Just the web address, usually.

Plain and simple.

Finding a URL pointing to a questionable site is a pretty direct link.

Gotcha.

What about history in legacy IE Edge?

IE defaulted to keeping history for 20 days.

And interestingly, it sometimes tracked other OS activity too, not just web stuff.

For IE 10 and later in the original Edge, the main action happens in a file called webcachev01 .dat.

It's an ESE database.

ESE.

Another database format to know.

Extensible storage engine.

Microsoft uses it a lot.

Tools like Ease a Database View can parse it.

Inside, you look for the containers table, and specifically other tables usually named, starting with MSS followed by numbers 12, 14, 15, 16 are common.

MSed.

Does the name tell you anything?

It often indicates the time period covered.

Some might be daily history logs, others weekly.

And what kind of info is in there?

Still web visits.

Web visits, yes, but also potentially other things.

Table 12, for example, might show activity like accessing files in the downloads folder via File Explorer.

Okay, that's interesting.

Timestamps.

Yes, but they're in a specific Windows format.

It looks like a long decimal number, but it's actually a conversion of a 64 -bit hexadecimal Windows file time.

Big Indian, usually.

Sound like you need to convert that too.

You do.

Convert the decimal to hex, then use a tool like Decode again to get the readable date and time.

Is there a catch with IE history?

One big one.

It can sometimes contain entries from pop -ups or ads that the user didn't actually click on or navigate to directly.

So context is important.

Right, not every entry is a deliberate action.

Is there a way to see just what the user typed into the address bar?

Yes, that's stored separately in the user's registry, specifically the NTUSER .dat file.

Under the key, Software Microsoft Internet Explorer typed URLs.

And tools can pull that out.

Regripper is a classic tool for registry analysis, and it extracts these type URLs easily.

It shows a list, usually up to 50 in IE 10 plus A, with the most recently typed URL at the top.

Typing it again just moves it up the list.

Is there a timestamp for those?

There is.

A corresponding key, typed URLs time, stores the date time each was entered, again in that hexadecimal Windows file time format.

And cache for iOldEdge, back in that webcache file.

Primarily handled by webcache v01 .dat, yes.

But again, dedicated tools like Internet Explorer Cache Viewer can provide a friendlier view, showing filenames, URLs, timestamps.

The actual cache files live in different locations depending on the Windows version, often in subdirectories with random looking games.

And cookies in the IE world.

They were mostly saved as individual text files, but the webcache v01 .dat file also tracks cookie information, usually in Table 5 with those decimal hex Windows timestamps.

So you have the text files and a database record.

Kind of.

The actual cookie files are in specific folders, different for IE and Edge, often with random alphanumeric filenames.

You usually need to correlate the info from the text file with the entries in webcache v01 .dat to get the full picture, like which website the cookie belongs to.

They're supporting evidence, usually not conclusive on their own.

Right.

Builds the picture.

Okay, let's round out the browsers with Firefox.

How does it handle things differently?

Firefox has a key feature, profiles.

Users can create separate profiles to keep browsing activities completely segregated, like one for work, one for personal.

Where are these profiles stored?

In the user's appdata local Mozilla Firefox profiles directory.

How do you know which profile is which, or if there are multiple?

The folder names are usually a random string of eight characters, then a dot, then the profile name, like .default or .username.

Plus, there's a crucial file called profiles .ini in the roaming appdata folder for Firefox.

And what does profiles .ini tell you?

It lists all the profiles that exist, the path to each one, and importantly, which profile is the default or was the last one used.

So an investigator needs to check that file first to know which profile folder to examine.

Absolutely.

All the important data history, cookies, cache, passwords is stored within each profiles folder.

Got it.

So within a profile, where's the cache?

It's in a subfolder called cache2.

You typically use a tool like mzcacheview, another in your SOC utility, to analyze it.

Results are similar to what you get from other browser cache viewers.

Cookies.

Firefox uses a single Squealite database for cookies named cookies .sqlite.

It's located in the roaming profile folder.

mzcookiesview or any standard Squealite browser can read it.

History and typed URLs, together or separate?

Together, mostly.

In another Squealite database called places .sqlite, also in the roaming profile folder.

This tracks both browsing history and URLs typed into the address bar.

Tool for that.

mzhistoryview works well.

You can see the list of visits, searches, typed URLs.

And these files can get huge, potentially thousands of entries.

Okay.

Passwords and Firefox.

Encrypted, I assume.

Yes.

They're stored across a couple of files in the roaming profile folder.

One or more keycheck .db files, like key3 .db or key4 .db, depending on the version, which hold the encryption keys.

And logins .json, which holds the actual encrypted login data.

Encryption possible.

With the right tools and access, yes.

PasswordFox is designed for this.

It can show the website, username, the stored password, usually masked, and also timestamps for when the password was created, last changed, and last used.

Useful details.

And finally, Firefox Bookmarks.

Also stored in a Squealite database within the roaming profile folder.

The tool FavoritesVue can parse this, showing the default Firefox Bookmarks plus any that the user added themselves.

All right.

That covers the major browsers pretty thoroughly.

Let's switch gears to something huge in digital life.

Social media.

Yeah.

Absolutely massive.

And honestly, it's pretty rare these days for an investigation not to touch on social media in some way.

Because the trails can lead to what?

Location?

Communications.

Both and more.

Who they talk to, what they're interested in, sometimes even where they were when they posted something.

But the big challenge here is that most of the data isn't actually on the user's phone or computer, right?

Exactly.

The vast majority of it posts messages, connections, logs, lives on the service provider's servers.

It's in the cloud.

Which means getting access involves lawyers and paperwork.

Pretty much.

You need the right judicial paperwork warrants, subpoenas, court orders directed at the specific provider, and you have to meet their requirements, which can vary depending on where they and you are located.

So how does an investigator even figure out if a person uses a specific platform like Facebook or Twitter to begin with?

Browser history is a good start.

Look for visits to Facebook .com, Twitter .com, etc.

Also check their email.

Users often get notifications or password reset emails from these services.

Okay, let's take Facebook.

Even if the main data is server -side, are there any local clues?

Sometimes.

Browser artifacts might reveal the username, or even better, the unique Facebook user ID.

How would you find that?

If you find Facebook URLs in the history or cache, look closely at them.

Sometimes you'll see a parameter like profile ID, followed by a long string of numbers.

And that number is the user ID?

Often, yes.

If you take that number and just put it after Facebook .com, it'll usually redirect right to their profile page, confirming the ID and revealing the associated username.

And that ID is what you need for the legal request?

Exactly.

It's the unique identifier Facebook uses.

Also, tools like Bulk Extractor, which scan raw data, can sometimes pull these profile IDs out of a forensic image or even a memory capture.

Interesting.

What about Twitter or X?

Similar story.

Similar concept.

Bulk Extractor might flag Twitter domain access.

Twitter users have a handle like at username, which they can change, but they also have a permanent numeric user ID or UI ID.

Can you find that UI ID locally?

Sometimes searching the forensic image for the term twid might uncover it in web data remnants.

Alternatively, there are websites like gettwitterrid .com, where you can enter a known Twitter handle.

And it gives you the UI ID?

Yeah, it queries Twitter and returns the UI ID and potentially the user's display name if they've set one publicly.

Again, that UI ID is gold for legal process.

So getting these unique IDs seems like step one for dealing with providers.

It's definitely a crucial step because the providers are the ones holding the really information subscriber details like name and address, account creation info, login times, IP addresses used, and of course, all the user generated content like posts and messages.

And accessing that always requires the legal paperwork.

Always.

Resources like search .org actually maintain lists of service providers and their legal department contact info, which is super helpful for law enforcement.

Some providers like Kik, for example, even have dedicated pages on their websites explaining their process for law enforcement requests.

What happens once the provider sends the data?

Is it easy to analyze?

It varies.

Sometimes it requires specialized third -party forensic tools designed for specific platforms.

Other times it might involve manual analysis, maybe even digging into hexadecimal data.

And a big factor is data retention providers don't keep data forever.

So how long ago the activity occurred matters.

Right.

Their policies dictate how far back the data goes.

Okay, let's move to another area often linked with investigations.

P2P file sharing.

Peer to peer.

Yeah, this allows users to share files directly between their computers without a central server acting as a middleman.

Used for legitimate stuff, but also left legitimate things.

Exactly.

It's great for sharing large open source software or public domain files, but it's also notoriously used for distributing copyrighted material or illicit content like CSAM.

How does it work, technically?

A user installs a P2P application, designates files or folders they want to share.

The app creates an index of these files.

When someone searches for a file, the app finds other users, peers on the network who have it, connects directly to them, and downloads the file often in small pieces from multiple sources it wants to speed things up.

And how does the application keep track of these files across the network?

It usually records the file name, type, and calculates a unique fingerprint, a hash value, typically SHA1.

But here's a quirk.

Many P2P apps use base 32 encoding for that hash, while forensic tools usually display hashes in base 16 or hexadecimal.

So you need to convert between the two?

Often, yes, if you want to compare a hash found in P2P logs with a hash calculated by your forensic tools.

There's Python code available, actually, to do that conversion.

What artifacts does P2P leave on the user's actual computer?

It really depends on the specific P2P program, the OS, and user settings.

But there are common patterns and files investigators look for.

Okay, let's take an example.

Ayers Galaxy.

Ayers is an open source P2P client.

It usually creates a profile folder under app data local Ayers.

Inside a data subholder, there are key files, often share h .net and sharel .dat.

And they track?

Shared files.

File name, hash, download timestamps, sharing status.

They might be encrypted, but tools like Magnet AXIM can often decrypt them.

Ayers also leaves traces in the NTUSCR .dat registry file.

What kind of registry traces?

Things like the last connection time, the user's nickname on the network, language setting, maybe an away message, and importantly,

often the last 2025 search terms the user entered into Aries.

Regripper can pull this out.

Okay, what about another popular one, Emule?

Emule, also open source, was a big one, often used with the E -Donkey network.

When you install it, it typically creates an Emule folder inside your downloads with incoming and temp subfolders.

For completed and in -progress downloads.

Exactly.

And crucially, these folders are usually shared by default, and it's not straightforward to stop sharing them.

Where are its config files?

Usually in Appnata local meal config.

There, you'll find preferences that ENI has the user's nickname, confirms the incoming temp folder locations.

Shareddir .dat lists any other folders the user explicitly chose to share.

Shared files, not dat lists files currently being shared.

Anything else important in there?

Preferences .dat contains a unique 16 -byte user ID and hex.

ACSearchStrings .dat holds the last 30 search terms, and maybe the most valuable is known .met.

Known .met, what's in that?

It's a log of files the user has downloaded and shared.

Even if the files themselves are deleted, the record might still be here, potentially with revealing file names.

It includes file size, timestamps related to sharing, and the file hash.

There are specific tools, like Emule Met Viewer, to parse this file.

Got it, one more P2P app.

Sharaza, what about its artifacts?

Sharaza, another open source client.

It creates folders in both local and roaming app data under Sharaza.

You'll find subfolders like incomplete, collections, data, torrents.

Keyfile.

Dataprofile .xml might contain user entered info and other artifacts.

The NTUSER .dat registry key, SoftwareSharaza, is also important.

It has subkeys detailing download paths and, again, user search history.

And then data library 1 .dat, and its backup library 2 .data, lists shared folders, shared files, and partially downloaded files.

Okay, that covers P2P well.

Now, let's zoom out to the really big picture technology that underpins so much of this cloud computing.

Right.

Fundamentally, it's about using remote infrastructure servers, storage, software accessed over the internet, instead of running everything locally.

Huge for businesses, huge for individuals now, too.

It's more than just storing files online, isn't it?

There are different models.

Definitely.

You have IS infrastructure as a service.

That's like renting raw computing hardware remotely.

You pay for what you use.

Yeah, okay.

Then software as a service.

That's accessing applications over the network, usually via subscription.

Think Microsoft 365 or Google Workspace.

Your data lives on their servers and pay as platform as a service.

This gives you a whole environment in the cloud OS servers networking where you can build and run your own applications, but the provider manages the underlying infrastructure.

How are these deployed?

Who can access them?

Different ways.

Public clouds are open to anyone who pays.

Private clouds are dedicated to a single organization.

Community clouds are shared by multiple orgs with similar interests, maybe like a group of law enforcement agencies sharing a specific platform.

Hybrid clouds mix two or more of these.

So with all this data moving off local machines and into these remote services, how does that change things for forensic investigators?

It's a massive shift.

You often find fewer traditional artifacts directly on the suspect's computer or phone.

The bulk of the evidence might be on servers located potentially anywhere in the world.

Which creates huge legal headaches with jurisdictional issues.

Exactly.

For law enforcement, getting a warrant for data stored in another country used to be incredibly complex, sometimes impossible.

For corporate investigations, you run into varying privacy laws and expectations across different regions.

Have things improved on the legal front?

Somewhat, yes.

In the U .S., for instance, the Stored Communications Act has been clarified, generally requiring U .S.-based providers to hand over data they control, regardless of where they physically store it, when presented with valid U .S.

legal process.

And for companies using cloud services?

Having really clear service level agreements, or SLAs, with their cloud providers is critical.

These should spell out exactly how data can be accessed for investigations, any limitations, where data will be stored geographically, and how legal conflicts will be handled.

International laws like the EU's GDPR add more layers, requiring things like user notification and consent in many situations.

When investigators do get data back from a cloud provider,

is it forensically sound?

That's a key concern.

Chain of custody is vital.

You need to understand and be able to validate the methodology the provider used to collect and preserve that data.

Was it complete?

Was it altered in any way?

Ensuring admissibility is crucial.

So even with the data in the cloud, are there any traces left locally that point to cloud usage?

Oh, definitely.

If they access the service through a web browser, you'll find artifacts in the browser cache, history, cookies, just like we discussed.

And things like prefetch files, which we covered previously, can show when cloud synchronization applications or related software were last run on the local machine.

Can we look at a couple of specific examples?

Say Dropbox.

What local artifacts might it leave?

If the user installs the Dropbox sync client, it creates that local Dropbox folder.

Forensically interesting files include config .dbx.

It contains the user's Dropbox ID, account email, username, and the path to that local sync folder.

Okay.

Anything else?

And filecache .dbx.

This is a database that acts like a journal, tracking files that have been synced or are in the process.

It lists file names, local paths, file sizes, and a local host ID.

What about Google Drive?

Similar artifacts?

Similar concept, yes.

Again, assuming the local sync client is installed.

Key databases include sync -config .dd holds the path to the local Google Drive folder, USB device sync settings, and the linked Google account email.

Then there's snapshot .db.

This one's important.

It has tables like local entry, detailing files synced from the local machine, with volume, serial numbers, timestamps, size, and cloud entry, detailing files synced from the cloud, filename, timestamps, size, sharing status.

Wow, that's detail.

Anything else for Google Drive?

There's also device .db, which specifically tracks USB devices that have been set up for backup or sync with Google Drive.

It logs the USB device ID, its label, upload times, and lists a file synced from that specific device.

So even with data flying off to the cloud, there are still these important local databases tracking the synchronization activity.

Absolutely.

They provide crucial context and links between local activity and cloud storage.

But, and this is a big but, cloud computing evolves so quickly.

The exact names, locations, and formats of these artifacts can change frequently.

Investigators have to constantly learn and adapt.

That's a really important point, constant change.

Well, this has been incredibly comprehensive.

We've really covered a lot of ground today on the internet artifacts.

We really have.

From the nitty -gritty of browser data, Chrome, i .e.

Edge, Firefox, looking at bookmarks, history, cache, cookies, passwords.

Then moving into social media, the challenges of server -side data, finding those user IDs for Facebook and Twitter, and the role of service providers.

Right, and the legal process involved there.

Then P2P file -sharing errors, Emule, Sharaza, understanding how they work, and the specific logs and config files they leave behind.

Yep, the hashes, search terms, file lists.

And finally, tackling cloud computing.

The different service models, deployment methods, the jurisdictional maze, and the local sync artifacts left by services like Dropbox and Google Drive.

I think, you know, the main takeaway for me is just how many digital footprints we leave, intentionally or not.

And for an investigator knowing where to look, what format the data is in, and having the right tools,

it's absolutely essential.

And understanding those legal hurdles, especially with third -party data.

Definitely, that's becoming more and more central to these kinds of investigations.

So thinking ahead, with the internet and cloud becoming even more integrated into our lives, it makes you wonder, doesn't it?

How is digital evidence going to keep changing?

What kind of new artifacts, new breadcrumbs, will investigators be looking for in, say, five or ten years?

That's the million -dollar question, isn't it?

The landscape is constantly shifting.

AI, IoT, encrypted communications.

The challenges and the traces left behind will definitely evolve.

It requires continuous learning.

A fascinating and maybe slightly unnerving thought to end on.

Well, I feel confident saying we've thoroughly covered the key aspects laid out in that source chapter on internet artifacts today, touching on all those critical areas from browsers right through to the cloud.