We now describe generating GUI signatures for applications and then how we use these signatures to enforce per-application network behavior.
4.4.1
Empty Signatures
Applications can be divided into two main categories as shown in Figure 4.3. Applications either come with a front-end GUI or not. Applications without a GUI cannot generate a signature for our approach. In these cases, we allow for a known, empty signature can be created. Since these applications do not interact with the user, our approach is unable to determine legitimacy of new connections. Therefore, we approve all connections from processes with a known empty signature (i.e., no GUI). We identify these applications with empty signatures by their full path.
Figure 4.3: Applications can be broken down by whether a GUI component exists and further broken down into what is considered malicious or not. Red shaded boxes are considered malicious.
4.4.2
Generating Application Signatures
Next, we discuss building our signature database using applications with a GUI. In total, we con- sider 3 applications for signatures. More detail is provided on application signatures in Section 4.6. Building a database of GUI application signatures requires loading applications and generating po- tential paths. While in practice signatures could be built over time with passive data collection or automated GUI techniques [139], we chose to rapidly establish signatures by manually launching applications and exhaustively exercising all GUI possibilities. As a result, we will also generate all possible paths for a given application.
Our approach has the local collector running on an end-host report all monitored Windows messages and generated network traffic to a centralized collection server that aggregates data from all clients. The data collection can either be used for the signature generation phase or later used for enforcing derived signatures (Figure 4.2).
Sink Terminating Paths
Some paths reported by the collector do not result in a network sink. For example, opening the “About” dialog in an application may generate a path that does not terminate with a sink node if no network connection is generated. Depending on the application, the number of non-sink terminating paths will vary and will be excluded from the signature.
We determine paths that end in network sinks by monitoring user interactions with objects. Any time a user interacts with a GUI object, we report and collect the full path starting from object interacted as the leaf node through root node. Essentially, we start from the leaf object and traverse the hierarchy of objects until we hit the Desktop, which is the parent of GUI applications. This method allows us to determine the path required to reach an object. A common example is applications that have a print dialog, which can typically be reached through multiple interaction paths such as using the menu or hotkeys (e.g., Ctrl+p). Important to the printing process is that a print dialog window appears and the user left clicks (or uses the keyboard) to select the print button.
Path
Text: File Type: Menu Parent: MainApp Text: Print (Ctrl+P) Type: MenuItem Parent: Menu Action: Left-clickAction: Left-click Text: Print Type: Button Parent: MenuItem Action: Left-click Network access Text: Print Type: Window Parent: Desktop
New window created
Figure 4.4: Common interaction path for printing. The dashed arrow and box represent the part of the path that is inferred.
Time Host Process ID Entry
t0 10.0.1.99 5561 Menu clicked: [(&File:Menu:Mail:#32770:2)
→ (&Mail:#32770:Desktop::1) → (Desktop::0)]
t1 10.0.1.99 5561 Menu item clicked: [(&Print:MenuItem:File:Menu:3)
→ (&File:Menu:Mail:#32770:2) → (&Mail:#32770:Desktop::1)
→ (Desktop::0)]
t2 10.0.1.99 5561 Window Disabled: [(&Mail:#32770:Desktop::1)
→ (Desktop::0)]
t3 10.0.1.99 5561 Button clicked: [(&Print:Button:Print:#32770:2)
→ (&Print:#32770:Desktop::1) → (Desktop::0)]
t4 10.0.1.99 5561 Network: TCP(10.0.1.10:9100:SYN)
Table 4.1: Data collected at the Collection server when a user clicks the print button on the print dialog screen for an application. GUI object entries are named using the structure of object ident = text:class:parent text:parent class:depth. Double colons represent NULL values.
When applications create a new window as a result of interactions, the new window is frequently not considered a child of the parent application. Instead, the new window is a direct child of the Desktop. In many cases, we are able to determine inferred paths using a couple of different features. First, we know the new window is related to the original window interacted with because the new window does belong to the same process ID. Second, applications often disable the original window using the WM DISABLE message. Thus, we can infer the previous interaction was a prerequisite for next interaction.
Figure 4.4 shows how some paths need to be inferred rather than directly obtainable by the hierarchical structure. In particular, some interactions create new relationships rather than follow- ing a direct parent-child relation. As with the print example, using the menu to print a document causes a new window to be created that is a child of the Desktop rather then the menu itself since the drop down menu is destroyed (visually removed) after choosing print and thus cannot have
child nodes. Table 4.2 shows how we are able to use data collected to determine paths that result in network activity. In particular, we see that by clicking the print button in the print dialog box a new TCP connection is attempted. By exhaustively exploring all possibilities in the GUI, we find all paths that result in network activity.