UAL Thank Us Later: Leveraging User Access Logging for Forensic Investigations
CrowdStrike analysts recently began researching and leveraging User Access Logging (UAL), a newer forensic artifact on Windows Server operating system that offers a wealth of data to support forensic investigations. UAL has proven beneficial to help correlate an account and the source IP address with actions performed remotely on systems.
To help your investigations, this blog post provides an overview of UAL databases and offers examples of interpreting the treasure trove of data that they contain.
What Is User Access Logging?
UAL is a feature included by default in Server editions of Microsoft Windows, starting with Server 2012. As defined by Microsoft, UAL is a feature that “logs unique client access requests, in the form of IP addresses and user names, of installed products and roles on the local server.”
This means that UAL records user access to various services running on a Windows Server. The access is logged to databases on disk that contain information on the type of service accessed, the user account that performed the access and the source IP address from which the access occurred. One key element of UAL is that each record is based on the combination of username, source IP and service accessed — so it’s naturally suited for identifying anomalous or rare access to a system.
With default settings, this information is retained for up to three years. Naturally, this data can be extremely valuable in forensic investigations. Unfortunately, there’s a marked lack of awareness of this type of artifact in the digital forensic community. Many forensic solutions do not parse these databases, and therefore threat analysts could potentially miss data relevant to an investigation.
Where to Find UAL Data
UAL database files are stored under the directory C:\Windows\System32\LogFiles\Sum. Inside this directory, you’ll find up to five Extensible Storage Engine (ESE) database files with .mdb extensions. The screenshot in Figure 1 provides an example of what the contents might look like.
The files shown above include:
- Current.mdb (UAL database — current year; active copy)
- <GUID>.mdb (UAL database — current year)
- <GUID>.mdb (UAL database — previous year)
- <GUID>.mdb (UAL database — two years prior)
- Systemidentity.mdb (database containing information about the server, including a map of RoleGuid values to Role names – more on this below)
The Current.mdb file contains UAL data for the current year, while the two previous years are stored in .mdb files with GUID-style filenames. Per Microsoft:
“UAL makes a copy of the active database file, current.mdb, to a file named GUID.mdb every 24 hours. On the first day of the year, UAL will create a new GUID.mdb. The old GUID.mdb is retained as an archive. After two years, the original GUID.mdb will be overwritten.”
This means there can be up to three years of historical data stored on the UAL (i.e., data from the previous year, two years prior and the current year up to the present).
Following the above, Current.mdb and the GUID-style files contain the same set of tables. These files will include the CLIENTS table, where some of the juiciest forensic data is stored — this is where you’ll find the historical records of users accessing various services.
Table 1 shows a sample record from the CLIENTS table. Please note that some of the fields are omitted for visibility (see Appendix for a full listing of all tables and fields in the UAL databases).
Table 1. Sample UAL CLIENTS table record
In the above example, the UAL record indicates that the user DOMAIN\User1 accessed the system via SMB on 2019-03-12 at 18:06:56 UTC, coming from the source IP address 10.10.12.200.
The source IP address is stored in the Address field in hexadecimal (0a 0a 0c c8 = 10 10 12 200). The InsertDate field contains the UTC timestamp of the first access for the year for the combination of user, RoleGuid and source IP. LastAccess is similar but represents the most recent access for the year.
The TotalAccesses value of 1 indicates that this was the only access for the year (again, based on the combination of user, source IP and RoleGuid). If access occurred on additional days between the InsertDate and LastAccess, the total count would be included in this field. In addition, a daily count of the number of accesses per day would be included in additional fields named Day1 up to Day366, which represent the day of the year the access occurred (see Appendix for more details). Unfortunately, a full timestamp is only included for InsertDate and LastAccess — nothing in between. But as will be shown, this is plenty.
The RoleGuid field represents the type of service that was accessed. In this case, it was 10a9226f-50ee-49d8-a393-9a501d47ce04, which corresponds with what is known as the File Server Role. This typically represents SMB access, though it’s possible other protocols may be logged here as well.
RoleGuid values are mapped to human-readable Role Names in the SystemIdentity.mdb database, under the ROLE_IDS table. Table 2 shows a sample ROLE_IDS table.
|c50fcc83-bc8d-4df5-8a3d-89d7f80f074b||0997dbd9-4db4-49aa-8ec5-8f5c6ae1c870||Active Directory Certificate Services|
|b4cdd739-089c-417e-878d-855f90081be7||0997dbd9-4db4-49aa-8ec5-8f5c6ae1c870||Active Directory Rights Management Service|
|bbd85b29-9dcc-4fd9-865d-3846dcba75c7||0997dbd9-4db4-49aa-8ec5-8f5c6ae1c870||Network Policy and Access Services|
|7fb09bd3-7fe6-435e-8348-7d8aefb6cea3||0997dbd9-4db4-49aa-8ec5-8f5c6ae1c870||Print and Document Services|
|4116a14d-3840-4f42-a67f-f2f9ff46eb4c||0997dbd9-4db4-49aa-8ec5-8f5c6ae1c870||Windows Deployment Services|
|d8dc1c8e-ea13-49ce-9a68-c9dca8db8b33||0997dbd9-4db4-49aa-8ec5-8f5c6ae1c870||Windows Server Update Services|
Table 2. Sample ROLE_IDS table
A Note on Roles
The Roles referenced by UAL data are tied directly to Server Roles installed on Windows Server systems. This is done via the Server Manager application, by clicking on Manage → Add Roles and Features.
This will bring up a menu that lists available Roles that can be installed, which will look similar to what’s shown in Figure 3.
Certain Roles are included in the ROLE_IDS table by default, regardless of whether or not they are enabled. Other Roles may get added to the bottom of the ROLE_IDS table when they are installed via the Server Manager. For example, when making a server into a Domain Controller, one would install the Active Directory Domain Services Role, at which point this server would be added to the bottom of the ROLE_IDS table, and access under this Role would start being logged in the CLIENTS table. However, not every installed Role will necessarily end up being tracked by UAL.
File Server Role
From a forensic perspective, one of the most fruitful Roles in UAL analysis is the File Server Role. It can be found as a subitem under File and Storage Services in the Server Manager menu.
As shown in Figure 4, Microsoft notes that the File Server Role “manages shared folders and enables users to access files on [a] computer from the network.” The consequence is that SMB access is logged in UAL databases under the File Server RoleGuid. This means UAL databases potentially contain up to three years of historical SMB access. This data can be extremely valuable during investigations, as we’ll demonstrate in the next section.
It’s important to note that this SMB logging includes when, for example, a user maps a file share and performs actions that use SMB under the hood, including SMB named pipes. For example, remotely interacting with a service using sc.exe will result in File Server UAL entries on the target system, because an SMB named pipe (\\.\PIPE\svcctl) is used. Similarly, a UAL File Server entry for a user doesn’t necessarily mean that the user purposefully used SMB.
As a side note, even if the File Server Role is not explicitly enabled, SMB access will still be logged by UAL (as long as the firewall rules to allow SMB access are enabled). When the File Server Role is installed, these firewall rules are automatically enabled.
Interpreting UAL Data
Let’s step through some quick examples to demonstrate just how powerful UAL analysis can be. Please note that the following data is simulated, but this information is very similar to what you’d see in real-world scenarios when analyzing UAL data.
In this first example, we’re analyzing a system called WEBSRV01. We already know that PsExec was used to execute the malicious file C:\Windows\malware.exe on 2020-11-04 at 19:53:08 UTC through analysis of host artifacts. However, all event logs have rolled and were not forwarded elsewhere. We’re trying to understand which user account executed PsExec targeting WEBSRV01 and from which system the activity originated. After parsing the UAL CLIENTS table (from the 2020 database file), the following results are returned.
Table 3. Sample CLIENTS table
The first thing that immediately jumps out is the row related to the account CORP\banderson that has a LastAccess value matching precisely the time of PsExec usage identified via other artifacts. This record’s address value is 10.20.49.201, meaning the activity originated from a device with this IP. We also note that the TotalAccesses value is 3. This means that for all of 2020, the CORP\banderson account only accessed WEBSRV01 via SMB from this IP address three times — and what’s more, all three occurred around the time of the PsExec activity (because all of the accesses would have occured between the InsertDate and LastAccess times).
Another anomaly in the above is we have the local Administrator account for WEBSRV01 accessing it from the IP address of another system. Based on the TotalAccesses value, this is a rare activity, having only occurred once in 2020, with all of the other local Administrator access coming from localhost.
|Simplify forensic data collection and analysis with the CrowdStrike Falcon Forensics™ solution. Incident responders can respond faster to investigations and conduct compromise assessments, threat hunting and monitoring all in one location with Falcon Forensics. Responders can gather comprehensive data and analyze it quickly via pre-built dashboards and easy search capabilities for both live and historical artifacts. Learn more about how Falcon Forensics works.|
UAL at Scale
Things get even more exciting when you start pulling UAL at scale from many systems at once. Even simply sorting the output by InsertDate can quickly identify suspicious activity. When aggregating CLIENTS table data from multiple systems, it’s not uncommon to observe scenarios similar to the example in Table 4.
Table 4. Sample UAL data from multiple systems
In this example, the account CORP\abcsvc accessed eight systems in rapid succession via SMB, coming from the IP address 10.20.52.40. Further, in each case the TotalAccesses value is 1, meaning this was the only time for the year that this account accessed each system via SMB from the source IP address.
When combined with other indicators to pivot from, UAL analysis at scale can help drive the direction of the investigation. For example, if there is a known compromised user account, UAL analysis can quickly identify other (Server 2012+) systems that the account accessed, by searching for records where the AuthenticatedUserName value matches the compromised user name.
Similarly, if there is a system that’s known to be compromised, analyzing UAL at scale can provide rapid insights into threat actor lateral movement activities. This can be accomplished by finding UAL entries where the Address field matches the IP address of the compromised system. This can quickly provide an overview of which accounts a threat actor was using from the compromised server, as well as systems targeted for lateral movement. (Did we mention this data is retained for up to 3 years by default?)
Armed with pivot points like these as a starting point, one can quickly glean critical insights from UAL data. Even without any other indicators to go on, it’s possible to spot anomalous activity by looking out for rare combinations of user, source IP address and RoleGuid via the TotalAccesses field.
Correlating UAL Data
Correlating UAL data with other artifacts can also help fill in the blanks when event log data is unavailable. An investigation timeline populated via host artifact analysis may yield something like that shown in Table 5.
Table 5. Sample timeline before UAL enrichment
By adding UAL data to the timeline and sorting by timestamp, everything falls into place, as shown in Table 6.
|APPSRV01||2020-12-01T04:10:50Z||UAL entry||RoleGuid: File Server | AuthenticatedUserName: CORP\rsmith-adm | Address: 10.100.2.201 | TotalAccesses: 1|
|APPSRV02||2020-12-01T04:10:50Z||UAL entry||RoleGuid: File Server | AuthenticatedUserName: CORP\rsmith-adm | Address: 10.100.2.201 | TotalAccesses: 1|
|DC01||2020-12-01T04:10:50Z||UAL entry||RoleGuid: File Server | AuthenticatedUserName: CORP\rsmith-adm | Address: 10.100.2.201 | TotalAccesses: 1|
Table 6. Sample timeline after UAL enrichment
After adding UAL data, we can now clearly see that malware.exe was copied to all of these systems by CORP\rsmith-adm; and that this activity originated from the IP address 10.100.2.201. Aside from subsequently focusing analysis efforts on that system, you can also identify additional systems of interest by searching the aggregated UAL data for entries with matching Address or AuthenticatedUserName values from around the same timeframe.
UAL Analysis Tools
On live systems, analysts can access UAL data via PowerShell cmdlets or WMI. In image analysis, UAL databases can be parsed with any tool that supports parsing ESE databases, such as esedbexport, which is part of Joachim Metz’s libesedb project.
At least two recently developed solutions are used for parsing UAL data from a forensic perspective: Eric Zimmerman’s SumECmd and Brian Moran’s KStrike. These tools add value by automatically converting RoleGuids to Role Names and automatically parsing the Address field to a human-readable IP address.
More to Come
These examples are only a tiny glimpse into the many powerful applications of UAL data in forensic investigations. The forensic analysis of UAL databases can provide exceptional insights to the forensic analyst. Currently, it’s an understudied artifact that’s also under-represented by forensic tools. We hope that this information is helpful for your analyses; additional research and testing are needed to learn more about this artifact and the valuable insights it can provide.
Appendix: UAL Databases and Tables
Here is a description of all tables included with the UAL database files.
Current.mdb (and <GUID>.mdb files)
As mentioned, this table stores the heart of the UAL data. It includes the information on user accounts accessing services on the server. Each row is based on the combination of user + source IP + RoleGuid. (In other words, if a user accesses a system via SMB from two different source IP addresses, each will get their own row). The CLIENTS table includes nine fields.
|AuthenticatedUserName||Domain\User account performing the access. Can include local accounts and domain accounts, including computer accounts.|
|Address||Source IP address from which access occurred. Can include IPv4 or IPv6, as well as localhost values.|
|RoleGuid||The type of service accessed. RoleGuids are mapped to Role names in SystemIdentity.mdb.|
|InsertDate||UTC timestamp of the first access for the year|
|LastAccess||UTC timestamp of the most recent access for the year|
|TotalAccesses||Count of accesses for the year (based on RoleGuid + AuthenticatedUserName + Address)|
|Day1 … Day366||Count of accesses per day for each day of the year|
|TenantId||Have seen this populated in relation to the Active Directory Domain Services RoleGuid, but interpretation is unclear. Microsoft defines it as “a unique GUID for a tenant client of an installed role or product that accompanies the UAL data, if applicable.”|
|ClientName||Unknown, have not seen it populated in the wild|
Table 7. CLIENTS table fields
The DNS table contains historical IP to hostname mappings. It appears this table is only populated if the server being analyzed has the DNS Server Role installed. The hostnames and IPs are likely related to clients of the DNS server, but more research is needed to determine what specifically causes this table to be populated. This table can aid in determining previous IP addresses associated with systems in instances where DHCP logs are not available. The DNS table includes three fields.
|HostName||Hostname associated with the IP address|
Table 8. DNS table fields
The ROLE_ACCESS table contains a high-level view of the types of Roles that have been accessed on the system, and when the first and last accesses occurred. It contains three fields.
|RoleGuid||RoleGuid value (associated with human-readable Role Name in SystemIdentity.mdb)|
|FirstSeen||UTC timestamp of the earliest access to the Role type for the year|
|LastSeen||UTC timestamp of the most recent access to the Role type for the year|
Table 9. ROLE_ACCESS table fields
The VIRTUALMACHINES table contains information on HyperV virtual machines running on the system. As of this writing, we have not come across it populated in the wild. It contains the following fields:
Table 10. VIRTUALMACHINES table fields
As mentioned, the ROLE_IDS table contains a mapping of RoleGuid values to human-readable Role Names. It includes three fields.
|RoleGuid||RoleGuid (GUID value)|
|ProductName||Typically related to the OS edition, it can be GUID value or human-readable. Microsoft defines as “The name of the software parent product, such as Windows, that is providing UAL data.”|
|RoleName||Human-readable Role Name for the RoleGuid|
Table 11. ROLE_IDS table fields
This table provides a mapping associated with the year for storing the <GUID>.mdb files. Each row contains two fields.
|Year||Year associated with database filename (e.g., 2021)|
|Filename||Database filename associated with the year|
Table 12. CHAINED_DATABASES table fields
This table contains information related to the operating system and hardware of the system. It contains the following fields, most of which are self-explanatory.
|Field Name||Field Name|
Table 13. SYSTEM_IDENTITY table fields
One interesting aspect of the SYSTEM_IDENTITY table is that it appears to have a new entry created each time one of the fields changes. For example, when changing a system’s hostname or domain, a new row will be created showing the new SystemDNSHostName and SystemDomainName, while the old data will still be available in previous rows. The LastBootUpTime field will then only continue to be updated for the latest row. Table 14 provides an example of this.
Table 14. Sample SYSTEM_IDENTITY table data
- Microsoft TechNet page on UAL: https://docs.microsoft.com/en-us/windows-server/administration/user-access-logging/get-started-with-user-access-logging
- Microsoft TechNet page on Server Roles: https://docs.microsoft.com/en-us/windows-server/administration/server-core/server-core-roles-and-services
- UAL PowerShell cmdlets: https://docs.microsoft.com/en-us/powershell/module/useraccesslogging/?view=windowsserver2019-ps