Supporting Your Application
Kelly C. Bourne, in Application Administrators Handbook, 2014
11.8.1.1 Console mode
When using RDC to connect to a remote Windows server, you are effectively creating a new session and logging into it. A session, called the console session, always exists on the server. This is also referred to as session 0. You can connect to this session by adding the parameter / console when making the connection from RDC.
The advantage of opening a session in console mode is that any applications that are currently running on the server will be visible to the console-mode session. This isnt the case when a session is opened in nonconsole mode.
There is a small degree of risk associated with using console mode when remoting to a server. One application that I administered would crash if anyone logged into the server in console mode. There was a bug in the application that required it be run in the console session. If someone remoted in as console mode, then the application crashed. The odds of your application having a similar bug are pretty small, but if it crashes whenever someone logs into the server as console mode then this might be the problem.
Presentation virtualization [Terminal Services]
Thomas Olzak, ... James Sabovik, in Microsoft Virtualization, 2010
Connecting to a windows remote desktop
Now let us make Remote Desktop connection and see the fruits of your labor.
1.From any Windows client machine on your network launch Remote Desktop Connection from the Start menu, under Accessories, as shown in Figure 13.16.
Figure 13.16. Launch Remote Desktop.
Enter in the name of your terminal server in the Remote Desktop Connection window, as demonstrated in Figure 13.17, and click Connect.
Figure 13.17. Select Your Terminal Server.
As shown in Figure 13.18, enter in the credentials of an account in the AD user group you granted permission to connect to your terminal server in Step 9 of the previous section, Installing the Terminal Services Terminal Server Role, and click OK.
Figure 13.18. Enter your credentials to connect.
What now opens, as shown in Figure 13.19, is a Remote Desktop session presented from your terminal server and including the Windows-based applications you installed in Step 13 of Installing the Terminal Services Terminal Server Role.
Figure 13.19. Launch Remote Desktop.
Windows Server 2008 R2 Remote Desktop Services
Dustin Hannifin, ... Joey Alpern, in Microsoft Windows Server 2008 R2, 2010
Configure the Remote Desktop Connection Broker, Desktop Session Host, and Web Access
Now that all components are installed, we are ready to configure them to complete the VDI setup. Again we assume that you have already set up one or more virtual machines that will be dedicated to users. Remember that the label name within Hyper-V needs to be a fully qualified domain name [see Figure 8.34]. Additionally, the VM must have Remote Desktop turned on.
Figure 8.34. Hyper-V VM with FQDN label.
To configure server components, first logon to the Remote Desktop Connection Broker and perform the following:
1.Open Server Manager.
2.Expand the nodes Roles | Remote Desktop Services | Remote Desktop Connection Manager | RD Virtualization Host Servers.
3.Select the node Personal Virtual Desktops [see Figure 8.35].
Figure 8.35. Personal Virtual Desktops configuration node.
Click the Configure link in the middle pane to launch the Configure Virtual Desktops Wizard which will take you through setting up the broker to support virtual desktops.
5.Click Next to begin the wizard.
6.Add the hostname of the Hyper-V server you set up as the Virtualization Host Server. Then click Next.
7.Enter the fully qualified domain name of the Remote Desktop Session Host server [see Figure 8.36]. If you need to support remote desktop clients earlier than 6.1, you will need to specify an alternative FQDN for the same session host. This can be accomplished by creating a new host [A] DNS record, and pointing it to the same Remote Desktop Session Host server. This FQDN is used purely to provide an alternative name that older clients will use to connect. Notice the option at the bottom of the page to not autoconfigure the session host. In most cases, you will want to leave this option unchecked, which will allow the wizard to automatically configure the session host server for redirection. After entering the FQDN of the Remote Desktop Session Host, click Next. The wizard will attempt to connect to the session host. If successful, it will configure the session host for redirect support.
Figure 8.36. Configuring Remote Desktop Session Host.
You now must specify the FQDN of the Remote Desktop Web Host server. In our exercise, this is the same server as the Remote Desktop Session Host. Enter the FQDN of the Remote Desktop Web Host, and click Next.
9.Verify your configuration on the confirmation page. Then click Apply.
10.Click Finish to close the Configure Virtual Desktops Wizard. Notice that the option to Assign Personal Virtual Desktop is select. This will launch the Assign Personal Virtual Desktop Wizard. Using this wizard, we will assign a user to his desktop. Every time a user logs onto a Personal Virtual Desktop session, they will access the assigned VM.
11.Select the user and the VM that you want to assign the user to [see Figure 8.37], and then click Next.
Figure 8.37. Selecting the user and the VM to assign to the user.
Click Assign to complete the Assign Personal Virtual Desktop Wizard.
13.Verify that the assignment was successful, and then deselect the option to Assign Another Virtual Machine to Another User. If selected, this would allow you to assign more users to move VMs. Click Finish to complete the assignment.
Now that you have assigned a user to a VM, you need to configure the Remote Desktop Web Host to use the broker server. To configure the host, perform the following:
1.Logon to the RemoteApp and Desktop Connection Web site by accessing the URL ///RDWeb [see Figure 8.38].
Figure 8.38. RemoteApp and Desktop Connection.
Ignore any certificate warnings. For a production deployment, you will want to assign a trusted certificate to the RD Web site.
3.Enter credentials with administrative access to the site and click the Sign-in button.
4.Click the Configuration tab.
5.On the Configuration page, change the Select Source Server to Use option to An RD Connection Broker Server. Then enter the FQDN of the connection broker. Click OK to save the configuration changes. After the settings are saved, click Sign-out.
Installing, Configuring as a Server
Graham Speake, in Eleventh Hour Linux+, 2010
Windows Interoperability
Interoperability between Linux and Windows is normally an essential task that any system administrator needs to undertake.
Remote Desktop
rdesktop uses the Remote Desktop Protocol [RDP] and can be used to present remote desktops. To connect to a remote host, hostname.mycorp.com with IP address 10.10.100.23, either of the following commands can be used:
rdesktop hostname.mycorp.com
redesktop 10.10.100.23
Crunch Time
The target server or client must have the remote desktop connection enabled for this to work. In addition, you may need to supply username and password credentials applicable to the target host. The protocol runs on port 3389, which will need to be open on any intermediate firewalls.
Virtual Network Computing
Virtual network computing [VNC] is a client-server application used to administer remote machines, operating on port 5901. A client for X Windows is vncviewer, which will connect to any VNC-compatible server.
Samba
Samba will implement the basic Server Message Block/Common Internet File System [SMB/CIFS] services, namely:
File and print services
Authentication and authorization
Name resolution
Browsing or service announcement
Users may wish to share some of all their files and allow only certain users to access [authentication and authorization]. All these are handled by the daemon that is included within Samba.
Fast Facts
The two daemons included with Samba are smbd and nmbd.
smbd handles file and printer sharing, including user access [authentication and authorization].
nmbd undertakes name resolution on a point-to-point basis or broadcast basis, using the NetBIOS protocol.
In broadcast mode, an nmbd client will send out a request to all machines on the network, for example, asking who is running a particular service.
The other name resolution element of the nmbd daemon revolves around the NetBIOS Name Service [NBNS] or Windows Internet Name Service [WINS].
Within NBNS, there is a master server that holds the IP address and NetBIOS name of each client or server on the network and will serve these upon request.
The network browsing or service announcement part of Samba is also handled by the nmbd daemon.
There is one local master browser [LMB] on a network that holds the list of available services and provide these upon request. These lists can be populated across domains via domain master browsers [DMBs].
The main configuration file for Samba is smb.conf, usually residing in /etc/samba/smb.conf or /usr/local/samba/lib/smb.conf. The smb.conf layout is similar to that used in older Microsoft Windows .ini files, comprising a number of sections with a section name in brackets [[]] delimitating the sections. The sections or stanzas will contain information about the shares, printers, and services on the server. There is one special stanza called global, which specifies parameters that apply to all other stanzas in the smb.conf file. A very minimal smb.conf file can be defined that just defines a couple of global parameters and some shares.
[global]
workgroup = mycorp
netbios name = computer_name
[share1]
path = /etc
comment = share the /etc folder to the world
[share2]
path = /documents
comment = share the global documents folder to the world
If you are setting up a server and want to share everyone's home directories, there is a special stanza called homes, which will enable the default home directory shares.
[homes]
comment = Home Directories
browseable = yes
Comment = only allow users to connect to their own directory, \\server\username
valid users = %S
comment = allow user to write to the directory
writable = yes
The lmhosts file is built into Samba and is the NetBIOS name to IP address mapping, in a similar format to the /etc/hosts file. The file is located in the /etc/samba or /usr/local/samba/lib directories.
The Samba server has a number of daemons [notably, nmbd and smbd] that need to be started, normally upon boot, and will read the smb.conf file. Once started, the server can be managed from the command line or through a graphical user interface [GUI]. The command-line interface is very easy to use, and the main command is smbstatus, which can display the full status of the servers and connected clients. Some of the options available are shown in Table 8.3.
Table 8.3. smbstatus Options
| -b | Displays the list of users who are currently connected to the Samba server |
| -s | Displays the list of connected shares |
| -L | Displays the files that are currently locked |
| -u username | Displays information on the user username |
| -p | Displays a list of the smbd processes |
Assume that there is a Samba server located on the server syngress with a shared directory called rosie; you could map a drive on Windows to this from the command line using: net use h: \\syngress\rosie.
Linux has a client to access a Samba server called smbclient, with a syntax: smbclient //servername/sharename.
This client will display a new prompt to the user [typically, smb: \>] and will have very similar functionality to a File Transfer Protocol [FTP] session with get, put, ls, and so forth.
winbind
The integration of Linux and Microsoft Windows can be time consuming as there is no real underlying unified login. The winbind component of Samba tries to solve this by allowing Windows domain users to appear and operate as a Linux user. The mappings between the Linux and Microsoft Windows user IDs are stored by winbind.
Securing RDP
Timothy Thor Mullen, in Thor's Microsoft Security Bible, 2011
Publisher Summary
The chapter defines the way to secure RDP. The protocol used for a remote desktop connection is called RDP and providing a user access to a system via RDP was originally called Terminal Services. Terminal Services came in two flavors: as a remote administration service called TSAdmin, and as an overall service offering for multiple users called TSAppMode. People started to more commonly use the term remote desktop instead of Terminal Server just in time for the Terminal Services Gateway [TSG] service to come out, which allows a terminate-and-distribute-type access to RDP hosts via a gateway. Deployment of RemoteApps is also discussed, via both RDWeb and signed RDP files. Finally, the chapter concludes with the introduction of a one-of-a-kind RDP client tool that allows to further lock down the RDP hosts via source port firewall rules.
General Administrative Tasks
In How to Cheat at Microsoft Vista Administration, 2007
Administer via Remote
Remote Desktop, which was introduced in Windows XP, is a powerful administration tool. It allows administrators to perform everyday admin jobs while sitting at their desks. In Windows Vista, Remote Desktop is available only in the Business, Ultimate, and Enterprise editions. You can configure Vista Home Basic and Home Premium computers for outgoing Remote Desktop connections only. In this section, we will explain how to set up Windows Vista computers for incoming and outgoing Remote Desktop connections.
Configuring the Remote Desktop Host
The host computer is the one which will allow remote computers to connect to it using the Remote Desktop connection. You must configure this computer appropriately in order to accept incoming connections. The procedure is as follows:
1.Open the Control Panel utility and click the System and Maintenance link.
2.Under the System group, click the Allow Remote Desktop link. UAC will prompt you to confirm your action. Click Continue.
3.The Remote tab of the System Properties window appears, as shown in Figure5.20.
Figure5.20. Configuring the Remote Desktop Host
Click one of the options from the Remote Desktop portion of the window, as explained shortly.
The three settings in the Remote Desktop portion of this window are as follows:
Dont allow connections to this computer This option will block all incoming connection attempts.
Allow connections from computers running any version of Remote Desktop [less secure] If you are working in a mixed Windows Vista and Windows XP environment, this is the option to select.
Allow connections only from computers running Remote Desktop with Network Level Authentication [more secure] Select this option if the computer trying to connect supports Network Level Authentication.
By default, a Windows Vista computer is configured not to allow any Remote Desktop connections. Once you make a selection, click the Select Users button to specify the users who will be allowed to connect to this computer using Remote Desktop.
To add users, click the Select Users button. The Remote Desktop Users dialog box appears, as shown in Figure5.21. Click the Add button to add users or the Remove button to remove any user who has been previously granted Remote Desktop access. You use the User Accounts link to add any users who do not already exist on the computer.
Figure5.21. Remote Desktop Users
Configuring the Remote Desktop Client
Once you have configured the Remote Desktop host to accept incoming connections, the client computer must connect to the host using the Remote Desktop Connection dialog box. You can open this dialog box using the following methods:
Click Start | All Programs | Accessories | Remote Desktop Connection.
Click Start and type Remote in the search box. Click the Remote Desktop connection from the list that appears.
The Remote Desktop Connection window appears, as shown in Figure5.22. There are a lot more options for configuring the outgoing connection, and we will explain them a little later in this section.
Figure5.22. Remote Desktop Connection
Type the name of the remote computer and click Connect. You can click the little down arrow at the end of the name box and click Browse for More to determine which one is the remote computer. The computer name is either the Fully Qualified Domain Name [FQDN] or the IP address of the remote host.
To view other options available for configuring the Remote Desktop connection, click the Options button. Figure5.23 shows the window that appears.
Figure5.23. Configuring Outgoing Remote Desktop Connection Settings
Various tabs in this window allow you to completely configure the connection settings, as summarized in the following list:
General You can configure the outgoing connection and save your settings by using the Save or Save As button. Click the Open button to open a previously saved connection settings RDP file.
Display The Display tab contains options for setting the size for the remote desktop and setting the number of colors to display. By default, the Display the Connection Bar When in Full Screen Mode option is checked.
Local Resources Settings in this tab allow you to configure sound from the remote computer and whether special keyboard commands [such as Alt + Tab and Ctrl + Alt + Del] will be executed on the local computer or the remote computer. The Local Devices and Resources section allows you to configure which devices on the remote computer can be used.
Programs You can specify a particular application to execute when the connection is established.
Experience This tab contains settings that you can configure for the entire Remote Desktop session. These depend on the connection speed, and they include desktop background, font smoothing, desktop composition, menus and window animation, and themes, among others.
Advanced You can use the settings in this tab to configure how the computer behaves if the authentication fails. You can also configure settings for a Terminal Services Gateway server. By default, the Remote Desktop connection is configured to Warn Me If Authentication Fails. You can set it to Always Connect Even If Authentication Fails or Do Not Connect If Authentication Fails. The Settings button in the Connect From Anywhere section opens the Terminal Services Gateway Settings window.
Firewall Settings for Remote Desktop Connection
Remote Desktop uses TCP port number 3389 by default. Because Windows Firewall in Windows XP and Windows Vista blocks this port, you will need to configure Windows Firewall in order to allow Remote Desktop connections. Here is the procedure to configure Firewall settings:
1.Click Start | Control Panel.
2.Click the Allow a Program Through Windows Firewall link under the Security group.
3.Click Continue in the User Account Control dialog box to confirm your action.
4.The Windows Firewall Settings page appears, as shown in Figure5.24.
Figure5.24. Configuring Windows Firewall to Allow a Remote Desktop Connection
Click the Remote Desktop checkbox and click OK.
6.Close the Control Panel.
Another way to access the Windows Firewall Settings page is to right-click the Security Center icon on the taskbar and select Open Security Center. Click Windows Firewall in the left-hand panel to open the Windows Firewall page. Click Allow a Program Through Windows Firewall.
Because Remote Desktop and Remote Assistance both rely on Terminal Services, it is necessary to open port 3389 on Windows Firewall on both the Remote Desktop host and client to allow incoming and outgoing connections. If the computers are located behind routers, you will need to configure the routers at both ends to open this port. Refer to the documentation of the router for changing these settings. Chapter 9 covers configuring and troubleshooting Windows Vista Firewall in more detail.
Microsoft Windows Server 2008
Aaron Tiensivu, in Securing Windows Server 2008, 2008
Solutions Fast Track
Terminal Services RemoteApp
TS RemoteApp makes the network programs available over the LAN and Internet that can be remotely accessed through clients running RDC clients or through Web.
TS RemoteApp is an easier way to deploy applications once and manage it across the enterprise. Remote offices with limited IT staff greatly benefit from this feature.
TS RemoteApp helps organizations manage frequently updated, difficult to manage, or infrequently used applications efficiently.
Terminal Services Gateway
Terminal Services Gateway helps administrators enable remote users to access the corporate applications without needing to set up a VPN.
RDP traffic from the remote clients travel through a HTTPS encapsulation to reach TS Gateway, and later the HTTPS encapsulation is removed to pass only RDP traffic to the terminal servers.
Configuration of TS Gateway servers includes installing SSL certificates and creating resource allocation policies CAP and RAP.
Group Policy for Terminal Services defines finer security settings, connection and session limits, resource management, and licensing.
RDC client parameters, connection, devices, and resource direction, licensing, printer redirection, user profiles, remote session environment, security, session time limits, temporary folders, and licensing are the options available for configuration.
You need to group identical terminal servers into one GPO and place them under the OU to apply Group Policy settings.
Terminal Services Web Access
Terminal Services Web Access provides a Web platform to access remote applications through a Web site. Remote applications appear as a Web link on the corporate Web site.
TS Web Access enables you to make RemoteApp programs appear as a link on the Web site and make them available to remote users.
TS Remote Desktop Web connection is a feature of TS Web Access that allows remote users to connect to a remote desktop, taking full control of the remote system instead of just accessing the remote applications.
Security Guidance for Operating Systems and Terminal Services
Tariq Bin Azad, in Securing Citrix Presentation Server in the Enterprise, 2008
Windows Remote Desktop Client
Microsoft now offers a single client solution to connect to Terminal Services that will run on operating systems from Windows 95 to Windows XP. This is the client that I recommend because it forces 128-bit encryption and offers the ability to connect to ports other than 3389. To connect to an alternate port, just add it to the IP address separated with a colon: 10.1.1.1:9999. This client is available on the Windows XP Professional CD and from Microsoft download site.
To install from the CD:
1Insert the CD.
2On the Welcome page, click Perform Additional Tasks.
Click Set up Remote Desktop Connection. Remote Desktop Connection runs on most of Microsoft's operating systems, including Windows 95/98/ME/NT 4, Windows 2000, and Windows XP.
Tools & Traps
Starting the TS Client on Windows XP
There is no need to install this client on Windows XP; it comes standard. The application can be started from its elusive location, Start | Programs | Accessories | Communications or by simply executing mstsc.exe from the command line.
Windows XP and Windows Server 2003 allow you to connect directly to the console by using the following command:
mstsc /v:10.0.6.36 /console
Once you have entered a valid username and password, TS will tell you if another user is logged in to the console. If you select to connect anyway, the user session at the console will be ended, and any unsaved data will be lost.
File Analysis
Harlan Carvey, in Windows Forensic Analysis Toolkit [Third Edition], 2012
Jump Lists
Jump lists are something new to Windows 7. In short, jump lists are lists of files that the user has recently opened, organized according to the application used to open them, so in this way they are similar to the RecentDocs Registry key [Registry analysis will be discussed in Chapter 5]. Users can view their recently accessed documents and files by right-clicking on the program icon in the Task Bar. Figure 4.16 illustrates a jump list for VMWares VMPlayer application.
Figure 4.16. VMPlayer jump list.
What the user sees depends on the program; for example, the jump list of Internet Explorer will show URLs, whereas the jump list for MS Word will show documents that the user has opened. Users can also choose to keep specific items persistent in the jump list by pinning them; that is, clicking on the push pin to the right of the item, as illustrated in Figure 4.16. While the items under the Recent list may change over time, items that the user chooses to pin will persist in the jump list. These jump lists may also appear alongside programs listed in the Start menu, as well.
From an analysts perspective, the users jump lists are maintained in the AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations folder within the user profile, as illustrated in Figure 4.17.
Figure 4.17. Contents of users AutomaticDestinations folder.
As you can see in Figure 4.17, the jump list files are named with 16 hexadecimal characters, followed by .automaticDestinations-ms. The first 16 characters of the jump list filename pertain to the specific application used, and are fixed across systems. For example, b3f13480c2785ae corresponds to Paint.exe, adecfb853d77462a corresponds to MS Word 2007, and 918e0ecb43d17e23 corresponds to Notepad.exe. These characters comprise the application identifier, or AppID, and identify the specific application, including the path to the executable file. Mark McKinnon of RedWolf Computer Forensics, LLC, posted a list of the AppIDs to the ForensicsWiki at //www.forensicswiki.org/wiki/List_of_Jump_List_IDs.
Several analysts within the community have noted that the jump list files follow a specific file structure. In fact, at a Microsoft cybercrime conference in the fall of 2008, Troy Larson, the senior forensic investigator at Microsoft, stated that jump lists were based on the compound document structured storage binary file format [the format specification can be found at //msdn.microsoft.com/en-us/library/dd942138[v=prot.13].aspx] that was used in Microsoft Office prior to version 2007. This structured storage file format was also referred to as a file system within a file, in that the format was used to create a mini-file system within the contents of a single file, complete with directories and files. Given this, according to Rob Lee [of SANS], one way to view the contents of a jump list file is to open it in the MiTeC Structured Storage Viewer [available at //mitec.cz/ssv.html], as illustrated in Figure 4.18.
Figure 4.18. Jump list file open in the MiTeC Structured Storage Viewer.
Each of the numbered streams visible via the Structured Storage Viewer are, in turn, based on the file format associated with Windows shortcut files; shortcut files, when by themselves, usually end with the .lnk extension and have the nickname LNK files. Microsoft has made the binary format of these files, referred to as shell link files, available at //msdn.microsoft.com/en-us/library/dd871305[v=prot.13].aspx.
As these streams follow the binary format of shortcut files, they contain a considerable amount of information that can be valuable to an analyst. For example, the format contains last modified, last accessed, and creation time stamps [in UTC format] for the target file; that is, when a jump list stream is created, the MAC time stamps of the target file are used to populate these values within the jump list stream. Analysts need to understand what these time stamps represent, and that the jump list streams do not contain time stamps that indicate when the streams themselves were created, last accessed, or last modified.
The format can also contain additional information, such as command line arguments used, if any, and possibly a description string. One example of a jump list stream that may contain command line options [and a description string] has been seen in the use the Terminal Service client on Windows 7 to access remote systems, as illustrated here [extracted using a custom Perl script]:
Stream: 1
M: Tue Jul 14 00:01:53 2009
A: Tue Jul 14 01:14:27 2009
C: Tue Jul 14 00:01:53 2009
C:\Windows\System32\mstsc.exe /v:"192.168.1.24"
Connect to 192.168.1.24 with Remote Desktop Connection
Other streams extracted from within the jump list file contain the same time stamps as just shown, as they represent the last modified, last accessed, and creation dates for the file C:\Windows\System32\mstsc.exe. Remember, starting with Vista, updating of last access times on files has been disabled, by default.
The streams identified within the jump list file can also be extracted and viewed with a shortcut/LNK file viewer. For example, using the Structured Storage Viewer, we can extract a stream, rename the extension to .lnk, and then point the MiTeC Windows File Analyzer [interestingly enough, named WFA.exe] at the directory where we saved the stream. The .lnk files within the directory will be parsed and the extracted information displayed, as illustrated in Figure 4.19.
Figure 4.19. LNK file information visible in WFA.
The information available from the LNK streams within the jump list file will depend on the shortcut viewer application you choose. For example, the MiTeC Windows File Analyzer application does not have a column for a description string or command line options when parsing shortcut files.
So how would this information be valuable to an analyst? Well, for the jump list to be created and populated, the user has to take some action. In the previous example, the user accessed the Remote Desktop Connection selection via the Windows 7 Start menu. As such, the existence of this information within the jump list may provide clues [possibly when combined with other information] as to the users intent. The user may be a local user with legitimate access to the system, or an intruder accessing the system via some remote, shell-based access such as Terminal Services. In addition, jump list artifacts may persist well after the user performs the indicated actions or even after the target file has been deleted.
Note
DestList Stream
Figure 4.18 illustrates several streams within an automatic jump list file, including two numbered streams and a third one named DestList. There isnt much information available about the structure of the DestList stream; however, research indicates that following a 32-byte header, the elements of the DestList stream follow a consistent format. Each element is associated with one of the numbered streams within the jump list file, and is 114 bytes long, plus a Unicode string. Table 4.1 provides information regarding the identified items within each element, along with the offset, size, and description of each item.
Table 4.1. DestList Stream Header Elements
| 72/0×48 | 16 bytes | NetBIOS name of the system; zero padded to 16 bytes |
| 88/0×58 | 8 bytes | Stream number; corresponds to the appropriate numbered stream with the jump list |
| 100/0×64 | 8 bytes | FILETIME object |
| 112/0×70 | 2 bytes | Number of characters in the Unicode string that follows; the string is actually [size * 2] bytes long |
Each offset listed within the first column of Table 4.1 is indexed from the beginning of the element within the stream. The first element is found immediately following the 32-byte header, and each subsequent element is adjacent to the last, with no separator. The 8-byte FILETIME object within the element is most likely used to sort the elements into a most recently used [MRU] or most frequently used [MFU] list; this is further supported by research, by accessing several files through several applications [e.g., MS Word, Adobe Reader, MS Paint, etc.], recording the times, and then parsing the entire jump list file, including the DestList stream. This research was initially conducted by Jimmy Weg, a law enforcement officer and forensic analyst in Montana, and further validated by other analysts, including some of my own analysis.
The jump lists that weve looked at thus far have been from the AutomaticDestinations folder. Users can create custom jump lists based on specific files and applications, which populate the CustomDestinations folder [in the AppData\Roaming\Microsoft\Windows\Recent\ folder within the user profile], with jump list files that end in customDestinations-ms. As with the previously discussed jump lists, the files begin with a 16-character AppID name that is associated with a specific application; limited testing indicates a correlation between the two types of jump lists, with the same 16 characters associated with the same application between them. According to Troy Larson, these jump lists consist of one or more streams in the shortcut/LNK file format, without the benefit of each stream separated into individual streams, as is the case with the automatic destination jump lists.
There are a number of tools available to assist in parsing jump lists for inclusion in your overall analysis. Mark Woan has made not only a shortcut file analyzer [lnkanalyzer] freely available at //www.woanware.co.uk/?page_id=121, but he has also made a jump list viewer application [JumpLister] available at //www.woanware.co.uk/?page_id=266. Both tools require that .Net version 4.0 be installed on your system. I also found a description of a tool called Jump List Extractor, from Alex Barnett, but could not find any way to download a copy of the tool for evaluation.
Using the Microsoft specifications for the compound document binary and shortcut file formats, I wrote my own jump list parsing tool [in Perl, of course!]. This code consists of two Perl modules, one for parsing just the Windows shortcut file format, and the other for parsing the AutomaticDestinations folder jump list files as well as the DestList stream. This allows me a great deal of flexibility in how I can implement the parsing functionality, as well as how I choose to display the output. For example, using the two modules [literally, via the Perl use pragma], I wrote a script that would read a single AutomaticDestinations folder jump list file, parse the DestList stream, parse the numbered streams, and then display the entries in MRU order, as illustrated here:
Fri Apr 15 11:41:56 2011
C:\Windows\System32\mstsc.exe /v:" 192.168.1.12"
Tue Apr 5 16:26:19 2011
C:\Windows\System32\mstsc.exe /v:"192.168.1.10"
Wed Mar 16 18:45:58 2011
C:\Windows\System32\mstsc.exe /v:"ender"
Mon Feb 7 14:09:40 2011
C:\Windows\System32\mstsc.exe /v:" 192.168.1.7"
This example output is from the jump list file for the Remote Desktop Client, and illustrates connections that I made from my Windows 7 system to various systems in my lab, several of them virtual systems. This information could very easily have been displayed in a format suitable for inclusion in a timeline [see Chapter 7].
Warning
Jump List Parser
The Perl modules and scripts that I wrote for parsing jump lists are somewhat roughperhaps a better term would be alphaand at the time of this writing, not suitable for release, and are therefore not provided with the materials associated with this book. Also, I am concerned that even though Windows 7 has been available for some time, jump lists are relatively new and not well understood for their forensic value; as such, releasing a tool that provides information from jump lists without the analyst really understanding the nature or context of that information would simply lead to confusion. I do hope to release the tool at some point in the future, after Ive had a chance to clean up the code and make it more usable.
ProDiscover [all but the free Basic Edition] also includes a built-in full featured Jump List Viewer, as illustrated in Figure 4.20.
Figure 4.20. ProDiscover Jump List Viewer.
To populate the Jump List Viewer, open your ProDiscover project, right-click on the Users Profile directory, and choose Find Jump List Files from the dropdown menu. ProDiscover will scan through the subdirectories, looking for, cataloging, and parsing the various automatic and custom jump list files [sans the DestList stream in the automatic jump list files, as of ProDiscover version 7.0.0.3].