Daily Blog #745: Solving the windows hello challenge part 1

 

Hello Readers,

Last week’s Sunday Funday challenge had me asking you all to test Windows Hello and discover what traces it leaves behind after authentication. Since the community couldn’t pinpoint the answer, I decided to dive in and do the testing myself.

Part 1: Facial Recognition

I started by focusing on the aspect that interests me most—facial recognition. Why facial recognition because it would indicate whose face was being presented and in theory who is actually at the keyboard. I purchased a Windows Hello-capable webcam that uses a facial scan for authentication. After installing it, I rebooted my computer, logged in using the facial scan, and then locked and unlocked the computer with Windows Hello.

Digging Into the Event Logs

First, I checked the Security Event Log. As expected, I found several Event ID 4624 entries. However, these only showed “Type 11 (cached credentials)”—there was no mention of Windows Hello or the facial scan being used for authentication.

After some research, I discovered a custom Microsoft log called Microsoft-Windows-Biometrics/Operational. There, I found Event ID 1605, which read:

"The Windows Biometric Service secure component successfully authorized user (domain)<user>"

This confirmed that biometric authentication had taken place, but it didn’t specify which method was used. Looking two events earlier, I found Event ID 1019, which provided the missing details:

"The Windows Biometric Service completed a privileged vendor-specific operation for sensor: Facial Recognition (Windows Hello) Software Device (ROOT\WINDOWSHELLOFACESOFTWAREDRIVER\0000).
The command was directed to the biometric unit's 'Sensor Adapter' component."

This closed the loop for me. I now know exactly which biometric device was used, which user was authenticated, and that the login was successful—all thanks to facial recognition.

Stay tuned for the next part, where I’ll explore PIN-based logins and what they leave behind!

Read More

Daily Blog #744: Sunday Funday 2/9/25

 

Hello Reader,

It's Sunday! This week's challenge is all about shellbags in Windows 11! Every version of windows changes the behavior of how our artifacts work, it's time for you to find out what's new in Windows 11!

The Prize:

$100 Amazon Giftcard

The Rules:

1. You must post your answer before Friday 2/14/25 7PM CST (GMT -5)
2. The most complete answer wins
3. You are allowed to edit your answer after posting
4. If two answers are too similar for one to win, the one with the earlier posting time wins
5. Be specific and be thoughtful
6. Anonymous entries are allowed, please email them to dlcowen@gmail.com. Please state in your email if you would like to be anonymous or not if you win.
7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post
8. AI assistance is welcomed but if a post is deemed to be entirely AI written it will not qualify for a prize. 

The Challenge:

 Test what causes a shell bag to be created or updated based on the following actions:

1. A directory created in the command line

2. A file being copy and pasted

3. A folder being copy and pasted

4. A file being cut and pasted

5. a folder being cut and pasted

6. A directory being opened from file explorer

7. A directory being opened from the desktop

8. A directory being clicked on from file explorer

9. A directory being clicked on from the desktop

 

Read More

Daily Blog #743: Solution Saturday 2/8/25

 

Hello Reader,

No winning entries this week, sounds like this is something i will have to research and post about!

Read More

Daily Blog #742: Life is short

 

Hello Reader,

I'm writing this after two days of rememberances for someone who died too young and left their family behind. This just a friendly reminder to enjoy each day you have with your love ones and leave behind a legacy of kindness and charity to be remembered by. Call the ones your love, you never know when you'll talk to them for the last time. 

Read More

Daily Blog #741: AI powered Honeypots

Hello Reader,

I’ve always found honeypots fascinating. There’s something deeply satisfying about reviewing logs of frustrated attackers and uncovering their latest tactics. However, setting up a convincing honeypot has traditionally required a lot of effort—crafting realistic environments, files, and services to appear valuable while ensuring they couldn’t be exploited for real attacks.

AI has changed the game once again. There are now AI-powered honeypots (at least two that I know of) that leverage large language models to simulate entire systems. These models dynamically generate file listings, process lists, file contents, and other system artifacts, making fingerprinting much harder for attackers. I think this is incredibly cool! In fact, I once asked ChatGPT to pretend to be a Linux system—and the results were hilarious!

Here are two AI-powered honeypots worth checking out:

• Splunk AI Honeypot (DECEIVE) – SSH Honeypot

🔗 GitHub: splunk/DECEIVE

• Galah – HTTP Honeypot

🔗 GitHub: 0x4D31/galah

Hope you find these as interesting as I do!

Read More

Daily Blog #740: USN V4 Data Ranges

 

Hello Reader,

In the prior post we talked aboutt the differences between USN v2, v3 and v4. I thought it would be good to a bit more into v4 and why it may be creating evcen more useful data for you. v4 stores 'data ranges' which means that it tells you what sectors on the disk where involved in a change. 

What does that mean for you?

1. If a file was deleted you have the data ranges it previously existed in, even if it was fragmented

2. If a file was changed you can see what blocks may have nay previous partial contents

What gets more interesting is that in the testing done it also appears that in some cases its not just the ranges of data that is being written to the USN Journal but some of the contents of those sectors as well. I'm going to be doing some testing to see if this limited to just resident files or if like EXT4 it will record the contents of all blocks changed!

Read More

Daily Blog #739: USN Versions (2, 3 and 4)

 

 

Hello Reader,

Since I first looked at the USN Journal many years ago and Matthew and I released ANJP to parse it along with other data I've known there where multiple USN versions. I thought this post would be a good place to document what the differences are and when to expect to see them. 

 

USN Journal v2 – The Vista Era

• Introduced:
  With the arrival of Windows Vista, the USN Journal came into existence.
  
• What It Contains:
  At its core, v2 records fundamental details for every change on an NTFS volume: the unique file reference number, parent file reference, a monotonically increasing USN, timestamp, and a set of reason flags indicating why the change occurred.
• Default Status:
  On any NTFS volume running Windows Vista or later, v2 is created not at format but after a certain number of changes occur if windows search indexing is turned on. .
• Documentation: https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-usn_record_v2
  

USN Journal v3 – Refinements in Windows 8

• Introduced:
  Windows 8 ushered in USN Journal v3.
• What’s New:
  Building on v2’s foundation, v3 expanded the record structure to capture additional metadata. While the basic fields remain, v3 started to include more nuanced details about certain operations—particularly those around renames and changes to alternate data streams. The idea was simple: as our file operations got more sophisticated, our change records needed to do the same.
• Default Status:
  For systems running Windows 8 and later, v3 became the default journal version on NTFS volumes. Again the journal is a subsystem that was meant to assist with drive indexing, backup programs and other utilities that needed to know when things changed and why. If you just format a disk the USN journal will not appear until you have created data that requires tracking. 
• Documentation: https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-usn_record_v3
  

USN Journal v4 – The Windows 10 Evolution

• Introduced:
  With Windows 10 (in a series of updates that refined NTFS’s internal structures), Microsoft rolled out USN Journal v4.
• What’s New:
  v4 is less about a radical overhaul and more about fine-tuning. It includes extra fields to provide even more granular information about changes—covering aspects such as improved record consistency, additional flags for security-related modifications, and adjustments for better alignment with newer NTFS features. In short, v4 offers a more complete picture of file system activity while ensuring that the data is as robust and future-proof as possible.
• Default Status:
  According to the MSDN documentation V4 records are only read if you Range Tracking is turned on within tghe journal.  .Otherwise my Windows 10 and 11 systems return V3 records. 
• Documentation : https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-usn_record_v4
  

 

Read More

Daily Blog #738: Arsenal Recon LevelDB Recon

 

 

Hello Reader,

Now that last week's Sunday Funday is over I can talk about a new (to me) tool from Arsenal Recon that Mark Spencer made me aware of, LevelDB Recon. Mark and his team of experts have created a tool to parse LevelDB files and extract all of the data it can find. So if you were looking for a simpler solution that what last weeks contestants went through it's included with a Arsenal Recon subscription!

 

 "LevelDB Recon parses LevelDB files (ldb, log, and sst extensions) more comprehensively and reliably than other tools we have evaluated. In other words, LevelDB Recon has been designed for maximum exploitation of LevelDB files - ultimately revealing records missed by other methods. LevelDB Recon includes logic to help make sense of the chaos often found within LevelDB data - for example, logic that attempts to locate and decode (in a human-friendly manner) many different types of timestamps."

 You can find out more here:

Arsenal Recon

 

Read More