Inside the domain of vulnerability research, many different methodologies exist for how a researcher may start their journey with auditing an application. This blog provides information on how to enumerate the attack surface of userland applications that are deployed on the Windows operating system.
The purpose of attack surface enumeration is to gather specific data about a targeted application. Accompanying information such as examples and tool usage are also showcased to aid the reader.
The point of attack surface enumeration is to identify all paths where user-controlled data affects an application.
Given that not every application is going to be the same, the attack surface is dependent on what functionality and technologies an application utilizes. Failure to perform proper enumeration can result in an incomplete map of the attack surface.
There are many different attack vectors that are specific to each environment such as permissions on local resources, how an application communicates with a service, and the privilege level of a service or application.
During attack surface enumeration, we are not only interested in the data that is operated on, but also how the application uses the data.
The file format of an application is a crucial part in the attack surface enumeration phase, so it is essential to know that each file type has a predefined format.
The specifications for these formats are available online and can offer insight into the data and its purpose within a file.
For example, refer to Figure 1 depicting a Windows PE binary in a hex editor.
The value at offset 0x3C is an offset that points to the location of the PE file signature within a PE binary.
As seen above, the value at offset 0x80 is “0x50450000″, showing that this is in fact a PE binary. Most of the applications we will come across on Windows are either C, C++, or .NET. However, these are not the only ones. Now that we have talked about file formats, let’s review identifying resource permissions.
Permissions are a core component of operating systems and are implemented in many ways.
When it comes to the Windows operating system, permissions are assigned using Access Control Lists (ACL). ACL’s are composed of Access Control Entries (ACE’s) which hold two separate permission structures.
The first is a Discretionary Access Control List (DACL) and the second is a System Access Control List (SACL). The DACL is the one we are most interested in since it defines who can access a specified resource to modify, write, read, or execute respectively. The SACL, on the other hand, is for logging purposes for the security event log.
To view the DACLs of a given resource, we can use the tool
icacls from the Windows command line.
icacls presents information about both inherited and non-inherited permissions. In Windows, most files and subfolders inherit permissions from the parent folder. The tool
SysInternals Suite is a Graphical User Interface (GUI) program that reports a more easily readable result of DACL’s for a given folder.
It also automatically reports any files or sub-folders that hold different DACL’s than the parent folder that was designated as the entry point to scan.
These are both examples of static analysis tools. For an example of
AccessEnum usage, refer to Figure 2.
Next, we will discuss the difference between static and dynamic analysis.
Dynamic analysis provides insight into the functionality of an application while it is running. An example of a dynamic analysis tool is
SysInternals which is used to view different types of operations performed by an application.
Static analysis provides insight into the base functionality of an application while it is not running. An example of a tool that has functionality to perform static analysis is
IDA Pro from
Hex-Rays which is capable of disassembling binary applications.
When performing analysis, the usage of both dynamic and static analysis can yield better results for later analysis. Now that we have covered some basic background information, let’s move to the beginning of attack surface enumeration.
The attack surface for Windows userland applications is massive. Many different functionalities exist that an application may choose to implement.
Throughout the process of attack surface enumeration, we will typically look for the following:
Each item in the list exposes a fair amount of functionality that an application can utilize. While some functionality is implemented directly like permissions, others like the Clipboard mechanism are not.
When enumerating local resources that an application uses, different attack vectors are exposed. These exist because of improper assignment of Windows permissions on local resources. Improper permission assignment can lead to the following attacks.
These are just a few examples of the many different types of attacks that can be performed. These attacks are possible because permissions are set for a resource that allow it to be accessed or modified by unintended users.
As an example, we are going to enumerate paths to DLL’s (Dynamic Linked Libraries) that an application loads during runtime and record the permissions assigned to them.
The application we are targeting is
Notepad.exe and the first tool we are using is
The reason we use
Procmon is because of its ability to gather specific data that we are interested in. The way
Procmon handles this is through the usage of
Filters that are user provided. Each
Filter can be broken down into four main columns.
The order of these column names are as follow:
We will expand on the values we provide to these columns to build our
Filter further on in this section.
Now that we have covered what we want to achieve and how we plan to achieve it, let’s put this into action.
Procmon and access the
Filter view. To do this, enter the hotkey
Ctrl+L and a window like Figure 3 will be present.
The type of
Filter we are interested in is a
Process Name filter.
This filter has a
Relation value of
Value value of
Notepad, and an
Action value of
The reason we use
contains for the
Relation value is because sometimes a process interacts with services that have a similar naming convention.
The next filter we are interested in is an
Operation based filter. This filter has a
Relation value of
Value value of
Load Image, and
Action value of
The reason for
Load Image is because
Procmon treats any functionality that maps memory inside of a process under this general
Column value of
The created filters should be like Figure 4, given the choice of the value for the
After the creation of these filters, start
Notepad.exe and record the unique directories in the
It is worthwhile to give
Procmon ample time to capture all
Load Image operations, because some resources take longer to load. The next step is to use
AccessEnum to find out the permissions of these different paths.
To perform this action, select the
Directory option then navigate to the first path in the list of recorded paths from
Procmon and hit
After this, record the results of the different permissions for each file and folder with unique permissions for further analysis. Now that we have finished showcasing dynamic analysis, let’s review the static analysis approach.
Common Windows API functions that handle loading DLL’s into a process’s memory can be seen below:
We can look for these functions inside the import table of an executable using a tool like
For example, the
LoadLibraryA function takes a single argument that can either be the DLL name, the full path including DLL name, or a relative path including the DLL name.
For an example, refer to Figure 5 depicting the identification of the
LoadLibraryA and associated functions inside of a binary via the Imports window.
Now that we have identified the presence of these functions, the next step is locating calls to them within the application. In order to perform this,
double click on a specific function. This will bring us to the
idata section within
idata section holds information related to functions that an application imports from external resources.
We now should be presented the function location in the
idata section within the ‘IDA View-A’ window like Figure 6.
LoadLibraryA is still highlighted press the hotkey
x to open the cross-reference window.
This window is responsible for showcasing all references of calls to this specific function that exist within the application. The current new window should be like Figure 7.
Now that we have a list of all calls to this function, the next thing we want to do is record each virtual address in the binary where the calls are made.
To do this,
double click on an individual result in the cross-reference window to be taken to the location where the
For an example, refer to Figure 8 depicting the location where the specific
call occurs.Now that we have covered resource permissions, let us cover identifying active ports.
When enumerating an application, we should identify the presence of networking capabilities. These capabilities can range from a local socket acting as a proxy to the point of establishing remote connections. The reason this is interesting is because it provides immediate insight into the exposed attack surface of an application.
When it comes to identifying these sockets, this can be done either through dynamic or static analysis. We can use the tool
SysInternals to identify TCP sockets via dynamic analysis.
TCPView provides information for both UDP and TCP endpoints exposed by an application. The information we are interested in is either the presence of Established or Listening connections.
These can be viewed from the results in the
State column. The default usage of
TCPView is fine for this case and when executed should present a window like Figure 9.
Another method of dynamic analysis could be through the usage of the
Procmon tool from
For this scenario, the creation of a
Filter for both
Process Name and
Operation is useful.
However, unlike in previous examples four different
Operations are of interest to record. The four operations are TCP Receive, TCP Connect, TCP Send, and TCP Disconnect. These operations will be provided inside of the
Value column when building the
Now that we have covered two examples for dynamic analysis lets cover static analysis.
The desired filter should look like Figure 10, depending on the usage of either
contains values for the
Relation column of the
Operation based filter.
For static analysis, we can use
IDA Pro to identify functionality associated with both the creation and usage of windows sockets.
The approach can be carried out similarly to how we performed the enumeration of
LoadLibrary function usage in a previous section in this blog post.
The list below shows some functions that are associated with Windows networking.
After proper identification of usage, we will record the yielded results for future analysis.
One thing to remember is that the main executable may not handle all functionality on its own. It may have DLL’s or external executables that it allows to handle this functionality instead. When performing the enumeration, make sure to cover all DLL’s or executables that an application uses.
A handle is used by an application to interact with certain types of data objects. When a data object is requested for use by an application, a specific handle is created and used by the application to reference that specific data object.
Many different types of objects may exist with an open handle. Most of these open handles can be seen by using the tool
We will want to start
Procexp as an administrator so that it can properly enumerate information it displays.
If we start
Procexp as a normal user, we will miss desired information such as type of objects that a handle exists for. In order to view open handles for a given process, we must activate the handle window inside of
To do this, go to the top menu item
Lower Pane View and select
Now whenever we select a process, the lower pane will populate with information about open handles. For an example, refer to Figure 11 depicting open handles of the Section object type.
From the list of open handles, right click on a specific handle then go to properties. From that point, we can view the security details and see the permissions assigned to each open handle. When recording this data, we must take note of the permissions assigned and the type of object the handle is for.
When it comes to the implementations of Inter-Process Communication (IPC), Windows supports quite a few different mechanisms to achieve this depending on the desired functionality.
The majority of these can be identified statically quite quickly, so that is how we are going to approach this.
Each of these provided mechanisms can be identified via static analysis using a tool such as
IDA Pro. The same methods described earlier in this blog post on usage of
IDA Pro can be used similarly here.
For each mechanism, we have a list of functions associated to identify in an application.
After identifying what mechanisms are exposed, record the yielded output for later analysis.
Whenever performing attack surface enumeration, it is essential to identify the level of privilege a given process has.
The way to accomplish this task is with
Procexp like before, however, this time we are going to change the type of column names displayed.
To do this, we
Right+Click on the
Column names to bring up an option called
Select Columns.... The current view should be like Figure 12, depicting the
Select Columns... option.
Then we select the
Process Image tab and make sure to tick the box in the
User Name option. Now we have a new
User Name column, and this is the user privilege that the process has.
For an example, refer to Figure 13 depicting the desired output inside of
The results of <access denied> is caused by the privilege level that
Procexp is currently running as. In order to fix this issue, start
Procexp as an administrator. Now that we can easily identify the privilege level of a given process, we will want to record this data for later analysis.
The process of identifying what services an application installs can be performed using a tool called
The output from
PsService can be hard to view in command prompt, so instead we can redirect the output to a file for analysis.
First, create a list of currently installed services by executing
PsService, then after installing an application execute
PsService again to record newly created services.
For an example of default usage, refer to the Figure 14.
While Windows is quite complex and has many different aspects to think of when trying to cover attack surface enumeration, this post hopefully provided insight into the more prominent aspects.
With the usage of this general approach one can map out the attack surface of Windows userland based applications.
It is important to remember that the purpose of attack surface enumeration is to gather as much information about our target. Think of it like reconnaissance; the impact of the information we gain directly affects the outcome of future attacks.
If you’d like to read more about Windows vulnerabilities, you can also read our post on Abusing Insecure WCF Endpoints here.
VerSprite's Research and Development division (a.k.a VS-Labs) is comprised of individuals who are passionate about diving into the internals of various technologies. From advanced technical security training to our research for hire B.O.S.S offering, we help organizations solve their most complex technical challenges.
Learn More →