Jump List Analysis, Pt III
Dan recently posted on Jump Lists on his blog, and provided a list of AppIDs, which can be used to augment what Mark posted on the ForensicsWiki.
So what happens if you run across an AppID that's not on one of the lists? Recently Jamie (Twitter: @gleeda) suggested determining the algorithm used to generate AppIDs, but what if the algorithm is a one-way hash, similar to what is used to compute the hashes in Prefetch file names? If that's the case, then having the AppID alone doesn't provide a means for determining the application name (i.e., if the hash is one-way). So, what else can be done?
Well, this would be a great time for timeline analysis. After all, it's unlikely that the only thing you'll want to determine is the name of the application that corresponds to the AppID; it's much more likely that that will be the first (or one) question of several.
When developing your timeline of system activity from a Windows 7 system, you'll likely have Prefetch files, Windows Event Log (EVTX) files, file system metadata, Registry key LastWrite times, time stamped information from Registry values, etc. Also, when you parse the DestList stream from the *.automaticDestinations Jump List files (particularly the one you're interested in), you'll have an MRU/MFU listing that you can add to the timeline. So what you'd normally look for (as with a Windows XP system) is that an entry was added to or modified within the Jump List file around the time that an application .exe was accessed...but wait...by default, Windows 7 (and Vista) doesn't update last access times on files! Holy MFT, Batman! What now?
Or, what happens if the user installs an application, does some stuff, and then deletes the application? Even if the Windows 7 system had been tweaked to update last access times on files, if the application is deleted and the executable file isn't available (MFT entry is overwritten...)...well, you can see where I'm going with this...
There is a solution to determining which application used in both of the above scenarios. One of the forensically interesting aspects of Jump Lists is that they persist on the system even after the application has been removed. We can use other, similar artifacts, such as Prefetch file metadata and UserAssist key entries (which also persist on a system after the application that was launched has been removed) to correlate the necessary information. For example, if a user installed an application (via an MSI package), you'd see that activity in the UserAssist key (as well as the MSI key listing). If they then launched the installed app, you'd also likely (depending upon how it was launched) see that in the UserAssist key, and then you'd see a Prefetch file being created in close proximity to the launch. You should also see the Jump List file being created within close proximity to the UserAssist key and Prefetch file data.
Once the application is removed from the system, you shouldn't see any further modifications to the Prefetch file or Jump List file data. If you found that the application appeared to have been run multiple times, then you should be sure to look to VSCs for additional available time stamped data.
What I hope this demonstrates is how analysis techniques such as timelines not only provide context to the data that you're looking at, but by incorporating multiple data sources, you increase your relative level of confidence in the data itself. Understanding the nature and value of those data sources also means that not only do you understand what should be there, but you can also fill the gaps when something (i.e., an application) is intentionally removed or deleted.
So what happens if you run across an AppID that's not on one of the lists? Recently Jamie (Twitter: @gleeda) suggested determining the algorithm used to generate AppIDs, but what if the algorithm is a one-way hash, similar to what is used to compute the hashes in Prefetch file names? If that's the case, then having the AppID alone doesn't provide a means for determining the application name (i.e., if the hash is one-way). So, what else can be done?
Well, this would be a great time for timeline analysis. After all, it's unlikely that the only thing you'll want to determine is the name of the application that corresponds to the AppID; it's much more likely that that will be the first (or one) question of several.
When developing your timeline of system activity from a Windows 7 system, you'll likely have Prefetch files, Windows Event Log (EVTX) files, file system metadata, Registry key LastWrite times, time stamped information from Registry values, etc. Also, when you parse the DestList stream from the *.automaticDestinations Jump List files (particularly the one you're interested in), you'll have an MRU/MFU listing that you can add to the timeline. So what you'd normally look for (as with a Windows XP system) is that an entry was added to or modified within the Jump List file around the time that an application .exe was accessed...but wait...by default, Windows 7 (and Vista) doesn't update last access times on files! Holy MFT, Batman! What now?
Or, what happens if the user installs an application, does some stuff, and then deletes the application? Even if the Windows 7 system had been tweaked to update last access times on files, if the application is deleted and the executable file isn't available (MFT entry is overwritten...)...well, you can see where I'm going with this...
There is a solution to determining which application used in both of the above scenarios. One of the forensically interesting aspects of Jump Lists is that they persist on the system even after the application has been removed. We can use other, similar artifacts, such as Prefetch file metadata and UserAssist key entries (which also persist on a system after the application that was launched has been removed) to correlate the necessary information. For example, if a user installed an application (via an MSI package), you'd see that activity in the UserAssist key (as well as the MSI key listing). If they then launched the installed app, you'd also likely (depending upon how it was launched) see that in the UserAssist key, and then you'd see a Prefetch file being created in close proximity to the launch. You should also see the Jump List file being created within close proximity to the UserAssist key and Prefetch file data.
Once the application is removed from the system, you shouldn't see any further modifications to the Prefetch file or Jump List file data. If you found that the application appeared to have been run multiple times, then you should be sure to look to VSCs for additional available time stamped data.
What I hope this demonstrates is how analysis techniques such as timelines not only provide context to the data that you're looking at, but by incorporating multiple data sources, you increase your relative level of confidence in the data itself. Understanding the nature and value of those data sources also means that not only do you understand what should be there, but you can also fill the gaps when something (i.e., an application) is intentionally removed or deleted.