How to use SmartScreen logs to find evidence of execution and user activity analysis

When it comes to forensic investigations, every morsel of data matters. But there’s a lesser-known (or under-appreciated) event log source that remains largely untapped—Windows SmartScreen Debug Event Logs. If this artifact is available in your evidence, it can provide crucial insights into executed applications, files accessed, and user activity on a Windows workstation.

Whether you’re tracking an adversary’s tools during an intrusion or investigating insider threats, this log source can be a total game-changer. I stumbled upon SmartScreen Debug Event Logs while researching something else, and I couldn’t help but dive in—and here’s what I uncovered. 

While there are other Windows artifacts like RecentDocs registry key, jumplists, and ShimCache that can provide similar data, forensic analysis is about stacking evidence above all else. The more artifacts you find to reinforce the finding, the stronger your case will be. 

Test your skills in our SmartyPants Sherlock

This blog focuses on exploring how these logs can help confirm execution and file interactions with solid forensic evidence. Let’s get into it. 

What is Microsoft Defender SmartScreen?

According to official Microsoft documentation, SmartScreen is designed to protect users from phishing sites, malware, and potentially malicious downloads. It  determines whether a site is potentially malicious by:

• Analyzing visited webpages and looking for indications of suspicious behavior. 

• If Microsoft Defender SmartScreen determines that a page is suspicious, it shows a warning page to advise caution.

• Checking the visited sites against a dynamic list of reported phishing sites and malicious software sites. 

• If it finds a match, Microsoft Defender SmartScreen shows a warning to let the user know that the site might be malicious.

When it comes to a downloaded app or app installer, SmartScreen determines whether or not it’s potentially malicious by:

• Checking downloaded files against a list of reported malicious software sites and programs known to be unsafe. 

• If it finds a match, Microsoft Defender SmartScreen shows a warning to let the user know that the site might be malicious.

• Checking downloaded files against a list of files that are well known and downloaded frequently. 

• If the file isn't on that list, Microsoft Defender SmartScreen shows a warning, advising caution.

Now, you may be thinking: “SmartScreen is an extended feature of Microsoft defender and is meant to protect endpoint users against malicious sites, file downloads, and so on”. 

You are right. At its core, SmartScreen is an endpoint security feature, but its logging capabilities go beyond protection. These logs can be valuable forensic artifacts, helping investigators track user actions and file executions.

Limitations to keep in mind

Before moving to the practical side of things, let’s acknowledge some limitations of this artifact.

• Disabled by default: This event log source is disabled by default on Windows. This need to be enabled by running the following command:

  wevtutil sl Microsoft-Windows-SmartScreen/Debug /e:true

• GUI-dependent logging: These logs only record executions and file access via Windows GUI (e.g., local interactive sessions or user activity during RDP). Anything run through PowerShell or CMD-SHELL are not recorded.

How to find execution evidence

Windows offers multiple artifacts to confirm executable launches; Prefetch, LNK files, RecentDocs, UserAssists, BAM, and more. SmartScreen Debug logs in particular stand out because: 

1. They’re written in real time

2. They’re easy to analyze

3. They integrate seamlessly into SIEM systems without additional tooling.

Now let’s start our demo and see what that looks like in action. 

Open Event Viewer, then go to: Applications and Services Logs -> Microsoft -> Windows -> Smartscreen-> Debug

Right now, you’ll notice that we have no events.

To create logs, let’s start off with a simple example of opening cmd.exe.

We see the below events:

The details tab of each event contains detailed information, including the full path of the executed exe, size of the file, the user SID who executed this and the time in UTC.

Moving up to the other related events, they are similar but instead show a record of the shortcut to the executed executable being run. 

We get another record which contains the name of the binary, its size, time in UTC and action taken on the exe which in this case is open.

The logs contain a SID value but not the user account name. But we can easily get that from the system using wmic via PowerShell or CMD. Use the following command to extract accounts and their respective SIDs: 

wmic useraccount get name,sid

Don’t have live access to the system? No problem. You can also get this information via registry, from multiple locations. That said, the most concrete and straightforward option is through SOFTWARE hive from the following path: 

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\

With all this information we now have concrete evidence that cmd.exe was executed by user account with SID S-1-5-21-3088055692-629932344-1786574096-1002 (cyberjunkie) at 2025-01-23 09:49:23:

Real-world scenario: Tracking a Mimikatz execution

Time to step this demo up and simulate a realistic case. Let’s download mimikatz.exe from GitHub and then execute it. We are faced with a SmartScreen window warning us to not run the exe as it may be malicious. Whether the user bypasses this prompt or not, the execution is logged. 

Moving back to our logs, we’ll see:

• Event ID 1000 appears in the logs

The record includes:

• URL source (from the Alternate Data Stream marking internet downloads)

• File name and enforcement status (SmartScreen’s warning status)

• Execution evidence (Full path, file size, user SID, timestamp)

We are interested in the execution evidence of this file. Let's move to the other event.

Here we can see the full path of the file, the size of the file, SID of the account executing this and time in UTC. Let’s see another event which records the unknown hash and the executed file metadata as well, which can be very helpful. This is because within the metadata, you’ll find information like author name, certificate info, company name, product name, etc. 

The full blob was very long, so here are the relevant snippets:

Above, you’ll see the name ‘Benjamin Delpy’, the author and creator of Mimikatz. You can also see the file name itself. Why does this matter? Well if a threat actor, for example, renamed the file from Mimikatz to hackthebox.exe, the metadata may still be helpful in determining the true nature of the file.

To put things into perspective and validate this artifact,  compare these results to a well-known artifact like those found in Prefetch logs (C:\Windows\Prefetch\MIMIKATZ.EXE-XXXXXXXX.pf)

The last execution timestamp from Prefetch matches the timestamp from our event log exactly. We can also match the full path of the file, which is the  same as the one we found in our event logs. This confirms that SmartScreen Debug logs reliably capture execution events and complement traditional forensic artifacts. 

Note: Ignore the timestamp in Other run times in the Prefetch results as this occurred when I was testing this and executed the file an additional time in error.

Tracking file interaction

Beyond executables, SmartScreen Debug logs also capture user interactions with non-executables—think text files, PDFs, documents, and so on. 

Practical example: Confidential file access 

Imagine a user within your organization gaining unauthorized access to a confidential file. You need to prove that they opened it on a specific date. Traditional artifacts like ShellBags, jumplists, and RecentDocs help, but SmartScreen logs give you additional confirmation. 

Let’s see that in action. For this example, we’ve created a normal .txt file and then accessed it.

Here, we can see the time in UTC when this was accessed, User SID, Full path of the file and its size. But what about a scenario where an insider threat got their hands on a confidential file. They were not meant to see it, but found and deliberately opened it, breaching confidentiality. What’s next?

As a forensics analyst, you’ll need to prove that the user account belonging to them opened that file at X date. If other artifacts like ShellBags, Jumplists, and RecentDocs come to mind, then you are on the right track as these might help determine the user’s behavior surrounding the confidential file. 

SmartScreen Debug logs can help you to solidify whether the user accessed the confidential file or not. Here’s how to do that in 4 steps: 

1. Open the confidential file 

We have a confidential pdf file called “Confidential Data.pdf”

2. Check your SmartScreen logs

After this file has been interacted with, we can see that there are records populated related to this in SmartScreen logs. Check SmartScreen logs for the file path, file size, user SID, and access timestamp:

What this specific record specifies is that the user account with SID  S-1-5-21-3088055692-629932344-1786574096-1002, which is connected with cyberjunkie-tes/cyberjunkie’s account, opened Confidential Data.pdf located at C:\Users\cyberjunkie\Documents. It’s also clear that this file was opened on 2025-01-23 at 11:24:08. 

This all is digital evidence of a specific user behavior—opening a confidential pdf file.

3. Cross-check with LNK file analysis

Using LECmd.exe, developed by Eric Zimmerman, you’ll be able to cross-check your findings. Here’s what that command would look like in this scenario: LECmd.exe -f “C:\Users\cyberjunkie\Recent\Confidential Data.lnk”

Here, we can see that file size, file path are exactly the same as found in SmartScreen debug logs. 

The LNK creation timestamp is the time when that file is first run on the system, and we can see the LNK was created on 2025-01-23 11:24:09, which is just 1 second after the actual execution of the pdf file. 

This one second can be neglected as this is the time taken by the system to create the subsequent LNK file.

Strengthen your forensic conclusions

While the data obtained from these SmartScreen logs is not new or groundbreaking by any means, they do offer another layer of visibility when investigating execution and file access. If traditional artifacts fall short, this log source can fill in the blanks and strengthen any forensic conclusions. 

Whether you’re dealing with an intrusion, an insider threat, or just need more data points, these logs are worth adding to your forensic toolkit. Enable them, explore their potential, and add another weapon to your investigative arsenal. 

Time to test your knowledge