X

Our website uses cookies to enhance your browsing experience.

CONTINUE TO SITE >

Employing FeatureUsage for Windows 10 Taskbar Forensics

Windows 10 On Office Building

During a cybersecurity investigation, digital forensics and incident response (DFIR) professionals need to obtain information from different artifacts to determine exactly what has occurred on a machine. When performing these investigations, it may help to know if an account was logged on interactively when a program was run — for example, if someone has used the Remote Desktop Protocol (RDP) to connect to the system. In addition to event logs, there’s a number of other artifacts that can provide valuable information, such as registry keys.

Many registry keys exist to help infer what programs have run on a system, such as:

  • UserAssist
  • RecentApps
  • Shimcache
  • Last-Visited MRU
  • Windows Background Activity Moderator (BAM)

It is important to note that as operating systems evolve and new features are added, so do the registry artifacts available to DFIR professionals.

Background and Context

In this blog, we introduce a new registry artifact called “FeatureUsage,” which is found in builds of Windows 10 version 1903 and later. To a DFIR professional, this artifact is another way of confirming software that has been run interactively by an account, and how many times the software was run. In addition, it provides some insight into user behavior, such as how often an account switches between applications, looks at the Windows clock, clicks the Start menu and more.

Windows 10 about page

Figure 1. Windows 10 version containing FeatureUsage key

The FeatureUsage registry key exists within user registry hives (their NTUSER.DAT file), and therefore all information stored within FeatureUsage will be unique for each account.

 NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\FeatureUsage

This registry key and its subkeys do not exist unless an account has logged on to a system interactively. In this scenario, “interactive” refers to someone who has authenticated from the log-on screen or through RDP.

KeyCreationTime | REG_QWORD

This key contains a 64bit QWORD value that details when the key was initially created (the first time this user interactively logged on). This provides an artifact that DFIR professionals can use to ascertain or confirm when an account first accessed a machine interactively.

KeyCreationTime Conversion

The KeyCreationTime registry key is stored in the Windows Filetime format. This format details the number of 100-nanosecond intervals that have passed since January 1, 1601 UTC. We can easily convert this to a valid timestamp using tools like CyberChef. By first converting to a Unix timestamp, it can then be converted to a valid date format that tells us the first time the account interactively logged onto a system.

A potential use case for this key is to highlight or help verify the presence of a “hands-on-keyboard” adversary that has remotely logged onto a system for the first time (for example, by using RDP and a compromised service account) and has taken measures to wipe Windows event logs and other well-known forensic artifacts. Although this artifact is no replacement for a centralized logging and endpoint detection and response (EDR) solution, it may help to confirm or deny the presence of an adversary and the approximate time they first connected through RDP when these logs are unavailable. 

In the example below, we have retrieved a user’s registry hive (NTUSER.DAT file) and loaded it into the Windows Registry Editor under the key name “TempHive” by clicking File > Load Hive.

Figure 2. NTUSER.DAT file loaded within the Windows Registry Editor

In Figure 2, we see that the key has the decimal value: 132286223503288727

From here, we can use CyberChef to convert this value back to a legible date and time format.

Figure 3. Windows Filetime conversion of KeyCreationTime registry key

Subkey Overview

The FeatureUsage registry key has five subkeys. The keys exist for the purpose of taskbar metrics; however, for a DFIR professional, they can provide valuable insight into the usage of a system by an account.

  • AppBadgeUpdated
  • AppLaunch
  • AppSwitched
  • ShowJumpView
  • TrayButtonClicked

 Each of these keys contains values that correspond to an executable or GUI-based application, the number of times run, and interactions through the taskbar.

AppBadgeUpdated

This key provides the number of times a running application has its badge icon updated (for example, to notify you of unread emails or notifications).

Figure 4. AppBadgeUpdated key (Click image to enlarge)

A potential use case of this key is to determine the quantity of notifications someone has received from a particular application. This may hold value — for example, in the case of a messaging application that has since been removed and wiped from the machine. The key may help to infer that the application was indeed used, and received a number of message notification updates during the time it was used.

AppLaunch

This key provides the number of times an application pinned to the taskbar was run. 

Figure 5. AppLaunch key (Click image to enlarge)

A potential use case of this key is to highlight an application that was pinned to the taskbar and how frequently it was run. In a criminal investigation, this may help to prove that an account holder knew about an application (as it is shown to them on the taskbar) and knowingly ran the application a certain amount of times from the pinned link.

AppSwitched

This key provides the number of times an application switched focus (was left-clicked on the taskbar).

Figure 6. AppSwitched key (Click image to enlarge)

This key functions much like the UserAssist and RecentApps registry keys and can be used to find evidence of GUI application execution; however, it instead shows the number of times the application was minimized or maximized, as opposed to just launched.

ShowJumpView

This key provides the number of times an application was right-clicked on the taskbar.

Figure 7. ShowJumpView key (Click image to enlarge)

Similar to the AppSwitched key, this key functions much like the UserAssist and RecentApps registry keys and can be used to find evidence of GUI application execution; however, it instead shows the number of times the application was right-clicked as opposed to just launched.

TrayButtonClicked

This key provides the number of times built-in taskbar buttons were clicked (e.g., clock, Start button, etc.).

Figure 8. TrayButtonClicked key (Click image to enlarge)

Using this key, an investigator may be able to gain further insight into user behavior and how someone interacts with the operating system based on the number of times that taskbar buttons are clicked. A potential use case for this is to determine how frequently an account has been interactively used.

Conclusion

By analyzing the FeatureUsage registry key, a DFIR professional may be able to further validate their findings with other known forensic artifacts to help strengthen their findings during an investigation. This may also provide insight into the potential use of RDP, when it first occurred, and if anti-forensic techniques were employed by an actor to remove more well-known forensic artifacts, or in the case of a criminal investigation, it may provide some insight into user behavior and how they interact with Windows. 

Additional Resources

 

CrowdStrike Falcon Free Trial
 

Try CrowdStrike Free for 15 Days Get Started with A Free Trial